Re: C Compiler for 8051 microcontroler

• Previous message: Tauno Voipio: "Re: Suggestions for audio noise mitigation?"
• In reply to: Dave Hansen: "Re: C Compiler for 8051 microcontroler"
• Next in thread: Robert Gush: "Re: C Compiler for 8051 microcontroler"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Thu, 15 Jan 2004 16:13:22 +0800

"Dave Hansen" <iddw@hotmail.com> wrote in message
news:40055603.159257904@News.CIS.DFN.DE...
> I've never tried SDCC, I don't know its ins and outs, but as far as
> Keil is concerned...
>
> >
> >unsigned char xmodem_tx(unsigned char (*buffer_loader)(unsigned char *))
> >{
> > unsigned char no_more = FALSE;
> > xdata unsigned char packet_data_buffer[PACKET_DATA_BUFFER_LENGTH];
> >
> > do
> > {
> > no_more = (*buffer_loader)(packet_data_buffer);
> >
>
> It is a strange piece of code...

Yes it is. Perhaps I should place it in a wider context. I wanted a module
that would xmodem transfer a file through the serial port, and which was
sufficiently modular to be readily incorporated into any application,
whether it be the current project or some later development. The only
external requirement for this module was to be an application specific
function that would refill a data buffer until all data had been
sent. I pass the address of this external function into the finished and
tested xmodem module when I want to send the file, so that I don't have to
screw about with the xmodem library module each time I use it. Nothing
ground-breaking, just trying to think about code management.

> You are requesting a local auto variable be located in xdata. I
> wasn't aware Keil would accept that silently. From the limited
> context you've provided, I can't tell for sure, , but I would expect
> you meant "static xdata unsigned char..." Perhaps thats what Keil
> actually does.

Hmm. Keil seems to compile it like this without any fuss. If it stayed as an
auto I couldn't see a problem accessing the buffer from within the called
loader routine. Keil is quite probably doing something with it that I don't
understand just yet. Maybe the manual will shed some more light. There's
really no way for me to tell what Zelda does in this situation.

> Note that (in Keil) "unsigned char *" is a three-byte type, but "xdata
> unsigned char *" is only a two-byte type. Presumably Keil isn't
> complaining because it coerces the type conversion. Make sure that
> any function you pass to xmodem_tx expects an "unsigned char *" and
> not "xdata unsigned char *".

Yes your quite right about the "unsigned char *" being a 3 byte, generic
pointer in Keil. I believe that such a pointer can be used to point to
variables in any data space, including xdata. At run time, when you pass it
a memory location, the type of memory space is recorded in the third byte.
It's apparently a slower method than Keil's 2 byte pointer access, but has
the advantage that my external buffer filling function need not be modified
if I subsequently choose to store the packet data buffer elsewhere in
memory. The same code will just as easily work with a buffer located in the
data memory space as in the xdata space. As you have suggested, I will be
careful to only pass a function that expects an "unsigned char *" to the
xmodem_tx function as above.

Gee, a good compiler manual makes you sound like a real expert. Well, at
least it doesn't leave you looking such a prawn.

The discrepancy between an "xdata unsigned char" address being passed as an
actual parameter to the *buffer_loader function (which expects the address
of an "unsigned char") looks more and more like a stuff-up when viewed as
SDCC code. I remember being quite certain at the time of submitting it to
the SDCC mailing list, that this was how I had to address the situation with
Zelda, given my experience at that time. It looked odd when I re-posted it
here, but I left it that way. I really don't know now. To tell you the
truth, I don't think Zelda minds too much what a pointer references. The
snipet crashes the compiler no matter how you address the matter, so I guess
it's of no consequence.

Thanks for that one Dave.

Regards,
Murray.
_____________________________________
Murray R.Van Luyn
Revolutionary Urban Guerilla.
Ph: +618 9354 1375
E-mail: vanluynm@iinet.net.au
           vanluynm@cs.curtin.edu.au

• Previous message: Tauno Voipio: "Re: Suggestions for audio noise mitigation?"
• In reply to: Dave Hansen: "Re: C Compiler for 8051 microcontroler"
• Next in thread: Robert Gush: "Re: C Compiler for 8051 microcontroler"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]