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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
