Not to forget to consider the time between reset and first init. Default
pin state mostly is input floating, or input weak pull-up.

Don't let big bang happen that early.

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Nathan Hartman <hartman.nat...@gmail.com> schrieb am So., 19. Feb. 2023,
13:13:

> On Sat, Feb 18, 2023 at 11:48 PM Tomek CEDRO <to...@cedro.info> wrote:
>
> > Hello world :-)
> >
> > I am working on a pretty industrial automation project right now that
> > will control 3 phase motor over 400V/25A relays.
> >
> > There are 6 relays to provide all possible modes of 3 phase motor
> > control. There are 3 groups of two relays for a task like direction
> > change, star-left-star-right, and star-triangle switch. Each two of
> > the relays in the group will have exclusive control (i.e. when one is
> > on the other will have control cut off). But there groups are not
> > fully exclusive physically due to their function. So when all three
> > groups are turned on then big bang happens :-)
> >
> > I am still wondering how to protect against this big bang. For sure I
> > will add some physical protection so this situation is impossible
> > (i.e. some sort of logic between GPIO and relays where only one line
> > will indicate possible safe operation state of all relays, while zero
> > or more than one line set high will always result in a safe state).
> >
> > This lead me to think of the initial state of the ESP32 GPIO pins
> > after boot then after NuttX starts.. or when device will be in
> > bootloader / flashing state.. in case of malfunction.. or malicious
> > actions (it might be connected to the internet somehow).. or simply
> > sending 0xFFFF to /dev/gpio0 etc etc?
> >
> > My question is: it is possible to be sure of the GPIO pin state since
> > power-on through bootloader + RTOS up to the application run? For
> > instance not to let all pins go high/low/random?
> >
> > Any hints welcome :-)
> > Tomek
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
>
> Rather than use the default GPIO driver, I would probably consider a custom
> driver that doesn't present to applications as individual GPIO pins, but
> rather as higher level constructs (motor off, star-left, star-right, etc),
> with mappings to specific GPIO pins in board.h. That custom driver would
> initialize the actual pins to the safe state (motor off) on boot, would
> return the pins to that state when the driver is closed, and would produce
> only allowed combinations of GPIO outputs.
>
> In addition, never trust software when it could cause real-world big bangs!
> Since industrial controls must be connected to a safety controller
> (emergency stop or "E Stop"), that can put the entire machine or line in a
> safe state, I would design logic on the circuit board that E-stops the
> system if: (1) any forbidden combination of GPIOs is ever output, or (2) a
> hardware watchdog that ensures the software hasn't frozen.
>
> Cheers
> Nathan
>

Reply via email to