What are the merits and demerits of using C over assembly language for mcu programming.
thank you
ece
You produce code faster using C.
You will get a lot fewer hard-to-find errors with C. The compiler notices uninitialized variables etc.
The code is easier to move to a different processor, since C is universally available. Only specific language extensions to take advantage of the architecture or code that manipulates bits in the processor will be non-portable or require some rewrites if changing to a different processor.
It is easier to rewrite the code to extend (or change) it's behaviour since the compiler and the language encapsulation will often catch partial rewrites.
It is easier for another developer to look at the code and understand it, or to be able to take over.
It is easier to debug. A higher-level language means that more can happen for each line when single-stepping. A single multiply or division in C can require a lot of assembler instructions if the processor doesn't have hardware instructions for multiply or divide.
The code may be a bit bigger/slower - but only if you have reasonably good knowledge of assembly for the specific processor. A lousy assembler programmer will loose to a compiler.
"Only (sic) specific language extensions to take advantage of the architecture or code that manipulates bits in the processor will be non-portable or require some rewrites if changing to a different processor."
Those parts will certainly need re-writing - but they are not the only parts!
There are many details of the 'C' language which are implementation-defined - any code which relies on such details will be non-portable.
But there are techniques to "encapsulate" these dependencies so that porting can be quite painless.
With assembler, you can't even guarantee that a different assembler for the same architecture will have even remotely similar syntax!
The code is easier to move to a different processor the most abused argument in small embedded. in small embedded you are, for a large part, so close to the hardware that portability is irrelevant.
It is easier to rewrite the code to extend (or change) it's behaviour since the compiler and the language encapsulation will often catch partial rewrites. I have no idea what this means. The compiler compiles what you write whether partial or not.
It is easier for another developer to look at the code and understand it, or to be able to take over. I have seen C I could not even dream of figuring out, I have seen well documented assembler that was a breeze.
It is easier to debug. A higher-level language means that more can happen for each line when single-stepping. A single multiply or division in C can require a lot of assembler instructions if the processor doesn't have hardware instructions for multiply or divide. you do not have to step, just set a breakpoint at the end. C debugging often hides stuff from you.
Erik
Doesn't matter if the embedded system is small or large.
A ring-buffer for serial data can have most of the lines reused by another project. So can most of the code from a real-time clock.
If you use software engineering when writing your applications, then you can get huge amounts of help from the compiler when switching algorithms or data structures. Assembler often don't have good enough methods to encapsulate data in structures, or to type-control variables, which means that the assembler has too little information to catch a lot of errors that are obvious to a c compiler.
It's completely irrelevant how you can abuse a language. The question is if there are a difference in readability if you write reasonably sane code.
When you have an algorithm that doesn't do what you expect, you often set a breakpoint where you want to start debugging, and then single step while trying to figure out where everything goes wrong. Writing in assembler means that you may have a huge number of small steps to single-step. It is hard to skip over all the code for a multiprecision multiply or divide, since they may be the reason for the bug. When using C, it is reasonable to think that a already tested function should do ok as long as you don't have a stack overflow. With assembler, you have to assume that you may send the wrong registers to it, or fetch the answer from the wrong registers. Or missing to pick up on any register flags after the call. Or having the function modify a flag you thought should not be affected. Hence, even if modularizing the assembly, you still have a lot more information to step through.
Yes, there are assemblers with splendid macro functionality - but those macro features are very, very specific to that assembler. Ever used an assembler that the company suddenly dropped the support for? Being forced to switch to a different C compiler may be a pita, but a very much smaller pita than being forced to switch to a different assembler.