It’s also possible that micros() doesn’t have the resolution you would expect. Could you run yourFunction like 100 times, and then divide the timing result by 100 to see if this makes a difference?
Allows me to measure a pulsetrain on pin 20 of 700 kHz. A bit more than 500 kHz. but still remarkably little considering it is a 700 MHz clock - if I understood it correctly:
Still working on it … I would like to see an ideal 2 or so Mhz (the more the merrier)
My next test would be using the low level RTOS software to see if I can manipulate the register directly… (from the Arduino code, it doesnt that over 4+ function layers.
Has anyone gotten any additional answers on why the small core is so slow? I set up my own arduino GPIO toggle sketch and found the best I could get is 500KHz toggling. I found this thread while looking for answers.
I’m working on a project that does bit banging to simulate some hardware. It works on the Pi Pico which is much slower, and I was really excited to port it to the MilkV Duo because I could run Linux on the big core and have a lot more RAM for buffering.
I’m really struggling to understand the results others in this thread have had. Pure assembly only getting 3MHz toggle on a 700MHz RISC-V core? It makes no sense to me.
Is there something slow in the internal peripheral bus that is causing this slowdown, or is the big core somehow taking priority?
Has anyone tried a toggle on the big core to see how fast it can go? If the big core can achieve reasonable speeds then I could probably get away with running my code on the big core. I could make due without Linux and still be ahead of the RPi Pico with the extra RAM, which is more important to me.
I’ve been looking at other threads I could find related to this, like interrupt latency on the little core. It almost seems as if the clock on the little core is not actually being configured correctly.