Hi Joep,
Joep Suijs wrote: > To reply with an other question: how much value would it add for the > users when we release fast? I did not follow the lists too close > lately, but im impression is that the beta is pretty good. If this is > not the case, then we should focus on fixing the problems. > If the beta is okay, we could either leave it at that or release soon > to get rid of the 'beta' label. I think too that the beta is pretty good, and we repaired some issues (including the compiler), so I agree we can release soon. > As for conditional compiling, I like to revisit the 'hardware version' > discussion. > I think it is a bad idea to do conditional compiling of code on the > device type but need to determine hardware versions of each peripheral > and base the code on this. This hardware version can be defined in the > device files or we can check on the device types in a specific lib. Conditional compile is already used by me in the pic_data_eeprom library to overcome differences in the names for the same register in the MPLAB .dev files and consequently in our device files. I used 'if defined(<register>)' statements to see which register name is used. This is much more practical for both user and maintainer of this library than having separate libraries! BTW. The only (former) problem with conditional includes was that variables declared in such a block were local. There was no problem with the included code. It seems you need for ADC something more. We have already a classification in groups. The ADC_GROUP is currently only mentioned in a comment in the device files but could easily promoted to a constant. > To get an idea about the different hardware versions, I played around > with the 'adcon' registers of all pics. > It turns out that most of the 18f pics don't have such a register, You must have made a mistake in your search. Most 18Fs have ADCON0, ADCON1 and ADCON2 (a global check tells me about 150). > and the 10/16 pics have 11 different combinations (where * = adcon): > *0_ADCS+*0_CHS+*0_GO+*0_NDONE+*0_ADON+*1_ADFM+*1_ADCS2+*1_PCFG+ > #16f819#16f870#16f874#16f876#16f877#16f88 > *0_ADCS+*0_CHS+*0_GO+*0_NDONE+*0_ADON+*1_ADFM+*1_ADCS2+*1_VCFG+ #16f882 > *0_ADCS+*0_CHS+*0_GO+*0_NDONE+*0_ADON+*1_ADFM+*1_PCFG+ > #16f871#16f872#16f873#16f873a#16f874a#16f876a#16f877a > *0_ADCS+*0_CHS+*0_GO+*0_NDONE+*0_ADON+*1_ADFM+*1_VCFG1+*1_VCFG0+ > #16f883#16f884#16f886#16f887#16f913 > *0_ADCS+*0_CHS+*0_GO+*0_NDONE+*0_ADON+*1_PCFG+ > #16f72#16f722#16f737#16f747#16f767#16f777 > *0_ADCS+*0_CHS+*0_GO+*0_NDONE+*0_CHS3+*0_ADON+*2_ACQT+*1_ADFM+*1_ADCS2+*1_VCFG+*1_PCFG+ > #16f74#16f76#16f77#16f785 > *0_ADFM+*0_VCFG+*0_CHS+*0_GO+*0_NDONE+*0_ADON+ #12f675#12f683#12hv615#16f506 > *0_ADFM+*0_VCFG+*0_CHS+*0_GO+*0_NDONE+*0_ADON+*1_ADCS+ > #16f676#16f677#16f684#16f685#16f687#16f688#16f689#16f690#16f716#16f818#16f914#16f916#16f917#16f946#16hv616#16hv785#16lf722 > *0_ANS+*0_ADCS+*0_CHS+*0_GO+*0_NDONE+*0_ADON+ #12f615#16f526#16f616 > *0_ANS+*0_CHS+*0_GO+*0_NDONE+*0_ADON+ #10f222#12f510 > *0_CHS+*0_GO+*0_NDONE+*0_ADON+*1_ADCS+*1_ADREF+ > #16f723#16f724#16f726#16f727#16f73#16lf723#16lf724#16lf726#16lf727#18f1220 Here you count also the differences in bit names. Maybe these differences are too small to justify separate libraries. > Besides this 11 versions, we have different domains of this registers > - like 16f877 and 16f876 who have the same registers but resp. 8 and 5 > ad channels. Maybe we could declare the number of channels and resolution (and other relevant differences) as constants in the device files as well, maybe these differences are already contained in the ADC_GROUP classification! Have a look in the MCC18 headers or in the dev2jal script (and in the devicespecific script. > It all looks like a lot of work to support all those versions. But the > least we should do, is handle these versions or users will get lost. What is the definition of 'hardware version', something like ADC-GROUP? > What I suggest: > - use different hardware versions in the library code. Meaning 1 libary for all PICs? > - assign the hardware versions in the lib itself, based on the type. > - divide support in two classes: full and beta, where 'full' means we > have actually tested this lib on that chip (or one in the same > datasheet). Beta means it compiles and could work, but we have not > verified it (like 16f882 which is close to 16f877). > Beta code can be enabled by an flag; default, compile will fail on a > pragma error. Isn't this the difference between validated and unvalidated, only that you have one library which is partly validated and partly not? Regards, Rob. BTW I have small test boards ready for 40-, 28-, 20-, 18- and 14-pins DIP packages. All have a LED on A0 for 'blink-an-LED' and all have a connector for an LCD (4-bits datapath). Most boards are tested with several PICs. A 8-pins board will follow soon (without LCD!). I can add an ADC input to most of the boards, so I'll have an opportunity to test the ADC library. -- Rob Hamerling, Vianen, NL (http://www.robh.nl/) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
