Using C to program the 8051 family - Page 5

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Using C to program the 8051 family
On Tue, 06 Jan 2004 22:06:54 +0000, the renowned Ian Bell

Quoted text here. Click to load it

I'm sure what remains sits in some dusty corner of an ASIC. That's the
"keyboard controller"  (on the motherboard). The keyboard itself
(which, on more careful reading seems to be what you were talking
about) uses another stand-alone micro, not sure what kind it is, but
I'd guess a descendant of the 80C51. They are pretty much all COB
construction these days (epoxy blob).  

Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Using C to program the 8051 family

Quoted text here. Click to load it

Sorry I was meaning the one in the keyboard itself.

Ian


Re: Using C to program the 8051 family

Quoted text here. Click to load it

Thanks. I'd never really thought of the 8080 or Z80 as being
"powerful" engines - and I can't help but grin at your "and
everything" comment.

I like C (and consider it to be one of the most powerful
development tools ever) but have to admit that for control
applications maxing out at few KB of code and 100 bytes of RAM, I
probably wouldn't consider anything other than Verilog or
assembly language solutions.
  --
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.


Re: Using C to program the 8051 family

Quoted text here. Click to load it

Back then (1982 or so) Verilog wasn't an option, and we did do
most of our 1K ROM 60 bytes of RAM apps in assembly.

However, the 8051 family has grown up (somewhat painfully) over
the past 20 years and now has varieties with 128+ KB of ROM and
8+ KB of RAM.  When you get to apps of that size, writing the
whole thing in assembly is pretty painful.

--
Grant Edwards                   grante             Yow!  Do I hear th'
                                  at               SPINNING of various
We've slightly trimmed the long signature. Click to see the full one.
Re: Using C to program the 8051 family

Quoted text here. Click to load it

Hey, I cut my programming teeth on a desktop computer with a Z80
processor in. It had word processors, development tools, an OS, games,
and everything :-)

I even had a mouse for it, and a light pen...

ABS


Re: Using C to program the 8051 family
Quoted text here. Click to load it

The 8048 was released first, and is a simpler (subset) uC than the 8051
which followed as process improved.
The 8051 was well optimised for embedded control, and added BOOLEAN
processor opcodes, and interrupt priority, as well as more register
banks, and efficent direct memory opcodes.
Those fundamentals have not changed

The Z80 was a microprocessor (No RAM/ROM), and was targeting external
memory apps. First systems needed MANY chips to function
IIRC Hitachi were the first to do a microcontroller version of the Z80,
and Zilog has very recently (in time line terms) released the FLASH
eZ80

-jg


Re: Using C to program the 8051 family
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

The 8080 was no more primitive than the Z80, and I found I could
do everything (in assembly) in very little more running time than
in the Z80 code set.  What Z80 opcodes did was primarily to allow
smaller object code.

At any rate, by about 1978 I had moved most of my embedded
machinery to Pascal, using my own compiler, validated against the
test suite for the ISO/ANSI standards.

One notable thing about Pascal is that one can provide many
extensions, in the form of standard procedures, without violating
the standard.  This is because such extensions exist in the
conceptual outer outer block, and therefore never create name
clashes.  Thus there is no need for the C style reserved names, or
C++ namespaces.  In addition I have yet to find an i/o or
communication device that I could not map into Pascal files.

I used such extensions to provide such features as C's unsigned
ints (no overflows), or to allow splitting ints into bytes (or the
reverse) without worrying about endianess, etc.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Using C to program the 8051 family

Quoted text here. Click to load it

I'd have to disagree.  Geeze, the 8080 required _three_ supply
voltages (+5, -5, and +12 IIRC).  The Z80 only required a
single 5V supply.  That was a huge advance.  The clock
circuitry on the Z80 was also much better and didn't require a
high-voltage dual-phase clock generator chip.  All you needed
was a single phase 5V TTL clock signal.

The Z80 interrupt model was far, far superior to Intel's crappy
hack which required an external interrupt controller in the
form of an 8059 (a horrible mistake which we're unfortunately
still stuck with).  

The Z80's dual register banks also made interrupt handling or
coroutines on the Z80 much easier than on the 8080.

The Z80 had built-in refresh circuitry for dynamic RAM.  With
the 8080, you had to add a dynamic RAM controller chipset.

All told, the Z80 eliminated the need for two power supplies
and about a half-dozen not-very-cheap support chips.

The addition of two 16-bit index registers also made for far
superior code generation for high-level languages.  There were
80 new opcode that included block move and block I/O
instructions.

And it just plain ran a hell of a lot faster.

IOW, the Z80 completly kicked the 8080's arse.  Once the Z80
came out the 8080 completely vanished from new designs.  The
8085 was a very lame, late, and failed attempt at meeting the
challenge of the Z80.

--
Grant Edwards                   grante             Yow!  I'm RELIGIOUS!! I
                                  at               love a man with a
