RTEMS | Draft: cpukit: add support for common CAN/CAN FD stack (!49)
Pavel Pisa (@ppisa)
gitlab at rtems.org
Fri Jun 28 12:45:16 UTC 2024
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_108465
> +struct canque_fifo_t {
> + /**
> + * @brief This field holds global flags describing state of the FIFO.
> + * %CAN_FIFOF_ERROR is set when some error condition occurs.
> + * %CAN_FIFOF_ERR2BLOCK defines, that error should lead to the FIFO block state.
> + * %CAN_FIFOF_BLOCK state blocks insertion of the next messages.
> + * %CAN_FIFOF_OVERRUN attempt to acquire new slot, when FIFO is full.
> + * %CAN_FIFOF_FULL indicates FIFO full state.
> + * %CAN_FIFOF_EMPTY indicates no allocated slot in the FIFO.
> + * %CAN_FIFOF_DEAD condition indication. Used when FIFO is beeing destroyed.
> + */
> + atomic_uint fifo_flags;
> + /**
> + * @brief This member holds the number of elements in the fifo.
> + */
> + unsigned int out_taken;
This is only the number of slots taken on the out side which processing has not been finished by chip driver (or copy to user in another direction). These has to be accounted because FIFI is not empty even that there are no slots on the linked list. Only when all slots taken by out side are processed then it can be signaled as empty. The take slots can be pushed back to the FIFO if unfinished hardware Tx buffers are reused for higher priority class (FIFO inernal `canque_fifo_again_outslot` and "public" `canque_again_outslot` functions).
--
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108465
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/dcfac170/attachment.htm>
More information about the bugs
mailing list