Pavel Pisa commented on a discussion on cpukit/dev/can/can-queue.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108462 > + rtems_mutex_unlock( &outends->ends_lock ); > + } > + } else { > + if ( inends ) { > + rtems_mutex_unlock( &inends->ends_lock ); > + } else if ( outends ) { > + rtems_mutex_unlock( &outends->ends_lock ); > + } > + } > + > + RTEMS_DEBUG_PRINT( "Edge %d returned %d\n", qedge->edge_num, ret ); > + return ret; > +} > + > +/** > + * @brief This function blocks slot allocation of all outgoing edges of This is problematic, the node outgoing edges are connected to the node by their inputs, the description canque_ends_t - inlist - This member holds the list of outgoing edges input sides. - outlist - This member holds the list of all incoming edges output sides. canque_edge_t - inends - This member holds the pointer to the FIFO input side terminal - outends - This member holds the pointer to the FIFO output side terminal So than naming is tricky, that s why read or write, Tx or Rx is not used and each entity has in and out side. The framework is generic so complete graph is possible which has been planned for routing, redundancy etc. Tx and Rx side is implemented by same low level queues code and same code implements nodes on chip and user sides but there is the specialization how events are propagated in the upper layer etc... -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108462 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
