ChibiOS Free Embedded RTOS

I've been using ChibiOS for a number of projetcs, using various chips and boards from STM and LPC, mostly. So far, getting thigs going for STM has been very easy, and for LPC it was fairly easy as well to adapt existing demos and makefiles. For as-yet unsupported LPC chips, I managed to make it work by hooking stuff into the ChibiOS makefile setup, but mostly that has led to a non-standard setup, i.e. not adding stuff into the ChibiOS tree, but hacking together my own headers, makefiles-which-then-include-the-chibios-makefile, and some ld files thrown together as needed.

Most of this was for 2.6, but for new projects I've started using 3.0, and really like the option of trying out Nil for low-end builds at some point.

For LPC, the 3.0 branch has not yet received much public attention, as far as I can tell. The CMSIS files are not in there, nor any demos for the ARMCMx series. Also, CMSIS 4 is out now, but ChibiOS still uses 3.2 (I don't know if there are important changes).

- is ChibiOS becoming an STM-mostly os? is it due to the lack of interest and access to all those other boards?
- are LPC contributions welcome, even if I don't necessarily volunteer as long-term maintainer for them?
- are there code bases for LPC that people are working on, which I could look at for guidance and as starting point?

In short: I very much like the essence of ChibiOS, in particular 3.0, and would like to spend more time extending and contributing to it in the ways it has evolved in 3.0, but it's a fairly big job, and I'm a little concerned by the current rate of change on the non-STM side of things, in particular the LPC8xx and LPC11xx variants.

-jcw

Hi,

ChibiOS is not meant to be STM-only, I am personally committed in keeping it as platform-neutral as possible.

Said that, the problem is bandwidth, the only platforms ported to 3.0 are those with an active maintainer, I cannot realistically handle more than one family in addition to the two kernels.

Giovanni

Hello Giovanni,

While I understand and respect your position, it would actually be a lot easier to handle different platforms if you were to support at least one of each type. The ST32F µC's are probably a lot easier to port across different variations, than starting on a new one.

Having said that, I did start out on the LPC812, just to see what it takes. I'm taking hints from the LPC214x and the KL2x already in there, but I'm hitting a wall:



Could you or anyone working on LPC's give me a hint on how to chase down the cause of this error message?

-jcw

Porting drivers is easy. It is important that you use makefiles and configuration files from 3.0 (from a demo targeting the SAME core), probably your problem is there, also look for the 3.0 port guide in the documentation section.

http://www.chibios.org/dokuwiki/doku.ph ... rom_2_to_3

Porting a driver means mainly removing any reference to "ch" functions and replace them with the equivalent function in OSAL.

Giovanni

Ok, thanks for that reference - hadn't seen it. Making good progress now.

Another Q: what is the new name for IOREG32?

-jcw

Never mind. Inserted volatile uint32_t for now.

-jcw

Ok, it compiles. The added files/dirs so far are:


Next step will be to debug this stuff. Some clock or nvic issue, I believe. Getting there!

-jcw

Ah right, now the function that enables an interrupt vector takes the priority level as parameter not the priority mask. See any STM32 driver for example. You have to remove the macro that converts from mask to priority from the call.

Giovanni