RTEMS | Draft: cpukit: add support for common CAN/CAN FD stack (!49)

[Pavel Pisa (@ppisa)]

Pavel Pisa commented on a discussion on cpukit/include/dev/can/can-queue.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108464

 > +
 > +#include <stdatomic.h>
 > +#include <inttypes.h>
 > +#include <sys/queue.h>
 > +#include <rtems.h>
 > +#include <rtems/timespec.h>
 > +#include <rtems/status-checks.h>
 > +#include <rtems/thread.h>
 > +
 > +#include <dev/can/can-frame.h>
 > +#include <dev/can/can-filter.h>
 > +
 > +/**
 > + * @brief This structure represents one CAN message slot in the CAN FIFO queue.
 > + */
 > +struct canque_slot_t {

The shorten names are to keep code line lengths sane. We have abandon keeping any wrappers and names restrictions for portability to Linux and NuttX. The RTEMS is actual priority. Then I plan to work on CTU CAN FD driver for NuttX and may it be test back on Linux but I know that we are going with actual work to add much more work to that steps. But original LinCAN code which kept compatibility wit Linux back to 2.4 kernels and allowed to build same code even without operating system in our sysless applications was nightmare and is unacceptable for any system mainline.

The different "word stems" and abbreviations in identifiers tries to help with orientation what is inner API, what is driver API what is low level FIFO API which should not be used directly etc. But complete rewrite (often from scratch) to make code better fitting RTEMS has mixed initial reasons and even that we have discussed about options the tuning of the result, catching and correction of commissions is on the table.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108464
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240628/11b78d6c/attachment-0001.htm>