i dont mean to keep carrying this off into a tangent, but that's just plain not true

8051 derivatives have been being programmed in C as far back as 15 years ago, starting with the old Keil compiler. and thats just as far back as I remember.

sure, there are still sunday-afternoon hobbyists and students in poorly-funded classrooms who may program blinking-LED projects for their PIC's in assembly

but as far as industry goes... tons of embedded apps use PICs, 8051s and similar GP controllers in complex applications ... and it would be absolute *suicide* for any competitive company to try and program them in Assembly. you'd never get your product to market in any reasonable time, and maintenance would be cost-prohibitive

think about it, when a C compiler costs a few hundred dollars, what kind of business would be crazy enough to pay the manhours required for a staff of assembly coders?

look im not saying there arent any Assembly coders out there gainfully employed. but they're the exception, not the rule. the majority of assembly you see these days are short little macros, sparsely placed

When debugging embedded systems, logic analyzers display timing diagrams, hex or in the good ones asm code. Sometimes you need to check your hex file for errors. Sometimes you need to create delays based on how may machines cycles an instruction takes. My point is you can't be a good programmer using those chips with out knowing the instruction set and those programmers can't keep asm in the back of their minds like desktop programmers can.

When writing a program, the question is still should/can the program be coded in a language other than the processor's native one, though the answer is usually yes. Even so, the programmer still thinks about what the uC is doing at the machine level. It makes no odds if 3/4 of your micro program is going to be C expressions like port1 = 0; as opposed to assembly lines
like mov port1, 0. It doesn't matter if you're a student blinking leds or a hired programmer writing a program to control the led display in your microwave.

Lastly, my brother programs PICs as part of his job. I hang out in micro forums and see nothing but assembly code. To be fair I don't know if assembly is used more, I just have reason to believe so.
It's just this comment I take exception to.

"in the early 90's it was important to know Assembly to do embedded programming"

because it's false to think it still isn't true regardless of what language is used.
Learning the hardware and learning the instruction set are one in the same.

okay, i agree with you on what i think are your points:

(1) there are still some people, somewhere, doing meaningful work in assembly.
(2) programming microcontrollers does require some "understanding" of how it works at the assembly level (but NOT for programming entire functions in assembly)
(3) there will always be a need for the occasional macros, such as precision timing, to be coded in assembly

but the point im trying to make, relative to the OP's question on which language to learn, is that

Assembly should be learned only after you have a solid command of the C and C++ fundamentals.

because, unlike 15 years ago, C compilers today produce highly efficient machine code for embedded microcontrollers in a way that has made 95% of the Assembly programmers and their arcane bag of tricks completely redundant.

the beginner will get the most return on their investment by learning C and C++. ... virtually no one hires entry-level assembly programmers. they do hire entry level C and C++ programmers. so learn to crawl, walk, and run before you learn to fly.

another very important thing Dragon noted earlier, is that if you learn Assembly first, you have to UNLEARN all those techniques that are useful only in Assembly, and make horrible, horrible practice for C and C++ ... like the heavy use of jumps and gotos, for instance.



.

I don't disagree if x86 assembly is the question. I don't see many reasons other than interest why people program those animals in assembly.

I have to agree with jephthah, I have programmed AVR and 8051 both in C. Though there is option to program in assembly but when sometimes it becomes difficult to learn the instruction set especially if you want to program many microcontrollers.

Furthermore, in the end both the assembly and the C code gets converted to .hex or .eeprom that is used to burn onto the microcontroller and I dont think it makes much of a differenc on what language you code(correct me if I am wrong).

You agree we can be serious 8051 programmers and not ever learn the instruction set? If so, could you explain how to create a delay of exactly 20us in Keil C for the 8051, if my two timers are already used?

Sure. It wouldn't be a C compiler if it didn't convert the source to object code.

look... the QUESTION that the original poster asks is, essentially, should he learn Assembly or should he learn C.

I'm saying this:

you can be a good C/C++ programmer, and do a lot of "real" work -- embedded or otherwise -- without having to know the deep dirty secrets of Assembly programming

Contrariwise, you can NOT just be a good Assembly programmer, and reasonably expect to do any meaningful projects in the real world, without having solid C skills.

C is therefore *primary* to Assembly and should be emphasized with prejudice over Assembly.

15 years ago (maybe even 10) the world was a different place. You could still argue the primacy of assembly over C for embedded. But the world has changed, and the changing technology of C compilers has caused a complete paradigm shift.

you can either move along with the change or get left behind.

so my advice to beginners is: learn C now, worry about assembly later. And this is coming from someone who learned (and loved) assembly first.

that is all.



.

Perhaps I did not make my statement clearly. I agree with jephthah that assembly should be learned after C/C++ . I dont have much experience at microcontroller programming but I did try my hand at both assembly and C and found C more comfortable.

Perhaps at later stages I will need to use assembly, but surely my first priority would be solving the problem in C. I will answer your first question after I have acquired considerable experience.

you cut-and-paste a teeny-tiny little delay macro that already exists in a million places on various 8051 boards, tweaking it if necessary.

as for the remaining 99.9% of your embedded code, you continue programming in C.

that's how you do it.

what you DON'T do, is become an Assembly Guru and learn every deprecated assembly programming technique from the early 1990's.