Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

PIC12F1822

Help
regis
2011-09-28
2013-03-12
  • regis
    regis
    2011-09-28

    Hi,
    Is it possible to add a new device to pic14 port when it is not supported by gputils ?
    I tried to add 12F1822 support according to the doc but unsuccessfully.
    Has somebody already tried and succeeded ? I googled but found nothing.

     
  • Borut Ražem
    Borut Ražem
    2011-09-28

    gputils from svn HEAD now supports 12F1822.

    Borut

     
  • regis
    regis
    2011-09-29

    Great ! Thank you.

     
  • regis
    regis
    2011-09-29

    Hi Borut,
    I tried to build gputils but I got this :
    /bin/sh: ../../gputils-0.13.8/ylwrap: Aucun fichier ou dossier de ce type (ylwrap not found)
    I found ylwrap file in the automake 1.11 and I copied  it in the gputils-0.13.8 folder.
    Now everything seems to be fine.

     
  • Borut Ražem
    Borut Ražem
    2011-09-29

    Now a copy of ylwrap is added to gputils svn.

    Borut

     
  • regis
    regis
    2011-09-30

    Hi,
    I build gputils (r.610) and sdcc (r.6884) with 12f1822 support.
    I tried this program :

    #include <pic12f1822.h>
    unsigned int i;
    void main(void)
    {
        TRISA = 0;
        while(1)
        {
            PORTAbits.RA0=1;
            for (i=1;i<1000;i++);
            PORTAbits.RA0=0;
            for (i=1;i<1000;i++);
        }
    }
    

    If I do :

    sdcc -S -V -mpic14 -p12f1822 test.c
    

    Then I get :

    bin/../share/sdcc/include/pic14/pic12f1822.h:873: syntax error: token -> '.' ; column 30
    

    I checked pic12f1822.h but there is no error …
    Any help to put me on the right way ?
    Thank you.
    Régis

     
  • Raphael Neider
    Raphael Neider
    2011-09-30

    I guess that error is due to some #define messing up your identifier namespace. You could try compiling with

    #define NO_BIT_DEFINES 1
    #include <pic12f1822.h>
    

    i.e., define NO_BIT_DEFINES before including the device header.
    Also check to see whether the identifier before the '.' on line 873 has been #define'd, e.g., by looking at the output of

    sdcc -mpic14 -p12f1822 -E test.c
    

    Apart from that, it's pretty difficult to debug code that's not available … Could you at least post some lines around l.873 from the device header or upload the complete file somewhere (e.g., pastebin.com)?

     
  • regis
    regis
    2011-09-30

    Thanks for your help ! That's it !
    I tried with #define NO_BIT_DEFINES 1 and I got :

    test.c:11: error 20: Undefined identifier 'PORTAbits'
    test.c:11: error 25: Structure/Union expected left of '.->'
    test.c:13: error 20: Undefined identifier 'PORTAbits'
    test.c:13: error 25: Structure/Union expected left of '.->'
    

    One problem was that PORTAbits is now called PORTA_bits (same syntax for all SFR's).
    (I wonder if it's new or if it's an error ? It can be really annoying for compatibility.)
    Anyway, I corrected that error and I tried again without #define NO_BIT_DEFINES 1 but I still got the same error.
    Wonder why it happens at line 873 (unsigned char CCP1SEL:1;) ?
    Here are the lines arround :

    #ifndef NO_BIT_DEFINES
    #define CCP1SEL              APFCON_bits.CCP1SEL
    #define P1BSEL               APFCON_bits.P1BSEL
    #define TXCKSEL              APFCON_bits.TXCKSEL
    #define T1GSEL               APFCON_bits.T1GSEL
    #define SSSEL                APFCON_bits.SSSEL
    #define SS1SEL               APFCON_bits.SS1SEL
    #define SDOSEL               APFCON_bits.SDOSEL
    #define SDO1SEL              APFCON_bits.SDO1SEL
    #define RXDTSEL              APFCON_bits.RXDTSEL
    #endif /* NO_BIT_DEFINES */
    // ----- APFCON0 bits --------------------
    typedef union {
      struct {
        unsigned char CCP1SEL:1;
        unsigned char P1BSEL:1;
        unsigned char TXCKSEL:1;
        unsigned char T1GSEL:1;
        unsigned char :1;
        unsigned char SSSEL:1;
        unsigned char SDOSEL:1;
        unsigned char RXDTSEL:1;
      };
      struct {
        unsigned char :1;
        unsigned char :1;
        unsigned char :1;
        unsigned char :1;
        unsigned char :1;
        unsigned char SS1SEL:1;
        unsigned char SDO1SEL:1;
        unsigned char :1;
      };
    } __APFCON0_bits_t;
    extern volatile __APFCON0_bits_t __at(APFCON0_ADDR) APFCON0_bits;
    
     
  • Raphael Neider
    Raphael Neider
    2011-09-30

    OK, both AFPCON and APFCON0 are defined (probably aliases?) with the same bitnames. Now, AFPCON causes

    #define CCP1SEL  AFPCON.CCP1SEL
    

    which causes the following bitfield declaration

    unsigned char CCP1SEL:1;
    

    from AFPCON0 to expand to the invalid sequence

    unsigned char AFPCON.CCP1SEL:1;
    

    I'd recommend removing one of the AFPCON/AFPCON0 aliases (surround the typedef and following BIT_DEFINE stuff with #if 0 … #endif) and go ahead. There might be more bit names that are defined in more than one SFR or in aliases - each of these will cause the same problem and should be removed. Alternatively, you can use NO_BIT_DEFINES and define shorthands for the bits you require yourself, possibly by copying them from the device header.

    Raphael

     
  • regis
    regis
    2011-10-01

    I corrected all aliases.
    My program is now :

    #include <pic12f1822.h>
    unsigned int i;
    void main(void)
    {
        TRISA0 = 0;
        while(1)
        {
            RA0=1;
            for (i=1;i<1000;i++);
            RA0=0;
            for (i=1;i<1000;i++);
        }
    }
    

    I compiled and linked it with :

    bin/sdcc -S -mpic14 -p12f1822 test.c
    bin/gpasm -Dpic12f1822 -D__12f1822 -c test.asm -o test.o
    bin/gplink -I"share/sdcc/lib/pic14" -s"share/gputils/lkr/12f1822_g.lkr" -o test test.o crt0i.o pic12f1822.lib libsdcc.lib
    

    here is what i got with gplink :

    crt0i.o: No such file or directory
    

    I tried without crt0i.o :

    pic12f1822.lib: No such file or directory
    

    I don't have such a lib ! Do I miss something when I build the whole stuff ?
    I tried to link with the only (except libm) lib I have in lib/pic14 (libsdcc.lib) :

    share/gputils/lkr/12f1822_g.lkr:24:Error invalid script command (LINEARMEM)
    share/gputils/lkr/12f1822_g.lkr:59:Error illegal argument (SHADOW)
    share/gputils/lkr/12f1822_g.lkr:65:Error illegal argument (SHADOW)
    share/gputils/lkr/12f1822_g.lkr:173:Error undefined section (linear0)
    

    Sorry to bother you but do you still have a good advice for me ?
    Waiting for the next sdcc revision with 12f1822 support ?

    Thank you.
    Régis

     
  • Raphael Neider
    Raphael Neider
    2011-10-01

    As for the device library: You probably forgot to include the 12f1822 into device/lib/pic14/libdev/devices.txt .

    I'd recommend to let sdcc call the assembler and linker:

    sdcc -mpic14 -p12f1822 --use-non-free test.c
    

    For me (with custom-built gputils and sdcc from SVN heads), this works nicely (until the linking stage).
    If you need to separate the assembling/linking passes or really want to call the tools yourself, please have a look at how sdcc calls the assembler and linker using the -V switch:

    sdcc -mpic14 -p12f1822 --use-non-free -V test.c
    

    There are quite a lot of required switches involved, including search paths for libraries/crt0.

    The gplink error messages should be reported to the gputils team. Basically, LINEARMEM is a unsupported directive (the line can probably be commented out). SHADOW seems to be a new modifier for DATABANKs; commenting out the SHADOW part might help. I have also commented out the last line, the one referring to linear0.

    While writing this I tried to get the linking stage to work and found that the 12f1822 is quite different from other pic14 devices: It has 16-bit indirect addressing (FSRnL/H) rather than 8 bits and allows up to 32 banks as opposed to 2. These changes make the device incompatible with the code emitted by sdcc, which relies on a single, 8-bit FSR and data banks being selectable via bits in STATUS.
    These differences probably also explain why the linker quits its job with

    error: processor family mismatch in "xxx"
    

    You are welcome to play around, but I do not think the 12f1822 will be properly supported by sdcc any time soon. Sorry :-(

     
  • regis
    regis
    2011-10-01

    OK, I have to find another chip.
    I suppose it will be the same with 16f1823 (same family type) and pic16 port ?
    I will report the gplink error messages to the gplink team.
    Thank you for your attention Raphael. It will be useful for the next step.
    Régis

     
  • Raphael Neider
    Raphael Neider
    2011-10-01

    I'd avoid the 16f1823: a quick look at the (common) datasheet indicates that it's the same device as the 12f1822 with some additional I/O but the same problems: The device uses the (extended) 14-bit instruction set (thus requiring the pic14 backend) but "feels" more like a pic16 device with its 16-bit address space and data bank selection scheme and its numerous SFRs. Neither SDCC backend (-mpic14 nor -mpic16) can easily target either of the two devices (12f1822 or 16f1823).

     
  • Borut Ražem
    Borut Ražem
    2011-10-02

    tecodev
    The gplink error messages should be reported to the gputils team. Basically,
    LINEARMEM is a unsupported directive (the line can probably be commented out).
    SHADOW seems to be a new modifier for DATABANKs; commenting out the
    SHADOW part might help. I have also commented out the last line, the one referring
    to linear0.

    This is now fixed in gputils: LINEARMEM and SHADOW directive are currently merely ignored since I don't know their purpose / usage.

    If somebody knows how they should be implemented, please let me know.

    Borut