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
I'm using an esp32c3 (which has support for a small amount of non-configurable clock stretching currently). When sending commands to the bno, it is normal/commong for the bno to take some time to be ready to respond. The bno will signal via the interrupt pin when the host mcu should read for data. However, this driver immediately attempts to read from the bno without checking the interrupt pin, resulting in a failed read (typically via a nack, but sometimes via an i2c timeout, presumably due to the lengthy clock stretching the bno employs).
If the driver provided an optional interrupt pin, this pin could be checked to determine if a read is possible. If the pin is unspecified, the driver could instead fall back to reattempting the read, several times until a specified timeout.
I will need to implement support for this feature in my firmware but I would ideally like to avoid a hard fork of this driver. I wanted to know:
Is there interest in accepting a PR for this functionality?
Do you have a preferred strategy for me to do that, so that I know before implementing it and are more likely to get it merged.
The text was updated successfully, but these errors were encountered:
I'm using an esp32c3 (which has support for a small amount of non-configurable clock stretching currently). When sending commands to the bno, it is normal/commong for the bno to take some time to be ready to respond. The bno will signal via the interrupt pin when the host mcu should read for data. However, this driver immediately attempts to read from the bno without checking the interrupt pin, resulting in a failed read (typically via a nack, but sometimes via an i2c timeout, presumably due to the lengthy clock stretching the bno employs).
If the driver provided an optional interrupt pin, this pin could be checked to determine if a read is possible. If the pin is unspecified, the driver could instead fall back to reattempting the read, several times until a specified timeout.
I will need to implement support for this feature in my firmware but I would ideally like to avoid a hard fork of this driver. I wanted to know:
The text was updated successfully, but these errors were encountered: