On Thu, Apr 27, 2023 at 6:03 PM Tomek CEDRO <to...@cedro.info> wrote:
> Hello world :-) > > I have some in-development question that could probably go to DOC/FAQ > as I found some questions/answers there already :-) Any hints > appreciated. Also the logic / approach errors and valid solution > propositions welcome :-) :-) > > 1. Daemon / Service: > > 1.1. I would like to have application running as daemon in the > background all the time. Is this possible? Yes, though I don't think there's a way to designate a program as a "daemon" necessarily, but a program can run all the time. In Kconfig there's a setting (I'm on my phone now so don't remember the name off the top of my head) that determines what initial task to run. In most in-tree board configs this is set to nsh_main. You could set this to your own init-style program that launches your daemon, or multiple daemons, and perhaps nsh as well, if you want it in the end product. Continued below: 1.2. On application error / crash I would like the application to > restart so it is always available. Is this possible? > One idea is to make your init-style program monitor that your daemon is running and if not, either restart it or reboot the board, whichever is applicable to your product. 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? > > 1.4. Is it possible to call the nsh as sub-process from within my > application so the application keeps feeding the watchdog? It is possible to start nsh from another program. It doesn't have to be the default application launched at boot. In fact, everything in the apps repo should be seen as examples and demonstration programs that you can use as-is, or use as a guide to building your own. So you need not actually have nsh at all, if it isn't appropriate in your product. 1.5. If the timing is important should I rather keep my application in > the foreground and abandon the idea of a daemon? If the daemon responds to some outside stimulus, you can give the daemon a high priority and have it wait on a semaphore for the event to occur. Perhaps interrupt logic would post the semaphore. (Be careful with priority inheritance and the recently changed semantics.) Hopefully others will be able to help with these: 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? > > 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? > > 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? > > 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? > > 3.3. Is it possible to attach Application / Board / Driver code > out-of-tree with no linking? > > 3.4. Is it possible to provide full path and no non-relative path to > nuttx-apps in ./tools/configure.sh? > > > Thanks :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > Cheers Nathan
