]> Repositories - Adafruit_Blinka-hackapet.git/commit
Do not prematurely stop waiting for an answer from the message queue
authorMichael Lass <bevan@bi-co.net>
Fri, 30 Oct 2020 22:57:10 +0000 (23:57 +0100)
committerMichael Lass <bevan@bi-co.net>
Fri, 30 Oct 2020 23:24:25 +0000 (00:24 +0100)
commit4305b552ea1be7f6a5ef3e8ae2f027bab443012b
treeca7981c24c13bc1b796fbd2b3f9cee68623fa1df
parent510aedeac6fc618f73554b9303bafd57bec3a8b5
Do not prematurely stop waiting for an answer from the message queue

When requesting data from libgpiod_pulsein via the message queue, we
always expect an answer. Prematurely stopping to wait for an answer can
only do harm. If we do not read the expected answer from the mq, it will
stay there and be read (falsely) as an answer to the following request.

Example:

* We request a pulse length by sending '^'.
* Due to high system load, libgpiod_pulsein does not send a response in
  time.
* We timeout with a RuntimeError. This is verly likely ignored by the
  calling code since RuntimeErrors are thrown with every invalid
  reading such that the calling code _has to_ ignore these errors.
* We trigger a new sensor reading (pause-clean-resume).
* We request the length of the pulse buffer by sending 'l'.
* We read from the message queue. The response we get now is the
  response to our original '^' request. Let this response be 100.
* We now assume 100 elements in the pulse buffer. This is of course
  wrong and will lead to all sorts of errors.

The only reason to timeout on an expected answer is probably during
initialization when we are not sure if the communication via message
queue has been successfully set up. In all other cases we should just
block and never timeout.
src/adafruit_blinka/microcontroller/bcm283x/pulseio/PulseIn.py