GSoC - CAN driver for BBB Was: CAN Options and Licensing, Testing, etc

[Pavel Pisa]

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:     pisa at 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