-
Notifications
You must be signed in to change notification settings - Fork 332
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
Bitbangio vs Busio #3
Comments
This seems fine to me. |
yup agreed! |
Yeah, there is an exception to busio being hardware-only when no hardware exists. For example, ESP8266 busio.I2C is done in software because no hardware support is present on any pin. The goal is to minimize the chance of confusion about whether the protocol is implemented in hardware or software. |
…not available and remaining pins are I2S or PWM
Merge pull request #385 from twa127/master
Closing as it is not clear that there is anything left to do on this issue. |
In this issue, I would like to propose how bitbangio and busio should map into underlying hardware and software interfaces on Micropython-flashed mcus.
I propose that busio only proceeds without error when there is hardware accelerated backing to the pin choices made in the constructor, while bitbangio only proceeds when there is a capability for software implementations to be run. In either case if the platform or pin choices don't allow the corresponding implementation to be spun up, then an error should be raised.
This implies some fairly detailed mapping of pin choices to underlying hardware capabilities through platform introspection, but seems one of the few consistent ways of managing the wrapping.
There is an option for bitbangio to seamlessly ignore when it is opportunistically using hardware-backed io, rather than raising an Error, but to do this, it will end up just replicating the behaviour already in busio, largely undermining the separation, so I don't think this is ideal.
Substituting a software-bitbang I2C or SPI for a requested hardware-accelerated implementation definitely seems wrong otherwise what is the point of the package separation?
UART or other unclocked high-throughput interface, is going to be busio-only on e.g. an ESP8266 platform because of interrupts making a software implementation infeasible.
The text was updated successfully, but these errors were encountered: