473,837 Members | 1,534 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

An improved version of C is needed for embedded systems.

C is inadequate for embedded systems for the following reasons:

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.

2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent.

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.

4) C does not provide overflow detection or carry out detection.

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
Nov 13 '05 #1
12 2989

Bill Hanna <bi*****@aol.co m> wrote in message
news:97******** *************** ***@posting.goo gle.com...
C is inadequate for embedded systems for the following reasons:

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.

2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent.

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.

4) C does not provide overflow detection or carry out detection.

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.


My comment:

You seem to feel that C is insufficient to your needs.
So use (or create) something that is sufficient.

Here, we discuss C as it is.

-Mike

Nov 13 '05 #2
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.l earn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Nov 13 '05 #3
# Comments are solicted.

The usual technique is to find a base language that you like, perhaps C
or Bliss or Ada or PL/I or Algol or Fortran, then adapt it to your specific
needs. Some of things you want simply do not exist on this or that cpu
I've worked on over the years. Demanding all of them to be standardised
into something like C would create a language that would be unusable for
some systems.

If customers demand things be done in a language that can't possibly
support it, you should've negotiated those issues before accepting them
as customers.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
What kind of convenience store do you run here?
Nov 13 '05 #4
Bill Hanna wrote:
C is inadequate for embedded systems for the following reasons:

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.
Direct addressing of memory mapped I/O /is/ supported simply and
easily.

Work-arounds for what?

What's your problem with macros? They're a language feature used
in C programs of all types.

Casts are seldom needed by programmers who've learned to work
/with/ the compiler instead of trying to force their incomplete
understanding of the language on it.

Pointers are a language feature that can provide flexibility and
efficiency, whether used to access memory or I/O space.
2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent.
Sorry. I (and /many/ others) have used C to service real time
interrupts. Some implementations even provide extensions to the
language to facilitate this activity. Please take notice of the
fact that such extensions may or not even be useful depending on
the hardware architecture.

Sorry again. Interrupt vectoring (when there are interrupts; and
when they are vectored) is dependent on the particular /hardware/
involved.
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.
Eh? In a wild and crazy moment, I wrote functions in C to perform
2048 x 2048 multiplication (also addition, subtraction, division,
and take square roots). The operations will work on even wider
operands if I change the 2048 to a larger number in a #define
statement in a header file.

Perhaps you meant to say that your processor doesn't provide
64-bit products? If so, this is hardly a C issue - just write the
code to do what you want...
4) C does not provide overflow detection or carry out detection.
Urk? WTFAYTA? It provides you with the ability to write code to
determine /before/ the fact that o'flo / carry will occur. The C
standard is unconcerned with particular ALU architectures. I've
seen hardware that not only didn't generate these status
conditions; but couldn't add (didn't even try).

For hardware specific code you'll need to take the time and
trouble to [1] learn the hardware; and [2] learn to program. I
don't think there's any compiler for any language that can do
either of these things for you.
The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer.
Obvious only to someone who knows assembler (and not C). I'm not
a C++ guru, so you'll have to ask about that language in the
news:comp.lang. c++ forum.
Comments are solicted.


C is a powerful tool for embedded systems development if you know
how to use it. If you don't, then you can either learn to use it
or choose another tool that works better for you.

If a prospect is determined to have C; and if you want that
prospect to become /your/ customer, then I'd suggest learning how
to deliver C - or find a prospect who wants something you /can/
deliver [hardly reocket science, is it?]
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c

Nov 13 '05 #5
1) and 3) are answered more adeptly than I can ever dream. However,
let me add my two cents worth for 2) and 4) . I will shuffle those
parts of original message :
The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer.
The following requirements *are* hardware dependent. As these
solutions are not provided within standard C, you need to have glue
assembly code (or have to depend on non-portable libraries - where
your library provider is using assembly instead of you using it). If
your customer demands these things in absolute C/C++, your customer
really needs education.
4) C does not provide overflow detection or carry out detection.
However, it depends what you mean by "support" in 2)
2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent.


Vectoring is actually machine dependent

So far as you are protecting your resources, you can safely use C in
ISRs. Linking and loading may be trickier - but are out of C's context

And you can *send and receive* signals (software interrupts) through C
- if your OS provides that facility. Signals are real time interrupts
too. And there is a world of RTOS doing various fantastic things with
signalling among tasks in C.

-Bhushit
Nov 13 '05 #6
Bill Hanna wrote:
C is inadequate for embedded systems for the following reasons:

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. =-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Direct addressing of memory mapped I/O is supported very simply:
volatile unsigned char * UART_RX = (unsigned char *) 0x40030;
/* .. */
unsigned char byte_read = *UART_RX;
Are you looking for something simpler?
I didn't use any macros above.
I haven't used any macros for reading from hardware devices for
the last 10 years in my embedded systems programming experience.

Usually, we also add a higher layer to to this:
unsigned char Read_Uart_By_Po lling(void)
{
/* ... */
return byte_read;
}
=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=


2) C does not support real time interrupts. The interrupt
vectoring is compiler dependent. =-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Some compilers add support that allow C functions to be designated
as ISRs. In the embedded system I am working on, the interrupt
vector points to an ASM routine which calls a C routine.

The reason interrupt vectoring is compiler dependent is that each
platform handles it differently. Some OSes don't allow a program
to alter the any ISR.
=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=


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. =-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Do you mean integral multiplication?
I am not familiar with DFAs, but my embedded C compiler has no
problems using 32 bits for an integral multiply.

I am in the process of writing C code for 1024-bit integer
multiplication. I'm not complaining that C doesn't support 1024-bit
integers; I'm adding additional support.
=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
4) C does not provide overflow detection or carry out detection. =-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Yes, you are correct. For the majority of applications, this is
not required. However, the C language does allow you to use inline
assembly. If your processor's instructions allow detection of
carry and overflow, you could insert some inline assembly. OTOH,
you could just write the whole routine in assembly and link it in.
=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer. =-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Wrong. I've never programmed an entire embedded system in pure
C; it has always been a mix of C and assembly language. Sometimes
the contents of the function was replaced by assembly language (so
the function calling I/F would not be changed). One company I worked
for had a rule: C functions could be replaced by assembly as long
as the assembly function worked the same or better than the C version.

Most companies restrict the use of assembly language. The primary
reason is productivity. I've found that time just comes to a halt
when I write functions in assembly language. I can code more
functionality in C than in assembly. I use assembly language routines
to take advantage of processor specific features (and maybe other
h/w devices).

If you can't program purely in C, try a hybrid. Some companies now
use more than just C. They might code something up in Perl and
link it to a C function or vice-versa. The situation all depends
on what can be done to get the product to market faster with
higher quality.
=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=
Comments are solicted.
Thanks,
Bill Hanna


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.l earn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

Nov 13 '05 #7

"Thomas Matthews" <to********@sbc global.net> wrote in message
The obvious rebuttal to this complaint is to program only in
assembler language, however use of C/C++ is usually demanded by the
customer.

=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-= Wrong. I've never programmed an entire embedded system in pure
C; it has always been a mix of C and assembly language. Sometimes
the contents of the function was replaced by assembly language (so
the function calling I/F would not be changed). One company I worked
for had a rule: C functions could be replaced by assembly as long
as the assembly function worked the same or better than the C version.

The OP does have a valid complaint, if it isn't possible to write embedded
systems wholly in C without resorting to use of the assembler.
However the problems of designing a portable language that could make use of
low-level hardware functions would seem to be insuperable. C is the best
option that we have.

Nov 13 '05 #8
>> 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.


