So far we assumed that if a device made it out of the passive device manager, it must be a LUMP device.

There may be other categories of active sensors that need a background process, so prepare for it now.

Reset isn't implemented here, so we don't need this argument.

Start off with a basic implementation. This is not async-compatible yet.

We used to turn power off only at the end of active sensor processes as well as at the end of a program. In general, we want to turn power off whenever something is disconnected, which is what we do here.

The goal here is to be able to turn off 9V to a sensor if a user has switched it on and then unplugs the device.

This is only an indentation change with continue replaced by returning success.

This thread should wait for a connection and then wait until disconnected. The outer sensor port loop will run this again instead.

This allows us to handle things like port reset in the outer sensor loop. This ensures 9V power is turned off once a device is unplugged, for example.

This will automatically turn off when unplugged.

Also supports async API.

This replaces the smbus version for ev3dev. Some missing methods will be reinstated in future commits.

This way we don't need to add the `max_read_size` parameter and only allocate as much as we need.

These are wrappers around write_then_read for backwards compatibility.

It appears that this was left on by accident.

A user could inadvertently make another async I2C request, but we don't allow this if another operation is ongoing. So we shouldn't override the state in this case.

Since this already deals with nxt quirks, include the required delay between operations too. This simplifies higher level code common to all I2C Sensors.

Creating duplicate async functions in Python for every method is not very nice. We can instead define callbacks to map bytes to relevant data when the operation completes.

Instead of having the driver memcpy it, let the caller handle it so it can do it after allocation. This also means we don't have to allocate bytes objects at all for most sensor methods in the nect commits.

We no longer need a double allocation just to shift the write data.

We've been gradually introducing this pattern for newer classes, so be consistent about it.

Allows sensor definitions to have an I2DDevice instance with awaitable operations with a result mapped to objects.

Given the firmware size limitations on NXT, using Python wasn't going to be scalable. With the recent changes to the I2CDevice implementation, we can use instances of it for sensor classes written in C.

This reverts commit a37f46f756cd8453ff8f99193263ac68f9b5a057.
This is reverted instead of dropped so we maintain the logic to import Python classes into the C module in git history for future reference.

This is commonly used for LEGO-style I2C device classes.

Also simplify passing in address to I2CDevice object creator.

Split out setting defaults to a separate function so we don't have to call it recursively.

Also make the comments about the quadrature mode never changing more explicit.

The original read/write were deemed generic enough. See #379

This is sufficient for most operations and more sensible for NXT. Larger amounts of data can still be written by prefxing the register in the user code.