[Newbie]NuttX on STM32 MCU

[lispybear-/[e-mail] [nuttx]]

Hi all,
this is my first post here.
I am about starting a project using some hardware/software platform provided by one partner company.
On the tiny STM32 hardware they have choosen to build a toolset built upon NuttX.
Before starting & trying by myself I'd like to have some information:
- what is the approximate size of NuttX on Flash ROM & the memory footprint in RAM ?
- Is the libc compliance level good (excellent as stated in the wiki?), I would need the standard functions to create file watchers & jobs schedulers?
- Do you have any experience from LISP interpreters on such hardware?


Sorry if this sounds dummy questions but I must create a new architecture quickly, dropping Java & Linux stack for a more realistic stack on the selected hardware.


Kind regards
Jerome

[spudarnia-/[e-mail] [nuttx]]

Answering the size question is not really possible with any accuracy. That is because NuttX is highly scalable so there is not a single size number that characterizes the RTOS.


If you disable a lot of features you can easily run in as little as 32KiB of FLASH. One person on this list had a version of NuttX *with* a full console application running in 12KiB of FLASH. But that size has probably increased since then. All software tends to grow over time and that growth is going to effect the smallest configurations the most.


However, I recommend more FLASH than that for any real application. Most people find that 128KiB is enough for NuttX and some relatively simple applications. In that case, NuttX proper is probably going to take about 30-40KiB of the FLASH; applications vary in size of course.


At the other end of the scale, I was recently using a configuration on a Cortex-A with all of the bells and whistles enabled and lots of built in applications and it was approaching 450KiB -- which was nothing in the 256MiB DRAM on that board. Most of that was application.


Static RAM usage by Nuttx is miniscule. Dynamically allocated RAM usage will vary primarily with the number of threads that you have running. The primary memory usage of a thread will be its stack. The total combined overhead for a thread is probably around 2KiB of RAM depending on the size of the stack that you need in your application and, again, on the number of features that you enable. The RTOS part of that overhead is probably a few hundred bytes.


I have run NuttX in systems with only 4KiB of SRAM but that is, again, not recommended. You will probably need more than 16KiB of SRAM. 32-64KiB is typical; 128KiB leaves plenty of space to move around in a typical embedded applications (yours might require more or less).


Greg

[spudarnia-/[e-mail] [nuttx]]

