Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
November 29, 2024, 06:29:04 18:29


Login with username, password and session length


Pages: [1]
Print
Author Topic: ccs4.023  (Read 4888 times)
0 Members and 1 Guest are viewing this topic.
raham
Junior Member
**
Offline Offline

Posts: 70

Thank You
-Given: 13
-Receive: 18


« on: January 25, 2007, 05:56:52 05:56 »

How is the compiler update ,anybody have,what are the fixes in the new version Smiley
Logged
bluex
Junior Member
**
Offline Offline

Posts: 83

Thank You
-Given: 10
-Receive: 39


« Reply #1 on: January 25, 2007, 09:34:05 09:34 »

The CCS compiler is ugly ... it has becamed buggy and the IDE is the worse IDE they have ever produced.
I think that we have to wait for a minimum of 6 months before it becomes reliable ....  Undecided
Logged
hate
Hero Member
*****
Offline Offline

Posts: 555

Thank You
-Given: 156
-Receive: 355


« Reply #2 on: January 25, 2007, 11:03:24 11:03 »

Yes bluex you're right very buggy and ugly! And do you have the v4.023 so we can check the current state of the compiler?

Regards...
Logged

Regards...
bluex
Junior Member
**
Offline Offline

Posts: 83

Thank You
-Given: 10
-Receive: 39


« Reply #3 on: January 25, 2007, 12:02:06 12:02 »

No sorry I do not own the CCS compiler. What let me avoid using their compiler is the commercial practices of CCS.
1- They use their costumers to test their product ... the fact that version 3 has become stable from about 3.223 ... 223 version to make a compiler stable is not serious ... that means that they do not test their compiler at all ... they do not have any test strategy.
2- A company that change it's compiler + its IDE + its tools the same time ... without doing at least 3 or 4 months of test ... I can not base my products on such tools.
3- The fact that you do not buy the product ... you only buy the version actually sold .. in order to get benefit from future version you have to pay ... and for example people hoom have paid for version 4 do not own a good compiler and they will not benefit from corrections absolutely needed for version 4. You can accept the fact that some bugs are tricky ... but you can not accept bugs in elementary functionnalities ... like ....
4- I can accept that I have to pay for Major version releases of the compiler .. like Hitec and most compilers sellers do, but not for every version. CCS has took more than 6 months to release v4.00 and has stopped dev and debug on version 3.249, so people ho have paid for 1 year subscription have been stoled, since for more than 6 months they have had nothing, and after this period they have had a buggy version 4.xxx ....

