Possible BUG: ADC wait time?

[medelec35]

External clock: 10MHz
Whenever use Proteus to simulate ADC, with FC6 no matter what Acquisition cycles delay time e.g 200 or conversion speed, then Proteus Simulation always displays the following:

ADC Bug1.png

(30.19 KiB) Downloaded 2804 times

Enabled Diagnostics and the following was displayed:

ADC Bug2.png

(188.14 KiB) Downloaded 2804 times

Changing Acquisition cycles delay time made no difference to conversion time.
I thought it should?
Although with FC7 the warnings have gone, but again changing Acquisition cycles delay time made no difference at all.
Here are conversion times with FC6 and FC7 and conversion speed is set to FRC:

ADC Bug4.png

(2.05 KiB) Downloaded 2804 times

Should Acquisition cycles delay time made a difference or am I barking up the wrong tree?

Martin

Edit: Not sure why, but there is a not a delay for

Code: Select all

MX_UINT16 FC_CAL_ADC_Sample (MX_UINT8 Sample_Mode)

like there is within the function above.
Adding a delay for example:

Code: Select all

MX_UINT16 FC_CAL_ADC_Sample (MX_UINT8 Sample_Mode)
	{
		MX_UINT16 iRetVal;

		while (adcon0 & 0x04);
		if (Sample_Mode)
		{
			iRetVal = (adresh << 2);							//10-bit ADC
			iRetVal = iRetVal | (adresl >> 6);
		}
		else
			iRetVal = adresh;									//8-bit ADC
			delay_us(50);
		adcon0 = adcon0 | 0x04;									//begin next conversion

		return (iRetVal);
	}

Solves the issue.

[Benj]

Hi Martin,

Hmm you're right that's a strange one.

For the initial ADC conversion we do have a delay in the enable macro to allow the ADC capacitor to pre-charge. After that we sample as quickly as possible so you can use the Raw ADC macros at max speed without pre-charging again. It could be we are doing something wrong and the pre-charge time delay should also be in the sample macro though in practise it seems to work ok.

Proteus are normally very good at getting things right but maybe they are expecting ADC reads to always be in the 1 shot mode rather than the stream mode.

My suggestion would be for us to try and find a way to let the CAL code know if another sample is needed or not. If not then don't immediately sample again, if we do then ensure were not sampling again too fast.