Hi Rob, I understand that even if organizing search a work may costs time (telling who's doing what), you can't be the only one who has to dig every datasheet to find the secret formula. You have to share the burden :)
I also understand your point about reputation, but... it already happened that someone has found a bug, or an non-working device file or library. Reactivity was then clearly high, and this is also about reputation I think. IMO, we'd better spend time on what users are using or are likely to use, not what they will hardly use. And in the meantime, provides more external libraries, protocols, improve peripheral libs (like the ADC one...). >From what you say, I understand you want to let things as they are (running a beep-system). Or... do you want to read these 35 datasheets alone ? If so, please take the time to give some of them to me, even if you may waste some explaining to me where to look, I'm sure I'll learn many things :) Cheers, Seb PS: the only reason you did not see me during marathon of Paris is because I wasn't on Paris by this time. Otherwise you would have seen me for sure. Or not... > Hi Seb, > > Sebastien Lelong wrote: > > > I would appreciate some help in checking the file 'devicespecific.cmd' > >> for the 'unchecked' ADC-group setting of PICs and update the file when > >> appropriate (change the group and/or update the 'checked/unchecked' > mark). > > > > Sure, but don't you think this (checking PIC <=> ADC group) could be done > as > > needed, that is when a user reports to use a PIC and appears not working > ? > > Yes, this is a possibility (the 'beep-system'). Difficult to say if this > is wise. It allows us to spent time on other (higher priority) issues. > But it may also cost reputation when the ADC libs don't work as > expected. > > > So the idea is to check if a PIC in devicespecific.cmd is in appropriate > > group (for those marked as '-'). Can you give a small example/recipe how > to > > do this ? Would the idea be: > > > > - take a PIC in devicespecific.cmd > > - check in MCC18 compiler sources, specifically pconfig.h and adc.h to > see > > if settings is appropriate (where can we find sources ? Can you post > these 2 > > files (and possibly other needed ones) ? > > - double check in datasheet to see if setting is still appropriate > > - fix devicespecific.cmd as needed ? > > Well, I was a bit short. I meant to say that for the 18Fs we may rely on > the MCC18 compiler. I extract the ADC-group directly from pconfig.h of > the MCC18 compiler, in which I expect not many errors (but maybe > Microchip works also with the beep-system!). I later stated that > 'double-checking' would be good. I already have checked for each group 1 > dataset for the ADCONx settings. > > But for the baseline and midrange we only have the datasheets to find > out how the ADC-pins have to be set to digital to find the corresponding > ADC-group. Currently I have for these PICs only ADC-groups V0, V1 or V2 > (or '-' when the PIC doesn't have and ADC module). Maybe some of these > PICs require a different (maybe not yet existing) group. > > > To avoid a PIC to be checked by two persons, you'd need to tell who is > doing > > what... > > Yes, and that requires extra work! So it may be better to have it in one > hand (mine!). It needs scanning the ADC chapters of 'only' about 35 > datasheets. It certainly isn't a high priority issue, and in the > meantime we use the beep-system! > > Thanks for helping to make up my mind! > > Regards, Rob. > > > -- > Rob Hamerling, Vianen, NL (http://www.robh.nl/) > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
