ADC not working with ATMEGA16A | Code in C

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't know what I'm doing wrong. Although I'm new to C. Can anybody help me out?

 

* Other codes are running on the MCU, so I'm assuming that my hard is ok!

 

* 8 LEDs are connected to portb & 8 leds are connected to portd.

 

* Using atmel studio 6 to code.
 
Here is the Code.

 

#include <avr/io.h>
#define F_CPU 12000000UL
#include <util/delay.h>


int main(void)
{

	DDRD = 0XFF;
	DDRB = 0XFF;			//MAKE PORTB AS OUT PUT
	DDRA = 0X00;			// MAKE PORTA AS INPUT FOR ADC
	ADCSRA = 0X87;	        //ADC ENEBLE & SELECT ck/128
	ADMUX = 0XC0;			// INTERNAL 2.56V REF V,    ADC0 CHANNEL, RIGHT JUSTIFIED 

	while(1)

	{	

		ADCSRA|=(1<<ADSC);			//STARTS CONVERSATION
		while((ADCSRA&(1<<ADIF))==0);
		PORTD = ADCL;
	    PORTB = ADCH;
	    _delay_ms(2000);
	}
    return 0;
}

 

Last Edited: Tue. Jul 11, 2017 - 03:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

there is something very wrong with :

 

 _delay_ms(2000);
 

It can't produce this much delay. The maximum amount that it can produce is dependent on your clock and is far less than 2000ms.

your should use something like this

for (int i = 0; i<250 ;i++) {
_delay_ms(15);
  _delay_ms(15);

}

 

Last Edited: Tue. Jul 11, 2017 - 04:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You wait for ADIF but then never clear it

 

Suggest you change:

		ADCSRA|=(1<<ADSC);			//STARTS CONVERSATION
		while((ADCSRA&(1<<ADIF))==0);

to be:

		ADCSRA |= (1 << ADSC);			//STARTS CONVERSATION
		while (ADCSRA & (1<<ADSC));

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

M3rry wrote:
The maximum amount that it can produce is dependent on your clock and is far less than 2000ms.
Rubbish. If you really think that you are looking at a VERY old version of the documentation! What the manual actually says is:

The maximal possible delay is 262.14 ms / F_CPU in MHz.

 

When the user request delay which exceed the maximum possible one, _delay_ms() provides a decreased resolution functionality. In this mode _delay_ms() will work with a resolution of 1/10 ms, providing delays up to 6.5535 seconds (independent from CPU frequency). The user will not be informed about decreased resolution.

 

If the avr-gcc toolchain has __builtin_avr_delay_cycles() support, maximal possible delay is 4294967.295 ms/ F_CPU in MHz. For values greater than the maximal possible delay, overflows results in no delay i.e., 0ms.

For a LONG time the compiler has had __builtin_avr_delay_cycles() and uses that to implement the function. For the user's 12Mhz that means the max delay is 4294967.295 ms / 12 = 357,913.94125 which is 357.91394125s which is just short of 6 minutes.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you are right, sorry.

 

I have seen the manual but :

 

 

clawson wrote:
The maximal possible delay is 262.14 ms / F_CPU in MHz.

 

 

This line looked so independent that I didn't look further. thank for letting me know

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree that the first paragraph could have included a "however ..." to lead into the following text.

 

The extension given in the second paragraph actually appeared about 10 years ago then the compiler got the much more accurate __builtin_avr_delay_cycles() something like 5 or more years ago.

 

The sentences should probably be rearranged to emphasise the latter and de-emphasise the former.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tell more about what "doesn't work" means.  What results do you expect?  What results are you getting?

 

What level is on Vcc?  Whet level on AVcc?  Are all power and ground pins connected, and properly decoupled?

 

What is connected to the AREF pin?  What voltage level do you measure there?

 

What voltage do you measure at the input pin, PA0?

 

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm assuming that my hard is ok!

Tell us more about your hard, like a diagram.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ikelectro wrote:
* Other codes are running on the MCU, so I'm assuming that my hard is ok!

Maybe those "other codes" just don't use the part(s) of your "hard" that are faulty ... ?

 

Show the schematic!

Instructions for posting images here: http://www.avrfreaks.net/comment...

 

As others have said, you really need to state:

  1. What do you expect the code to do?
     
  2. What does the code actually do?
     
  3. What debug/testing/investigation have you done to find the problem?
    eg, have you stepped through with a debugger or simulator?

 

As a side note, don't write comments in ALL CAPITALS. Text in ALL CAPITALS is just hard to read.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

after a long time. Actually I'm not very well with schematic design. So please don't mind. 

here is the schematic. 

Although I have fixed the voltage at ADC0, the output is always changing after every two 2 seconds.

Atmega16A ADC Circuit

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

As others have said, you really need to state:

  1. What do you expect the code to do?
     
  2. What does the code actually do?
     
  3. What debug/testing/investigation have you done to find the problem?
    eg, have you stepped through with a debugger or simulator?

You still aren't answering these questions!

 

Apart from:

ikelectro wrote:
the output is always changing after every two 2 seconds.

we don't know what the issue is. "changing" could mean anything. If a reading is 517, 519, 516, 518 then that is just "noise". You might expect small changes like that unless your electronics is "solid". But if the changes you are talking about are actually 517, 203, 844, 126 then THAT really is a problem you need to get to the bottom of.

 

So tell us more about the "problem". Like Andy says, what did you expect, what did you get, how are you observing it?

 

BTW you do this:

	ADMUX = 0XC0;			// INTERNAL 2.56V REF V,    ADC0 CHANNEL, RIGHT JUSTIFIED

Shame you used hard coded numbers but I assume one of the upper bits set there matches the comment and is ADLAR ? If so then why are you doing:

		PORTD = ADCL;
	    PORTB = ADCH;

and using the full result? The point of ADLAR is that only the top 8 bits are significant and you only plan to use those.

 

PS forgot to say that as you appear to be reading the results on rows of LEDs as 0/1 binary numbers my examples would be:

 

517, 519, 516, 518 = 10 0000 0101, 10 0000 0111, 10 0000 0100, 10 0000 0110

 

In this case the upper bits remain stable but there'll be some "flickering" in just the lower couple of bits. My other example:

 

517, 203, 844, 126 = 10 0000 0101, 00 1100 1011, 11 0100 1100, 00 0111 1110

 

would see any/all the LEDs flickering wildly.

 

Expect the former, worry about the latter.

Last Edited: Thu. Oct 5, 2017 - 08:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Show your current code so we can see that you did the suggestions above. You'll have the correct result if you followed those suggestion.
.
MG

I don't know why I'm still doing this hobby