Bitbangio vs Busio

[cefn]

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.

[dhalbert]

This seems fine to me. busio is hardware-only and pin-dependent on our own ports. If you give pins that won't map in hardware to usable SERCOMs and their limited pin choices, then you get an "Invalid pins" error. The only exception is that busio.OneWire is just an alias for bitbangio.OneWire.

[ladyada]

yup agreed!

[tannewt]

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.

[makermelissa]

Closing as it is not clear that there is anything left to do on this issue.