Question

This is an academic question (I’m not necessarily planning on doing it) but I am curious about how it would work. I’m thinking of a userland software (rather than hardware) solution.

I want to produce PWM signals (let’s say for a small number of digital GPIO pins, but more than 1). I would probably write a program which created a Pthread, and then infinitely looped over the duty cycle with appropriate sleep()s etc in that thread to get the proportions right.

Would this not clobber the CPU horribly? I imagine the frequency would be somewhere around the 100 Hz mark. I’ve not done anything like this before but I can imagine that the constant looping, context switches etc wouldn’t be great for multitasking or CPU usage.

Any advice about CPU in this case use and multitasking? FWIW I’m thinking of a single-core processor. I have a feeling answers could range from ‘that will make your system unusable’ to ‘the numbers involved are orders of magnitude smaller than will make an impact to a modern processor’!

Assume C because it seems most appropriate.

EDIT: Assume Linux or some other general purpose POSIX operating system on a machine with access to hardware GPIO pins.

EDIT: I had assumed it would be obvious how I would implement PWM with sleep. For the avoidance of doubt, something like this:

while (TRUE)
{
    // Set all channels high
    for (int c = 0; x < NUM_CHANNELS)
    {
        set_gpio_pin(c, 1);
    }

    // Loop over units within duty cycle
    for (int x = 0; x < DUTY_CYCLE_UNITS; x++)
    {   
        // Set channels low when their number is up
        for (int c = 0; x < NUM_CHANNELS)
        {
            if (x > CHANNELS[c])
            {
                set_gpio_pin(c, 0);
            }
        }

        sleep(DUTY_CYCLE_UNIT);
    }
}

Answer 1

Use a driver if you can. If your embedded device has a PWM controller, then fine, else dedicate a hardware timer to generating the PWM intervals and driving the GPIO pins.

If you have to do this at user level, raising a process/thread to a high priority and using sleep() calls is sure to generate a lot of jitter and a poor pulse-width range.