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.


_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs

Reply via email to