Creating very short pulses

[therealfreegeek]

I need to create a pulse train at s low frequency, say 5 to 50HZ, but the pulses need to be as short as possible, one FTM clock pulse would be ideal, or a few if necessary.

Running the FTM at 60MHz will give an ideal single clock cycle of 16.6666nS.

I will use a PIT to initiate the creation of the pulses but I am not sure of the best way to create the pulses from the FTM without external logic.

I would like to use the FTM output compare to set and then clear an output just one count apart, it would be great if somehow you could use two output compare channels to act on a single pin to achieve this, is it possible?

Can anyone suggest a solution?

I will be using the FRDM-K64 running at max seed.

[mjbcswitzerland]

Hi

Ensure you compile with optimisation enabled otherwise the code it generates may be taking a nap between the instruction writes.

I didn't use any tricks - running form Flash, 120MHz core, 60Hz bus - the GPO is configured to be in high speed mode otherwise the pulse is not even seen since the slew rate is too slow for it to change.

Regards

Mark

[therealfreegeek]

Hi Mark,

Yes the code seems not to be optimised for the two C instructions, they show up as;

00000b21:   ldr r3, [pc, #16]       ; (0xb34 <main+36>)
00000b23:   mov.w r2, #65536        ; 0x10000
00000b27:   str r2, [r3, #12]
00000b29:   ldr r3, [pc, #8]        ; (0xb34 <main+36>)
00000b2b:   mov.w r2, #65536        ; 0x10000
00000b2f:   str r2, [r3, #12]

I only have a debug option under my compile hammer, is there a tutorial anywhere showing how to create an "optimised" compile option, or a preconfigured optimised option that can be imported?

[therealfreegeek]

OK, I found this thread and now have nice short pulses.

how can i set the optimization level for a file?

The optimised code looks like this;

00000adb:   ldr r2, [pc, #12]       ; (0xae8 <main+28>)

00000add:   mov.w r3, #65536        ; 0x10000

00000ae1:   str r3, [r2, #12]

00000ae3:   str r3, [r2, #12]

And the pulse like this.

[therealfreegeek]

Hi Mark,

Thanks for the suggestion, it reduced the pulse width ten fold, but it is still at 50ns.

Were you running your code from RAM or using some other trick to get to 8ns?

Here is my pulse.

... and my clock settings

[mjbcswitzerland]

Hi

I have attached two FRDM-K64F binaries that can be loaded to test a slow pulse train:

- uTaskerV1.4.12_FRDM-K64F_1s_8ns.bin generates an 8ns pulse on the connector J1-pin 2 every 1s (1Hz)

- uTaskerV1.4.12_FRDM-K64F_1s_35ns.bin generates a 35ns pulse on the same output at the same rate

The first one, with fastest pulse, is obtained by simply togging a port twice in a PIT interrupt.

The second uses PIT DMA trigger to write to the port toggle register twice in a row each time it triggers.

Analysis of possibilities.

- It is best to use a PIT to trigger either an interrupt or DMA because it can generate very slow frequencies. FTM (16 bit counter) can only generate about 8Hz and above when the K64 is working with 120MHz system frequency.

- If a PIT is used as time base (and interrupt) there is no need to use it to trigger an FTM pulse generation since it is more work (overhead) and even if a method can be found to efficiently generate the two output changes (it could be done with additional DMA and unnecessary complication which will slow it even more) it will be slower that the port toggle.

- Port toggling doesn't limit the used output to be a particular peripheral port (and GPIO can be used).

- If absolutely no processor overhead is desired (no PIT interrupt handling) it is possible to do it by allowing the PIT to free run and generate DMA triggers (see second binary). This in fact continues to operate even when the processor is halted with the debugger as long as the timer can continue to run. Although it has no CPU overhead to toggle the ports, the actual rate is limited by the way that the DMA operates since its back-to-back port writes are not as fast as two CPI instruction writes, thus causing a longer pulse width of around 35ns instead.

- Lowest possible periodic jitter is expected with the DMA method since there is no interrupt latency which may be influenced by higher priority interrupts in progress or when critical code regions are being executed (that temporarily block interrupt handling), as well as during Flash erasure/programming periods.

Regards

Mark

[therealfreegeek]

Hi Mark,

Thanks for the suggestions, I tried toggling a pin in the PIT interrupt already but was very disappointed with the results (really long pulse) but I was using KSDK drivers to set and clear the pin, I will take another look at that and report back.

I suspect the drivers have a lot of overhead.

Thanks

Jim

[mjbcswitzerland]

Jim

To create a pulse on a port output simply use:

GPIOn_PTOR = x;

GPIOn_PTOR = x;

Where n is the port (A, B, C, etc.= and x is the port bit (or multiple bits).

In an interrupt handler that won't be interrupted this will take give an 8ns pulse when the core is running at 120MHz.

Beware that you will need a fast oscilloscope or analyser (1G samples/s) to accuratey measure the pulse.

Regards

Mark