Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

ADC


  • Please log in to reply
10 replies to this topic

#1 laurentiss

laurentiss

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationGrenoble France

Posted 27 July 2012 - 08:11 AM

I make an infinite loop on ADC.Read() I takes about 0,5ms per loop with the debugger. Can I expect an ADC read in 100 microseconds ?

#2 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 27 July 2012 - 12:56 PM

Hello Laurentiss. I'm supposing you want to perform a tight sampling of the ADC, that is at 10kHz rate. Before asking myself whether that rate could be reached, I'd consider that the Netduino runs over a managed framework, that is unpredictable as timing. The test you done, is just an unreliable context, because as soon you have lots of objects removed from the heap, the garbage collection (GC) will work at any time, causing small yet annoying delays. I guess the timing UN-reliability is the worst fault of this kind of board (i.e. language). Anyway, could you describe better what you want to do? Cheers
Biggest fault of Netduino? It runs by electricity.

#3 laurentiss

laurentiss

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationGrenoble France

Posted 27 July 2012 - 02:17 PM

Thank you Mario for your response. I know that the framework slows things down..But most of teh time the developper is the problem! But I know that on a PC, the differences is sometimes hard to see.. The conversion time of an ADC can be less than 5 Microseconds.. A simple loop with simple calculation run very fast. It is the call to the ADC which goes wrong. Usually, it is possible to start conversion, than to read the result later. With NetDuino, it seems that we have to start and wait conversion.. Even though, response time is very long... What I want to to is to store data from 1khz ->10khz signal into memory, and dump it from a PC. It works fine for 100hz signal.. I will work on it...

#4 laurentiss

laurentiss

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationGrenoble France

Posted 27 July 2012 - 02:19 PM

This may help... http://www.arduino.c...m=1208715493/11

#5 caEstrada

caEstrada

    Advanced Member

  • Members
  • PipPipPip
  • 84 posts

Posted 27 July 2012 - 04:18 PM

Hello Laurentis, These things should be tested out of the PC Environment for better results.

#6 laurentiss

laurentiss

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationGrenoble France

Posted 27 July 2012 - 04:47 PM

You are right, but I do not know yet how to run the target in stand alone mode...
:)

Hello Laurentis,

These things should be tested out of the PC Environment for better results.



#7 Nobby

Nobby

    Advanced Member

  • Members
  • PipPipPip
  • 70 posts

Posted 28 July 2012 - 01:33 PM

Thank you Mario for your response.

I know that the framework slows things down..But most of teh time the developper is the problem!

But I know that on a PC, the differences is sometimes hard to see..
The conversion time of an ADC can be less than 5 Microseconds..
A simple loop with simple calculation run very fast.
It is the call to the ADC which goes wrong.
Usually, it is possible to start conversion, than to read the result later.
With NetDuino, it seems that we have to start and wait conversion..
Even though, response time is very long...

What I want to to is to store data from 1khz ->10khz signal into memory, and dump it from a PC.
It works fine for 100hz signal..


I will work on it...


If you configure the ADC to operate in free-running mode, the contents of the ADC register is constantly changing for you at the maximum rate the ADC will operate at. This kinda eliminates conversion times from a hardware interrupt. There are two probelms with a free-running ADC.

If you strobe multiple pins you run into parallel operation errors. I haven't checked the SAM7 architecture but most AVRs only have 1 ADC but have 5+ pins you can strobe off. When you change the ADC strobing register to select another pin, it might be impossible to determine which pin the ADC data register contents belongs to if you read it immediately or shortly after. Some AVRs don't allow free-running with strobing.

The other issue you have is when you read a sample from the ADC register in free-running mode, you don't know how "old" the data is. When you take two readings, there will always be a degree of skew in your measurement windows which increases with a slower ADC sampling rate.

Those two issues aside, it's also a tall-order to measure a time interval less than 1ms accurately.

#8 laurentiss

laurentiss

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationGrenoble France

Posted 01 August 2012 - 09:59 AM

Thank you for this reply.
I agree with your statements...
I still want to improve the ADC speed.
The best ways to have a real - but not accurate - refresh rate is to count loops in a certain time (1 second). Is this is no good, there is no need to go any further.
It is too bad on a system than have such a CPU not to beeing able to access a peripheral in less than 0,5 microsecond. I will look into the frameworks sources files to learn more.
Anyone knows how to rebuild a framework ?




If you configure the ADC to operate in free-running mode, the contents of the ADC register is constantly changing for you at the maximum rate the ADC will operate at. This kinda eliminates conversion times from a hardware interrupt. There are two probelms with a free-running ADC.

....

Those two issues aside, it's also a tall-order to measure a time interval less than 1ms accurately.



#9 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 01 August 2012 - 11:08 AM

I still want to improve the ADC speed.

The ADC clock frequency is set to 5 MHz, the performance of the adc.Read() loop is determined by the duration of managed code execution - as you probably know, .NET Micro Framework does not have Just-In-Time compiler (JIT), so the managed code is interpreted and there are several layers of abstraction that add to the processing time.

Even if you improve the 'ADC speed', you are still limited by the speed of managed code, i.e. your program will never be fast enough to do any non-trivial data processing (or maybe any processing at all). IMHO what could work is to implement the ADC sampling function in native code (C++), which periodically performs the ADC conversion and stores the results into a buffer, then passing this buffer to managed code, perhaps via a queue, if the managed code is able to process it further - otherwise, it would have to be done in the native side either (e.g. streaming/sending the buffer over serial or SPI).

Anyone knows how to rebuild a framework ?

The Porting Kit documentation is a good place to start, the topic has been thoroughly discussed in the forum - just search for "firmware build" or such.

I don't know enough about your application, but you might be able to get it done [much faster] using the PC sound card.

#10 yiulsup

yiulsup

    Advanced Member

  • Members
  • PipPipPip
  • 34 posts

Posted 01 August 2012 - 11:41 PM

To laurentiss

The more speed is possible for built-in ADC with modifying the native source code which I done before.

With modifying the native code for ADC releated managed code, I can attain speed which i want to reach.

Kevin

#11 aballung

aballung

    New Member

  • Members
  • Pip
  • 4 posts

Posted 17 May 2013 - 07:15 PM

Where do you find the built-in ADC native source code to edit? I need the ADC to sample at >2MSPS.

 

Angelo






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.