PCH - Keeping perspective

[Bruce R. Knox]

Hello Everyone:

Today, I am shipping a serious 18F252 application that I have built using CCS compilers 3.075 through 3.078. Though a new CCS user, I’ve got about 25 years experience developing little applications (12C508 style) though large, distributed systems employing PICs/Motorola 68xxx/PCs/VAXes(!) etc.

I can tell you, the “professional” software development tools some of my engineers use for Motorola applications would get you 50 years of support from CCS for what you pay for them…. CCS is not expensive software and “you get what you pay for”. That being said, I am fairly impressed (but frustrated at times) by the performance of this suite.

PICs are not really designed for “C”, and compiler writing is an art form even for processors that are really designed for high level languages. Even though Microchip claims that the 18 family is “C compiler friendly”, it still doesn’t have a stack for passing parameters, and it still has bank selecting (the 68000 in 1979 had linear addressing through 16 Mb and 9 address registers you could use as stack pointers!) What PICs DO have is availability (MOT screwed us many times when we needed parts and they quoted 39 week delivery on a production part because some automotive user decided they needed a few extra parts!). Also, the upward/downward hardware compatibility has saved us a fortune over the past 5 or so years – the design I am talking about here originally had a 16F876 specified – we just dropped in the F252 as requirements grew, recompiled the “slightly adjusted” source file, and kept on going. You just can’t do this with MOT (or any of the others that keep pounding on us to change over to their controller de jour).

To keep the story short, I got up to about 75\% of ROM on the F252 and all things were working fine (with the exceptions noted below). At one point, however, I added a couple of floats, and now printfs with \%ld were blowing up all around the program (wrong characters in the output). Strangely, \%lx would work ok! Worse, the entire program went to “flaky land” – all indications of bank select/pointer problems (it happens in assembler too, folks!).

So, out comes the list file and SFR and FR pages on the emulator (ICE-2000), and lo and behold, I find that I have pushed in to Bank 1 on the 252…. and that the high byte of the FSR0 (new to the 18C parts) was not being loaded consistently. Further analysis showed that certain array accesses were writing in to Bank 0 instead of Bank 1. I was using chars or ints as the array indexes – changing them to longs fixed everything up and I was able to keep going.

Next problem – I was seeing some random things happen. Inspecting the .lst, I found that memcpy was not working right on the 18 part – works fine with the 16 parts, but generates extra instructions (MOVFFs!) that are pretty scary. I fixed this one by writing my own function (in assembler!) that calls like memcpy, but uses FSR1 and FSR2 to do the moving.

In summary:

1. PCH 3.078 seems to generate “big code size” fine (I am now at 86\% of a 16kw part and no observed bugs related to the size fo the program). Watch "large ram size (>256)" when strange things start happening.

2. Number 1 notwithstanding, code generated by memcpy in 3.078 (perhaps earlier, I don’t know) is not good. Don’t use it! If you want my code for the memcpy fix, let me know.

3. Be sure to use 16 bit pointers/indexes for arrays to keep the banking right on array accesses. I have not tried this with an array of floats to see if it will make that work, by the way.

4. Printf works, mostly. When you’re having problems, make sure that you’re using 16 bit pointers/indexes (everywhere in the program!) and try other formats – this has worked for me so far.

5. Even with the bugs, I was able to write a 4000 line application in two weeks (yes, I am tired right now), and I didn’t even own a CCS compiler at the end of February 2002. The application has been tested as we develop, and it is shipping for beta test today.

6. I wrote a little test program that illustrates these problems and sent it on to CCS. Again, the problems are easily re-created with small programs - code size doesn't seem to matter much (yet!).

I have found CCS’s tech support (Mark and Darren) to be quite responsive to telephone calls and e-mails. I hope that the test program(s) they use can be improved to find some of the obvious bugs (regressively, hopefully to minimize breaking things that used to work).

Bottom line - I could not have written this program in assembler in the amount of time I had allotted, and I spent less time messing around with environment problems than I would have debugging an assembler version of the program! And I'm only out $400 (gotta send in that support payment!).

Bruce
___________________________
This message was ported from CCS's old forum
Original Post ID: 3294

[Hans Wedemeyer]

Bruce,
Ever heard of luck....
This is not a personal attack, but my rebuttal to your comment, please keep that in mind when you read on...

