> 1. Daemon / Service:
>
> 1.1. I would like to have application running as daemon in the
> background all the time. Is this possible?
NuttX supports the daemon() API.
https://man7.org/linux/man-pages/man3/daemon.3.html
Lots of examples to look at:
$ grep -ri daemon apps | wc -l
2384
Most do not call daemon() but do the same thing inline. Using daemon()
would be better:
$ grep -r "daemon[(]" apps | wc -l
46
> 1.2. On application error / crash I would like the application to
> restart so it is always available. Is this possible?
If properly configured, the parent task can receive the Death-of-Child
signal, SIGCHLD when a task dies. But not a "true" Linux deamon which
would re-parent itself to the init process. daemon() does not re-parent
today, but should.
You could probably use on_exit() or atexit() to have a task restart
itself too.
I a more costly design, you could have another thread monitor the daemon
with waitpid() to see it it executes. You can also check of the daemon
is still running by using kill() with signal zero.
> 1.3. There is a Watchdog in NuttX. Who feeds the watchdog? Is it
> possible that there are two watchdogs: one for the OS and second for
> the Application? In case of either system / application crash the
> system should be rebooted by one of the watchdogs. Is this possible?
These are your design decisions.
> 1.4. Is it possible to call the nsh as sub-process from within my
> application so the application keeps feeding the watchdog?
NuttX supports the system() interface to run NSH commands:
https://man7.org/linux/man-pages/man3/system.3.html
> 1.5. If the timing is important should I rather keep my application in
> the foreground and abandon the idea of a daemon?
Daemonizing has no effect on the priority or timing of the daemon
> 2. Sim -> HW.
>
> 2.1.. I would like to develop my application first on the Simulator,
> and then when its working at some point I would like to port is to the
> real hardware. How my firmware could know what Arch is it currently
> running on?
NSH supports the uname command:
https://man7.org/linux/man-pages/man1/uname.1.html
> 2.2. On Sim I would like to produce log messages, while on the real
> Hardware driver actions should be performed. What would be the best
> way to achieve that? Is is possible to determine hardware / arch at
> runtime? Should I use #ifded CONFIG_BLAH macros to attach driver code
> when real hardware is selected?
Using uname or configuration options sound good to me. The existing
CONFIG_ARCH_SIM that is set when you compile the system should be enough.
> 2.3. I can see that there is GPIO available in the SIM. How can I
> interact with that gpio from my host OS? Is there sort of additional
> application to perform such interaction with the simulator
> application?
>
>
> 3. Out of tree Application / Board / Drivers.
>
> 3.1. My current working setup is based on git. I would like to keep
> all firmware code in my project's repository and external to the NuttX
> + NuttX-Applications source tree. So that nuttx.git and nuttx-app.git
> is provided as git submodule on the main project repo. Is this
> possible?
Yes. See
CONFIG_ARCH_BOARD_CUSTOM
CONFIG_ARCH_BOARD_CUSTOM_NAME
CONFIG_ARCH_BOARD_CUSTOM_DIR
CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH
CONFIG_BOARD_CUSTOM_LEDS
CONFIG_BOARD_CUSTOM_BUTTONS
CONFIG_BOARD_CUSTOM_IRQBUTTONS
CONFIG_BOARD_CUSTOM_INTERRUPT
> 3.2. I know that Application can be kept out-of-tree if linked to
> nuttx-apps.git. Should I do the same with Boards and Drivers?
No, use the custom board configuration settings.
> 3.3. Is it possible to attach Application / Board / Driver code
> out-of-tree with no linking?
What do you mean no linking? Do you mean that it is not linked into the
code on the FLASH? Or do you meaning symbolic linking of files? If so,
use the custom board configuration.
> 3.4. Is it possible to provide full path and no non-relative path to
> nuttx-apps in ./tools/configure.sh?
Yes, I believe so.
