General Fault When using ADC in dsPIC

[AlPicCss73]

Hi All

As I'm new to the CCS 5, I've a little (big!) problem using the ADC. The problems are:

1. The help of ccs told me that by using #DEVICE ADC=x, I can change the resolution, but this code makes error during the compilation. I learnt that in the ccs 5 I've to change the resolution in the header file. A big progress for me but! if I want to change the resolution in the code whenever I want, what I've to do?

2. look at this code please:

[temtronic]

1) WHY do you want to change the resolution of the ADC when the program is running?

Normally you set it once, done. If set for say 10 bit and you only need 8, then simply shift right twice (10 bits ->> 8 bits). Now you can directly set the ADC register bits, just consult the datasheet's ADC section, then the PIC 'header' file to get the appropriate names of the registers/bits. Though really I've never needed to do that in 20 years...

2) the BIG problem I see is you using the adc_clock_internal ! Again, read the datasheet buy 99.99999% of all ADC use never uses the internal option. I suspect this is cauisng the bad readings.

3) be very careful with the PCB traces and wiring. getting reliable, accurate, repeatable ADC operation means you MUST use proper analog design and layout. If you have poor layout, a 12 bit ADC project might only have 8 bits of 'good' data !

Jay

[drh]

You need to select the ADC channel also. i.e. set_adc_channel(n);
_________________
David

[Ttelmah]

The ADC=x operand, is a _pre-processor directive_, not a program instruction. It changes the actual code generated and registers accessed.

Easiest way to change the value at run time, is to use ADC=16 (giving a left justified 16bit value), and then taking the high byte of the result gives an 8bit value, while /64 will give a 10 bit result.

[AlPicCss73]

[Ttelmah]

Key thing (of course), is that he hasn't told us the actual PIC, or the compiler version.

Now ADC_CLOCK_INTERNAL, should not be used above 1Mhz unless you put the chip to sleep, on 90% of PIC's, but he says 'dsPIC', and most of these do allow the internal clock. So he may be the exception here.

So:
1) Post the compiler version.
2) Post the actual PIC.
3) Post the program.

Currently, he has posted 75% of the program, without all the fuses, chip data, clock settings etc.. These are all vital parts of the program. Without these we cannot compile the code, and see what is wrong.

[AlPicCss73]

[Ttelmah]

OK. Now you have given us the rest of the program.

Comments like 'it works in MicroC', are pointless. CCS, is _not_ MicroC, and both require their own setups. While the core 'language' is the same, every I/O operation and setting is compiler specific. What you post would _not_ work in MicroC, without their settings, and different instructions. It's a bit like saying 'diesel works in my other car'. When the car you are now driving is petrol, that is not exactly a sensible comment....
The read_adc function in MicroC (adc_read), also selects the channel. Downside of this is that it means you have to wait for Tacq, every time you use this function. This is why CCS keep the two operations separate. MicroC also defaults to the RC clock, which is not recommended by the manufacturer for 90+% of PIC's.

So the CCS code should be:

[jeremiah]

As a general note on dsPICs and PIC24's:

It's also good to set to the two oscillator fuses explicitly. The compiler can sometimes figure them out based on your code, but it isn't always able to.

If your clock really is a 20MHz external crystal, then it will probably figure out the correct ones.

That said, on some older revisions I have found bugs with that decision making process.

For a 20MHz external crystal, you should add:

#fuses PR //selects the external oscillator as the source for the mux
#fuses HS //selects the high frequency circuit for the external osc

[Ttelmah]

Agreed.

I did actually check that his compiler version is selecting those fuses correctly, since it is commonly a problem.

[AlPicCss73]

Now it works! Ttelmah was right. The problem was I thought that the channel() selects one of four built in channels in the chip but it selects the pin channels. My bad comprehension and maybe bad explanation of ccs's help.
Thanks guys.

[Ttelmah]

It's actually how the chip itself works.

On the PIC you have a setting that configures 'which' ADC channels are actually connected to the multiplexer. Then you have a setting to select which multiplexer channel to connect to the ADC.
These are separate, since every channel connected to the multiplexer, potentially introduces more noise to the ADC.
CCS show how to do it in their examples, but as a common 'thing' do assume that people actually read the chip data sheets. This is a problem, for people not used to working this way.

The general 'flow chart', for every chip with CCS, is:
Read the CCS manual.
Read the chip data sheet.
Read the .h file for the processor.

Then you'll find every CCS option (and fuse) actually corresponds directly to settings in the data sheet. So on chips that only allow particular combinations of channels to the ADC, these exact options are the defines in the .h file.
Suddenly the options start to make sense.

CCS try to give you 'wrappers' for operations like UART I/O etc., but also try to give you direct access to the hardware. It's very salutary when you code something in assembler, and then try the same operation in CCS, and find that the compiler manages to be within a couple of instructions over dozens of lines of code, of doing it DIY!... This is the 'delight' of CCS, but does bring with it the need to think closer to the chip itself than with some other compilers.