Hi guys, I finally did not parse datasheets, as only 7 or 8 was needed to read. The idea was to know how to configure PCFG bits, that is configure how many ADC channels. There are 3 ways to select the number of ADC channels:
- PCFG bits can be found in non-18F PICs, and in this case, there's no logic at all. I copied the PCFG table in a python map - PCFG bits can also be found in 18F. In this case, from the few DS I could read, it appears the meaning is quite straightforward: there are as many PCFG bits as ADC channels, with 1-to-1 relation. If you set PCFG5, channel AN5 is active. There's no need to parse or guess a logic here. Implementation should be easy. - For other PICs, there are ANS bits, I think all coming from ANSEL register. This is the same logic as PCFG for 18F: set ANS4 and channel AN4 is active. Do I understand correctly ? Do I miss something ? Original adc_hardware lib was "only" dealing with "PCFG for non-18F" case, and only for a very few PICs (2 or 3). That's why there was a "adc_hardware_nchan" constant you had to define before using the lib. In this case, you can't select which pin will act as ADC, you just can reach a combination, documented in DS, and controlled by PCFG bits (wanna 4 channels ? Then they will be AN0, AN1, AN4 and AN5, no choice). On the other side, if I understand correctly, with 18F and ANSEL controlled PICs, you can select which pin will act as ADC, one by one. There's no need to define a "adc_hardware_nchan" constant here, it's far more flexible here. Yet we could still provice the ability to pass the number of wanted channels, and the lib would configure them from AN0 to ANx. Not mandatory though... As a consequence, there will be great improvement here (I think :)). And, the API won't be the same regarding the ability to independently select ADC pins, or select them according to a predefined presets. Do you have any suggestions about the future API ? Cheers, Seb 2009/5/7 Sebastien Lelong <[email protected]> > Hi guys, > > (Ahlalala... now I understand and know what you feel, Rob, when you're > diving into datasheets, into this chaotic doom from which few people can get > back from without sanity injury) > > > So... I'm still on ADC lib refactoring (re-writing ?). I've identified > several critical points, like: knowing which pins is analog (mapping RA0 <=> > AN2, for instance), clock selection bits logic, selecting how many ADC > channels you want, selecting the ADC channel you want to read, etc... > > I'm on this point: selecting how many ADC channels you want. The original > adc_hardware.jal lib sets ADCON1 according to the number of channels, > configured by users. Ex: ADCON1 = 0b_0000_1001 will give 6 channels. For > 16F877 and 16F877A. Not for others. These 4 bits (..._1001) are known as > PCFG bits in our device files. In some PICs, the number of wanted channels > are configured through these PCFG bits. In some other PICs, these are the > ANSEL bits responsible for this (that's another topic). > > So far so good... I tried to find a way to extract a common logic from > these PCFG bits, amongst PICs, and it appears there aren't any logic. I'm > about to parse datasheets again, particularly these PCFG tables (see as an > example, datasheet 30325B / 16F7X, page 84). I think this is not a big deal. > > If you "grep _PCFG include/device/*" and combine the results with > datasheet/PIC mapping, this gives 43 datasheets, potentially providing 43 > different ways to interpret these PCFG bits. Not that much for a "by hand" > job, after all... > > The good news, if we have this information, is we'll be able to selectively > set a pin as digital or analog, ala Arduino. Very handy, even powerful I > think. > > > Am I lost in a fifth dimension ? Maybe in higher dimension ? Does the way > I'm trying to walk on is the wrong one ? Do you see any other option to deal > with these PCFG bits ? > > > Cheers, > Seb > -- > Sébastien Lelong > http://www.sirloon.net > http://sirbot.org > -- Sébastien Lelong http://www.sirloon.net http://sirbot.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
