LeafLabs Garden

A place to share, learn, and grow...

1. 

   Jeannette Bagley
   Member

   Hi everyone,

   for a project I am currently thinking of I need to time 4 different external events, i.e. run times. All events have a common starting point in time, t0, so I thought of using the Maple board with a timer set to input compare to store the counter values in memory using DMA and trigger an interrupt once all counter values are available.

   From the manual / forum, I learned that USB and SYSTICK should be disabled to avoid Jitter, and since precision is pretty important in my application, I'll probably have to stick to that. My question now, is though, how to communicate the value to the "outside world"? I would love to do continuous measurements, which kinda rules out storing the values on the board itself, and transmitting them back to a connected PC via USB is also out of the question (although that would be ideal).

   Will serial communication work? Will it induce Jitter? Any other alternatives, pointers? Any help is appreciated!

   Cheers,
   Jeanette

   Posted 4 years ago #
2. 

   poslathian
   LeafLabs

   You may be able to use the USB if you are not continuously sampling always. You could stash the values in a buffer and then turn on the USB periodically to print them. SerialUSB.end() and SerialUSB.begin() should kill and revive the USB. Similarly systick_end() (I think, check the docs) should kill the systick. If you cant buffer the data you need (sampling too often) you can use a UART/USART connected to an FTDI or Arduino or another Maple to feed the data out if you absolutely cant ever turn on the USB.

   your idea of using the input compare mode on the timers is sound. You might also use external digital interrupts to do the timing latching, but it might not be as accurate as input compare on the timers

   Posted 4 years ago #
3. 

   trevden
   Member

   What sort of precision are you actually looking for? Tens of nanoseconds? Microseconds? Milliseconds?

   And, of course, the more information you can provide about your specific application and what sort of inputs/parameters you have, the better the answers we can give you. :)

   Posted 4 years ago #
4. 

   trevden
   Member

   Also, FTR, it looks like input capture happens on such a low level that it latches the counter value in hardware, so it shouldn't be affected by things like USB interrupts. Of course, you still need to start the counter with the appropriate accuracy...

   Posted 4 years ago #
5. 

   poslathian
   LeafLabs

   as trevden points out, properly configured you should be use the hardware timers in input capture mode to get about 14ns resolution!

   Posted 4 years ago #
6. 

   mbolivar
   LeafLabs

   although, to be fair, input capture support isn't in timer.h yet, and we haven't done any thinking at all about how (or even whether) to include support for it in HardwareTimer.

   btw, issues like these are why the HardwareTimer interface was declared unstable in 0.0.10 -- it would be easy to keep adding features to it, but the result would be an unusable mess. this is definitely an issue that needs more brains; input from the forum on this would be great.

   edit: see my separate thread on this issue here: http://forums.leaflabs.com/topic.php?id=794

   Posted 4 years ago #
7. 

   gbulmer
   Moderator

   As folks have said, input capture timing is done in autonomous hardware, so software interrupts can't cause that to jitter.

   BUT, there is a trade-off between resolution and duration.

   The timers count in multiples of 72MHz, so as poslathian explains, that is the highest resolution.

   The timer is only 16 bits, so if it counts at 72MHz, it will wrap around at about 1099Hz, so the longest duration the timer will record is under 1 millisecond. Longer than that, and there will be ambiguity.

   There are a couple of ways to improve on this. For example, timers can be 'chained' together (Section 15.3.15 "Timer synchronization" of RM0008) to create a 32bit timer, which would then wrap around at roughly 60 seconds.

   Once the timer values are converted to an adequate range of values, you could send them to a host PC. Then the obstacle may be the amount of bandwidth needed to communicate the values.

   As trevden wrote, the more information you are able to share, the better we might be able to help.

   Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.