RFC: Hardware API: finalising machine.Pin

[deshipu]

Thank you for clarification. It would be nice to add a short note in the other thread too, for the users who don't follow the whole forum, but only subscribed to that, and for future users who find that thread and wonder about the status.

[chrismas9]

pin.value() is undefined for PIN.OUT and when PIN.OPEN_DRAIN is low but defined when it is open drain high (floating).

I use open drain pins in various ways including wire OR'd busy/ready synchronising between multiple devices, bidirectional multidrop 1 pin serial links and soft I2C. In many cases it is useful to be able to use pin.value() to know the pin state whether it is being driven low by the internal driver or an external driver. With the current implementation of pin.value() you have to first test if you are driving the pin before reading it which is an unnecessary code complication.

I have not seen any physical MCU port schematic that follows these rules. I have only found two types of port:

1. Some older small memory MCU's (eg some MSP430's) only have a single pin read register. It reads the pin in input mode and the output register in output mode. They do not support the PIN.OPEN_DRAIN requirement:

if the pin is in state ‘1’, the method returns the actual input value currently present on the pin.

but this can be emulated by switching the in/out mode to emulate open drain.

2. All other MCU's including all 256k+ MCUs I have found that are suitable for MicroPython have a separate read registers for the output drive register (pin.out_value) and the actual pin (pin.value).

So I see no need for pin.value to ever be undefined. It is usually fully supported by the MCU port logic, or needs emulation anyway.

Is there a valid reason for the pin class spec to not define pin.value() when the pin is driven? The only reason I can think of is that the type 1 MCUs can't actually read their pins I output mode, but I think emulation is ok and will always return the correct value unless the pin is short circuited or overloaded.

I think it would be better for the machine API to support all the hardware features of modern MCUs and emulate them on a few older parts than not provide a feature because it's not universally supported in hardware.

I have seen code like this for pin toggle: pin.value(not pin.value()). According to the machine API tis wouldn't work as pin.value() is undefined.

[pythoncoder]

@chrismas9 Good points.