[RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)

[Michal Lenc]

Dear RTEMS developers,

we have made a progress with our CAN stack and virtual/CTU CAN FD
controller tests using standard x86-64 QEMU. We can now provide scripts
that build the stack and our applications on i386-pc686 target and run
RTEMS in QEMU. The actual CAN stack can still be found in our university
GitLab

https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd

and following steps build and run RTEMS in QEMU:

$ export PATH=$PATH:/opt/rtems/6/bin

$ cd targets/i386_pc686

$ ./setup-host-socketcan

$ ./qemu-i386-pc686-2x-ctu-pci-build

$ ./qemu-i386-pc686-2x-ctu-pci-run

Support for i386_pc686 BSP is located in /opt/rtems/6 in this case. You
can use following script to compile the BSP with required configuration
setting.

$ ./i386-rtems-sys.cfg (you might need to change RTEMS_DIR variable
based on your location of RTEMS source code directory)

RTEMS terminal in QEMU should come up after executing run command. You
can try applications for both virtual controller and CTU CAN FD
controller. The controllers have to be initialized and register which is
done by

can_register -t [target]

command (target is either virtual or ctucanfd). Registered devices are
assigned to test applications with can_set_test_dev [dev0] [dev1]
command, where dev0 and dev1 are paths to character devices. Then test
applications are can_1w (one way) and can_2w (two way). For example for
CTU CAN FD

# this registers two CTU CAN FD controllers under dev/can0 and dev/can1

SHLL [/] # can_register -t ctucanfd

# assign dev/can0 and dev/can1 to test applications

SHLL [/] # can_set_test_dev /dev/can0 /dev/can1

# run test applications

SHLL [/] # can_1w

SHLL [/] # can_2w

All those steps are also described in project README or you can use help
app command in RTEMS terminal to get further description of commands and
their arguments.

We want to rewrite some other controllers for our CAN stack to provide
further tests and widen the support (SJA1000 would probably be the first
one on our list), but currently the priority is the full completion of
the stack itself (error reports, all required IOCTLs, etc.).

Best wishes,

Michal Lenc