Sonsivri

Hi!
I have written a complete firmware for power control and GSM data transfer (via sms) for STM32F373.
The next step will be bidirectional communication over TCP/IP (stack is included in the modem, so no need for that). But I also need to implement code that is NOT so bullet proof very soon.
My choice is to get a RTOS working. This must be done with the actual code as base.
The RTOS should therefore:
- be fast and some special tasks should be able to run with high priority.
- use a small amount of RAM because I need most of the RAM as sample memory
- able me to move my code quickly to the RTOS, preferably step-by-step.
- somehow debuggable with standard tools
There are a lot of RTOS for Cortex, so wich one to choose?
I have read about Keil RTX, wich would be convenient because I use uVision. There is ChibiOS which is free and seems small..
I never have used any RTOS, so I have no idea if the porting of my code is a big task or not...
Give me your ideas.

Hi,
You can use FreeRTOS, it is free and really a very stable and power OS.
I have used this OS in several comercial devices and until now we have reach
good results.
Other OS I have used is uCOS II and newer uCOS OS -III  from Jean Labrosse.
A lot of documentation and demos on the www.
Noe I am working with  SEGGER embOS. I do not have license, so only three
task can be actives for long time. If more task are defined and started,  in time
are deactivated.

You can get these OS in the manufactures www page.
If you need some more help , I can send  the actual projects, but have in mind,
the OS are dependable of the processor used , not all, only the "ports" os the OS.

I am currently working with renesas RX series processors.
Regards.

The Keil RTX works well - So long as you don't want to include any of the other Keil middleware packages (such as USB or TCP support). I can say from experience that these can be quite troublesome and Keil have a habit of carrying out updates that break compatibility with previous releases; which normally means rework for the developer.

But that said, it does have a lot going for it. Not least is that it effectively comes from ARM and it is open source and royalty free.

I have known die-hard developers who have used the Keil RTX for years, defected to FreeRTOS and become big fans.

It would definitely be worth closely at these two.

Question: Why?

[Flame mode ON]

RTOS is for lazy and / or non capable embedded programmer...  :o.

[Flame mode OFF]

Cheers...

-ichan

yes. That's me.
Additional I have to implement code portions soon without having the time to make them bulletproof in every case.
And I got some calculation code that takes more than a minute (complex dft stuff). I want to be able to control parts of the device meanwhile.
It just has to be done.

Has anyone yet migrated a finished firmware to a rtos? I especially search for an easy solution in this way.

aplank: do you know about the memory footprint (especially RAM) of RTX compared to other RTOS?

Yes. I had a large project written for an x86 cpu. Originally no RTOS primarily in assembler, but also a lot of C. Done when I was younger and not so lazy  8)

Then it was ported to an ARM9 core. Time to market was vital, but space was not an issue. Lots of middleware was needed and RTX was chosen. Fortunately (or by design?), the original code was structured in a way that meant the port to an RTOS was relatively straightforward. The ease to do this porting will (at least in part) depend upon the structure of the original code.


Sorry, but for my project the footprint was not an issue.  Keil's RTX footprint details can be viewed at:

http://www.keil.com/rl-arm/rtx_size.asp

Please explain! How can I prepare my code to make the translation as painless as possible?

You might also look at Qkernel.  I've not used it but the I know the guys who wrote it and they are smart as hell :)

I'm with Ichan though.  I hate using an RTOS until absolutely necessary.  dotm's project seems reasonable though. 

That said, if any of the code isn't bulletproof that's a pretty bad starting point.

This one is not for ARM Cortex architecture.
http://www.microchip.com/forums/m769747.aspx

There is no one-off answer to that one.  My goal for anything but the smallest projects is to have the code as modular as possible. Typically, having a main supervisory loop to dispatch work.  Have interrupts that do the minimum necessary and set flags that are picked up in the supervisory loop.

If this is done, then those main tasks in the supervisory loop can each be allocated a task in the RTOS and the interrupts trigger those tasks.  Doing this can increase the modularity of the code quite nicely and (to me) that shows a true advantage of using an RTOS on a larger system - It can make it more manageable and lets an older brain like mine keep track of what's happening.

 Why... ???

