CBord board abstraction

Definition of terms

The CBoard is not one concrete and not one abstract class. The CBoard is not the fixed class name.
The CBoard is the proposed way to isolate the main application from the hardware and the environment.
The CBoard is one shortcut for the implementation of the board hardware abstractions.
As soon as the hardware abstraction performed the requirements listed below, it is referenced as "CBoard".

The main idea between CBoard is to move application between hardware abstractions without the need for the changes in the application self.
For example: more from bare metal to posix enwironment, and at same time move from native CAN HW to the socket based communication and/or replacing CAN communication by UDP.

Main CBoard proncipies

Each type of the service provided by the HW is abstracted throuch one common interface.
The interface satisfy following requirements:
1. Pull based (application had to poll data from the interface)
2. Interface is free from teh concurrency (concurrent resource access handled inside of the CBoard)
3. No pointers used for data tranbsfer. References to arrays withfixed length usedtead.
4. No data is passed by reference. Data always copied from the CBoard to the application. Memory management objects and memory block handles are used to transfer huger amounts of data, if necessary.
5. Free form environment specific details and configuration.
6. Provided by the CBoard services to be exposed by ports provided with interface contracts assigned to the ports.
7. No associacions to CBoard allowed.

Example of the CBoard interface CAN

The low level CAN interface provides services:
1. Send CAN message
2. Receive CAN message
In both cases the application has to pool to get the transmission status and to poll to get access to the new data received.
Of interest are the "byIndex" versions of the interface functions. The functions require the "can id index" versus "can id value".
This allows to isolate the real can id values from application and to use address handles.
At same time it allows to move the application to the other platform with other HW and to use the UDP. The application self will still use the can id handles (consider als configuratiuon handles) and not affected by this change:
Platform1: can id handle -> CBoard -> can ID 0x1234
Platform2: can id handle -> CBoard -> can ID 0xabcd
Platform3: can id handle -> CBoard -> UDP port 1002.

At same time numerous CAN HW is available. This is two general types of the HW:
1. Intelligent CAN controller: provides enough buffers and filters for each CAN ID send or received.
2. Simple CAN controller: provides limites anount of buffers, buffers are scheduled by SW, messager are filtered by SW

The provider of the low level CAN interface is responsible to expose the intelligent CAN behavior to the applications. For this reason the applications are free form HW related details and always developed in the assumption enough rx and tx buffers provided by HW.
In case of the intelligent CAN HW the can id index is used to map the function call to the HW buffer directly.
In case of the standard CAN the can id index is used to map to the simulated buffer and the SW is responsible for the scheduling of the buffers.

Future CBoard development

At current moment the available CBoard implementations are monolitic, and build to met the supported platforms only.
The better approach is to provide set of the reuseable components to support the CBoard development.
In the first order this is necessary for the POSIX CBoard.
For this reason the available CBoard abstractions shall be re-worked and will receive the name CBoardNG in the future.