machine.Pin methods?

[Capstan]

I'm trying to determine what subset of the methods that might be available in the Pin class are actually implemented for the esp8266.

Here I am seeing quite a few for the pyBoard;
https://docs.micropython.org/en/latest/ ... b.Pin.html

But I am finding that many do not work for the 8266. In particular I am trying to find out which pin was responsible for generating an interrupt on a rising or falling edge. In this code, for example, the callback function will receive pObj as an argument;

pin = 12
pObj = Pin(pin, Pin.IN)
pObj.irq(trigger = Pin.IRQ_FALLING, handler = callback)

def callback(pinObject)
print(pinObject) # would be indented of course

This results in the following being printed;
Pin(12)

What is the appropriate way to get the pin number out of Pin so I can see which pin generated the interrupt?

pinObject.__str__()
AttributeError: 'Pin' object has no attribute '__str__

pinObject.pin()
AttributeError: 'Pin' object has no attribute 'pin'

[dhylands]

You should be able to do

Code: Select all

dir(machine.Pin)

to see all of the available attributes (which includes functions and constants).

[deshipu]

I think a pin has an "id" method that you can call to get its number.

[Capstan]

>>> dir(machine.Pin)
['init', 'value', 'low', 'high', 'irq', 'IN', 'OUT', 'OPEN_DRAIN', 'PULL_UP', 'IRQ_RISING', 'IRQ_FALLING']

So yeah, a pretty small subset of the pyBoard implementation. I found that, as a workaround, when I set up an IRQ I have to put an entry into a dictionary that is the Pin object keyed by the pin number. Then when the interrupt gets triggered I have to iterate through the dictionary looking for the reported Pin object value, and the key for that is the pin number. Awkward.

[dhylands]

irq functions can also be class methods. Then you can store any addtional information you want in the instance.

Here is an example (albeit for the pyboard) which demonstrates this: https://github.com/dhylands/upy-example ... eat_irq.py

[SpotlightKid]

Or you can use the partial function from functools to bind some data (e.g. the pin number) to the callback:

Code: Select all

from functools import partial
from machine import Pin

def cb_func(pin_no, pin):
    print(pin_no, pin)

pin_no = 12
pin = Pin(pin_no, Pin.IN)
pin.irq(trigger=Pin.IRQ_FALLING, handler=partial(cb_func, pin_no))

[Capstan]

>>> from functools import partial
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: no module named 'functools'

[deshipu]

https://github.com/micropython/micropyt ... /functools

[SpotlightKid]

If you have a large number of pin callbacks, the class based approach might be more memory efficient. Using partial, you'll need memory for a function object, an empty dict for the kwargs and a tuple with one entry for the args for every callback you define, whereas with one class with a single callback method and an attribute mapping instances (or the hash(obj) value) to your data, you'll probably need much less. But I haven't actually measured it.

[scargill]

Well, while appreciating the fantastic amount of work that must've gone into this - I have to say this was not a good start for me.

I downloaded the latest software onto an ESP8266 and went off to the documentation here.

https://docs.micropython.org/en/latest/ ... /repl.html

Unless I'm missing the point - the official docs for the ESP8266.

and there it was, a simple example:

>>> import machine
>>> pin = machine.Pin(2, machine.Pin.OUT)
>>> pin.high()
>>> pin.low()

and it didn't work. No such thing as high and low.

I'm so glad I came here to notice the test to see what is available - dir(machine.Pin) .... not high and low but on and off. I happily tried:

pin.on()

Nothing - no light on the little board.

pin.off()

Wunderbar - the light came on - in other words the instructions are merely inverted and using the wrong methods.

So while this is great - it proves my board works... I'm wondering before I go further with this..

Is there an up to date document anywhere that actually DOES have working examples? Had I not stumbled on this page I might've assumed that there was something wrong.

I have to say.... I'm wondering if I DARE try I2c and SPI for fear or other "differences"? Anyone tried these on an ESP8266?