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

[Pavel Pisa (@ppisa)]

Pavel Pisa commented on a discussion on cpukit/dev/can/ctucanfd/ctucanfd_txb.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108450

 > +#undef TXB_SH
 > +
 > +#define TXT_DONE     0x4
 > +#define TXT_BF       4
 > +#define TXT_MASK     0xf
 > +#define TXT_ANY_DONE ( ( TXT_DONE << ( 0 * TXT_BF ) ) | \
 > +                       ( TXT_DONE << ( 1 * TXT_BF ) ) | \
 > +                       ( TXT_DONE << ( 2 * TXT_BF ) ) | \
 > +                       ( TXT_DONE << ( 3 * TXT_BF ) ) | \
 > +                       ( TXT_DONE << ( 4 * TXT_BF ) ) | \
 > +                       ( TXT_DONE << ( 5 * TXT_BF ) ) | \
 > +                       ( TXT_DONE << ( 6 * TXT_BF ) ) | \
 > +                       ( TXT_DONE << ( 7 * TXT_BF ) ) )
 > +
 > +#define TXB_BF 4
 > +#define TXB_MASK 0xf

Yes and no, by coincidence, TX_STATUS (3.1.37) register has the same bit field size for the buffer as the TX_PRIORITY (3.1.40) and uint32_t txb_order has the same 4 bits per entry as well. But TXB_ and txb_order are fully software only constructs and code can be directly copy pasted into some other controller optimized solution and even 64-bit storage and 5 bit wide bit-fields could be used. 4-bits per status are CTU CAN FD specific as well as in the theory separated priority register fields which size is hard-coded in ctucanfd_txb_order2prio.

Probably more comments would help. I am not sure if adding PRIO_ORDER, TX_STATUS and PRIO_REG in each define would be better because is descriptive or worse because relatively complex tricks with shifts etc. starts to be unreadable.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108450
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/af5ede9a/attachment.htm>