Hello everyong,
I inherited a project using a PIC18F46K80. I need to set up four channels of A/D. I am using the xc8 compiler. In the library there is a function called "OpenADC()" I have looked at all the examples I can find and they are either for one channel or written in assembly. Here's my question;

In the second parameter, do I have to list all ports I intend to use.

example;


OpenADC(ADC_FOSC_64 & ADC_RIGHT_JUST & ADC_6_TAD,
ADC_CH0 & ADC_INT_OFF & ADC_VREFPLUS_VDD & ADC_VREFMINUS_VSS, etc.

would I use ADC_CH0 & ADC_CH1 & ADC_CH2 & ADC_CH3 ?

Thanks in advance for helping an old newbie!
Paul

 

OpenADC() sets up the various params and starts the conversion on the indicated channel. After that, use SelChanConv_ADC to change the channel select bits in ADCONx and start conversion on the new channel. I haven't used this particular library (XC8 Peripherial Library) but that's what the underlying registers would suggest.

From there, you can run a round-robin select-convert-read loop to get your 4 channels. Don't forget to set up the IO pins as well.

Its kind of primitive i.e. it would be nice to 'open ADC(..) and have it take care of ALL of the register actions (TROS, IO, ANSEL et al) and have it just spit out values but I don't think that's what it does.


Have fun!

 

Thanks John,
it seems like a strange function. In some code I have looked at, it seems they only set up CH0 with the OpenADC() function and then do as you say and call ConvertADC() to start the conversion. This is partly what had me confused. I didn't think you had to open the adc each time. Thanks again for the reply. I'll muse over it a bit more. By the way, I have been "beating the stupid out of sand" for about the same length of time but this is my first PIC controller.
Paul

 

By the way, I have been "beating the stupid out of sand" for about the same length of time but this is my first PIC controller.

Sometimes, the sand beats right back, doesn't it?

FWIW, I've been doing PIC in C and assy for a couple of decades and usually just write my own libraries. I find it easier. If you've done other uC's, you won't have any trouble. If you do, post away.

Good luck!

 

I've never been a big fan of peripheral libraries that are just wrappers for bit twiddling. If I've been reading the data sheet I already have a pretty good idea how to set these things by myself. So to say set up a D2A I prefer to code things like so (ripped from my current PIC18F14K50 project):

    ADCON0 = 0b00001101;
    //         00------   Unimplemented
    //         --0011--   Analog Channel Select bits = AN3
    //         ------0-   GO/DONE: A/D Conversion Status bit
    //         -------1   1 = ADC is enabled
    ADCON1 = 0b00000100;
    //         0000----   Unimplemented
    //         ----01--   +reference supplied externally through VREF+ pin.
    //         ------00   -voltage reference supplied internally by VSS.
    ADCON2 = 0b10111110;
    //         1-------   A/D Conversion Result = Right justified
    //         -x------   Unimplemented
    //         --111---   A/D Acquisition time = 20 TAD
    //         -----110   A/D Conversion Clock = FOSC/64

It's actually less typing then it seems as I start by copying the text out of the data sheet (it's just a PDF) and pasting into my source code.

I use the C18 compiler but this should work in C8 too.

 

I've never been a big fan of peripheral libraries that are just wrappers for bit twiddling.

The very words I was looking for!

 

Really study the family A/D module information on the Data Sheet. It's a 12-bit differential with a few extra configuration registers modes not seen on the plain 10-bit versions on most 8 bit chips.

I have some test code (might be confusing for a PIC newbie) for that chip family using the ADC but it's in C18 also. (the register configs should be the same)
https://github.com/nsaspook/nidaq700/blob/master/mx_test/SlaveO.c

 

Thanks John,
it seems like a strange function. In some code I have looked at, it seems they only set up CH0 with the OpenADC() function and then do as you say and call ConvertADC() to start the conversion. This is partly what had me confused. I didn't think you had to open the adc each time. Thanks again for the reply. I'll muse over it a bit more. By the way, I have been "beating the stupid out of sand" for about the same length of time but this is my first PIC controller.
Paul

You must remember that the libraries that follows the compiler is not carved in stone never to be changed. Nor are they by far compleate for any situation. So you are free to write your own libraries based on the latter libraries. Using any existing code may save you a lot time instead of staring from zero. That was core of comment from John. He did not meant to be rude or ridicule you in any way.

 

