Open adriaan-niess opened 1 month ago
@JLPLabs, At first glance I think it would be a little bit more flexible to provide a timeout (longest possible time allowed to buffer a CAN message) to the talker application instead of a fixed number of CAN messages to be aggregated. Then the talker would either wait until
For the default setting we could set the timeout simply to zero which would imply no buffering at all.
But maybe you had a very specific reason why you did it the way you did?
Adriaan,
I like those ideas! And thank you for asking if I had a specific reason. I do, but it is perhaps a little selfish...
I do like the idea of a max number of CAN frames per Ethernet frame, as there may be use cases where the user (particularly while doing initial development, which is me right now!) prefers looking at only a handful of CAN frames in an Ethernet frame while analyzing protocol behavior.
I'm going to take the liberty of combining your idea with mine... I hope you are OK with that.
Let's say the default behavior of talker is "full buffering"-- unless the user indicates otherwise, we'll pack as many CAN frames into the Ethernet frame as we can before sending it.
If the user doesn't want "full buffering" then they can use one or both of --timeout
and/or --count
.
Here are behaviors other than default:
--count 1
-- today's behavior of talker (we send the Ethernet frame as soon as we get CAN frame).
--timeout 0
-- also gives today's behavior.
--count 5
-- do some packing, but keep it user-friendly when doing manual inspection of frames
--timeout 400
-- pack only "bursty" traffic
--timeout <time>
where <time>
is integer number of microseconds (not milliseconds), so that it is possible to support the use case where a user only wants packing done for "bursts" of traffic.
examples:
--count <count>
where <count>
is the maximum number of CAN frames allowed in an Ethernet frame.
The Ethernet frame is sent once any of these are true:
<time>
usec.<count>
--notes--
[1] This "only" gives the user 1.19 hours between messages... which for nearly all practical vehicle use is OK. (I could imagine some diagnostics done by a product engineer -- where they filter traffic looking for a very specific and rare event and they want all of theses rare events in one Ethernet frame and 1.19 hours isn't enough). For this case the engineer should create their own application?? Otherwise the tradeoff could be to measure <time>
in ms, and which means we can no longer require packing to be done for just "bursts" of traffic.
Hey, this looks very well thought out to me. Big thanks! Unfortunately I can only give you a short reply, because I'm in a little bit of hurry. Some thoughts:
Sorry for my delayed response.
I think your logic for timing makes sense. I'll start to work on updated code with this definition for --timeout
:
--timeout <time>
where <time>
is an integer number of microseconds, "usec". (not milliseconds)
<time>
usec if the Ethernet frame becomes full or the maximum count (see --count
) of CAN messages has arrived.examples:
--timeout 0
means no waiting, immediately pack and send the CAN frame in a 1722 frame.--timeout 700
means wait no longer than 700 usec from the arrival of the first CAN frame to start the 1722 frame transmission process. --timeout
is given, then the 1722 frame will be launched when one of these is true:
<count>
number of messagesHi,
don't worry take your time. Only thing I'd change is to set the default timeout to 0 instead of 2^32-1 because then it could happen that a single CAN frame gets delayed for a very long time. I fear some users could interpret this as a bug if they don't study the documentation first.
If you need any help or feel stuck at some point let me know.
Regards Adriaan
Based on comment from @JLPLabs we should consider adding support to aggregate multiple CAN frames into a single Ethernet frame.