ppisa commented on PR #11868: URL: https://github.com/apache/nuttx/pull/11868#issuecomment-1991785732
In general, I am happy that driver will be moved to the common code area and can be used with all ESP32 chips and even SJA1000 chips from single source which allows to keep it update and reuse profit of each enhancement for all SJA compatible/based controllers integrated int broad range of chips. I expect that you use code with our old JSA1000 FD tolerant design https://gitlab.fel.cvut.cz/canbus/zynq/sja1000-fdtol . I have no time to look at it for years but if you have some enhancement, fix of problems available, I will be happy to integrate it when I have some more time. I expect that you will use driver with some FPGA based design. In such case I can help you with basic functional SJA1000 emulation in QEMU which allows to develop driver core without need to debug on hardware (bittiming and lot more has to be developed on real HW anyway). Our SJA1000 emulation is included in QEMU for years https://www.qemu.org/docs/master/system/devices/can.html but mapping is only for PCI/PCIe devices. But during our CTU CAN FD river development for RTEMS, I have found way how to implement QDEV mapping the core into Zynq FPGA address space by QEMU commandline arguments. Some part of the code is still a hack and I need to discuss with people more knowledgeable about QEMU internals how to resolve it better, but it works for us with RTEMS and Linux kernel for testing. The branch and mapping file are there https://github.com/ppisa/qemu/blob/net-can-ctucanfd-platform/hw/net/can/ctucan_mm.c I expect that adding such mapping to system bus for our SJA1000 emulation on Zynq and other SoC targets would be simple task. I can try that. It could be extended to TWAI emulation on ESP32C3, C6, etc... if somebody from Espressif is interested. I can try to find some CTU student to do that as summer job for some small funding. We have reached quite huge progress with our RTEMS CTU CAN FD drivers and complete new CAN FD framework and we are ahead of schedule. In some of my past exchange with MoTeC, I have stated that we should have driver ready by May and it can be reused on NuttX. We have some minor things to resolve still, but base code i performing excellent including link priority inversion between priority classes prevention. We will have article at iCC about that https://www.can-cia.org/icc/ . The RTEMS CTU CAN FD driver core is there https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/blob/master/lib/candrv/ctucanfd/ctucanfd.c . As result of review process, we will change queues locking to RTEMS core maintainers suggestion etc. But I think that porting to NuttX can start soon when somebody finds time for that. I can get to it myself, but probably not earlier than in summer. @michallenc (actual main developer on RTEMS side) has lot of tasks as well so he probably cannot find time earlier either. -- 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
