Possible BUG: ADC wait time?

A forums to allow bugs and problems with Flowcode v6 to be reported and resolved.

Moderator: Benj

Post Reply
medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Possible BUG: ADC wait time?

Post by 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.
Martin

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Possible BUG: ADC wait time?

Post by 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.

Post Reply