I tried doing a PIC18 project last year when the compiler came out of beta.... you think you have problems with floats.... go back to the earlier versions if you want to see problems.

The point is many of use like the CCS approach, but they have some issues.

About your $400.- out of pocket for one project...

Well I've been paying $200 a year for about 5 years now, and could have purchased a different compiler for a lot less, some have upgrades at no cost, most have bug fixes at no cost.

It's false to say CCS is cheap or economical, it is not. If I could buy the product and if it worked then perhaps it could fall into the cheap class.

Upgrades were originally intended to add new chips as microchip produced them, and NOT for paying CCS to fix and break things.

I purchased the PCWH and the product setup wizard is one feature I like. However it does not work for PIC18 parts. So another $200 for a partial product.

You came onto the PCH scene at a time when hundreds of bugs had been fixed, but let me tell you the float and int in printf has been an on going battle for about the last 12 months, and array problems have been around for a long time also.

I have ALL PCWH releases and can easily demonstrate the fact, this is the first compiler where I have to record the Compiler version number in source code and re-install that version if I do maintenance!

I'll say this for CCS they do keep on trying to fix things, and if they did not do that I think peple would move on...

This week I thought I'd try PCH for a new project and things moved along OK for a time, then suddenly the RS-232 interrupt stopped (see my other post) fo no apprarent reason ! Obvisouly there was a reason, but this is a classic case... I move the interrupt routine code in the source and recompiled.... it started working again.. That caught me unawares and I should have known better !

This is not a cheap product when it sneaks in a problem like this, and catches me unaware, and I spend hours looking for problems that don't exisit !... I don't think I should be inspecting the results of the compiler every darn time I compile, that defeats the purpose of the thing. I remember doing that in the CP/M days with early C compilers.... but that was 25-30 years ago.

It is not unreasonable to say
"I expect the compiler to produce working code, it may not be the best code but it should work. "

BTW I ended up moving last years PIC18 project to a Rabbit module and for a couple of hundred bucks I got a dev. kit and stable C compiler.

Thanks for your perspective,a nd I'm happy that you were able to complet your project, just think how much easier it would have been if those memcpy and printf issue were gone !
___________________________
This message was ported from CCS's old forum
Original Post ID: 3295

[Bruce R. Knox]

:=Bruce,
:=Ever heard of luck....
:=This is not a personal attack, but my rebuttal to your comment, please keep that in mind when you read on...
:=
:=I tried doing a PIC18 project last year when the compiler came out of beta.... you think you have problems with floats.... go back to the earlier versions if you want to see problems.
:=
:=The point is many of use like the CCS approach, but they have some issues.
:=
:=About your $400.- out of pocket for one project...
:=
:=Well I've been paying $200 a year for about 5 years now, and could have purchased a different compiler for a lot less, some have upgrades at no cost, most have bug fixes at no cost.
:=
:=It's false to say CCS is cheap or economical, it is not. If I could buy the product and if it worked then perhaps it could fall into the cheap class.
:=
:=Upgrades were originally intended to add new chips as microchip produced them, and NOT for paying CCS to fix and break things.
:=
:=I purchased the PCWH and the product setup wizard is one feature I like. However it does not work for PIC18 parts. So another $200 for a partial product.
:=
:=You came onto the PCH scene at a time when hundreds of bugs had been fixed, but let me tell you the float and int in printf has been an on going battle for about the last 12 months, and array problems have been around for a long time also.
:=
:=I have ALL PCWH releases and can easily demonstrate the fact, this is the first compiler where I have to record the Compiler version number in source code and re-install that version if I do maintenance!
:=
:=I'll say this for CCS they do keep on trying to fix things, and if they did not do that I think peple would move on...
:=
:=This week I thought I'd try PCH for a new project and things moved along OK for a time, then suddenly the RS-232 interrupt stopped (see my other post) fo no apprarent reason ! Obvisouly there was a reason, but this is a classic case... I move the interrupt routine code in the source and recompiled.... it started working again.. That caught me unawares and I should have known better !
:=
:=This is not a cheap product when it sneaks in a problem like this, and catches me unaware, and I spend hours looking for problems that don't exisit !... I don't think I should be inspecting the results of the compiler every darn time I compile, that defeats the purpose of the thing. I remember doing that in the CP/M days with early C compilers.... but that was 25-30 years ago.
:=
:=It is not unreasonable to say
:="I expect the compiler to produce working code, it may not be the best code but it should work. "
:=
:=BTW I ended up moving last years PIC18 project to a Rabbit module and for a couple of hundred bucks I got a dev. kit and stable C compiler.
:=
:=Thanks for your perspective,a nd I'm happy that you were able to complet your project, just think how much easier it would have been if those memcpy and printf issue were gone !

