Re: initial gpio state: power on -> boot -> rtos -> app.
On Sun, Feb 19, 2023 at 1:13 PM Nathan Hartman wrote: > 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. Thank you Nathan! Sounds like a good idea.. and I could learn to write drivers in NuttX :-) > 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. Exactly :-) I always smiled at devices that could be physically broken via software modification / error.. now I am facing the issue myself from the other side :-P As the time is short for the proof of concept device and the risk is too high, after consideration, I will use only 2 groups of relays for now, that completely eliminates the big bang scenario, different motor type will require simple rewire of the relays, this is the simplest and safest approach (kiss rule = keep it simple stupid). More versatile but also complex design may follow if the initial project pays off ;-) Thank you for your time and hints!! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: initial gpio state: power on -> boot -> rtos -> app.
On Mon, Feb 20, 2023 at 7:21 AM Simon Filgis wrote: > > 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. Yup, that was my concern number one: unknown state on power-on -> internal boot -> firmware boot -> rtos boot -> application.. and the variations during firmware flashing upgrade etc.. these days you won't write all of the assembly code yourself anymore straight from the reset vector.. also reset != zero everything to a known state in modern mcus so its better to be safe than sorry :-) In a more complex design I think that dedicated logic is required between mcu and the acuators that would verify working state with some sort of latching that prevents accidental fires :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: initial gpio state: power on -> boot -> rtos -> app.
Hi, In my devices I always have external pull-up/downs at important/dangerouse ports. -Oleksandr пн, 20 лют. 2023, 14:53 користувач Tomek CEDRO пише: > On Mon, Feb 20, 2023 at 7:21 AM Simon Filgis wrote: > > > > 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. > > Yup, that was my concern number one: unknown state on power-on -> > internal boot -> firmware boot -> rtos boot -> application.. and the > variations during firmware flashing upgrade etc.. these days you won't > write all of the assembly code yourself anymore straight from the > reset vector.. also reset != zero everything to a known state in > modern mcus so its better to be safe than sorry :-) > > In a more complex design I think that dedicated logic is required > between mcu and the acuators that would verify working state with some > sort of latching that prevents accidental fires :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: initial gpio state: power on -> boot -> rtos -> app.
On Mon, Feb 20, 2023 at 2:52 PM Tomek CEDRO wrote: > In a more complex design I think that dedicated logic is required > between mcu and the acuators that would verify working state with some > sort of latching that prevents accidental fires :-) In addition to machine-state-awareness, even safer than latching would be keepalive control clocking, so logic will only set a valid working acuator state for a short period of time (i.e. 1s) until it gets another command or gets back to a safe state (stop), mcu must send desired command soon enough (i.e. 1/2s) in order to perform continuous actions. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: initial gpio state: power on -> boot -> rtos -> app.
Hi Tomek, 1s keepalive can also be addressed with sw-watchdog. It may be easier than flipflopping. -- Hard- and Softwaredevelopment Consultant Ingenieurbüro-Filgis USt-IdNr.: DE305343278 On Mon, Feb 20, 2023 at 3:08 PM Tomek CEDRO wrote: > On Mon, Feb 20, 2023 at 2:52 PM Tomek CEDRO wrote: > > In a more complex design I think that dedicated logic is required > > between mcu and the acuators that would verify working state with some > > sort of latching that prevents accidental fires :-) > > In addition to machine-state-awareness, even safer than latching would > be keepalive control clocking, so logic will only set a valid working > acuator state for a short period of time (i.e. 1s) until it gets > another command or gets back to a safe state (stop), mcu must send > desired command soon enough (i.e. 1/2s) in order to perform continuous > actions. > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: initial gpio state: power on -> boot -> rtos -> app.
On Mon, Feb 20, 2023 at 3:12 PM Simon Filgis wrote: > 1s keepalive can also be addressed with sw-watchdog. It may be easier than > flipflopping. Thanks Simon! I was also thinking about custom NuttX driver as Nathan suggested.. I need to see how complex is that.. always want to learn new stuff.. I will start from reading the sw-watchdog code :-) :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: initial gpio state: power on -> boot -> rtos -> app.
Hi Tomek, I mean MCU peripheral watchdog just for clarification. Not a sw-watchdog flow control. But is that available in the nuttx codebase btw? :) -- Hard- and Softwaredevelopment Consultant Ingenieurbüro-Filgis USt-IdNr.: DE305343278 On Mon, Feb 20, 2023 at 3:24 PM Tomek CEDRO wrote: > On Mon, Feb 20, 2023 at 3:12 PM Simon Filgis wrote: > > 1s keepalive can also be addressed with sw-watchdog. It may be easier > than > > flipflopping. > > Thanks Simon! I was also thinking about custom NuttX driver as Nathan > suggested.. I need to see how complex is that.. always want to learn > new stuff.. I will start from reading the sw-watchdog code :-) :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: initial gpio state: power on -> boot -> rtos -> app.
One thing to be careful with hardware watchdogs: Most have a cyclic behavior, so if your MCU locks up, the hardware watchdog might output a square wave that causes motor to turn on, off, on, off, rapidly, instead of killing it. On Mon, Feb 20, 2023 at 9:44 AM Simon Filgis wrote: > > Hi Tomek, > I mean MCU peripheral watchdog just for clarification. Not a sw-watchdog > flow control. But is that available in the nuttx codebase btw? > :) > > -- > Hard- and Softwaredevelopment Consultant > Ingenieurbüro-Filgis > USt-IdNr.: DE305343278 > > > On Mon, Feb 20, 2023 at 3:24 PM Tomek CEDRO wrote: > > > On Mon, Feb 20, 2023 at 3:12 PM Simon Filgis wrote: > > > 1s keepalive can also be addressed with sw-watchdog. It may be easier > > than > > > flipflopping. > > > > Thanks Simon! I was also thinking about custom NuttX driver as Nathan > > suggested.. I need to see how complex is that.. always want to learn > > new stuff.. I will start from reading the sw-watchdog code :-) :-) > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > >
Re: initial gpio state: power on -> boot -> rtos -> app.
On Mon, Feb 20, 2023 at 3:47 PM Nathan Hartman wrote: > One thing to be careful with hardware watchdogs: Most have a cyclic > behavior, so if your MCU locks up, the hardware watchdog might output > a square wave that causes motor to turn on, off, on, off, rapidly, > instead of killing it. ACK! :-) I would prefer to make my own "control" circuit (aka hardware watchdog) based on a generic part.. I have bad experiences with using custom / specific parts that may be out of stock or skyrocketing price :-P I will focus on the basic KISS PoC for now. But I know the possibilities for next version. Thank you! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
