On 10/18/07, William Chops Westfield wrote: > I have to admit that I feel pretty uncomfortable about the current > crop of ARM processors (for example) that provide a C library > for accessing the various peripherals on their chips, and not a > whole lot else. Which C Compiler vendor does this? I do not think any of the leading ARM C compiler (Keil/IAR/etc) providers provide a C libraries for accessing the various peripherals. Often it is the MCU vendors who did the job by providing a firmware framework. ST is a good example. > It reminds me of the time I typed in a copy of 8085 > Forth, ran it through my homemade > assembler, and tried to run it on my homemade 8085 simulator. > It didn't work (of course?) and I was faced with the daunting task > of figuring out WHICH piece of software was broken. Simulator, > Assembler, transcription, or the original published source? If you > write in assembler, and write all the code yourself, you at least know > that any bug that exists is in YOUR code. Having to debug someone > else's library, or someone's compiler, when you expected to have > them "just work", really sucks. That is why you pay for a good C compiler. And you make your own libraries. Often this will be based on some existing libraries (eg: newlib for ARM7 MCUs) and the vendor supplied libraries. > (Of course, it's like code efficiency in compilers vs assembler. 95% of > the time it doesn't really matter. Hopefully. Because I REALLY, REALLY > want the 20% of the project that is "difficult" (and takes 80% of the > time) to be resolvable by me doing clever things in the right places, and > NOT by hunting down someone elses bugs.) I think if you go to ARM, code efficiency is often not the issue and very few will write the code in assembly. Portability may or may not be a big issue. Code maintainability is much more important issue here. Xiaofan -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist