Following on from my other thread... about having realtime behaviour for use within brief bursts of GPIO activity, the interval between these bursts not needing any timing consistency or accuracy.
This concerns a Pi Zero W (v1.1), I'm not sure if that would mean behaviour would be identical on the 3, 3A and 3B. I don't knowif the Zero W has the same quad core system and the ability to dedicate a core to realtime use, the way the 3B is discussed as being able to do. Nor do I yet know how to dedicate a core to a C program, what I have got working so far is discussed below.
Simply using the library functions seems to work well, surprisingly.
So far I've just been using the bcm library's delays:
bcm2835_delayMicroseconds(time_to_delay_for)
for short delays between GPIO events
and I've included a "magic" piece of code that the library recommends:
#include <sched.h>
#include <sys/mman.h>
and then at the start ofthe C code's main function I've got:
struct sched_param sp;
memset(&sp, 0, sizeof(sp));
sp.sched_priority = sched_get_priority_max(SCHED_FIFO);
sched_setscheduler(0, SCHED_FIFO, &sp);
mlockall(MCL_CURRENT | MCL_FUTURE);
This does a very good job of making the timing more precise, I'm getting a severe deviation from the intended microsecond scale timings only once every few seconds, even if I'm constantly doing precisely timed GPIO stuff.
But those severe deviations take on the 40ms to 60ms sort of time scale*, and can happen at any point it appears.
*all timings I mention are as read from an oscilloscope monitoring the Pi's GPIO pins
I understand this "magic" code takes over the operating system's scheduler and gives maximum priority to the C code one is running, this does things like make the mouse cursor go laggy at times, but that is not a problem in my use case.
But I suspect that if I could find a line of code to "undo" what that "magic" set of lines do and turn the scheduler back ON then I'd be able to use the "magic" lines to turn the scheduler off for just a very brief critical section of code, then turn it back on shortly afterwards. In doing so I suspect whatever is causing the random 40 to 60 ms pauses would then choose to let itself run during the times when the scheduler was operating normally, between time critical bursts of GPIO activity rather than making a 40ms to 60ms break in the middle of a burst. And other than for the time critical bursts, I think the mouse and other things would continue to run pretty normally.
Can anyone help me better understand what that "magic" code is about, and therefore how to undo it at some points in the C code so it can then be turned on only when needed.
Thank you
This concerns a Pi Zero W (v1.1), I'm not sure if that would mean behaviour would be identical on the 3, 3A and 3B. I don't knowif the Zero W has the same quad core system and the ability to dedicate a core to realtime use, the way the 3B is discussed as being able to do. Nor do I yet know how to dedicate a core to a C program, what I have got working so far is discussed below.
Simply using the library functions seems to work well, surprisingly.
So far I've just been using the bcm library's delays:
bcm2835_delayMicroseconds(time_to_delay_for)
for short delays between GPIO events
and I've included a "magic" piece of code that the library recommends:
#include <sched.h>
#include <sys/mman.h>
and then at the start ofthe C code's main function I've got:
struct sched_param sp;
memset(&sp, 0, sizeof(sp));
sp.sched_priority = sched_get_priority_max(SCHED_FIFO);
sched_setscheduler(0, SCHED_FIFO, &sp);
mlockall(MCL_CURRENT | MCL_FUTURE);
This does a very good job of making the timing more precise, I'm getting a severe deviation from the intended microsecond scale timings only once every few seconds, even if I'm constantly doing precisely timed GPIO stuff.
But those severe deviations take on the 40ms to 60ms sort of time scale*, and can happen at any point it appears.
*all timings I mention are as read from an oscilloscope monitoring the Pi's GPIO pins
I understand this "magic" code takes over the operating system's scheduler and gives maximum priority to the C code one is running, this does things like make the mouse cursor go laggy at times, but that is not a problem in my use case.
But I suspect that if I could find a line of code to "undo" what that "magic" set of lines do and turn the scheduler back ON then I'd be able to use the "magic" lines to turn the scheduler off for just a very brief critical section of code, then turn it back on shortly afterwards. In doing so I suspect whatever is causing the random 40 to 60 ms pauses would then choose to let itself run during the times when the scheduler was operating normally, between time critical bursts of GPIO activity rather than making a 40ms to 60ms break in the middle of a burst. And other than for the time critical bursts, I think the mouse and other things would continue to run pretty normally.
Can anyone help me better understand what that "magic" code is about, and therefore how to undo it at some points in the C code so it can then be turned on only when needed.
Thank you
Statistics: Posted by Infraviolet — Tue Jan 23, 2024 3:28 am — Replies 0 — Views 99