CAN driver message structure

[Karel Gardas]

Hi Prashanth,

not sure about others but Pavel Pisa is CAN expert here. CCing him 
directly as I've not seen him active recently.

Anyway, as a non-expert I'd like to offer my hopefully not that 
misleading point of view.

If you are going to write CAN driver, then you first need to interface 
with the physical hardware which may expect data push to it and pulled 
from it in a certain format. That is probably the reason why you see 
different CAN message formats spread over RTEMS tree.

But your approach or intuition of providing generic CAN message format 
is of course right here. The problem is, such messsage format then needs 
to be part of some CAN-related API which is used by user application. 
There are several ways how to design such API, but if we like to stay 
more generic, it's probably better to look around and see what people 
are already using.

- in Linux world, there is a push to SocketCAN: 
https://en.wikipedia.org/wiki/SocketCAN and 
https://www.kernel.org/doc/html/latest/networking/can.html
The API is also considered to be implemented or already implemented on 
top of some RTOSes like NuttX and Zephyr:
https://forum.opencyphal.org/t/socketcan-api-on-a-rtos/750
https://docs.zephyrproject.org/2.6.0/samples/net/sockets/can/README.html

- the other crowd is pushing CANopen which not only provides whole 
layered architecture, but also its own API:
https://en.wikipedia.org/wiki/CANopen
https://canopen-stack.org/v4.2/api/node/

I would definitely wait for Pavel message to know where the wind is 
blowing in industry these days and which API is most probably to be used 
in the future.

Cheers,
Karel

On 4/12/22 02:40, Prashanth S wrote:
> Hi All,
> 
> This is to query on CAN message format for CAN drivers.
> 
> I want to implement a CAN driver for BeagleBone Black in RTEMS(GSoC).
> 
> As I looked through the RTEMS Source Tree, found
> https://devel.rtems.org/browser/rtems/bsps/arm/lpc176x/can
> <https://www.google.com/url?q=https://devel.rtems.org/browser/rtems/bsps/arm/lpc176x/can&sa=D&source=docs&ust=1649726382869937&usg=AOvVaw3vJP6V_BiCCjzC3q-F4AH1>
> , https://devel.rtems.org/browser/rtems/bsps/powerpc/gen5200/mscan
> <https://www.google.com/url?q=https://devel.rtems.org/browser/rtems/bsps/powerpc/gen5200/mscan&sa=D&source=docs&ust=1649726382870043&usg=AOvVaw3i4_IK73l4WoZ7u64ab0yB>
> CAN drivers, which have driver specific CAN message structure.
> 
> https://devel.rtems.org/browser/rtems/bsps/powerpc/gen5200/include/bsp/mscan.h
> struct can_message {
>    /* uint16_t mess_len; */
>    uint16_t mess_id;
>    uint16_t mess_time_stamp;
>    uint8_t  mess_data[MSCAN_MAX_DATA_BYTES];
>    uint8_t  mess_len;
>    uint8_t  mess_rtr;
>    uint32_t toucan_tx_idx;
> };
> 
> https://devel.rtems.org/browser/rtems/bsps/arm/lpc176x/include/bsp/can.h
> typedef union {
>    low_level_can_message low_level;
>    registers_can_message registers;
>   } can_message;
> 
> I would like to know if I should define a driver dependent CAN message
> structure or use one of the existing ones.
> 
> Ideally, I think a generic (driver independent) CAN message structure will
> help applications to be portable.
> 
> Regards
> Prashanth S
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel