Initial machine.Pin output latch state

Question

I'm trying to control a Pin in MicroPython which must operate as an open collector (i.e. float or drive low). I must never drive it high (the XBee3 is running a slightly higher voltage than the connected device). Sadly, I can't simply set the pin state to OPEN_DRAIN as this mode is not supported.

From the MicroPython documentation for Pin (referenced from the XBee3 MicroPython manual) when setting a value() on an input:
The value is stored in the output buffer for the pin. The pin state does not change, it remains in the high-impedance state. The stored value will become active on the pin as soon as it is changed to Pin.OUT or Pin.OPEN_DRAIN mode.

This is not possible as setting a value whilst in Pin.IN module, results in an error.

The only options I see presently are:
1) switching to output mode 'appears' to default the latch to 0, but this is not documented/certain.
2) the Pin constructor does permit a value to be set together with the mode change, so I could create a new Pin every time I need to change state
3) Use AT commands to change IO states

Am I missing something with Pin or is this a non-compliance/bug in the implementation?

Cheers, Ross

Answer 1

Since the MicroPython Pin object builds upon the XBee's model of pins controlled via AT commands, it doesn't currently support open drain.

I can confirm for you that setting the mode to output defaults to "output low" unless the pin is already configured for "output high". So switching from input (high-impedance state) to output will always be low, which should give you what you need.

When doing the initial pin configuration, you'll probably want to enable the pull-up with the pull=Pin.PULL_UP keyword parameter.

Answer 2

Thanks Tom, that makes a lot of sense. I'd not considered the relationship to the commands, but I do see why Digi have chosen to implement the parts of the Pin API as they have, given the AT commands available.

Why did you suggest a pull up? Just because this is open drain logic or another reason? The slave device takes care of the 'pull up' in my case. In fact, it's a little more complex and is a signal that oscillates but sits around 1V (the pin is multi-function). This raises an additional question though...

While the XBee pin might be high impedance when set to input, it still has a digital input buffer engaged. Generally they don't like this kind of voltage. I'm not sure if I've read whether the XBee3 IOs are schmitt-triggers although I'd guess they probably are for this kind of product (and the 0.3Vcc/0.7Vcc spec). I've chosen however to set the pin to ADC rather than input, which I assume will deal with this issue (but is only available on some pins).

Cheers, Ross