DUE: unable to read AD0 and AD1 at the same time

Official Hardware Mega Due
1

Hi guys,

i'm quite new to the community, so i'm not sure if this is the right section for my issue.

i believe it's a programming issue with the analogRead function. I have the impression, when reading out both AD0 and AD1 together, they read out the same values although there are different voltages applied to the pins

i'm using the Arduino Due board and have the following schematic

![](http://electret+potmeter AD0-AD1.png)

when i read out the AD0, i get the following results while tapping the electret microphone

only PIN_ANALOG_IN_1
	 micro val:122
	 micro val:429
	 micro val:623
	 micro val:814
	 micro val:739
	 micro val:1023

when i try to read AD1, i get the following (while rotating the potentio meter (1OK)

only PIN_ANALOG_IN_2

	 trigger signal:652
	 trigger signal:641
	 trigger signal:632
	 trigger signal:622
	 trigger signal:609
	 trigger signal:587
	 trigger signal:560
	 trigger signal:537
	 trigger signal:525
	 trigger signal:519
	 trigger signal:514

when i try to read them both immediately the one after the other, i read the following when tapping the electret, the potentiometer doesnt budge..

both

	 trigger signal:1023	 micro val:632
	 trigger signal:700	 micro val:0
	 trigger signal:0	 micro val:869
	 trigger signal:885	 micro val:985
	 trigger signal:991	 micro val:730

i have the following code (left some extra code in there because maybe the array influences the memory locations in which the analogread stores it values ???

#define PIN_ANALOG_IN_1 0 // electret microphone for listining
#define PIN_ANALOG_IN_2 1 // potmeter for scaling factor
#define BUFFER_ANALOG_IN_1 64


////Pin connected to DS of 74HC595
int dataPin = 22;
//Pin connected to SH_CP of 74HC595
int clockPin = 26;
//Pin connected to ST_CP of 74HC595
int latchPin = 24;
int button = 23;

int arr_analogval[BUFFER_ANALOG_IN_1];

int arr_74HC595[2];

void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);

  pinMode(latchPin, OUTPUT);
  pinMode(clockPin, OUTPUT);
  pinMode(dataPin, OUTPUT);
  pinMode(button, INPUT);
     digitalWrite(button, LOW);  
 
     // init arr_74HC595
     arr_74HC595[0] = 0X00;
     arr_74HC595[1] = 0X00;
     
     // clear 74HC595
     digitalWrite(latchPin, LOW); delay (1);
     shiftOut(dataPin, clockPin, LSBFIRST, arr_74HC595[1]);   delay (1);
     shiftOut(dataPin, clockPin, LSBFIRST, arr_74HC595[0]);   delay (1);
     digitalWrite(latchPin, HIGH); delay (1);


 // end of setup 
  Serial.println("OK");
}

void loop() {
  float signal_factor = 0;
  float trigger_factor = 0;
  int avg_analogval = 0;


  Serial.print("\t trigger signal:"); Serial.print(analogRead(PIN_ANALOG_IN_2));

  avg_analogval =   analogRead(PIN_ANALOG_IN_1);
  Serial.print("\t micro val:"); Serial.print(avg_analogval); 
  
  Serial.println("");
}

i tried a quick google but nothing apparent came out of this :wink:

hope someone has encountered the same issue and can enlighten me :slight_smile:

CHeers!

H.

electret+potmeter AD0-AD1.png

2

Try using A0 and A1 as the analog pins not 0 and 1.

Mark

3

holmes4:
Try using A0 and A1 as the analog pins not 0 and 1.

Mark

No point doing that, analogRead () accepts either numbering scheme.

This is a bug(*) that should be fixed in the next beta release as far as I recall - this
thread should be moved to the Due forum BTW.

(*) See reply #8 in analogRead problem with IDE 1.5.5 libraries - Arduino Due - Arduino Forum
once you switch to a different pin you get double conversions with the lowest
numbered pin being the one the value returned corresponds to.

I think the work around is something like

  analogRead (13) ;
  val = analogRead (pin) ;
  analogRead (13) ;
  val = analogRead (other_pin) ;

So long as pin and other_pin are less than 13 the result should belong to the
one you intend - well try it.

4

Hi all,

thanks for pointing the bug out.

not sure how to move this thread. feel free to move it to the right location!

i tried your work around as follows, but the result stays the same.

void loop() {
  analogRead(13); // nasty hack 
  Serial.print("\t trigger signal:"); Serial.print(analogRead(MICROPHONE));
  analogRead(13); // nasty hack 
  Serial.print("\t micro val:"); Serial.print(analogRead(DIAL));
  Serial.println("");
}

should i try to manipulate the registers directly ?

i'm a bit new to this so it will take some time to get it going...

Herman

5

Ah, probably optimized away, try

volatile int t ;
void loop ()
{
  t += analogRead(13); // nasty hack 
  Serial.print("\t trigger signal:"); Serial.print(analogRead(MICROPHONE));
  t += analogRead(13); // nasty hack 
  Serial.print("\t micro val:"); Serial.print(analogRead(DIAL));
  ...
}
6

Hi Mark,

tried the trick with the "volatile int" but doesnt seem to do the trick...

i'm not sure to understand why that would would be a work around.

what is the nature of the bug? i wasnt able to derive it from the other thread referenced earlier.

is it a memory issue? or rather a timing issue?

strange thing is that i reuse the code from a previous sketch (programmed in win XP) and i have seen it work before there... if i compile that same sketch in win7 (professional) then it seems to hang on me. not sure if it's a clue.

cheers!

H.

7

hermy:
Hi Mark,

tried the trick with the "volatile int" but doesnt seem to do the trick...

i'm not sure to understand why that would would be a work around.

what is the nature of the bug? i wasnt able to derive it from the other thread referenced earlier.

is it a memory issue? or rather a timing issue?

strange thing is that i reuse the code from a previous sketch (programmed in win XP) and i have seen it work before there... if i compile that same sketch in win7 (professional) then it seems to hang on me. not sure if it's a clue.

cheers!

H.

You have to understand the ADC peripheral and the code in analogRead() and the patches
in that posting to understand the bug - its not trivial, its a while back, good luck. It also
depends on which version you're running, which is why you see a difference - when reporting
bugs for the beta release please say which version you are running, and don't bother unless its the latest one, no point reporting a fixed bug.

Anyway I think the issue went like this:

pre 1.5.4 analogRead() reset the ADC on every call, worked but SLOW (40us)

1.5.4, analogRead() kept the ADC active between conversions but every time
a new channel was used it was added to a set of active channels which were
all converted on every call, the result being an accident of conversion order.
Raw conversion about 2us, more like it should be.

1.5.5 when changing channels the previous channel was de-activated before
activating the new one which worked but had the (undocumented) effect of
shutting the ADC down, leading to a SLOW conversion again (40us after
changing channels, thereafter down to 2us again)

The fix is to enable the new channel before disabling the previous one, which
doesn't let the ADC shut itself down, and keeps only one channel active.

Bear in mind the ADC hardware is really designed to sample multiple channels
on a regular sampling clock to a DMA channel, its complex to set up
compared to the Uno/Mega for instance.