micropython / micropython-esp32

Old port of MicroPython to the ESP32 -- new port is at https://github.com/micropython/micropython
MIT License
673 stars 216 forks source link

Soft SPI GPIO pin direction issue #189

Closed MrSurly closed 6 years ago

MrSurly commented 6 years ago
import machine
Pin = machine.Pin

def x():
    rst = Pin(15, mode = Pin.OUT)
    cs = Pin(2, mode = Pin.OUT)

    mosi = Pin(14, mode = Pin.OUT)
    miso = Pin(12, mode = Pin.IN)
    sck =  Pin(13, mode = Pin.OUT)

    s = machine.SPI(baudrate = 100000, sck = sck, mosi = mosi, miso = miso)
    return s

def y():
    rst = Pin(15)
    cs = Pin(2)

    mosi = Pin(14)
    miso = Pin(12)
    sck =  Pin(13)

    s = machine.SPI(baudrate = 100000, sck = sck, mosi = mosi, miso = miso)
    return s

Calling x() returns an object that works as expected. Calling y() returns an object that doesn't actually work.

This is because mp_pin_make_new only calls machine_pin_obj_init_helper if there are parameters, and in turn machine_pin_obj_init_helper calls gpio_pad_select_gpio.

extmod/machine_spi.c (which has the code for soft SPI) will call mp_hal_pin_output, but since this does not result in any calls to gpio_pad_select_gpio, the pin isn't actually configured as GPIO.

Is it safe to assume that the intent mp_hal_pin_output is to actually make subsequent calls to mp_hal_pin_write work? If so, should I make changes to mphalport.h? Essentially add a call to gpio_pad_select_gpio to mp_hal_pin_output.

nickzoic commented 6 years ago

Right, I see what you mean. mp_hal_pin_output calls gpio_set_direction but not gpio_pad_select_gpio. It does seem pretty reasonable to me that if you set a pin to be an output, it's because you want it to output stuff.

dpgeorge commented 6 years ago

Fixed by above PR.