"It is possible that that code worked, but the problem you are experiencing is not due to interrupts, so you didn't notice any improvement."
Something is definitely "interrupting", and doing so even when my code runs with top priority in FIFO mode. If it isn't an interrupt what could it be? Something happens that, as can be seen on the o-scope traces of the GPIO pins pauses GPIO activity for between 100us and 200us every so often. I think I also get, very rarely, a 50ms pause in which the system keeps up to date with other processes, the system does this in a way which collides with my GPIOing on rare occasions despite the fact that I switch to a SCHED_OTHER priority as soon as the time critical stuff is done, and therefore my code runs about half the time GPIOing with top priority and half the time handling calculations with only normal level priority. What I can't get is why, whatever the 100us-200us thing, and the very rare 50ms thing, can't just wait for the chance they inevitably get to run within somewhere from 0.5ms to 2ms of when my time critical GPIOing starts.
Neither " sudo sh -c "echo -1 > /proc/sys/kernel/sched_rt_runtime_us" ", nor putting it back to the default 950000 had any effect on the very rare 50ms either, nor on the more frequent 100us-200us pauses. And one would think that as my code releases priority much more quickly than a whole 950ms the rest of the system would be able to do its stuff inbetween my ( <=2ms from taking priority to releasing it )GPIO periods anyway. Whatever is causing either of them doesn't seem to respond to these methods. maybe it would if I were on a multi-core Pi, but I want to get this working with a Zero W as the smaller form factor is very useful when embedding it in small places (small wheeled/tracked/legged robots and such).
I looked around online and saw rumours that ARM chips like the bcm****(not actually 2835 since first Pi version?) in the Pi won't let the "cli()" and "sei()" (as they'd be on AVR) equivalents be called from user-mode processes? If so this might explain why that code didn't work.
" You can pass data to it via the write to the /sys interface file."/"You can pass data to it via the write to the /sys interface file."
Are there any example pieces of code which do this which I can look at? Simple ones which just show how this is done, rather than trying to understand this from looking at big pieces of kernel code that do loads of other stuff too. Thanks
Something is definitely "interrupting", and doing so even when my code runs with top priority in FIFO mode. If it isn't an interrupt what could it be? Something happens that, as can be seen on the o-scope traces of the GPIO pins pauses GPIO activity for between 100us and 200us every so often. I think I also get, very rarely, a 50ms pause in which the system keeps up to date with other processes, the system does this in a way which collides with my GPIOing on rare occasions despite the fact that I switch to a SCHED_OTHER priority as soon as the time critical stuff is done, and therefore my code runs about half the time GPIOing with top priority and half the time handling calculations with only normal level priority. What I can't get is why, whatever the 100us-200us thing, and the very rare 50ms thing, can't just wait for the chance they inevitably get to run within somewhere from 0.5ms to 2ms of when my time critical GPIOing starts.
Neither " sudo sh -c "echo -1 > /proc/sys/kernel/sched_rt_runtime_us" ", nor putting it back to the default 950000 had any effect on the very rare 50ms either, nor on the more frequent 100us-200us pauses. And one would think that as my code releases priority much more quickly than a whole 950ms the rest of the system would be able to do its stuff inbetween my ( <=2ms from taking priority to releasing it )GPIO periods anyway. Whatever is causing either of them doesn't seem to respond to these methods. maybe it would if I were on a multi-core Pi, but I want to get this working with a Zero W as the smaller form factor is very useful when embedding it in small places (small wheeled/tracked/legged robots and such).
I looked around online and saw rumours that ARM chips like the bcm****(not actually 2835 since first Pi version?) in the Pi won't let the "cli()" and "sei()" (as they'd be on AVR) equivalents be called from user-mode processes? If so this might explain why that code didn't work.
" You can pass data to it via the write to the /sys interface file."/"You can pass data to it via the write to the /sys interface file."
Are there any example pieces of code which do this which I can look at? Simple ones which just show how this is done, rather than trying to understand this from looking at big pieces of kernel code that do loads of other stuff too. Thanks
Statistics: Posted by Infraviolet — Sun Jan 28, 2024 7:10 am
