Anyone who's followed my position in the HLL-vs.-ASM debate for any length of time will recognize, I'm probably overly sensitized to the fact that HLL tends to be both bigger and slower than ASM. Further, it's probably been noted that I use ASEM-51 much of the time, hence, can define my own macros, which generate application-specific functions very easily and with a minimum of overhead. A macro is, functionally, as observed by the programmer, just another opcode, though it expands into whatever volume of code it represents. It can be lightning-fast when needed, and, of course, it can deal directly with MCU specifics just as efficiently and often more-so than can a HLL. Unless you KNOW that the product life is going to exceed the life of the current code body, there's not much advantage in writing the code in 'C', no matter how popular 'C' is, or in Pascal, no matter now widely understood it is, if it's not going to survive the current revision in hardware. The only potential advantage is in the possible port to an entirely different architecture. If that's not on your menu, I'd say you're not going to produce the best possible result for your boss/client/customer in HLL unless his volume is pretty low and his cost-sensitivity is pretty high. Those seldom occur together. As exception might be the one-shot, not so rare, where a client/customer wants a product out the door quickly so he can seize market share quickly and then sell his product and company, then retire to the south seas.



As one who is more familiar with writing embedded code in ASM than in HLL, I have to agree that it's not so much easier to write 'C', PASCAL, or BASCOM code than to write ASM, particularly when using a MACRO-ASSEMBLER.

Though you can, if you like, use include files for setup, and other "boilerplate" for specific MCU's (805x variants), it's just as easy to do, and simpler to understand, if included in macro definitions as part of the main code body. It does, after all, remain as "boilerplate" which contains, among other things, the static definitions that you're going to want to use with any implementation of the current MCU. Moreover, you will, over time, develop habits that utilize those features and thereby become more easily understood by any reader of the code, be it someone else or yourself at a later date.

Moreover, with the use of MACROS, either inline or called, your code becomes much more readable than it would in HLL, because there's a well-defined mnemonic at the place where you use it, which, in HLL, generally requires a cross-reference to examine what it is and what, exactly, it does the machine state. If you use simple conventions, as HLL would, with respect to parameter passing and status return, your code couldn't be more transparent in HLL.

Now, I disagree that it's much more convenient for one who knows enough to do the job properly in ASM to do it in any HLL. The very things that make the HLL convenient make embedded programming less so because they interpose themselves and the compiler/language intrinsics between the programmer and the details of the machine. Those details are the very things that require the most attention.

If there's a vital algorithm that begs to be written in HLL, one could do that and then whittle on the resulting ASM until it's truly optimized for the target MCU and application though that will most likely be a truly burdensome task, and then insert it as a MACRO in the ASM code. I personally doubt the virtue of that approach, but believe it could be done.

RE