8 replies to this topic

[Joshua Watkins]

Is there a way to get microsecond level timing from the netduino+?

[Stefan]

Hi, could this thread point you in the right direction? http://forums.netdui...e-system-timer/

[CW2]

Could you please provide some more details on what exactly you need? The current implementation of .NET Micro Framework cannot provide microsecond precise timing when executing managed code, but there are certain ways to overcome that limitation, for example by using PWM, SPI, USART hardware modules, or there might be already a native driver (C++ code that can have precise timing) for a particular device or protocol.

[Victor M.]

Is there a way to get microsecond level timing from the netduino+?

Why you need "us" ? Netduino have troubles when you reduce so much the interruption time and events. Around 100ms the periodic count start to be very unstable and the oscillate between 80ms and 120ms. This problem occur because your code staying on the high level code and the code of bootloader and .NET Microframework stay under it. To make some type of aplication you need to use other processor or try to put you code compiled with the bootloader.

Other solution for this problem is use other processor to manage fast process.

[Stefan]

Other solution for this problem is use other processor to manage fast process.

Or to see if there's a native class for the kind of job you want to do, like CW2 pointed out.

If you want to drive a specific chip, you could bitbang, but also use native SPI, I2C, PWM or UART classes.

[Nobby]

Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks has 100ns precision(0.1us) but the accuracy is skewed by +- a few hundred microseconds due to the runtime overhead. If you need to measure an interval less than one millisecond, you end up with an error of about 20% but this error is negligable for slightly larger intervals. The 100ns precision is definitely usefull for cumulative timing functionality. Are you using the timer as a measurement interrupt?

[jfriedman]

You may be able to squeeze less than 20% of error out if you cause the processor to use interrupts.

 

See this article

 

http://www.codeproje...recision-in-NET

[Morpheus]

Dear all

 

what i did in order to overcome this error is the following:

I made some tests in order to find how many ticks are for each microsecond. I calculated the ticks for 1 microsec to 1 sec in some discrete steps. I assumed that the greatest the time is the greatest the precision for the ticks counting so for various tests for 1 sec i found that there are about 10,1 ticks per 1 microsec (eg 1010347 ticks for 100ms (100000microsec) thus 1010347/100000=10,10347 ticks per microsec.

				    long startTick = Utility.GetMachineTime().Ticks;				    Thread.Sleep(1);				    long endTick = Utility.GetMachineTime().Ticks;				    long Delta = endTick - startTick;				    Debug.Print("1ms:" + Delta.ToString());				    startTick = Utility.GetMachineTime().Ticks;				    Thread.Sleep(10);				    endTick = Utility.GetMachineTime().Ticks;				    Delta = endTick - startTick;				    Debug.Print("10ms:" + Delta.ToString());				    startTick = Utility.GetMachineTime().Ticks;				    Thread.Sleep(100);				    endTick = Utility.GetMachineTime().Ticks;				    Delta = endTick - startTick;				    Debug.Print("100ms:" + Delta.ToString());				    startTick = Utility.GetMachineTime().Ticks;				    Thread.Sleep(1000);				    endTick = Utility.GetMachineTime().Ticks;				    Delta = endTick - startTick;				    Debug.Print("1s:" + Delta.ToString()); 

Then i wrote a function that creates a delay in microseconds.

 

 

 double ticksPerMicrosec=10; // this came after calculation (see above)	    public static void WaitMicroseconds(double microseconds)	    {		    long ticks = Utility.GetMachineTime().Ticks;		    while ((Utility.GetMachineTime().Ticks - ticks) < (microseconds * ticksPerMicrosec)) ;	    } 

[YuvaRaja]

I found a link for Microsecond delay in the Netduino.

 

http://www.j2i.net/b...-Framework.aspx

 

But this is only for netduino and depends upon the Hardware also.