gnupic: Re: [gnupic] Re: [Sdcc-user] USB compilation for PIC16 - strange errors
Subject:
Re: [gnupic] Re: [Sdcc-user] USB compilation for PIC16 - strange errors
From:
"David Barnett" ####@####.####
Date:
5 Dec 2007 17:28:04 +0000
Message-Id: <4d52f78b0712050927u4f3367d8r61378b6317442011@mail.gmail.com>
On Dec 3, 2007 7:59 AM, Vaclav Peroutka ####@####.#### wrote:
> I have following output (maybe some problems with gputils) - there is
> EEPROM memory. I noticed it in some other projects as well so it is not a
> bug of USB code or SDCC itself.
>
> d:\v\USB-test\PICHID>make
> sdcc -I. -Id:\v\sw\sdcc\include --vc --denable-peeps --optimize-goto
> --optimize-cmp --optimize-df --obanksel=9 --opt-code-size
> --fommit-frame-pointer -mpic16 -pp18f2550 -c main.c
> sdcc -I. -Id:\v\sw\sdcc\include --vc --denable-peeps --optimize-goto
> --optimize-cmp --optimize-df --obanksel=9 --opt-code-size
> --fommit-frame-pointer -mpic16 -pp18f2550 -c usb.c
> usb.asm:399:Warning [220] Address exceeds maximum range for this
> processor.
> ...
The latest version of gputils in our SVN repository should fix this warning
where it isn't appropriate. Previous versions of gputils would never check
code size in absolute mode (as opposed to relocatable mode). The
0.13.5release version added that new feature, but we didn't take
EEPROM into
consideration.
usb.c(704) : warning 110: conditional flow changed by optimizer: so said
> EVELYN the modified DOG
> gplink.exe -I. -Id:\v\sw\sdcc\lib -Id:\v\sw\sdcc\lib\pic16 -m
> pic18f2550.lib libio18f2550.lib libc18f.lib libsdcc.lib crt0.o main.o
> usb.o -s 18f2550.lkr -o USBHID.hex
> warning: processor mismatch in "main.o"
> warning: processor mismatch in "usb.o"
>
> ...
> Strange is the EVELYN stuff - I can't find "SET_DESCRIPTOR" (line 704) in
> the ASM ... Is it correct ?
I'm pretty sure EVELYN is something in sdcc, not gputils. If that's the
case, I can't tell you much about it, but I remember it was a strange
undocumented warning.
>
>
> Regarding mismatches - I don't know. Maybe libraries were generated for
> different PIC processor - hopefully register addresses are OK. Should I
> re-generate them ?
The "maximum range" warnings use data compiled into gpasm, not from any
libraries or linker scripts. It is only affected by what processor sdcc
tells gpasm to use, which in turn comes from the sdcc -m and -p options.
I hope that answers your question. I wasn't positive exactly what the
question was.
David Barnett
