AVR-Chat

Hi all,

I have been looking at PICs and the Atmel chips and the major 
difference appears to be that PIC has one major category and all the 
parts are slightly different.

It seems that you cannot write a program on a PIC and then just port 
it to any other pic.  In some cases, it needs major work, in others, 
its just a few changes.  I think that has a lot to do with the memory 
and how that works.

The Atmel chips are supposed to offer a much better upgrade or should 
I say, chip family ?

The idea being that if you write a program for one chip, you can 
upgrade to another in the same family with very little difficulty.

Anyway, while looking for programmers, I was shown a like to a 
developemnt board and found controller boards.  Herein lies he 
question.

There are ATmega chips, AVR chips, ATmini chips, AT90 chips.

Are these pretty seperate families ? by that I mean if one writes for 
an AT89, do all AT89 chips pretty much use the same program ?  or 
would one need to re-write more than just a few lines to make it 
work ?

Can one write for the ATmini and then use that program on the AT90 ?

I have been googling things like 'differences in atmel chips' 
or 'difference between atmini and avr' and am not getting answers.

Any enlightenment would be appreciated.

Dave

>
>The Atmel chips are supposed to offer a much better upgrade or should 
>I say, chip family ?

The AVRs are very "portable".
I've moved applications between chips, simply by providing the appropriate interrupt vector table. 

Most of the peripherals work the same between chips, though there are some differences.

They do make some 8051-like chips, that aren't part of the AVR family.

i dont think AT89s are AVRs. The AT89 family is an 8051 
avr is a microcontroller. Very different from AVR. 8051 is 
a CISC, AVRs r RISCs. But AVRs instruction set is not so 
reduced  [in my opinion] so it is somewhat similar to 
8051.

The differences between 3 main families of avr [mega, 
tiny, and 90s/standard] are mainly their peripherals, 
memory size, and maybe memory mapping stuff. Name of 
registers are sometimes different, especially between mega 
and the lower classes, coz megas have much more features 
and more memory.

One other important thing is their fuse bits. megas have 
much more fuse bits, and great caution must be taken when 
programming them.

my point is, it is easy to port a program specifically 
made for 1 AVR to another one if that other AVR has 
similar peripherals and meets the required memory size.

im still studying avr myself.

regards,
irfan.

On Wed, 28 Jul 2004 05:13:26 -0000
  "Dave Mucha" <dave_mucha@yahoo.com> wrote:
> Hi all,
> 
> I have been looking at PICs and the Atmel chips and the 
>major 
> difference appears to be that PIC has one major category 
>and all the 
> parts are slightly different.
> 
> It seems that you cannot write a program on a PIC and 
>then just port 
> it to any other pic.  In some cases, it needs major 
>work, in others, 
> its just a few changes.  I think that has a lot to do 
>with the memory 
> and how that works.
> 
> The Atmel chips are supposed to offer a much better 
>upgrade or should 
> I say, chip family ?
> 
> The idea being that if you write a program for one chip, 
>you can 
> upgrade to another in the same family with very little 
>difficulty.
> 
> Anyway, while looking for programmers, I was shown a 
>like to a 
> developemnt board and found controller boards.  Herein 
>lies he 
> question.
> 
> There are ATmega chips, AVR chips, ATmini chips, AT90 
>chips.
> 
> Are these pretty seperate families ? by that I mean if 
>one writes for 
> an AT89, do all AT89 chips pretty much use the same 
>program ?  or 
> would one need to re-write more than just a few lines to 
>make it 
> work ?
> 
> Can one write for the ATmini and then use that program 
>on the AT90 ?
> 
> I have been googling things like 'differences in atmel 
>chips' 
> or 'difference between atmini and avr' and am not 
>getting answers.
> 
> Any enlightenment would be appreciated.
> 
> Dave
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 

===========================================================================================
Netkuis Instan untuk wilayah Bandung (kode area 022) - SD,SMP,SMA berhadiah total puluhan juta rupiah... periode I dimulai 1 April 2004
===========================================================================================

At 01:04 AM 7/28/2004, Astria Nur Irfansyah wrote:

>i dont think AT89s are AVRs. 

They aren't.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

--- In AVR-Chat@yahoogroups.com, "Astria Nur Irfansyah" 
<irfansyah@t...> wrote:

> ... AVRs instruction set
> is not so reduced ...

These days, what distinguishes RISC and CISC is not so much the size 
of the instruction set but whether you can perform operations 
directly on memory. In the AVR, you have to load data from memory to 
a register, operate on it and write it back, therefore it is RISC. 
(There are exceptions for built-in peripherals.) In the ZiLOG Z8 
Encore! (for example) you can operate directly on memory, so it is 
CISC. It's hard to know what relevance this has to users unless you 
are used to one or the other style and are programming in assembly.

Graham.

--- In AVR-Chat@yahoogroups.com, David VanHorn <dvanhorn@c...> wrote:
>> These days, what distinguishes RISC and CISC is not so much the
>> size of the instruction set but whether you can perform operations 
>> directly on memory. In the AVR, you have to load data from memory
>> to a register, operate on it and write it back, therefore it is
>> RISC. 
> Where did you get that idea?
> "RISC" and "CISC" are marketing distinctions.

There's a very good article here:

http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html

> >
> >> ... AVRs instruction set
> >> is not so reduced ...
> >
> >These days, what distinguishes RISC and CISC is not so much the 
size 
> >of the instruction set but whether you can perform operations 
> >directly on memory. In the AVR, you have to load data from memory 
to 
> >a register, operate on it and write it back, therefore it is RISC. 
> 
> Where did you get that idea?
> "RISC" and "CISC" are marketing distinctions.

<SNIP>

Interesting distinctions.  I had thought that CISC is Complex 
Instruction Set and RISC was Reduced Instruction Set and that the 
difference was say with a thing like square root.  If the work is 
doen in software (ie, larger code) then it might be a RISC chip, but, 
if it is done in firmware (CMOS???), it is CISC.  The main difference 
was if you needed to write code for the function or call the firmware 
code for it.... 


OK, this post is not about the similarities or differences as they 
don't seem to really effect programming.

Will the code writen for the AT90 be almost the same as the code for 
the AVR ?  Is my using an assembled boards based on the AT90S2313 a 
good idea ? or should I be more interested in using AVR devices ?

Is there a basic that will handle both ? would a C program need a 
simple alteration, or a major re-write ?

I guess what I am asking is if I had ONE micro to use, which one ?

Dave

At 08:49 AM 7/28/2004, Graham Davies wrote:

>--- In AVR-Chat@yahoogroups.com, "Astria Nur Irfansyah" 
><irfansyah@t...> wrote:
>
>> ... AVRs instruction set
>> is not so reduced ...
>
>These days, what distinguishes RISC and CISC is not so much the size 
>of the instruction set but whether you can perform operations 
>directly on memory. In the AVR, you have to load data from memory to 
>a register, operate on it and write it back, therefore it is RISC. 

Where did you get that idea?
"RISC" and "CISC" are marketing distinctions.
The limit case of RISC is a processor with one infinitely fast instruction called "NOP".  Kind of useless, but really fast!

The more instructions a processor supports, the more you can get done, in a finite number of instructions.  Usually, the CISC processor is slower per cycle than the RISC processor, but this is not always the case. In fact, the Z8 was running at 12 clocks per instruction, the PIC four, and the AVR usually one. 

Atmel has some cases of what I would call BS-Ops, like the SBI/R and CBI/R, (really just AND and OR operations) and CLR, which is really just LDI X,0.  These happen in the assembler though, they aren't implemented as separate instructions in the processor.

>(There are exceptions for built-in peripherals.) In the ZiLOG Z8 
>Encore! (for example) you can operate directly on memory,

True  All on-chip ram is registers. I don't remember if it handles off-chip ram this way, but I doubt it.

> so it is CISC.

BZZZT False.

>
>There's a very good article here:
>
>http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html

This also illustrates the huge gap between the microcontroller world, and the intel/AMD pc processor world.

i agree with Mr Davies. a RISC computer involves register-to-register operation while a CISC involves lots of memory access. that is why the AVR has 32 registers in its register file since a RISC computer requires atleast 32 registers. the CISC however involves memory access. that is why we lots of different addressing modes in a CISC than in a RISC.
 
