Ok that seems to make sense. Note sometimes I tend to mix up wave file with the wav as in the signal you are processing. In this case I was interesting in dumping the output of what the values getting passed to the dac so I could plot and review; but I suspect it wont be needed as per the following comments.
So if its working fine at low freqs, then it does sound like the issue is the sin wave resolution as you said.
Been a while since I played with the Pi Pico and when i did I was using C code and direct flash so no python getting in the way.
from memory the clock rate is 125 MHz. That being the case, it sounds like it should be fast enough, but i do understand there is overhead getting in the way.
I have an esp32 dual core running at 240 Mhz trying to bit bang to a jtag interface to read the Chip ID (and a few other things) and the fastest I could get that was 1Mhz at the jtag clock pin; so yeah… i understand.
A few things I learnt about trying to get it faster was tracking down the overhead. So the following are more thoughts as I dont know enough about python to say for sure.
-
Calling functions to do work while trying to clock out data will have overhead. the more inline code you have, the faster it should run. e.g. Memory permitting, you could create a higher resolution sin wave at what ever freq you need, store that in an array, then simple clock that out. That should drop sum funcation calls and the math, all taking up cpu ticks.
-
As you already found setting pin outputs takes time so any faster ways to do that would help. e.g. is there a direct register way or do you need to use a function call.
-
IRQ and running code on events takes too much cpu time.
The simplest way to work out the 100% upper limit would be to have a very tight loop and just toggle a single IO pin and check that on the scope.
e.g. assuming no other instructions and guessing over simplified, something like the following would happen
while (true)
setpin high
setbin low
If we said 2 CPU ticks per line (for an example) and we need to jump back to the while, we have 8 CPU ticks per loop pass; so 125 Mhz / 8 = 15 Mhz (rounded)
We can also look at this in reverse.
if we can clock at say 1 Mhz, then 125Mhz/1 = 125 ticks per loop pass to do all the work; which I would say is not much work is going to get done.
but if we have a pre calculated sin wave at 1000 samples per cycle, then we have 125,000 cpu ticks to clock it out.
Of course all this depends on the python and other overhead.
Please note: The key point I am trying to make with some made up example data, is to increase the wave resolution, you need more samples. to get more samples you need to minimize anything getting in the way.
