ATMega644P external VREF?

[audioguy]

Is it ok to change the ADMUX register in the ATMega644P to use an external reference, but then still use the ZBasic intrinsics to read the converter?

The reference would still be roughly equal to VCC, but come from a precision regulator with a decoupling filter.

(This is in the context of the "ZBasic for Generic Targets" license, which I'm considering)

Thanks,
--jim

[dkinzer]

Is it ok to change the ADMUX register in the ATMega644P to use an external reference, but then still use the ZBasic intrinsics to read the converter?

If I understand your question correctly, the answer is no. The reason is that when you call GetADC() it sets the ADC registers to do a single-ended conversion with AVcc reference. Setting the ADMUX register prior to the call thus has no effect.

That said, the ADC is fairly simple and you can write some simple code to make it do what you want. As an example, you might check this thread from a while back showing how to do a differential conversion using the mega32-based ZX-24. The details will be slightly different for configuring the ADC to use AVref but the general outline is applicable. Further, there may be some differences in detail (e.g. bit values or even register names) for the mega644P as compared to the mega32.

Also, the example code in the aforementioned thread reads the two bytes of the ADC result separately. It's simpler to just use Register.ADC to read the 10-bit result as a 16-bit value (high order bits will be zero).

Lastly, it is important to note that the ADC clock has a minimum and maximum rate to get the maximum ADC resolution. On the mega644P the range is 50KHz to 200KHz. You must select a prescaler divider such that the main clock frequency divided by the prescaler value falls in this reange. So, for example, if you're running on a 10MHz main clock the divisor must be between 50 and 200. Generally speaking you'll probably want to select the smallest divisor that yields a suitable ADC clock so that conversions complete as quickly as possible.

[audioguy]

Got it, thanks.

I'm coming back to AVR from an excursion into STM32-land, and I'm somewhat amazed to find all the things I don't remember or never knew...

--jim