The cookbook is useful. There are lots of opportunities for assembler still, especially in microcontrollers, so don't let the C zealouts fool you, they just haven't pushed the limits of the hardware, or spend $$ on more hardware to deal with compiler overhead.
I wouldn't use it for everything, only where needed, but sometimes you need very tight timing control, or you need to save some space, or you otherwise know what the hardware is capable of but can't outsmart the compiler into doing it (or think it is ridiculous to try only to watch it break with the next release or a change in compiler flags).
So there are lots of things you can do without it, but some things that you can't. Pushing the limits of the hardware with a compiler is like pushing anything with a wet noodle. If you have lots of units for a project and can use a less expensive chip with assembler then that can be a win too. As well anytime something goes wrong with the compiler, the first answer is usually "look at the assembler output". The higher language abstractions are great and make simple jobs easy, but still worth knowing exactly what is going on under the hood in any event.
I was VERY glad to see the cookbook, that can only encourage more pushing of the limits of the hardware, though I did notice the mbed ide isn't reporting asm errors very well.
Iam really unhappy with the only program I can get to work with the mbed is the "HellWorld" program. I typed it in ( both the C portion and the *.s ) I got it down to the last error and it would not tell me what line the problem was on. I took the assembly (*.s) portion and took it down to one LDR line and the with on thel the " Area, int_func, etc. and the "END" and it still did not work. I am really perplexed. Does anyone have any idea where I am going wrong?
Or should I just give up on Assembly on a MCU?
triad