SDCC open source C compiler

[vanepp]

Hopefully the start of a single discussion of progress on getting SDCC to work with the
iMCU7100EVB.
For those unfamiliar with SDCC its is an open source C compiler (and thus that best of all possible
prices free!) for 8051s, Z80s, some PICs and a 68xx or two. It is available from

http://sdcc.sourceforge.net/

Two things I know so far:

1) Don't do this:

void main()
{

Init_iMCU(); // Initialize iMCUW7100
lcd_init(); // Initialize Charater LCD

/* Output LCD */
lcd_command(LCD_CLEAR);
evb_set_lcd_text(0," Network CH_LCD ");
}

it causes main() to return which is a no no (I spent most of the afternoon trying to figure out why
this doesn't work before noticing a comment in the assembler output about not returning from
main() because bad things will happen). This does as little (i.e. it does the initialization and then
nothing til reset) but the write to the LCD is successful rather than the puzzling garbage from the first case.

2) You can fix the complaint about the redefinition of size_t by adding a conditional to the types.h
file from this:

#ifndef _SIZE_T
#define _SIZE_T
typedef unsigned int size_t;
#endif

to this

#if !defined(_SIZE_T) && !defined (_SIZE_T_DEFINED) /* added for sdcc pve */
#define _SIZE_T
typedef unsigned int size_t;
#endif

which also detects the sdcc definition of size_t (which is identical to this code, which is also important). It would be good if someone would verify that Keil doesn't get unhappy about this (it shouldn't, but you never know until someone tries).

Peter Van Epp

[buddy.smith]

As I said in the other thread, until SDCC can support overlays, it's going to be very memory inefficient, and it wants to put all parameters in IDATA, so space runs out fast!

SDCC only overlays functions which don't call any other functions. Keil actually checks which functions call each other, and overlays accordingly.

--buddy

[vanepp]

Thanks, I had missed your post about the overlays. Thats useful information (I'm more usually
a PIC person the 8051) as it may indicate that the PIC solution is the better one than Wiznet in my
case.

Peter Van Epp

[vanepp]

Success with the SDCC compiler. Most of the secret is that the isrs need to be defined in the
main() function or SDCC doesn't populate the interrupt vector(s). Since this cause a branch in to the initialization code (which promptly clears memory) the results are unfortunate. I ported Dave Tweed's startkit code from the Circuit Cellar article in to SDCC and have attached difs from his code (with a where to get both SDCC and his code) in the sdcc_startkit.tar.gz file attached to this post. I'll feed a copy of the W7100.h file back to the SDCC developer for inclusion in SDCC and point out a number
of errors in the W7100.h file to the Wiznet folks as well.

Peter Van Epp

[vanepp]

Arggg! Just after posting the tar file found a typo in the W7100.h file. Corrected tar file attached.
Discovered I can edit my mistakes and put the new file in both posts

Peter Van Epp

[vanepp]

Also spoke too soon . There is a problem in (at least) SDCC initial memory clearing. It is trying
to use the P2 and XPAGE sfrs neither of which the W7100 has. As a result intiialization and the code
doesn't always seem to work (at least for the lcd, the serial port and network have been working
all the times I've tried). I'll keep poking at it ...

Peter Van Epp

[vanepp]

I'm not sure that the problem isn't the W7100 debugger. It appears to be clearing P0 (which lights
all the LEDs) during SDCC startup when there are no port commands in the code. Without the debugger attached startkit.hex appears to operate correctly (and in fact right now it appears to be operating correctly even with the debugger on). I've opened a couple of cases on this issue with the
Wiznet tech support folks and we will see what happens.
Has any one else tried my code on SDCC yet and if so what were your results? The failure I was
seeing is the LCD displaying garbage rather than

iMCU7100EVB
192.168.1.20

but even then the serial port and network connection both seemed to work fine, just the LCD was affected (which could still be some bug of mine that just isn't showing up for me right now).

Peter Van Epp

[buddy.smith]

Has anyone succeeded in getting a project built using SDCC that works with the networking?

If so, I'd love to see it as a reference. I really wish it would support overlays!

[vanepp]

> Has anyone succeeded in getting a project built using SDCC that works with the networking?

> If so, I'd love to see it as a reference. I really wish it would support overlays!

Yes. The file startkit1.tar.gz attached a couple of posts back is difs (and a new w7100.h file) that compile and run Dave Tweed's startkit code both serial and networking on SDCC. It seems stable for me now that I have written off the debugger.

Peter Van Epp

[vanepp]

I just found a nasty bug in the serial code of the startkit port I posted here a few places back. I'm inputing gps data on the serial port, checking the crcs and outputing the data to a telnet connection.
Sometimes on a specific sentence ($GPLL) the G gets lost causing a crc error. I expected to find that interrupts are disabled for too long somewhere causing an over run and loss of the character. To that end I wrote a profiler program that can collect data either on a timed basis or by probes in the isrs (or both) and installed it. To by great suprise this isn't an interrupt problem at all. The value of the buffer pointer that the serial isr is using to place the character in the buffer is overwritten (by something currently unknown) at the time of the interrupt for the "G". Thus the G gets stored in the wrong place in the buffer (potentially corrupting something else if the buffer was full). By the next interrupt the value is correct again so the apparant result is just the loss of the G. I haven't yet figured out why the value changes (register bank switching is one possibility if the compiler is putting the value in a tegister) although I expect I will find out for future reference. The fix (or at least a fix) is to correct the definition of the variables. They are currently defined as:

#define INBUF_SIZE 256
#define OUTBUF_SIZE 256

/* actual I/O buffers declared here */
char xdata inbuf[INBUF_SIZE];
static uint8 inbuf_head;
static uint8 inbuf_tail;

char xdata outbuf[OUTBUF_SIZE];
static uint8 outbuf_head;
static uint8 outbuf_tail;

without the xdata qualifier (to put them in external memory). Changing that so they are all defined as xdata
appears to fix my problem:

/* actual I/O buffers declared here */
char xdata inbuf[INBUF_SIZE];
static uint8 xdata inbuf_head;
static uint8 xdata inbuf_tail;

char xdata outbuf[OUTBUF_SIZE];
static uint8 xdata outbuf_head;
static uint8 xdata outbuf_tail;

until I figure out why static uint8 inbuf_head; is wrong (which may be an SDCC bug or just that it is incorrect).

Peter Van Epp