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/can-quekern.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108456

 > + * @brief This function waits for all slots processing
 > + *
 > + * @param qends   Ends structure belonging to calling communication object.
 > + * @param qedge   Pointer to edge.
 > + * @param nowait  True if semaphore should not wait
 > + * @param timeout Number of clock ticks to wait for semaphore
 > + *
 > + * @return Positive value indicates, that edge empty state has been reached.
 > + * Negative or zero value informs the semaphore timeouted.
 > + *
 > + */
 > +int canque_sync_wait_kern(
 > +  struct canque_ends_t *qends,
 > +  struct canque_edge_t *qedge,
 > +  bool nowait,
 > +  rtems_interval timeout

We need all three, infinite wait, limited wait and no wait and mapping to RTEMS API is a little tricky there `rtems_binary_semaphore_wait_timed_ticks` ... A ticks value of zero specifies an infinite timeout.
And because we want to keep total wait time limit from the user perspective, we can exhaust whole time on previous testing iterations and only zero time is left but it should not be converted to infinite wait...

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