We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
hi buddies.........i am a green horn to Embedded World.
Please send me few basic programs that i can do it on my silicon labs c8051f350. and also any books related to C programming for 8051. I had already gone thru Keil Cx51 Compiler but didn't understand anything.
Pleeeeeease guide me. Thanx a lot.
"...to b a good embedded programmer we shud be very good at pointers..."
You can't be a C programmer without understanding the mapping of data objects in memory. You have to convert data from one data type to another, use arrays, and pass data by reference to functions. All that need pointer knowledge.
Here are a few C links to help you:
www.lysator.liu.se/.../ten-commandments.html www.lysator.liu.se/.../bwk-tutor.html http://c-faq.com/ www.phim.unibe.ch/.../master_index.html www.eskimo.com/.../
Now, to be a good embedded programmer, you need to go further than C: you must study carefully the architecture of the target processor core, understand issues like stack, memory models, storage classes, and efficient C style.
Furthermore, you absolutely need to thoroughly read and understand the chip data sheets, compiler manuals and errata.
www.lysator.liu.se/.../bwk-tutor.html
Note the disclaimer at the top of this page:
"This 'tutorial' is presented as a historical document, not as a tutorial. Although it has lost little of its didactic value, it describes a language that C compilers today do no longer understand: the C of 1974, four years before Kernighan and Ritchie published the first edition of 'The C Programming Language'"
(my emphasis)
This WILL requere some fluency in assembler, which, unfortunately, is 'obnoxious' to many.
I know NO "good embedded '51 programmers" That are not fluent in assembly whether they use it or not.
Erik
"Note the disclaimer at the top of [the] page"
You're right, of course. But I think it is still a nice tutorial, filled with many historical info on C (for example, that some machines implemented int with 36 bits and char with 9 bits).
I probably should have made the disclaimer explicit. The function argument declaration syntax used, for example, is not supported in current C compilers, and several ANSI features were added much later to the language.
erik malund wrote: "This WILL require some fluency in assembler, which, unfortunately, is 'obnoxious' to many."
Yes. It derives from the notion that working at the dungeons-level is a waste of time. This reflects the pre-reuse era of computing, when low-level was still an option for system programming for large systems, and the industry was striving to move to higher-level, cross-platform reusability.
That is a sad misconception when applied to deeply embedded or high-performance programming.
Learning well the architecture of the target processor and its Assembly Language is a must to any embedded programmer, or to anyone that works at the state of the art, like library and driver design.
"I know NO "good embedded '51 programmers" That are not fluent in assembly whether they use it or not."
I will go further: I know no real embedded programmer who doesn't have a good knowlegde of the chip-level design, and has the chip datasheets and circuit schematics at arm's length.
It is SO MUCH EASIER to write good embedded software when you know the compromises and dependencies of your code from the circuit-level up. -------------------------------------
That said, I am not saying that embedded code should be written in an unportable way. But every high-performance code WILL need retargetting, often at a very pervasive scale in the source code.
Better than write fully recompilable ANSI code with no compiler-specifics or processor-dependencies, you should always write clearly docummented, architecturally-clean code, functionally-local, so it will be easy to retarget at the algorithm-level using any strengths the new processor may have, instead of just recompiling at the implementation level.