View previous topic :: View next topic |
Author |
Message |
Hans Wedemeyer
Joined: 15 Sep 2003 Posts: 226
|
PIC18F4520 problems |
Posted: Mon Oct 24, 2005 9:10 pm |
|
|
My design uses a PIC18F4520 TQFP 44 pin package.
It makes use of all 13 ADC inputs. All 13 channels are buffered by an OPAMP to ensure a low impedance source for the ADC input.
#device adc=10
#use delay(clock=29491200)
#use rs232(baud=230400,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8)
The important fuses... among others...
#FUSES NOLVP // turn off LVP make sure this is not an issue.
#FUSES PBADEN // enable Port B as Analog
PCWH Code at startup sets up the chip.
setup_adc_ports(ALL_ANALOG|VSS_VDD);
setup_adc(ADC_CLOCK_INTERNAL|ADC_TAD_MUL_0);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
The heart of the ADC loop for the first 12 channels. This loop is called about 10 times per second.
for ( i=0; i<12; i++)
{
set_adc_channel ( i ); // select the channel
delay_us(10); // hang around
ADC.L = read_adc(); // read the conversion
PutCharCRC16 ( ADC.hl.l ); // send it.
PutCharCRC16 ( ADC.hl.h );
}
First set of readings are good, after that the ADC values never change even if the analog voltage at the pins changes!
Note! the change at each ADC pin is very slow i.e. takes seconds to ramp up to 5 volts.
In other words I get the first set of readings repeated until the code stops !
Did I miss something or what did I do wrong here ?
I hate the ADC built in the PIC, it never fails to give me problems... |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Oct 24, 2005 9:53 pm |
|
|
The first thing I would try is to use an ADC clock based on the
crystal oscillator, rather than the internal RC oscillator.
The data sheet says to use a divisor of 32 for your crystal frequency.
Example:
setup_adc(ADC_CLOCK_DIV_32 | ADC_TAD_MUL_0); |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
Thanks |
Posted: Tue Oct 25, 2005 9:52 am |
|
|
Well if I made the code do what I intended !
It was calling the loop so fast that the display (iPAQ using Bluetooth)
was backed up and sure enough the first several thousand sets of samples are the same (checked with WinHex), but they are not taken at 10 samples per second !
When the iPAQ code finally go around to displaying the changed data several seconds later the penny dropped... !
Thanks for the help.
Hans W |
|
![](templates/subSilver/images/spacer.gif) |
|