Quote:
|
Originally Posted by velocipenguin
Tweaking code for maximum efficiency is a useful skill to have. Coding for small microcontrollers, regardless of the language used, requires a fair amount of manual adjustment to make everything fit. Although I suspect this is rather uncommon, I actually enjoy this; it's a tremendously entertaining challenge to try to cram complex routines into the tiny program ROM on low-end PICs. If you want a language that hides all the scary details from you, code in PBASIC. C is a little harder to deal with, but it offers far more control over the hardware than anything else (except assembler, of course).
|
This is a great point. C's strength is in making highly efficient code for embedded control systems. That is one reason that I like having C for the controller this year: it gives people a good feeling for what it's like to program a real embedded controller.
As I've mentioned before, things are starting to move more toward auto-coding, but this is made possible due to faster, cheaper microcontrollers that can make up for the more inefficient code. However, there is still a high likelihood that we'll be using C for quite a while since there will always be an ultra-cheap product that needs to have too much code crammed into a tiny micro.
One last thing about auto-coding: Auto C code generation is just another step up the auto-coding ladder. It's not that revolutionary. Think about it: what is a C compiler other than an auto-coder for assembly language? People used to program with only an assembler. Now the standard is to let the C compiler auto-generate the assembly code and THEN let the assembler go ahead and make the machine code. The next level up is to let TargetLink create the C code, then the compiler creates the assembly code, and so forth.