GPIO from Python

Marcello

Would a typical Raspberry PI script that includes for example the following lines run ummodified?
And do what it is supposed to do?

import RPi.GPIO as GPIO
...
GPIO.setup(17, GPIO.IN, pull_up_down=GPIO.PUD_UP)
.....
GPIO.wait_for_edge(17, GPIO.FALLING)

Dan O'Donovan

Sorry for the late reply. We will be pushing some updates to our port of the RPi.GPIO module for UP, to fix some issues there.

Unfortunately, that script example above still won't work. The reason is this bit:
pull_up_down=GPIO.PUD_UP

Unlike the Raspberry Pi, the UP board doesn't have internal pull-up resistors which can be configured dynamically. So we are removing support for that option in our version of the RPi.GPIO library , which will cause that script to fail. If a pull-up resistor is needed on the GPIO input pin, it would need to be added externally (i.e. by physically connecting a pull-up resistor to the GPIO pin.

We will post here again when an update to the RPi.GPIO library has been published.

Marcello

Thanks for your reply. As I design the corresponding electronics myself, it is not an issue to modify the schematics and add pull-ups or whatever is needed.
However, I would need to know what is supported and what is not (e.g. Edge triggering?)
Also, upon reset / power up, is the state of the pins well defined?
Thanks for pointing me to the relevant resources!

Dan O'Donovan

Edge-triggering (rising/falling/both) is supported. High/low level triggering is also supported, but only useful within a kernel driver (this is a limitation of Linux).
GPIO performance is, unfortunately, about 10x slower than equivalent Raspberry Pi GPIO performance (a limitation of the GPIO controller design in the Cherry Trail SoC).
The pins are in high-impedence state initially after power-on, but a kernel driver will configure some of them as outputs later depending on what pin functions are enabled. For example, if the UART function is enabled, then the UART TX pin (8) will be configured as an output. Pin function is currently determined by the state of the associated controller. Taking the UART example again, if the relevant UART controller is enabled in the BIOS configuration menu (which it is by default), then the pin function for pins 8 & 10 is assumed to be UART; otherwise, GPIO input would be assumed by default. In other words, by changing BIOS settings, it is possible to have all GPIO pins configured as GPIO inputs by default after the OS boots up.

Marcello

dan wrote:

Sorry for the late reply. We will be pushing some updates to our port of the RPi.GPIO module for UP, to fix some issues there.

Unfortunately, that script example above still won't work. The reason is this bit:
pull_up_down=GPIO.PUD_UP

Unlike the Raspberry Pi, the UP board doesn't have internal pull-up resistors which can be configured dynamically. So we are removing support for that option in our version of the RPi.GPIO library , which will cause that script to fail. If a pull-up resistor is needed on the GPIO input pin, it would need to be added externally (i.e. by physically connecting a pull-up resistor to the GPIO pin.

We will post here again when an update to the RPi.GPIO library has been published.

Hello Dan,
Any news on the RPi.GPIO library ?
Any working version available / where?
thanks.

JAN

GPIO performance is, unfortunately, about 10x slower than equivalent Raspberry Pi GPIO performance (a limitation of the GPIO controller design in the Cherry Trail SoC).
Is this limitation valid in windows 10 iot

Dan O'Donovan

As far as I am aware, Windows 10 IoT is not available for the UP board at this time.

In general, I expect this performance limitation to be similar for all operating systems on the UP board, as it appears to be a limitation of the underlying Cherry Trail SoC hardware design (i.e. the time it takes to read a register on the GPIO controller).