We've slightly trimmed the long signature. Click to see the full one.
Re: Using C to program the 8051 family. C for small processors
Dave,

Modern compiler technology overcomes the majority of the objections to C running
on 8 Bit micro's and other small processors or processors with unusual
architectures.

It is unfortunate that many of the C compilers that are currently offered for
embedded systems were re-targeted from public domain C compilers originally
implementations for much larger hosted processors. Very good conforming C
compilers have be written
for many of small processors including processors like the 8051's and Microchip
PIC's by designing the compiler for the intended target and utilizing current
compiler technology on powerful personal computers.

Dave Hansen wrote:
Quoted text here. Click to load it

C99 brought forward size specific declarations. The As-If implementation rules
allow very efficient expression implementations (including 8 bit) on small
embedded system processors
Quoted text here. Click to load it
 
These are translation limits for the compiler. There is no place in the
standards that I know of that defines hardware limits.

Quoted text here. Click to load it

There is nothing in embedded micro's that prevents recursive calls. Probably
what is more important is there is nothing in the standard that prevents
compilers from optimizing out recursive calls if they are not needed. In the
same way there is no reason
that every function be called in the same way.
Quoted text here. Click to load it

ISO since the release of C99 focussed on C standards for embedded systems to
address the specific issues of using C to program embedded systems. It defines
support for multiple address spaces, register access, fixed point data types,
asymmetrical I/O
devices. The result of this work is a Technical Report (ISO/IEC WDTR 18037
Programming languages, their environments and system software interfaces
Extensions for the programming language C to support embedded processors) that
is expected to become part
of the language in future language standard releases.

Walter Banks

Re: Using C to program the 8051 family. C for small processors


Quoted text here. Click to load it
running on 8 Bit micro's and other small processors or processors with unusual
architectures.
Quoted text here. Click to load it
embedded systems were re-targeted from public domain C compilers originally
implementations for much larger hosted processors. Very good conforming C
compilers have be written
Quoted text here. Click to load it
Microchip PIC's by designing the compiler for the intended target and utilizing
current compiler technology on powerful personal computers.
Quoted text here. Click to load it

I'm unaware of any public domain C compilers. Do you have an example?

[...]


Re: Using C to program the 8051 family. C for small processors
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Small C.  To all practical purposes gcc and lcc also, since you
can do what you like with them, apart from seize them for your
exclusive use.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Using C to program the 8051 family. C for small processors


Quoted text here. Click to load it

Psst! I have a secret. That's the idea.


Re: Using C to program the 8051 family. C for small processors
I think you need to look at your posting line length options...

On Tue, 06 Jan 2004 13:32:06 -0500, Walter Banks

Quoted text here. Click to load it
running on 8 Bit micro's and other small processors or processors with unusual
architectures.
Quoted text here. Click to load it
embedded systems were re-targeted from public domain C compilers originally
implementations for much larger hosted processors. Very good conforming C
compilers have be written
Quoted text here. Click to load it
PIC's by designing the compiler for the intended target and utilizing current
compiler technology on powerful personal computers.

I've used NQC compilers for several micros, including Keil's excellent
C51 and CCS's adequate PIC C.  I prefer either to programming in
assembly.

I'm not sure what you mean by "public domain C compilers."  Perhaps
avr-gcc (which isn't really public domain, but let's skip that
discussion for now)?  That actually works quite well.  Certainly much
closer to real C than (e.g.) Keil C51 (though it still struggles with
the Harvard architecture).  SDCC?  I haven't tried that yet, so I
can't really comment.

Quoted text here. Click to load it
allow very efficient expression implementations (including 8 bit) on small
embedded system processors

True.  Given

   unsigned char x, y, z;

   x = y+z;

the compiler _should_ be able to avoid generating a 16-bit add
operation.  I don't recall any that do so, however.  Except for a NQC
compiler for AVR.  However, that compiler that has other bugs.  Such
as, when given

   unsigned int n;
   unsigned char s = 12;

   n = 1 << s;

it will write a zero to n.  

Quoted text here. Click to load it
standards that I know of that defines hardware limits.

Section 5.2.4.1 says an implementation must be able to translate _and_
_execute_ a program containing at least one instance of each limit.
Hard to execute programs when the resources aren't there.

Quoted text here. Click to load it
what is more important is there is nothing in the standard that prevents
compilers from optimizing out recursive calls if they are not needed. In the
same way there is no reason
Quoted text here. Click to load it

True to a point.  I guess my particular complaint is that, unless
special extended keywords are used, Keil C51 will generate
non-reentrant functions which cannot be called recursively.  There are
good reasons for this.  And the reasons have to do with the
architecture of the 8051 and its memory hierarchy.  But it's not C.

Quoted text here. Click to load it
address the specific issues of using C to program embedded systems. It defines
support for multiple address spaces, register access, fixed point data types,
asymmetrical I/O
Quoted text here. Click to load it
Programming languages, their environments and system software interfaces
Extensions for the programming language C to support embedded processors) that
is expected to become part
Quoted text here. Click to load it

I'd heard of this, and am interested in seeing the results.
Obviously, though, it's not C yet, and certainly no compiler (free or
expensive) implements those today.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: Using C to program the 8051 family. C for small processors


Quoted text here. Click to load it

Public domain in the sense that they are widely available (some
times with usage restrictions) to port C to new target platforms.
Some examples are the portable C compiler and GCC which have
been used for this. All of the compilers of this type that I
am familiar with were not originally intended for non hosted
or limited resource targets.

Quoted text here. Click to load it

This could trigger a huge thread by itself. In general if the
intention is to validate the compiler limits then selective
family members, simulation or external user defined memory
space (ISO/IEC WDTR 18037) can be used to achieve the test.
Quoted text here. Click to load it

ISO's mandate is to create standards that reflects current
practice. The ISO/IEC WDTR 18037 technical report examined
in detail Byte Craft, ACE, Keil, Cosmic, HiWare and a bunch
of others. There is a lot of collective compiler experience
in all of the topics in the report.

You are correct it is not C yet. It is a Technical Report
that describes changes to the language in the future, a
kind of language Beta test.

Walter Banks
http://www.bytecraft.com

Re: Using C to program the 8051 family. C for small processors


Quoted text here. Click to load it
[...]

I've never heard of the portable C compiler, but GCC is definitely
not PD. SDCC, which is intended for micros, is perhaps not ready
for prime time, but is definitely not PD.

I'm aware of nothing in the computer realm worth 2 bits that is
PD. Never confuse a free license with PD.


Re: Using C to program the 8051 family. C for small processors

Quoted text here. Click to load it

Wasn't much of the old unix base declared to be effectively public domain in
the BSD-SCO case many years ago?

But you are right about gcc - there is a large difference between public
domain code (where the author / copyright owner gives everyone free use to
do what they want with the code, apply any licence they want, and make any
copyright notice changes they want) and open source code, where the
copyright is very carefully maintained and specific licences are applied for
specific purposes.  The uncaring end-user might not notice the difference
(after all, in both cases the program is probably free in monetary terms),
but it makes a huge difference to developers and distributers, and thereby
indirectly to all users.




Public Domain and Open-Source (was: Using C to program the 8051 family. C for small processors)
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

I am assuming GNU GPL here, but there are other licenses.

It makes no difference to distributors, because in general the
licenses allow charges for services.  The only thing it prevents
is third parties seizing the code and applying their own
copyrights.

As an example, I could create a new machine, either in hardware or
as a simulator, copyright/patent/whatever that, and adapt gcc to
generate code for it.  I get the useful software to promulgate my
ideas for essentially nothing, or at least a minimum of my
effort.  I retain complete ownership of the machine, the right to
charge whatever I wish for it, but NOT the right to hide or
restrict use of my gcc mods.

Of course, should you wish, you are welcome to create a compiler
for your new machine from scratch, and then charge what you wish,
and hide all the details.  I suspect it will be a few years before
it is as accurate or flexible as gcc.  Meanwhile you will have to
keep your whiz-bang off the market, and the business may well go
elsewhere.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Public Domain and Open-Source (was: Using C to program the 8051 family. C for small processors)

Quoted text here. Click to load it

GPL also restricts use in commercial products. That's not usually an
issue with gcc, since the libraries are LGPL, with fewer restrictions.

--
Al Balmer
Balmer Consulting
We've slightly trimmed the long signature. Click to see the full one.
Re: Public Domain and Open-Source (was: Using C to program the 8051 family. C for small processors)

Quoted text here. Click to load it

What?  IANAL, but I have read the GPL.  I don't remember any
restriction on use in commercial poducts.  Got a cite?

Quoted text here. Click to load it

--
Grant Edwards                   grante             Yow!  Will the third world
                                  at               war keep "Bosom Buddies"
We've slightly trimmed the long signature. Click to see the full one.
Re: Public Domain and Open-Source (was: Using C to program the 8051 family. C for small processors)

Quoted text here. Click to load it

Read the GPL again, the part where it talks about distribution of unmodified and
modified versions.

If you modify a GPL'ed work, and distribute the binary, under ANY TERMS
WHATSOEVER, you are required to grant the people who receive your binary
permission to redistribute it *AND* you must provide your source code to them
for not more than a nominal copying and media charge AND you must grant
permission to redistribute your source code as well.

LGPL carries less "onerous" terms.

The fundamental idea is that software released under the General Public License
is freely redistributable, freely modifiable, and comes with SOURCE CODE that is
freely redistributable and modifiable, and it is damned well going to STAY that
way.



Site Timeline