Description
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.