Error in the ADC definition

[HjH]

Hallo,

the controler is a 16LF1939 with 16MHz tact.

I could not read the 13 ADC Channels with the Flowcode ADC-component. The results of measuring was wild numbers. After my correction of the codes the result was sent correct, but the result had the average deviation from 1.1 %. The maximum deviation of fraud 100%. After the correction the deviation is 0%.
You can the correction of the function "SampleADC" and " ReadAsInt" check in the sample

ADC_Test_2.fcf

(14.46 KiB) Downloaded 375 times

[Rosenbaum]

The results of measuring was wild numbers.

When the numbers jump from 64 - 128 - 192 in "ReadAsByte" and 256 - 512 - 768 in "ReadAsInt", I have the same problem with PIC16F1827 and PIC16F1936.Maybe the problem is the left-right justify or the new Bit's in ADCON0 and ADCON1.

[Rosenbaum]

I found a short and nice solution.
I looked at the "UserCode" from ReadAsInt ans ReadAsByte and changed the code from the 1827/1936-Code

Code: Select all

	short iRetVal;
	SampleADC();
	#ifdef _BOOSTC
		#ifdef ADRES
			iRetVal = (adres << 2);
		#else
			iRetVal = (adresh << 2);
			iRetVal = iRetVal | (adresl >> 6);
		#endif
	#endif
	#ifdef HI_TECH_C
		#ifdef adres
			iRetVal = (adres << 2);
		#else
			iRetVal = (adresh << 2);
			iRetVal = iRetVal | (adresl >> 6);
		#endif
	#endif
	return (iRetVal); 

to the "876A"-Code

Code: Select all

	short iRetVal;
	SampleADC();
	iRetVal = (adresh << 2);
	iRetVal = iRetVal | (adresl >> 6);
	return (iRetVal);

[Benj]

Hello,

Yes it seems that on some of these newer devices both the "ADRES" and "ADRESH" registers are defined which is throwing off the code we use to detect which type is present. I will see if we can make this work correctly for the next release.

[Rosenbaum]

Jes, I think the problem start at
#define ADRES 0x009B
#define ADRESL 0x009B
#define ADRESH 0x009C
in ..\boostc\include\pic16F1xxx.h
It seems that ADRES should used as an integer for AdresL+AdresH, but Flowcode use only AdresL.

[Benj]

Hello,

Yes that makes sense, Hopefully there is an elegant solution to resolve the problem. I guess it depends mainly on whether BoostC have adopted this approach throughout the entire range of devices. We have already thought up a mechanism to allow Flowcode v5 to work much better with regards to component problems such as these by coding the appropriate registers for a device into the FCD device definition file.

[Dmitry Maximenko]

HI,
OK, if I use 16f1827 what shall I do?
Do I need to add C code to solve that problem?
Please modifi my flow chart to get it work:-) then I have chans to anderstand.
Very grateful!

[Benj]

Hello,

You can use the method Rosenbaum suggested above.

Add an ADC component to your program, right click the ADC component and select custom code.

Click the read as byte function and click edit.

Change the code to this.

Code: Select all

SampleADC();
return adresh;

Then click OK and select the read as int function and click edit.

Change the code to this.

Code: Select all

short iRetVal;
SampleADC();
iRetVal = (adresh << 2);
iRetVal = iRetVal | (adresl >> 6);
return (iRetVal);

You will need to repeat this process for each ADC component you have included in your program.

Or you can find the appropriate C file in the Components directory and change the code there so the change becomes permanent.

[Rosenbaum]

The file for pic16F1827 is "PIC_ADC_23.c" in the "Component" Folder.
I attached my file, which is changed to work.

[Dmitry Maximenko]

Thank you VERY much!
Rosenbaum, It solved my problem!
I had the problem in three days to try solve it! Was getting frustrated.-((.

What about the internal voltage reference on 16f1827?
Can we use it in the flow code?

Very grateful for the help!

[medelec35]

16F1822, 16F1823, 16F1824, 16F1825, 16F1828 & 16F1829 are also affected. All use PIC_ADC_26.c . For example using 16F1824 AN2 ReadAsInt. With 0V at pin 11 Instead of reading 0 it was reading at 255
This is solved by placing attached PIC_ADC_26.c into Flowcode V4/components directiory, overwriting original file.
I would like to say thanks to Rosenbaum for solving this issue

Martin