 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
| 18F45J11 ADC problems |
 Posted: Mon Nov 28, 2011 3:28 am |
 |
|
Any one could translate this for me? "from 18F45J11.h", I cannot work it out at all. My chip is absolutely crazy when I use this values. Whatever it means it does not correspond to real chip whatsoever.
Thank you
| Code: |
#define sAN15 0x80 // H7
#define sAN14 0x40 // H6
#define sAN13 0x20 // H5
#define sAN12 0x10 // H4
#define sAN11 0x8 // F6
#define sAN10 0x4 // F5
#define sAN7 0x800000 // F2
#define sAN5 0x200000 // E0
#define sAN4 0x100000 // A5
#define sAN3 0x80000 // A3
#define sAN2 0x40000 // A2
#define sAN1 0x20000 // A1
#define sAN0 0x10000 // A0
#define NO_ANALOGS 0x0 // None
#define ALL_ANALOG 0xdf00ff // A0 A1 A2 A3 A5 F1 F2 F3 F4 F5 F6 H4 H5 H6 H7 |
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19219
|
|
| Posted: Mon Nov 28, 2011 5:03 am |
|
|
How these values work, is described in the .h file itself, when combined with the manual....
If (for instance), you wanted an analog input on AN11., then you use:
| Code: |
setup_adc_ports(sAN11);
|
If you want an analog input on AN15, and AN7, then you use:
| Code: |
setup_adc_ports(sAN11|sAN7);
|
Then you have an optional second argument controlling the Vref, so if you want to use 0-Vref, as the voltage reference, you use:
| Code: |
setup_adc_ports(sAN11|sAN7,VSS_VREF);
|
The AN numbers are defined _in the data sheet_, so AN11, is RC2.
These are also the numbers you need to use when selecting the analog channel, so to read AN11, you have to set the analog channel as 11.
Obviously you also have to setup the ADC clock, with setup_adc, and (again optionally), you can 'or' in the TAD multiplier to provide automatic acquisition delays. So to use Fosc/64, and a 6*TAD cycle delay, you use:
setup_adc(ADC_CLOCK_DIV_64|ADC_TAD_MUL_6);
Again for values, you _must_ read the data sheet.
There are a couple of selections that are 'non obvious', so (for instance), you can select AN15, though there is no such pin. This is the internal bandgap reference. The values also allow you to select AN13, which the data sheet has as 'reserved'. Again data sheet is your friend...
The table you show, has obviously been 'cut and pasted' from the one for another similar chip with different pin numbers, but it does at heart 'work', seeming to put the right values into registers using the current compiler.
There are also configurations that affect the pins on this chip a lot. So (for instance, you need to turn off the PMP peripheral to use a lot of the pins, and you need to remap the digital peripherals away from the pins you want to use as analog (#PIN SELECT).
Now you say you are getting the chip going crazy - critical thing here _what compiler version_. The bits do work, but it is common for things to go wrong sometimes when new chips are added, and as revisions are made to the compiler, so you need to say 'what version'....
Best Wishes |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Mon Nov 28, 2011 3:16 pm |
|
|
Did you open the datasheet? I did, there are no pins as such, the .h file does not match a real chip so I can do whatever I like but as long as .h file is not corresponding to real device then it will not work. This pic has pins from an0 to 12 - 44pin box, so how do I get my an6 working if it is not there or an15 which does not exist???? The .h file is wrong for this chip.
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19219
|
|
| Posted: Mon Nov 28, 2011 3:33 pm |
|
|
Read what I said.
Yes, the pin names they give, disagree with the chip, but the values do set the correct bits in the registers (I have used the chip), and the AN numbers agree. I also explain AN15.
The numbers they use are just bit masks for the registers. All they have done is copied these from another chip with the wrong names. About 20 seconds work to use and correct to anyone used to programming, and applies to several other chips as well.
Don't expect them to get everything right.
Best Wishes |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Mon Nov 28, 2011 3:43 pm |
|
|
So I did, however not everyone is able to do it. This should be fixed. There is an issue with H4 too which does not work. Thnx
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Mon Nov 28, 2011 3:44 pm |
|
|
By the way I pay then I expect. My customers do too. ;)
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19219
|
|
| Posted: Mon Nov 28, 2011 3:50 pm |
|
|
Yes, which is why you should submit a bug report to them, not here.
Best Wishes |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Mon Nov 28, 2011 11:02 pm |
|
|
Here everyone can read it, so everyone is aware and does not go in circle as I was  , CCS probably knows very well about all those things, it is not first day issue
Regards
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Tue Nov 29, 2011 2:11 am |
|
|
| Code: |
#define sAN12 0x10 // B0
#define sAN11 0x8 // C2
#define sAN10 0x4 // B1
#define sAN9 0x2 // B3
#define sAN8 0x1 // B2
#define sAN7 0x800000 // E2
#define sAN6 0x400000 // E1
#define sAN5 0x200000 // E0
#define sAN4 0x100000 // A5
#define sAN3 0x80000 // A3
#define sAN2 0x40000 // A2
#define sAN1 0x20000 // A1
#define sAN0 0x10000 // A0
#define NO_ANALOGS 0x0 // None
#define ALL_ANALOG 0xff00ff // A0 A1 A2 A3 A5 E0 E1 E2 B2 B3 B1 C2 B0
|
This is very big difference of what is in the original file, like an ocean...
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9102
Location: Greensville,Ontario
|
|
| Posted: Tue Nov 29, 2011 7:04 am |
|
|
One of the problems that CCS faces is the sheer number of different PICs that are available! I've always been impressed that they try to keep up with the ever changing 'silicon' that MC pumps out.How they can test each PIC and sub variations is beyond me as there must be hundreds of 'unique' situations.
I'm slowly migrating from the 877 to the 4550 (it's probably 'obsolete') and every day I find something different and believe me it's hard for an old dog to change his ways!So now ,as well as the CCS Help file on screen, I keep the 4550 datasheet 'open' for reference with every project.
That some things get by is understandable and they do fix 'bugs' once they know about it. |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Wed Nov 30, 2011 2:24 am |
|
|
I need help here, I am running in a circle:
| Code: |
setup_adc_ports(sAN0 | sAN1 | sAN2 | sAN5 | sAN6 | sAN7 | VSS_VDD);
setup_adc(ADC_CLOCK_DIV_16 | ADC_TAD_MUL_16); //set AD ports |
clock is 20Mhz
This is reading routine:
| Code: |
void read_analogue_input(unsigned char adcParameter) { //capture analogue
int i;
float r0;
float r1;
float factor;
float taken_reading;
float tmps;
float tmp_calc;
float tmp_load;
float tmp_result;
disable_interrupts(GLOBAL); //clear interrupts
set_adc_channel(adcParameter);
delay_ms(30);
tmp_load = read_adc();
enable_interrupts(GLOBAL); //clear interrupts
switch (adcParameter) {
case 0:
factor = 3.06;
r0 = 0;
r1 = 0;
break;
case 1:
factor = 3.2;
r0 = 0; //
r1 = 0; //
break;
case 2:
factor = 3.2;
r0 = 0; //
r1 = 0; //
break;
case 5:
factor = 3.2;
r0 = 0; //
r1 = 0; //
break;
case 6:
factor = 3.2;
r0 = 0; //
r1 = 0; //
break;
case 7:
factor = 3.2;
r0 = 0; //
r1 = 0; //
break;
} //*
tmp_result = (tmp_load+r0-r1)/factor;
tmp_result16 = (int16)tmp_result;
raw_data = tmp_load;
if (adcParameter < 3) {
if (tmp_load > 10) {
celsius = tmp_result-273;
kelvin = tmp_result-200; //add 200 in the software
printouth = tmp_result16/0x100;
printoutl = tmp_result16;
} //*
else {
celsius = 0;
kelvin = 0;
} //*
} //*
if (adcParameter > 4) {
tmp_result16 = tmp_result*0x100;
printouth = tmp_result16/0x100;
printoutl = tmp_result16;
} //*
} //void
|
What is happening - when my tested voltage is close to 5V I get perfect reading (each time the same), when I drop it down to less than 4V I get total mess, I get one time raw data 900 and the other 1020, etc, no rules. I have 6 different ANs in use on different circuits and reading is affected in the some way. When I use 18F4520 I have no problems at all, any idea? Whole AD operation is a chaos and I cannot get it doing the job properly, I have no problems on the other chip so I am scratching my head now what is going on...
Circuit is built like this:
On 18f4520 I use lm7805 for 5V supply, lm350 for 13.8V circuits.
On 18F45j11 I use lmXXX-3.3v for 3.3V chip supply and sampled voltages are supplied from circuit with lm350 (13.8V), I test battery, mains, power out, internal temperature I test on lm335 supplied from separate lm350 dropping down to 5V.
I am not sure why 18F4520 works in such config and 18F45j11 not. :(
running on the battery I get supplied voltage of 10.04V but my tests are showing 12.31V which is more than test shows on mains ON (12.163V) - this is crazy and I am almost at the point of throwing CCS out of my window...
Any help with ideas?
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Wed Nov 30, 2011 3:25 am |
|
|
Whoa!!
The PIC18F45J11 is a 3.3V PIC with some 5V tolerant digital inputs. The analague inputs are NOT 5V tolerant, and even if they were you could not measure above your PIC supply voltage, i.e. 3.3V. So you've got a big voltage level problem right there. If you try to drive any analogue input above Vdd or below Vss then all the analogue readings, even from channel with in range voltages, are haywire. So even if you have one out of range you'll get crazy readings for everything. This is a significant weakness of the PIC analogue subsystem. You don't get overrange indications and it doesn't isolate the problem to one channel. You can easily blow up the PIC too by over, or under volting the analogue inputs. I know, I've done it enough times 
Your ADC code seems confused and there are floats everywhere. You delay 30ms after changing the ADC channel, where even 30us would be long (12-15us is generally about right) but you ALSO set ADC_TAD_MUL which makes the ADC do that delay for you, which means you don't need any extra delay in software at all. You've also disabled interrupts while converting. Is there a particular reason for this? Unless there's some silicon errata on the PIC18F45J11 that seriously affects ADC performance that's fixed by this there's no point whatever in doing it. Also the interrupts stay off for over 30ms, which is a looooooooong time.
RF Developer |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Wed Nov 30, 2011 3:41 am |
|
|
Thank you, I think my chip is ok, not blown yet (always can put new one in), now I understand why it goes mad, floats and other things are just a dirty code resulting from war and tests with it . Will be tided up later on. First I will get voltage levels back to what it should be and then see how it is. Thank you for your help, I would not work it out myself, data sheet does not say anything about this as long as I can remember. Now it is so clear... why I didn't work it out myself...? 
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19219
|
|
| Posted: Wed Nov 30, 2011 3:52 am |
|
|
Seriously, simplify and see what is going on.
Now, you are annoyed by the pin names not being right in the header, and one being missing. The latter, is an error, but honestly I have never looked at or used the pin names in the header, preferring _always_ to trust the data sheet instead...
Now, this compiles, runs, and prints a count out from the ADC on channel AN0, to the UART1, merrily for me, changing as I adjust a pot attached to the pin, with no altering the header file or anything. Setup to use the internal clock, since I don't have a 20Mhz crystal, but otherwise should run directly for you.
| Code: |
#include <18F45J11.h>
#device adc=10
#FUSES NOWDT, WDT128, NOXINST, INTRC_IO, NOFCMEN, NOIESO
#use delay(clock=8000000)
#use rs232(baud=9600,parity=N,UART1,ERRORS)
void dummy(void) { //Dummy routine - never used prevents compiler error
int8 i; //Optimiser removes this, so no RAM/ROM wasted....
i=RS232_ERRORS;
}
void main()
{
int16 val;
setup_adc_ports(sAN0, VSS_VDD); //Do use the later syntax here - a lot of more
//recent chips _require_ the VSS_VDD setting as a separate value, not 'ored' in.
setup_adc(ADC_CLOCK_DIV_16 | ADC_TAD_MUL_4);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
setup_timer_4(T4_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
set_adc_channel(0);
do {
val=read_adc();
printf("count = %ld\n\r",val);
} while (TRUE);
}
|
Ah!.
I see as I finished typing, that a really likely reason for your problems has been posted....
Best Wishes |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Wed Nov 30, 2011 2:06 pm |
|
|
Thnx guys for your help, I will change voltages and let you know if chip is cooked or not, I hope not. By the way IRQ being turned off is to do not interrupt the test. Just a safety switch to let it do the test without any breaks in the middle.
CCS is great program but they need to put a little more focus on details because in cases like this one I focus on CCS driver being faulty instead of my circuit. They should have a sit for a week and go through all drivers at once and fix all of it because the particular one is not only one with this error. I have found few more out there.
Thnx
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
