On Mon, 16 Apr 2007 11:06:41 +0100, Mike Harrison wrote: > And features like 'trigger out' when certain instructions get executed > can save an awful lot of debug time... Yeah, I almost forgot about that -- hardware triggered hardware triggers! An excellent resource for triggering your 'scope or logic analyzer on the one condition that occurs only once in a blue moon while swinging a dead cat... ;-) >> Interesting, I find just the opposite. I rarely use a simulator, maybe >> once or twice a year for a given MPU family. Most (90% ?) of my >> debugging is with hardware hooked up to real world devices debugging >> those processes, not the hardware independent aspects of the software. >> > I have never used a simulator - most embedded projects are so dependent > on outside stimulus which is hard/time-consuming or impractical to > simulate. Same here. In fact I can't remember the last time I used a simulator. It has to be at least 18 months or more. If I do use one, it's generally for something like a math/filtering algorithm that truly is hardware and outside stimulus independent. It's funny but even though I do quite a bit of analog design, I find myself using SPICE simulation only occasionally as well. >> I currently develop with 6-8 different MCU families and will freely >> switch from one to another when it fits the project. When I'm looking at >> a new MCU family, the first thing I look at is whether it has a good C >> compiler, relatively non-intrusive on-chip debug facilities and a good >> IDE debugger (tightly coupled with the C compiler). >> >> As much as I like PICs, I think the available PIC tools are making a >> slow slide downward versus what's available for a lot of other chip >> families. The ICSP/ICD methods Microchip uses are getting a bit long in >> the tooth and I'm finding it harder and harder to work around some of >> their warts. >> > I'm surprised at this comment - I certainly agree ICD can be somwhat > primitive ( no WDT - er... hello?), and being an early starter in the > market, ICD is showing its age, but MPLAB ICE2000 is streets ahead of > most other offerings on similar-class micros - 'proper' ICEs like this > are becoming a rarity these days - Atmel seem to have abandoned their ICE > range, although Debugwire/Jtag work reasonably well as long as you use > them with something less flaky than the dreadful AVR Studio. Speed and > packaging issues mean that we are probably seeing the end of 'real' ICEs, > so the limitation of on-chip debug systems will be an increasingly > important factor. I was really just referring to the ICSP/ICD interface. The ICE2000 is a fine piece of kit. I wish more manufacturers made decent emulators. The ICE2000 is reasonably priced too, for what you get. 3rd party emulator makers are in a tough situation -- it takes enormous resources to develop and maintain the hardware and software for an emulator family and they'll never sell more than a few 1000 of them (if they're lucky). They also have to worry about manufacturers dropping a chip family at any time and also about whether they'll be able to get "bond-out" chips for the pods, etc. We use AVRs, MSP430s, various flavors of ARMs and a few other families as well as PICs in our designs. Right now, the least problematic tools are the MSP430 and ARM tools. They cause us the least grief in hardware and have the best debuggers. We're using Rowley Associates Crossworks for the AVR and it's *so much better* than AVR Studio it's not even a comparison. We also use their ARM tools and they are equally excellent. We'll probably switch to their MSP430 tools at some point as well. My biggest gripes with the PIC ICSP/ICD interface is with low voltage programming and sharing port pins with the ICSP/ICD interface. The trend with other manufacturers seems to be add more pins and use dedicated OCD/programming pins. I like this trend. I do almost all SMD designs for several years now and adding 3 or 4 pins at .5mm or .65mm pin spacing is not a big space issue for me, even on the smaller packages. Working with PICs at 3.3V or less is also a pin. We all know about no bulk erase below 4.5V. I won't add extra hardware to make my boards 5V tolerant or jerry rig the power to the PIC just because the flash process is old or the on-chip charge pumps can't make programming voltage at 3V. I really hope they improve these things with the newer PICs of the future. I also have issues with MPLAB (much like AVR studio but for different reasons). C Source level debugging under MPLAB is kind of primitive, especially with 3rd party compilers. And since Microchip only has one "ok" compiler (C18, if you are using a 16F you are SOL), you're likely going to be using a 3rd party compiler. I gave up on MPLAB for my PIC 16F and 18F applications and use CCS C and their IDE/Debugger now since it covers both 16F and 18F families and the compiler and debugger are tightly coupled. FWIW, I like the ICD pods from CCS better than Microchip's ICD2 also as they are a lot smaller and only cost $75 each. They also supply a free standalone programming application so for $75 I can setup a programming station for clients or a production line. >> I doubt I'll ever go completely away from developing with PICs but they >> certainly aren't the easiest to develop with anymore and usually not my >> first choice, all things being equal. >> > All things being equal, I still tend towards PICs, for the sole reason > that I have a proper ICE, which can easily save days of dev time, and > MPLAB is solid and reliable. I guess my main point was that with many of the newer chips I'm finding less of a need for a hardware ICE. The MSP430 and ARM OCD functions are pretty nice, I really like developing with them. Hopefully Microchip will improve on their debugger and programming interfaces and not cling to basic designs that were done in the late 90's... Matt Pobursky Maximum Performance Systems -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist