Comments please on bug reporting

[XXXXXX]

Could someone out there comment.
I have been using an old version 3.xxx compiler with good success because the newer 4.xxx ones were more buggy. I basically wasted a year's support money because the newer compilers and IDE were worse that the old one. Can anyone out there tell me if the new version is any good , before I pay for support again.
Also what is the best way to report bugs , and get a response. I tried to report a bug in the PIC16F88 write_program_memory function today and was told to "email it in and they would look at it when they have time".

Is there official support at CCS? Is customer service OK?
As this bug was stopping me working I actually had to write the function myself.
Just looking for user feedback.
thanks

[Douglas Kennedy]

There is pressure on the CCS compiler from two sources as I see it. One is Microchip introducing new devices and even whole new families like dsPIC. The second is the silicon is often better served with a limited version of C but C programmers can be and often are purists and pressure for standard C occurs. The compiler can be viewed by some in C terms alone in which case the absence of C features becomes a reason to reject it. I have only looked at the demo version of V4 but I suspect adding C driven capability such as overloading pointers to constants pointers to functions etc is much the cause of the delays and lack of robustness. The other issue is tinsel (IDE fluff) which further adds to mission creep. No doubt C features and tinsel sells but it is robust compiler engineering that keeps a compiler out of the repair shop.
CCS versions very quickly and V4 is at 50 right now my guess is there are about 50 more versions to go before compilation is robust. Before it becomes robust new versions can bring the value of finally getting something useful. After it becomes robust new versions can bring the result that something useful gets messed up. I see the compiler as value when it robustly supports silicon. Functions to support hardware I2c SPI UART etc trump C purity and IDE tinsel. The business decision is complicated by that fact that the CCS pricing has special weighting between maintenance and outright cost.
An unfinished ( not robust) compiler demands a lower cost and CCS wants to make up the lower initial cost in a lifetime maintenance revenue stream. This causes late adoption of new compilers by existing customers as they can view maintenance as paying CCS for the privilege of being a beta tester. With no price break for early adopters waiting saves money and time unfortunately CCS Marketing may fix this with price increases for late adopters. The right answer for all is in early robustness but that requires project management, limited scope and avoidance of mission creep.

[Ken Johnson]

I've been called many things, but . . . now, a purist?

re: Standards! I must disagree with Douglas. When one works with several different micros, and thus several different compilers, it can be very wasteful trying to remember who does what and how, with constructs that should and can be standardized. An example is CCS older implementation of pointers - always byte pointers. There is no reason for this deviation from the standard.

On the other hand, the pic stack implemtation certainly imposes serious limitations on a compiler, and CCS support of chip-specific features is highly commendable. We really get a lot for a few hundred bucks

So, my opinion is that adherence to the ansi standard should be top priority, and that any non-compliance, including (very necessary) extensions, be fully, emphatically documented.

Oops - now to answer the original poster's question:

CCS is very good at support (although currently overwhelmed). I don't think there will be any more upgrades to the V3 compiler - V4 is the product now. From my (limited) experience, pcb, pcm and pch work pretty well. PCD still needs a lot of work. If you find a problem, report it to ccs (email), including a small project demonstrating what is wrong. They are indeed good at responding, offering a temporary work-around, and fixing things. Work with them, support them, and they'll support you.

'nuff said
Ken Johnson
Software Engineer

[Jim Hearne]

I've reported several dozen bugs to CCS via email, mostly genuine (occasionally me) and the response varies greatly from nothing at all to quite comprehensive replys, help and even thanks.
I suspect it probably depends on who actually gets assigned it at thier end, i notice the replys are never signed so i don't know how many people there are doing support at CCS.

They are currently putting the prices of everthing up which is a bit of a cheek with the state of version 4 which has only been usable since version 4.3xx.
And it still has frequent broken versions (including the latest v4.050) where they obviously have introduced more bugs fixing something else.

Jim

[treitmey]

I've seen simular issues.

[Douglas Kennedy]

There are always different ways to view things and if Ken is a purist I think that is admirable. If I'm right CCS seemed to focus on supporting silicon from Microchip. The trade was you could at low cost write in a limited C ( an advantage to me over assembler) and get something useful done with the silicon. I never truly divorced the assembler often using the lst file as window into the accuracy of the compiler. V4 seems to me to be a lot to do with language features and less priority on supporting silicon. The higher language features I suspect will make the assembler validation less efficient. This is branching away from low cost pragmatism. This is fine but it has consequences. I'll guess that nobody at CCS has the true number that represents the cost of say adding pointers to constants but you can bet whatever extra time and money it took it will be reflected in their business plan for V4. The issue this presents for me is that the silicon has changed and V4 is CCS's way of supporting dsPIC silicon. That means I get C features I was doing fine without but at the expense of a very long delay in supporting dsPIC that I really could use and at the same time they rain on my parade by not continuing support for v3 in which I invested in a long learning curve. Some perhaps many will love the features but if at the end of the day the features aren't reliably flashed into the PIC device was it all worthwhile? I believe CCS struggled with V3 have they now learned the project skills to handle a more complex V4?

[Jim Hearne]

Some bugs they just don't seem to want to fix.
I've reported the inconsistant search and replace and the faulty text formatting bugs in several times since ver 3.something when they introduced them but they are still there and rather annoying.

Jim