Bill said:
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_Polling(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.learn.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