gnupic: Thread: SDCC newbie .... First of many questions ...

Hi 

Given there is no such thing as a dumb question, this may be a dumb question.

I've been looking for a GNU based PCI compiler, it appears SDCC may be it.  
My problem is determining which version I need and what command line switches 
and arguments I may need.  What needs to be setup?  etc, to get an initial 
development system up an running using sdcc? Is there a FAQ I can read on 
this to get started?

Thanks in advance
Bob Warner

On Sun, 19 May 2002, Robert Warner wrote:

> Hi 
> 
> Given there is no such thing as a dumb question, this may be a dumb question.
> 
> I've been looking for a GNU based PCI compiler, it appears SDCC may be it.  
> My problem is determining which version I need and what command line switches 
> and arguments I may need.  What needs to be setup?  etc, to get an initial 
> development system up an running using sdcc? Is there a FAQ I can read on 
> this to get started?

Welcome Bob.

Just 2 days ago someone suggested a FAQ for the SDCC PIC Port be created. 
Let me roll off a few FAQ points:

1) SDCC Pic Port is part of SDCC. http://sdcc.sourceforge.net/

2) As of May 2002, SDCC PIC Port is still not 100% ready, but mostly 
usable. It's recommended that the most recent version in CVS be used.

From SDCC's web page, the instructions for getting SDCC from CVS are here:

cvs ####@####.#### login

The password is empty and pressing [ENTER] will get you in.

cvs -z3 ####@####.#### co 
sdcc

... will create the sdcc directory in your current directory and place all 
downloaded code there.

Once everything has been downloaded, you'll need to compile:

$ cd sdcc
$ ./configure
$ make 
$ make install

OR to better customize for your system:

$ aclocal
$ autoheader
$ automake -a
$ autoconf
$ ./configure
$ make
$ make install


3) SDCC is just a compiler. It will produce a .asm file that can be 
assembled either with gpasm or MPASM. gpasm is available on the gputils 
web page: http://gputils.sourceforge.net/

4) gpsim can be used to debug your PIC C-code (at the source level). gpsim 
can be found:
http://www.dattalo.com/gnupic/gpsim.html

5) As of May 2002, the SDCC PIC port does not have Linker support. This 
means all of your code must go into 1 file.

6) Command line arguments. SDCC has many, many command line arguments. 
Most of these are for the 8051 port. The important ones for the PIC port 
are:

 -m    Select the Port. e.g. -mpic14
 -p    Select port specific processor e.g. -mpic14 -p16f84
 -S    Compile only; do not assemble or link

So to use sdcc for the PIC, enter this command:

sdcc -S -mpic14 -p16f84 myfile.c

Note, if you want to see which devices are supported, type:

sdcc -S -mpic14 -pHELP

Processor: HELP
'HELP' was not found.
Valid devices are:
p16f627  p16f628  p16f84   p16f877

(actually, any non-valid processor after -p will print the processor list)
The default processor is the p16f877.

6') Here's a simple script that customizes SDCC command line for a PIC:

# sdcc compile for pic

USAGE="Usage: `basename $0` somefile.c"
SDCCBIN=/exports/gnupic/sdcc/bin

if [ $# -lt 1 ] ; then
  echo "$USAGE"
  exit 1
fi

# compile
${SDCCBIN}/sdcc -S -mpic14 $1

7) After compiling, assemble with gpasm:

$ gpasm -c  -I /usr/local/share/gpasm/header myfile.asm

Note, the -I /usr/... tells gpasm where the .asm include files are 
located. The exact location may be different for your system.
After this command, you'll have three new files: myfile.hex, myfile.lst, 
and myfile.cod. The .hex file is suitable for a device programmer. The 
.lst file is nicely formatted file with tons of information about your 
program. The .cod file is a symbolic file that is used for debugging.

8) Debugging your program. 

$ gpsim -s myfile.cod

All of the information that gpsim needs to know about your C program is 
stored in the .cod file. The gpsim source browser lets you alternate 
between .c and .asm modes. You can double click on either .c or .asm lines 
to set break points. Variable names are preceeded with an under score. So 
if you want to set a break point when the upper nibble of "myvar" is equal 
to 1, then from gpsim's command line type:

gpsim> break wv _myvar 0x10 0xf0

And gpsim's response will be:

break when bit pattern XXX1XXXX is written to register 29
bp#: 0

9) Example code. When you download SDCC from CVS you can look at the PIC 
regression test files for numerous examples on using SDCC. Those are found 
in:

  sdcc/src/regression/*.c

10) Setting the config word. See sdcc/src/regression/configword.c

typedef unsigned int word;

word at 0x2007  CONFIG = _WDT_OFF & _PWRTE_ON;

11) Declaring variables. See sdcc/src/regression/bank1.c

unsigned char dummy=0;
unsigned bit bit1;

typedef unsigned char byte;

byte d2;

unsigned char uchar0 = 0xa5;

data at 0xa0 byte  uc_bank1_temp=0x42;
data at 0xa2 unsigned int  ui_bank1_temp=0;

Notice that bits can be declared and are natively supported by SDCC. This 
is *NOT* an ANSI standar and is thus not portable. 


----
I'll collect this into a FAQ and put it in some easily accessible 
location. If anyone cares to add to this, please let me know.

Scott

Scott Dattalo wrote:
>
> 7) After compiling, assemble with gpasm:
> 
> $ gpasm -c  -I /usr/local/share/gpasm/header myfile.asm
> 
> Note, the -I /usr/... tells gpasm where the .asm include files are
> located. The exact location may be different for your system.
> After this command, you'll have three new files: myfile.hex, myfile.lst,
> and myfile.cod. The .hex file is suitable for a device programmer. The
> .lst file is nicely formatted file with tons of information about your
> program. The .cod file is a symbolic file that is used for debugging.
> 

Starting with gpasm-0.9.14, the -I /usr/local/share/gpasm/header became
unnecessary.  It was added to the default search path.  The path is
reported if you command "gpasm -h".