View previous topic :: View next topic |
Author |
Message |
dvsoft
Joined: 28 Nov 2003 Posts: 46
|
3.207 Bug !! |
Posted: Tue Aug 10, 2004 2:42 am |
|
|
Part of my code
Code: |
//---------------------------------------------------------------------------
// Configuration Register
//
typedef struct {
int16 Channel10Hz; // 10Hz enabled Channels
int16 Channel25Hz; // 25Hz enabled Channels
int16 Channel50Hz; // 50Hz enabled Channels
int16 StartValue; // Start Logging Value
int16 DTF_Prefixe; // DataFlash Page Prefixe
int8 StartRegIdx; // Start Register Index
int8 CaptureCfg; // CCP1,CCP2,LapTop Config
int8 LoggerID; // Logger ID
int8 Dummy; // 16/8 Bits Padding
}TCfgRegister;
//---------------------------------------------------------------------------
// Union Cfg register
//
typedef union {
int8 Map[14]; // int8 Register Table
TCfgRegister Regs; // Structure Register
}TUCfgRegister;
//---------------------------------------------------------------------------
// Register Map
//
TUCfgRegister CfgRegisters;
.......
int16 ChannelToRecord;
......
//---------------------------------------------------------------------------
// Timer2
//
#int_TIMER2
Timer2_isr()
{
//--- Time System
MilliSecondeCnt++;
//--- 1 Seconde ?
if (MilliSecondeCnt > 999) {
MilliSecondeCnt = 0;
SecondeCnt++;
}// End IF
//--- Recording Flag at 50 Hz
Flag50HzCntDown--;
if (!Flag50HzCntDown) {
Flag50HzCntDown = CNT_50HZ;
:IF y use this code the compiler crash without error message
ChannelToRecord = CfgRegisters.Regs.Channel50Hz;
}// End IF
......
}
|
PIC18F452 Compiler 3.207
with option #opt 10 Grash
with option #opt 5 Grash |
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Aug 10, 2004 4:07 am |
|
|
In the revision history for v3.207: Quote: | 3.207 A bug involving some constant array references in an ISR is fixed |
Is this another example of solving one bug, created another one? |
|
![](templates/subSilver/images/spacer.gif) |
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Tue Aug 10, 2004 6:13 am |
|
|
Sorry guys. It's all my fault. I made the switch to another compiler (C18) due to all these sorts of bugs. Just yesterday, I needed to do some work on a new product I decided to give CCS another shot (mainly because it's a 16F part). I guess I jinked it again
BTW, when will CCS give module level compiling implemented! It sucks to have to redo all my code because of it. |
|
![](templates/subSilver/images/spacer.gif) |
dvsoft
Joined: 28 Nov 2003 Posts: 46
|
|
Posted: Tue Aug 10, 2004 6:43 am |
|
|
hello has all.
I think that it is not a bug compiler
I made another test which this compiles without problem
I think that it is a problem of definition of name of variable
Code: |
typedef struct {
int16 Channels10Hz;
int16 Channels25Hz;
.....
} TCfg;
typedef union {
int8 Map[14];
TCfg Reg;
} TUCfg;
TCfg CfgReg;
#define Channel10Hz CfgReg.Reg.Channels10Hz
may be name space error ?????
|
Sorry for my bad English
Alain |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Tue Aug 10, 2004 7:01 am |
|
|
Mark,
Sounds like you are like me. I have a love hate relationship with CCS.
CCS does a really good job with code optimizations. However it is not quite what one would expect from a real compiler. That is it lacks:
Allowing more than one C file in a project, other than hacking...
Does funny type definitions like, int is not signed but unsigned.
Rather than libraries features like delay functions and printf are compiler implemented.
Error reporting is not so great yet, especially errors like leaving semi-colon off a function prototype.
Compiler is often released with lots of errors which causes developers to spend hours and hours debugging valid code.
I think CCS grew up as being a great compiler for little PIC processors, however with the PIC18's and the dsPIC the compiler is going to have a hard time with it's history. That is as developers like me get to where you have almost 6K lines of code the compiler starts breaking down. That is each release of the compiler breaks something different.
So then you stop and think I will go and use the C18 compiler, pretty soon you are cursing that compiler as the code is not optimized nearly as well as CCS. Then you find that they did not implement a printf function and spend weeks writting one. Then you start getting it to compile code and start writting all the other functions like delay routines, etc. Finally you get code and realize the compiler optimizations are not good enough for your application.
Thus you say, well I will give CCS another shot and the next thing you know you are faced with porting your code and cursing again. You start looking and saying "Why the heck did CCS not use bit feilds and unions like the C18, it is a lot cleaner and easier than bit_clear, bit_set, etc." Then you start looking and saying, why doesn't CCS allow multiple C files, and the reason is history and optimization.
The net result is that CCS has it's good points and bad, C18 has it's good points and bad. Personally I think CCS is better than the C18, it would be great if they would fix a few things, especially their testing before release. Nothing is more frustrating than having your code broken because of the compiler crap shoot. Even worse is when the code runs with one of your bugs and then broken in next compiler release. Now you have to spend hours figuring out is the bug the compiler or my code, and well why did it work before...
Personally I am to the point where I am about to say "to heck with Microchip" that is with all the problems with compilers I am about to the point where even though Microchip has good silicon, with out a good code generation method the silicon is worthless. Last year I tried a project with Microchip and ended up swapping processors due to speed and compiler issues. The PIC18 is such a perfect fit that I hate to change processors for stupid compiler issues...
Trampas |
|
![](templates/subSilver/images/spacer.gif) |
Darren Rook
Joined: 06 Sep 2003 Posts: 287 Location: Milwaukee, WI
|
|
Posted: Tue Aug 10, 2004 10:38 am |
|
|
Trampas,
you need to update your C compiler comparisons. I remember you wrote a pretty good one a few years ago, but it was missing a few things. I think it would be a good read for all. |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Tue Aug 10, 2004 3:42 pm |
|
|
Is it Trampas as in Trampas Stern? Our old pal. Welcome back. I thought it might be a different Trampas since you seem to have fewer complaints now. |
|
![](templates/subSilver/images/spacer.gif) |
Darren Rook
Joined: 06 Sep 2003 Posts: 287 Location: Milwaukee, WI
|
|
Posted: Tue Aug 10, 2004 3:48 pm |
|
|
I'm pretty sure it's him. I don't remember him complaining that much, and at least he was being constructive.
However, there were some people here who had a mission to make me (and anyone else at CCS) feel like a small, little insignificant man. |
|
![](templates/subSilver/images/spacer.gif) |
bdavis
Joined: 31 May 2004 Posts: 86 Location: Colorado Springs, CO
|
|
Posted: Tue Aug 10, 2004 8:49 pm |
|
|
I think it would be great if you wrote a compiler comparison - most are out of date, and if you have experience with multiple compilers, you could do a fair comparison. |
|
![](templates/subSilver/images/spacer.gif) |
Trampas Guest
|
|
Posted: Sat Sep 04, 2004 8:54 am |
|
|
Yeap,
It is me and I am cursing compilers as usual. I guess I need to update my compiler comparisions.
Right now I am using the CCS compiler as that my last project using the PIC18F8620 uses something like 98% of the code memory. Thus CCS optimizations are needed.
However I also find that some things in CCS just frustrate me to no ends, for example code works in version of the compiler and breaks in the next. Then often your code will grow large to avoid compiler features, like not allowing pointer to functions or recursive function calls.
I would suggest that CCS might consider asking for help with their code verification and support. For example CCS could offer virtual points for code which is able to self check operation. That is have some code which runs and verifies result. Then CCS when doing a new release of compiler could have an automated test system which compiles and runs all these code examples. If they fail, then CCS would know they had a problem.
I would also suggest that this idea be taken to the next level which is to have actually hardware which code runs on. Then the verification can be done by running code on hardware an verifying operation.
I know that in the PCH 3.207 the sprintf rountine did not appear to work correctly, but in 3.209 it appears to have been fixed. From reading the change log I could not tell if the sprintf was fixed or not. So I am left hoping that it was fixed an will not break in 3.210....
Trampas |
|
![](templates/subSilver/images/spacer.gif) |
bdavis
Joined: 31 May 2004 Posts: 86 Location: Colorado Springs, CO
|
|
Posted: Sat Sep 04, 2004 10:37 am |
|
|
I really like the CCS compiler, but do wish they would at least post known bugs as soon as they find them. People spend countless hours debugging something that the compiler broke, but CCS did not disclose. I think the PIC compilers have more work due to the number of different chips they support. I would think CCS would have a at least a couple hundred PIC chips networked for regression testing with different FW on each one, and different chips, but it may be that they let the people that pay for maintenance do all their testing for them. Kinda sad that people that pay big bucks for maintenance (compared to the price of the compiler) do all the testing and countless hours of debugging.
I would think that if CCS posted known bugs in the current version, it would decrease their support required also. I am really glad they at least post Beta's and a version listing - even if the listing isn't complete and is rather terse.
I thank CCS also for having this forum - I think the top several posters that give the most help should get free stuff from CCS - free maintenance, free new compilers, and free kits - a small thing for those that spend so much time helping everyone with the CCS compiler and circuit issues...
Anyway - that's my 2 cents
Trampas - When do you think you may be able to do an updated compiler comparison? ![Laughing](images/smiles/icon_lol.gif) |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
What's this ? |
Posted: Sat Sep 04, 2004 10:50 am |
|
|
Trampas Wrote:
Quote:
"Why the heck did CCS not use bit feilds and unions like the C18, it is a lot cleaner and easier than bit_clear, bit_set, etc." Then you start looking and saying, why doesn't CCS allow multiple C files, and the reason is history and optimization.
end quote:
If you are going to write a compiler comparison then please get it right this time... The above sentence shows your are still living in the past !
Why the heck Darren Rook does not catch things like this I fail to understand.
Of course CCS allows bit fields, and my current project uses 7 "C" files.... What your problem with that ?
Sometime I get sick of CCS and the untested updates as much as anyone.
Hans W |
|
![](templates/subSilver/images/spacer.gif) |
bdavis
Joined: 31 May 2004 Posts: 86 Location: Colorado Springs, CO
|
|
Posted: Sat Sep 04, 2004 10:59 am |
|
|
I think he was refering to the ability to link several different object files such that all the C code isn't compiled at once. I can understand from an optimization level that having a single object is good since you can optimize better, so that doesn't bother me. I have worked on projects with about 70,000 lines of code with hundreds of files that are compiled together for optimizations for an ARM compiler - still works good. PC's are fast enough now that it doesn't bother me. |
|
![](templates/subSilver/images/spacer.gif) |
Trampas
Joined: 04 Sep 2004 Posts: 89 Location: NC
|
|
Posted: Sat Sep 04, 2004 2:15 pm |
|
|
As far as the bit feilds goes, what I was refering to is that instead of in the CCS header files having:
#define PIN_A0 31744
#define PIN_A1 31745
#define PIN_A2 31746
#define PIN_A3 31747
#define PIN_A4 31748
#define PIN_A5 31749
#define PIN_A6 31750
You could have something more like C18 compiler which is:
extern volatile near unsigned char PORTA;
extern volatile near union {
struct {
unsigned RA0:1;
unsigned RA1:1;
unsigned RA2:1;
unsigned RA3:1;
unsigned RA4:1;
unsigned RA5:1;
unsigned RA6:1;
};
struct {
unsigned AN0:1;
unsigned AN1:1;
unsigned AN2:1;
unsigned AN3:1;
unsigned T0CKI:1;
unsigned AN4:1;
unsigned OSC2:1;
};
struct {
unsigned :2;
unsigned VREFM:1;
unsigned VREFP:1;
unsigned :1;
unsigned LVDIN:1;
unsigned CLKO:1;
};
} PORTAbits;
The difference may seem trival, however coding is a bit easier:
if (PORTAbits.RA0==0) or
if (bit_test(PIN_A0)==0)
Or how about something like this:
PORTAbits.RA0=!PORTAbits.RA0;
This code is much more portable and easier for people than the intrisic functions like bit_test, bit_clear, etc. Of course the best part is that CCS can handle both.
As far as the multiple C files, the idea that you have to #include each C file in the main file is a pain. Plus there is a large chance for user errors. Like if I declare a global in a C file, then all the files after the include see the global. This gets into problems when porting code as that two C files could have global variables with the same name.
Trampas |
|
![](templates/subSilver/images/spacer.gif) |
bdavis
Joined: 31 May 2004 Posts: 86 Location: Colorado Springs, CO
|
|
Posted: Sat Sep 04, 2004 2:58 pm |
|
|
Trampas -
I'm using CCS version 3.202 with PIC 18Fxxx, and it will let me do the following, which uses bit fields:
typedef struct _TASK_FLAGS
{
union
{
struct
{
U8 TaskSetLeds :1; /* 0 */
U8 TaskSerialRx :1; /* 1 */
U8 TaskTimer0 :1; /* 2 */
U8 TaskReadSwitches :1; /* 3 */
U8 TaskConfigureSwitches :1; /* 4 */
U8 TaskSetMux :1; /* 5 */
U8 TaskEverySecond :1; /* 6 */
U8 TaskNotUsed_1 :1; /* 7 */
} b; /* bit */
U8 c; /* char */
} u;
} TASK_FLAGS, *PTR_TASK_FLAGS;
TASK_FLAGS TaskFlags;
while (TaskFlags.u.c != 0)
{
if (TaskFlags.u.b.TaskSetLeds)
{
Task_SetLeds();
break;
}
if (TaskFlags.u.b.TaskSerialRx)
{
Task_SerialRx(); /* We have data in the Rx Buffer */
/* Let one of the below tasks run... */
}
if (TaskFlags.u.b.TaskTimer0)
{
Task_Timer0();
break;
}
if (TaskFlags.u.b.TaskReadSwitches)
{
Task_ReadSwitches();
break;
}
if (TaskFlags.u.b.TaskConfigureSwitches)
{
Task_ConfigureSwitches();
break;
}
if (TaskFlags.u.b.TaskSetMux)
{
Task_SetMux();
break;
}
if (TaskFlags.u.b.TaskEverySecond)
{
Task_EverySecond();
break;
}
}
I do the same thing with the registers and bits for them. I don't use any of the ouput_bits() or anything like that either - nice of CCS to have them, but totally not needed and hides what is actually happening.
As for the multiple OBJ's/separate C file compilation - there are actually lots of reasons to have this and why it is a good idea to be able to have separate OBJ files, but it doesn't bother me having it compiled all at once, but that's just me... |
|
![](templates/subSilver/images/spacer.gif) |
|