ppisa commented on issue #15567: URL: https://github.com/apache/nuttx/issues/15567#issuecomment-2612168607
> +1 for common bittiming calculation interface. Names with `nx_` prefix are OK. Great, I will discuss that with @michallenc and we would reuse knowledge or code (license is OK for some time already) from our RTEMS project. >The only problem I see now is where to place such a common interface that must be shared across chardev and socketcan implementation ? We already had a PR that tries to generalize some of the code in CAN implementations, but it got stuck: [#14759](https://github.com/apache/nuttx/pull/14759) I proposed there `include/nuttx/can_cmn.h` for common header but we need also place for common code, probably `drivers/can/can_cmn.c` will be enough. Previously `/drivers/can` was reserved for chardev implementation, but since we support PCI CAN cards in this directory that use both CAN interface - this is no longer valid. I don't see a better place for this kind of code. I would propose `drivers/can/can-bittiming.c` and `include/nuttx/can-bittiming.h`, which can be shared easily. The bittiming code in Linux kernel SocketCAN has been moved to separated files during its evolution. So it would not be a problem. > > CTU CAN FD bittiming and changes > > I agree, but we need someone who could verify if the changes work on real HW. Personally, I don't have access to any CTU CAN FD hardware. Implementation without any verification on real device makes no sense to me. Are there any commercially available PCI cards with this IP core? Playing with FPGA is out of the question for me at the moment :) CTU CAN FD has been run on multiple FPGAs, Altera (for some time Intel now), Xilinx, Lattice etc. The easiest it is on XilinX Zynq, but there is problem with missing NuttX support. I have that experiment build on our NXP LPC4088 + Xilinx XC6SLX9 based LX?RoCoN which has NuttX support. It not for real use, because FPGA is small and CTU CAN FD barely fits and nothing else, but I have tested that it can communicate with LPC CAN interface on this system from my system-less LinCAN port. > > SJA1000 > > Also agree, but again - we need someone who could verify all changes on different hardware with SAJ1000: 1. ESP implementation, 2. FPGA implementation, 3. PCI implementation. This is quite difficult for one person and also difficult to coordinate several people in the project who could help. The ESP is probably easiest, the best is ESP32C3 legacy because there is TWAI driver implemented by us, Jan Charvat's [bachelor thesis](https://dspace.cvut.cz/bitstream/handle/10467/87714/F3-BP-2020-Charvat-Jan-Model_of_CAN_FD_Communication_Controller_for_QEMU_Emulator.pdf) solved under my mentorship which is based on LinCAN and includes proposed bittiming algorithms inlined, simplified in the driver code. So they could be removed and replaced by common ones and tested easily. The later Espressif non legacy ESP32Cx HAL based TWAI driver made me to weep when I have seen the defines and bitrates, baserates ifdefs mess. -- 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 For queries about this service, please contact Infrastructure at: us...@infra.apache.org
