[Kinda SOLVED] Get mode on machine.Pin

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
Post Reply
yeyeto2788
Posts: 28
Joined: Wed Mar 30, 2016 4:09 pm

[Kinda SOLVED] Get mode on machine.Pin

Post by yeyeto2788 » Fri Mar 02, 2018 1:53 pm

Hello guys,

I'm trying to develop a class to use on the Witty Cloud (ESP8266 based board) to have "everything" within it so I can just call desired methods to do what I want.

the code is hosted here > https://github.com/yeyeto2788/MicroPyth ... WittyUtils

Quick explanation:

I have some methods but the reason why I'm opening this topic is because in the methods

Code: Select all

clear_leds
and

Code: Select all

set_led_value
I'm using the same pin if I want to.

Here you have the methods code:

Code: Select all

@classmethod
    def clear_leds(cls):
        for pin in cls.pins['leds'].values():
            if pin != cls.pins['leds']['builtin_led']:
                machine.PWM(machine.Pin(pin)).deinit()
                machine.Pin(pin, machine.Pin.OUT).off()
                
@classmethod
    def set_led_value(cls, strled, intduty):
        if strled in cls.pins['leds'].keys():
            machine.PWM(machine.Pin(cls.pins['leds'][strled]), freq=500).duty(intduty)
So in the

Code: Select all

clear_leds
method I want to check whether the pin is being used as PWM so I can

Code: Select all

deinit()
that exactly pin.

I have seen documentation for the wipy and it seems to have a

Code: Select all

mode
method for the

Code: Select all

pin
class, so I want to retrieve the mode the pin is being used. If is an OUTPUT, INPUT or even PWM.

Anyone that could help me out?
Last edited by yeyeto2788 on Wed Mar 14, 2018 1:44 pm, edited 1 time in total.

cefn
Posts: 230
Joined: Tue Aug 09, 2016 10:58 am

Re: Get mode on machine.Pin

Post by cefn » Fri Mar 02, 2018 10:51 pm

