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
I just wanted to get some clarification on the support for RTR bits in this library since in this open issue there's mention that the library doesn't support RTR bits and setting the existing flag does nothing. However, at the same time there is this merged pull request that seemingly added support for reading and writing RTR bits.
From my own use/testing with this library, it feels like the implementation/interpretation of the RTR bit exists but isn't quite right since the receiving CAN_FRAME object stores an RTR bit and increments the value with each frame received until it reaches 0x1F where it overflows back to 0.
Any insight/clarification on this issue would be greatly appreciated. Below is a snippet of my output from printing the received frames:
The text was updated successfully, but these errors were encountered:
I just wanted to get some clarification on the support for RTR bits in this library since in this open issue there's mention that the library doesn't support RTR bits and setting the existing flag does nothing. However, at the same time there is this merged pull request that seemingly added support for reading and writing RTR bits.
From my own use/testing with this library, it feels like the implementation/interpretation of the RTR bit exists but isn't quite right since the receiving CAN_FRAME object stores an RTR bit and increments the value with each frame received until it reaches 0x1F where it overflows back to 0.
Any insight/clarification on this issue would be greatly appreciated. Below is a snippet of my output from printing the received frames:
The text was updated successfully, but these errors were encountered: