Giovanni wrote:Hi,
It looks interesting, I cannot give it a try right now, too many things ongoing, I would appreciate some feedback about it.
It would help to know how to try it.
Giovanni
It's pretty cool, we've been using it internally for a while now. So, it's battle tested code to some degree.
CAN: Using socket CAN allows you to connect multiple CAN nodes together (each of which could be a ChibiOS instance) on the same machine using vcan (virtual can devices - supported natively by socket CAN), or to external devices over an actual CAN device (such as a USB to CAN converter). It works transparently, and the ChibiOS application need not know if it is a virtual CAN device or a physical one. We've tested this using dozens of instances of ChibiOS running over multiple virtual CAN buses. The CAN buses were created using can-gw (in the linux can-utils package), which allows you to define routing rules between CAN devices. Using that tool, you can create multiple broadcast domains - thus making each one look like a "bus".
Serial/UART: Both of these use tty or pts in the back end. Which means, just like CAN, you can transparently have serial communication with a virtual tty device (pts) and communicate with another application on the same machine, or you can specify the path to /dev/ttyUSB0 for example - and do serial comms with a device external to the PC. The ChibiOS application doesn't really know the difference. The driver just needs a path to the device.
The UART driver is probably the one for which comments are needed. Currently it models the STM32 registers, as the existing HAL at the time didn't support character match - and we wanted our application to target both uC and simulation. This could probably use some working over...
I think improving the Simulation port of ChibiOS could lead to greater adoption as well - you don't even need hardware to evaluate it, and do quite complex things with it. For example, on each of those dozens of ChibiOS instances mentioned above, we were running a full IP stack, sensor emulation, file I/O, etc .. Each of which could be retargeted on actual hardware and pretty much "just work".