AVR: Max ADC clock/Ksps if only 8bits are needed

[Psi]

Anyone have experience with how fast you can clock the ATmega ADC when only needing 8 bits before you start to lose bits. I know ~200khz is the max for 10bits.

I have a product that is currently running the ATMega64A CPU at 7.3728Mhz and the ADC at /16 which is 460khz and it's reading 8bits and it works fine. (35k samples /sec)

For some future changes to the product it would be great to squeeze a tiny bit more out of it. I only need an extra 20% faster sampling but the next ADC clock option is /8 so 921khz and 70k samples/sec.

Obviously I will be testing it, just wondering if anyone had done 70k samples/sec before on an ATMega and knows how well it works?   I'm also a little worried about the number of interrupts this would cause, but that is another issue.

[TomKatt]

Don't AVR's run at 16 MHz master clock?  Is this a power sensitive application that needs to run at reduced speed?

For that matter, I've even overclocked a few projects and haven't run into any issues, though I'm not sure I'd guarantee long term commercial reliability...

EDIT - at some point you might consider either adding another AVR dedicated to data acquisition or moving to a faster platform.  Though I know from personal experience that if you are comfortable with a particular platform that has a lot of value.

[Psi]

No power constraints, it can draw whatever it needs.

Master clock is the CPU core which comes off the crystal or RC osc.
In this case 7.3728Mhz crystal to get correct UART baud rates.

At some point you might consider either adding another AVR dedicated to data acquisition or moving to a faster platform.  Though I know from personal experience that if you are comfortable with a particular platform that has a lot of value.

Yeah, Long term plan is to redo the product with a STM32F0 or similar, something with DMA, but for now I just need to add some extra features to the existing product and maintain backwards compatibility to run the new firmware with new features.


I can do all the new features with the current ADC sample rate, but that means the product specs have to change from processing input data at 40hz to 20hz. So would be nice if i didn't have to do that, which means clocking ADC faster.

[TomKatt]

No power constraints, it can draw whatever it needs.

Master clock is the CPU core which comes off the crystal or RC osc.
In this case 7.3728Mhz crystal to get correct UART baud rates.

It's been a little while, but I'm certain I've built many AVR projects running at 16 MHz and not having baud rate issues.  Then again, I can't remember what serial speeds I used lol.  Most likely 38400 or 115200.  But my neurons aren't what they used to be 

EDIT - isn’t one of the cool design elements of the AVR that it runs many instructions in a single cycle for 16 MIPS?  But I also remember that most i/o operators require 2 or more cycles.

[Psi]

Onboard RC osc only goes up to 8.0MHz on ATMega64A.
And requires fuse bit changes, so cant be done with simple firmware upgrade.
USART error rate is around 8.5% for 115kbaud and 8.000mhz clock according to the table in the DS. (3.5% at 16mhz if it did that)

[TomKatt]

Onboard RC osc only goes up to 8.0MHz on ATMega64A.
And requires fuse bit changes, so cant be done with simple firmware upgrade.
USART error rate is around 8.5% for 115kbaud and 8.000mhz clock according to the table in the DS. (3.5% at 16mhz if it did that)

Ah - you're using onboard clock.  I always used boards that came with external 16 MHz crystals (esp 32.768 KHz for timing) - those ran fine at 16 MHz.  Obviously no good way to modify controllers already in the field if you didn't start with that foundation.

I'm lazy - I'd probably just crank it up and see how she flies lol.

[Psi]

I'm using external 7.3728Mhz crystal to get accurate BAUD rates

[TomKatt]

I'm using external 7.3728Mhz crystal to get accurate BAUD rates

Not familiar with crystal options, but wouldn’t double that result in the same baud rate accuracy?

[Psi]

I'm using external 7.3728Mhz crystal to get accurate BAUD rates

Not familiar with crystal options, but wouldn’t double that result in the same baud rate accuracy?

Double 7.3728Mhz would also be fine yes, any multiple of baud rate freq would be fine and 0% error.  So long as it fast enough to actually capture the signal. Obviously the cpu clock has to be faster than the baud rate by some amount.

You only get the error problem when it's not a multiple. Unless, i think, if your UART supports oversampling which i think most do now. 8bit AVRs are old now and dont do that. There's a big table in the UART section of the datasheet showing you error rates at different clock frequencies.

I think those errors are worst case though, so if it says like 3% error that is assuming the clocks are at the worst possible sync relative to each other and normally that isn't happening.  So running an AVR off the internal RC osc at exactly 1,4,8,16mhz usually doesn't show the errors in the short term but it can ruin your day long term if your protocol doesn't have error checking/recovery

[Kleinstein]

Chanes are the ADC would still get 8  usable bits with 950 kHz ADC clock. That is at least what the datasheets gives as typical. I had not problem getting stable 10 bits even with the ADC running with 310 kHz. So chances are there is some reserve. Things can also depend on the supply and layout. So one has to test it with the real HW anyway. A somewhat higher supply (e.g. 5 V)  could also help to run the ADC faster, because the on resistance of the switches will go down. With a supply at the low end it may be more critical with the ADC speed.

[gatk555]

I did test this some time ago, but can not now find the results.  As far as I recall 8 bits were fine up to 1MHz ADC clock.  The noise-reduction sleep seemed to have no effect.  But I tested only a single example of ATTiny85.

[Psi]

I did test this some time ago, but can not now find the results.  As far as I recall 8 bits were fine up to 1MHz ADC clock.  The noise-reduction sleep seemed to have no effect.  But I tested only a single example of ATTiny85.

Sounds promising then. Thanks.