Pi pico control PWM with arduino IDE?

[bill-rubasse]

Hi,
Is it possible to control rp2040's PWM, like duty ratio and frequency through arduino IDE?
With micropython, it's quite easy to control Pi pico's PWM.
Can we do the same way with arduino IDE?

[earlephilhower]

analogWrite is the equivalent. See the documentation from Arduino. In a nutshell, you can set the PWM frequency and then the duty cycle with the actual analogWrite command.

[Andy2No]

I found we can use analogWriteFreq(frequency) to set the PWM frequency, as per the ESP8266 Arduino Core. That core also has analogWriteRange(PWMRANGE) too, and that also appears to work - you can set it to 255 or 1023. I haven't checked it with an oscilloscope, to see if it really changes, but I found we're allowed to set it to 1023, or at least try to.

I made a version of the simple siren tone() example, to use PWM instead. On my first attempts, I just got silence. It seems calling analogWriteFreq() has that effect, so I'm guessing it resets the waveform each time, causing an oscillator sync effect.

Here's a very crude attempt at a rising tone siren, with some sort of stereo effect which I've yet to hear convincingly. If I tweak constants enough, I probably will in the end. I can hear a PWM sweep effect, which sounds a little like moving the filter cut off control on a synth. There are some odd chirps at the beginning of each sweep of the siren, which seem to be related to resetting the wave and starting again each time I call analogWriteFreq

/* Simple annoying siren example using tone() */
/* Released to the public domain by Earle F. Philhower, III */

// Mangled to a PWM based version, with an attempt at a stereo effect (needs more work)

#define TONEPINL 13
#define TONEPINR 12

// This is either 255 or 1023 - not sure which
#define PWMRANGE 1023

int PWMRANGE1= PWMRANGE+1;  // used for modulo arithmetic, to stay in range
int PWMHALF= PWMRANGE1 / 2; // half amplitude value

#define FREQUPDATESTEP 4

#define PHASESTEP 100
#define PHASESHIFTDIVIDER 4


void setup() {
  pinMode(TONEPINL, OUTPUT);
  pinMode(TONEPINR, OUTPUT);

  analogWriteRange(PWMRANGE); // attempt to set 10 bit PWM
}

int maxtone= 3000;
int mintone= 31;

void loop() {
  for (int i = mintone; i < maxtone; i += 1) {
    //tone(TONEPINL, i);
    //tone(TONEPINR, maxtone+mintone - i);

// analogWriteFreq(freq) to set the PWM frequency for all PWM pins (default 1kHz)
    // Calling this too often results in silence, if no delay is added to the loop
    if((i % FREQUPDATESTEP) == 0)
      analogWriteFreq(i);

    int phase= i / PHASESTEP;
// analogWrite(pin, freq) to set the duty cycle on a pin, keeping the same frequency for all
    analogWrite(TONEPINL, (PWMHALF + ((i - phase) >> PHASESHIFTDIVIDER)) % PWMRANGE1);
    analogWrite(TONEPINR, (PWMHALF + ((i + phase) >> PHASESHIFTDIVIDER)) % PWMRANGE1);

    delay(1); // This is quicker than using tone() so it needs to be slowed down to make sense of the sound
  }
}

[earlephilhower]

Changing the analog PWM frequency while the system is running is a bad idea and isn't what the PWM hardware should be used. Changing the PWM frequency needs the whole PWM block to be reset (hence click/pop/etc.) on the next write, including time for the PLL to settle. In a real system where PWM was controlling something, those could be dangerous.

[Andy2No]

Interesting. Yes, there are a lot of clicks and pops.

I've also noticed that analogWriteFreq() doesn't give the frequency asked for, for part of the range - I haven't yet worked out whether it's lower frequencies or higher ones, but slowing down how often I update it, I can hear it's playing a pseudo random tune, at one end of the sweep.

The tone() example sounds more musical, but of course it has limitations too. I've been meaning to ask how interrupts can be used, for arduino-pico (I found I can't use ISR(), for example), but that's off topic, so I may start a new discussion when I've looked into it more.

[bill-rubasse]

analogWriteFreq() doesn't give the frequency I asked for, and tuning Pico's hardware timer seems too difficult to understand, that's the reason why I asked the question.
I found blink without delay code from Adafruit's Toturial: https://learn.adafruit.com/multi-tasking-the-arduino-part-1,

Maybe by counting the DigitalWrite() HIGH and LOW time, frequency and duty cycle of the PWM can be programmable?

[Andy2No]

