Related to:
If you are writing co
Go for c !
I've worked for a large CE manufacturer. The last time I saw assembly was there was around 1996 in some small interrupt services routines for RC5 and RC6 decoding and TV tuning algorithms. After that always used c, and C++ (only used classes, no stl, exceptions or rtti). I have good experiences with the old KEIL compiler for 8051 and with greenhills compiler (MIPS) and the VxWorks toolset (PowerPC based).
As Roddy says, first write in C , and optimize in assembly later (if needed).
That is the bottom line if you use C you can hand optimize later, I wouldnt use anything other than C or assembler (no C++, etc).
The key is the microcontroller instruction set if you are using a PIC or even an 8051 I would use assembler only. If it is a compiler friendly isa like arm or avr or msp430 then use C to save some typing but you will probably have some routines in assembler for various reasons. Likewise you probably want to avoid a C library, even newlib can be just too bulky, borrow code or ideas from them but dont just link one in. Oh, back to the question, look at what C compilers are available for the target, again arm and avr you wont have any problems. Likely msp is okay as well. Just because Keil or Iar will SELL you a compiler doesnt mean you should buy it or use it, the output of pay for as well as free compilers can be dreadful. You need to be well versed in the asm anyway and examine the output (you probably have to write a disassembler to do this).
Bottom line (another bottom line), there is no global answer (well avoid anyhthing higher than C is a global answer) it always depends on what the platform is what your resources are what your task is what the performance requirements are what the portability requirements are (if it is truly embedded on a microcontroller much of it is by definition not portable) what compilers, debuggers, jtag, etc are availble, even so far as what host operating system are you developing on can be a big factor.
The problem these days is that embedded can be anything from an ATTiny with 6 pins and a few bytes of RAM to a multi-core SBC running an embedded OS that would put some people's desktop computers to shame.
As such, the choice of langauge / development environment needs to take into account how efficient you need to be vs how complex the system is.
First off - C works everywhere and scales pretty well, the higher you go the more you'll end up calling external libraries etc. to handle the complexity.
For very small micros (measuring flash/ram in bytes) you are best off using ASM, when you get up to the kb range, C or any of the other traditional languages can be used as you don't need to count every byte. Once you have megabytes to play with you have both the ability and increasingly likely the requirement to use an RTOS to take care of everything and cut down development time. By the time you have hardware you could run a full blown OS on you can probably abstract yourself from the hardware and just write everything in a padded cell like Java or somesuch without worrying too much about how terribly wasteful it all is and how you're not a real programmer anymore... ;)
The exception to the above is when you need all the performance you can wring out of the hardware, at which point you may need to drop down a level or two to keep things efficient.
Assembly can in many cases be faster; when you're on a desktop, the compilers tend to be optimized to the point that hand assembly is rarely a necessity, but in the uC world, it often is. Also, if you need to write interrupt handling routines and things like that, you often can't do it in C.
As for compilation, google around for a C compiler for your target.
It is too bad no one has mentioned Forth or Scheme so far. Both can be appropriate for small environments, and can give impressive productivity gains.
I would definitely go with C. It is faster and it creates more reliable software. Assembly has very little to offer and in scarce occasions. Have in mind that in C:
Another thing that specifically has to do with PIC18. You won't have to deal with the non-intuitive PIC architecture and things like memory BANKs.