Re: [sdcc-devel]Serial line support in 8051

[Dr R. W. <R.W...@18...>]

Johan, (also Sandeep,)

> I always wondered how the non-ds390 users could survive without standard
io
> support, they probably haven't connected a terminal to their microwave :).
> When I started using sdcc for the ds390, I noted the total lack of
> consistancy of it. For the ds390 I did it by introducing a new library
> (libds390.lib) that contains all DS80C390 related (in this cases partly
TINI
> related :) (std)io, like serial ports, timers, i2c, lcd, rtc etc, that
> supersedes whatever is in libsdcc.lib.

Ah.  Sounds like I hadn't missed anything obvious.  From just a very brief
look, it seems that the ds390 stuff could act as a paradigm of something
more general.

I hope this is not too presumptious of me but it seems to me that the
library could do with a refactoring.  The original SDCC was 8051 specific
and so having 8051 specific header files and library was fine.  In order to
deal with the ability to be retargetable, the include files and library need
an architecture that supports general and architecture specific in an
integral way.  I cannot speak about the ds390 stuff in detail as I haven't
used it but it is clear that the z80 port does not fit neatly as yet.

> Something like that could be done too for the core mcs51 and other ports
as
> well. All the derivates have at least a serial port and a timer 0 and 1
that
> are compatible.

Certainly this is true for all 8051 family but may not be true always more
generally.  This means a three level architecture:  general, processor
family, individual processor.  As long as there were two levels of
pre-processor macros a combination of central header files and
subdirectories would work fine.

> There just has to be some one who needs it, does it and shares it.

We have a need for a working i8051 and z80 compiler.  Although we have used
Keil for the i8051 in the past, we would prefer to use something Linux
based, hence the interest in SDCC.  We are not anxious to spend more money
on tools such as Keil since they are processor specific rather than being
general with plug-ins and so want to use SDCC for the z80 rather than spend
on the IAR product.  We are happy to spend money on products but only if
they are the products we really want!

If the person who started the z80 port is willing to hand over
responsibility we can take this on board, i.e. spend our resource creating
the compiler rather than spending on someone else's product.  The result
will of course be added to the SDCC pool.

So the issues for us before wading in are:

1.  We can get simple C programs working on s51 but the main software fails
to run on s51 even though it compiles fine with SDCC.  The same source
compiled and run with Keil works fine.  We are not certain whether this is
an SDCC problem or an s51 problem and are not sure how to sort this out
since we haven't yet been able to run SDCC code on the Keil simulator.

2.  The SDCC system needs to be evolved to be more general than just 8051
family -- affects the header files and library structure only as far as we
can tell.

3.  Being granted the authority to proceed.

> > Also I note that _ser and ser_ir define the same procedure names, how
> > does the linker select the correct ones from the library.  I can't see
> > anything in the header files that disambiguates in any way.
>
> The compiler uses whatever it sees first, in that order. But since ser_ir
> isn't in libsdcc.lib it will never be used.

OK so as I understand it whatever *.asm files are in the library directories
the *.lib files are the indexes used by the linker.  This impies there are
files in the library that can never be used implicitly.  This implies that
ser_ir is in some sense redundant and the fact that #include <ser_ir.h> will
work just as well as #include <ser.h> it will always be the _ser.asm
procedures that will be used.

What would be the best way of progressing a refactoring?

There could either be a general discussion iterating to something that
someone could then take on board to implement or someone could make
something to put up as a proposal to be iterated.  The former could just
happens sparked by this email.
For the latter, we could create a CVS fork of the header files and library
code and work on it creating a new architecture and put it up as a proposal
for consideration.

As far as the z80 port is concerned, we could fork that or work with the
current system -- assuming the person who was working on the z80 port is not
able to continue the work.

Russel.
====================================================================
Dr Russel Winder                Chief Technology Officer
OneEighty Software Ltd          Tel: +44 20 8263 2329
The Lansdowne Building          Fax: +44 20 8263 6314
2 Lansdowne Road                R.W...@18...
Croydon, Surrey CR9 2ER, UK     http://www.180sw.com
====================================================================
Under the Regulation of Investigatory Powers (RIP) Act 2000 together
with any and all Regulations in force pursuant to the Act One Eighty
Software Ltd reserves the right to monitor any or all incoming or
outgoing communications as provided for under the Act