Newbie with general questions and wants to compile for STM32

[Gregory N]

Oops... I moderate all messages from new group members to avoid SPAM. But this time I accidentally hit the "delete" instead of "approve" button and deleted Christoph's message. My apologies, Cristoph; here is your message in its entirety:

From: Christoph Drube <ch.drube-DIx0nqDsXdjJrnlU/***@public.gmane.org>
Date: Mon Mar 11, 2013 10:37 am
Subject: Newbie with general questions and wants to compile for STM32

Hi folks,

First: I am completely new to RTOS on Microcontrollers (only experiences with RTLinux on CNC machines). But we here use Linux a long time and have some experiences with STM32 and Eclipse + CodeSourcery compilers.

On the long run (one year is ok) we want to develop small GUIs for some solutions for the galvanic industries with STM32Fxx and a 7" touch screen with SSD1963, USB connector, LAN etc. The hardware prototype (still basing on a STM32F4DISCOVERY) is ready and we can draw some graphic primitives like lines, circles by functions written on our own. etc. - so this works.

But I also know that using a real OS with most of the work for the interfaces already done should be a much better choice then doing this
all from scratch.

I like the integrated graphical interface/library and window manager of NuttX (one big point for us)

My first question: What do you think - is NuttX the right candidate for these our plans?

If so, my second question would be:

I followed the instructions and have copied all the config files to $(TOPDIR), tried to compile NuttX for stm32dicovery. PATH is ok, arm-none-eabi-gcc is found, and as I can see also the inlcude path (I invoke make from the nuttx directory). But he gave me this:

...
make[1]: Entering directory '/home/jogger/nuttx-code/nuttx/sched'
CC: os_start.c
os_start.c:42:20: fatal error: debug.h: No such file or directory
compilation terminated.
make[1]: *** [os_start.o] Fehler 1
make[1]: Verlasse Verzeichnis '/home/jogger/nuttx-code/nuttx/sched'
make: *** [sched/libsched.a] Fehler 2

That seems to be strange to me. Is $(TOPDIR)/include not included by
default?

I hope that this is not a stupid question but NuttX is so new for me and it is much to learn about the directory structure - I am a little bit confused :-}

A big "Thank you!" for every hint.

Best regards from Germany,
Christoph

[Gregory N]

Hi, Cristoph,

Post by Gregory N
First: I am completely new to RTOS on Microcontrollers (only experiences with RTLinux on CNC machines). But we here use Linux a long time and have some experiences with STM32 and Eclipse + CodeSourcery compilers.
On the long run (one year is ok) we want to develop small GUIs for some solutions for the galvanic industries with STM32Fxx and a 7" touch screen with SSD1963, USB connector, LAN etc. The hardware prototype (still basing on a STM32F4DISCOVERY) is ready and we can draw some graphic primitives like lines, circles by functions written on our own. etc. - so this works.
But I also know that using a real OS with most of the work for the interfaces already done should be a much better choice then doing this
all from scratch.
I like the integrated graphical interface/library and window manager of NuttX (one big point for us)
My first question: What do you think - is NuttX the right candidate for these our plans?

Of course I am biased, but NuttX and your objectives seem to be very much in common.

- NuttX provides a very Unix-like programming environment. The goal of NuttX is to be a tiny Linux work-alike for deeply embedded MCUs. You should feel comfortable in this environment.
- STM32 support is very strong in NuttX
- The SSD1963 LCD controller is not specifically supported. There are drivers for SSD LCD controllers so this should not be a significant development effort (SSD1289, SSD1305, SSD1306, SSD1329, SSD1783)
- The graphics interface, widget library, and window manager are maturing well and have been used in several products.

Post by Gregory N
...
make[1]: Entering directory '/home/jogger/nuttx-code/nuttx/sched'
CC: os_start.c
os_start.c:42:20: fatal error: debug.h: No such file or directory
compilation terminated.
make[1]: *** [os_start.o] Fehler 1
make[1]: Verlasse Verzeichnis '/home/jogger/nuttx-code/nuttx/sched'
make: *** [sched/libsched.a] Fehler 2
That seems to be strange to me. Is $(TOPDIR)/include not included by
default?
I hope that this is not a stupid question but NuttX is so new for me and it is much to learn about the directory structure - I am a little bit confused :-}

debug.h exists at include/debug.h, right? If so, then the problem must be with your include path or symbolic link setup. My bet is the latter. But to be sure, you should do this:

make V=1

The V=1 turns on verbose output and you will be able to see the GCC command line. Cut and paste this command so that you can run GCC by itself:

- cut GCC command
- cd sched/
- paste GCC command

You should be able to edit that GCC command to make it compile. Then you will know what is wrong.

What configuration did you use? What platform are you building under? You should do this:

1) Build the kconfig-frontend tools if you have not already done so. See:

http://sourceforge.net/p/nuttx/code/5730/tree/trunk/nuttx/README.txt
http://sourceforge.net/p/nuttx/code/5730/tree/trunk/misc/tools/README.txt

2) Start clean

make distclean : Remove everything and start over
cd tools
./configure.sh stm32f4discovery/nsh : Re-configure

3) Check the configuration:

make menuconfig

All of the STM32F4Discovery configurations are configured to build under Windows in the Cygwin environment using CodeSourcery for Windows. Is that what you are using?

(Except for the winbuild configuration which builds natively under Windows).

That is about all that I can think of with the little amount of information that I have.

Greg

[[e-mail]]

Hi Greg,

thank you very much for the quick support :-)

You are right - first I have to explain my stuff here a little bit:
We mostly use Linux (Ubuntu 12.10) here on 64-Bit-Intel-PCs - so all development is done under Linux. IDE is Eclipse and the ARM tool chain is CodeSourcery.

Post by Gregory N
- NuttX provides a very Unix-like programming environment. The goal of NuttX is to be a tiny Linux work-alike for deeply embedded MCUs. You should feel comfortable in this environment.
- STM32 support is very strong in NuttX
- The SSD1963 LCD controller is not specifically supported. There are drivers for SSD LCD controllers so this should not be a significant development effort (SSD1289, SSD1305, SSD1306, SSD1329, SSD1783)
- The graphics interface, widget library, and window manager are maturing well and have been used in several products.

That all sounds good to me. The driver for the SSD1963 should be no problem - I have read every page in the data sheet and have programmed it a lot in the last months :-)

Post by Gregory N
- cut GCC command
- cd sched/
- paste GCC command
You should be able to edit that GCC command to make it compile. Then you will know what is wrong.

It seemed that the -include contained only empty quotes ("").

But I have compiled the kconfig tool and configuration is now much easier.

Now make runs to the end and I finally got my first nuttx.hex :-)

I am too tired to test it now (its 22:30 here in Germany, work started at 6:30am) but cannot await tomorrow and the first shell.

I will give more feedback tomorrow.

A first "Thank you",
Christoph

[[e-mail]]

Hi again,

Phew, I have read tons of NuttX-docs now - and I got some nice results:

I was able to compile the simulator with X11 framebuffer output and it worked out of the box with the "Hello World!", lines and image example :-)

(BTW: May be I overlooked this in the documentation but I first got the linker error of a missing "nx_main" function. I had to learn that the entry point has to be set according to the example main function :-} One additional sentence in the docs should help beginners to run the examples directly.)

If I understand the simulator right, it can do all things except of controller interrupts and timer stuff. So it should be the choice for me to develop my GUI. I read about the touchscreen emulator with mouse. If I would be able (I haven't done this yet) to run it, this should give me a good testing platform. Or is there a better way?

Regarding the image example apps/examples/nximage:
It seems to use a very simple way of run length encoding for storing images in arrays. Because I will have many graphical symbols in my GUI i would prefer a strong and small compression algorithm. I have looked around for some GIF libraries and found things like giflib (http://giflib.sourceforge.net/gif_lib.html) which could read from an io stream.

So my questions are:

1.) Is there already existing code for NuttX which implements a small, simple GIF reader? Important for me would be, that the GIF is decoded line by line so I don't need to hold the complete GIF in my (small) STM32-RAM. Of course I don't need encoders or format error checking for this - so I hope it will be small.

2.) If not: I guess the simplest way will be to store all needed gif images in a file system (e.g. ROMFS) so that no further work on them would be needed - and then decode it with the giflib file stream functions. Or is this a stupid way?

3.) Ok. Now I have compiled NuttX, all the needed code, libs and NXGL etc. But how to proceed further now? How should I start to implement my entry point in the NuttX environment. As an app like in the examples with kconfig entries? Or in other words: how and where do you all add your own code? How can I separate my own development as much as possible from the NuttX code tree so I don't have to compile all stuff or run into trouble when updating NuttX? I hope my intention is clear :-)

Christoph (Germany, 20cm snow last night, -5°C ... brrrr)

[Gregory N]

Hi, Cristoph,

Post by electronicthingks-***@public.gmane.org
I was able to compile the simulator with X11 framebuffer output and it worked out of the box with the "Hello World!", lines and image example :-)
(BTW: May be I overlooked this in the documentation but I first got the linker error of a missing "nx_main" function. I had to learn that the entry point has to be set according to the example main function :-} One additional sentence in the docs should help beginners to run the examples directly.)

For all of the canned configurations, the CONFIG_USER_ENTRYPOINT should already be set correctly. Like:

nx/defconfig:CONFIG_USER_ENTRYPOINT="nx_main"

But, yes, if you modify a configuration, you have to change the name of the entry point. There used to be a common entry point name called 'user_start' then lots of conditional compilation to change the entry point names for different contexts.

People didn't like that so now the entry point names are unique and you have to change the configurations. This is documented (I think), but obviously not in a place that was helpful to you.

Post by electronicthingks-***@public.gmane.org
If I understand the simulator right, it can do all things except of controller interrupts and timer stuff. So it should be the choice for me to develop my GUI. I read about the touchscreen emulator with mouse. If I would be able (I haven't done this yet) to run it, this should give me a good testing platform. Or is there a better way?

The simulator does have some negative aspects. It is implemented as a single Linux thread and implements "multi-threading" using setjmp and longjmp. But that means that when you wait for Linux events (like keyboard input), the simulation freezes and multitasking stops. That gets me a lot.

Another is that there are no interrupts. Timing is completely faked in the IDLE loop. When processes run, time basically stops but then in the IDLE loop, times goes much faster and it catches up. I like this for testing because I can set CONFIG_SIM_WALLTIME=n and the simulation runs much faster than real time.

I use the simulator for all of my graphics development because it is such a convenient development environment and the Linux tools are usually much better than the tools for embedded systems. There are some things to be careful about with X11 calls (and any Linux calls in general): The simulation uses the fixed NuttX stacks. The Linux and library internals will not behave like an embedded system and may use huge amounts of stack space. This can sometimes cause some very strange behavior.

So I set the stack size of any thread that calls into X11 to be very large (like 16K) and that usually avoids problems.

There is also a simulated touchscreen also based on X11. If you move the mouse over the X11 window and click, it should be behave like a screen touch. However, the last time I tried that it did not work. I suspect that is busted and you may need to fix that to do serious interactive graphics work.

Post by electronicthingks-***@public.gmane.org
It seems to use a very simple way of run length encoding for storing images in arrays. Because I will have many graphical symbols in my GUI i would prefer a strong and small compression algorithm. I have looked around for some GIF libraries and found things like giflib (http://giflib.sourceforge.net/gif_lib.html) which could read from an io stream.
1.) Is there already existing code for NuttX which implements a small, simple GIF reader? Important for me would be, that the GIF is decoded line by line so I don't need to hold the complete GIF in my (small) STM32-RAM. Of course I don't need encoders or format error checking for this - so I hope it will be small.

No. That run length encoding is there because it was easy. Isn't GIF patented? Perhaps PNG would be a better choice.

Post by electronicthingks-***@public.gmane.org
2.) If not: I guess the simplest way will be to store all needed gif images in a file system (e.g. ROMFS) so that no further work on them would be needed - and then decode it with the giflib file stream functions. Or is this a stupid way?

Petteri wrote a conversion program that converts any format supported by Python into that simple NuttX RLE format. That tool is at NxWidgets/tools/bitmap_converter.py

Post by electronicthingks-***@public.gmane.org
3.) Ok. Now I have compiled NuttX, all the needed code, libs and NXGL etc. But how to proceed further now? How should I start to implement my entry point in the NuttX environment. As an app like in the examples with kconfig entries? Or in other words: how and where do you all add your own code? How can I separate my own development as much as possible from the NuttX code tree so I don't have to compile all stuff or run into trouble when updating NuttX? I hope my intention is clear :-)

I don't know how most people do this.

- I provide the apps/ directory as a model for the application space. Many people use that apps/ directory unmodified and add their directories in it.

You have apparently not yet ran the NxWM unit test yet. See NxWidgets/UnitTests/README.txt. This is probably the best graphics demo. There is a configuration configs/sim/nxwm for the simulator. By default it builds without the touchscreen and just does some canned tests.

Anyway, those UnitTests build by putting a symbol link into the apps/ directory.

- Another option is to create your own application directory using the apps/ directory as a model.

In both of those cases, the "master" Makefile would be the nuttx/Makefile. For many people, that seems backward to have the RTOS build Makefile to be the center of the universe.

- There is a make target called 'export'. If you 'make export' then all of the nuttx libraries and start files will get packaged up. Some people the 'make export' to just build NuttX from libraries.

There are probably lots of other things that you can do. I am probably not the best person to answer the question because I don't develop applications. What have other people in the list done to separate their application development from NuttX? Does anyone have any recommendations to improve the integration of NuttX into an application development environment?

Post by electronicthingks-***@public.gmane.org
Christoph (Germany, 20cm snow last night, -5°C ... brrrr)

Greg (Costa Rica, balmy, 83°F/28°C per http://costarica.com/weather/)

[Gregory N]

Post by Gregory N
You have apparently not yet ran the NxWM unit test yet. See NxWidgets/UnitTests/README.txt. This is probably the best graphics demo. There is a configuration configs/sim/nxwm for the simulator. By default it builds without the touchscreen and just does some canned tests.
Anyway, those UnitTests build by putting a symbol link into the apps/ directory.

Some older screen shots here: http://tech.groups.yahoo.com/group/nuttx/files/NxWM%20Screenshots/

Greg

[petteriaimonen]

Hi,

Just my two cents on this. For the past 6 months, I have been doing a commercial project based on NuttX, and it is nearing completion.

Post by Gregory N
I like the integrated graphical interface/library and window manager of NuttX (one big point for us)

I have to say that the NXWidgets and NxWM are not yet as complete as one would expect. There are still plenty of missing features and bugs hiding there. They are not difficult to add as you need them, but plan ahead for the time needed.

However, it does seem to be the best open source option for this kind of thing. Some of the commercial microcontroller GUI packages do seem great, but I haven't tried them. Also the development around Gwen, GLIDE and similar GUI frameworks seems promising, but they are also still somewhat incomplete and also require a bit more memory than NuttX.

Post by Gregory N
My first question: What do you think - is NuttX the right candidate for these our plans?

I would go for embedded Linux if you can afford the slightly increased price and power usage. Software development will be greatly simplified.

For me, the big reasons to go for NuttX were that I needed realtime operation and power usage below the 500 mA limit of USB.

--
Petteri

[Gregory N]

Hi,

Post by petteriaimonen
Just my two cents on this. For the past 6 months, I have been doing a commercial project based on NuttX, and it is nearing completion.

Post by Gregory N
I like the integrated graphical interface/library and window manager of NuttX (one big point for us)

I have to say that the NXWidgets and NxWM are not yet as complete as one would expect. There are still plenty of missing features and bugs hiding there. They are not difficult to add as you need them, but plan ahead for the time needed.
However, it does seem to be the best open source option for this kind of thing. Some of the commercial microcontroller GUI packages do seem great, but I haven't tried them. Also the development around Gwen, GLIDE and similar GUI frameworks seems promising, but they are also still somewhat incomplete and also require a bit more memory than NuttX.

What Petteri says here is correct and applies to most smaller open-source projects. The huge, mainstream projects like Linux have an extensive test and support infrastructure. There are many eyes and hands on the code, so it is solid and has a rich feature set.

The benefits of open-source software are pretty much obvious, but as a business decision there are other things to take into account:

- Does the open source software have all of the features that you need? If not, what is plan to implement them.

- Testing of open source software is spotty -- varying from pretty good to terrible. There is no dedicated test and verification team to assure the correctness of the code at any particular time.

So you really have two options: (1) Become a open-source co-developer. This is what most people do. The level of information/support available on the forum is good. Most people contribute bug reports, bug fixes, and enhancements as patches.

Or (2) if you don't want to get that deeply involved in the open source development, then the other option is to contract support. I do that and there are several other people listed here: http://www.nx-engineering.com/partners/

Post by petteriaimonen

Post by Gregory N
My first question: What do you think - is NuttX the right candidate for these our plans?

I would go for embedded Linux if you can afford the slightly increased price and power usage. Software development will be greatly simplified.

I would be an option for you if you have a lot of external memory and boot loader in FLASH. The only Linux port that I have heard of the STM32 Linux port is EmCraft: http://www.emcraft.com/ . The have a u-boot port was well. They charge a very small fee for the port ($500 as I recall).

Post by petteriaimonen
For me, the big reasons to go for NuttX were that I needed realtime operation and power usage below the 500 mA limit of USB. See http://micrium.com/

I have heard positive things about uC/OSII so might be commercial option to consider as well. The cost would probably be in the 5-digit range, depending upon how many of the add-on packages you purchase. That is really a very good price in that market.

Greg

[[e-mail]]

Hi again, it's me, the Spammer ;-)

thank you Petteri and Greg for your estimation.

I know - there is a huge support for Linux out there, but I think that Linux is too big for my jobs.

Linux is much bigger than NuttX - so it is much harder to understand all the parts needed for a rudimentary OS.
I think it is better to understand my OS completely (and I hope I will do in a year) and write the missing code by myself than to search for every answer in the Web because I don't overlook my OS.

I have written some drivers for Linux in its early versions (2.0, around 1999/2000) and it was much work. For a microcontroller system I will need even more and direct hardware access and quick driver development for special features. As I can see from the driver code in NuttX this is quite easy - at least much more easy than for Linux (and RTLinux).

And of course RT is a big point - an advantage I shouldn't throw away easily. Even if I don't need it for my first project it is a must for many applications I am planning for my companys future.

Another thing is scalability:
If I get it right NuttX spreads over a large range of controllers, from very small (and cheap!) ones to the big. We are currently (slowly) switching from AVR (which we used for over 10 years now) to ARM/Cortex. When using Linux I would have to use a big controller every time - when I need a small solution I will have to switch to - to what?
For the future I prefer a modular system for all my jobs.

And, of course, another big point is the License of NuttX. I like the free BSD license of Tcl/Tk (I really love this scripting language :-)

Post by petteriaimonen
I have to say that the NXWidgets and NxWM are not yet as complete as one would expect. There are still plenty of missing features and bugs hiding there. They are not difficult to add as you need them, but plan ahead for the time needed.

Yes, I am aware of this - but this is no problem :-)
It shouldn't be too much work to write the missing SSD1963 driver and some graphics functions - I will not need a multiple windows solution for now.

Christoph