Post by lispybear-/***@public.gmane.org [nuttx]
- Is the libc compliance level good (excellent as stated in the wiki?), I would need the standard functions to create file watchers & jobs schedulers?

This question is also difficult to answer. The NuttX libc is tiny C library but strives to complete and standard compliant. But there are not "file watchers" or "job schedulers" in the C library -- I am not even sure what that means.


What interfaces are specifically asking about? It if is not part of ANSI or POSIX it probably will not be there (although there are a smattering of GNU and Linux interfaces that are supported).


Greg

[lispybear-/[e-mail] [nuttx]]

Hi Gregory, thanks for the so quick answer....
By watchers I mean capability to watch for file changes & react accordingly.
Using the C wording, I expect to be able to use sys/select or pselect ?
Job scheduling as far as I know relies on timers & signals.
So I would expect a libc providing such functions to build required tools for my application.


Thanks once again
Regards
Jerome

[spudarnia-/[e-mail] [nuttx]]

Hi, Jerome,

Post by lispybear-/***@public.gmane.org [nuttx]
By watchers I mean capability to watch for file changes & react accordingly.
Using the C wording, I expect to be able to use sys/select or pselect ?

NuttX does support select() (or better, poll() since select() is built on poll() and, hence, has an extra memory/performance penalty).


However, poll()/selected() does not work with files. Or you mean character drivers in the file system? Yes, that works fine provided that the driver has the proper support.

Post by lispybear-/***@public.gmane.org [nuttx]
Job scheduling as far as I know relies on timers & signals.
So I would expect a libc providing such functions to build required tools for my application.

I imagine that is all there. Much is not in libc, however, but in the OS itself. In a flat build, you don't interface with the OS via libc as you do in Linux, you interface directly with the OS.


You probably need to look through the user and porting guides:http://www.nuttx.org/doku.php?id=documentation


There is a missing from those documents, but they will give you a pretty good idea of what you are dealing with.


Greg

[Kosma Moczek [e-mail] [nuttx]]

Hi!

We recently switched to NuttX as our primary RTOS for STM32, so I'm
more than willing to share some experiences we had.

Post by lispybear-/***@public.gmane.org [nuttx]
- what is the approximate size of NuttX on Flash ROM & the memory footprint in RAM ?

We're successfully running NuttX on STM32F103RB with 20KiB of RAM.
That's enough for a somewhat complicated application (GPS + GSM
stacks, 6 threads running in the system), but we had to specifically
design the app in a way that would keep the stack hogs in a single
2KiB-stack thread. We have just 500 bytes of free memory right now; we
could probably carve out 1-2KiB more if we needed but that's
approximately where the limit is. Remember that thread memory usage is
not just stack; the TCBs are quite big too, especially if you need
lots of UNIX features (we did).

Note, also, that this is without any flash filesystem. Last time I
tried SmartFS I couldn't get it running on the 20KiB part without
disabling at least one background task. That's precisely we switched
to a 64KiB part in the latest hardware revision: to stop worrying
about constant shortage of RAM.

Flash-wise, you could fit in 64KiB if you disabled some features but
for serious development 128KiB is the minimal size I find comfortable.
A small-ish hardware test image is 56KiB for us; the main app image is
approximately 90KiB. Again, this is with lots of features enabled,
floating point support, date/time utils, etc. In the real life there's
rarely any point in optimizing the image size as RAM is pretty much
always your primary concern.

Post by lispybear-/***@public.gmane.org [nuttx]
- Is the libc compliance level good (excellent as stated in the wiki?)

It's excellent compared to every other RTOS I tried, even though
things do break sometimes. Some functions are missing, a few are
behaving wacky, but generally I'm extremely impressed with the vast
amounts of UNIX goodies that NuttX has. Even if something's missing or
broken, often it's just a matter of enabling it in .config; in other
situations you can often fix it yourself and submit the patch here.
Gregory is extremely responsive when it comes to integrating bugfixes.

Post by lispybear-/***@public.gmane.org [nuttx]
By watchers I mean capability to watch for file changes & react accordingly.
Using the C wording, I expect to be able to use sys/select or pselect ?
Job scheduling as far as I know relies on timers & signals.

NuttX is like your typical UNIX system, but with some justified
exceptions: for example, you can't fork() or SIGKILL on MMU-less
systems. Other than that, you can expect your typical function to Just
Be There. Pthreads, select()/poll() and timers - it's just a matter of
enabling them in "make menuconfig".

To put it in some perspective: My primary documentation when
developing NuttX apps are BSD manpages. They're enough 95% of the
time. NuttX docs are only ever really needed when doing something
OS-specific or writing a new BSP.
--
Kosma Moczek
http://www.kosma.pl/


------------------------------------
Posted by: Kosma Moczek <kosma-OqCRPfiDy+***@public.gmane.org>
------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/nuttx/join
(Yahoo! ID required)

<*> To change settings via email:
nuttx-digest-***@public.gmane.org
nuttx-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
nuttx-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[lispybear-/[e-mail] [nuttx]]

Thanks Kosma for this very detailed answer. I know now that NuttX is a good layer for the hardware and it may definitely the right choice for my
application. It should have less requirements than yours..
Kind regards
Jerome

[Kosma Moczek [e-mail] [nuttx]]

Post by lispybear-/***@public.gmane.org [nuttx]
I am about starting a project using some hardware/software platform
provided by one partner company.

PS. If you want to keep your life simple and easy, my very big piece of
advice is: buy a well-supported devkit/evboard (see configs/ directory for
a list) and work from there, changing only one thing at a time and testing
if it works. The first few times I tried NuttX, I changed literally *half
of the config* on the first build because I saw so many exciting things
there - unsurprisingly, my builds would not even start. Unlike Linux, you
*can* build an image that won't even boot.

Don't go that way. Get a supported devboard (maybe you already have one?),
make sure everything works fine, trim the config down to a minimum and use
that as a starting point for your custom board config. Use version control
and commit every single little change you make so that you can git bisect
when things mysteriously break. Will save you lots of headaches.