Just to finish the series on Raspberry Pi I/O – here’s proof of its GPIO pulsing speed:
The trouble is the irregularity caused by Linux’s multi-tasking properties, and I wanted to show you some examples of that. After a few dozen captures, I came up with this one:
Looks pretty bad, right? Tons of hickups in what was meant to be a 5.2 MHz pulse train.
Not so fast…
The sample rate used by the oscilloscope for this capture was 10 MHz, so it’s sampling the signal at 100 ns intervals. That’s extremely risky, because when the signal is also pulsing at this rate, you might end up missing each peak for a substantial amount of time. This would make it appear as if the signal was low or high all the time, despite its rapid changes.
This effect is called “aliasing”, and the solution is simple:
Do Not Sample At A Rate Close To The Frequencies In Your Signal!
I’m inclined to discard the above snapshot – it’s probably a measurement artefact.
Here’s another screen, this time at 50 MHz sample rate, i.e. 20 ns between captures:
At that rate, it’s impossible to miss pulses which are all in the range of 100 ns or longer. As you can see, there are still glitches (almost on every snapshot there is one), but it’s not as bad as the previous screen shot was suggesting.
Anyway. Enjoy your RPi and all the Linux high-level stuff it can do (like, ehm, run the Arduino IDE and cross-compile stuff for ATmega’s), but beware of treating it like a CPU which is exclusively at your service.
A Raspberry Pi is fast most of the time, but it’s (occasionally) a bit occupied with itself…