Hello folks.
Are projects with multiple source files (section 3.2.3 p27) supported for
the -mpic16 extension?
http://sdcc.sourceforge.net/doc/sdccman.pdf
When using the -mpic16 flag the compiler doesn't seem to produce rel
files when -c is supplied.
~Joshua
-
On Tue, Jul 8, 2014 at 4:03 PM, Unix Savvy Brian wrote:
> Please provide some output with the error message you are getting. You
> might want to add -v option to show the intermediate steps actually taken
> by the SDCC front-end.
>
> that would be helpful.
>
>>
>>
Here is the command and the out
> And where is the -c in this line?
>
>
Ooops, here is act 2 of the six shooter.
user@enj:~/sdcc/proj/count$ ls
count.c
user@enj:~/sdcc/proj/count$ sdcc --std-c99 -mpic16 --use-non-free
-p18f97j60 -c --verbose count.c
Processor: 18f97j60
sdcc: Calling preprocessor...
sdcc: Generating code...
On Wed, Jul 9, 2014 at 9:07 AM, Maarten Brock
wrote:
> The only issue is that gputils uses .o instead of .rel object files and
> thus you see no .rel ;-)
>
>
Ah ha. Ok.
However as sdcc doesn't understand the .o files "warning 119: don't know
what to do with file 'count.o'. file extension unsupp
On Wed, Jul 9, 2014 at 9:52 AM, JuanPi wrote:
> In the makefile that I sent you you could see that I was renaming the
> .o into .rel.
> Works fine like that.
>
>
Here is my millage.
I tried renaming the .o's to .rel's and then with the pic flag still
enabled sdcc complains it doesn't know what a
On Wed, Jul 9, 2014 at 11:59 AM, Joshua Lansford <
joshua.lansf...@laserlinc.com> wrote
>
> strlen is used from the string.h header file which I am assuming is
> /home/user/sdcc/sdcc/device/include/pic16/string.h
>
> Anyone know what I am missing in the call to gplink so t
Hey guys,
I just got uIP .9 is working on MIcroChip's PICDEM.net 2 board being
compiled by sdcc. :-) The PICDEM.net 2 board uses the PIC18F9797J60 with
an internal PHY. Microchip's driver files are of course non-free but can
be distributed as for a MicroChip uP or Ethernet controller. No chan
Hello,
I understand that it is important to not overstuff a micro processor
design to prevent the stack from encroaching on other variables and causing
intermittent corruption that might be hard to detect and difficult to
diagnose.
Where do I look, or what command do I use to determine device u
On Mon, Dec 29, 2014 at 10:20 AM, jon wrote:
On most CPU where the stack works down until it hits the top of the
> variables it is pretty easy to detect. Just stick a known value at the
> end of the variables and test its value in the main loop to see if it
> overwritten. I have done this many t
