On 2007-10-16 14:58:24, Matt Pobursky wrote:

>> I don't do a lot of work with MPLAB, so can't say how well the
>> integration works.
> 
> Just out of curiosity, how do you debug your applications? 

Usually some form of in-process output, like prints to a serial port or pin
toggles. Most of the code I write depends heavily on outside interaction,
and simulating this appropriately would be too much work -- and running the
code without it just would get it into some kind of "limp home" mode :) 

I generally develop code for smaller devices in a bigger device until it
all works (more comfortable, debugging-wise; I can just throw prints, even
printf's in as much as I need), then I port that code, now functionally
already running and tested, to the smaller device. Since I already write it
with the porting in mind, that's usually very little work -- and probably
much less work than trying to debug on a small device.


> (Last I checked HiTech PICC didn't have an integrated IDE debugger. I was
> a Hitech PICC user but debugging was painful under MPLAB. 

FIWI, they are integrated, with that MPLAB plugin system, and it seems it
has improved compared to a few years ago. But if you don't like MPLAB, that
doesn't help :)


> Not doing PIC16 and PIC18 with the same compiler was also a killer for
> me)

I'm using HiTech's PICC and PICC18, and even though it's not the same
compiler, it is pretty much the same -- so much the same that the above
technique to write and debug code on an 18F device that is ultimately meant
for a 12F device is easily possible.


> For us there are a lot of "pros" to the CCS PICC tools:
> 
> 1) All families of the PIC with one compiler. 

For me, that's a non-issue. Whether I have to call a different exe doesn't
matter all that much. The compilers are otherwise compatible enough.

> 2) MUCH, MUCH better source level debugging than MPLAB. [...]

Can't comment on this topic, but what you say sounds reasonable.

> 3) Cost is reasonable. No forced maintenance, you can pick up maintenance
> anytime even if your current maintenance has lapsed.

Cost is higher for HiTech, but "picking up" maintenance is also possible.

> 4) Produces reasonable code. 

I'd say that goes also for HiTech.

> 5) Very good peripheral libraries. 

Probably a point for CCS in this comparison. There's not all that much for
HiTech compilers.

> Part of the issue with CCS and their bugs is that they do a tremendous
> job of "compiling around" silicon bugs. They incorporate as many
> software fixes to errata problems as they can and given the number of
> PICs and their errata this is a daunting task. 

Well, HiTech also does that -- any decent compiler needs to incorporate
erratas that affect code generation.

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist