Arduino PWM output difference between 16MHz/256MHz

HiFive1 Rev B
1

I’m going through the example programs on the Arduino IDE, and I have a strange behaviour with the standard “Fade” program. Using the 16MHz XTAL, the sketch works exactly as you would imagine, the LED slowly fades in and out. However, when I upload exactly the same sketch using the 256MHz PLL, things change. The LED does try to fade in and out, but “jumps” and blinks when it is close to full illumination. I can’t capture it on my oscilloscope, but if needed, I can send a quick video showing the behavior.

2

Interesting! I’ll try it out later today as well.

3

My guess ist that the high clock speed is driving the PWM cycles into harmonics, When the fading appears to work,it is because the harmonic cycles are “out of phase”, and when the “blinking” starts they are getting “in phase”. That cycle then continually repeats.Try increasing the wait parameter in your sketch by a factor of 16 and see if that helps. Sorry that I cannot test it myself, since my HiFive1 did not clear customs.

4

I’m not sure it’s exactly what you’re describing, but I do see some subtle timing glitches every few PWM cycles at 256MHz. If I run the “Blink” demo at 256MHz there are also some longer blinks, so I believe the delay function may have a precision/overflow issue. I will look into it.

Does that match what you see?

5

I noticed the glitches were coming at a period which would correspond to a 32-bit overflow at 256MHz, (and means we should see the same glitchy behavior on a longer scale for the 16MHz, but I didn’t want to stare at the blinky for 5 minutes :slight_smile: ).

I rewrote the delay() function to use the 64-bit values instead of 32-bit, which resolved the glitches for me. The fixes for delay/millis/micros will be in the v1.0.1 package.

Let us know if this doesn’t sound like the issue you’re seeing…

6

That does indeed sound like what I’m encountering, I’ll check it out when v1.0.1 is posted. In the mean time, I’m having a lot of fun (and this isn’t a showstopper for me). Many thanks, Megan!

7

How do you change to 256 (or other) MHz?

8

In the Arduino IDE there is an option under the Board menu to select it.

9

Thanks. I just came back to say I found it in the Tools menu…

10

Oops, you’re right. Tools not Board

11

So, at 256 MHz:

Address of global = 800005D4
Address of setup = 20400204
Address of loop = 20400074
Address of local = 80003FB4
Two Micros in a row = 4
Two Micros in a row = 4
Two Micros in a row = 3
Two Micros in a row = 4
Two Micros in a row = 3
Two Micros in a row = 4
Two Micros in a row = 4
Two Micros in a row = 4
Two Micros in a row = 4
Two Micros in a row = 4
Micros = 16570557 fib(40) = 102334155
Micros = 16570497 fib(40) = 102334155
Micros = 16570481 fib(40) = 102334155
Micros = 16570497 fib(40) = 102334155
Micros = 16570497 fib(40) = 102334155
Micros = 16570497 fib(40) = 102334155
Micros = 16570497 fib(40) = 102334155
Micros = 16570497 fib(40) = 102334155
Micros = 16570496 fib(40) = 102334155
Micros = 16570497 fib(40) = 102334155

This is before the improved micros() divide. I guess I can check out your repo and symlink it into the Arduino IDE somewhere.

Fibonacci(40) takes 16.57 seconds. (very stable timing!)
On riscvemu (local, C, not js) it takes 18.64
qemu takes 4.62
Native (i7 6700K) takes 0.44

So the HiFive1 CPU is roughly equivalent to a 115 MHz superscalar out of order Skylake x86. ie. the IPC or CPI is about 2.2 times worse. On highly recursive code. (the merely two level return stack cache will be killing the HiFive1 on this)