WiringPi: Initial state of output. Bug?

[sorenfriis]

Hi there,

I have just begun writing some C++ programs for my pi(s) and am making use of GPIO's for activating a line of relays.
Since I want the program to run as non-root, I figured I could use wiringPi's export functionality.

Therefore I have this script which exports the GPIOs which I need

Code: Select all

for pin in 4 17 10 9 25 8 7 11; do
/usr/local/bin/gpio export $pin out
done

However, when doing this, all the IO's are set LOW, actively enabling all my relays, which in my case is unacceptable. (They trigger a beer vending machine...So free beer when rebooting.. not good for business:) )

I haven't been able to find a way where the export command does not force the exported output low.
I could set the output high immediately after, but it still triggers the relay briefly.

Am I missing something or is this a bug in wiringPi?

PS. I also tried controlling the I/O's using low-level C (OUT_GPIO). This requires root-access, but does not set the output low when initialising.

[sorenfriis]

This page guided me in the right direction.
http://www.domoticz.com/forum/viewtopic.php?f=11&t=2743

It turns out, that it is possible to set the mode as "high" also.
I.e.

Code: Select all

gpio export 0 high

This will act as an output, but stay high during the export.

[DougieLawson]

It's a quirk of the hardware, you could swap active low to active high with a transistor inverter on each one.

If the relays have change-over contacts (one set of NC contacts, one set NO contacts) then the easy way is to swap the wiring on the load side of the relays.

[sorenfriis]

If the relays have change-over contacts (one set of NC contacts, one set NO contacts) then the easy way is to swap the wiring on the load side of the relays.

Yep, I could do that, but that would mean drawing current through all the relay coils when the machine is idle.
And since I am driving 8 relays from the 5V output of the pi, I want to make absolutely sure that maximum 1 relay is active at a time to not exceed the capability of the pi's 5V out.

[Burngate]

Forgive me for butting in ...
I'm ignorant about C++ and WiringPi - I've only done this sort of thing in assembler - but you can write to the GPSETn or GPCLRn registers before setting the direction with the GPFSELn registers.
If I can do it in assembler, I'm confident the same is possible with WiringPi - set it high then make it an output

[FTrevorGowen]

You may also need to take note of the changed behaviour** when a GPIO is unexported:
viewtopic.php?f=44&t=99113
Trev.
** Back in late January with the use of the "Device Tree" etc.

[AndyD]

Is this relevant? - Changing the default pin configuration.

From my naive understanding, wouldn't it be possible to change he default states of the GPIO pins using a custom device tree blob?

[paulv]

With the advent of the "new" Device Tree, the default state of the GPIO pins is changed, because the pull-low is now activated. This makes sense. If the Pi is powerless, the pins are low, and when the Pi boots, they stay low, until you are in control and can change it.

If the pin would be left floating (no-pull) or set high, the connected hardware will see a change as soon as the Pi is powered up or when the VideoCore is programming the GPIO pins during the boot process. There can be a 20-30 second window of undetermined or possibly incorrect settings from power up until your application initializes the GPIO pins the way you want them to be. For anything other than probably an LED, this is undesirable and can lead to failures.

Even though the pull action is preserved over power cycles because that setting goes into EEPROM (or somethink like it), if set high, the pin action will still go from low at power off, to high at power on.
Unless your connected hardware uses the same power supply and does not get confused during the power up sequence, there are ample opportunities for a glitch. (If in doubt, use a scope)

IMHO, all GPIO pins should be programmed such that they are active high, and any connected hardware of serious nature should take this into account.
In that light, the recent change is not a bug, but a fix to a bug.

[jojopi]

With the advent of the "new" Device Tree, the default state of the GPIO pins is changed, because the pull-low is now activated. This makes sense. If the Pi is powerless, the pins are low, and when the Pi boots, they stay low, until you are in control and can change it.

That is not the behaviour I am seeing, nor would it be correct. With no SD card at all, several GPIOs are actually pulled high at power on; see Table 6-31 in the datasheet. The firmware similarly defaults to pulling these up, not down. Your convention of using active high logic only really works for the (majority) pins that default to pulled low.

When the board is unpowered, it does not make sense to say that the GPIOs are low. They are high-impedance with respect to both ground and "3V3".

Pull actions are not stored in EEPROM, and do not a survive a power cycle of more than a second or so. In practice they do not survive a reboot either, because older firmware disables them during boot, and newer firmware resets them to power-on state. (I believe some early device tree firmwares did leave pulls untouched, and it is arguable whether that was better.)

Anyway it is easy for external hardware to be immune to weak pulls, and we are getting well off topic. This thread was about what happens if you set a pin as an output without programming a level. Obviously it is not best practice to rely on that. Set the level explicitly, preferably before or at the same time as you set the mode, if the library allows that.

[paulv]

Pull-up/down actions of GPIO pins:
BCM2835-ARM-Peripherals.pdf: Page 100

The GPIO Pull-up/down Register controls the actuation of the internal pull-up/down
control line to ALL the GPIO pins. This register must be used in conjunction with the 2
GPPUDCLKn registers.
Note that it is not possible to read back the current Pull-up/down settings and so it is the
users’ responsibility to ‘remember’ which pull-up/downs are active. The reason for this is
that GPIO pull-ups are maintained even in power-down mode when the core is off, when
all register contents is lost.

You can easily check this by programming a GPIO pin with a pull high or low. Connect two 100K or so resistors from the GPIO pin to 3V3 and one to ground. Connect the GPIO pin to a scope or DVM, and you can see that the voltage will be about 1.6V when floating, about 3V3 when pulled high, and close to 0V when pulled low. I have observed that the pull-up/down setting (without a "cleanup" action) will survive a power cycle and will keep the setting for days, not seconds. In the firmware versions prior to July 15 2014, the general purpose GPIO pins were floating as default with the above method.

https://www.raspberrypi.org/documentati ... uration.md

As of July 15th 2014, the Raspberry Pi firmware supports custom default pin configurations through a user-provided device tree blob file.

The general purpose pins are programmed as follows in the dt-blob.dts file

Code: Select all

   videocore {
            pins_rev1 {
               pin_config {
                  pin@default {
                     polarity = "active_high";
                     termination = "pull_down";
                     startup_state = "inactive";
                     function = "input";

Please correct me if I'm missing something.

[joan]

The pull ups/downs revert to the documented state when powered up from a powered down state.

Contrary experiments so far have been because the Pi has not been powered down (battery still connected, HDMI monitor still connected, etc. etc.).

[paulv]

Joan,
I wrote a post more than a year ago, documenting my observations of the GPIO pin behavior differences at power-up and reboot and the effect of using or not using the GPIO.cleanup() command on both situations.

It seems I need to do my tests again with the latest version the firmware/software, because what I observed at the time was different.

After doing some tests, I humbly stand corrected. I verified that the pull indeed does not survive a power cycle, it only survives a Halted state or a Reboot.