ppisa opened a new issue, #15567: URL: https://github.com/apache/nuttx/issues/15567
### 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](https://www.pikron.com/pages/products/cpu_boards/lx_cpu.html) (part of [LX_RoCoN](https://www.pikron.com/pages/products/motion_control/lx_rocon.html)) board with NuttX [support](https://nuttx.apache.org/docs/12.5.0/platforms/arm/lpc40xx/boards/lx_cpu/index.html). 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 - [x] I have verified before submitting the report. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
