Hi Bill, Rob,
BTW, I don't know if you've noticed, but in all Microchip datasheet is
missing the minimum value for
(Vref+) -|Vref-|. Usually they presume the user is connecting Vref- to Vss
and Vref+ to Vdd or to the internal reference
(1.024V, 2.048V or 4.096V) or to a different one for external Vref+ mode).

The Vref- can be tied to a positive voltage. On old PIC16F876 supplied at
5V, I remember the (Vref+) -|Vref-| = ~2.2V.
I'm quite sure that on XLP microcontrollers supplied at minimum 1.8V this
value must be much smaller.
More than that, Vref- can be tied to a negative voltage of about -0.5V ( at
0.6V the protective diodes on IO pins are conducting) without degrading the
ADC linearity. Again, that value is from memory, measured on PIC16F876
supplied at 5V.

Bill, can you do please a test about these reference voltage values on
16F1783?
thx,


On Fri, Jun 25, 2021 at 6:25 PM Rob CJ <[email protected]> wrote:

> Hi Bill,
>
> Thanks for the update. About the 16F1783. If you look in the datasheet it
> say this:
>
> The CHS<4:0> bits of the ADCON0 register determine which positive channel
> is selected.
> When CHSN<3:0> = 1111 then the ADC is effectively a single ended ADC
> converter.
>
> These CHSN bits seems to be something extra since not al ADC has them
> (CHSN<3:0> are Negative Differential Input Channel Select bits). At reset,
> the CHSN bits are at 0, which selects AN0. So you could try to set these
> bits to 1111 and see if your problem is solved (1111 = ADC Negative
> reference - selected by ADNREF).
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens Bill Beek
> <[email protected]>
> *Verzonden:* vrijdag 25 juni 2021 16:29
> *Aan:* jallib <[email protected]>
> *Onderwerp:* Re: [jallib] Re: ADC library
>
> Hi Rob,
> I've tested your adc lib on several PICs so far found no problems. It
> concerns the following types:
> 16F876A, 18F2520, 18F24K50, 16F1783.
> The latter only works well if AN0 is connected to GND, the other 10 analog
> channels then work well
> with 12 bits of resolution.This also happens with the old adc lib, so I
> suspect something is wrong somewhere in myconfiguration, I'm still looking
> into that.
> I will test some other types later on.
>
> Bill.
> On Wednesday, June 23, 2021 at 9:12:03 AM UTC+2 [email protected] wrote:
>
> Hi Bill,
>
> Thanks for the update but I have chosen a different approach to solve the
> problem.
>
> Yesterday I simplified the ADC library to a basic version so that it
> supports more PICs and to prevent that the libary becomes too complex to
> support all variations of the ADC. Reason is that the library did not
> provide the functionality that it said it did, this because the library
> 'adc_channel.jal' was no longer used some time ago and so some
> functionality was not working because of that (like channel selection and
> setting the reference voltage).
>
> This simplified version makes it more generic but as I mentioned earlier,
> the user has to take the following steps in de main program:
> 1) Set the correct analog input for the used channel(s)
> 2) Set the correct reference voltage. I think the default is often that is
> used VDD as reference which works fine in most cases.
> 3) Set the correct AD clock using the table in the datesheet.
>
> With this change I no longer include the adc_clock.jal library and  so
> this also works for a PIC16F18857.
>
> I attached this version to this post and if there are no objections to
> this change, I need to update the adc sample programs (hmm, 26 sample files
> to check) and test some to see if they work for different PICs.
>
> So @Jallib users. If you have any objections, let me know.
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens Bill Beek
> <[email protected]>
> *Verzonden:* dinsdag 22 juni 2021 21:15
> *Aan:* jallib <[email protected]>
>
> *Onderwerp:* Re: [jallib] Re: ADC library
> Hi Rob, I have included your piece of software in the adc_clock library
> library.
> After I defined the variables  everything worked  properly.
> Of course I have the ADC_ADCS_BITCOUNT set back to 1 in the 16F18857 lib.
> The FRC clock signal is now used, which is also my preference.
> As far as I'm concerned, this chapter is closed
> Thanks again to all who contributed ideas and made suggestions.
>  Bill.
> On Tuesday, June 22, 2021 at 7:17:59 AM UTC+2 vasile wrote:
>
> Hi Rob, this wasn't a  request. I never used the ADC library from the
> jalpack even though I have read it and tried to understand it's philosophy.
> But you have perfectly defined my way of working with ADC. So it's up to
> jal users requests and finally on your own wish.
> best wishes,
>
>
> On Mon, Jun 21, 2021 at 8:18 PM Rob CJ <[email protected]> wrote:
>
> Hi Vasile,
>
> Thanks for the feedback. I agree with you that a basic ADC library is
> better than nothing. I think the Tad calculation is making it more
> beautiful but requires also more space than needed (since it calculates for
> different target clocks).
>
> The basic ADC library would then only start a conversion and return the
> result.
>
> The user of the library should then take care of the following 3 items
> which can be mentioned in the adc.jal library and the sample program:
> 1) Set the correct analog input for the used channel
> 2) Set the correct reference voltage. I think the default is often that is
> used VDD as reference which works fine.
> 3) Set the correct AD clock (Tad) using the table in the datesheet. I
> think if you do not set this it will still work OK.
>
> If we would go this way, the whole Tad calculation (adc_clock.jal) could
> be removed (sorry Rob Hamerling) and adc.jal could be simplified.
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens vsurducan
> <[email protected]>
> *Verzonden:* maandag 21 juni 2021 18:50
> *Aan:* [email protected] <[email protected]>
> *Onderwerp:* Re: [jallib] Re: ADC library
>
> Rob, the library does not need to compute the TAD, that was introduced
> first by a french jallian (i think it was Sebastien Lelong) who tried to
> write an universal ADC library ( and for a short time it works).
> You have only to choose one of the recommended ranges. The ADC will work
> very well with several different clocks...
> As a PIC user, performing an ADC without reading the microcontroller
> datasheet...and letting the library do everything for you just to be easy
> seems weird.
> best wishes,
>
> On Mon, Jun 21, 2021 at 6:28 PM Rob CJ <[email protected]> wrote:
>
> Hi Bill,
>
> I looked into some more details of the library and I think understand why
> it works for you. Since you use the defaults of the PIC after reset and you
> changed ADC_ADCS_BITCOUNT to 2 the program compiles and runs but the clock
> selection that is calculated by the library does not work correctly for the
> PIC you are using.
>
> I am not sure what the ADC clock settings are used now but it may be that
> your ADC now uses a clock source of fosc/2 since a clock register is set to
> 0 (this PIC is different from the other PICs since is uses a separate
> register for the clock of the ADC and that is why it has the setting of 1
> instead of 2 and 3). If you are using fosc/2 then according to the
> datasheet you may be  using it out of spec. see table below with a clock
> frequency of 20 MHz.
>
>
>
> The clock register for your PIC is defined as follows:
>
>
> I was working on an update of the library but got stuck with the clock
> adc_clock part that calculates the Tad.
>
> Maybe somebody else knows what goes wrong in the code below (it always
> results in the warning that the clock speed is too high as if the dword
> 'value' is not calculated correctly). It also results in quite some rom
> space which I do not like.
>
> I wonder why we would not simplify the libary and always use FRC since
> that is always correct according to the table  above. It would make the adc
> library simpler since adc_clock.jal library st no longer needed. If
> somebody has any idea why not to do that,  let me know.
>
>    elsif (ADC_ADCS_BITCOUNT == 1) then
> -- target has separate clock selection register
>       counter = 0
>       done = FALSE
>       ADCON0_ADCS = FALSE                       -- use ADCLK register
>       repeat
>          value = (2 * dword(counter + 1) * 10_000_000) / target_clock
>          if value >= ADC_MIN_TAD then
>             tad_word  = word(value)
>             jallib_adcs = counter
>             done = TRUE
>          end if
>          counter = counter + 1
>       until done | (counter == 64)
>       if !done then
>          _warn "\n\t
> Clock speed too high for Tad, internal ADC oscillator (Frc) selected"
>          tad_word  = 40                        -- (approx)
>          ADCON0_ADCS = TRUE                    -- use Frc
>       end if
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *Van:* [email protected] <[email protected]> namens Bill Beek
> <[email protected]>
> *Verzonden:* maandag 21 juni 2021 16:22
> *Aan:* jallib <[email protected]>
> *Onderwerp:* [jallib] Re: ADC library
>
> Hi Rob,
> After your post I looked even further, I use the latest adc lib and tested
> the first 10 adc channels. they work all the time, and are relatively
> accurate. I also looked at the adc_clock lib and tried to adjust the code.
> The 18857 only has 1 clock selection bit "FRC or crystal controlled" , but
> it didn't work yet. For now, I'm happy with the result.
> Here's a piece of the program I used.
>
> const bit ADC_HIGH_RESOLUTION = true
> const byte ADC_NCHANNEL = 2
> const byte ADC_NVREF = ADC_NO_EXT_VREF
> include adc
> adc_init()
> var word measure
> var word voltage
> var byte lowmeasure
> const byte prefix[] = "Channel "
> const byte highstr[] = " (high) "
> const byte lowstr[] = " (low) "
> const byte suffix[] = ": "
> const byte value[] = "  U = "
> const byte units[] = " Volts."
> forever loop
>    var byte channel = 0
>    -- loop over all channels and read
>    led = !led
>    for 11 using channel loop
>       -- get ADC result, high resolution
>       measure = adc_read_high_res(channel)
>       -- send it back through serial
>       print_string(serial_hw_data,prefix)
>       print_string(serial_hw_data,highstr)
>       print_byte_dec(serial_hw_data,channel)
>       print_string(serial_hw_data,suffix)
>       -- print_word_bin(serial_hw_data,measure) ; this one works !
>       print_word_dec(serial_hw_data,measure) ; I should get ~512
>       voltage = measure * 0.4883  -- 5 V / 1024 * 100 (for 2 decimals)
>      print_string(serial_hw_data,value)
>      --print_word_dec(serial_hw_data,voltage)
>      --print_string(serial_hw_data,value)
>      format_word_dec(serial_hw_data,voltage,5,2) -- decimal 2 = /100
>      print_string(serial_hw_data,units)
>      print_crlf(serial_hw_data)
>        delay_1ms(250)
>       -- Even if we set high resolution, we can still access results
>       -- in low resolution (the 2 LSb will be removed)
>       lowmeasure = adc_read_low_res(channel)
>       print_string(serial_hw_data,prefix)
>       print_string(serial_hw_data,lowstr)
>       print_byte_dec(serial_hw_data,channel)
>       print_string(serial_hw_data,suffix)
>       print_byte_dec(serial_hw_data,lowmeasure) ; I should get ~127
>       print_crlf(serial_hw_data)
>       -- and sleep a litte...
>       --led = OFF
>      delay_1ms(2500)
>    end loop
> end loop
>
> Kind regards Bill.
> On Thursday, June 17, 2021 at 3:56:36 PM UTC+2 Bill Beek wrote:
>
> Hello all,
>
> When I tried to do a test with analog input on the 16F18857 I found that
> the library adc.jal gave 7 errors. In particular, the "adcon0_chs" was not
> recognized. The lib of the 16F18857 does recognize it the "adcon0_adcs" . It
> seems that some newer MCU's have this problem as well.  After a change of
> the adc lib a new error occurred,
> _error "Found unsupported value for constant ADC_ADCS_BITCOUNT".
> Does anyone else have experience with this event or know a solution?
> Thanks, Bill
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/fb841324-9302-4429-b6ce-bf91a8cc5ed2n%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/fb841324-9302-4429-b6ce-bf91a8cc5ed2n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/AM0PR07MB6241CE5B558BCB2464E7B2AEE60A9%40AM0PR07MB6241.eurprd07.prod.outlook.com
> <https://groups.google.com/d/msgid/jallib/AM0PR07MB6241CE5B558BCB2464E7B2AEE60A9%40AM0PR07MB6241.eurprd07.prod.outlook.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/CAM%2Bj4qu%2B4yTSgaMF7V_0%3DEf8ypCOtrenVvJ3xxXwSFuCBxubOw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jallib/CAM%2Bj4qu%2B4yTSgaMF7V_0%3DEf8ypCOtrenVvJ3xxXwSFuCBxubOw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/AM0PR07MB62416C19816AE39CC900C31DE60A9%40AM0PR07MB6241.eurprd07.prod.outlook.com
> <https://groups.google.com/d/msgid/jallib/AM0PR07MB62416C19816AE39CC900C31DE60A9%40AM0PR07MB6241.eurprd07.prod.outlook.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/90d7b00f-fbae-4ece-b4e2-1361b9167f51n%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/90d7b00f-fbae-4ece-b4e2-1361b9167f51n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/828a6520-fea0-441a-8f91-105be2d134can%40googlegroups.com
> <https://groups.google.com/d/msgid/jallib/828a6520-fea0-441a-8f91-105be2d134can%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/AM0PR07MB624157796524C32D2CEEBA38E6069%40AM0PR07MB6241.eurprd07.prod.outlook.com
> <https://groups.google.com/d/msgid/jallib/AM0PR07MB624157796524C32D2CEEBA38E6069%40AM0PR07MB6241.eurprd07.prod.outlook.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/CAM%2Bj4qti2LUe-oMJJnMvnGu%2BkLeFwwKEM2_ywFECGjz%2B7QfRtA%40mail.gmail.com.

Reply via email to