LeafLabs Garden

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

1. 

   bhclowers
   Member

   I'm hoping this is a very easy fix. To start, I'm using Maple IDE 0.0.9 and the maple r5 board. The sketch I have at present attempts to fill an array with both a time stamp of when the data was acquired and the actual analogRead. The problem of the output can been seen below. Despite having a delayMicroseconds(50) there seems to be some sort of variable delay that takes approximately 7-8 microseconds. While livable, it would be nice to have a reproducible time stamp for the analog reads placed into an array--or any process for that matter. I tried introducing the noInterrupt() call but that still produced the same result. Any ideas would be appreciated.

   Cheers.

   Brian

   SerialUSB Output:
   ####################################
   Micros DeltaT AnalogIn
   6152400 , , 2370

   6152457 , 57 , 2266

   6152515 , 58 , 2186

   6152573 , 58 , 2129

   6152631 , 58 , 2089

   6152688 , 57 , 2056

   6152746 , 58 , 2033

   6152804 , 58 , 2167

   6152862 , 58 , 2115

   6152920 , 58 , 2076

   6152977 , 57 , 2047

   6153036 , 59 , 2178

   6153093 , 57 , 2120

   6153151 , 58 , 2077

   6153211 , 60 , 2048

   6153268 , 57 , 2027

   6153326 , 58 , 2156

   6153384 , 58 , 2107

   6153442 , 58 , 2074

   6153500 , 58 , 2045

   6153557 , 57 , 2177

   6153615 , 58 , 2119

   6153673 , 58 , 2075

   6153731 , 58 , 2050

   6153788 , 57 , 2029

   #################################

   int analogPin = 0;
   // our array size
   int size=25;
   uint32 time[25];
   uint32 rawdata[25];

   void setup() {
   pinMode(analogPin, INPUT_ANALOG);
   SerialUSB.begin();
   }

   void loop() {
   //noInterrupts();
   for (int i=0;i<size;i++) {
   time[i]=micros();
   rawdata[i]=analogRead(analogPin);
   delayMicroseconds(50);
   }
   for (int i=0;i<size;i++) {
   SerialUSB.print(time[i]);
   SerialUSB.print(" , ");
   if (i > 0) {
   SerialUSB.print((time[i]-time[(i-1)]));
   SerialUSB.print(" , ");
   }
   else{
   SerialUSB.print(" ");
   SerialUSB.print(" , ");
   }
   SerialUSB.println(rawdata[i]);
   }
   SerialUSB.println("");
   delay(3000);
   }

   Posted 4 years ago #
2. 

   StephenFromNYC
   Moderator

   Hello-

   Brian, this may not be the quick answer you want, but I am waiting for the DMA functions which will be included with the next software release.

   With DMA the ARM Cortex M3 chip will perform analog reads (ADC) without using the processor (no need to call analogRead()). Just set up the required ADC timing and the DMA circuits should do the rest. I do not know how quickly or how much data can be sent via SerialUSB. I do not know how data acquisition by the Maple board and transmitting the data from the Maple board to the host is coordinated if you need high speed data acquisition via ADC.

   Thanks!

   Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

   Posted 4 years ago #
3. 

   bhclowers
   Member

   Thanks Stephen,

   If your assessment is correct that I'll be happy to wait. Having explicit control over the acquisition rate would be fantastic. I'm looking at reads on the order of 50us to fill an array--well within the range of the processor speed. As for transferring data via USB, that was only used a way to look at the data after it was acquired. That function should have no bearing on the actual read times.

   I'll stayed tuned for that next release. Any ideas on a date?

   Cheers,

   Brian

   Posted 4 years ago #
4. 

   gbulmer
   Moderator

   Brian - a DMA solution is a good solution, but if you are willing and able to 'get your hands dirty', a timer channel could be used to trigger the ADC conversion. This is slightly intricate code, but I guess less difficult than writing the DMA code. Even then, you might want to avoid it, but it would give very regular samples.

   You might find that their are several sources of delays:
   1. analogRead takes about 6-7 microseconds; that is set in the source code of analogRead to ensure signals with a relatively high output impedance (eg. a few K ohms) are sampled reasonably faithfully
   2. USB generates interrupts when the host PC polls the Maple, so sometimes those interrupts may happen after the delay(50), and before the analogRead, causing 'jitter' or variability
   3. micros() might not have microsecond precision (I think its precision was a couple of usecs)
   4. delayMicroseconds may suffer a bit from USB interrupts causing some variability too

   (for full disclosure: I am not a member of LeafLabs staff)

   Posted 4 years ago #
5. 

   StephenFromNYC
   Moderator

   Here is an apples:oranges comparison.

   From the arduino web site:

   http://www.arduino.cc/en/Reference/Micros

   16 MHz Arduino boards (e.g. Duemilanove and Nano), this function has a resolution of four microseconds (i.e. the value returned is always a multiple of four)

   I do not know how the Arduino resolution was determined for micros().

   Enjoy!

   Stephen from NYC (full disclosure: I am not a member of the LeafLabs staff)

   Posted 4 years ago #
6. 

   gbulmer
   Moderator

   StephenFromNYC -

   16 MHz Arduino boards (e.g. Duemilanove and Nano), this function has a resolution of four microseconds (i.e. the value returned is always a multiple of four)

   I do not know how the Arduino resolution was determined for micros().

   The Arduino millis() timer is driven by the ATmega's Timer/Counter0 peripheral, with is an 8bit timer.
   It is set up to count with a frequency of 16MHz/64, and hence counts at 4 microseconds.

   Timer/Counter0 generates an 'overflow' interrupt which is used to update a millis-count variable used by millis(). It isn't updated by software. Once it is initialised, it just counts from 0 to 255 in hardware.

   micros() uses the millis-count variable and the actual value of the hardware counter in Timer/Counter0 to give a time stamp with 4 microsecond precision.

   The time on the Maple, uses a STM32F hardware timer called sysclock, intended for timestamps. Like the Arduino's Timer/Counter0, it isn't normally updated in software; once initialised the timer keeps itself going in hardware. I just read the code, and it is counting at 72MHz, so the jitter on it is way smaller than 1 microsecond.

   (I was mistaken about the precision of this time source. The ST documentation suggests counting at a much lower frequency than 72MHz, so I had assumed maplelib did that, but it doesn't.)

   The nice thing about using timers is they don't 'jitter' because they count in hardware, and aren't effected by interrupts.

   The Arduino delayMicroseconds uses a similar 'busy wait' technique to the one in maplelib. Neither Arduino nor Maple use the underlying timers, but instead run some instructions a calculated number of times, so do have jitter caused by interrupts.

   (NB - sysclock isn't available as a source of triggers to the ADC.)

   (full disclosure: I am not a member of the LeafLabs staff)

   Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.