Main Site Documentation

G400: Can the States of Digital Outputs be Set on Bootup?


#1

Is there a mechanism to preset the state of digital output pins to particular states so that those states are set immediately when the controller is turned on?

When I used the Netduino, there was a boot-up period of about 7 seconds before the digital outputs could be set which obviously causes serious problems when you have pneumatic actuators and solenoids hooked to those outputs.

I’d like to know how to deal with this issue on the G400. Thanks!


#2

You’ll have to use pull-up or pull-down resistors to set the initial state of an I/O pin. As far as I know, there’s no way around this.


#3

There is no mechanism for this as far as I know. We ran into similar problems on one project. (Using a G120)

We designed our driver electronics in a way, so the outputs stay low during bootup as long as the GPIO is not initialized.
You could also design an output which is high on bootup (inverted or not)

For safety critical movements we have chosen pneumatic valves which have stable states and are only triggered by a pulse in both directions, or are at the safe position when output is low.
This makes it even more save on power failure or similar exceptions.

Even if you do that you need to make sure that the firmware does not switch these outputs on bootup.
If a display is configured, the RGB pins will switch all the time until you initialize the pin in your app.
Fortunately with the latest FW the display is not configured anymore by default.


#4

To make sure of a start up state, you must use hardware pull up or pull down resistors. Thats the only way to guarantee this.


#5

Thank you all for your suggestions on the pullup/down resistors. Obviously, it’s not an ideal solution as it limits the flexibility of the system.

Is there any way for us (or GHI) to add some pre-boot C-code (perhaps via RLP or another mechanism) to set the IO? Is this a feature that GHI could add to their framework?


#6

For raptor (as for all premium boards) I think GHI would have to do so.
You could contact them via support/consulting according to that.
But I still think you should handle it in a different way. (electrically or pneumatically)
1st: there is always a ‘dead zone’ before pre code and pre pre code …
2nd: What happens to your pneumatic if power goes off?
It’s never safe to rely on the boot behavior of GPIO’s of a micro controller.

I would use bi stable relays or valves which are triggered by pulse to go in one or the other direction.
Then use a pull down resistor (or pull up if you have an inverting driver) on the GPIO to make sure you get no pulse before the GPIO is initialized.


#7

The pre boot code will still run sometime after booting so the default state is not set on power up. Typically, adding a simple resistor solves this really.


#8

Even where I can have control of the microcontroller registers to set the GPIO state (eg AVR devices), I would still use a pull up or pulldown resistor to ensure the hardware is where I want it during the boot cycle.


#9

Can you tell more about how flexibility is downsized using pull-up or puul-down résistors ?

In my case, i had to do the same will playing with relays to avoid access control doors to be opened when the box boot up…and it solved the problem…


#10

So with all this discussion about pullup/down resistors, it sounds like the GPIO are tri-stated (indeterminate) during bootup, correct? Then after bootup, the GPIO goes from tri-state mode to active mode and it uses the initialization settings in user code to set the states, so the outputs go from tri-state to the user-set values in one instant, right?

On the Netduino, the outputs all were driven low from the moment of power on, so pullups wouldn’t help.

@ LouisCpro: Flexibility is reduced with pullup/down resistors because if you need to rearrange output channels, you have to rearrange resistors in addition to modifying the code.


#11

Yes, if you consider that it can be, High (Pull_Up), Low (Pull_Down) or in the Air (No resistor)…Else No.

I’d rather say boot state then user state, as it is the default values you set in your program at the initialization step… but Yes.

OK, but what if I need them to be High at power on ? for Normally closed outputs for example…

OK, but is it not finally more flexible to be able to choose between 3 states regarding to your needs, instead of being imposed to use Low boot level and if you need High, you have to implement a negative logic to your output, which will also require some hardware and software ?

As for me, i did not make any change to the code. In any case, I put some init values to my outputs, and have a Pull-Up resistor that match my needs (in my case, it will avoid any status change during boot on the relays).