Hi Carlo, hi guys,

Thanks Carlo for this explanation. I'm diving into this lib, hoping to
refactor or rewrite a better, more generic one. This will be an incremental
job, stepping over ADC feature one by one (or I'll get lost...):

  - first for midrange:
      - generic way to select ADC channel
      - generic way to perform ADC
      - generic way to select vref
      - etc...
  - same for 18F

Rob has made a nice wiki page (
http://code.google.com/p/jallib/wiki/FindADCON) showing all registers
involved in ADC, for all PICs. There are many combination which I first need
to identify, in order to extract some group of PICs that acting the same way
regarding ADC. A sort of ADC_GROUP for 18F Rob was talking about in MCC18
compiler.

Once these groups are identified, I need to randomly pick several
representatives PIC of each group and read DS to know if they actually
operate the same. I expect execptions...

I'll then unknit adc_hardware, keep what should be, refactor the rest or
rewrite the whole, boil and cook it until I get a working lib, hopefully
better :)

About exceptions, I was thinking about adding some special vars, which could
be declared or not. These vars would represent a user defined custom
configurations, so he can bypass default configuration handled in the lib,
and inject some of his logic/configuration. Ex: if the lib can't handle a
particular PIC (because code miss some generic stuff), user could define
some these va, say channel selection, on his own, so he can test, and
finally report what should be put in the lib.

Also note, about debugging, if we add the opportunity to overrule
procedure/function, these would have help us a lot... But I'm afraid this is
a dead idea... The main argument against this was: lib writer should be able
to tell which proc/func can be overruled or not. "I, the lib writer, don't
want some of my internal procedures to be overruled". The fact is, in our
case, an internal procedure would have to be overruled to test ADC clock
setting, namely "_ad_init_general()". "Just keep it simple" as they say,
we're not building a new J2EE framework...


Back to work !

Cheers,
Seb



> Hi to all,
> Some note to the ADC on 16F690.
> This evening i've playing with my code for the 16F690, I've
> experimentig with clock, ranging from 8Mhz to 125Khz.
> The DS of 16F690 at page 109 has a nice table for FOSC/?? it seems
> that FOSC/16 can handle all the frequency range from
> 125khz to 8Mhz, at least on my test set (LPC with LCD attached on
> portC) it works.
> At page 111 there is a list of action to take to make ADC work, I
> followed it and explained explicitly in the code and it works.
> I'm guessing a way  to assign the input pin in the library but I'm
> thinking it's better to assign it in the code, together with ANSEL
> settings too, but Sebastien could give me an advice.
> The 16F690 has only the selection on VDD or external VREF trough pin
> RA1 for the reference voltage and seem it can trough CHS bit in ADCON0
> select an internal reference
> of 0,6 volt and a CVREF for the conversion, (I didn't undestand very
> well the DS on this point).
>
> PS (Not for Rob and Sebastien that I bothered with PM)  my code for
> 16F690 is on Jallist at
> http://tech.groups.yahoo.com/group/jallist/files/CarloD/
> That's all for now.
>
> Regards, Carlo
>
> >
>


-- 
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to