sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

sim/README: Mention macOS

Browse Source
This commit is contained in:
YAMAMOTO Takashi 2020-03-27 15:43:47 +09:00 committed by Xiang Xiao
parent ebc6627b77
commit 2f6d458bcf
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
boards/sim/sim/sim/README.txt
View File

@ -27,7 +27,7 @@ Description
----------- -----------
This README file describes the contents of the build configurations available This README file describes the contents of the build configurations available
for the NuttX "sim" target. The sim target is a NuttX port that runs as a for the NuttX "sim" target. The sim target is a NuttX port that runs as a
user-space program under Linux or Cygwin. It is a very "low fidelity" user-space program under Linux, Cygwin, or macOS. It is a very "low fidelity"
embedded system simulation: This environment does not support any kind of embedded system simulation: This environment does not support any kind of
asynchronous events -- there are nothing like interrupts in this context. asynchronous events -- there are nothing like interrupts in this context.
Therefore, there can be no pre-empting events. Therefore, there can be no pre-empting events.
@ -84,8 +84,9 @@ graphical front-end to GDB:
gdb> b user_start gdb> b user_start
gdb> r gdb> r
NOTE: This above steps work fine on both Linux and Cygwin. On Cygwin, you NOTE: This above steps work fine on Linux, Cygwin, and macOS.
will need to start the Cygwin-X server before running ddd. On Cygwin, you will need to start the Cygwin-X server before running ddd.
On macOS, it's probably easier to use lldb instead of gdb.
Issues Issues
^^^^^^ ^^^^^^
@ -121,11 +122,11 @@ NuttX heap. The memory management model is exactly the same in the simulation
as in a real, target system. This is good because this produces a higher as in a real, target system. This is good because this produces a higher
fidelity simulation. fidelity simulation.
However, when the simulation calls into Linux/Cygwin libraries, it will still However, when the simulation calls into the host OS libraries, it will still
use these small simulation stacks. This happens, for example, when you call use these small simulation stacks. This happens, for example, when you call
into the system to get and put characters to the console window or when you into the system to get and put characters to the console window or when you
make X11 calls into the system. The programming model within those libraries make X11 calls into the system. The programming model within those libraries
will assume a Linux/Cygwin environment where the stack size grows dynamically will assume the host OS environment where the stack size grows dynamically
and not the small, limited stacks of a deeply embedded system. and not the small, limited stacks of a deeply embedded system.
As a consequence, those system libraries may allocate large data structures on As a consequence, those system libraries may allocate large data structures on
@ -156,9 +157,9 @@ The simulation build is a two pass build:
and then linked with nuttx.rel to generate the simulation program. and then linked with nuttx.rel to generate the simulation program.
NuttX is a POSIX compliant RTOS and is normally built on a POSIX compliant NuttX is a POSIX compliant RTOS and is normally built on a POSIX compliant
host environment (like Linux or Cygwin). As a result, the same symbols are host environment (like Linux, Cygwin, or macOS). As a result, the same
exported by both the NuttX domain and the host domain. How can we keep them symbols are exported by both the NuttX domain and the host domain. How can
separate? we keep them separate?
This is done using the special file nuttx-name.dat. This file just contains a This is done using the special file nuttx-name.dat. This file just contains a
mapping of original function names to new function names. For example, the mapping of original function names to new function names. For example, the