STM32F4 timing application question

[jamesdavis9]

Posted on February 05, 2015 at 19:44

The application is to use a STM32F4, but not allow the core to enter any level of ISR at the time it's supposed to service a TIMER interrupt. The application needs the TIMER events to be repeatable down to clock cycle.

S

o, will the following work?

- Have a list of ''things'' to do at certain time intervals (T1, T2, ...Tn).

- Have a main infinite loop running along, interpreting commands it may get in a buffer unrelated to the list. 

- A TIMER is setup to interrupt at T1. Then the INT handler sets a new T2 and restarts the timer. This operation would continue to Tn based on the list.

- The TIMER interrupt  must always have the same overhead, so it can have the same number of clock cycles. 

Is this possible?

[Tesla DeLorean]

Posted on February 05, 2015 at 20:12

Caching, prefetching, multi-cycle instructions and branch prediction would tend to throw a spanner in the works.

You could have a singular time line, and ascribe or advance timer interrupts to occur along that line with a reasonable amount of precision. Certainly sub micro-second.

[waclawek.jan]

Posted on February 05, 2015 at 20:32

If you tell us more about ''things'', we might come up with better solutions.

As a minimum, the reprogramming for the next time can be automated using DMA. JW

[Cristea.Catalin]

Posted on February 05, 2015 at 21:34

Just to clarify my involvement in this: James is trying to help me with this; I will reply/add content as needed.

[Cristea.Catalin]

Posted on February 05, 2015 at 22:07

Thanks Clive, Jan

That's the kind of depth I'd like to know about. To simplify, let's say I need a precise pulse on one GPIO pin: I write 0x01 to a GPIO port; start the timer, and I need to write 0x00 to that GPIO port after 1000 clock cycles. Not 1001, nor 999. If I know the overhead and if it's fixed I can do that. Can I make the overhead fixed? My thought is that if the only enabled INT are the timer one I should be able to. I'm hoping somebody that knows more than me can confirm... or not. Thanks Cat

[Tesla DeLorean]

Posted on February 06, 2015 at 00:43

This seems like something you'd want the TIM hardware to do. Interrupting just adds a layer

of variable latency. You could also use the TIM to trigger a DMA action against the GPIO, say if you wanted to output a more complex bit pairing, and have a pattern buffer. This would significantly tighten the variability, but we're not going to be able to get to this exact cycle nonsense. That is a hardware task.

[Cristea.Catalin]

Posted on February 06, 2015 at 16:57

It would be ideal if the TIM HW could do all that might be needed but that might not be possible.  Triggering a DMA to the GPIO is a good idea; thanks.

Is it wrong to try to make sense of this nonsense? 🙂 For example, what makes the latency variable?  Can't I eliminate that variability? Thanks, Cat

[Tesla DeLorean]

Posted on February 06, 2015 at 18:25

I guess you could design your own micro-processor, and attached peripherals?

You need to approach your problem differently. If all the runways at an airport go East-West, approaching from the South isn't going to help you land. Modern CPU are complex, there are a lot of interactions with disparate bus speeds, and write buffers, and external contending hardware, there are data dependent execution speeds and code paths, and cache line states. There is sufficient meta-stability in what you're doing that a M4 running at 168 MHz is not going to be able to place a cycle accurate (5.95ns) GPIO signal with software tasks. Placing something with about 100ns of jitter, now that's something that's doable. This is what I mean by sub-micro second accuracy. So a 1000 cycles of what are we talking about? I can get the STM32F4 to generate equally spaced pulses every 1000 cycles of an 168 MHz clock all day long. I can modulate them, and change the duty, etc. To do this I'd use the TIM peripheral to place the edges. The F40x parts have a maximum pin output rate of 84 MHz.

[Cristea.Catalin]

Posted on February 06, 2015 at 23:55

Hey Clive,

You are generally very helpful and I usually look forward to seeing your reply to any help request in the forum. In this case you could just say it's impossible (or you think so) without metaphorising and combobulating 🙂 I's not exactly helpful to tell me 100ns is doable if I need 6ns. It seems to me like you say that modern CPUs are SO complex that nobody can tell/control what's happening in there. I'm hoping I CAN control some of the things that seem so uncontrollable to you: - external contending hardware - maybe write buffers - maybe ''data dependent execution speeds and code paths, and cache line states'' I can also do the things you mention you can; the help I need is with the things I can't (so far). It looks like you've been the most ''helpful helper'' so far and I may not get anything better. I thank you! I was hoping some STM people would jump in and say something... maybe they don't know either :( RE 84MHz: - I can use the 32F427 then 😉

[Tesla DeLorean]

Posted on February 07, 2015 at 00:58

What I'm saying is you're taking a knife to a gun fight. Sure you might win, but you're also likely to get mortally wounded. Much better to pick fights you can win and live.

I could perhaps get the part to do all the things you want, but I'd probably have to run it at 24 MHz and spend too much time babysitting the compiler and linker's code placement. F42x, 90 MHz so not a big win there. The signal speeds, and placement accuracy you're talking about needs to be done in hardware. Program the TIM peripheral to place your signals, it will be as accurate as your clock sources, and PLL/VCO allow. Perhaps you have poorly defined your task, and your implementation makes far more sense. ST has a very low profile here, so good luck with that. Ask you're FAE