Hi Seb,
Sebastien Lelong wrote: >> I suppose you would like both for all devices with 2 VCFG bits in >> ADCONx, thus also PIC of which the .dev file contains only the >> enumerated fields (e.g. 16f88x)? >> Somewhat more work but can be done. > > > Not sure to understand but, for some PICs, there are: > > var volatile bit ADCON0_VCFG0 ... > var volatile bit ADCON0_VCFG1 ... > > I would also like to have: > > var volatile bit*2 ADCON0_VCFG > No misunderstanding: you'll get both! When the .dev file has only a bit*2 field I'll add enumerated bits, when the .dev file has only the enumerated bits I'll add a bit*2 var. I've seen tat the VCFG bits are sometimes in ADCON0, sometimes in ADCON1. That is no problem for the ADC library? > You can have a look at adc_channels.jal, at the end, to understand how I use > it. As you'll see, it's not that straightforward. I did not think enough > about this. The rules are: > > - 0 Vref ? then VCFG0 = VCFG1 = false > - 1 Vref ? then VCFG0 = true > - 2 Vref ? then VCFG0 = VCFG1 = true > > I thought having VCFG as a bit*2 would allow the following: > > VCFG = ADC_NVREF ;(being 0, 1 or 2, how simple !) > > but if it's equal to 2, VCFG should be 0b_11 (VCFG0 = VCFG1 = true), and 2 > is 0b_10, not 0b_11... > > Sorry for this cryptic information. What I mean is if it's too complicated, > or/and if you think it's not a good idea, I can handle it in the lib. All of > this is very versatile, sorry about that! With this (consistent) double declaration of VCFG bits the device files don't become more complex than they already are today. And when it helps to make the library easier, then it is a good solution. >> What about the PVCFG an NVCFG fields (like of the 18F13K50)? Also both >> type of declarations required/desired? My guess: yes! > > > > Crap... I wasn't aware for these bits ! They can be found in 4 PICs: > > 18f13k50, 18f14k50, and their "lf" brothers, 18lf13k50, 18lf14k50 > > Since 18F14K50 seems in the mood these days, I'll have to deal with that > case ! For this bits, I'll make the lib compatible with the original > meaning: Vref is either Vdd or taken from Vref+/- pin, I won't take care > about Vref taken from FVR pin. (?) Seems a good compromise to me. Regards, Rob. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