Hans:

Luck? I'd be in Vegas if I had that kind of luck!

I'm not sure that I would have lasted five years in this mode - you make a good point. I just don't see how CCS could do a heck of a lot more for the prices they charge - but now it will certainly be a sticky wicket for them to try to charge more to be able to provide more testing, etc.

On a couple of your other points: I actually don't have any problems with floats (thanks to all that came before for debugging that!). I referred to the array of floats that someone else had commented on earlier. Memcpy and printf? I spent a couple of hours straightening them out. So, overall, not so bad, really.

I'll be using this tool for many more projects... if it continues to get better (at least two steps forward for each one back, anyway!). Time will tell on that.

BTW - I have a couple of really cool products/projects I have done with the Rabbit and Rabbit C - those guys have a few bugs too, but most of those are with the applications they provide (like TCP/IP). If PCWH worked like the Rabbit C compiler, this would be a whole different discussion board!

Have a great day!

Bruce

ps - This Board has been useful for me to know what to watch out for, so, if nothing else, I hope my experiences I described earlier help other avoid those holes, anyway.
___________________________
This message was ported from CCS's old forum
Original Post ID: 3298

[Mark]

:=So, out comes the list file and SFR and FR pages on the emulator (ICE-2000), and lo and behold, I find that I have pushed in to Bank 1 on the 252…. and that the high byte of the FSR0 (new to the 18C parts) was not being loaded consistently. Further analysis showed that certain array accesses were writing in to Bank 0 instead of Bank 1. I was using chars or ints as the array indexes – changing them to longs fixed everything up and I was able to keep going.
:=

I had the same problem. It turns out that CCS does not save the high byte of FSR0 when servicing an interrupt. I had to write my own int handler to fix this.

:=Next problem – I was seeing some random things happen. Inspecting the .lst, I found that memcpy was not working right on the 18 part – works fine with the 16 parts, but generates extra instructions (MOVFFs!) that are pretty scary. I fixed this one by writing my own function (in assembler!) that calls like memcpy, but uses FSR1 and FSR2 to do the moving.
:=

If you look at these instructions you will find that the regs they are using (0xFEF, 0xFEE, 0xFED, 0xFEC) increment or decrement the FSR0.

Mark
___________________________
This message was ported from CCS's old forum
Original Post ID: 3302

[Bruce R. Knox]

:=:=So, out comes the list file and SFR and FR pages on the emulator (ICE-2000), and lo and behold, I find that I have pushed in to Bank 1 on the 252…. and that the high byte of the FSR0 (new to the 18C parts) was not being loaded consistently. Further analysis showed that certain array accesses were writing in to Bank 0 instead of Bank 1. I was using chars or ints as the array indexes – changing them to longs fixed everything up and I was able to keep going.
:=:=
:=
:=I had the same problem. It turns out that CCS does not save the high byte of FSR0 when servicing an interrupt. I had to write my own int handler to fix this.
:=
:=:=Next problem – I was seeing some random things happen. Inspecting the .lst, I found that memcpy was not working right on the 18 part – works fine with the 16 parts, but generates extra instructions (MOVFFs!) that are pretty scary. I fixed this one by writing my own function (in assembler!) that calls like memcpy, but uses FSR1 and FSR2 to do the moving.
:=:=
:=
:=If you look at these instructions you will find that the regs they are using (0xFEF, 0xFEE, 0xFED, 0xFEC) increment or decrement the FSR0.
:=
:=Mark


Mark:

At least in 3.078, all three FSRs are saved locations 0x07 through 0x0c in the RTCC interrupt routine... maybe it's another interrupt that they don't get saved in???

Relative to the autoinc/dec: in my version (3.078), memcpy, with counts up to four (as big a move as I need for this application) generates a bunch of movff (about twice as many as needed and wrong ones mixed in with the right ones) instrux and does not use the FSRs at all. I used those autoinc/dec instrux to implement my own memcpy using FSR1 and FSR2.

