What's the fastest clock you have generated on a GPIO pin of an ARM dev board

[tggzzz]

Has anyone been able to bit bang a 20 MHz clock on any arm dev board ? If so, could you share your arm board. I would like this to be done with a program, rather than assembly code, and look like:

while(1) {
  write GPIO 1;
  write GPIO 0;
}

I may be a purist, but that techinque is not useful for determining the frequency of a clock. It is useful for determining the minimum interval between two transitions.

Why?

• the CPU cannot be doing anything else at all. If interrupts cause it to do something else, then the intervals will obviously be extended. If the clock is only intermittent then there will extra tests in the while clause. If data is to be transmitted then there will be extra statements in the loop body.
• depending on the CPU, what is/isn't in a cache will cause timing variations, resulting in jitter

[photon]

I opened this thread to find out if it were possible to bit bang a SPI bus at 20 MHz using one of the arm dev boards. I decided to first ask an easier question to find out how fast you can toggle a pin. But, now that this question is answered and you bring up the issues involved, is it possible to bit bang a SPI bus at 20 MHz? Has anyone done this? Even though arm boards have hardware SPI it might be useful to have a software SPI if you want to debug or test another SPI interface by injecting problem cycles, or be able to use a mode of the SPI bus not implemented by the hardware.

[Brutte]

is it possible to bit bang a SPI bus at 20 MHz? Has anyone done this?

Yes, it is possible. But I doubt anyone tried that when a $2 chip has three hardware SPI modules. If you need fourth SPI, then these are present in $3 chips.

[Howardlong]

is it possible to bit bang a SPI bus at 20 MHz? Has anyone done this?

Yes, it is possible. But I doubt anyone tried that when a $2 chip has three hardware SPI modules. If you need fourth SPI, then these are present in $3 chips.

I'd tend to agree, if I need to generate time critical 20MHz SPI, then I'd be unlikely to be doing it by bitbanging. That said, if the bitstream was constant and you chose the right GPIO pins on the same port, you could generate 100MHz SPI with bitbanging.

[photon]

I may be a purist, but that techinque is not useful for determining the frequency of a clock. It is useful for determining the minimum interval between two transitions.
Why?

• the CPU cannot be doing anything else at all. If interrupts cause it to do something else, then the intervals will obviously be extended. If the clock is only intermittent then there will extra tests in the while clause. If data is to be transmitted then there will be extra statements in the loop body.
• depending on the CPU, what is/isn't in a cache will cause timing variations, resulting in jitter

For an OS like a PC or Linux, then I agree. For a real-time system interrupts can be masked and latencies controlled. A SPI clock only has to run during a bus transaction. Otherwise it is off. There are no caches, data or instruction, in a Cortex M micro. The term "bare metal" compiler means something here.

[Howardlong]

You need to be a little careful when running from SPIFI flash on the LPC4300 series, except for very trivial things (like the example provided), there is some indeterminism due to the proprietary mechanism used to make the quad SPI flash appear in the memory map like normal memory. There is some caching going on as well as occasional significant wait states on cache misses. The simple way to avoid this is to put the code into one of the RAM segments on a dedicated bus, where the memory runs at core speed (using the RAMFUNC modifier).

[tggzzz]

I may be a purist, but that techinque is not useful for determining the frequency of a clock. It is useful for determining the minimum interval between two transitions.
Why?

• the CPU cannot be doing anything else at all. If interrupts cause it to do something else, then the intervals will obviously be extended. If the clock is only intermittent then there will extra tests in the while clause. If data is to be transmitted then there will be extra statements in the loop body.
• depending on the CPU, what is/isn't in a cache will cause timing variations, resulting in jitter

For an OS like a PC or Linux, then I agree. For a real-time system interrupts can be masked and latencies controlled. A SPI clock only has to run during a bus transaction. Otherwise it is off. There are no caches, data or instruction, in a Cortex M micro. The term "bare metal" compiler means something here.

I agree about the CPU, hence my prefixing the statement with "depending on the CPU". Ditto "If" in the statement about interrupts. I'm fully aware of the implications of bare metal; I've even declined to use the Arduino environment for an atmega328, since I knew I couldn't predict what assumptions were in the libraries

The other, more important, points about the CPU not being able to do anything else stands, for the reasons given.

Hence this technique is only useful for determining the minimum interval between two transitions - it is not useful for determining the frequency of a clock.

[jimon]

Easy to get 120 MHz from stm32f407 by overclocking it to 240 MHz, a bit pointless though.
On other hand it's possible to run transmission "bursts" like this - you generate transmission code in RAM, and then jump to it. This could be useful for simpler MCU that doesn't have ability to transmit with DMA.