[FEATURE] CAN and CAN FD bittiming/bitrate calculation consolidation and CAN drivers updates goals

[ppisa]

Is your feature request related to a problem? Please describe.

CAN/CAN FD bittiming calculation is spread in many diverging implementations and concepts in NuttX CAN drivers.

It is often solved by mapping to individual chip/controller timing parameters defined for discrete bitrate base, which makes controllers unusable for another chip variants or different clocks setups.

Describe the solution you'd like

Sound CAN/CAN FD subsystem where code duplication is seriously weighted against maintenance cost and problem to fix common or individual issues on many locations in the source tree. The Linux CAN subsystem has proven the broad scale reusability of the common controller codes. We have show such possibility in LinCAN even before SocketCAN and LinCAN base has been used for more system-less setups as well as ported to RTEMS recently. So there is space for incremental progress in proposed direction.

Describe alternatives you've considered

I would suggest to consider the solution which I have proposed more than 20 years ago for LinCAN and later updated and provided to SocketCAN

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/dev/calc_bittiming.c

The code which has been maintained for LinCAN, other our projects and updated for RTEMS recently has NuttX compatible license

https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/blob/master/lib/candrv/can-bittiming.c

I would like to know, what should be the prefix for NuttX to keep some namespace rules for single image linking with application. I propose nx_ prefix, that is rename rtems_can_bitrate2bittiming -> nx_can_bitrate2bittiming.

CTU CAN FD bittiming and changes

As for the CTU CAN FD driver, there is bittiming calculation missing completely in NuttX driver

https://github.com/apache/nuttx/blob/master/drivers/can/ctucanfd_pci.c

It is usable for test in QEMU emulated environment only for now.

The driver should be separated to common part and separate PCI mapping part. The common initialization function on RTEMS driver is

struct can_chip *ctucanfd_initialize(
  uint32_t addr,
  rtems_vector_number irq,
  int ntxbufs,
  rtems_option irq_option,
  unsigned long can_clk_rate
)

https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/blob/master/lib/candrv/ctucanfd/ctucanfd.c?ref_type=heads#L1491

Should be the prefix nx_ or some other applied there as well?

When the code is separated then the same base can be used for PCIe devices on real hardware and QEMU. And the same code could be reused for FPGA SoCs based systems.

I have experimental FPGA design with CTU CAN FD prepared for our LX_CPU (part of LX_RoCoN) board with NuttX support.

Our main CTU CAN FD development environment is XilinX Zynq, but that is not supported by NuttX.

But we are working on PolarFire (BeagleV Fire) CTU CAN FD support with RTEMS, Linux and it should be usable even for NuttX.

SJA1000

There is multiple implementations of the driver in the NuttX tree, some are fully based on our code, some probably only partially, i.e. new Espressif code which allows only limited set of discrete bitrates for limited input clocks frequencies and even for that it has lot of defines magic inside...

https://github.com/apache/nuttx/blob/master/drivers/can/kvaser_pci.c

https://github.com/apache/nuttx/blob/master/drivers/can/kvaser_pci.c

https://github.com/apache/nuttx/blob/master/arch/risc-v/src/esp32c3-legacy/esp32c3_twai.c

https://github.com/apache/nuttx/blob/master/arch/risc-v/src/common/espressif/esp_twai.c

https://github.com/apache/nuttx/blob/master/arch/xtensa/src/esp32/esp32_twai.c

This level of code duplication is nightmare and each copy has has some missing features and limitations. So long term goal should be to look for code reuse and ideally single central bittiming calculation and SJA1000 driver common, maintainable and durable functionality which allows mapping to different SoC integrations.

Verification

• I have verified before submitting the report.