Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CommError during soft_reset and init #5

Open
TheButlah opened this issue Jan 23, 2023 · 0 comments
Open

CommError during soft_reset and init #5

TheButlah opened this issue Jan 23, 2023 · 0 comments

Comments

@TheButlah
Copy link

TheButlah commented Jan 23, 2023

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant