Conversation
Allow the CANopenNode ASCII gateway command FIFO to be safely accessed from a transport thread while CO_GTWA_process() runs in the CANopen processing context. - add a CAN module context to CO_GTWA_t - add CO_LOCK_GTWA() and CO_UNLOCK_GTWA() driver hooks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request Description (PR description)
[
Why is this PR needed
CANopenNode's ASCII gateway uses
commFifofor receiving command data.When a transport runs in a different execution context from
CO_GTWA_process(), the transport may write to the FIFO while the gatewayparser is reading, searching, or resetting the same FIFO.
This is required by transports such as an RTOS console frontend, where
command input is produced by a shell thread while gateway processing runs
from the CANopen main processing context.
The change also fixes several printf format mismatches exposed on targets
where the fixed-width integer typedefs differ from the types assumed by
the original explicit casts.
What is your solution
Add a CAN driver synchronization context to the ASCII gateway and introduce
CO_LOCK_GTWA()/CO_UNLOCK_GTWA()driver hooks.The locks are intentionally limited to individual shared FIFO operations:
The complete
CO_GTWA_process()state machine is not locked, so potentiallylong-running SDO, NMT, LSS, response generation, and callback processing do
not hold the transport synchronization primitive.
CO_GTWA_init()now receives the CAN module used by the driver-specificlocking implementation.
The change also updates fixed-width integer formatting to match the
<inttypes.h>format macros without relying on incompatible explicit casts.]