strange ADC / rprintf prob with WebbotLib

[Admin]

I have a strange problem. I'm probably doing something dumb, but can't figure it out.

This code works:

Code: [Select]

r1cur=a2dConvert8bit(r1current);
rprintf("%d\r\n",r1cur);
r2cur=a2dConvert8bit(r2current);
rprintf("%d\r\n",r2cur);
r4cur=a2dConvert8bit(r4current);
rprintf("%d\r\n",r4cur);
rprintf("get data %d %d %d\r\n",r1cur,r2cur,r4cur);
It correctly outputs:

42
0
1
get data 42 0 1

This does not work:

Code: [Select]

r1cur=a2dConvert8bit(r1current);
r2cur=a2dConvert8bit(r2current);
r4cur=a2dConvert8bit(r4current);
rprintf("get data %d %d %d\r\n",r1cur,r2cur,r4cur);
It outputs the same value for r1cur, r2cur, and r4cur no matter what. The actual value appears a bit random.

I can't figure out why it only works when I add in extra rprintfs . . . .

This is my initialization:

Code: [Select]

#define r1current ADC_NUMBER_TO_CHANNEL(8)
#define r2current ADC_NUMBER_TO_CHANNEL(9)
#define r4current ADC_NUMBER_TO_CHANNEL(10)

int r1cur;
int r2cur;
int r4cur;

[Webbot]

As  a matter of interest: have you tried using ADC 1,2,3 rather than 8,9,10 - just humour me !

Also: with the code that 'does not work' I'm a bit confused as to what you see. You say 'It outputs the same value....' - do you mean the same value is repeated for all 3 readings - and that one value changes?

Incidentally - just as with AVRlib - you dont need to say '\r\n' you cant just say '\n' as it gets xlated to '\r\n'. Will save you 2 bytes of memory each time.

[Admin]

have you tried using ADC 1,2,3 rather than 8,9,10 - just humour me !

Nope, doesn't fix it.

with the code that 'does not work' I'm a bit confused as to what you see. You say 'It outputs the same value....' - do you mean the same value is repeated for all 3 readings - and that one value changes?

I mean that whatever value it outputs, all of them are outputting the same value. Strange, since each is attached to a different sensor. For example:

get data 5 5 5

Will save you 2 bytes of memory each time.

lol I'm not that OCD!

[Admin]

Still playing around with it . . . using this code:

Code: [Select]

r1cur=a2dConvert8bit(r1current);
rprintf("%d\r\n",r1cur);
r2cur=a2dConvert8bit(r2current);
r4cur=a2dConvert8bit(r4current);
rprintf("get data %d %d %d\r\n",r1cur,r2cur,r4cur);
It'll generate a result where r1cur is printed out currectly, but r2cur and r4cur are not (always the same value).

41
get data 41 5 5

Then if I run this code:

Code: [Select]

r1cur=a2dConvert8bit(r1current);
r2cur=a2dConvert8bit(r2current);
rprintf("%d %d\r\n",r1cur,r2cur);
r4cur=a2dConvert8bit(r4current);
r5cur=a2dConvert8bit(r5current);
rprintf("get data %d %d %d\r\n",r1cur,r2cur,r4cur,r5cur);
It'll give me results where r1cur and r2cur are always the same, and r4cur and r5cur are always the same:

41 41
get data 41 41 5 5

But if I put a rprintf for each individual value, they are all different values (like in the first post).

totally confused . . .

[Admin]

Playing around with more code . . . still confused.

Both code snippets result in all output values being exactly the same. As if there is no difference.

Code: [Select]

rprintf("get data %d %d %d\n",a2dConvert8bit(ADC_NUMBER_TO_CHANNEL(8)),a2dConvert8bit(ADC_NUMBER_TO_CHANNEL(9)),a2dConvert8bit(ADC_NUMBER_TO_CHANNEL(10)));

Code: [Select]

r1cur=a2dConvert8bit(r1current);
rprintf("get data %d %d %d\n",r1cur,a2dConvert8bit(ADC_NUMBER_TO_CHANNEL(9)),a2dConvert8bit(ADC_NUMBER_TO_CHANNEL(10)));

[Admin]

PROBLEM SOLVED

The lamest bug ever. Apparently you need to add a tiny delay between ADC reads.

Code: [Select]

