From PCH to C18 porting

[Guest]

Hi all, after 120-150hrs spent identifying and working around PCH bugs over the last year, II've hit another serious one and one of my clients will spend the $ for C18 to keep her project moving forward.

If anyone has advice on doing ports to C18 pls. let me know.

It is very unfortunate but I have hit literally 20+ bugs that have wasted 1 to 30 hours on per. This makes it impossible to predict development time and therefore impossible to make a living with the PCH compiler.

While I prefer to support "the underdogs" at this time I'm making about $4/hr on this project b/c of how serious and pervasive the bugs have been.

I have about 10,000 lines of code to port, I use timers, I2C, a/d and serial. Not much with interrupts.
I haven't looked at C18's hw support yet.

Jesse

[PCM programmer]

Mark would be the one to ask about C18 issues. He uses it
instead of PCH. For some reason he's not on the forum lately.
Click on the Memberlist link at the top of the main forum page.
He's member number 14. You can email him from there.
-----------
I am curious about your 20 bugs. At our company we've just
finished doing a large project using PCH and 18F458 PICs.
We started out using vs. 3.178, and then switched to 3.188
because it fixed the "access violation during COFF generation" bug.
That was only an annoyance anyway, because you could
work around it by turning off COFF file output.

But the key point is, I didn't do the coding for this project.
A co-worker did it, who had no experience with CCS at all.
And it worked ! I had always thought that you had to be
ushered into a secret society to use CCS (at least somewhat).

He asked me a few questions about the pre-processor statements,
and I think he found out for himself that CCS doesn't automatically
promote variables when you mix data types in an expression.
(Even though K&R says the compiler should do this, you have to
manually cast them yourself with CCS). But other than that,
he just went at it and wrote tons of code, and pulled several
all-nighters, and it all worked. I was sort of surprised.

But you've got these 20 bugs that have absolutely demolished you.
I would like to know what version of PCH you're using and what
PIC you're using, so I can stay away from them.

But with regard to your problem, emailing Mark would be your best bet.

[Douglas Kennedy]

Everyone's experience will be diferent . With the 18XXXX I have to suspect the silicon as often as the compiler when there is an issue. It's sad but I believe nothing is tested at Microchip and any chip that is recently available is a best a beta version. This was never true of the 16xxxx.
Silicon errors are very serious to the customer....compiler errors though bad can often be identified within the lst file and corrected or worked around. With silicon errors you are on your own until often belately Microchip fesses up. Even then there is no such thing as a recall or a replacement effort from Microchip. I still can't to this day understand how the 18F452 addressing above 4000h issue got into our world. The major purpose of this chip was to expand the rom so Microchip not testing it in the expanded address area is at best incompetent and at worst malicious.
It may be worth considering moving to another chip Ex AVR since you will be buying a new compiler anyway.

[Haplo]

I'm also interested in the bugs you are experiencing. I agree CCS has bugs, but seeing 20+ bugs in the same projects is a bit unlikely. My experience shows %80 of the time bugs are actually mistakes made by the coders.
If you want you can share your bug list with us. We may be able to tell you how to avoid them/work around them.

[Guest]

Well seeing 20+ bugs in one project is unlikely, but this project has been a year long (not full time) and is actually two related things.

The problems I have are not related to microchip errata, which is pretty distrubing in its own right. It is to CCS credit that they seem on top of things and put in mchip's suggested workarounds when possible.

I've used the 242,442,452,6720 parts.

Keep in mind that over a year ago when I started the compiler was on revision 3.112. So there have been 75+ updates since then. Look at the list of problems they have fixed. And of course their one-liner descriptions don't tell the full story.

Part of the reason I chose CCS was the linux version. Well, guess what. There is 1 guy who does the linux stuff. I had to call and email numerous times to get new versions. One time I got a debug build and a huge compiler state log file was produced each build. Another time I discovered that the last 3 linux releases were actually all the same code - the only difference was a timestamp in the executable. Their build had been silently breaking for 2 months and they didn't notice. The linux version also emitted the wrong line #s for errors, b/c they don't handle the cr/lf vs cr linux/windows difference properly.

So finally they gave me a windows license b/c they couldn't get their linux build functional. Is this something you want from a vendor you need for production work?

Bugs.

Well they have been large and small. The largest was a problem with a static array that was 3K in size, only the first 200 or so bytes were correct when indexing through it. This was DSP startup code for an mp3 chip. So, the chip didn't work. But there were many other things that could go wrong, all sorts of settings in the chip have to be right, as well as the hardware around it. It took more than 30 hours of hair pulling to finally track this down. I was almost ready to redesign with a new chip.

