Sigurthr wrote ...

Yep, it was shielded.

At first I didn't hand write a program for the tests, as it was a quick look into the viability, and I'm not very experienced with arduino's lower level programming side. Basically I used a simple sketch that had you enter in a frequency via serial monitor and it would configure timer.1 to output pulses at the chosen frequency. I compared the output via scope and digital frequency counter. Ar 1MHz it was rather accurate, something like 999,400Hz. At 280KHz it was off by about 30KHz, somewhere around 250KHz. At 100KHz it was pretty accurate again. At direct fractions accuracy was good, at more distant fractions errors were introduced.

My initial impression was that it was something to do with the programming so I went and used a simple fixed variable and as little code as possible to see try and eliminate programming error. I hard coded in 10uS on and 10uS off, but still used digitalWrite functions. The result was ~37KHz. Clearly digitalWrite execution time was a problem. I looked into directly writing the IO registers but didn't give it a try, as at this point it was already proving to be too much hassle.

So, that's why I keep bringing up instruction execution delays. I literally had nothing other than standard setup, variable initialization, and two digitalWrite commands with variable calls and I couldn't get it to keep up. Assuming you write highly efficient code for timer.1 and the control loop, directly write to registers to avoid digitalWrite, and avoid any other high level instruction functions you may get something workable, but I don't know if you'll be able to set it to 50KHz and actually get 50KHz out. You might have to set it to 70KHz and get 51KHz out and call it good enough.

Steve Conner wrote ...

You will need to do as much of the work as you can in the timer hardware to avoid issues like this. You also need to check that the timer you're using has enough resolution to generate an accurate frequency. The Arduino libraries do a great job of abstracting away differences in the hardware, but by the same token they also do a great job of hiding its limitations. Read the microcontroller datasheet very carefully.

I think the problem described by Sigurthr is really two separate problems. The first one was limited resolution of a hardware timer, the second was instruction execution delays.

If I had to build something like this tomorrow, I would use a 4046 PLL chip, a PIC, and a CPLD.

Ash Small wrote ...

I'm not familiar with the Arduino myself, but you will want to avoid any high level programming, as this does introduce significant dalays.

I used to write stuff in machine code years ago, which avoids all of the problems with high level language, as well as low level assembler stuff.

Typing in all those ones and zeros is pretty time consuming, though, especially if you make a mistake.

Linas wrote ...

PSoC5LP does have FPGA like analog and digital capability, aka hardware processing as well as Cortex M3 core for more advanced stuff.

Maybe sone one would try to do something with it ?

if not, go to STM32F429, it can run at 200MHz, at his point you can do loops with 20ns precision ( GPIO toggle will go up to 100MHz)