ARM fastest possible pulse

[eurofox]

I'm new with ARM, maybe some guru could help me how I can get the fastest possible pulse to an output from an ARM CPU.

The idea is to generate a programmable pulse generator and avoid to use an extra DDS.

Time and duration should be stable, it will go into a programmable delay line.

Thank in advance.

eurofox

[dannyf]

The fastest would be to use BSRR to flip a pin. If you fill the rom with that, you get 1/2 of the instruction frequency which varies a lot from chip to chip, from tends of Mhz to hundreds of Mhz.

[dannyf]

Another approach is with DMA to a port / pin. You have finer control over the timing / data.

[mikeselectricstuff]

Depends entirely on the peripheral and IO architecture. The answer will usually be to use a timer/compare peripheral

[David Hess]

The fastest would be to use BSRR to flip a pin. If you fill the rom with that, you get 1/2 of the instruction frequency which varies a lot from chip to chip, from tends of Mhz to hundreds of Mhz.

The GPIO interfaces usual operate at a fraction of the core clock severely limiting toggle rate.

[Jeroen3]

Use a timer match, SPI or SGPIO peripheral.

[poorchava]

fresh example: SAM4S series uC. At 120MHz, using pure assembly, bit-banding and unrolled loop (eg. STR [addr1], 1; STR [addr2] 1, STR [addr1], 1..... etc) the result was 10MHz. Output drivers do well up to 30-ish MHz.

STM32 outputs can do up to 50MHz, obviously using timer, above that you get a sine-like waveform. Aside from timers, also hardware SPI can be used to generate very fast square waves. Just setup DMA to write indefinitely from some address.

[JDubU]

I just did a test with a STMF4 Discovery board running at 168MHz system clock and am getting 27.77MHz square wave output (18ns pulses) using only BSRR writes to toggle pin GPIOD15.

[AndyC_772]

I've just done a design with an STM32F205. It runs at 120 MHz, and some of the timer peripherals run at the full core speed, so you should be able to get pulses that are 8.3ns wide using that device.

[Jeroen3]

You are probably limited to clock input/output pins when you're going above 50 MHz.

[T3sl4co1l]

It's unlikely you'll get much faster, as pin drivers aren't usually too elaborate (even FPGAs don't usually drive full CMOS logic levels into the 100s of MHz, those are for differential lines), and IO is often in a different clock domain, not always the case with simpler ones (ATmega uses the same clock everywhere, except for prescalers into counters/timers; similar way with the smaller ARMs, say up to 50MHz or thereabouts), and definitely not the case for anything with a core multiplier.  If nothing else, having "instantaneous" response is unlikely, with clock domains and pipelining at play.

At least in the old days (say, 486/Pentium), I think IO instructions were some of the slowest, ever, since they had to flush through cache.  I don't know if modern hardware (among x86 or embedded) has pipelined or cached IO.  Hopefully, the embedded processors we're talking about here will be well enough documented to determine that -- in which case, RTFDS.

Tim

[westfw]

The fastest would be to use BSRR to flip a pin

That's a very ST-specific answer...
TI Tiva for example has GPIO accessible via two different buses, and says:

Fast toggle capable of a change every clock cycle for ports on AHB, every two clock cycles for ports on APB

It's also dependent on pin configuration and perhaps flash speed (and caching effectiveness.)  One of the complaints that 8bit programmers have about 32bit arm chips is the loss of easy determinism in figuring out this sort of thing.

[Laurynas]

Check out Cypress PSoC devices, their programmable logic may be useful here.

[dannyf]

At 120MHz, using pure assembly, bit-banding and unrolled loop (eg. STR [addr1], 1; STR [addr2] 1, STR [addr1], 1..... etc) the result was 10MHz.

10Mhz sounds very low.

[dannyf]

Here is the disassembly from Keil, under O1:

Code: [Select]

    89:                 LED_PORT->BSRR = LED_C;       //set led_c
