Small Device C Compiler suite

The $LD_LIBRARYPATH solved the config problem. Regular sdcc built as 
expected. Building
the pic16 libsdcc still fails. First the Makefile.common does not 
contain the -mpic16 flag. Second
the compiler has BUS FAULTS building most of the arithmetic library  
modules.

I commented out individual lines until it stopped faulting. It is 
behaving like a stack problem. Almost
all the compound "if" statements cause failure. I am not seeing the same 
problem with Linux.

On the Linux side I have compiled and loaded into a pic18f252 a PID 
algorithm for motor control.
The motors turn but "control" is nowhere to be found. The operations 
include signed 16-bit integer
mult, div, add, sub, and testing for limits.

George

Phuah Yee Keat wrote:

> Phuah Yee Keat wrote:
>
>> I tried it on Solaris8/Sparc.
>>
>> The configure process will complete successfully, if you invoke it 
>> this way
>> $ LD_LIBRARY_PATH=/usr/local/lib ./configure
>>
>> assuming your gcc is in /usr/local/lib, I think this have something 
>> to do with the gcc vs g++ thing about standard c++ libraries, will 
>> try to make a patch if I have the time.
>>
>> Proceeding to make, then stop because the solaris8 yacc compiler 
>> could not process SDCC.y (it was complaining about the except 6 line, 
>> after I removed the -o option that was not supported from the 
>> makefile), maybe will try with bison from sunfreeware.com later.
>
>
> Successfully compiled the whole sdcc snapshot on SOlaris8/Sparc with 
> the following commands
> $ LD_LIBRARY_PATH=/usr/local/lib ./configure
> $ make
>
> With the following packages installed from http://www.sunfreeware.com:
> 1. make-3.80
> 2. gcc_small-3.3.2 (latest version without iconv dependancy)
> 3. bison-1.35 (version 1.875 will spit out a broken pipe error)
> 4. flex-2.5.4a
>
> Cheers,
> Phuah Yee Keat
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

While building with the snapshop of 9/28 I am getting the following message:

gen.c:1574: WARNING: need to allocate new register by name -> iTemp16

followed by a signal 11: SIGSEGV


Regards,
    George

Hi
=20
I have an external .asm file for a custom interrupt vector table:
=20
.module ivect
 .area IVECT (CODE)
 ljmp __sdcc_gsinit_startup
 reti
 .ds 7
 ljmp _timer0_ISR
 .ds 7
 reti
 .ds 7
 reti
 .ds 7
 reti
 .ds 7
 reti
=20
and I assemble this using " asx8051 -plosgff ivect.asm". The 'g' option
tells the assembler that my undefined symbols (such as _timer0_ISR) will
be resolved during linking. When I compile and link this with my main
program, the linker gives an error: "ASlink-Warning-Undefined Global
_timer0_ISR referenced by module 'ivect'. Apparently, this is because
the assembler/compiler does not generate a "global" symbol for my
timer0_ISR function in my main .c file ( _main and
__sdcc_gsinit_startup seems to  have global symbols). I compile and link
everything with : "sdcc -Wl-b IVECT=3D0x0000 --code-loc 0x2000 =
main_prog.c
ivect.rel". What must I do so that the linker will be able to reference
the C-functions in the main file?
=20
thanks for any help.
=20
Jaco
=20
=20
=20
=20
=20
=20

Vangelis,

I would like to start with the math libaries.  What is the next step?

George

Vangelis Rokas wrote:

>
>
> On Fri, 24 Sep 2004, George M. Gallant wrote:
>
>> I must echo the opinion of others, this project needs end users that are
>> willing to live with occasional code generation problems.
>
>
> You are right, as long as these occasional problems are solved in time.
>
>
>> I am building a small robot based on multiple 18f252's and plan on using
>> sdcc for the main line control. I will use assembler for I/O and
>> interrupts. I have built, loaded, and run code entirely from the
>> sdcc/gputls tools set on Linux (no MicroChip).
>
>
> Is there any specific problem with SDCC/pic16 and interrupts, which
> prevented you from writting them in C ? I understand that assembly is
> straghtforward, but what is your opinion?
>
>> I am willing to take on the library support.
>
>
> Read my message to J. Dumaresq, and take your pick. I'll send as soon as
> possible the pieces of sources that will most interest you, or even the
> whole currently implemented sources.
>
> regards,
> Vangelis
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

Alex Faveluke wrote:

>Hi,
>
>Sorry if this is off topic for this list, but I don't know where else to 
>look..
>
>I'm using SDCC to write a very simple polled communication for the EZ2131 
>chip, with the usblib API on the linux host side, fxload for programming.  
>I've got some problems with data returning out of order... like a read gets 
>the previous packet I tried to read.  Are there any good examples for simple 
>polled IO beyond what's in the Cypress book.
>  
>
Examples are in the Cypress developement kit.

>Another problem I've got is that sometimes the chip will disappear from the 
>USB system, and not respond to plugging/unplugging.. It comes up temporarily 
>as an unknown device with no endpoints then disapears again. I have to 
>completely restart my system to fix this.  Is there a way I can just request 
>the entire USB bus to reset?
>
>Thanks,
>
>Alex
>
>  
>
What hardware do you use?   Look to in linux to dmesg to see what the 
kernel recognize - unplug etc.
If the hardware is stable it looks like a software bug. The pipe 0 
messages are no longer answered by your device
due to different errors like stack overflow, disabled interrupts etc.
Bye Wolfgang