also, from what i've learned in class, a RISC computer has a definite number of op-codes per instruction, except for memory related instructions. the AVR has 2 bytes of op-codes for simple instructions, as what i've read from the .lst file. 
 
A CISC computer don't have a definite number of op-code per instruction. some may only have 4 bytes, while some have 5 or 6. this is what i've found in the Z-80 uP.
 
the speed of processing a single byte of op-code however goes with the microprogram routines inside the CPU itself.
 

David VanHorn <dvanhorn@cedar.net> wrote:
At 08:49 AM 7/28/2004, Graham Davies wrote:

>--- In AVR-Chat@yahoogroups.com, "Astria Nur Irfansyah" 
><irfansyah@t...> wrote:
>
>> ... AVRs instruction set
>> is not so reduced ...
>
>These days, what distinguishes RISC and CISC is not so much the size 
>of the instruction set but whether you can perform operations 
>directly on memory. In the AVR, you have to load data from memory to 
>a register, operate on it and write it back, therefore it is RISC. 

Where did you get that idea?
"RISC" and "CISC" are marketing distinctions.
The limit case of RISC is a processor with one infinitely fast instruction called "NOP".  Kind of useless, but really fast!

The more instructions a processor supports, the more you can get done, in a finite number of instructions.  Usually, the CISC processor is slower per cycle than the RISC processor, but this is not always the case. In fact, the Z8 was running at 12 clocks per instruction, the PIC four, and the AVR usually one. 

Atmel has some cases of what I would call BS-Ops, like the SBI/R and CBI/R, (really just AND and OR operations) and CLR, which is really just LDI X,0.  These happen in the assembler though, they aren't implemented as separate instructions in the processor.

>(There are exceptions for built-in peripherals.) In the ZiLOG Z8 
>Encore! (for example) you can operate directly on memory,

True  All on-chip ram is registers. I don't remember if it handles off-chip ram this way, but I doubt it.

> so it is CISC.

BZZZT False.


Yahoo! Groups SponsorADVERTISEMENT


---------------------------------
Yahoo! Groups Links

   To visit your group on the web, go to:
http://groups.yahoo.com/group/AVR-Chat/
  
   To unsubscribe from this group, send an email to:
AVR-Chat-unsubscribe@yahoogroups.com
  
   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!

aren't the AT90 chips the early AVR? like the AT90S8515.

Dave Mucha <dave_mucha@yahoo.com> wrote:
> >
> >> ... AVRs instruction set
> >> is not so reduced ...
> >
> >These days, what distinguishes RISC and CISC is not so much the 
size 
> >of the instruction set but whether you can perform operations 
> >directly on memory. In the AVR, you have to load data from memory 
to 
> >a register, operate on it and write it back, therefore it is RISC. 
> 
> Where did you get that idea?
> "RISC" and "CISC" are marketing distinctions.

<SNIP>

Interesting distinctions.  I had thought that CISC is Complex 
Instruction Set and RISC was Reduced Instruction Set and that the 
difference was say with a thing like square root.  If the work is 
doen in software (ie, larger code) then it might be a RISC chip, but, 
if it is done in firmware (CMOS???), it is CISC.  The main difference 
was if you needed to write code for the function or call the firmware 
code for it.... 


OK, this post is not about the similarities or differences as they 
don't seem to really effect programming.

Will the code writen for the AT90 be almost the same as the code for 
the AVR ?  Is my using an assembled boards based on the AT90S2313 a 
good idea ? or should I be more interested in using AVR devices ?

Is there a basic that will handle both ? would a C program need a 
simple alteration, or a major re-write ?

I guess what I am asking is if I had ONE micro to use, which one ?

Dave





Yahoo! Groups SponsorADVERTISEMENT


---------------------------------
Yahoo! Groups Links

   To visit your group on the web, go to:
http://groups.yahoo.com/group/AVR-Chat/
  
   To unsubscribe from this group, send an email to:
AVR-Chat-unsubscribe@yahoogroups.com
  
   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 



		
---------------------------------
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!

>
>Will the code writen for the AT90 be almost the same as the code for 
>the AVR ?  Is my using an assembled boards based on the AT90S2313 a 
>good idea ? or should I be more interested in using AVR devices ?

The AT90 is an AVR.  The 2313 is a lower end AVR, but capable.
My favorite starter chip is the 2343, a little of everything.


>Is there a basic that will handle both ? would a C program need a 
>simple alteration, or a major re-write ?

Basic, C, and assembler are all very different animals.

--- In AVR-Chat@yahoogroups.com, David VanHorn <dvanhorn@c...> wrote:
> At 08:49 AM 7/28/2004, Graham Davies wrote:

> Where did you get that idea? [that CISC
> and RISC are distinguished by the ability
> and iniability to operate directly on
> memory].

Well, a lot of places, actually. Articles on the Web (such as the one 
mentioned in this thread), in technical magazines and presentations 
by vendors. I've also directly observed the difference in processors 
I've worked with.

> "RISC" and "CISC" are marketing distinctions.

This is also true, but not very interesting.

> The more instructions a processor supports ...

Right you are again, but this is all pretty obvious, non-contentious 
and doesn't further the debate.

> All on-chip ram [of the Z8] is registers.
> > so it is CISC. 
> BZZZT False.

Thank you for pointing out my error in such a kind way. However, I 
wan't talking about the Z8, I was talking about the Z8 Encore! Only 
16 memory locations are accessible at any one time as registers. The 
rest must be addressed as memory using one of an intimidatingly large 
number of addressing modes. However, once you've addressed a memory 
location, you can do things to it directly without loading to a 
register, operating and storing the result.

So, it is CISC.

Bing! True.

Graham.

--- In AVR-Chat@yahoogroups.com, David VanHorn <dvanhorn@c...> wrote:
> 
> >
> >Will the code writen for the AT90 be almost the same as the code 
for 
> >the AVR ?  Is my using an assembled boards based on the AT90S2313 
a 
> >good idea ? or should I be more interested in using AVR devices ?
> 
> The AT90 is an AVR.  The 2313 is a lower end AVR, but capable.
> My favorite starter chip is the 2343, a little of everything.
> 
> 
> >Is there a basic that will handle both ? would a C program need a 
> >simple alteration, or a major re-write ?
> 
> Basic, C, and assembler are all very different animals.

What I was trying to say is that if I write a program in Basic for 
the AT90, will it able to be easily be ported over to the tiny or 
mega without much re-programming ?


ditto if the program was in C or if it was in Asm.  I know that a 
port from basic to anything else is a major undertaking as would be 
something going from C to Asm or from any language to another 
language.

Dave

--- In AVR-Chat@yahoogroups.com, David VanHorn <dvanhorn@c...> wrote:
> 
> >
> >What I was trying to say is that if I write a program in Basic for 
> >the AT90, will it able to be easily be ported over to the tiny or 
> >mega without much re-programming ?
> 
> Yes. Easier than any other large family of processors I've worked 
with.
> 
> Atmel brought out the AT90 series first, then the Tiny and Mega 
versions. 
> So, you can think of the Tiny as subsets of the AT90 (like 
AT90S8515 and 8535) and those as subsets of the ATMEGA chips.

That is GREAT news.  

Dave

>
>Well, a lot of places, actually. Articles on the Web (such as the one 
>mentioned in this thread), in technical magazines and presentations 
>by vendors. I've also directly observed the difference in processors 
>I've worked with.

So my tiny-11 is CISC, because it can operate directly on all the ram it can address?
:)

There's a lot of confusion out there, caused by marketers that want their processor to look a certain way to their customer base. 


>> "RISC" and "CISC" are marketing distinctions.
>This is also true, but not very interesting.

Well, I think it's the primary distinction..
It started as a marketing thing to make a processor with a limited (but faster) instruction set look more powerful than a processor with a more comprehensive (but slower) instruction set, and had nothing to do with where the memory was located.


>Thank you for pointing out my error in such a kind way.

:)

> However, I wan't talking about the Z8, I was talking about the Z8 Encore!

Major difference.

> Only 16 memory locations are accessible at any one time as registers. 

