This commit makes sure that functions in usb.core.Device return as
soon as they raise a MicroPython exception rather than continuing
on with whatever code would normally run. This will hopefully help
to avoid things like dereferencing null pointers.
shared-module/usb/core/Device.c had several spots where it would
raise a MicroPython exception with a NULL argument. That made it
very difficult for CircuitPython code to attempt to recover from
fault conditions caused by quirky USB device behavior. This adds
short error strings to distinguish the different types of faults.
- Starts with @tannewt's changes.
- Make sure proper component is being compiled.
- Added `I2C.probe()` as a visible new method. This was a hidden common-hal method, but the C version of adafruit_bus_device could not use it because it needs to call probe via a Python method call. So make it visible. It's useful, and `I2C.scan()` could be phased out, since now `.scan()` can be implemented in Python with `.probe()`.
- set clock-stretching timeout on espressif to a minimum of 1 second. In all impls of busio.I2C()`, the timeout is ignored and is set to a fixed 1 second. @tannewt's new code was using the passed-in value, which was often too short.
To do:
- switch esp-camera to new-driver version. We have to use the same I2C driver everywhere.
- Check about I2CTarget.
Make busio.I2C use finalizers for reset instead of bulk reset. This
makes it easier to track and free the memory that the IDF allocates
internally for its "handle".
Extend the bitfields of these instructions: BitmapHandle, ClearTag, Tag, BitmapSource, PaletteSource
Add instructions: BitmapSourceH PaletteSourceH
All the new bits and opcodes are ignored by earlier hardware, so this change is backwards-compatible.
Passes tests on all EVE hardware.
The setmodel() method controls the behavior
So existing code will continue to work unchanged
Subsequent releases of the ``eve`` library will call setmodel() to enable the new behavior
Confirmed all code paths on EVE hardware
Now, try_lock (SPI & I2C) & begin_transaction (display bus core) will check
that the related objects are still valid first; if they are not,
the lock/begin transaction will fail by returning false, rather than
"other things" such as raising a Python exception where it is not
permitted, accessing invalid memory, etc.
Closes#8278 and Closes#9426