r1cur=a2dConvert8bit(r1current);
delay_us(2);
r2cur=a2dConvert8bit(r2current);
delay_us(2);
r4cur=a2dConvert8bit(r4current);
rprintf("get data %d %d %d\r\n",r1cur,r2cur,r4cur);
I never had this problem with AVRlib . . . Webbot, can you fix this in your WebbotLib? Basically force a 2us delay after each ADC read (not sure what the optimal delay is).

thanks airman00!

[Webbot]

Ok, no probs.

But will do some 'data sheet checking' as well since I hate adding delays per se as they just make your code grind to a halt.

AVRlib uses an interrupt to signal 'conversion complete' but as far as I can tell this is not used by the rest of their code. Consequently I have excluded it in my lib (no point having meaningless interrupts). But it may be that this interrupt service handlerr just 'wastes time' and achieves the 2us delay.

Will report back.

[Admin]

I'm still having another problem with ADC.

My code:

Code: [Select]

rprintf("12: %d ", a2dConvert8bit(ADC_NUMBER_TO_CHANNEL(12)));
rprintf("11: %d ", a2dConvert8bit(ADC_NUMBER_TO_CHANNEL(11)));
rprintf("0 : %d\n", a2dConvert8bit(ADC_NUMBER_TO_CHANNEL(0)));
When I apply 5V to the signal pin on ADC 12:
channel 11 and channel 0 both give 255, while channel 12 gives random value

When I apply 5V to the signal pin on ADC 11:
channel 0 both gives 255, while channel 11 and 12 both give random values

When I apply 5V to pins 13-15, channels 0, 11, and 12 all give random values

Applying 5V to pin 0, channel 12 goes high . . .

I'm confused!

(its not cross-pin voltage leaking, I already checked)

[Admin]

It gets even stranger. It appears like the output is out of phase.

For channels 0->7, whatever I apply to pin X, the voltage outputs on pin X+1.

For example, if I put 0V on pin 2, it'll say pin 1 is 0V.

And of course for applying 0V to pin 0, it changes output 12 to 0 . . .

Its just whack!

Also of note, your a2d.h has this:

Code: [Select]

#define ADC_CH_ADC8 0x20
#define ADC_CH_ADC9 0x21
#define ADC_CH_ADC10 0x22
#define ADC_CH_ADC11 0x23
#define ADC_CH_ADC12 0x24
#define ADC_CH_ADC13 0x25
#define ADC_CH_ADC14 0x26
#define ADC_CH_ADC15 0x27
While mine has this:

Code: [Select]

#define ADC_CH_ADC8 0x08 //BG add 8 more chans
#define ADC_CH_ADC9 0x09
#define ADC_CH_ADC10 0x0a
#define ADC_CH_ADC11 0x0b
#define ADC_CH_ADC12 0x0c
#define ADC_CH_ADC13 0x0d
#define ADC_CH_ADC14 0x0e
#define ADC_CH_ADC15 0x0f
I tried using my code in your a2d.h and compiling, but that didn't change anything . . .

[Webbot]

Think I've emailed you on this ... but anyway I've fixed the problem in the next release which I'm in the process of making.

The problem was caused by the routine to detect if the a2d conversion was complete. It was back-to-front. So if you asked to do ADC on channels 0,1, and 2 then it would return immediately with a random value and then return the 'real' ADC reading at a later date - ie for ADC#2 for example. My elementary test only used one ADC channel and that worked ok because the correct value was returned eventually - its only when you have multiple ADC reads that things got jumbled up.
So previous posts regarding adding a '2us' delay sort of helped the problem to get hidden. But nows its fixed.

The ADC channel numbers I use are straight out of the ATmel data sheet. The reason our channel 8 starts at 0x20 is because in between channels 0 and 7 there are a whole host of other modes for measuring voltage differences between sets of ADC pins. My lib still allows you to use these whereas your code maps ADC8-15 over the top of them . Thats where my ADC_NUMBER_TO_CHANNEL macro comes in - it makes my code do the same as yours does for the simple case whilst keeping the 'voltage difference' ability for anyone who may choose to use it by not using the ADC_NUMBER_TO_CHANNEL macro.

Apologies for the headaches.

[Webbot]

Version 1.5 now available. Should sort the A2D and software servo issues you've been having.