MCF52235 GPIO and core synchronization

[ariaveta]

Hello,
I'm trying to use a MCF52235 GPIO to output a digital waveform. It is clocked by a 25 MHz oscillator, and PLL is configured to produce a system clock of 60 MHz.

I discovered that I cannot generate precise pulses: the duration of the pulse is random even if I use assembler and TRAPF instructions to control it.

If I try to generate a pulse 500 ns long, for example, I get a pulse log 500+- 32ns, randomly.

Could someone please explain this? Is there an absolute maximum in the random component?

Thanks,
Marco


Message Edited by ariaveta on 2008-05-08 11:32 PM

[bkatt]

The General Purpose Timer (GPT) is designed to do this sort of thing. You would set it up to toggle on output compare, then go into a loop or interrupt sequence that waits for the timer compare event, then adds the next delay interval to the compare register.

[ariaveta]

Thanks for the advice. Do you have any code to show how to do this?

I'm trying to figure out how the timer could be driven by the core without any random delay in the reload of the compare register.

Marco

[bkatt]

Start the timer at zero and the compare register at some value, call it a. When the timer reaches a, the output will toggle and a status bit is set. Note that the timer keeps counting. Your program sees the status bit, and adds a new value, b, to the compare register. The compare register is now a+b. When the timer reaches a+b, the output toggles again, the status bit is set again, and your program can add a new value, c, to the compare register, which becomes a+b+c.

You can continue as long as needed; both the timer and the compare register wrap around after 65535. The timer counts steadily forward with no random delays. Your program can vary its execution speed as long as it detects the status bit and completes the add to the compare register before the timer gets to the next value.

[ariaveta]

Thanks for your kind answer.

I just tried the approach you suggested; it seems quite good.

In my case, however, I need to generate a train of non periodic pulses lasting exactly 500ns. The core of the MCF52235 runs up to 60 MHz, so I have to reload the value 29 into the register (because I need 30 clock cycles to reach 500ns) to shape the smaller pulse of my signal.

So I filled an array with all durations, then tryed to use it to load the counter after each compare event match. I found that I cannot reach the 500ns because I have not enough clock cycles to fill the compare register of the DMA timer, increment an index and wait for next match event.

I think there's no way to generate a train of 500ns pulses using MCF52235@60Mhz.

Thanks again for your suggestion,

Marco

[admin]

You wrote "I need to generate a train of non periodic pulses lasting exactly 500ns."

Could you example any "train of non periodic pulses lasting exactly 500ns"? How many pulses until stop? Do you mean all the intervals and durations are unique? What is the minimum time duration, that all the intervals are multiple of it?

[ariaveta]

Hello, and thanks for your answer.

I'll try to explain what I need to do.

Let's use P to indicate a pulse lasting 500ns. For "pulse" I mean a digital signal switching from level 0 to level 1 at time 0, remaining at level 1 for 500ns, then switching to level 0 again.

Let's use Z to indicate a signal which remains at 0 for 500ns.

Let's use L to indicate a pulse lasting 1000ns, ie a digital signal switching from level 0 to level 1 at time 0, remaining at level 1 for 1000ns, then switching to level 0 again.

I need to generate someting like this: ... ZZPZPZZZZPZPZZZPZLZLZPPZZP...

The exact sequence is not always the same (it depends from variable data). The number of pulses until stop may vary from 60 to 120, also depending on data.

All intervals are multiple of 500ns. The 1000ns pulses, however, can't be obtained by concatenating 2 500ns pulses because there's no return to 0 after the first 500ns.

I tried to obtain this sort of thing in three different ways using MCF52235:

1) Using QSPI: I configured the QSPI to produce pulses of 500ns, then I loaded data in the QSPI transmission register and started the peripheral. The result was good, but I cannot prevent the QSPI from inserting a little delay between bursts. So I abandoned this approach.

2) Using GPIO: I wrote a little assembler routine which toggled the status of a GPIO pin based on data; I inserted some delay to ensure the toggling lasts 500ns exactly. It worked *perfectly* on two different MCF52235 evaluation boards; after we made the first prototype, however, we realized that there was a random jitter in pulse duration: the jitter was of 32 or 64 ns. For example: if a P pulses lasts, say, 500-32 ns, the following Z "pulse" lasts 500+32 ns. We *suppose* this is due to synchronization between Coldfire core and GPIO. We haven't been able to discover this reading the manual.

3) Using DMA timer: this is the solution that gives no jitter in pulse duration. However, this is not good for us, because 500ns (30 clock cycles) are not enough to toggle the pin, reload the  counter, and check for new data. Then minimun duration we were able to handle was about 60-70 clock cycles. Of course, there's no jitter in pulses generation.

After loosing the battle against jitter, we give up and used an external CPLD to retime the signal coming from GPIO (solution 2).

Any better solution?

[bkatt]

---

ariaveta wrote:
...500ns (30 clock cycles) are not enough to toggle the pin, reload the  counter, and check for new data....

---

Since you were able to get down to the 500 ns range by bit-banging the GPIO, you should be able to get there with the GPT technique. A hand-optimized inner loop would only be 4 instructions, such as:

top:
    btst.b      #0,(a1)
    beq          top
    move.w   (a0)+,(a2)
    bne          top

where #0 refers to timer 0 (bit 0), a1 points to the GPTFLG1, a2 points to the GPTC0, and a0 points to a table of already-summed compare values (shorts) ending with zero. This takes advantage of the fast-clear and auto-toggle features of the GPT.

[admin]

You can try one of the following ideas.

1. Use GPT channel3 with setting the output pin value via GPTOC3D register.

Arrange interrupt by the tmer overflow each 500ms.

In ISR, copy from SRAM to GPTOC3D the configuration value for next 500 ms.

I hope, that such SRAM-to-GPTOC3D copy can be implemented within 500 ms -before the next tmer overflow event.

2. Use 4-channel GPT with interlaced compare events. This way is more sophisticated, but it reduces CPU time and SRAM consumption.

Configure all 4 channels to roll FFFF->0000 simultaneously each 2000ns.

Interlace the compare events between the channels: set the 16-bit comparator value of channel0 to  0ms, set the 16-bit comparator value of channel1 to 500ms, set the 16-bit comparator value of channel2 to 1000ms, set the 16-bit comparator value of channel3 to 1500ms.

Enable interrupt for timer overflow event of the single channel only.

In the ISR, write GPTCL1 with the next SRAM stored set/clear OCNx pin configuration byte for the next four 500ns intervals. I hope, that such SRAM-to-GPTCL1 copy can be implemented within 500 ms -before the next compare event at channel 1.

To Possibly, you will need to clear (single time soon after the start) all 4 channels simultaneously by pulse at the tied SYNCx pins.

The four output pins needs to be either ANDed or ORed.

[admin]

To generate pulses with precise timing, you need to use TOUT pin of a hardware timer.

Various RTOS or hardware or other background housekeeping activity (which consumes either core or bus clocks) isn't synchronized with your application. Thus, you will see random change of the execution time of the same code.

Note, that 32 ns is close to duration of two 60 MHz clocks.