3.207 Bug !!

[dvsoft]

Part of my code

[ckielstra]

In the revision history for v3.207:

[Mark]

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.

[dvsoft]

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

[Guest]

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

[Darren Rook]

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.

[Guest]

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.

[Darren Rook]

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.

[bdavis]

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.

[Trampas]

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

[bdavis]

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?

[Guest]

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

[bdavis]

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.

[Trampas]

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

[bdavis]

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...