Re: initial gpio state: power on -> boot -> rtos -> app.

2023-02-20 Thread Tomek CEDRO
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

Re: initial gpio state: power on -> boot -> rtos -> app.

2023-02-20 Thread 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 ->

Re: initial gpio state: power on -> boot -> rtos -> app.

2023-02-20 Thread Oleksandr Oryshchenko
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 s

Re: initial gpio state: power on -> boot -> rtos -> app.

2023-02-20 Thread Tomek CEDRO
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 t

Re: initial gpio state: power on -> boot -> rtos -> app.

2023-02-20 Thread Simon Filgis
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: >

Re: initial gpio state: power on -> boot -> rtos -> app.

2023-02-20 Thread Tomek CEDRO
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

Re: initial gpio state: power on -> boot -> rtos -> app.

2023-02-20 Thread Simon Filgis
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 M

Re: initial gpio state: power on -> boot -> rtos -> app.

2023-02-20 Thread Nathan Hartman
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

Re: initial gpio state: power on -> boot -> rtos -> app.

2023-02-20 Thread Tomek CEDRO
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! :-)