Author Topic: What's the fastest clock you have generated on a GPIO pin of an ARM dev board  (Read 11089 times)

0 Members and 1 Guest are viewing this topic.

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 12451
  • Country: gb
    • Having fun doing more, with less
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
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline photon

  • Regular Contributor
  • *
  • Posts: 234
  • Country: us
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.
« Last Edit: January 02, 2016, 08:57:34 pm by photon »
 

Offline Brutte

  • Frequent Contributor
  • **
  • Posts: 614
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.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4938
  • Country: gb
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.
 

Offline photon

  • Regular Contributor
  • *
  • Posts: 234
  • Country: us
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.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4938
  • Country: gb
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).
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 12451
  • Country: gb
    • Having fun doing more, with less
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline jimon

  • Regular Contributor
  • *
  • Posts: 159
  • Country: se
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf