Mr. Wieser, I haven't seen you mention which library you're using to write to GPIO with Python. I know of two options:
1) RPi.GPIO: https://sourceforge.net/projects/raspberry-gpio-python/ -- the more popular option 2) WiringPy: https://github.com/WiringPi/WiringPi-Python -- an alternative with better performance See (7 year old) benchmarks here: https://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ WiringPy has it's own delay function, which may have better performance than using any Python alternative. See an example here: https://github.com/WiringPi/WiringPi-Python/blob/master/examples/softpwm.py RPi.GPIO has dedicated PWM functions, which may or may not solve your problem. See docs here: https://sourceforge.net/p/raspberry-gpio-python/wiki/PWM/ Cheers, Luciano On Wed, Nov 13, 2019 at 3:27 PM R.Wieser <address@not.available> wrote: > > Dennis, > > > So... you need to adjust for the time spent in processing between > > calls to sleep(). > > That was my first thought too, but any code calculating that adjustment > before ultimatily calling sleep itself can also be interrupted. With that > in mind I was aiming/hoping for something with a /very/ short path between > the calculation and executing the sleep (as in: none at all, done by the > system itself). > > > The creep could be mitigated some by having the handler's first > > action being to start the next timer instance, and then doing "stuff". > > Yup. But the cost of using that command is generating threads - which some > search results warned against (not sure why though). > > The best solution I can think of would be a build-in (hardware?) timer which > would generate "ticks" until its stopped. > > Regards, > Rudy Wieser > > > -- > https://mail.python.org/mailman/listinfo/python-list -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg -- https://mail.python.org/mailman/listinfo/python-list
