Is there a way to "restart" pulse train ?

[XANi]

Is there a way to "start" UPS Pico, if say rPi stopped generating pulse train for few minutes ?

I'm trying to write replacement for picofssd (the daemon is not working in the 64 bit Debian because libs do not support it) and so far it works well until I stop it and start again (because I am testing).

I am assuming UPS Pico goes into suspend mode and I'm getting some pulses:

event:  RISING EDGE offset: 27 timestamp: [1573132477.587398017]
event: FALLING EDGE offset: 27 timestamp: [1573132477.587476401]
event:  RISING EDGE offset: 27 timestamp: [1573132477.587520255]
event: FALLING EDGE offset: 27 timestamp: [1573132477.587586660]
event:  RISING EDGE offset: 27 timestamp: [1573132477.587650201]
event: FALLING EDGE offset: 27 timestamp: [1573132477.587718951]
event:  RISING EDGE offset: 27 timestamp: [1573132477.587780929]
event: FALLING EDGE offset: 27 timestamp: [1573132477.587846710]

event:  RISING EDGE offset: 27 timestamp: [1573132498.751365780]
event: FALLING EDGE offset: 27 timestamp: [1573132498.751465362]
event:  RISING EDGE offset: 27 timestamp: [1573132498.751496612]
event: FALLING EDGE offset: 27 timestamp: [1573132498.751554997]
event:  RISING EDGE offset: 27 timestamp: [1573132498.751618069]
event: FALLING EDGE offset: 27 timestamp: [1573132498.751708954]
event:  RISING EDGE offset: 27 timestamp: [1573132498.751748849]
event: FALLING EDGE offset: 27 timestamp: [1573132498.751828744]

event:  RISING EDGE offset: 27 timestamp: [1573132519.915647220]
event: FALLING EDGE offset: 27 timestamp: [1573132519.915752271]
event: FALLING EDGE offset: 27 timestamp: [1573132519.915810760]
event: FALLING EDGE offset: 27 timestamp: [1573132519.915854614]

it generates 4 short pulses every 20 seconds, what should be rPi answer to those ?

[PiModules]

Hi, Hmmm, difficult question. The PIco stopped generating them for some reason. Normally it is working like that PIco send a pulse, and Raspberry Pi respond to this pulse (with 1/2) of rate. This cause an interrupt on PIco side, that check them. I can add a command to start this again, but you should send me more info why (how) it happens (I mean stop pulses generation - the conditions) Answering from PIco side is one by one. If you send me more info I can adopt it to your needs, if they are logical also for other users Also please notice that, we used this mechanism of pulses, as a part of users use PIco when many files was copied, so interrupt based mechanism was necessary as polling cause problems. Now, we have imagine different mechanism, and implemented it, and in this or next firmware update we will provide it so also the used GPIOs will be free from now. IN the UPS PIco HV3.0 user will have possibility to use both ways with RPi interaction. Similar mechanism we implemented in the new UPS PIco HV4.0 (the new one) Please do not hesitate to ask whatever you need again BR Io

On 07-Nov-19 3:17 PM, XANi wrote: Is there a way to "start" UPS Pico, if say rPi stopped generating pulse train for few minutes ? I'm trying to write replacement for |picofssd| (the daemon is not working in the 64 bit Debian because libs do not support it) and so far it works well until I stop it and start again (because I am testing). I am assuming UPS Pico goes into suspend mode and I'm getting some pulses: |event: RISING EDGE offset: 27 timestamp: [1573132477.587398017] event: FALLING EDGE offset: 27 timestamp: [1573132477.587476401] event: RISING EDGE offset: 27 timestamp: [1573132477.587520255] event: FALLING EDGE offset: 27 timestamp: [1573132477.587586660] event: RISING EDGE offset: 27 timestamp: [1573132477.587650201] event: FALLING EDGE offset: 27 timestamp: [1573132477.587718951] event: RISING EDGE offset: 27 timestamp: [1573132477.587780929] event: FALLING EDGE offset: 27 timestamp: [1573132477.587846710] event: RISING EDGE offset: 27 timestamp: [1573132498.751365780] event: FALLING EDGE offset: 27 timestamp: [1573132498.751465362] event: RISING EDGE offset: 27 timestamp: [1573132498.751496612] event: FALLING EDGE offset: 27 timestamp: [1573132498.751554997] event: RISING EDGE offset: 27 timestamp: [1573132498.751618069] event: FALLING EDGE offset: 27 timestamp: [1573132498.751708954] event: RISING EDGE offset: 27 timestamp: [1573132498.751748849] event: FALLING EDGE offset: 27 timestamp: [1573132498.751828744] event: RISING EDGE offset: 27 timestamp: [1573132519.915647220] event: FALLING EDGE offset: 27 timestamp: [1573132519.915752271] event: FALLING EDGE offset: 27 timestamp: [1573132519.915810760] event: FALLING EDGE offset: 27 timestamp: [1573132519.915854614] | it generates 4 short pulses every 20 seconds, what should be rPi answer to those ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#51?email_source=notifications&email_token=ACBH7BFK7H5I2ZACZD7VZA3QSQIQBA5CNFSM4JKGOZIKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HXTJJYA>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBH7BAIFUCI2M26AOQOKY3QSQIQBANCNFSM4JKGOZIA>.

-- Ioannis www.pimodules.com -- Pi Modules Legal Disclaimer The content of this email is confidential and solely intended for the indicated addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient be informed that disclosure, reproduction in any form, in part or whole, or circulation of the content of this email is prohibited and may be unlawful. In this case, please inform immediately the sender of the email.

[XANi]

Hmmm, difficult question. The Pico stopped generating them for some reason.

The reason was rPi stopped sending it. I was testing an app to communicate with it and the app was just stopped long enough. Which is entirely expected, my question is what are recovery options from this state ? Can I send something to Pico start it it ? Or does rebooting Pi is enough to wake Pico ?

I also noticed there is a short pulse train every ~20s from Pico when it is shut down, what is a reason for that ? Is rPi supposed to answer that ?

I can add a command to start this again, but you should send me more
info why (how) it happens (I mean stop pulses generation - the conditions)

Okay, so story time. We tried to just run stock 64 bit Debian on rPi, because that's what we run everywhere else. The app handling UPS Pico relies on libs that use either /dev/mem, which on latest kernels do not have GPIO access (there is kernel option that doesn't allow even root to access it, for security, and most distos enabled it by default) or module providing /dev/gpiomem, which is also not in stock.

What is in the kernel is the "new" way of handling GPIO, via /dev/gpiochipX

So I looked in the source code how it is handled, and said "well, that doesn't look to hard" and started developing an app to handle it.

And that meant I had to stop and start the app to test it in the first place, which triggered Pico going down, just because app was turned off long enough.

I can add a command to start this again, but you should send me more
info why (how) it happens (I mean stop pulses generation - the conditions)

The cause is basically "the daemon handling it is down for whatever reason". The reason might be as simple as "not installed yet" or someone doing some maintenance, or maybe someone just screwed something on rPi side but is 50 km away and can't press a physical button on it to restart Pico.

Also please notice that, we used this mechanism of pulses, as a part of
users use PIco when many files was copied, so interrupt based mechanism
was necessary as polling cause problems. Now, we have imagine different
mechanism, and implemented it, and in this or next firmware update we
will provide it so also the used GPIOs will be free from now. IN the UPS
PIco HV3.0 user will have possibility to use both ways with RPi interaction

I'd love a bit more documentation on it. Just info "what Pico sends, what rPi should respond", etc.

Pretty much everything else in the project is very nicely documented but that part I had to dig thru source code to dig out.