I can't give you a direct answer to your question. I suspect that mode() doesn't work that way (as you can see from the mode value available in the Pin constructor, PWM isn't one of the possible values - it would just be an Output in terms of mode).

http://docs.micropython.org/en/v1.9.3/e ... e.Pin.html

The way you use PWM and Pin are surprising and I am not sure they behave as you expect. Using them differently would help you.

First of all, I think you are expected to create a Pin when you want to use it, and keep the reference as long as the Pin is in use. It isn't just a wrapper for an id, which is then intended to be thrown away after every line. As you can see from the Pin#__init__() method there can be side effects from every call to the Pin constructor (including all of the default values which get set if they are not explicitly specified in the Pin() call).

Similarly, a PWM isn't intended to be created just to issue a single PWM-related request and then be thrown away, it is an object representing a specific function which has been allocated to a pin, and should be kept around as long as that function remains allocated to the pin, and especially if you plan to reinitialise or manipulate that function.

If you want to keep a map of inputs, outputs and pwms, then I suggest to create a dict of tuples, indexed by pin id and keep the references in there, with some metadata which helps you recall what function was allocated.

The first item of the tuple could be the reference to the Pin object, which is created ONCE when a pin is allocated a specific function. Following items should be data structures detailing previous configuration which has been made of the pin. You could put the PWM in there, or perhaps a mode value, or whatever else suits you to be able to recover relevant prior information about configuration. Obviously this structure can be managed lots of ways, but
  • there is only one place to look for a pin's function - not under multiple headings - "led", "input", "output",
  • a Pin is only created once, is stored, and has its functions manipulated later
  • similarly any PWM is only created once, is stored, and has its functions manipulated later
Since all configuration would have been done by your own code, you don't need to rely on some other built-in record to retrieve this information from the micropython API, it will be in your managed dict.

That way, when you seek to switch a pin from one function to another, you can look up in your dict to see what function it was previously allocated, and use the Pin and or PWM reference directly to change its configuration (e.g. using pin.init()) or to undo prior operations, (for example calling deinit() on a previously created PWM).

If you were to artificially populate the dict structure (rather than populating by pin-function allocations one-by-one as in the real class, it might look like this pseudocode (sorry for any errors I haven't got a module to run this on right now)...

Code: Select all

from machine import Pin, PWM
MYIN = 0
MYOUT = 1
MYPWM = 2
pinRef4 = Pin(4, mode=Pin.OUT)
pinRef5 = Pin(5, mode=Pin.IN)
pinRef6 = Pin(6, mode=Pin.Out)
pwmRef6 = PWM(pinRef6)
WittyBoard.lookup = dict(
    4=(pinRef4, MYOUT),
    5=(pinRef5, MYIN),
    6=(pinRef6, MYPWM, pwmRef6)
)
You can see how this data structure can allow you to save and retrieve the Pin and (sometimes) PWM references, and query previously allocated functions.

yeyeto2788
Posts: 28
Joined: Wed Mar 30, 2016 4:09 pm

Re: Get mode on machine.Pin

Post by yeyeto2788 » Mon Mar 05, 2018 12:31 pm

cefn wrote:
Fri Mar 02, 2018 10:51 pm
I can't give you a direct answer to your question. I suspect that mode() doesn't work that way (as you can see from the mode value available in the Pin constructor, PWM isn't one of the possible values - it would just be an Output in terms of mode).

http://docs.micropython.org/en/v1.9.3/e ... e.Pin.html

The way you use PWM and Pin are surprising and I am not sure they behave as you expect. Using them differently would help you.

First of all, I think you are expected to create a Pin when you want to use it, and keep the reference as long as the Pin is in use. It isn't just a wrapper for an id, which is then intended to be thrown away after every line. As you can see from the Pin#__init__() method there can be side effects from every call to the Pin constructor (including all of the default values which get set if they are not explicitly specified in the Pin() call).

Similarly, a PWM isn't intended to be created just to issue a single PWM-related request and then be thrown away, it is an object representing a specific function which has been allocated to a pin, and should be kept around as long as that function remains allocated to the pin, and especially if you plan to reinitialise or manipulate that function.

If you want to keep a map of inputs, outputs and pwms, then I suggest to create a dict of tuples, indexed by pin id and keep the references in there, with some metadata which helps you recall what function was allocated.

The first item of the tuple could be the reference to the Pin object, which is created ONCE when a pin is allocated a specific function. Following items should be data structures detailing previous configuration which has been made of the pin. You could put the PWM in there, or perhaps a mode value, or whatever else suits you to be able to recover relevant prior information about configuration. Obviously this structure can be managed lots of ways, but
  • there is only one place to look for a pin's function - not under multiple headings - "led", "input", "output",
  • a Pin is only created once, is stored, and has its functions manipulated later
  • similarly any PWM is only created once, is stored, and has its functions manipulated later
Since all configuration would have been done by your own code, you don't need to rely on some other built-in record to retrieve this information from the micropython API, it will be in your managed dict.

That way, when you seek to switch a pin from one function to another, you can look up in your dict to see what function it was previously allocated, and use the Pin and or PWM reference directly to change its configuration (e.g. using pin.init()) or to undo prior operations, (for example calling deinit() on a previously created PWM).

If you were to artificially populate the dict structure (rather than populating by pin-function allocations one-by-one as in the real class, it might look like this pseudocode (sorry for any errors I haven't got a module to run this on right now)...

Code: Select all

from machine import Pin, PWM
MYIN = 0
MYOUT = 1
MYPWM = 2
pinRef4 = Pin(4, mode=Pin.OUT)
pinRef5 = Pin(5, mode=Pin.IN)
pinRef6 = Pin(6, mode=Pin.Out)
pwmRef6 = PWM(pinRef6)
WittyBoard.lookup = dict(
    4=(pinRef4, MYOUT),
    5=(pinRef5, MYIN),
    6=(pinRef6, MYPWM, pwmRef6)
)
You can see how this data structure can allow you to save and retrieve the Pin and (sometimes) PWM references, and query previously allocated functions.
Thank you very much for that explanation, it was really helpful for me and I could understand a bit better.

I have modify the code to store the 'mode' the pin is currently set to.

You can see modifications in here: https://github.com/yeyeto2788/MicroPyth ... WittyUtils

Post Reply