[RFC] Ideas for ChibiOS/RT 3.0

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
User avatar
Prof. Dr. YoMan
Posts: 57
Joined: Thu May 24, 2012 11:00 am
Been thanked: 1 time

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Prof. Dr. YoMan » Fri Dec 07, 2012 3:54 pm

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".

User avatar
Giovanni
Site Admin
Posts: 13063
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 757 times
Been thanked: 636 times
Contact:

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Giovanni » Fri Dec 07, 2012 4:24 pm

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

User avatar
Prof. Dr. YoMan
Posts: 57
Joined: Thu May 24, 2012 11:00 am
Been thanked: 1 time

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Prof. Dr. YoMan » Fri Dec 07, 2012 4:40 pm

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

User avatar
Tectu
Posts: 1226
Joined: Thu May 10, 2012 9:50 am
Location: Switzerland
Contact:

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Tectu » Fri Dec 07, 2012 4:48 pm

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


~ Tectu

User avatar
Prof. Dr. YoMan
Posts: 57
Joined: Thu May 24, 2012 11:00 am
Been thanked: 1 time

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Prof. Dr. YoMan » Fri Dec 07, 2012 5:41 pm

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
Posts: 36
Joined: Wed Oct 17, 2012 8:57 am

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Freddie Chopin » Fri Dec 07, 2012 6:01 pm

Giovanni wrote: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!!

User avatar
Tectu
Posts: 1226
Joined: Thu May 10, 2012 9:50 am
Location: Switzerland
Contact:

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Tectu » Fri Dec 07, 2012 8:02 pm

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
Posts: 36
Joined: Wed Oct 17, 2012 8:57 am

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby Freddie Chopin » Fri Dec 07, 2012 8:06 pm

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
Posts: 20
Joined: Sun May 13, 2012 3:59 pm

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby lmamakos » Fri Dec 07, 2012 8:11 pm

Freddie Chopin wrote:
Giovanni wrote: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
Posts: 21
Joined: Sun Jul 03, 2011 6:48 am
Location: Bend, Oregon, USA

Re: [RFC] Ideas for ChibiOS/RT 3.0

Postby jcbarlow » Fri Dec 07, 2012 9:48 pm

lmamakos wrote: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.


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 5 guests