I made a start on making a PWM tone generator, which is the same problem but intended more for music. The idea is to just watch the microseconds timer, and decide if it's time to flip the state of the output, yet.

The downside is that if an interrupt happens, the state will stay as it is for a little longer than it should, but will flip the next time the code inside the loop is called.

I originally intended to add code to make a siren, so there are some variables in this that don't do anything, yet. Everything is global, and not even in structures, because I wanted to keep it as cycle efficient as possible.

Since this doesn't wait, you could rename the loop() as something else, e.g. pwm_update() and just call it from loop() as often as possible. The rest of the code in loop could then get on with doing other things, provided they don't take so long that it delays calling the pwm_update() function too much.

It currently just plays a square wave test tone, at 435Hz. I went with milli Hz as a unit of frequency, so I can add accurate pitch bending and detuning.

Next, I'll probably add knobs to change the frequency and mark/space ratio, but as far as I know, that should already work by just changing constants to try it.

The calcPeriods() that's called in setup(), also needs to be run, each time the mark and space changes... It might be more convenient to change those to just a ratio too. At the moment, they're meant to be two numbers that add up to markSpacePrecision, which is currently 1024.

unsigned long utime;

int ledstate=0;
int led= LED_BUILTIN;

#define TONEPINL 13
#define TONEPINR 12

// Implement PWM at a given frequency (base_freq) allowing for modulation
// Frequencies are in milliHz, times are in microseconds;
unsigned long baseFreq, currFreq;

unsigned long  mark, space; // the ratio of these is what matters 
  // - can be in arbitrary units but use big enouugh values to get some precision
unsigned long markSpacePrecision= 1024; // Assume 10 but ADC values

unsigned long currMarkPeriod, currSpacePeriod;

// Make a swept siren tone between these two frequencies, in Hz
unsigned long minFreq=31000, maxFreq=3000000; //31Hz to 3kHz

long sirenStep= 5000;  // Amount to change siren period, at each step
unsigned long sirenInterval= 700000;  // time between changes to period

unsigned long mHzToMicros= 1000000000;  // 1mHz has a period of one thousand million microseconds

void calcPeriods()
{
  unsigned long totalPeriod= mHzToMicros/currFreq;
  if(mark > space)
  {
    currMarkPeriod= totalPeriod * mark / markSpacePrecision;
    currSpacePeriod= totalPeriod - currMarkPeriod;
  }
  else
  {
    currSpacePeriod= totalPeriod * space / markSpacePrecision;
    currMarkPeriod= totalPeriod - currSpacePeriod;
  }
}

void setup() {
  pinMode(led, OUTPUT);
  pinMode(TONEPINL, OUTPUT);
  pinMode(TONEPINR, OUTPUT);

  //Serial.begin(9600);

//  currFreq= baseFreq= minFreq;

// Start with just a test done at 3Hz
//  currFreq= baseFreq= 3000;
// Start with just a test done at 435Hz
  currFreq= baseFreq= 435000;

  mark=space= markSpacePrecision >> 1; // arbitrary units - the ratio is what counts
  
  calcPeriods();  // Set initial marks and space

  // test overriding mark/space to 1 second
  //currMarkPeriod= currSpacePeriod= 1000000;
}

int soundState= 0;  // space for 0, mark for 1
unsigned long stateChangePeriod= 0; // microseconds to next state flip

unsigned long lastStateChangeTime, nextStateChangeTime= 0;

//unsigned long sec= 1000000;
void loop() {
  utime = micros();

// instead of delays, keep looping but do things on time

  if(utime - lastStateChangeTime >= stateChangePeriod)  // toggle output
  {
    if(soundState) // currently mark
    {
      stateChangePeriod= currSpacePeriod;
    }
    else
    {
      stateChangePeriod= currMarkPeriod;
    }
    //nextStateChangeTime= lastStateChangeTime + stateChangePeriod;
    lastStateChangeTime= utime;     

    soundState= ~soundState;
    
    digitalWrite(TONEPINL, soundState);
    digitalWrite(TONEPINR, soundState);

  
//    Serial.print("Time: ");
//    Serial.println(utime); //prints time since program started
//  only uncomment the above if the frequecy is very low, for debugging - wait a second so as not to send massive amounts of data

// Keep this for debugging by using a very low frequency - toggles the LED to prove it's running
    digitalWrite(led, ledstate);
    ledstate= ~ledstate;

  }
}

[Andy2No]

One thing to note is that the micros and millis timers loop, so you have to be careful how you do the comparison. You have to think of it in terms of modulo arithmetic aka clock arithmetic.

