Skip to content

Add UART functionality to library #41

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

Closed
kattni opened this issue Oct 25, 2019 · 12 comments
Closed

Add UART functionality to library #41

kattni opened this issue Oct 25, 2019 · 12 comments
Assignees

Comments

@kattni
Copy link
Contributor

kattni commented Oct 25, 2019

The original Python library includes the ability to use UART with the BNO055. Please look into implementing UART in the CircuitPython library.

@ladyada
Copy link
Member

ladyada commented Oct 25, 2019

@dherrada hiya you recently did some hacking on this library so thought this could be a good one for you to do. the sensor has both i2c and uart. the old library had both, this library only has i2c but maybe we could add uart?

@caternuson
Copy link
Contributor

Looks like this will be interesting from a class layout perspective. Current library only has the one class for I2C. So did the old library, and determined I2C vs. UART based on what was used in constructor. That's different than most of the CP libraries that tend to have separate classes for each interface type.

@ladyada
Copy link
Member

ladyada commented Oct 25, 2019

im ok with a refactor to have two classes!

@caternuson
Copy link
Contributor

Cool. Refactor fun time! @dherrada Let me know if you're on this.

@evaherrada
Copy link
Collaborator

@caternuson Yep. I'll do it. I probably won't be able to get to it until after Nov. 1 (early decision deadline for V. Tech) but I'm definitely interested in learning about this and adding uart

@caternuson
Copy link
Contributor

@dherrada awesome. go for it.

@tannewt
Copy link
Member

tannewt commented Nov 1, 2019

Could we abstract UART, I2C and SPI away instead and have the driver deal with commands? I'd rather see something like the display buses where the driver doesn't care about the transport rather than having multiple classes.

@ladyada
Copy link
Member

ladyada commented Nov 1, 2019

yes we would abstract it like we do for BMx80 sensors or PN532 for an exciting look https://github.com/adafruit/Adafruit_CircuitPython_PN532/tree/master/adafruit_pn532

@tannewt
Copy link
Member

tannewt commented Nov 1, 2019

I'm thinking we'd have one driver class that takes in a standard wrapper for UART, I2C and SPI. I don't mean having a number of subclasses. I imagine there is a standard way to pack things over the different transports and by having an object to pass in, we can factor out the packing logic.

@ladyada
Copy link
Member

ladyada commented Nov 2, 2019

for i2c/spi you can do that kinda cause SPI chips tend to use a standard way to mimic i2c registers.
see
https://github.com/adafruit/Adafruit_BusIO/blob/master/examples/i2corspi_register/i2corspi_register.ino
uart tends to be a free-for-all, as its quite rare. we could try all the sensors with uart and then see if its generalizable

@kattni
Copy link
Contributor Author

kattni commented Apr 16, 2020

@caternuson If you have cycles for this, it's something that still needs to be done. Dylan is currently on other projects.

@caternuson
Copy link
Contributor

Done with #47

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

5 participants