Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

pic16 and --code-loc

2008-03-01
2013-03-12
  • Jason Bacon
    Jason Bacon
    2008-03-01

    I'm trying to figure out how to use sdcc to program a Vex robot, which is based on the PIC 18f8520.  The Vex has traditionally been programmed with MPLAB and mcc18, and more recently with EasyC and RobotC.

    The first hurdle I need to overcome is the base address of the hex file. The Vex requires programs to reside between 0x0800 and 0x3fff.

    I found the --code-loc linker flag, but it doesn't seem to have any effect.  Is this flag supposed to work the the PIC16 port?  Am I missing something obvious?  I realize that PIC support may not be finished.  If that's why I'm having trouble here, I'll just shut up and be patient...

    As a stop-gap, I thought of hacking the addresses in the hex file after-the-fact, but that would only be simple if the code uses purely relative addressing, which I can't assume.  I haven't had time to explore the machine code format yet.

    Below is a simple test program compiled with what seem to me to be the right flags.  Below that is a segment of the Vex default firmware, to show an example with the correct 0x0800 base address.

    I'm using the Mar 1, 2008 snapshot of sdcc.

    Thanks,

        Jason

    FreeBSD sculpin bacon ~/Prog/VEX/Squares 441: more squares.c 
    void    main\(\)
    
    \{
            int             c,
                            d;
    
            for \(c=0; c<100; ++c\)
            \{
                    d = c \* c;
            \}
            return;
    \}
    
    FreeBSD sculpin bacon ~/Prog/VEX/Squares 442: sdcc -mpic16 -p18f8520 -c squares.c
    
    FreeBSD sculpin bacon ~/Prog/VEX/Squares 443: sdcc -mpic16 -p18f8520 --code-loc 0x0800 -oSquares.hex squares.o
    message: using default linker script "/usr/local/share/gputils/lkr/18f8520.lkr"
    
    FreeBSD sculpin bacon ~/Prog/VEX/Squares 444: more Squares.hex                  :020000040000FA
    :0400000076EF00F0A7
    :06002A00040EF66E010E4B
    :10003000F76E000EF86E0900F550056E0900F550D8
    :10004000066E04E1056702D064EF00F00900F55088
    :10005000006E0900F550016E0900F550026E0900AE
    :100060000900F550E96E0900F550EA6E0900090033
    :100070000900F550036E0900F550046E09000900EF
    :10008000F6CF07F0F7CF08F0F8CF09F000C0F6FF81
    :1000900001C0F7FF02C0F8FF035002E1045009E07D
    :1000A0000900F550EE6EF5CF7EFF0306F6E204067A
    :1000B000F7D707C0F6FF08C0F7FF09C0F8FF05062D
    :1000C00001E2060621EF00F01200006A016A015009
    :1000D000800F800F02E1640E005CD8B075EF00F075
    :1000E000002AD8B0012A67EF00F0120012EEFFF0EC
    :1000F00022EEFFF0F86AA68EA69C15EC00F065ECE7
    :1001000000F0FFD7010012010000600000000100B4
    :0401100000000000EB
    :00000001FF
    

    FreeBSD sculpin bacon ~/Prog/VEX/Firmware 449: more Vex_default_firmware.hex
    :020000040000FA
    :0608000081EF1BF0120065
    :02080600743349
    :0608080056EF12F0120091
    :02080E00C250D6
    :08081000020B01E0010E1200D1
    :0608180049EF19F0120087
    :02081E000200D6

     
    • Jason Bacon
      Jason Bacon
      2008-03-04

      OK, I'm still wondering about the --code-loc flag, but I managed to get the addressing scheme I need by editing the linker script 18f8520.lkr to the following, using the EasyC/mcc linker script as a model.  ( They're not quite compatible, but very similar. )

      // $Id: 18f8520.lkr,v 1.7 2006/08/19 02:50:52 craigfranklin Exp $
      // File: 18f8520.lkr
      // Sample linker script for the PIC18F8520 processor

      // Not intended for use with MPLAB C18.  For C18 projects,
      // use the linker scripts provided with that product.

      LIBPATH .

      CODEPAGE   NAME=vectors    START=0x0            END=0x7FF          PROTECTED
      CODEPAGE   NAME=page       START=0x800          END=0x7FFF
      CODEPAGE   NAME=idlocs     START=0x200000       END=0x200007       PROTECTED
      CODEPAGE   NAME=config     START=0x300000       END=0x30000D       PROTECTED
      CODEPAGE   NAME=devid      START=0x3FFFFE       END=0x3FFFFF       PROTECTED
      CODEPAGE   NAME=eedata     START=0xF00000       END=0xF003FF       PROTECTED

      ACCESSBANK NAME=accessram  START=0x0            END=0x5F
      DATABANK   NAME=gpr0       START=0x80           END=0xFF       PROTECTED
      DATABANK   NAME=gpr1       START=0x100          END=0x1FF
      DATABANK   NAME=gpr2       START=0x200          END=0x2FF
      DATABANK   NAME=gpr3       START=0x300          END=0x3FF
      DATABANK   NAME=gpr4       START=0x400          END=0x4FF
      DATABANK   NAME=gpr5       START=0x500          END=0x5FF
      DATABANK   NAME=gpr6       START=0x600          END=0x6FF
      DATABANK   NAME=gpr7       START=0x700          END=0x7F3
      DATABANK   NAME=dbgspr     START=0x7F4          END=0x7FF          PROTECTED
      ACCESSBANK NAME=accesssfr  START=0xF60          END=0xFFF          PROTECTED

      The resulting hex file is acceptable to the loader (programmer), although it has an extra line in it before the code when compared with the mcc generated code:

      mcc:

      :020000040000FA
      :0608000040EF25F012009C
      :02080600564A50

      sdcc:

      :020000040000FA
      :0400000061EF04F0B8
      :10080000EC0EF66E080EF76E000EF86E0900F5504D
      :10081000056E0900F550066E04E1056702D04FEF42

      If someone can point me to a some good docs on the hex file format, I'd appreciate it.

      Thanks,

          Jason

       
      • > If someone can point me to a some good docs on the hex file format, I'd appreciate it.

        The original Intel specification is also available but you'll find it
        in the documentation for the highly recommended toolset "srecord" as well:

        http://srecord.sourceforge.net/srecord-1.39.pdf     (page 75)

        Btw. both your intel hex snippets do not seem complete, the end of file record
        :00000001FF
        is missing.

        srec_info (part of the above mentioned toolset) complains:)

         
    • Jason Bacon
      Jason Bacon
      2008-03-31

      Thanks for the pointers.

      I know the snippets were incompete: I only posted enough to show the extra line I was referring to.

      Thanks again,

          Jason