Short pulse creation and code optimisation

[therealfreegeek]

I am trying to create two ~10ns pulses with a separation of ~20ns or so.

I am using a FRDM-K64 running at full speed.

I was able to get the waveform below with port toggle writes which is close to what I want.

The code is triggered in a PIT interrupt routine and has been working well for a few weeks. The interrupt file "events.c" is optimised in its miscellaneous properties with -O3.

The code I use is:

GPIOC_PTOR = 0x00010000; // Toggles PortC-16 by writing a 1 to the toggle register port bit

GPIOC_PTOR = 0x00010000; // Toggles PortC-16 by writing a 1 to the toggle register port bit

GPIOC_PTOR = 0x00010000; // Toggles PortC-16 by writing a 1 to the toggle register port bit

GPIOC_PTOR = 0x00010000; // Toggles PortC-16 by writing a 1 to the toggle register port bit

and the assembler is;

00001607:   mov.w r2, #65536        ; 0x10000

0000160b:   str r2, [r3, #12]

0000160d:   str r2, [r3, #12]

0000160f:   str r2, [r3, #12]

00001611:   str r2, [r3, #12]

Today I was experimenting with various instructions between the two pulses to create  a 20ns delay, but was not able to get anything below 70ns or so, even with just a NOP between the pulses.

But when I went back to my original code and recompiled I ended up with the waveform below and I cant get back to my original.

Do you have any idea what would cause this to change in this way?

Also, do you have any suggestions on an instruction that will cause a delay shorter then ~70nS.

This code

00001606:   mov.w r2, #65536        ; 0x10000

0000160a:   str r2, [r3, #12]

0000160c:   str r2, [r3, #12]

0000160e:   nop

00001610:   str r2, [r3, #12]

00001612:   str r2, [r3, #12]

Looked like this;

[mjbcswitzerland · Accepted solution]

Hi

Don't forget that code running from Flash may be subject to changes in execution time depending on the speculation operation and caching. This means that changes to the code 'may' cause routines that you have previously tuned to have quite different timing.

The Flash operates at max. 24MHz and so any faster execution is acheived by these techniques, which are not however guaranteed to be consistent.

I would put special code that requires guaranteed timing behavior in SRAM, where it will run at a higher speed and (probably) be more consistent. You may also prefer to ensure that its operation is excluded from the cache so that it won't have any possibility of jumping around in case the close-coupled cache does allow it to be executed slightly faster in sime circumstances.

Regards
Mark

[therealfreegeek]

Thanks, by adding a nop just before the first toggle I was able to manipulate the way the code executed and get just what I needed, thanks.