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.
Abhishek wrote:My suggestion for the next generation of ChibiOS would be ChibiOS++, a C++ implementation of ChibiOS, and not just a wrapper. Especially, I feel that the HAL and device driver implementation should be moved. Being an OOP, it'd probably simplify portability problems across hardware a lot.
Totally agree with that. The HAL is already designed in a OOP-way but implemented in C which is definitely efficient. Implementing the drivers in C++ would transfer a considerable degree of work from designer (who has to take care manually about the interfaces, function-tables etc.) to the compiler. The C++ overhead is, if it's done right, almost negligible (see also The Inefficiency of C++ Fact or Fiction?).
Just my 2 cents.
I considered (and I am still considering) this, my problem is mainly with portability of such an approach, currently ChibiOS is portable even to the most #$%##$ proprietary compilers. If written in C++ it would be limited to G++ and very few decent and expensive commercial compilers. Except for portability, it would not be hard to rewrite external layers directly in C++ (all interfaces, high level HAL, queues, mailboxes, semaphores, mutexes etc) keeping the core scheduler in C.
Voted for more sub-systems. That would really ease development and would definitely bring some new users.
Also, a few more ports like lpc17/18xx (Fastest CM3, LCD controller), EFM32 (low power) and Kinetis (awesome peripherals, probably the best CM4 as of now) would be really cool.
The kernel already supports any Cortex device and apparently most commercial customers are only interested in the kernel.
Also, currently there is not enough development bandwidth to support other families at the same level of the STM32 so most you can realistically expect is some basic support at some point.
Giovanni wrote:[...] my problem is mainly with portability of such an approach, currently ChibiOS is portable even to the most #$%##$ proprietary compilers. If written in C++ it would be limited to G++ and very few decent and expensive commercial compilers. [...]
I'd suspect that gcc/g++ is the compiler of choice for most of the ChibiOS-users ( only a guess ). Most compilers in the list of the officially supported ChibiOS-ports are C++ capable compilers (GCC, IAR, RVCT). The STM8 seems to lack C++ compilers.
I only use gcc/g++, except for 8051 where I must use SDCC, ugh...
Anyway, a clean C++ ChibiOS++ would be nice, but a minor thing, since you can already do everything with the current design, I just say that it's a bit more effort to modify the ChibiOS/RT code. The improvement of a native C++ version would be mostly "sugar". Note that there would be NO REASON TO USE C AT ALL IN THE KERNEL. You don't pay for the C++ features you don't use, no matter how low level you want to go.
On the other hand, what I would like to have is better low power support in ChibiOS. That means ability to efficiently and easily (for application developers) use microcontroller low-power sleep modes and do event-driven programming, and possibly dynamic core clock speed switching. This would be a HUGE advancement, and I haven't seen other free RTOSs that have good low power sleep support already. At least when I looked at FreeRTOS it did not seem to.