Hmm.. Aren't the AVR registers mappable as RAM as well?
I never use them that way, so I don't remember offhand.

>The  rest must be addressed as memory using one of an intimidatingly large 
>number of addressing modes.

The Z8 is good with modes. LOADS of modes. 

> However, once you've addressed a memory location, you can do things to it directly without loading to a register, operating and storing the result.
>
>So, it is CISC.
>Bing! True.

I disagree. Rich Instruction Set, and Complex Instruction Set, make no mention of how ram is accessed.

>
>What I was trying to say is that if I write a program in Basic for 
>the AT90, will it able to be easily be ported over to the tiny or 
>mega without much re-programming ?

Yes. Easier than any other large family of processors I've worked with.

Atmel brought out the AT90 series first, then the Tiny and Mega versions. 
So, you can think of the Tiny as subsets of the AT90 (like AT90S8515 and 8535) and those as subsets of the ATMEGA chips.

Hi, my friend wants to use the ADC of an AT90s8535, but 
she is not sure how. i never had any experience using 
AVR's ADC. My friend told me that there is still some 
external circuit to be made. Is this true? What is the 
purpose of this external circuitry?

And what are the limitations of AVR's ADC? Is is slow 
compared to simple ADCs like 0804/0809?

Thx.
Irfan.
===========================================================================================
Netkuis Instan untuk wilayah Bandung (kode area 022) - SD,SMP,SMA berhadiah total puluhan juta rupiah... periode I dimulai 1 April 2004
===========================================================================================

At 04:05 AM 7/29/2004, Astria Nur Irfansyah wrote:

>Hi, my friend wants to use the ADC of an AT90s8535, but 
>she is not sure how. i never had any experience using 
>AVR's ADC. My friend told me that there is still some 
>external circuit to be made. Is this true? What is the 
>purpose of this external circuitry?

not really.
You need to connect AVCC (always!), you need to supply an external reference, or use VCC for ratiometric measurements (the internal reference is pretty dodgy), you need to supply a cap on the ref pin.  The ADC inputs as on most micros, are relatively low impedance, so if you need high impedance, you'll have to buffer.

Most uP ADCs have these limitations to one degree or another.
Used within it's limits, the ADC in the AVR is pretty nice.


>And what are the limitations of AVR's ADC? Is is slow 
>compared to simple ADCs like 0804/0809?

Yes, it is successive approximation, at something like 200 kHz.
Definitely not what you'd call a flash converter.

<snip>
> You need to connect AVCC (always!), you need to supply an external 
reference, or use VCC for ratiometric measurements (the internal 
reference is pretty dodgy), 

This part is typical for internal or external ADC's.    the ADC value 
is referenced to the power supply or to another value.  if you have a 
good reference, then your ADC reading will be better.

>you need to supply a cap on the ref pin.  The ADC inputs as on most 
>micros, are relatively low impedance, so if you need high impedance, 
>you'll have to buffer.

Depending on the external value, you might need to use an op-amp to 
change the value to get it to read so the highest voltage is the same 
as the chips voltage.    This means that if you are running on 3 
volts and the thing you want to read is 0 to 10 volts, you can use a 
a voltage divider to change that to 0 to 3 volts.  But, if you want 
to measure 0 to 100mV,then you need to ampliphy the value and for 
that an op-amp would be called for.

Since you mentioned external components, this may be on of those that 
would be needed.   But it would be needed for any style ADC you chose.

Dave

On 29 Jul 2004 at 8:15, David VanHorn wrote:

> You need to connect AVCC (always!), you need to supply an external
> reference, or use VCC for ratiometric measurements (the internal reference
> is pretty dodgy), you need to supply a cap on the ref pin.

	Does the same apply to the ATMEGA8 ADC? I have used the internal
reference without problems.

> Yes, it is successive approximation, at something like 200 kHz.

	You can go up to 1MHz if you only need 8 bit precision.

	Mark Jordan

At 08:39 AM 7/29/2004, Mark Jordan wrote:

