Pavel Pisa commented: https://gitlab.rtems.org/rtems/rtos/rtems-examples/-/merge_requests/22#note_147237 For information, RTEMS CAN/CAN FD stack support use of single interface for multiple applications which can interact with other nodes connected through CAN controller and CAN bus but they can even interact in between on a given node. When the message is send successfully by the controller then it is echoed back to all other local open of the given controller. Echoing to the sending file object/handle is filtered by default, `CAN_FRAME_ECHO` mask is set on queues by default. But the `CAN_FRAME_LOCAL` to distribute locally sent frame to other local applications is enabled in the filters by default. Because virtual CAN "chip" has no connection to external bus, the use of `CAN_FRAME_LOCAL` frames is the only way how to communicate over it. For the drivers operating with real hardware, they can be used same way but the rule for CAN communication is that the frame is not considered sent successfully if it is not confirmed by at least one other physical node on the bus. So solo controller would newer send message and that is why it even does not distribute it to the local applications. Some controllers can support setting `CAN_CTRLMODE_PRESUME_ACK` mode. When this mode is set, then even physical controller does considered the frame as sent successfully even if no other node acknowledges it. In such cane, multiple applications can run on the single node with single controller and the communication can be observed on physical interface for example by oscilloscope. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems-examples/-/merge_requests/22#note_147237 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
