All, I've worked on a software PWM implementation using an interval timer signal (timer_create()) and used pthreads to isolate signal handling to a single thread that uses the kernel ioctl gpio access (ABI V2) to implement the PWM on the pins. On x86 (Bullseye from the Pi imager) I can get a max frequency of about 50KHz (generated clock) before saturating the core running the signal thread. (on a Pi Zero 2 W)
Surprisingly (or maybe not), on x86_64 (same Bullseye from Pi imager), I can only get 25KHz before saturating a single core with the signal thread.
Now 25KHz or 50KHz to create a PWM from is fine for most purposes -- except for DC motor control. There you need a minimum of 10 times that rate to place a PWM with minimum range of 10 at or above 25KHz to put the audible motor noise at less than 100% dutycycle above the normal human hearing range.
Is there a better approach that would yield a faster usable frequency for software PWM? Even at 25KHz clock, with a range of 10-steps (off, 10%, 20%, ...), that results in a PWM frequency of 2500Hz. Ideally, you would want a range of 20 or 30 for steps of 5%, or 3.3% of the dutycycle.
Currently, this produces a beautiful and stable software PWM, with the only limitation that the clock rate not saturate a single core handling the interval timer signals generated. Would it be better to approach the issue using timers for the off-count and on-count rather than using an interval to define the clock. That just seems to introduce a lot more latency or uncertainty in scheduling for how quickly the OS could switch between the timers defining one PWM cycle?
This is kind of where I'm stuck -- trying to figure out if I need to take another approach or if a stable software clock of 25KHz (on x86_64) and 50KHz (on x86) is about the max of what you could expect to get generating software PWM?
Surprisingly (or maybe not), on x86_64 (same Bullseye from Pi imager), I can only get 25KHz before saturating a single core with the signal thread.
Now 25KHz or 50KHz to create a PWM from is fine for most purposes -- except for DC motor control. There you need a minimum of 10 times that rate to place a PWM with minimum range of 10 at or above 25KHz to put the audible motor noise at less than 100% dutycycle above the normal human hearing range.
Is there a better approach that would yield a faster usable frequency for software PWM? Even at 25KHz clock, with a range of 10-steps (off, 10%, 20%, ...), that results in a PWM frequency of 2500Hz. Ideally, you would want a range of 20 or 30 for steps of 5%, or 3.3% of the dutycycle.
Currently, this produces a beautiful and stable software PWM, with the only limitation that the clock rate not saturate a single core handling the interval timer signals generated. Would it be better to approach the issue using timers for the off-count and on-count rather than using an interval to define the clock. That just seems to introduce a lot more latency or uncertainty in scheduling for how quickly the OS could switch between the timers defining one PWM cycle?
This is kind of where I'm stuck -- trying to figure out if I need to take another approach or if a stable software clock of 25KHz (on x86_64) and 50KHz (on x86) is about the max of what you could expect to get generating software PWM?
Statistics: Posted by drankinatty — Fri May 03, 2024 8:23 pm
