ADC
#1
Posted 27 July 2012 - 08:11 AM
#2
Posted 27 July 2012 - 12:56 PM
#3
Posted 27 July 2012 - 02:17 PM
#5
Posted 27 July 2012 - 04:18 PM
#6
Posted 27 July 2012 - 04:47 PM
Hello Laurentis,
These things should be tested out of the PC Environment for better results.
#7
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
Posted 01 August 2012 - 09:59 AM
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
Posted 01 August 2012 - 11:08 AM
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.I still want to improve the ADC speed.
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).
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.Anyone knows how to rebuild a framework ?
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
Posted 01 August 2012 - 11:41 PM
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
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