ppisa opened a new pull request, #15564:
URL: https://github.com/apache/nuttx/pull/15564
## Summary
Corrected CAN FD messages sending in character driver mode. Assign CAN FD
format flag in reception of CAN FD messages. Corrected some defines mismatches.
The overall state of this third party CTU CAN FD driver in NuttX is far from
ideal. It would worth to consult and follow more closely our Linux kernel
driver and even better RTEMS CAN/CAN FD stack design
https://canbus.pages.fel.cvut.cz/#cancan-fd-subsystem-and-drivers-for-rtems
## Impact
Without these fixes, CAN FD messages are sent without FDF flag set and if
combined with data
length longer than 8 bytes then it causes error reporting on QEMU side when
sent to
host over SocketCAN and message is discarded.
Other errors cause incoming messages missing ch_edl flag set for FDF marked
incoming
messages.
## Testing
The code has been tested in QEMU
qemu-system-x86_64 -m 2G -enable-kvm -smp 1 \
-cpu host,+pcid,+x2apic,+tsc-deadline,+xsave,+rdrand \
-kernel nuttx/nuttx \
-nographic -serial mon:stdio \
-object can-bus,id=canbus0-bus \
-object can-host-socketcan,if=can0,canbus=canbus0-bus,id=canbus0-socketcan
\
-device ctucan_pci,canbus0=canbus0-bus,canbus1=canbus0-bus
## Discussion
In general, the code requires to include bitrate calculation. I would be
happy
if NuttX community agrees so some common principles how it should be done.
I would suggest 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 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`.
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?
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.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
