**ATmega328P: 1024**

**ATmega4809: 1023**

I have difficulties to understand this difference.

Author

Message

**ATmega328P: 1024**

**ATmega4809: 1023**

I have difficulties to understand this difference.

The max number you can ever get **IS **1023 (from 10 bits)...the difference is: can you go all the way to vref or one count below it.

The typical standard is that you can go to Vref-1 lsb MAX

https://masteringelectronicsdesi...

note, also, they *could *scale the result by adding an internal resistor divider to give any smaller desired number (1000, 1023, 378, 555, etc) with max voltage at the pin.

So while Vin*1024/vref is correct, they *could theoretically *give vin*555/vref , or anything smaller than 1024 (such as vin*1023/vref)

Last Edited: Wed. Sep 16, 2020 - 07:21 PM

That difference COULD depend on the internal design of the ADC. It was a pretty significant redesign because speeds are now quite a bit faster. So, Microchip does not tell us what, if anything has changed. As a result we don't know what the difference, if any, is. We may never know!

Jim

Level: 10k+ Postman

Joined: Fri. Jul 1, 2005

Posts: 25563 View posts

Location: Basingstoke, Hampshire, UK

Isn't it just a case of whether you're counting fence panels, or fence posts?

The maximum reading you can get from the ADC is all 10 bits at 1; ie, 0x3FF = 1023

But the number of different values that the ADC can return is 1024

The definitions there are a bit unclear. Usually, they are equipped with a floor or ceiling operation.

Maybe consider an analogous case where the converter is 2 bits instead of 10 and make a graph of RES versus Vin/Vref for each case.

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 105132 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Isn't it just a case of whether you're counting fence panels, or fence posts?

Level: 10k+ Postman

Joined: Fri. Jul 1, 2005

Posts: 25563 View posts

Location: Basingstoke, Hampshire, UK

some people argue hotly for 1023 some for 1024.

Indeed.

In practice, at the end of the day, it's just a 1 LSB "error" - which isn't likely to be significant.

Seems like the two different document authors were simply of differing opinion.

Exactly.

It's also going to be a whole lot easier to multiply/divide by 1024 rather than 1023, which might be important if power consumption and/or code size are important.

Steve

Level: 10k+ Postman

Joined: Fri. Jul 1, 2005

Posts: 25563 View posts

Location: Basingstoke, Hampshire, UK

a whole lot easier to multiply/divide by 1024 rather than 1023

Absolutely. Excellent point.

Indeed it is and there's been a lot of prior discussion about this. No doubt "fence post" will be a good search term. It's almost like a religion in fact - some people argue hotly for 1023 some for 1024. Seems like the two different document authors were simply of differing opinion.

I seem to recall some definitive stuff in a prior discussion. Was it something like "you can't really get a 5.0V result when converting the 5V signal"? Now, how in the world will we be able to search out the pertinent prior discussions?

It's also going to be a whole lot easier to multiply/divide by 1024 rather than 1023, which might be important if power consumption and/or code size are important.

Yeah, I see 1023 and I think WTF??

But if you're doing an N/D scaling, you can also just choose your N to be 1024/1023 larger. Or just ignore it because it's down in the noise anyway.

Indeed it is and there's been a lot of prior discussion about this.

Indeed!

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

Quote:Also, you should be dividing by 1024, NOT 1023.Quote:LOL--this has been tossed about before: 2004: https://www.avrfreaks.net/index.p... 2007: https://www.avrfreaks.net/index.p... 2008: https://www.avrfreaks.net/index.p... 2010: https://www.avrfreaks.net/index.p... ... and others. ...Why? (ok it's cheaper). Isn't 1023 max?

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

Disclaimer:Thread title copied verbatim with no permission from owner.

Here is the link my post refers to: http://www.electro-tech-online.com/threads/why-adc-1024-is-correct-and-adc-1023-is-just-plain-wrong.132570/

I found the above post quite interesting, and not being a member of the above forum, I thought you may find it interesting and comment on it a bit.

I found it strange that anyone would divide by 1023 in the first place. Then in the second post I find this line.

Doing the incorrect math of ADC *5 /1023, gives ONE advantage, it means that the top ADC reading of 1023 will give an output result of "5v"

The disadvantages is also there. But the most interesting bit for me is the last heading at the end of the second post.

I'm quoting it all here highlighting what I what like to be lectured about.

Doing the ratio scaling math right!First let's clear one thing up, the ratio scaling math of *x /n is perfect, it has no error.

But there are two rounding down errors that we need to deal with;

1. The ADC hardware itself causes a rounding down error. Every possible input voltage is reounded down to the nearest ADC unit. This error occurs BEFORE any ratio math is done, and can be compensated by adding 0.5 ADC counts to every ADC sample BEFORE any conversion.

Since it is impossible to add 0.5 in integer math the best way is to double the ADC value, and then just add 1, ie; (ADC*2)+1

2. The math *x /n does not introduce error with the *x but the /n operation using integer math causes a rounding down error to the nearest n unit. This integer division rounding down error can be compensated by adding half the divisor; +0.5n /n which in our case is +512 /1024.

However since we have the ADC value already doubled from the previous operation, we need to divide by double, or 2048. So it becomes; +1024 /2048.

Putting it all together.To get a reading of 0.00v to 5.00v from the PIC ADC can be done using the correct data scaling of all samples, and properly compensated integer rounding on all samples, by the following integer math;

((ADC*2)+1) *500 +1024 /2048Using *x of *500 means we are converting 1024 ADC units to 500 output units (which represent 0-500 ie 0.00v to 5.00v).

- The ADC causes rounding down .... I guess that is true for AVR as well as I suppose its the same type of ADC and nothing to be done about it, unless perhaps feed a slightly lower reference voltage?

- /n (divide by n) causes a rounding down in integer math .... true.

- And then the final result, i.e. the formula in turquoise... 1024/2048 should always return 0 in integer maths? I am not so sure if the formula is correctly printed there.
- I think it should read (((ADC*2) +1) * 500 + 1024) / 2048

Crickey, I've never even given it the slightest consideration when converting, and I doubt it will make a difference in most projects, but considering a perfect environment, will it actually make a difference?

...

... and more. OP should digest these and them come back with anything specific. After reviewing some of the threads in making the list, it still makes my head swim. In practice, for me, as long as the ADC gives monotonic results I'm happy. Real-world work discards a few counts at the top and bottom anyway, leaving a convenient

~1000 counts of usable range.

Quote:

- The ADC causes rounding down .... I guess that is true for AVR as well as I suppose its the same type of ADC and nothing to be done about it, unless perhaps feed a slightly lower reference voltage?

- /n (divide by n) causes a rounding down in integer math .... true.

- And then the final result, i.e. the formula in turquoise... 1024/2048 should always return 0 in integer maths? I am not so sure if the formula is correctly printed there.
- I think it should read (((ADC*2) +1) * 500 + 1024) / 2048.

The two round-off additions can be rolled into one by noting that +1 * 500 / 2048 is 500 / 2048 which is 250 / 1024. So this could be done (more clearly IMO) as ((ADC * 500 + (250+512)) / 1024. Does it matter? I'm not convinced. Especially since any system that needs more than trivial accuracy will end up being calibrated anyway.