Scott Main [Tue, 8 Dec 2020 02:04:52 +0000 (18:04 -0800)]
Support pin names in RPI style for Coral boards
This should allow code compatibility across boards when using the
"D#" names, as per the Raspberry Pi header.
This also renames several pin names for the Mini so they actually match
the datasheet pin names. (Previously, I mistakenly used pin names
from the original Dev Board.) These renames are safe at this point
because the Dev Board Mini has not shipped yet.
Scott Main [Fri, 4 Dec 2020 20:09:22 +0000 (12:09 -0800)]
Add timout loop after exporting the PWM pin.
This gives udev time to respond to the device event. Without this,
the subsequent attempts to modify pin properties will fail when
depending on udev rules to apply new user permissions.
This code is essentially copied from python-periphery, as was most
of this file (both MIT licenced). Although it appears sergeev added
this loop recently, compared to when this code was originally cloned.
Scott Main [Fri, 4 Dec 2020 20:09:22 +0000 (12:09 -0800)]
Add timout loop after exporting the PWM pin.
This gives udev time to respond to the device event. Without this,
the subsequent attempts to modify pin properties will fail when
depending on udev rules to apply new user permissions.
This code is essentially copied from python-periphery, as was most
of this file (both MIT licenced). Although it appears sergeev added
this loop recently, compared to when this code was originally cloned.
Scott Main [Fri, 4 Dec 2020 20:09:22 +0000 (12:09 -0800)]
Add timout loop after exporting the PWM pin.
This gives udev time to respond to the device event. Without this,
the subsequent attempts to modify pin properties will fail when
depending on udev rules to apply new user permissions.
This code is essentially copied from python-periphery, as was most
of this file (both MIT licenced). Although it appears sergeev added
this loop recently, compared to when this code was originally cloned.
Scott Main [Fri, 4 Dec 2020 20:09:22 +0000 (12:09 -0800)]
Add timout loop after exporting the PWM pin.
This gives udev time to respond to the device event. Without this,
the subsequent attempts to modify pin properties will fail when
depending on udev rules to apply new user permissions.
This code is essentially copied from python-periphery, as was most
of this file (both MIT licenced). Although it appears sergeev added
this loop recently, compared to when this code was originally cloned.
Scott Main [Fri, 4 Dec 2020 20:09:22 +0000 (12:09 -0800)]
Add timout loop after exporting the PWM pin.
This gives udev time to respond to the device event. Without this,
the subsequent attempts to modify pin properties will fail when
depending on udev rules to apply new user permissions.
This code is essentially copied from python-periphery, as was most
of this file (both MIT licenced). Although it appears sergeev added
this loop recently, compared to when this code was originally cloned.
Michael Lass [Fri, 30 Oct 2020 22:57:10 +0000 (23:57 +0100)]
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.
projects / Adafruit_Blinka-hackapet.git / log