The current showstopper is a problem where the statement: x = struct1->pNext->someField fails if pNext is in a different 256-byte bank than struct1. This was happening in some complex code that reads fragmented fat12 filesystems, that are rife with trickyness in their own right. Again its been 20+ hours to diagnose b/c of the subtly of this case - same code would work in other tests, just depending on how things got allocated. I just spent several hours at a client site reprogramming boards to avoid this bug. I sent a test case to CCS thursday, no response.

Problems like the non-automatic promotion another poster mentioned still bite me, since CCS says "We're not ANSI" they give themselves license to implement however they'd like, but it means a lot of pretty generic code won't work. And there isn't even a warning about it. And other small things like function prototypes not matching if the name of the argument vars is different - not the types, the names, which are optional. malloc() exists but is totally broken. Samples given don't compile, or at least they didn't when I first got the compiler. Support for high-priority interrupts is nearly useless, since the compiler won't put in code to save its internal state RAM, much less the PIC registers, so you have to code it all in assmbly or look at the compiler output and try to puzzle out what you have to save for whatever C you wrote. I2C using software was broken a few versions back at least, I switched to hardware and all my problems went away. "#opt" (in linux anyway) would crash the compiler. "#error" would crash the compiler. For awhile address of a struct in an array of them failed, so I always had to make a local copy of the struct, do address of it to call a function, and copy changes back. Mysterious problems with single-stepping code in MPLAB, line numbers not matching up, variables not found or wrong type, etc. This may be MPLAB, or the ICD2, or CCS, I can't say for sure. Turning optimization completely off has helped, and MPLAB has had a lot of upgrades, and things are better but still not nearly perfect. The tutorial for using MPLAB is still for version 5.x and doesn't mention anything about how optimization affects things and where to set it.

These are the things I remember off the top of my head. There were quite a few more over the last year.

It is apparent that QA is pretty minimal, so many of these things could be caught with a good test suite, and most importantly caught before shipping the compiler to people trying to make a living developing hardware. The fact that many of the releases fix regressive bugs is telling.

All this matters much less if you are a high-end hobbyist, and a robot you're making won't be ready for a monthly enthusiast's meeting. But if projects are late, my clients don't pay. I have rent to pay, a reputation I'm trying to build (this business is 75% referrals), and I don't want to work most weekends or apologize for the 7th time that a deadline will be missed.

The compiler for 16F parts has gotten good recommendations by collegues. Nobody had used the new 18F version. So, 188 releases since the first one, things are obviously much better, but I have to pull the plug at some point, and it should have been long ago.

Jesse

[PCM programmer]

After reading your post, I think maybe it does take the secret society
(to use CCS).

Most of my reaction to your problems is "mmmm.... I wouldn't do
that...".

Examples:

The Linux compiler. CCS's main effort goes into the Windows compilers
and it just seemed to me like "too much" for them to produce a Linux
compiler too. When I saw them come out with that version, I had
a feeling "do they really have the resources to do this ?"

The 3 KB ram array. CCS's experience was initially limited to at most
a 96 byte array in a 16F877. If someone came to me and said, "Can
I make a 3096 byte array ?" (in PCH, let alone Linux PCH), I would
have expressed caution.

You should have asked us. I have the gestalt of years of reading this
board, and so it's more like I have feelings of where to be cautious and
when not to push the envelope.

x = struct1->pNext->someField. That is a fairly complicated structure
reference for CCS. I would have limited it to only one level of
indirection. I mean, just to be safe.

I think CCS can produce production code, but you have to use the
Windows version, and you have to back off on constructs that would
work fine with MSVC++, but are too much for this small embedded
compiler. I don't know how you would learn this without explicitly
asking us users about it.

I know you want to go to C18, but C18 has its own limitations.
One user came on here and asked about it, and was told that it
doesn't have a printf function. Then he bought it and came on
here again, and loudly complained about this. All we could do
was look at him and shake our heads in astonishment.

As I said, if you're going to C18, you should email Mark and get
his opinions. Also do a search on this board for C18 and read the
posts. There is a review of PIC18 compilers here, written by Trampas:
http://www.ccsinfo.com/forum/viewtopic.php?t=1773
Based on his post, C18 might well have caused you as many problems
as the Linux PCH. I'm not sure what to say. Except, use caution with
embedded compilers, or maybe it gets better if you spend a whole lot
more money ? I don't know.