this is a not serious company to work with .... (It's my OWN opinion ... !!!)

Best regards
Logged
hate
Hero Member
*****
Offline Offline

Posts: 555

Thank You
-Given: 156
-Receive: 355


« Reply #4 on: January 25, 2007, 12:59:56 12:59 »

Yes CCS is very bad in their lack of support you're right even the worst for such a 'GOOD COMPILER' vendor IMO! Let's see why I used the phrase 'GOOD COMPILER':

1- Microcontroller specific functions (delay_xs, shift_xxx):
I'm using the Keil C51 compiler for my MCS-51 based projects & I'm definetly beginning to hate ANSI compilers for embedded systems. C51 cannot shift a byte buffer nor delay some us or ms because it's an ANSI standart compiler. I don't get the neccesity for ANSI when you're using an microcontrollers really. ANSI is for enviorements that use the same hardware like computers with the same processor but different Operating Systems. I'd like to see the 2 different ANSI compilers compile the same source without any problems one for Intel CPU and the other for AMD or something else. So when you change your hardware there's no way you don't change your software, a little(ANSI case) or much(non-ANSI case) either way you CHANGE it. I personally prefer to change the code instead of writing my own uC spefic functions(like bit manipulation or delay function...) on ANSI standart compilers (like HITECH). Yes I can use a timer to generate the delay time and I use that method when I want precise timing but what about a single milisecond delay for button debouncing? Write an interrupt handler, give the control registers correct values, make some registers to hold the timing values.... why do I use a C compiler then, to write my code in Assembly? No I'm not a worker I'm an hardware engineer and I have to use the much readily avaible to me!

2- The versions:
The CCS compiler version is only v4 by now. And let's look at other compiler versions;

-Hitech V9xx
-MicroC was V6 last time I know
-IAR is not even compareble IMO because it doesn't support inline assembly.

Oneday I'd like to compare the same versions of these vendors with CCS when CCS releases the same version number with those vendors which are using that 'version increment according to what?' technique.

3- Specializes in Microchip PIC:
CCS makes compilers for only Microchip parts(I don't tread the SX as some other MCU because it's the same architecture as PIC) so that's a plus IMO.

And at the end I want to say that CCS has lot's of bugs I found a bug of the version 4.018 and it wasn't corrected by v4.020 by I have hope that all of them will be fixed by the upcoming version, but what about other vendors' compilers' bugs? Don't they have any?
These are just my opinions and please be sure I'm not against anybodies opinions!

Regards...
Logged

Regards...
bluex
Junior Member
**
Offline Offline

Posts: 83

Thank You
-Given: 10
-Receive: 39


« Reply #5 on: January 25, 2007, 01:46:21 13:46 »

I fully agree with you (hate), I think that :
1- Portability is not mandatory in microcontroller world ... especially because of the way peripherals are accessed, initialized and managed.
2- CCS has a good (may be the most exhaustive) librarie of drivers for differents peripherals and components (memories, temp captors, ...)
3- CCS do only C, and it's a good thing I think, like Hitec do. This is what I do not like in MikroElektronika ... they try to do All kind of compilers, and worse, they want to do them the same way ... witch is technically a very bad approach (from compilers writing and dealing with different grammars point of view).

But ....
What I like in (Hitec or other compilers writers) Compilers in searching to be ANSI compatible is that the rules that manage the name, and the variable sizes are the same. When you use an "int" it's always the 2 times the size of the minimum data unit, in the case of PIC it"s a byte then INT=2 bytes... in 68000 it's 16Bits so INT=32 bits ...
The problem with CCS, is that they FULLY DO NOT conform to any standard ... their compiler is even the only "C" compiler I have seen that is not Case sensitive ... they added a directive to let you force it to be case sensitive, but the problem is that their manual says that not ALL HEADER FILES AND EXAMPLES are written with case sensitivity in mind ... witch can be very very dangeourous ...

Another thing I like in Hitec compilers is Pointers to Functions ... this makes it easy to develop Real Time Operating Systems.

For numbering versions it's only a commercial strategy, HITEC will have been in version 5.xxx if it has continued using its old numbering scheme. they only tried to do quick in order the make all their C compilers for the same family of mcu's at the same level, for example for PIC/dsPIC/PIC24... version is 9.5xxx

ALL the compilers have bugs ... when using them in commercial environment you have to make a manual check of the generated ASM code. This is mandatory for a good product QA strategy .
Even HITEC Compiler has bugs ... but :
The problem is that we must differentiate :   having bugs and being FULLY BUGGY is not the same.
When a compiler have very tricky bug in extreme conditions (like in HITEC C) this is not an issue ... it can be problematic but the compiler is very handfull compared to ASM manual coding. But when the compiler is BUGGY... when you do not event trust it in nested loops, in indirect variable accessing ... this becomes very ugly, especially if you know that you have to pay for getting corrections to a buggy product ...

I do not hate CCS, and have nothing against them, but I'll never buy their products because I'll never trust them for commercial products.

Best regards.
Logged
hate
Hero Member
*****
Offline Offline

Posts: 555

Thank You
-Given: 156
-Receive: 355


« Reply #6 on: January 25, 2007, 05:03:01 17:03 »

This is starting to be a Hitech-CCS(or ANSI-nonANSI) comparision and please don't get me wrong 'bluex' I just express my opinions about both and thank you for your contribution.Wink Ok let's see:

Quote
What I like in (Hitec or other compilers writers) Compilers in searching to be ANSI compatible is that the rules that manage the name, and the variable sizes are the same. When you use an "int" it's always the 2 times the size of the minimum data unit, in the case of PIC it"s a byte then INT=2 bytes... in 68000 it's 16Bits so INT=32 bits ...

The ANSI standart says that "each compiler is free to choose appropriate sizes for its own hardware, subject only to the restriction that SHORTs and INTs are at least 16 bits, LONGs are at least 32 bits, and SHORT is no longer than INT, which is no longer than LONG". You can check the book "The C Programming Language" by K&R. In my point of view ANSI is not a good standart here because of the hardware it is standartised for. Most of the time I use "int"s for counting registers which are mostly enough to be represented by a byte. Also most optimized code size is the case with 1 byte int for a 8-bit uC's as it should be for other cases(16,32 bit cores). When I had to use an ANSI compiler I use the

Code:
typedef unsigned char int8;

directive to not to get confused. Also the "int8, int16, int32" are the non-ANSI keywords for the CCS compiler which declare an integer number for corresponding bits.

Quote
The problem with CCS, is that they FULLY DO NOT conform to any standard ... their compiler is even the only "C" compiler I have seen that is not Case sensitive ... they added a directive to let you force it to be case sensitive, but the problem is that their manual says that not ALL HEADER FILES AND EXAMPLES are written with case sensitivity in mind ... witch can be very very dangeourous ...

Yes they DO NOT conform to any standart but I think being non-ANSI is enough to be out of standarts as there aren't many more standarts other than ANSI. And they don't claim to be ANSI. Compiler can be made case sensitive with the "#case" preprocessor command but not case sensitive by default as you say. But the keywords are always case sensitive that's a fact. Also I always build my projects with the "#case" command and didn't get into any trouble with their "HEADER FILES AND EXAMPLES" even they say that they may not be case sensitive. Only a problem with the IO PORT "C" mixing with the carry flag "C" in the case sensitive mode but that was not a big problem for me.

Quote
Another thing I like in Hitec compilers is Pointers to Functions ... this makes it easy to develop Real Time Operating Systems.

I agree with you but I can multitask many programs by using interrupts and never had the need to multitask so far but if it is needed CCS has a RTOS embedded in the compiler. And last but not least CCS DO SUPPORT "function pointers".

Quote
For numbering versions it's only a commercial strategy, HITEC will have been in version 5.xxx if it has continued using its old numbering scheme. they only tried to do quick in order the make all their C compilers for the same family of mcu's at the same level, for example for PIC/dsPIC/PIC24... version is 9.5xxx

Then let's the two when CCS comes out with version 5! Wink

Quote
ALL the compilers have bugs ... when using them in commercial environment you have to make a manual check of the generated ASM code. This is mandatory for a good product QA strategy .

You have to check not only the generated ASM code also the uC with the generated hex file on the system real time if you want a good product QA because you can not depend only on the compiler.

Quote
Even HITEC Compiler has bugs ... but :
The problem is that we must differentiate :   having bugs and being FULLY BUGGY is not the same.
When a compiler have very tricky bug in extreme conditions (like in HITEC C) this is not an issue ... it can be problematic but the compiler is very handfull compared to ASM manual coding. But when the compiler is BUGGY... when you do not event trust it in nested loops, in indirect variable accessing ... this becomes very ugly, especially if you know that you have to pay for getting corrections to a buggy product ...

I don't know what you refer to as "being FULLY BUGGY" but the compiler isn't "FULLY BUGGY" it have some bugs but not that much to be referred to as "being FULLY BUGGY". If we're talking about the IDE it isn't also "FULLY BUGGY" it is "COMPLETELY BUGGY". I don't know of any bugs with the nested loops or indirect variable accessing or some other low-level code case because if there was a bug I would find it as I always use these. And I would pay them if they corrected the bugs i find!;) I found a structure bug a few weeks ago and it isn't corrected yet. They don't even respond to bug reports and yes this is very UGLY!

Quote
I do not hate CCS, and have nothing against them, but I'll never buy their products because I'll never trust them for commercial products.

I also do not hate CCS or HiTech or IAR or some other vendor nor a supporter of any of them. I just like to get the most from a compiler as it reserves me time.

Regards...
Logged

Regards...
bluex
Junior Member
**
Offline Offline

Posts: 83

Thank You
-Given: 10
-Receive: 39


« Reply #7 on: January 25, 2007, 07:03:59 19:03 »

100% Ok  ... but for the compiler most of users on CCS forum says that v3.249 is more reliable and less buggy.

Best regards
 Wink
Logged
hate
Hero Member
*****
Offline Offline

Posts: 555

Thank You
-Given: 156
-Receive: 355


« Reply #8 on: January 25, 2007, 09:45:28 21:45 »

Yes that's right but most of the bugs refer to the IDE and new issues of the compiler regarding to the "current version info" page.

http://www.ccsinfo.com/devices.php?page=versioninfo

Regards...
Logged

Regards...
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright © 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC