LCD help needed

erik malund said: "this is NOT an argument aginst using C (I do it extensively) but the "portability" is very limited in small embedded."

I agree with erik. In C, often the compiler choices, memory layout and linker scripts are so different from a processor to the next, that major redesign is inevitable.

For example, writing precise timing loops in C is often a waste of time, because you simply can't control the machine code generated from the C source. A simple change in compiler optimization level can wreck you timings.

Especially when you need to push the performance, you tend to write a C style that matches the particular processor you target. There are always specific ways to write loops, logic sequences, expressions, function prototypes that match more closely a given processor.

An embedded programmer that is conscious of these styles will write faster and smaller C code, often deviant from ANSI. When you are struggling to fit a 80KB code in a 64KB processor flash, that's a go/no_go issue.

"So, if it works in assembler, let sleeping dogs lie"

Absolutely. I have seen C code that is virtually unrecognizable. As a matter of fact, the assembly portions of the large systems we work with are generally much better documented and maintainable, because they were usually written by a careful coder.

Almost all large systems we produce have the lower lib layer written in hand-optimized assembly for the target processor core.

erik malund said: "this is NOT an argument aginst using C (I do it extensively) but the "portability" is very limited in small embedded."

I agree with erik. In C, often the compiler choices, memory layout and linker scripts are so different from a processor to the next, that major redesign is inevitable.

For example, writing precise timing loops in C is often a waste of time, because you simply can't control the machine code generated from the C source. A simple change in compiler optimization level can wreck you timings.

Especially when you need to push the performance, you tend to write a C style that matches the particular processor you target. There are always specific ways to write loops, logic sequences, expressions, function prototypes that match more closely a given processor.

An embedded programmer that is conscious of these styles will write faster and smaller C code, often deviant from ANSI. When you are struggling to fit a 80KB code in a 64KB processor flash, that's a go/no_go issue.

"So, if it works in assembler, let sleeping dogs lie"

Absolutely. I have seen C code that is virtually unrecognizable. As a matter of fact, the assembly portions of the large systems we work with are generally much better documented and maintainable, because they were usually written by a careful coder.

Almost all large systems we produce have the lower lib layer written in hand-optimized assembly for the target processor core.

"writing precise timing loops in C is often a waste of time"

Rather than "often", I'd say "always" - certainly for precise timing:

"because you simply can't control the machine code generated from the C source."

Absolutely - because you can never control it, it is always a waste of time!

"A simple change in compiler optimization level can wreck you timings"

Even without changing optimisation; eg, if the compiler happens to be using a register in your delay, then you add some "unrelated" code and the compiler happens to use the register for this and therefore something else in your loop...

An embedded programmer that is conscious of these styles

if he is not, he has no right to call himself an embedded programmer

Erik

Andy Neil wrote: "NEVER write precise timing loops in a HLL"

erik malund wrote: "... he has no right to call himself an embedded programmer"

To whom I fully agree. Maybe I should have made stronger remarks on my comments.

It is so tiresome the pointless ancient discussion of C versus ASM.

Real development in C always require you to implement base functions and critical portions using non-portable and/or low-level.

Even when using C++, I use to implement many methods of the base classes in assembly.