Using C to program the 8051 family

Hi Klaus. My name is Ian. I still write complete applications in assembler and not just ones with very time critical interrupt routines.

C is platform dependant too when it comes to samll 8 bit micros.

Ian

assembler

to

headers

Well, I use Keil and that one is ANSI C compliant. And if you need to switch then choose a compiler that too is ANSI C compliant or close to that effect

Cheers

Klaus

"Klaus Vestergaard Kragelund" wrote in news:3ffaaf20$0$9719$ snipped-for-privacy@dread14.news.tele.dk:

Keil C51 has a number of 8051 specific extensions, which will require rework when migrating to a different processor.

Graeme Faelban wrote in news:Xns9468499754391richardrapiernetscap@130.133.1.4:

Bah, forgot to change that sig for my rare appearance here.

I'm aware of that, but isn't it still better than rewriting all the ASM code? If you write your C code in a strutual manor, you need to change very little...

Cheers

Klaus

How amusing. C, like any other development tool, is just that - a tool. Choosing the right tool for the job is obviously key, and obviously somewhat subjective.

Re optimiser: yeah, yeah (yawn). That's part of the process of choosing the right tool for the job. I routinely read the assembler generated by any compiler. I've frequently made changes to optimisation as a consequence. However, with say the H8 family (less so the 8051) I find that the available compilers do a pretty damn fine job.

As to "larger platforms" - huh? That's just silly. Tell that to the guys I know who use C on the PIC family ;).

Various answers: - Using third-party *anything* leaves you open to dangers. I've had some nasty experiences with 3rd-party libraries. I've occasionally had to work around toolchain misfeatures. But I basically don't proceed until I do trust the tools. - Haven't used a disassembler in >20 years. Most compilers will compile to assembler. You're clearly not so familiar with such tools. - Haven't used an ICE in >15 years. I write defensively and validate rather than debug. I don't "do" bugs.

Your mileage may, and obviously does, vary. If the interpreted approach works for you, lovely. But don't diss the rest of us - I typically work on mission-critical high-reliability high-volume embedded apps, and after

Steve

Which would be what, about 0.1% of the code? As opposed to 100% of an assembler program.

Bob

Dittos.

Bob

I'm not the one you asked, but I didn't see where anyone really answered this question...

C is totally, completely, and utterly usuited for the 8051. Or any other 8-bit micro. And vice-versa. (Well, the AVR isn't too bad, but that's a special case: it was developed with the help of a compiler vendor specifically to work nicely with C.)

This is off the top of my head. I'm sure there are others.

The 8051 seems to have been fiendishly designed to make programming in C difficult, inefficient or just impossible. Some of the worst problems are the lack of stack space, access of xdata through dptr only, and of course, the Harvard architecture. The only chip that seems to be worse (disregarding 4-bitters) is the 12- and 14-bit PIC cores (I haven't looked closely at the 16-bit PIC core or the dsPIC yet).

OTOH, Keil (and some of the other vendors and perhaps SDCC as well) has generally done an excellent job with its NQC (Not Quite C) development systems. They're very effective and easy to use, and make efficient use of the 8051 resources.

Just don't go confusing them with C.

Regards,

-=Dave

You're missing an important point, there. Just because Keil *has* those extensions doesn't mean you have to use them all over the place, thus making the code unportable. There'll obviously be some parts of a project where that will be unavoidable, but those would be the ones that 100% platform-specific by definition, regardless of how you do them.

And even where you do use those extensions, you can still hide them nicely behind some macros, so all it takes to render the code entirely portable is to change the definition of those.

Quite so Dave but your comments will fall on deaf ears here.

Thanks for adding some more recent experience, Dave, mine is woefully out of date and I'd forgotten a few of those glitches. C was written for Unix, not for 8-bit micros. Although time has extended C to other venues and added new features it remains unsuited for the 8051.

One point, I know you were joking but the 8051 was first designed about

-- Regards, Albert

---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts

----------------------------------------------------------------------

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 doma>

C99 brought forward size specific declarations. The As-If implementation rules allow very efficient expression implementations (including 8 bit) on small embedded system processors

These are translation limits for the compiler. There is no place in the standards that I know of that defines hardware limits.

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.

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

In article , Klaus Vestergaard Kragelund writes

There are many extension in Keil C51 which are not the same in other

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

Due to the 51 memory map much of it will use the extensions. However it is not that difficult to change them when porting.

I have found that portability comes a LONG way behind reliability, efficiently and compactness.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

In 1975 nearly all embedded programming was being done in assembly language, with FORTRAN and PL/M to follow. There were some fairly compact BASIC interpreters; but their performance was generally 'poor' to 'intolerable' for time-critical applications.

I used C on (first) I8080 and (later) Z80 CPUs and had no serious problems - though I was constrained to integer math. Even the primitive 8080 could be programmed to produce 32-bit (or larger) results when needed.

I've never needed to produce code for an 8051 (nearly all of my more recent work has been on 16- and 32-bit SOCs) but I'm amazed to hear that the 8051 has less capability that Intel's old I8080 or Zilog's Z80!

Why? The 8051 (and it's predecessor the 8048) was aimed at much smaller, simpler applications than the 8080/Z80 family.

IIRC, the 8048/8051 were built for Ford. They were intended for very small, simple automotive control applications with a few KB of code and maybe 50-100 bytes of RAM. The 8080/Z80 was a much more "powerful" general-pupose CPU with a stack pointer,

The archtypical application for an 8048 in those days was a keyboard controller. I believe the original IBM PC keyboard used one.

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