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.
What's New:
A little about the FlexCAN issue...
When I was originally testing use of this library on Teensy with FlexCAN, I did my testing with the VT example using a terminal that only supports 16 ETP frames at a time, which hid the fact that large ETP sessions could become corrupted due to a few issues/gremlins which I will discuss below. When testing on a terminal that supported 255 frames, I could reproduce the issue in #4
Results of my investigating:
seq
flag when writing frames to FlexCAN, which could cause out of order messages to be sent.seq
flag, there is definitely a bug either in the FlexCAN_t4 driver, or with the actual FlexCAN peripheral on the i.MX RT1060Long story short, there's gremlins in the CAN peripheral on the Teensy, which is very frustrating as a library developer. I have worked with many ARM devices with rock-solid CAN peripherals before, and this one seems... not great.
Anyways, rant over, I think this PR will essentially "fix" the issue for nearly every use-case for our library, because it ensures that an entire ETP sessions worth of frames will fit with plenty of overhead. I tested with a terminal that supported the max ETP frame count and several other devices on the bus, and it seemed much more reliable.
Side note
One thing I noticed the better terminal doing was if it received an ETP frame out of order, it would re-request part of the same session starting from the last good packet it received. Our library does not yet support this, but we should! I will open a ticket on the main repo to support that at some point.
Closes #4