Hi Seth,
On 10/20/20 8:35 PM, Bollinger, Seth wrote:
In this case we’re switching from on:86400, off:0 -> on:0, off:86400. We write off first, then on using fwrite() to a file. From the trace, it looks like on is always stored first. So, the first store is on:0, off:0 for a brief period (enough to trigger the default), and then off is stored. We’re already trying to not have them not both be zero at the same time. I tried putting fflush() between them, but that didn’t help. I suppose we could try to sleep some period of time, but this seems bad as well. Maybe write and read to verify the value is correctly stored?
I don't understand. Why would you use blink with on:86400, off:0?
In this case we’re using the api to turn the LED on and off, without blinking (in this case only).
If there's no reasonable value to change the frequency, we'll need to
fix that.
I think if we could control the delays with trigger set to none, then we could set the delays and enable the timer trigger for a no glitch operation. I suppose if there was a timer-off trigger, that would work as well, but seems kind of silly.
You may want to look at ledtrig-transient and ledtrig-oneshot...?
Ok, I’ll take a look. Thanks!
You might want to check also ledtrig-pattern and paragraph 2.
of its documentation [0].
[0] Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
--
Best regards,
Jacek Anaszewski