Bruce
___________________________
This message was ported from CCS's old forum
Original Post ID: 3310

[Todd C. Micallef]

Just one last tidbit....

Keep a backup of the version you used to ship your product. If you ever have to debug problems or add new features down the road it will be best done with the version you shipped.

You probably already know this, but just a word to the wise....



:=:=Bruce,
:=:=Ever heard of luck....
:=:=This is not a personal attack, but my rebuttal to your comment, please keep that in mind when you read on...
:=:=
:=:=I tried doing a PIC18 project last year when the compiler came out of beta.... you think you have problems with floats.... go back to the earlier versions if you want to see problems.
:=:=
:=:=The point is many of use like the CCS approach, but they have some issues.
:=:=
:=:=About your $400.- out of pocket for one project...
:=:=
:=:=Well I've been paying $200 a year for about 5 years now, and could have purchased a different compiler for a lot less, some have upgrades at no cost, most have bug fixes at no cost.
:=:=
:=:=It's false to say CCS is cheap or economical, it is not. If I could buy the product and if it worked then perhaps it could fall into the cheap class.
:=:=
:=:=Upgrades were originally intended to add new chips as microchip produced them, and NOT for paying CCS to fix and break things.
:=:=
:=:=I purchased the PCWH and the product setup wizard is one feature I like. However it does not work for PIC18 parts. So another $200 for a partial product.
:=:=
:=:=You came onto the PCH scene at a time when hundreds of bugs had been fixed, but let me tell you the float and int in printf has been an on going battle for about the last 12 months, and array problems have been around for a long time also.
:=:=
:=:=I have ALL PCWH releases and can easily demonstrate the fact, this is the first compiler where I have to record the Compiler version number in source code and re-install that version if I do maintenance!
:=:=
:=:=I'll say this for CCS they do keep on trying to fix things, and if they did not do that I think peple would move on...
:=:=
:=:=This week I thought I'd try PCH for a new project and things moved along OK for a time, then suddenly the RS-232 interrupt stopped (see my other post) fo no apprarent reason ! Obvisouly there was a reason, but this is a classic case... I move the interrupt routine code in the source and recompiled.... it started working again.. That caught me unawares and I should have known better !
:=:=
:=:=This is not a cheap product when it sneaks in a problem like this, and catches me unaware, and I spend hours looking for problems that don't exisit !... I don't think I should be inspecting the results of the compiler every darn time I compile, that defeats the purpose of the thing. I remember doing that in the CP/M days with early C compilers.... but that was 25-30 years ago.
:=:=
:=:=It is not unreasonable to say
:=:="I expect the compiler to produce working code, it may not be the best code but it should work. "
:=:=
:=:=BTW I ended up moving last years PIC18 project to a Rabbit module and for a couple of hundred bucks I got a dev. kit and stable C compiler.
:=:=
:=:=Thanks for your perspective,a nd I'm happy that you were able to complet your project, just think how much easier it would have been if those memcpy and printf issue were gone !
:=
:=Hans:
:=
:=Luck? I'd be in Vegas if I had that kind of luck!
:=
:=I'm not sure that I would have lasted five years in this mode - you make a good point. I just don't see how CCS could do a heck of a lot more for the prices they charge - but now it will certainly be a sticky wicket for them to try to charge more to be able to provide more testing, etc.
:=
:=On a couple of your other points: I actually don't have any problems with floats (thanks to all that came before for debugging that!). I referred to the array of floats that someone else had commented on earlier. Memcpy and printf? I spent a couple of hours straightening them out. So, overall, not so bad, really.
:=
:=I'll be using this tool for many more projects... if it continues to get better (at least two steps forward for each one back, anyway!). Time will tell on that.
:=
:=BTW - I have a couple of really cool products/projects I have done with the Rabbit and Rabbit C - those guys have a few bugs too, but most of those are with the applications they provide (like TCP/IP). If PCWH worked like the Rabbit C compiler, this would be a whole different discussion board!
:=
:=Have a great day!
:=
:=Bruce
:=
:=ps - This Board has been useful for me to know what to watch out for, so, if nothing else, I hope my experiences I described earlier help other avoid those holes, anyway.
___________________________
This message was ported from CCS's old forum
Original Post ID: 3311