0x08000F82 61A5      STR      r5,[r4,#0x18]
    90:                 LED_PORT->BSRR = LED_C<<16;                              //reset led_c
0x08000F84 61A1      STR      r1,[r4,#0x18]

Without optimization, each C statement is turned into two instructions.

So unless your gpio is on a slow bus (apb1/2 for example, with prescaler), you should be able to get very fast IO actions.

PS: the above code uses the higher 16-bits to reset the ODR bits. Another approach is to use the BRR register -> no sheet for that shift.

[Jeroen3]

If you want to do this in software there are some things to consider.

Flash has access time, and might have a cache or prefetch miss. SRAM doesn't, have your program load itself in executable SRAM.
Use a minimal Cortex M3 since a Cortex M0 will need at least 2 bus cycles. Since the M0 only has System Bus, and no I and D bus.
Code the running part assembler, since then you have full control over all instructions, even with future versions of the compiler and optimizer.
Turn off interrupts, and don't try to multitask.

Using peripherals it can get more resolution if you have a chip with an fractional (audio) pll connectable to a timer or spi shift register.

[dannyf]

Hard coding a pin flip is the least efficient approach from space / mcu utilization point of view. But it is the simplest.

Otherwise, DMA is on the other spectrum - once it is set-up, it uses little mcu processing power. Through the mcu, you can write to the port directly, or you can go through a peripheral (like spi). It also offers better resolution and flexibility -> by adjusting the data to be sent through DMA, you can change the pattern or frequency.

[timb]

Tiva C chips can manipulate pins on certain ports every cycle. They also have special high resolution PWM timers that can go very fast, very accurately!


Sent from my Smartphone

[dannyf]

Whether a pwm generator works will depend on the requirement. For a fixed frequency, it certainly works.

If you wish to generate glitch free variable frequency pulses, you have to use center-aligned pwm and it will not be anywhere close to the flip-a-pin approach.

[Jeroen3]

Note that using a DMA can still introduce jitter since the bus is still shared.
A peripheral is the best approach. However, there will be accuracy and stability error due tot the oscillator, pll, and undocumented timings inside the chip.
I'd suggest using programmable logic for high speed pulse generation. Maybe one of those hybrid devices can help you out?
You can also put an arm inside HDL, but that is probably out of budget scope.

[Brutte]

217ps

[tggzzz]

217ps

That's resolution of a pulse's leading/trailing edge, not necessarily pulse width! Or can they really output a >4Gb/s (i.e. >2GHz) signal?

[splin]

If you're not already committed to a particular device, you might want to look at the STM32F3x4 range. These have 6 timers with resolution down to 217ps or equivalent to a 4.6GHz. Is that fast enough?

They are only 16-bit timers though so  if you want a PWM output < 70.3 kHz you need to pre-scale the clock which reduces the resolution. EG. for a PWM frequency in the range 4.4 kHz to 8.8 Hz you need a pre-scaling ratio of 16 which reduces the resolution to 3.47ns

I somewhat doubt however, that you could us it to generate a 2.3GHz clock or pulse widths of 217ps by the time it gets out of an I/O pin!

Also remember that the processor clocks are PLL multiplied from the crystal/external clock so phase noise, jitter and wander could be quite poor.
 
Freescale have also announced the motor control targeted 150MHz M4 core sub-family with 312ps resolution 16-bit timers. Don't know when they will be available though.

There are also 32 bit PIC devices with high resolution timers.

Splin

PS. I see someone beat me to it while I was typing this in!

[paulie]

It might be of interest to know that pulse frequency can be doubled using a simple quad xor gate. So whatever an MCU can produce you can multiply that x2 for pennies.

[westfw]

I think the original poster has disappear in the hail of controversy.

"fastest pulse" is a different question than "highest frequency"...

On ST microcontroller, don't forget that there are clock prescalers for the relevant bus to set, and a GPIO_Speed setting in the GPIO_InitStructure (or bare registers.)  I don't think I'd trust those to be set for maximum speed by default.