>On 29 Jul 2004 at 8:15, David VanHorn wrote:
>
>> You need to connect AVCC (always!), you need to supply an external
>> reference, or use VCC for ratiometric measurements (the internal reference
>> is pretty dodgy), you need to supply a cap on the ref pin.
>
>        Does the same apply to the ATMEGA8 ADC? I have used the internal
>reference without problems.

I suspect it's endemic to all micros, but I haven't checked the M8.
On the tiny-26's the "precision" reference of 2.5V was sitting at 2.7V.
10% error into a 10 bit A/D?   

>> Yes, it is successive approximation, at something like 200 kHz.
>
>        You can go up to 1MHz if you only need 8 bit precision.

I never tried "overclocking" it, never really needed to. 
I've heard others complaining about several bits of jitter, but I never saw that, just the expected 1 bit quantization errors.

Hi, Mark

> > You need to connect AVCC (always!), you need to supply an external
> > reference, or use VCC for ratiometric measurements (the internal
reference
> > is pretty dodgy), you need to supply a cap on the ref pin.
>
> Does the same apply to the ATMEGA8 ADC? I have used the internal
> reference without problems.

    Could you post the schematic and program snippet that you used ? When I
tried to use the ADC it seemed to be very bad. I probably made something
quite wrong but did not have the time and incentive ($$) to find out what it
was...

> > Yes, it is successive approximation, at something like 200 kHz.
>
> You can go up to 1MHz if you only need 8 bit precision.

    That makes it even more interesting.... Have you used it at that speed
and got real 8 bit's precision ???

Best regards,
Alexandre Guimaraes ( Avr ADC frustated user :-) )

>
>    Could you post the schematic and program snippet that you used ? When I
>tried to use the ADC it seemed to be very bad. I probably made something
>quite wrong but did not have the time and incentive ($$) to find out what it
>was...

There are some timings to be observed, for when you can change channels.
What I did, was to launch the conversion in the foreground, with the conversion complete ISR storing the data.

I did one system with rotating channels, automatically sampled by the conversion complete ISR, but most of my apps lately, need the samples taken at specific times, so I can't use that approach..

This may also be a factor, if your input is noisy you can have aliasing problems.

Filter the input as much as you can. No sense letting the input change faster than you can sample.

On 29 Jul 2004 at 10:48, Alexandre Guimaraes wrote:

>     Could you post the schematic and program snippet that you used ? When I
> tried to use the ADC it seemed to be very bad. I probably made something
> quite wrong but did not have the time and incentive ($$) to find out what it
> was...

	No electronic voodoo here, just two 100k resistors from the ADC 
channel input pin, one to GND and the other to VREF pin. The audio signal 
goes through a 200nF capacitor. The ADC conversion is started by a timer 
interrupt doing the sample rate of my 1200bps AFSK demodulator (DSP).


 
> > You can go up to 1MHz if you only need 8 bit precision.
> 
>     That makes it even more interesting.... Have you used it at that speed
> and got real 8 bit's precision ???

	Yes, not a problem. As stated in the datasheet.

	Mark Jordan

>
>>     That makes it even more interesting.... Have you used it at that speed
>> and got real 8 bit's precision ???
>
>        Yes, not a problem. As stated in the datasheet.

Well.. They say you can go faster if you don't need 10 bit accuracy, but they never give any guidance on how fast the accuracy degrades above nominal, which is another reason I've never bothered with it.  I don't like treading off the guaranteed specs. Something about needing thousands and thousands of boards to all work right off the production line.

--- In AVR-Chat@yahoogroups.com, "Alexandre Guimaraes" <listas@l...> 
wrote:

> > > Yes, it is successive approximation, at something like 200 kHz.
> > You can go up to 1MHz if you only need 8 bit precision.
> That makes it even more interesting.... 

Just to clarify for anyone not reading the data sheet, these 
frequencies are the SAR clock rate. Conversion takes 13 cycles. So, 
the fastest sample rate is about 77 kHz. The input bandwidth is given 
as 38.5 kHz, which is exactly half this and should probably be taken 
with a pinch of salt. It would be wise to limit the bandwidth of any 
applied signal to this figure to avoid aliasing. I'm sure there are 
more severe restrictions if you're switching inputs.

Graham.

P.S. The above is actually from the ATmega16.

