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 >
