python-can-isotp
python-can-isotp copied to clipboard
stmin is wrong at least on windows.
So I got a lot slower transfer than I expected I did a quick hack to busy wait to get something much more like what the stmin time should be. Not sure what a proper solution really is. maybe the code as is works fine under linux.
$ git diff -w
diff --git a/isotp/protocol.py b/isotp/protocol.py
index 1acd21b..d2d041c 100755
--- a/isotp/protocol.py
+++ b/isotp/protocol.py
@@ -826,6 +826,10 @@ class TransportLayer:
pass # Nothing to do. Flow control will make the FSM switch state by calling init_tx_consecutive_frame
elif self.tx_state == self.TxState.TRANSMIT_CF:
+ while not self.timer_tx_stmin.is_timed_out() :
+ #print(f"timer_tx_stmin active elaspsed = {self.timer_tx_stmin.elapsed()}")
+ pass
+
if self.timer_tx_stmin.is_timed_out() or self.params.squash_stmin_requirement:
data_length = self.params.tx_data_length-1-len(self.address.tx_payload_prefix)
msg_data = self.address.tx_payload_prefix + bytearray([0x20 | self.tx_seqnum]) + self.tx_buffer[:data_length]
What is the issue? You posted a solution with no problem
Well I got slow transfer. that was the problem. the interpacket delay that stmin is setting get WAY longer than intended. this "hack" makes the delay be what stmin is set to.
I needed to set stmin to slow the transfer down as it was to fast for the receiving end but setting it to ANY value added a huge delay and when that hapens on every packet it gets very slow.
the problem is probably someplace else as the code "looks" ok but i had to add this busy wait to be able to control stmin when actually running the code.
This issue is long known. isotp v2.x is under development. Preliminary results shows that better results can be achieved with blocking reads. Still not perfect, but significantly better.
left = isotp v1.x right = isotp v2.x
(ignore initial delay that is longer)
I am closing this issue as it is a duplicate of many other. Timing subject is being handled in v2.x (yet to be released)