--- In AVR-Chat@yahoogroups.com, "Graham Davies" <YahooGroups@e...> 
wrote:
> --- In AVR-Chat@yahoogroups.com, "Alexandre Guimaraes" 
<listas@l...> 
> wrote:
> 
> > > > Yes, it is successive approximation, at something like 200 
kHz.
> > > You can go up to 1MHz if you only need 8 bit precision.
> > That makes it even more interesting.... 
> 
> Just to clarify for anyone not reading the data sheet, these 
> frequencies are the SAR clock rate. Conversion takes 13 cycles. So, 
> the fastest sample rate is about 77 kHz. The input bandwidth is 
given 
> as 38.5 kHz, which is exactly half this and should probably be 
taken 
> with a pinch of salt. It would be wise to limit the bandwidth of 
any 
> applied signal to this figure to avoid aliasing. I'm sure there are 
> more severe restrictions if you're switching inputs.
> 
> Graham.
> 
> P.S. The above is actually from the ATmega16.


OK, so if you wanted to monitor an analog value, an external ADC 
would be best if the speed of the samples were high.

as for the successive approximation, would the accuracy be higher if 
the process were relatively steady and the change between readings 
were rather small ?

Temperature is a very slow moving process so one would not expect to 
see a process swing of more than a few percent over a few minutes.  
So, would that mean internal ADC readings would be pretty accurate ?

Dave

>
>as for the successive approximation, would the accuracy be higher if 
>the process were relatively steady and the change between readings 
>were rather small ?

Depends..
I used the M8 and M128 ADCs in a thermal printer, and I needed samples taken at a specific time, about 100uS after the burn starts. This is because the huge current draw pulls the battery voltage down during the print.  You can't calculate the burn energy accurately, unless you know the voltage during the burn.

For other inputs like the temperature, I just sampled them whenever convenient, and heavily filtered them in analog.

>Temperature is a very slow moving process so one would not expect to 
>see a process swing of more than a few percent over a few minutes.  
>So, would that mean internal ADC readings would be pretty accurate ?

The internal ADC is accurate, in that it reads out whatever it was when you sampled. 
The trick is that your voltage may have "hair" on it, that either is, or is not, important. 

Where it isn't important, filter it away, or you may read the peak, or valley of the hair, and mistake that for an average value. 

Where it is important, don't filter much at all, and sample at exactly the right time to read the hair you want.

--- In AVR-Chat@yahoogroups.com, "Dave Mucha" <dave_mucha@y...> wrote:

> OK, so if you wanted to monitor
> an analog value, an external ADC 
> would be best if the speed of
> the samples were high.

If you need a sample rate higher than the AVR can provide, the only 
way is to use an external converter. Remember (from earlier posts in 
this thread) there is a speed/accuracy tradeoff available in the AVR. 
If you select the higher ADC speed, you loose some accuracy.

> for the successive approximation,
> would the accuracy be higher if 
> the process were relatively steady
> and the change between readings 
> were rather small ?

No. Successive approximation wipes the slate clean and starts again 
for every conversion.

> Temperature is a very slow moving
> process so one would not expect to 
> see a process swing of more than a
> few percent over a few minutes.  
> So, would that mean internal ADC
> readings would be pretty accurate ?

This is an ideal application of the internal ADC. Use the lower 
sample rate, clocking at 200kHz, for best accuracy. If you are using 
a thermistor, you don't even need an external reference voltage. Just 
work "ratiometrically" by connecting the fixed resistor / thermistor 
divider to whatever you use as a reference. Just don't use VCC 
without cleaning it up, ideally with an inductor and capacitor.

Graham.

On Thu, 29 Jul 2004, Dave Mucha wrote:

> Depending on the external value, you might need to use an op-amp to
> change the value to get it to read so the highest voltage is the same
> as the chips voltage.    This means that if you are running on 3
> volts and the thing you want to read is 0 to 10 volts, you can use a
> a voltage divider to change that to 0 to 3 volts.  But, if you want
> to measure 0 to 100mV,then you need to ampliphy the value and for
> that an op-amp would be called for.
>
> Since you mentioned external components, this may be on of those that
> would be needed.   But it would be needed for any style ADC you
> chose.

