A CAN driver is needed for the managing of a specific CAN controller chip provided on the hardware level. In order to avoid the necessity of implementation of a CAN driver for each CAN controller type on the market, the concept of the generic CAN driver was introduced under EUROS. It handles the receive and transmit sequences of CAN messages at a higher level, without requiring detailed knowledge about the CAN controller itself. Through an appropriate configuration of a common source code library the driver for the specific CAN controller is generated automatically. This approach takes into consideration that all CAN controllers are virtually identical - they have to implement the same functionality. If certain type of functionality is not provided by a particular CAN controller, it is emulated by the driver's software.

Implementing new CAN controllers now means adding hardware-dependent code and connecting it with the existing source code library. This reduces implementation and support efforts drastically and allows the re-use of tested source code. Additionally, if enhancements in the API are done, all drivers benefit automatically.

Each "generic CAN driver" is generated out of the source code library for each CAN controller type; such a driver provides the mechanisms of sending and receiving CAN messages as well as managing error conditions. The drivers can run in a multitasking environment, which allows access to CAN from multiple tasks simultaneously. Detailed error management allows control over error situations on the CAN bus.

CAN drivers under EUROS are available for virtually all types of internal, as well as external CAN controllers.

The following functionality is provided by the generic CAN drivers:

• Initialization of the CAN controller
• Configuration of the communication parameters such as baud rate, sample point, etc.
• Transmission and reception of both 11-bit and 29-bit messages on the same CAN bus segment
• Transmission of messages using timeout or asynchronous behavior
• Configuration of callbacks (hooks) for message reception
• Configuration of message reception for single/multiple message IDs and for single/multiple message ID/Mask pairs

CAN protocol stacks are used on top of a CAN driver, on a second level, where the message content of CAN messages is evaluated and presented to an application using appropriate objects. This enables the user to access data on a logical layer. It is not necessary to deal with message contents and format, and to keep timings and check timeouts; all of this is done by the CAN protocol stack itself.

CAN protocol stacks are implemented using approved CAN standards, and provide the functionality described there. Hardware access to the CAN controller is done using a CAN driver. This allows the protocol stack to be totally hardware-independent because it uses the standardized driver functions.