Electronic – What development boards have good RTOS support

linuxrtos

I'm looking for a relatively low-cost (<$50 would be ideal) development board with real support for an RTOS. It doesn't matter if the RTOS is manufacturer-supported or a separate project, but I'd like something that is solidly supported (i.e. actually works for multiple people). I've spent some time fixing broken RTOS ports and I'd rather not have to mess with that.

My other requirement is that the development board has to have support for a Linux development environment.

We're looking for something that is specs-wise roughly comparable to the Atmega 2560. (And, in fact, an Arduino Mega 2560 running BeRTOS is certainly one option.)

To give a little more background to the question, last year we built a quadcopter from scratch (i.e. all the hardware, all the code, etc. Nothing borrowed from Arducopter or anything like that). A small budget ($400) had us stuck with an Arduino Pro (an Atmega 328-based board). By the time we had the thing flying, we were bumping up against the memory limit (due to code size) and doing everything we could to optimize so that our PID loops would run fast enough.

The new goal is to redo the control system based on a less limiting micro and an RTOS.

So, to summarize, the question is, what development boards fit these criteria:

Approx <$50
RTOS support
Compatible with a Linux development environment

Thanks!

Best Answer

I've had lots of success with FreeRTOS, combine this with an ARM Cortex dev board such as one from Olimex (available from Farnell) - see This Page for a list of supported devices. A Cortex M3 will run at 75MHz and deliver over 80MIPS. ARM code is dead effecient and some ARM Cortex devices include fixed point math functions.

If you want even more grunt, try a Beagleboard or RasberryPI.

As well as FreeRTOS, the latter will run Linux with Linux compiled with config_preempt_rt config option.

Related Solutions

Electronic – the reason the PIC16 multitasking RTOS kernel doesn’t work

What you are trying to do is tricky, but very educational (if you are prepared to spend a lot of effort).

First, you must realise that this kind of PC-only (as opposed to PC+SP) task switching (which is the only thing you can do on a plain 12 or 14-bit PIC core) will only work when all the yield() statements in a task are in the same funtion: they can't be in a called function, and the compiler must not have messed with the function structure (as optimization might do).

Next:

currentTask->pch = PCLATH;\
currentTask->pcl = PCL + 8;\
asm("goto _taskswitcher");

You seem to assume that PCLATH is the upper bits of the program counter, as PCL is the lower bits. This is NOT the case. When you write to PCL the PCLATH bits are written to the PC, but the upper PC bits are never (implicitly) written to PCLATH. Re-read the relevant section of the datasheet.
Even if PCLATH was the upper bits of the PC, this would get you into trouble when the instruction after the goto is on not on the same 256-instruction 'page' as the first instruction.
the plain goto will not work when _taskswitcher is not in the current PCLATH page, you will need an LGOTO or equivalent.

A solution to your PCLATH problem is to declare a label after the goto, and write the lower and upper bits of that label to your pch and pcl locations. But I am not sure you can declare a 'local' label in inline assembly. You sure can in plain MPASM (Olin will smile).

Lastly, to this kind of context switching you must save and restore ALL context that the compiler might depend on, which might include

indirection register(s)
status flags
scratch memory locations
local variables that might overlap in memory because the compiler does not realise that your tasks must be independent
other things I can't imagine right now but the compiler author might use in the next version of the compiler (they tend to be very imaginative)

The PIC architecture is more problematic in this respect because a lot of resources are loacted all over the memory map, where more traditional architectures have them in registers or on the stack. As a consequence, PIC compilers often do not generate reentrant code, which is what you definitely need to do the things you want (again, Olin will probaly smile and assemble along.)

If you are into this for the joy of writng an task switcher I suggest that you swicth to a CPU that has a more traditional organization, like an ARM or Cortex. If you are stuck with your feet in a concrete plate of PICs, study existing PIC switchers (for instance salvo/pumkin?).

Electronic – Using RTOS support in OpenOCD

Indeed the documentation for this amazing feature is rather poor, however there is a guide for ChibiOS. Basically this boils down to:

pass -rtos auto to {TARGET_NAME}.cpu configure in the Tcl configuration script
use thread commands in gdb, where info threads is the probably the one you will use most

Related Topic