You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like the purpose of flushCan() is to discard any previously received messages before performing some queries with the JMCs. However, if we receive some extra CAN message during those queries, this will break.
Fortunately, decodeParamFrame() does some message validation to ensure that it has the proper IDs. However, rather than discard spurious messages, decodeParamFrame() prints an error and bails out.
I think the right behavior here is validate IDs for each received CAN frame, and discard that frame if the IDs don't match. Only if we do not receive a correct response from the JMC before some timeout should we abort (or maybe even retry). This would also make the flushCan() function unnecessary.
The text was updated successfully, but these errors were encountered:
It looks like the purpose of flushCan() is to discard any previously received messages before performing some queries with the JMCs. However, if we receive some extra CAN message during those queries, this will break.
Fortunately, decodeParamFrame() does some message validation to ensure that it has the proper IDs. However, rather than discard spurious messages, decodeParamFrame() prints an error and bails out.
I think the right behavior here is validate IDs for each received CAN frame, and discard that frame if the IDs don't match. Only if we do not receive a correct response from the JMC before some timeout should we abort (or maybe even retry). This would also make the flushCan() function unnecessary.
The text was updated successfully, but these errors were encountered: