good Embedded C resources plz...

You will find articles about Embedded Software Design at:

-- EventStudio 2.5 -

Real-time and Embedded System Modeling with Sequence Diagrams

hi christina this is mehul here. i had opted for Embedded Systems as my elective. you can check out the book on "Embedded C Using AVR", it's the best book on earth to learn EC. you can reach me at

This is a good book for beginners Programming Microcontrollers in C" by Ted Van Sickle. On Amazon:

It is biased toward Motorola/Freescale micros, but that should come as n surprise since Mr Van Sickle works for them.

As a general introduction to micros and their capabilities, Jack Ganssl (a well known industry maven) reccomends this book:

-Aubrey This message was sent using the comp.arch.embedded web interface o

"[..] I wanna learn C programming language to the level that I can do good embedded programming.

[..]

I wanna be strong at embedded C programming."

This is good. Your aspirations already exceed those of many C programmers.

"In my course I have learnt basics like arrays,pointers,data structures."

Avoid dynamic memory when feasible.

"But in embedded field I see,more usage of macros, [..]"

Avoid macros, though unfortunately many embedded C libraries are riddled with these.

Care to elaborate why?

Vadim

Embedded programming is where the fun is! Churning out yet another pretty windows app is soul destroying. In the embedded field you get to play with lots of toys and work at a desk covered in circuit boards, wires and emulators!

Definitely. The smaller the memory on your taret processor the more this rule applies. In my products using malloc would require approval from the chief software Engineer and an extremely good justification.

Macros are an extremely good way of hiding the implementation and making your code more readable and maintainable. Many times you need to directly drive the GPIO lines of a processor to perform some interfacing function. For example if you use constructs like

#define BIT6 0x40 #define GPS_ARM_INTERRUPT BIT6 #define ASSERT_GPS_INTERRUPT() P2OUT &= ~GPS_ARM_INTERRUPT #define REMOVE_GPS_INTERRUPT() P2OUT |= GPS_ARM_INTERRUPT

then the code is easier to read ASSERT_GPS_INTERRUPT() ; as opposed to P2OUT |= 0x40 ;

and should your hardware pin assignment change then you have only one change to make. Supporting multiple hardware targets just becomes a conditional compilation of the macro definitions.

Trust me - been there and earned the T-shirt many years ago ;-)

Ian

p.s. Christina - I realise that you are posting from a German domain, and that English is probably not your first language, but please try to avoid falling into TXT/SMS speak. I seem to spend half my life trying to get my daughters to speak English and obliterate wanna, gerrit, innit... These just make you look stupid, probably a wrong impression but that is how you portray yourself.

snip

I'm about to start a little project with the AVR butterfly, and since my programming skills are not the greatest I find going through other peoples code very useful. Currently I am going through

the code is in AVR Butterfly - Application Rev06

Also check out Jack Ganssle.

Do any people here keep URLs' of " nice code" for AVRs' and the like?

martin

"[..]

Avoid macros, [..]"

Ian said:

"Macros are an extremely good way of hiding the implementation and making your code more readable and maintainable. Many times you need to directly drive the GPIO lines of a processor to perform some interfacing function. For example if you use constructs like

#define BIT6 0x40 #define GPS_ARM_INTERRUPT BIT6 #define ASSERT_GPS_INTERRUPT() P2OUT &= ~GPS_ARM_INTERRUPT #define REMOVE_GPS_INTERRUPT() P2OUT |= GPS_ARM_INTERRUPT

then the code is easier to read ASSERT_GPS_INTERRUPT() ; as opposed to P2OUT |= 0x40 ;

and should your hardware pin assignment change then you have only one change to make. [..]

[..]"

Is that any more readable than the following?

enum { BIT6 = 0x40 /*or 1

Martin Griffith asked:

"[..]

Do any people here keep URLs' of " nice code" for AVRs' and the like?"

I have not really examined it, but you might like

Care to elaborate why?"

Lexically changing the program with a preprocessor for no reason has been discouraged for quite a few years in the C community.

[...]"

You need a semicolon at the end there. And it only works for values of type int. E.g.

enum { MAX_VOLTAGE = 16.5 };

will not compile.

Perhaps, if you declare it static and put it in a header file. Otherwise, a function body must be generated, since the compiler doesn't know from where else this might be called.

But it depends on the quality of your compiler. The inline keyword might help, if your compiler supports it.

[...]

In C, the compiler _will_ reserve memory for BIT6, no question, where a macro will not. Also,

const int ARRAY_SIZE=10; int array[ARRAY_SIZE];

works in C++, but not C.

Regards,

-=Dave

--
Change is inevitable, progress is not.

Since were talking embedded, I would point out that macros defining bits and such can be useful in mixed assembly/C scenarios, whereas enums and consts don't do much for any assembler I've ever used :-)

In one project I had almost exactly the code that you suggest - using actual function calls rather than macro expansion. I went through an exercise in code size reduction and by using the macro method the code size was reduced by some 300-400 bytes. This was a significant saving, allowing me to get all of the required functionality into the target.

Ian

Dave said at Wed, 24 Aug 2005 19:36:01 GMT:

"On 24 Aug 2005 20:34:39 +0200, Colin Paul Gloster wrote: [..]

You need a semicolon at the end there."

Correct, sorry.

" And it only works for values of type int. E.g.

enum { MAX_VOLTAGE = 16.5 };

will not compile."

Not as good type checking as const, but when enums work they can be better. If someone accidentally used an enum for a float, this will be caught at compile time and can be replaced with a variable or a macro then.

"In C, the compiler _will_ reserve memory for BIT6, no question, where a macro will not."

Correct, and unless memory is being exhausted, this is not necessarily a problem, and for those of us who have to modify a deployed system by radioing a patch with only a few minutes' radio visibility of the system at a time, it can be beneficial to modify one datum and have it work throughout the memory image, instead of patching everywhere the value is needed.

An example I had this week of a system (which will not be patched like this, chiefly because its only receiver is a GLONASS/GPS receiver and not a general purpose radio) in which I did replace a const with a macro did reduce the memory consumption (but even with most of my 4KB of RAM being used I am not in trouble of running out of RAM, and with far over half of my 64KB of ROM unused I am content), but the reason I did this was because one deadline was being missed, and using the hardcoded literal (which in my terms a macro is, though you would seem to disagree) sped it up enough to meet that deadline.

"Also,

const int ARRAY_SIZE=10; int array[ARRAY_SIZE];

works in C++, but not C."

And

enum {ARRAY_SIZE=10}; int array[ARRAY_SIZE];

works in ANSI/ISO C99 and not ex-ANSI/ex-ISO C89. 1989 was a long time ago. Yikes, so was 1999 even. So why not use enum here in 2005?

Gloster said: " void ASSERT_GPS_INTERRUPT(void) /*This can probably be compiled without any function call overhead.*/ "

Dave responded: "[..]

[..] The inline keyword might help, if your compiler supports it."

I have just noticed ( news: snipped-for-privacy@news.xsall.nl ) that inlining is part of the current C standard.

From PDF page 290, hardcopy page 205 of

:

"On average every fifth statement is a function call. This is very frustrating for writers of optimizers (long sequences of C code without any function calls provide more opportunities to generate high-quality machine code). The introduction of support for the inline function specifier, in C99, offers one way around this function specifier syntax 1512 problem for time-critical code."

From later in that document:

"6.7.4 Function specifiers

-------------------------- 1512 function specifier syntax function-specifier: inline Commentary Rationale The inline keyword, adapted from C++ . . . The keyword inline is invariably used by languages to specify functions that are to be considered for inlining by a translator.

C90 Support for functionspecifier is new in C99. [..]

Coding Guidelines Those coding guideline documents that argue against the use of the register storage-class specifier may well argue against the use of function specifiers for the same reasons. These coding guidelines do not recommend against this usage for the same reason they did not recommend against the use of the register storage-class specifier.

[..]

1519 Making a function an inline function suggests that calls to the function be as fast as possible.118) Commentary The inline specifier is a hint from the developer to the translator. The 1970s gave us the register keyword and the 1990s have given us the inline keyword. In both eras commercially usable translation technology was not up to automating the necessary functionality and assistance from developers was the solution adopted. Published figures on translators that automatically decide which functions to inline[210, 315, 338] show total program execution time reductions of around 2% to 8%. The latest research on inlining[1384] has not significantly improved on these program execution time reductions, but it does not seem to cause the large increase in executable program size seen in earlier work, and the translation overhead associated with deducing what to inline has been reduced.

[.. paragraph about not caring about function delays from a clearly non-embedded persepective and more importantly non-realtime]

It often comes as a surprise to developers that use of the register storage class can slow a program down. The same is also true of the inline function specifier; its use can slow a program down (although the situations in which this occurs appear to be less frequent than for the register storage class). Degradations in to an increase in page swaps, on hosts with limited storage; or an increase in program size causing the number of cache hits to decrease are the most commonly seen reasons. One published report[267] (Fortran source) found that a lack of sophisticated dependency analysis in the translator meant that it had to make worst-case assumptions in a critical loop, that did not apply in the non-inlined source. Even when inline is used intelligently (based on execution counts of function calls) improvements in performance can vary significantly, depending on the characteristics of the source code and on the architecture of the host processor.[315, 338]

[..]

Coding Guidelines The term type safe macro (because the types of the arguments are checked) or simply safe macro (because the arguments are only evaluated once) are sometimes applied to the use of inline functions. 1520 The extent to which such suggestions are effective is implementation-defined.119) Commentary There is no requirement on an implementation to handle calls to a function defined with the inline function specifier any differently than calls to a function defined without one. This behavior parallels that for the register storage-class specifier.

[..]

Coding Guidelines Drawing parallels with the implementation-defined behavior of the register storage class would suggest that although this behavior is implementation-defined, no recommendation against its use be given. However, there is an argument for recommending the use of inline in some circumstances. Developers sometimes use macros because of a perceived performance advantage. Suggesting that an inline function be used instead may satisfy the perceived need for performance (whether or not the translator used performs any inlining is often not relevant), gaining the actual benefit of argument type checking and a nested scope for any object definitions.

1521 Any function with internal linkage can be an inline function.

Commentary The C Standard explicitly gives this permission because it goes on to list restrictions on inline functions with external linkage. [..]

1522 For a function with external linkage, the following restrictions apply: Commentary The following restrictions define a model that has differences from the one used by C++. Rationale Inlining was added to the Standard in such a way that it can be implemented with existing linker technology, and a subset of C99 inlining is compatible with C++. [..] 1526 Therefore, for example, the expansion of a macro used within the body of the function uses the definition it had at the point the function body appears, and not where the function is called; [..] 1531 An inline definition does not provide an external definition for the function, and does not forbid an external definition definition in another translation unit. Commentary An inline definition is explicitly specified as not being an external definition. The status of an inline function as an inline definition or an external definition does not affect the suggest it provides to a translator. An inline definition is intended for use only within the translation unit in which it occurs. Because it is not an external definition, the constraint requirement that only one external definition for an identifier occur in a program does not apply. However, if a function is used within an expression an external definition for it must exist somewhere in the entire program. The absence, in a function declaration, of inline or the inclusion of extern in a declaration creates such an external definition. Also, because an inline definition does not provide an external definition, another translation unit may have to contain an external definition (to satisfy references from other translation units). 1532 An inline definition provides an alternative to an external definition, which a translator may use to implement any call to the function in the same translation unit. Commentary The inline definition provides all the information (return type and parameter information) needed to call the external definition. Its body can also be used to perform inline substitution. An inline function might be said to have ghostly linkage. It exists if the translator believes in it. Otherwise it does not exist and the external definition is referenced. [..] 1533 It is unspecified whether a call to the function uses the inline definition or the external definition.120) Commentary The C Standard does not require that the sequence of tokens representing an inline definition or external definition, of the same function, be the same. However, the intended implication, to be drawn from the unspecified nature of the choice of the definition used, is that a programs external output shall be the same in both cases (apart from execution time performance). If the definitions of the two functions are such that the external program outputs would not be the same, the behavior is undefined. [..] [..]These extensions do offer some advantages; and programmers who are concerned about compatibility can simply abide by the stricter C++ rules. [..] Commentary Although fahr is an external definition, an implementation may still choose to inline calls to it, from within the definition of convert. [..]"

sample code for avr gcc / win avr and for bascom

Video Generation with Atmel AVR microcontrollers Alex