On 4 Jul 2003 22:36:08 -0700,
bi*****@aol.com (Bill Hanna) wrote in
comp.lang.c:
C is inadequate for embedded systems for the following reasons:
That's funny, I've been using C for embedded systems for more than 20
years, and I find it highly adequate.
Besides which, who ever said that C was supposed to be adequate for
embedded systems?
Finally, what's better?
1) Direct addressing of memory mapped I/O is not supported simply
and easily. You have to find work-arounds that are compiler dependent.
You have to create macros , use casting and use indirect addressing
(pointers) to read or write to memory mapped I/O.
What's wrong with any of the above? If your compiler does not provide
a format for macros that it recognizes and optimizes away the
pointers, take it up with the compiler vendor or buy a better
compiler. The syntax works quite directly.
And what about things stranger than memory-mapped I/O, such as special
registers, the separate I/O space of some Intel (and some other)
architectures, memory-mapped registers, and quite a few other things?
So what?
2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent.
The interrupt vectoring is hardware dependent, depending on the
processor and quite a few other things.
3) C does not provide the full result of a fixed point 32X32
multiply. It only provides the LH result. The UH result is needed for
digital filter applications.
C does not support fixed point data at all. It supports integer and
floating point types natively. Fixed point is supported by vendor
supplied libraries.
4) C does not provide overflow detection or carry out detection.
Right, and that's deliberate. One of the fundamental design goals of
C is that you don't pay for what you don't need. In the cases where
you need these features, add them. Don't try to burden every program
by everyone else with them when they are not needed.
The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer.
Comments are solicted.
Thanks,
Bill Hanna
C is adequate for embedded systems because customers demand it. And
also because of the huge number of robust embedded systems that have
been built with it over more than a quarter of a century.
While all of this is off-topic, I do have two additional comments:
1. Stop whining. If the requirement of your customers is to use C,
either do it without complaint or perhaps look for another line of
work.
2. Most of your complaints are not about the language proper. C
doesn't support any hardware at all, not keyboards, video displays,
disk drives, serial terminals, not anything. Nor does it support
interrupts at all. So the fact that it doesn't support ADCs or PWMs
or DACs is irrelevant. Lack of support for the first list of hardware
I mentioned hasn't stopped C from being used for almost every major
operating system. Lack of standardized support for interrupts (and
what a nightmare that would be) has not prevented interrupt routines
from being written in (non-standard, extended) C in operating systems
and applications for desk tops.
Your problems appear to be not so much with the language, but with
your compiler vendor. Apparently they are not doing such a good job
providing usable extensions for your particular platform.
--
Jack Klein
Home:
http://JK-Technology.Com
FAQs for
comp.lang.c
http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++
http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
ftp://snurse-l.org/pub/acllc-c++/faq 
