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.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
