[RFC] Ideas for ChibiOS/RT 3.0

[Prof. Dr. YoMan]

I would love to see a optional fully integrated newlib with correct fast locking for everything and a replaced malloc.
More complete stubs for it (as above in "POXIS-compatibility), but no need for 100% POSIX.

Also optional fully integrated libstdc++ (locking, etc) with STL would be great.

We can get 256kB RAM with uCs now and placeing a standard SDRAM is no problem. RAM is "cheap".

[Giovanni]

Then you can just make serial ports accessible through the C library by implementing the whole syscalls.c, much easier than creating a whole Posix wrapper.

Giovanni

[Prof. Dr. YoMan]

You are right with the syscalls, but malloc, locking etc. for newlib and libstdc++ is still missing.

[Tectu]

malloc is provided by ChibiOS... chHeapAlloc() and friends.


~ Tectu

[Prof. Dr. YoMan]

Yes it is. But many newlib functions use the newlib internal malloc and using the malloclock/unlock feature is not the optimal way. Same for the other lockings in newlib. There are some threads/posts about it.

[Freddie Chopin]

Then you can just make serial ports accessible through the C library by implementing the whole syscalls.c, much easier than creating a whole Posix wrapper.

That leaves the actual paths to the devices...

4\/3!!

[Tectu]

I don't think that a POSIX like implementation like open/close/read/write/ioctl would gain so much in an embedded device. I fully agree with Giovanni that the overhead would be too big.
Also, I don't think that something like that is needed at all, or do you guys have any driver interface problems at all?


~ Tectu

[Freddie Chopin]

It's not a matter of "problem", as you can as well use assembly instead of C/C++ and RTOSes, but a matter of code re-use. There are MILIONS line of code available to PC platforms and that can be reused, but you need a proper and functioning abstraction to deal with that. And that "proper abstraction" is POSIX, not any API invented specifically for one single project.

4\/3!!

[lmamakos]

Then you can just make serial ports accessible through the C library by implementing the whole syscalls.c, much easier than creating a whole Posix wrapper.

That leaves the actual paths to the devices...

4\/3!!

I'm not really at all interested in more complete POSIX emulation in ChibiOS; if I need embedded Linux, I know a few places I can go to find it. The differentiation that software like ChibiOS brings to the table is a light-weight, more intimate connection with the underlying hardware. To be able to extract more performance from the hardware platform because of the lower overhead due to the OS. Performance could be measured a bunch of ways: smaller memory footprint; faster response time; more application CPU cycles available; more compute per watt/second of power, etc.

I'd like to see:

Some ChibiOS provided/mediated framework for low-power modes. I've an application based on an STM32L152-based part, and there's much opportunity to run in low power modes, but the application, OS and HAL need to cooperate to achieve this goal. There are going to be some platform specific properties to deal with, so my application may not be arbitrarily portable over CPU families or chip venders, but..

For more performant systems with more memory, a more mature TCP/IP network stack. I know you can stuff a whole Berkeley TCP/IP stack into well less than a megabyte, including the rest of the OS and applications (see 2.11BSD for PDP-11 systems), so how about on the larger ARM parts? Real IPv6, multicast, etc. The socket abstraction in that network stack has very well defined interfaces to, e.g., file descriptors on UNIX and you could "easily" substitute I/O channels or whatever makes sense for ChibiOS.

As others have mentioned, the single most attractive thing to me when I was looking around at NuttX, ChibiOS/RT, FreeRTOS, etc. is the first-class support in the HAL layer with all of the STM32-based parts and their peripherals. I realize that you can structure the distribution many different ways, but in a large sense, it was the HAL support that pulled me into the ChibiOS world. It would be a shame if that was lost, either in reality or even perception.

[jcbarlow]

I'm not really at all interested in more complete POSIX emulation in ChibiOS; if I need embedded Linux, I know a few places I can go to find it. The differentiation that software like ChibiOS brings to the table is a light-weight, more intimate connection with the underlying hardware.

I think this is a key point. Linux already exists. It will run today on quite small, low cost, low power platforms. That situation should steadily improve with time. There is no need to re-invent that particular wheel.

What Linux doesn't do well is "hard" RT. Yes, I am aware of the "RT" kernel patch set. It is still not a full solution and it still has issues with worst case interrupt latency. ChibiOS/RT fills a niche that is not well served otherwise, that is low overhead, hard RT on fairly low end hardware. Please don't pollute that with full Posix overhead.

OTOH, I think 8 bit CPUs are pretty much history except for extremely low end, ultra cost sensitive products. (Those are boring and there's little money to be made on them) I can't imagine why anyone would design a new product with one of the larger AVRs when one can get a modern ARM chip for the same price. Dropping support for AVRs etc in ChibiOS/RT and focusing on ARM CM, MIPS32, etc and standardizing on gcc would I think ease development of ChibiOS/RT itself and make life simpler for those of us wanting to do hard RT on a modern C++ platform.