Who to blame, user, tool or microcontroller?

In an attempt to help another user, I extracted a part of the code and put it in a stand-alone sketch. This is supposed to give an 8MHz square wave on pin 11 of an Uno

#define PIN11
void setup()
{
  cli();
#ifdef PIN11
  DDRB |= (1 << 3);//pin 11
  TCCR2A = (1 << COM2A0) | (1 << WGM21) | (1 << WGM20);
  TCCR2B = (1 << WGM22) | (1 << CS20);
  OCR2A = 0;//(F_CPU)/(2*(X+1))
#else
  DDRB |= (1 << 1);//pin 9
  TCCR1A = (1 << COM1A0) | (1 << WGM11) | (1 << WGM10);
  TCCR1B = (1 << WGM13) | (1 << WGM12) | (1 << CS10);
  OCR1A = 0;//(F_CPU)/(2*(X+1))
#endif
}

void loop()
{
}

I also (last week) acquired a relatively cheap logic analyser (Sparkfun version of Saleae); max 24MHz / samples.

The code seems to work; when enlarging the view, the frequency is 8MHz. But I observe gaps in the output as shown below at roughly every 150us; there is a slight variation.

timer2_8MHz.jpg1176×257 31.4 KB

Question is what possible causes are.
1)
328P processor; I doubt it.
2)
Pulseview / logic analyser; can be.
3)
User who does not know how to work with Pulseview / logic analyser; can't be excluded from the options.

Anybody any thoughts?

The connections are relatively simple. GND to GND with 10cm dupont,
CH0 and CH1 to D9 and D11 via 15cm dupont.

layout.resized.jpg1248×936 113 KB

The code shows that I'm also trying to user timer1 instead of timer2; it basically exhibits the same behaviour plus something else that I have to check in the datasheet.

I was thinking it was the millis() interrupt but when I changed your sketch to override the core library's main(), the output stayed the same. Then I noticed that when I change the sample rate on PulseView to 24 MHz the gaps disappear (though there is still some smaller variation in the frequency).

The logic analyzer is really a great tool. I got one of the Chinese Saleae Logic 8 clones for free as a promo and it's been really helpful for a couple of projects now.

I think there's an explanation from Dave Jones here:

pert:
I was thinking it was the millis() interrupt but when I changed your sketch to override the core library's main(),

Note that I used cli() in the beginning of setup.

I will have a look at the video tomorrow.

You're viewing an 8MHz signal with only 16MHz sample rate - I think it's an artifact of the sampling rate. Can you increase the sample rate? I suspect you'll see that you actually have a clean signal if you do.

Interrupts won't interfere with it - it'll work fine with interrupts enabled, it's using hardware output compare.

Thanks people for the replies.

@pert, Unless I miss something, I do not think that that is it. I know that the timing can be slightly off and hence can I see e.g. every N pulses a miss. But not every 1200 periods a miss of 80 periods.

@DrAzzy, as far as I can recall, 24Mhz still exhibits the behaviour. I'm aware that I'm working at the limits of what this little logic analyser can do and that 24MHz is not much of an improvement over 16MHz but it's the maximum that is supported. At 24MHz, the duty cycle becomes 66% instead of 50%; that one I can explain

===
I suspect that this has to do with the transfer from the logic analyser to my Windows 8 system. Just wanted to exclude user error or an abused processor; for the latter I will hook it up to another Uno or a Leo and see.

I will also contact Sparkfun to find out what the memory depth is; I could not find that in the spec. If that's only 2k, it might explain.

===
Next on the list an oscilloscope with reasonable specs. A 50MHz, 100MS/s will probably do in the AVR environment; correction allowed

Look at what Dave gets from the 2 MHz signal sampled at 8 MHz:

I'm just not seeing it I have no output, he just has a different frequency / duty cycle (if I understand it correctly).

I will keep it on "user error" or "expected equipment behaviour"

Thanks for the efforts.

It looks like just the same phenomenon to me. The expected frequency interspersed with periodic gaps:

Clipboard01.png1116×95 29 KB

Anyway, take it or leave it. I don't claim to know what I'm talking about. It's just that I've noticed the same phenomenon myself and remembered seeing the Dave Jones mention this "trap for young players" in a video I watched recently.

Anyway, take it or leave it.

I'm not un-thankful; appreciate the help.

It looks like just the same phenomenon to me. The expected frequency interspersed with periodic gaps:

Ah, I see now. Will toy further when I have a chance to play around reducing the generated frequency.

Thanks again.

I'll have to sort something else out as well; might be related to this but also might be related to the use of timer1 instead of timer2. Also generating a 8MHz signal

sterretje:
as far as I can recall, 24Mhz still exhibits the behaviour.

When you get a chance, give it a try just to be sure. I'm fairly certain we have the same logic analyzer. You'll see them with different stickers but I think they all have the same hardware and firmware inside, copied from the Saleae Logic 8. I get the same output as in the picture you posted at 16 MHz.

Although I'm convinced that I did see the same behaviour yesterday, I did not manage to reproduce today at 24MHz. I've tried several different sample settings.

The only thing noticeable now is the swapping of high and low at occasion what can be explained because the sample time is just slightly of from the 8MHz (or vice versa).

timer2_8MHz.24MS_s.jpg1176×203 33.3 KB

timer2_8MHz.24MS_s.overview.jpg1176×195 27.7 KB

timer2_8MHz.24MS_s.jpg1176×203 33.3 KB

timer2_8MHz.24MS_s.overview.jpg1176×195 27.7 KB

DrAzzy:
You're viewing an 8MHz signal with only 16MHz sample rate - I think it's an artifact of the sampling rate. Can you increase the sample rate? I suspect you'll see that you actually have a clean signal if you do.

+1
OP is sampling close to the Nyquist frequency and suffer from aliasing.

No idea about your problem, but I really dig that rhinoceros table top!

At least it still has a horn In the future, we will only see that in paintings like on this table cloth:(

To everybody else, I'm still trying to come to terms with this (not a request for further help currently).