Hello Prashanth, On Thursday 14 of April 2022 20:20:45 Prashanth S wrote: > This is to summarize the things suggested from the discussions and clarify > on CAN generic APIs. > > Things on the plate: > > - CAN driver for BBB. OK > - CAN driver for any one of the QEMU supported SoC (SJA1000 on PCI/e on > x86, Zynq UltraScale+ MPSo on QEMU). usesfull for testing > - Generic CAN APIs yes > - ADC driver (not using libbsd) for BBB.
it is my opinion, may it be somebody else should express his/her from other perspective. > Please correct me if I missed out anything. > Query on CAN generic APIs: > With my understanding on the discussions, Should I use the mentioned stacks > (LinCAN, CANOpen) as reference CANopen is higher layer, not relevant for the low level code and should be possible to build above any of the drivers. LinCAN not strict, may be only some inspiration > and define the data structures (CAN message header and CAN message > structures) or port one of the stacks (In case port one of the stacks is > the right option: I would suggest to go through CAN message structures of the existing projects and use one of them or define one which is easy to use and port. I would help. I do not suggest unsigned long for ID as it is in LiNCAN for example. I suggest uint32_t. > From the suggestions given in the discussions, I could not conclude which > stack to choose, Considering the future Scalability (both software stack > and CAN protocol features) and portability) to RTEMS. The minimal driver can be directly based on MPC5200 direct use of rtems_message_queue(s), one for Rx and one for Tx https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/mscan Its message format there https://git.rtems.org/rtems/tree/bsps/powerpc/gen5200/include/bsp/mscan.h Again problematic uint16_t mess_id; which prevents compatability with extended message format. I suggest some single bigger unsigned type used with masks for RTR, EXT and futire BRS and CAN FD flags, flags. uint8_t mess_rtr; is not extensible. It would be great to find if somebody is actually using MPC5200 RTEMS BSP still and in such case negotiate changes with them. May it be GrLib unification could be usesfull as well. I look at https://git.rtems.org/rtems/tree/bsps/include/grlib/grcan.h#n133 /* CAN-FD MESSAGE */ typedef struct { uint8_t extended; /* 1= Extended Frame (29-bit id), 0= STD Frame (11-bit id) */ uint8_t rtr; /* RTR - Remote Transmission Request */ uint8_t fdopts; /* Bit1: 1=Switch bit rate. bit2: 1=FD frame. */ uint8_t len; /* 0-8, 12, 16, 20, 24, 32, 48 or 64 bytes */ uint32_t id; union { uint64_t dwords[8]; /* up to 64 bytes if FD=1 and len>8 */ uint8_t bytes[64]; /* up to 64 bytes if FD=1 and len>8 */ } data; } CANFDMsg; This messageformat look acceptable. The first uint8_t forms in the fact aligned unit32_t. I would personally put extended, rtr and fdopts into single masked integer, but this is acceptable. Missing is space for 16-bit or better at least 32-bit timestamp. As for the infrastructure/stack, I would prefer to prepare code for multiple prioritized queues and LinCAN and SocketCAN provides. But as I have mentioned simple RTEMS queues can be used for initial proof and change later to something with more functions would not be problem if API is designed such way, that it does not need to be changed. I offer co-mentor role or possibly even mentor but I would not have time over whole summer and I have quite lot to do till semester end, so I can have week or two delay... not ideal for main mentor. Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ company: https://www.pikron.com/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel