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
Copy file name to clipboardExpand all lines: doc/source/isotp/implementation.rst
+15Lines changed: 15 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -252,6 +252,18 @@ The transport layer ``params`` parameter must be a dictionary with the following
252
252
253
253
Sets the name of the logger from the ``logging`` module used to log info and debug information
254
254
255
+
.. _param_wait_func:
256
+
257
+
.. attribute:: wait_func
258
+
:annotation: (callable)
259
+
260
+
**default: "time.sleep"**
261
+
262
+
Defines a waiting function used to create the necessary delay between consecutive frames during a transmission, dictated by the receiver STMin.
263
+
Expected signature is ``my_wait_func(delay:float) -> None``
264
+
265
+
Defaults value is the system ``sleep`` function, which can have a coarse granularity, depending on the scheduler policy.
266
+
255
267
-----
256
268
257
269
.. _rate_limiter_section:
@@ -407,6 +419,9 @@ Using the approach described above, a message can be read from the link-layer an
407
419
40us latency is far better than the latency caused by calls to ``time.sleep()`` required with v1.x. Considering that a CAN bus running at 500kbps has a message duration of about 230us,
408
420
the latency is in the acceptable range.
409
421
422
+
Finally, the delay between consecutive frames is dictated by a user-definable function passed with the :ref:`wait_func<param_wait_func>` parameter. By default, the wait function is the system ``sleep`` function.
423
+
On machines where the ``sleep`` function has a coarse granularity and a high resolution timer is available, it is possible to pass a busy-wait function to this parameter.
0 commit comments