ARM fastest possible pulse - Page 1
Forum section: electronics / general

author: eurofox
author_rank: Unknown
timestamp: September 11, 2014, 02:26:57 pm
content: 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

author: dannyf
author_rank: Super Contributor
timestamp: September 11, 2014, 03:01:24 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: September 11, 2014, 03:03:16 pm
content: Another approach is with DMA to a port / pin. You have finer control over the timing / data.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 11, 2014, 03:24:54 pm
content: Depends entirely on the peripheral and IO architecture. The answer will usually be to use a timer/compare peripheral

author: David Hess
author_rank: Super Contributor
timestamp: September 12, 2014, 04:08:55 am
content: Quote from: dannyf on September 11, 2014, 03:01:24 pmThe GPIO interfaces usual operate at a fraction of the core clock severely limiting toggle rate.

author: Jeroen3
author_rank: Super Contributor
timestamp: September 12, 2014, 05:31:48 am
content: Use a timer match, SPI or SGPIO peripheral.

author: poorchava
author_rank: Super Contributor
timestamp: September 12, 2014, 05:39:01 am
content: fresh example: SAM4S series uC. At 120MHz, using pure assembly, bit-banding and unrolled loop (eg. STR , 1; STR  1, STR , 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.

author: JDubU
author_rank: Frequent Contributor
timestamp: September 12, 2014, 06:22:29 am
content: 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: September 12, 2014, 06:53:15 am
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: September 12, 2014, 07:01:34 am
content: You are probably limited to clock input/output pins when you're going above 50 MHz.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 12, 2014, 07:23:38 am
content: 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

author: westfw
author_rank: Super Contributor
timestamp: September 12, 2014, 07:27:23 am
content: QuoteThat's a very ST-specific answer...TI Tiva for example has GPIO accessible via two different buses, and says:QuoteIt'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.

author: Laurynas
author_rank: Contributor
timestamp: September 12, 2014, 08:19:54 am
content: Check out Cypress PSoC devices, their programmable logic may be useful here.

author: dannyf
author_rank: Super Contributor
timestamp: September 12, 2014, 10:41:38 am
content: Quote10Mhz sounds very low.

author: dannyf
author_rank: Super Contributor
timestamp: September 12, 2014, 10:52:34 am
content: Here is the disassembly from Keil, under O1:Code:89: LED_PORT->BSRR = LED_C; //set led_c0x08000F82 61A5 STR r5,[r4,#0x18]90: LED_PORT->BSRR = LED_C<<16; //reset led_c0x08000F84 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: September 12, 2014, 12:08:22 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: September 12, 2014, 12:25:36 pm
content: 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.

author: timb
author_rank: Super Contributor
timestamp: September 12, 2014, 12:53:01 pm
content: 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

author: dannyf
author_rank: Super Contributor
timestamp: September 12, 2014, 02:22:24 pm
content: 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: September 12, 2014, 02:32:30 pm
content: 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.

author: Brutte
author_rank: Frequent Contributor
timestamp: September 12, 2014, 05:25:48 pm
content: 217ps

author: tggzzz
author_rank: Super Contributor
timestamp: September 12, 2014, 05:38:20 pm
content: Quote from: Brutte on September 12, 2014, 05:25:48 pmThat'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?

author: splin
author_rank: Frequent Contributor
timestamp: September 12, 2014, 05:56:15 pm
content: 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.47nsI 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.SplinPS. I see someone beat me to it while I was typing this in!

author: paulie
author_rank: Frequent Contributor
timestamp: September 12, 2014, 10:14:54 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: September 12, 2014, 10:25:48 pm
content: 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.

author: eurofox
author_rank: Unknown
timestamp: September 12, 2014, 10:40:36 pm
content: Quote from: westfw on September 12, 2014, 10:25:48 pmI still watching with really a lot of interest and really appreciate all inputs, I think I will try some of the ideasBefore I build the hardware I will test it on my STM32FA4 discovery board.I'm quite experienced with PIC's and other 8 and 16 bits CPU's, the ARM is new for me and I really look forward to start discovering is CPU.eurofox

author: dannyf
author_rank: Super Contributor
timestamp: September 12, 2014, 11:53:56 pm
content: QuoteDepending on your ability to read the datasheet, the learning curve can be steep.

author: eurofox
author_rank: Unknown
timestamp: September 13, 2014, 12:07:14 am
content: Quote from: dannyf on September 12, 2014, 11:53:56 pmI have time since I'm retired

author: dannyf
author_rank: Super Contributor
timestamp: September 13, 2014, 12:11:31 am
content: Time is not as big of an issue as persistence / perseverance - you will eventually get there if you keep trying.

author: David Hess
author_rank: Super Contributor
timestamp: September 13, 2014, 03:08:10 am
content: In the fastest mode, it looks like the output ports of the STM32F344 are good to 50 MHz with 5 nanosecond rise and fall times. Internally it uses a tapped delay line and 144 MHz clock so there may be other limits to the minimum pulse width with the high resolution timer but I did not find them in the documentation.

author: Psi
author_rank: Super Contributor
timestamp: September 13, 2014, 03:35:51 am
content: I think some of the STM timers can be setup in 'one pulse' mode for generating a narrow pulse.So you should be able to get a pulse out that's the same as the timer clock rate. Assuming the I/O clock is fast enough.

author: westfw
author_rank: Super Contributor
timestamp: September 13, 2014, 04:08:07 am
content: No one has yet mentioned that if you're going to be generating 50MHz signals, you'd better be paying a lot of attention to the PCB design of that signal and it's connection to whatever it is connected to. There are a lot of Arduino users (for example) who think that going from Uno (16MHz AVR) to Due (84Mhz ARM) they'll suddenly be able to run their SPI over jumper wires to a breadboard 5x faster, and that doesn't seem very likely to me...

author: paulie
author_rank: Frequent Contributor
timestamp: September 13, 2014, 09:14:31 pm
content: Quote from: westfw on September 12, 2014, 10:25:48 pmI think you are confusing this with the one dollar one minute thread. However that OP will NEVER be scared off. LOLQuote from: westfw on September 12, 2014, 10:25:48 pmTrue, I was taking the title literally. For programmable delay line it should have said "highest resolution pulse" or "fastest controllable pulse". XOR would be the path to simply fastest.

author: Jeroen3
author_rank: Super Contributor
timestamp: September 15, 2014, 07:35:52 am
content: Quote from: westfw on September 13, 2014, 04:08:07 amThe attenuation of a long (30 cm) two-layer design board with planes is workable up to 60 MHz. Then it becomes a sine and fades out very fast.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: September 15, 2014, 07:40:14 am
content: Quote from: Jeroen3 on September 15, 2014, 07:35:52 amNo, not nearly so bad. It's about two orders of magnitude better than this. You do need to be aware of proper signal quality however. Not because of rounding off, but because of ringing.Tim

author: David Hess
author_rank: Super Contributor
timestamp: September 15, 2014, 05:29:50 pm
content: Quote from: T3sl4co1l on September 15, 2014, 07:40:14 amIt is amazing what can be done with 100+ MHz clocks on FR4 with proper terminations and ground returns.

author: dannyf
author_rank: Super Contributor
timestamp: September 15, 2014, 06:57:12 pm
content: -you get 1/2 of the instruction frequency which varies a lot from chip to chip, from tends of Mhz to hundreds of Mhz. -that assumes a fast bus on gpio. Stm32f4 for example can go to 84mhz - 168mhz / 2 .on a f0 chip, the fastest is clock / 4 = 16mhz. The same with f1 chips = 18mhz.