Skip to content

Inconsistent pin behaviour #1405

@dhylands

Description

@dhylands

I've run into an issue which I throught I would bring up, and see how to best go about solving it.
If I do:

pin = pyb.Pin('J12', pyb.Pin.IN)

Then I get a pin which has been run through the Pin type's make_new and init_helper function. If I do:

pin = pyb.Pin('J12')

Then I get a pin which has been run through the Pin type's make_new function, but not the init helper function. If I then try to query the pin's value, it always returns zero because the clock for that port hasn't been initialized. I can move the clock initialization to the make_new function to get around this.

However, I can also get a pin via:

pin = pyb.Pin.cpu.J12

and I get a pin from the dictionary in flash that hasn't been run through make_new and have the same problem. I can query the pin:

>>> pyb.Pin.cpu.J12
Pin(Pin.cpu.J12, mode=Pin.IN)
>>> pyb.Pin.cpu.J12.value()
0
>>> pin = pyb.Pin('J12', pyb.Pin.IN)
>>> pyb.Pin.cpu.J12.value()
1

For ports A-D, you can do the above and the first call to value() will return 1 because the clock is enabled.

My question is, do we want to resolve this inconsistency?
Should we consider raising an error on a pin that hasn't been initialized?
Or should we enable the clock?

Right now, when you ask for pyb.Pin.cpu.J12 you're getting a pin from a local_dict:
https://github.com/micropython/micropython/blob/master/stmhal/pin_named_pins.c#L43

By changing this to an attr and we could have the gpio clock enabled. Or we could throw an error if init hasn't been called yet, or we could do nothing.

So I just thought I'd throw this out for discussion.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions