Using C to program the 8051 family

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
                               visi.com            WHIRRING, ROUND, and WARM
                                                   WHIRLOMATICS?!

snip

Unfortunately Ansi C compliance does not help when switching micro platform as all the important stuff like interrupts, timers, peripherals etc are all different.

Ian

running on 8 Bit micro's and other small processors or processors with unusual architectures.

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

Microchip PIC's by designing the compiler for the intended target and utilizing current compiler technology on powerful personal computers.

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

[...]

Was? What do they use now?

Ian

running on 8 Bit micro's and other small processors or processors with unusual architectures.

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

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.

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 >

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.

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

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.

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

Programming languages, their environments and system software interfaces ? Extensions for the programming language C to support embedded processors) that is expected to become part

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.

The *was* refers to the *archtypical application* and was not meant to infer that it is no longer used in IBM PC keyboards.

It's been a few years since I've disassembled an IBM keyboard and I don't rightly know what kind of controller it uses.

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.

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.

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

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"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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

[...]

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.

I guess I've been dreaming for the last 10 years then. Shipped at least fifteen products and never used an ICE.

Casey

Almost likewise.

Mike Harding

... snip ...

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

... snip ...

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

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

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.

I can push that time span to 30+ years. I will concede that once or twice I have wished for one.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

As will any C compiler or any other programming language (including assembler). I recently migrated a (reasonably substantial) project from

8051 to MSP430. It took me less than a day. That included converting all header references (they are seldom the same), thinking out and redefining the IO allocations, removing references to smart pointers, etc, etc. that were no longer required due to the different architecture, and running and testing the result on the target. I dare say it would have taken rather longer in assembler.

Paul Burke

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