Hi, Don't get me started.... ;-) I've always regarded "C" as more of a "high level macro assembler", I personally don't regard it as a high level language as such - sort of a halfway house. Now, if you understand how C "works" (read K&R a few times as a start) and the intimate details of your target hardware then you can do a passable job. The problem is, most programmers nowadays simply don't have that level of knowledge, which inevitably leads to large, slow, buggy firmware which is nigh on impossible to fully debug. And then there's the issue of readibility. I don't care what anyone says, I find assembly language listings VASTLY easier to understand than someone elses' "C" code no matter how well commented/documented (even when I've never encountered that particular processor before). I'll give you a personal example. I was once tasked with converting a real time OS from Z8 assembly language (yes, Z8) to V50 (x86) assembly language; we're talking a lot of code here, the assembled code filled almost an entire 32K EPROM. Took me about three and a half weeks, at the end of which I had a well structured, fully documented and FULLY DEBUGGED (I took a LOT of pride in never releasing code which was less than 100%) product which was cleared for production. Unknown to me at the time, initially at least, my boss also tasked our "C" programmer to do the same job. He did the conversion in about two weeks....and then spent the next TWO MONTHS trying (and failing) to track down the bugs in his code, about a third of which were caused by compiler bugs rather than something he'd done wrong. I was eventually brought in to help him, at which point I learnt rather a lot about how bloated and inefficient the output from "C" compilers can be. Needless to say, it was impossible for us to fully debug his code (or fit it into a 32K EPROM for that matter) and so it was dropped in favour of mine. "C" certainly has it's uses (I'm sure), but in my opinion, embedded systems/device drivers isn't one of them.... TTFN - Pete.