plzzz help............novice here

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.

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.