ARM embedded delay hardware timer vs CPU cycle counter

3
votes

I'm working on an embedded project that's running on an ARM Cortex M3 based microcontroller. Some code provided by our vendor uses a delay function that sets up built-in hardware timer and then spins until the timer expires. Typically this is used to wait between 1 and a couple hundred microseconds. These delays are almost because they are waiting on some register, chip or bus to complete an action and need to wait at least the given number of microseconds. The hardware timer also appears to cost at least 6 microseconds in overhead to setup.

In a multithreaded environment this is a problem because there are N threads but only 1 hardware timer. I could disable interrupts while the timer is being used to prevent context switches and thus race conditions but it seems a bit ugly. I am thinking of replacing the function that uses the hardware timer with a function that uses the ARM CPU Cycle Counter (CCNT). Are there are pitfalls I am missing or other alternatives? Obviously the cycle counter function requires it be tuned to the proper CPU frequency which will never change for our system, but I suppose could be detected at boot programmatically using the hardware timer.

2
armembedded
Which kind of ARM M3 has a single hardware timer? You are saying that you have a multi-threaded environment, so the a timer for the scheduler is required: are you saying that the only timer you have is the one assigned to the scheduler? - LPs
There are actually 2 hardware timers and also a system tick interrupt which fires on 1 millisecond intervals. The system tick interrupt is not a timer, you cannot query how much time has passed you simply get an interrupt every 1 millisecond which is used to inform the preemptive scheduler. The resolution of 1 millisecond is also much too long for the delays I am interested in. - satur9nine
Busy spinning such a long time is a pretty bad approach for modern MCUs. If they use such stuff, I'd be suspicious about the quality of the rest.. - too honest for this site

2 Answers

6
votes

Setup the timer once at startup and let the counter run continuously. When you want to start a delay, read the counter value and remember this start value. Then in the delay loop read the counter value again and loop until the counter value minus the start value is greater than or equal to the requested delay ticks. (If you do the subtraction correctly then rollovers will wash out and you don't need special handling to check for them.)

2
votes

You could multiplex your timer such that you have a table of when each thread wants to fire off and a function pointer / vector for execution. When the timer interrupt occurs, fire off that thread's interrupt and then set the timer to the next one in the list, minus elapsed time. This is what I see many *nix operating systems do in their kernel code, so there should be code to pull from as example.

A bigger concern is the fact that you are spin locking the thread waiting for the timer. Besides CPU usage, and depending on what OS you have (or if you have an OS) you could easily introduce thread inversion issues or even full on lock ups. It might be better to use thread primitives instead so that any OS can actually sleep your threads and wake them when needed.