Author Topic: Accuracy of micros(); ?  (Read 1987 times)

TayRobChap

  • RFduino Newbie
  • *
  • Posts: 11
  • Karma: +0/-0
    • View Profile
Accuracy of micros(); ?
« on: June 11, 2014, 03:17:49 PM »
Hello!

Making headway re the interrupt handling as posted in another thread and we will post a follow up there for others to use in the future.

There is a mystery to solve though with micros(); We are just getting rolling with the RFDuino and I hope we are just missing something obvious!

We setup a hardware test here with the scope such that we turn on an output line when we enter the interrupt routine and turn it off when we exit - so we could view accurately the interrupt timing. In that routine we grab micros(); and compare it to a previously stored value of micros(); so that we measure the time from entering the interrupt to the next time we enter the interrupt (ie from falling edge to falling edge in this case).  The timing on the scope is very repeatable but about 5% to 10% of the time we get a value from micros() which is approx 30usec longer than expected. We don't get random time variations - just the odd time when micros() seems to have ticked away an extra 30usec - while the timing from the scope from point to point has not changed at all.

For reference the code was running in an Arduino Uno previously and we are porting it over now to the RFDuino so we can test the basic operation prior to turning on and messing with the BLE stuff.  We have executed no BLE routines at all but is there a chance something is running in the background which would affect the values micros() would return?

Any help most appreciated!

Thanks!


« Last Edit: June 12, 2014, 08:32:32 AM by TayRobChap »

TayRobChap

  • RFduino Newbie
  • *
  • Posts: 11
  • Karma: +0/-0
    • View Profile
Re: Accuracy of micros(); ?
« Reply #1 on: June 13, 2014, 09:42:22 AM »
Hello!


Just wanted to post a follow up after we did some testing yesterday. Micros() does indeed have a resolution of about 30usec. We did several tests code and scope wise to confirm and also last night I spotted this:

https://github.com/RFduino/RFduino/search?q=micros&type=Code

with a note in there that micros is accurate to 30.5usec.

We also confirmed that micros() does run while we are in an interrupt and that it takes approx 10usec to grab the value from micros() - longer than expected but still ok for us.

Since for our application we need to detect timing changes with a higher resolution (something like 10usec or better) we are kinda stuck.... Hard coding some timing ourselves with loops is a bit precarious since when we implement the BLE stuff I expect interrupts on that side of things will mess with the loop timing.

I know with the Atmel based UNO it is possible to directly manipulate and read the timers - is this kind of direct timer read possible with the RFduino? If we can do that then likely we'll be good to go.

Our application is to add bluetooth (and BLE) function to an existing product that has been shipping for about 10 years time so making changes to the data stream timing to allow reads with the 30usec resolution is a no go as it would require reprogramming of all the modules in our system. 

We may be  able to use both an Atmel processor (currently running old school bluetooth) and then combine it with the RFDuino but that is a bit messy and apart from this gotcha with the resolution of the timing the RFDuino would be perfect for the application.

Any suggested most appreciated!

Thansk!



 

anything