When he said "fixed point" he probably meant "integer". His complaint
is that C doesn't give us any way say that we want to multiply two N
bit ints and accumulate the 2*N bit long int product (that's a common
requirement in digital signal processing). If we could somehow express
that in C, then the optimizer may be able to emit much more efficient
code. I'm not advocating that C should do that, just clarifying his
complaint.
Nov 13 '05 #9
Gammaburst <sp******@eat.t his> wrote:
When he said "fixed point" he probably meant "integer". His complaint
is that C doesn't give us any way say that we want to multiply two N
bit ints and accumulate the 2*N bit long int product (that's a common
requirement in digital signal processing). If we could somehow express
that in C, then the optimizer may be able to emit much more efficient
code. I'm not advocating that C should do that, just clarifying his
complaint.


uint_16_t factor1, factor2;
uint_32_t result;

result = (uint_32_t)fact or1 * factor2;

Surely that should work in C99? For C89, typedef uint_N_t to be
whichever type is appropriate.

Richard
Nov 13 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

13
1779
by: Joe Feldman | last post by:
This position is located in the South Bay Area in Northern California. If you are interested please send me your resume in a word .doc so that I can review it. If this does not look like a match, we have over 100 other open positions. Senior Member of Technical Staff/ Principal Engineer- Protocols Infrastructure
10
4127
by: lallous | last post by:
Hello, This question was asked in comp.lang.c++ and the answers involved the use of objects whose destructors are automatically called when getting out of scope, however I was expecting suggestions that doesn't involve the use of objects. So here is the question again. I have a function like: void fnc() {
49
8981
by: Alex Vinokur | last post by:
Are there any restrictions/problems for use of C++ STL in development in embedded systems? In particular: * Does STL require too much space/memory? * Is 'implementation of STL algorithms/methods' reenterable/reentrant? * What is the cost to provide continuity of vectors in memory? Any other problems? -- Alex Vinokur
20
22557
by: Jack | last post by:
Is there a Python packaging that is specifically for embedded systems? ie, very small and configurable so the user gets to select what modules to install? For Linux-based embedded systems in particular? I'm thinking of running it on the Linksys's Linux-based open source router WRT54G. It has 4MB flash and 16MB RAM. I think another model has 16MB flash. Any possibilities of running Python on these systems?
0
2273
by: YellowFin Announcements | last post by:
Whitepaper: "Yellowfin Reporting" enables Embedded Business Intelligence -------------------------------------------------------------------------------- Embedded reports are a standard requirement of most applications. But users are increasingly demanding more sophisticated reporting from applications - seeking such features as custom report design, ad hoc report creation and analytics. Developers that want to embed business...
18
2573
by: Chris Hills | last post by:
The MISRA-C team has to make a decision: should it move from Referencing C95 (9899:1990+A1+RC1+TC2) to referencing C99 for the next MISRA-C (version 3) In the real world (especially embedded, safety-critical and high-integrity circles) there are no C99 compilers in use as on September 2007. They are C95+. Any thoughts from anyone involved in writing compilers? Either to the NG or to my email address. Yes, I have asked most of the...
14
1903
by: Martin Wells | last post by:
When I want to store a number, I use "unsigned". I go with unsigned because it's the natural type for the system, and so should be the fastest. However, there are 8-Bit microcontrollers out there that do 8-Bit arithmetic faster than 16-Bit arithmetic, and so on these systems char is faster than int. Standarising C in such a way that int is at least 16-Bit, has this made C both slow and memory-hungry for embedded systems programming?
20
2060
by: =?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?= | last post by:
There are a few guarantees I exploit in the C Standard. For instance, I might write (unsigned)-1 to get the maximum value for an unsigned integer. Also, I might rely on things such as: memset(data,-1,sizeof data)
30
4312
by: =?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?= | last post by:
Let's say we had a simple function for returning the amount of days in a month: unsigned DaysInMonth(unsigned const month) { switch (month) { case 8: case 3: case 5:
0
9682
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10872
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10270
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9397
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7806
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5668
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
4474
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4040
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3124
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.