You need to avoid addition, followed by a comparison, because the number after the addition could have wrapped around to just past zero. For the micros timer, that happens about every 70 minutes, apparently, so if you do the comparison the wrong way, it's likely to work okay for 70 minutes, then stall for another 70 minutes.

That's why it's done like this:

if(utime - lastStateChangeTime >= stateChangePeriod) ...

where utime is the current value, from micros(), lastStateChangeTime is the last time the output was flipped, and stateChangePeriod is the amount of time to wait, in microseconds, before flipping it again.

By doing it as a subtraction, we avoid the roll-over problem where the timer goes back to zero. That works because both variables, utime and lastStateChangeTime, are unsigned, and have the same number of bits, as does the answer. It's modulo arithmetic with a base of 2 to the power of the number of bits.

[khoih-prog]

You can try my new hardware-based RP2040_PWM library which can support PWM frequency from very low (7.5Hz) to very high (Mhz).

With frequency lower than 7.5Hz, try this ISR-based RP2040_Slow_PWM Library

[Hyper-ZX]

hello. if you are there, please reply. I need some help with your library

[Laserjones]

I found that according to the documentation, analogWriteFreq supports up to 60 kHz PWM cycle frequency, and analogWriteRange supports up to 65536 level values. However, since the Pico's maximum PWM counter step frequency is 125 MHz, this would mean that, for example, at 60 kHz, the maximum possible number of level values (counter steps) would be 125000/60 = 2083, i.e. only about 11 bits rather than 16 bits of resolution. Does the core take care of this? If someone sets a range that is too high for the frequency, what will the functions do?

[earlephilhower]

Yes it does. See

arduino-pico/cores/rp2040/wiring_analog.cpp

Lines 82 to 95 in 5dee051

	// For low frequencies, we need to scale the output max value up to achieve lower periods
	analogWritePseudoScale = 1;
	while (((clock_get_hz(clk_sys) / (float)(analogScale * analogFreq)) > 255.0) && (analogScale < 32678)) {
	analogWritePseudoScale++;
	analogScale *= 2;
	DEBUGCORE("Adjusting analogWrite values PS=%d, scale=%d\n", analogWritePseudoScale, analogScale);
	}
	// For high frequencies, we need to scale the output max value down to actually hit the frequency target
	analogWriteSlowScale = 1;
	while (((clock_get_hz(clk_sys) / (float)(analogScale * analogFreq)) < 2.0) && (analogScale > 32)) {
	analogWriteSlowScale++;
	analogScale /= 2;
	DEBUGCORE("Adjusting analogWrite values SS=%d, scale=%d\n", analogWriteSlowScale, analogScale);
	}

[Laserjones]

Great! It would probably be a good idea to mention these limits (frequency * range <= 125 MHz) in the documentation, as they may not be obvious to everyone.

[Laserjones]

What is the reason for the 60 kHz limit, by the way? For audio purposes, that's a bit low (only 1.5 cyles per sample if we set a suitable sampling rate of 40 kHz to cover the maximum audible frequency of 20 kHz). Shouldn't it be possible to go up to, say, 488 kHz? That would still allow a PWM level resolution of 8 bits. As far as I can see, the Pico SDK does not set an upper limit except the 125 MHz counter frequency.

[earlephilhower]

I started this repo w/code from the ESP8266 work I did, so that's why there's a 60kHZ limit (on the 8266 there is no PWM hardware and an IRQ is used to generate it hence the limit).

Would you like to do a PR and up the limit to, say, 500kHz? I think it's a 1-liner and the math in the code should "just work."

[Laserjones]

I'm still an absolute beginner with all that stuff (Arduino, C++, Pico, GitHub ...), so I don't think that's a good idea. I can just contribute suggestions.

As far as I understand, the lowest PWM resolution you consider useful is 4 bits / 16 steps. That would mean that the highest usable PWM cycle frequency would be clock_get_hz(clk_sys) / 16, which is 7.8125 MHz with the default 125 MHz clock. I see no reason not to allow this, as the frequency can't be high enough for high-quality analog signals (an analog low-pass filter is often required at the output pin to smooth the voltage, but it should not be too aggressive in order not to blur the signal, and the higher the PWM frequency, the less ripples will remain in the filtered signal).

By the way, in section 7.2.2 of your documentation, it says "A range of 16 to 65535 is supported." That should be 15 according to the code (as it's the max. counter value, i.e. range minus 1), right? Also, it would be good to also state the possible range of the res parameter (4 to 16).