What method do you recomend for sourcing +V and -V to the opamp?

Rodrigo

>
>What method do you recomend for sourcing +V and -V to the opamp?

Analog and digital grounds ideally are separated, and meet under the micro. I use 0 ohm resistors, since it's an easy way to fool your cad package into considering AGND and DGND as separate things.   

I take VCC through a small resistor (1-10 ohms) to AVCC, with a large-ish cap to AGND.
Inductors are more effective, but also more expensive.  I've not yet needed to resort to the inductor solution.

Remember that Avcc supplies power to the analog port I/O pins (i.e. if you
use them for regular I/O).  Even if you only use them for analog inputs, the
Schmitt trigger is still active - drawing different current levels for '0'
vs '1'.  If you use Avcc as your reference and if you have too much
resistance on the Avcc line, you will get artifacts on your ADC readings.  I
found out the hard way once with a 100 ohm resistor/cap on the Avcc line...
That is why an inductor is usually recommended.  I find that a simple analog
ground plane connected to everything else at one point with a seperate
bypass cap at Aref & Avcc is good enough.

Of course the problem is much worse if you use some of those lines as
outputs...

-----Original Message-----
From: David VanHorn

>
>What method do you recomend for sourcing +V and -V to the opamp?

Analog and digital grounds ideally are separated, and meet under the micro.
I use 0 ohm resistors, since it's an easy way to fool your cad package into
considering AGND and DGND as separate things.

I take VCC through a small resistor (1-10 ohms) to AVCC, with a large-ish
cap to AGND.
Inductors are more effective, but also more expensive.  I've not yet needed
to resort to the inductor solution.

At 10:50 AM 8/2/2004, Larry Barello wrote:

>Remember that Avcc supplies power to the analog port I/O pins (i.e. if you
>use them for regular I/O).  Even if you only use them for analog inputs, the
>Schmitt trigger is still active - drawing different current levels for '0'
>vs '1'.  If you use Avcc as your reference and if you have too much
>resistance on the Avcc line, you will get artifacts on your ADC readings.  I
>found out the hard way once with a 100 ohm resistor/cap on the Avcc line...
>That is why an inductor is usually recommended. 

Sure. Goes without saying that if you draw enough through the resistor to get any significant droop, it will be a problem, at least for ratiometric conversions.

> I find that a simple analog
>ground plane connected to everything else at one point with a seperate
>bypass cap at Aref & Avcc is good enough.

If the system's not too noisy.

At 12:36 PM 8/2/2004, you wrote:
><?xml version="1.0" ?>
>On 2 Aug 2004 at 10:54, David VanHorn wrote:
> >
> > Sure. Goes without saying that if you draw enough through the resistor to
> > get any significant droop, it will be a problem, at least for ratiometric
> > conversions.
> >
>     Extracted from the Mega8 datasheet:
>     "The ADC has a separate analog supply voltage pin, AVCC. AVCC 
> must     not differ more than ± 0.3V from VCC. See the paragraph “ADC 
> Noise     Canceler” on page 197 on how to connect this pin."
>     Mark Jordan


Well at least for quite a few mega8s out there keep in mind that the avcc 
is probably connected to vcc internal to the chip.
This was discussed at length over at avrfreaks, just want to make sure 
people over here know of the issue.

    http://www.avrfreaks.com/phpBB2/viewtopic.php?t=20967

    So any fancy filtering  on avcc to limit noise or reduce emi  may not 
work as well as expected.

  They may or may not have fixed this on the newr dies, or they perhaps 
just want you to wait for mega88s to fix it.


-carl

>
>  They may or may not have fixed this on the newr dies, or they perhaps 
>just want you to wait for mega88s to fix it.

Well that's a major screwup.

Still, it does not mean that AVCC can be left floating. EVER.

Sometimes, with all the "help" that our vendors give us, I'm amazed that anything ever gets sold.

--- In AVR-Chat@yahoogroups.com, Rodrigo Feher <feher@p...> wrote:
> What method do you recomend for sourcing +V and -V to the opamp?

How about a MAX232?

Mike