While I agree that for many cases, going without OS is efficient, both in terms of code/ram as well as in terms of execution speed. But certainly there are cases where RTOS is of tremendous help in both simplifying the complex coding and long-term maintenance/feature adding to code without breaking code in some other place. OS provides a lot of data structures, semaphores, messages, queues, safe interrupt nesting, safe data sharing between multiple threads/tasks, soft-timers etc. No doubt, you can all implement that by yourself, but having well-tested, well-proven, project independent code base is vital for many projects.

Using RTOS, introduces it's own problems, ROM, RAM for each task, stack overflows, slightly reduced code execution speed due to task switching, due diligence to adhere to RTOS conventions, priority inversions etc, but advantages far outweigh them.

In opinion, if you can get away without RTOS, its fine. But don't introduce undue complexities just to make things work and avoid RTOS. RTOS might be more elegant solution.

FreeRTOS and uC/OS both are fine. I prefer FreeRTOS, due to its licensing.

1) To start with, divide your code into functional blocks. For example, UI handling, a complex time consuming math, etc. See if you can insulate these blocks from other code as far as possible. Keep the access/interface to these blocks through predefined APIs only, never directly or through globals. This might make code a bit slower, it will help in the long run.
2) Work on your code to get the priorities of these blocks, their RAM/ROM/STACK usage.
3) Look at the calls your code is making to standard libs. Usually these libs are not re-entrant, i.e. they can't be called from multiple threads simultaneously. With RTOS, this may occur as OS decides the order of execution.
4) Insulate your hardware-dependent low-level drivers. Again multiple tasks might try to access them simultaneously.

These are just few things that came to mind, there are many others. Best to read few books on these such Jean.j.labrosse's MicroC OS II: The Real Time Kernel, David Simon's  Embedded Software Primer, FreeRTOS's documentation.

Hope this helps.
sam_des

So has anyone ever used an RTOS with uVision or uVision as Eclipse plugin, able to debug kernel-aware like RTX can do?
http://www.keil.com/rl-arm/rtx_debug.asp
ChibiOs has a Eclipse plugin, but I never got the uVision plugin for eclipse working...

Like driving a car to buy a pack of cigarette at seven-eleven store within one block distance from your house... Wasting many things and not good for the health, lazy it is.  ;D

-ichan

this is a german proverb, i try to translate freely:
"even a chain of associations is just as strong as it's weakest link"

sorry about that.  I'm not used to RTOSs having such narrow architecture support.

But walking 50 miles every day for 6 months to tend your tobacco crop when all you want is a smoke probably isn't the best idea either :P

Use the right tool for the job based on the requirements

Ok so I looked at some of the RTOS, especially ChibiOS and RTX came into focus.
I went for RTX because:
- perfect integration in µVision 5 using the runtime environment and the kernel-aware debugger
- CMSIS version available: CMSIS-RTOS RTX, using CMSIS as much as possible is good thing
- slightly smaller RAM footprint than ChibiOS
- possibility to kill task from another task (I know that this should not be necessary, but as Ichan said: non-capable programmer. That's me.)
- and at last: ChibiOS has its own device drivers, port layers and initialisation and configuration routines. All of them completely different from my code (based partially on CMSIS and the STM32 std library), I would have to rewrite it completely to adapt to ChibiOS. The ChibiOS board files (port and function configuration) are somewhat messy, I spent hours to make mine pretty and readable.

Yep, cigarettes is the weak link of my life chain, but i can't help myself about it, i'd better go to sleep rather than coding if i run out of cigarettes - well maybe some other activity related with bed  :P.

I do respect RTOS, it is a great concept! Seems the problem is on me, my experience is with Salvo RTOS (long time ago) and FreeRTOS (some years back) - i found it was wasting my time and the result is not better than my code without it.

I just read about RTX, here is an interesting link: RTOS Advantage (http://www.keil.com/rl-arm/rtx_rtosadv.asp)

The writing above compare RTOS with a plain vanilla forever loop - it doesn't talk about state machine or the use of system tick and function pointers.

-ichan

CooCox CoOS is an embedded real-time multi-task OS specially for ARM Cortex M series

http://www.coocox.org/CoOS.htm

:)

I'll decided to abandon all RTOS which are not compliant to the CMSIS abstraction layer.
I'll make a new topic for that.

I'm also trying to port STM32 old application to free RTOS, but still cannot reliably manage the low power mode using the recommended  portSUPPRESS_TICKS_AND_SLEEP(). My device goes well to (eternal) sleep .... :(