Walter Banks wrote: > What is actually needed in embedded applications? A decent language. I use mostly assembler for lots of reasons having nothing to do with the high level language tools available. We have pushed toward somewhat higher level programming by use of the MPASM macro capability and by features created ourselves with our PREPIC PIC assembler preprocessor. The few times I might have used a real compiler I didn't because: 1 - They're all (mostly) in C. Standards are good in the right circumstances, but unfortunately also become a refuge for the unimaginative and lazy. Your own company is guilty of this too. C is by far the worst programming language to ever get widespread use. There are just too many things broken in the C definition that I would never chose C for any project of my own accord. I have used C on PICs because the customer insisted on it or I received code in C that would have been too expensive to re-develop. I'm rarely concerned with portability of my PIC code to other platforms, so I'd much rather see a decent language that aids in responsible programming and that was designed for the PIC or small systems in general than something "standard" and ugly like C. The silly thing is that by the time you add the stuff to make C useable on a PIC you've left the standard behind anyway. That means you end up with the worst of both worlds, a awful language that still isn't well suited to the PIC environment. 2 - They don't integrate well with MPASM/MPLAB. I'm always going to have some assembler, so a compiler that doesn't play nice with my large existing library of MPASM code is useless to me. At least with Microchip C18 it is possible to create a mixed MPASM/C18 project, but it's nowhere near as easy as they would have you believe. This is partly due to them making some downright stupid choices for things like FSR use, stack conventions, and subroutine linkage conventions. Of course it can be done and we've done it, but it's not that "nice". We have a C18COMP switch in our assembler facilities and in the build scripts that switches things into the less efficient C18 compatibility mode. Other compilers are even worse than C18 in that you have to use their assembler. That ain't gonna happen. 3 - Aside from C being a awful language in general, it lacks features important on small systems like PICs. There is no seamless integration with assembler (It should be able to read MPASM include files, and the assembler should be able to read the HLL include files. If done properly both would be a single translator.), no understanding of multiple address spaces each with their own limitations and pointer types, no instruction-level timing capability, no built in data types of explicit width (int8u_t, int16u_t, etc), etc. For example, 24 bit floating point makes a lot of sense on PIC 16 and PIC 18, assuming you need the dynamic range. One part in 65K is plenty for intermediate calculations when your inputs are 10 bit A/D readings and outputs are 8 bit PWM duty cycles. 32 bit IEEE standard floating point is just silly in the vast majority of such applications, but yet that's the common floating point format for PIC 16 and PIC 18 compilers. 4 - The few compilers that aren't C have so little use that I don't trust them. Compilers for small systems are buggy enough that I want as many other people using the same compiler as possible. I don't want to be a test pilot, so I'll leave the niche compilers (no matter how nice the language) to others. In the end I'm going to stick to my PIC development environment and MPASM. I can crank out PIC projects using that environment quickly and reliably with very few bugs. Some who don't really understand the issues always say they can develop a project more quickly in a HLL than in assembler. But they are usually comparing artificial projects and not using expert level assembler programmers with a large pile of tested reusable code all within a consistent framework already sitting on the disk. They also usually compare the more algorithmic code where a HLL really does win. But look at most PIC projects and you will see that this kind of non-IO pure number crunching code is very rare. The real work of a PIC project is to first design the architecture to use the PIC capabilities effectively, and then most of the code is in some way related to PIC-specific peripherals or other PIC specific limitations. Something like solving a quadratic equation, for example, is a very very small part of overall PIC code. Even if that part becomes free, you haven't gained much. You'll gain a lot more by embracing the PIC architecture instead of trying to get your tools to work around it, and by getting really good at learning how to use it effectively. I'll probably continue to enhance PREPIC as I wish I had a feature. For those willing to look at PREPIC, you can see that most of its features are not aimed at the kinds of things HLLs generally solve for you on a micro, but mostly at allowing good coding practises that reduce the chance of human error and make it easier and more reliable to change global parameters, while not getting in the way of regular MPASM programming. IN other words, things a really good assembler would have built in. Frankly, everybody should be using PREPIC for assembler projects, if only for the /INBIT and /OUTBIT commands. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist