RFC: Hardware API: finalising machine.I2C

[deshipu]

@pfalcon Also, please feel free to provide counter-examples that show that there shouldn't be a unified way to send the slave address and R/W bit over the I²C bus. You can add them to the same issue, so that everything is in one place.

[deshipu]

This introduces another problem: the behavior becomes unpredictable, changing depending on the order in which the peripherals are initialized, and (especially in the REPL) depending on what other commands have been issued. For instance, if you have a peripheral P1 that can work on pins 1 and 2, and P2 that can work on pins 1 and 3, then one of the two programs, P(1),P(2) or P(1),P(3) will not work, for no apparent reason, while the other will work fine. Add to that your context managers and only initializing the peripherals right before you use them (as the context managers encourage you to do), and you have pure chaos, with random failures.

Yes, the underlying peripheral use would change depending on initialization order. However, it wouldn't be for no apparent reason. The exception you throw can explain the issue just like if you provided a peripheral ID that can't output on the pins you give it.

I'm not sure how you can extrapolate to chaos and random failures. Its a deterministic scheme that simplifies the initialization in most cases.

Consider a program, that only initializes the peripherals when it first needs them, based on what the user selects from the user interface. For instance, a weather station that has a temperature sensor, a humidity sensor and a wind speed sensor. The user can select any two measurements to be displayed on the screen. Depending on the order in which those are selected, the program will crash or not.

[tannewt]

Consider a program, that only initializes the peripherals when it first needs them, based on what the user selects from the user interface. For instance, a weather station that has a temperature sensor, a humidity sensor and a wind speed sensor. The user can select any two measurements to be displayed on the screen. Depending on the order in which those are selected, the program will crash or not.

Good point! I hadn't thought of a user interaction as a source of randomness. I'd propose providing the peripheral to use as optional (not first argument) and default to auto rather than a specific peripheral. I wouldn't expect the peripheral ids to port across either.

[dhylands]

I think that the pin objects should be optional.

For example, under linux/unix if you use the builtin I2C busses, then you can't specify a pin, and anything you tried to specify as a pin would be ignored.

It might be possible to use a bit-banged I2C from userspace under linux, but it certainly wouldn't be recommended.

What prompted this was that I started thinking about implementing machine.I2C for the unix port (as per @pfalcon's request elsewhere).

[deshipu]

So I went and tried to implement the I2CEndpoint in Python, and stumbled upon some questions:

• Would it make sense to merge the reg_write and reg_read into just reg with an optional value (doing a write when the value is specified, otherwise doing a read), similar to how it is done in many places in MicroPython already?
• Should we have separate reg8, reg16 and perhaps even reg32 methods?
• If not, should there be a size/type argument? Maybe something similar to what struct uses -- a single letter?
• If not, what should be the size?
• (I've used devices that have both 8 and 16-bit registers, and some of them require the 16-bit registers to be read in a single atomic transaction.)
• Also signed or unsigned?

[dhylands]

(I've used devices that have both 8 and 16-bit registers, and some of them require the 16-bit registers to be read in a single atomic transaction.)

I happen to be playing with one of those right now. The TI TMP006 temperature sensor has several 16-bit registers at register addresses that differ by 1.

[kfricke]

+1 for multi-byte commands (registers and send/receive)