Peter Vranken - 2022-10-05

The CAN interface has undergone a redesign. The monolithic structure has been broken up into a now user-visible object structure with publicly defined interfaces. This allows to exchange all cooperating elements with interface-compatible other ones, which may be either chosen from the palette of available implementations or be self-made if specific platform or environment requirements hinder from using the pre-defined ones.

The new concept widens the flexibility in integrating the interface in various platforms. In particular two uses cases are addressed:

  1. Memory protected or managed environments

The monolithic structure so far had contained an event queue, which was implemented in a multi-threading- and multi-core-safe way. Events generated on one core could be processed on the other core. While working fine, it could not meet the demands of memory protected systems as for example demanded by safety related software. All involved memory had been from the same sphere, i.e., having same address space and access rights. Now, the basically same queue implementation has got separate objects for head and tail, such that the event producer can be instantiated in a another memory sphere than the consumer, with differing access rights and maybe even at differing address. (Whereas it still needs to be the same physical, shared memory.) If only the producer has write access, the consumer can only read from the queue, then we already have an example of Freedom from Interference, which is a basic requirement of safety related software.

  1. Better support of modern hardware

The dispatcher in the monolithic structure so far unavoidably had an event queue. The new dispatcher just has an event port. Connecting a queue object to this port is no more then the most common, typical use case. However, nowadays CAN controllers often have plenty of RAM and this RAM can be shaped into a message queue. If this queue is large enough then no additional software queue is required any more. It requires only a few lines of code to wrap the existing CAN driver API into an event port interface, which can be directly connected to the dispatcher.

The same idea holds if the CAN driver has a sufficient number of parallelly working mailboxes and if regularly polling these mailboxes is deemed safe enough to avoid message loss.

Migration of existing code to the new architecture will be about a day of work after studying the samples and understanding the differences.

The two code generators have barely been changed. Major difference is the integration of the latest releases of the Java libraries ANTLR and StringTemplate V4.