Menu ▾ ▴

#1230 pic16 adc functions are not portable

open
nobody
PIC16
5
2026-10-17
2006-11-12
Goofy
No

At least, they are not working for 18f4550 family members.

As driving adc seems to be quite different from a
family to another one, these functions may be specific.

An other option is to remove them from the I/O library.

Discussion

  • Philipp Klaus Krause

    • Category: --> PIC16
     
  • zeynelsagcan

    zeynelsagcan - 2026-10-17

    I re-tested the current PIC16 ADC library with PIC18F4550 using SDCC 4.6.4 around r16998.
    PIC18F4550 is mapped to __SDCC_PIC16_FAMILY = 1824550, which selects __SDCC_ADC_STYLE = 1822200.
    All ADC library sources compile successfully for -p18f4550: adcbusy.c, adcclose.c, adcconv.c, adcopen.c, adcread.c, and adcsetch.c.
    The generated assembly uses the expected PIC18F4550 ADC registers (ADCON0, ADCON1, ADCON2, ADRESH, ADRESL).
    I also tested:

    • channel selection and adc_setchannel()
    • ADC_FOSC_32, ADC_FOSC_64
    • ADC_ACQT_8, ADC_ACQT_20
    • ADC_CFG_1A
    • ADC_VCFG_AN3_AN2
    • right-justified result mode
    • ADC interrupt enable path (ADIF, ADIE, PEIE)
    • conversion start / busy test
    • adc_read()
    • adc_close()
      The generated values and bit operations match the expected PIC18F4550 ADCON0/1/2 model in these tests.
      So the original issue reported here, specifically that the ADC functions do not work for PIC18F4550 family members, appears to have been addressed by the later family/style-specific ADC implementation.
      There are still legacy compatibility comments in adcopen.c around PCFG/VCFG handling, so this should not be taken as proof that every PIC18 ADC family is fully portable. But PIC18F4550 itself appears to be working correctly in the current tree.
     

Log in to post a comment.