That was core of comment from John. He did not meant to be rude or ridicule you in any way.

Thanks, I sure didn't. You might have seen the part of the reply I deleted. I thought it sounded wrong as well.

Thanks to nsaspook as well for noting the enhanced ADC. Didn't look that far. Nice to know.

 

Thanks again everyone. I have looked over the code snippets and see now what is going on. Well, back to the bit bucket for me!
All the best,
Paul

 

FWIW, I've been doing PIC in C and assy for a couple of decades and usually just write my own libraries. I find it easier...

Where do you put your libraries? How do you build them? I noticed that MPLAB doesn't have a way to make libraries, but there are ways to use XC8 from the command line.

 

You don't have to make libraries... If you place your code in files then you have essentially a library... I don't create library files as I need to modify my own source from time to time.. I just include them when I need to....

 

First off, a library may either be simply a source code, or it can be a precompiled code object.

Source code libraries needs the dot-c to be included in your project, and your code to reference the dot-h file somewhere. Each time you rebuild your project you rebuild the library.

Object libraries just need the reference to the dot-h files to be in your project code. The library itself (a dot-o file AFAIK) needs be in the library search path, and the linker will link it back into your code.

Object libraries need to be compiled (once), not by MPLAB but by the compiler you are using (which may work inside MPLAB but is doing the heavy lifting itself).

 

None of that answers my question to JohnInTx. Where do you put your libraries and how do you build them?

 

That's why I commented.... I think John is doing the same as I do....

Are you saying you want to pre-compile them so you never have to worry about them in the future??

EDIT!!!
In the manual 3.3.6... It shows you how to pre-compile a library..

 

I'm willing to bet that someone who's been beating the stupid out of sand since 1974 is using precompiled libraries and automatic linking. Thanks for the section/paragraph, that's the command line method I referred to above. I have just started looking into this, as I have code I want to put into a prebuilt library. I am aware of the facility in MPLAB that specifies the search path.

Now all that remains is find a good way to organized the library project. My PIC projects are presently not organized in any logical way.

 

It said that you can do this in MPLABX But If you read further down in section 8... There is a executable called "Libr" ( command line only ) that automates the process...

 

I didn't mean to ignite a controversy here. I was just trying to convey to the OP that the XC8 libraries provided limited functionality for his application and ErnieM stated it better when describing them as 'wrappers' for register stuffing. That's all.

For Brownout, the procedure for compiling to libraries for XC8 is given in Sec. 8.2 - Librarian in the XC8 user's manual. I've not built libraries in XC8. I have built libraries in PICC18 and the procedure is similar - you make a project with the modules you want in the library then select compile/link to library in the project configuration window. I added the library specification as a command line macro in the project config as well. Eventually though, I reverted to just specifying the files as C source.

My reason for not pre-compiling (PIC) libraries is shared with Ian and Ernie - you have to stop down and recompile the library when a routine changes. Back when I did a lot 8080/5, 6800, HC11, 68000 stuff, it made more sense to put routines in libraries. Development systems were slower with limited storage. Only the called routines get linked so you could put dozens of related routines in a library and only pay for the ones you called.

But those systems were more adaptable to the library model for a big reason, the code and RAM was easily relocatable -AND- the overall system organization didn't change much from project to project.

With PICs, the different families and several variants of each peripheral usually require tweaking. The memory maps change. After a few times trying to build a universal library for the UART, for example, I just decided that it was just as good to leave the code as .C source and add it to the project as needed. Each function UART, I2C, CAN etc, gets its own .C file set - low level hardware drivers - mid level interrupt-handling/buffering etc. - high level API and all use the IODEF.h file that describes the particular hardware/port assignments, PCB revision that might affect things etc.

For PICs, I let the linker take care of fitting things - I've never had occasion to care where it puts things and I don't miss the days when you had to write your own linker scripts/location maps.

Finally, the main reason I avoid using ANYBODY's peripheral libraries is that I want to know exactly how the code is written and ensure that it fits my programming model. That and I don't want to be exposed to changes in the library code over compiler updates that might affect my program.

So while I have indeed been beating the stupid out of sand for a long time, I've adapted my methods and tools to fit a changing environment.

Peace.

 

Well, not the first time I've been wrong

 

Well, not the first time I've been wrong

No worries. If you proceed with building XC8 libraries, I'd be interested to know what you thought of that approach compared to keeping common routines in the source and er.. also how you did it

Have fun!