| View previous topic :: View next topic |
| Author |
Message |
Andreas
Joined: 25 Oct 2004
Posts: 136
|
| CCS Compiler vs Microchip Compiler |
 Posted: Fri Sep 14, 2007 6:31 am |
 |
|
Hello Friends !
I was running in serious business Problems with my main customer because of compiler related software problems. Now the customer is asking me to convert to Microchip C18 Compiler.
Therefore I have some questions to the CCS User community:
1. What are Your experiences with C18?
2. Has somebody some samples for converting CCS C Source to C18?
3. Does it make sence to spend the time in converting ?
4. Any known major problems with C18 ?
I hope some of You experienced users out there can help me on finding a commercial acceptable solution.
best regards
Andreas out of Vienne,Austria |
|
 |
dyeatman
Joined: 06 Sep 2003
Posts: 1933
Location: Norman, OK
|
|
| Posted: Fri Sep 14, 2007 6:40 am |
|
|
In your position I would be asking these questions of the C18 group.
We have folks here that have come from C18. However, logic says that if they went from CCS over to C18 they wouldn't be hangng out here. In either case you may not get unbiased answers... |
|
|
libor
Joined: 14 Dec 2004
Posts: 288
Location: Hungary
|
|
| Posted: Fri Sep 14, 2007 6:47 am |
|
|
You might first want to look at the microchip forum's C18 related topics (4784 topics with 28650 posts) with about the same average ratio of reporting a possible compiler problem...
btw: tracking a bug down to a level to prove it is really compiler related equals to be able to easily debug (work-around) it as a by-effect. ...so I see some contradiction about 'customers complaining about compiler-related bugs'. 
Last edited by libor on Fri Sep 14, 2007 6:59 am; edited 1 time in total |
|
|
Ken Johnson
Joined: 23 Mar 2006
Posts: 197
Location: Lewisburg, WV
|
|
| Posted: Fri Sep 14, 2007 6:48 am |
|
|
What version are you using?
What problems are you (your customer) seeing?
Ken |
|
|
Andreas
Joined: 25 Oct 2004
Posts: 136
|
|
| Posted: Fri Sep 14, 2007 7:24 am |
|
|
Hi,
I am now using 4.053 which looks quit well, but the problem I had with my customer is now about 5 to 7 month ago compiled and unfortunatly i couldnt remember which version I used, but I think it was one of the first V4.xx versions.
The problem I discovered is that I am using a pointer to a NV Ram which has also clock registers in the same Memory area and suddendly it happend that the pointer was incremented twice and therefore missed the reset condition and the pointer got incremented into the Timekeeper registers and destroyed the Clock --- no more correct Datalogging was possible.
I know now it would have been better to make the reset condition more flexible - but this software part was running without problems for more than a year already - so I had no chance to see a leak there.
Now I recompiled with 4.053 it runs - but I really dont know how test for weak conditions ???
Many thanks for the lot answers
Best regards
Andreas |
|
|
Ken Johnson
Joined: 23 Mar 2006
Posts: 197
Location: Lewisburg, WV
|
|
| Posted: Fri Sep 14, 2007 8:07 am |
|
|
Note that V4 treats pointers per "standard C", whereas V3 always treated 'em as byte pointers (I think). What type is the pointer target?
Ken |
|
|
Andreas
Joined: 25 Oct 2004
Posts: 136
|
|
| Posted: Fri Sep 14, 2007 1:29 pm |
|
|
Hi Ken !
I am not using a "standard Pointer" as in C, what I meant was that I am using a variable which will be autoincremented at each write function to the RAM.
here is a sample:
| Code: |
RTC_write(NVRAMBuff++,inport[0]);
RTC_write(NVRAMBuff++,inport[1]);
RTC_write(NVRAMBuff++,inport[2]);
RTC_write(NVRAMBuff++,inport[3]);
RTC_write(NVRAMBuff++,Hours);
RTC_write(NVRAMBuff++,Minutes);
RTC_write(NVRAMBuff++,Seconds);
RTC_write(NVRAMBuff++,mSec);
RTC_write(NVRAMBuff++,Date);
RTC_write(NVRAMBuff++,Month);
RTC_write(NVRAMBuff++,Year);
RTC_write(NVRAMBuff++,Cksum1);
if (NVRAMBuff == 0x80)
{
Read_RTC_Parameter();
NVRAMBuff = 0x20;
............................
|
Now You have to know that the RTC has a RAM Area starting from 0 to 0x1e which belongs to the internal Clock functions like regiser for second, minutes, hours and so on.
User Area starts around 0x1e until 0x7F.
So my Counter NVRAMBuff will be initial set to 0x20 then autoincremented until it reaches 0x80
So my opinion is now that it may be that in some circumtances either the check for ==0x80 fails or the autoincrement before fails sometimes.
But You must also know that I have about 50 Units in the field with the same sourcecode but compiled with versions 3.XXX and no such problem at all.
Thats now the reason why I was tending to belief that it could be one of the very hidden compiler odditie.
Thanks for Your Ideas !
best regards
Andreas |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
