View previous topic :: View next topic |
Author |
Message |
cabel Guest
|
stable version |
Posted: Thu Jun 11, 2009 5:07 am |
|
|
How many years we have to wait for a pcw stable version?
I'm using pcw since many years and every new version has newer stupid bugs.
I've purchased 4.093 recently and it's nasty to see many bugs. |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
tantalizing - |
Posted: Thu Jun 11, 2009 7:06 am |
|
|
so would you post a LIST of the many bugs you have found - ?
It would be helpful if an expert such as your self would point out
the specifics of what you are talking about.
I guess i don't write programs with enough complexity - because - i have been very pleased with the lack of bugs .
SO i'd be curious to learn more about the problems you have discovered
so i can be sure they are not important features instead. |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1941 Location: Norman, OK
|
|
Posted: Thu Jun 11, 2009 9:13 am |
|
|
I would be interested to see the list as well. I just finished two 18F4550 industrial control applications with PCWH and encountered no problems at all. _________________ Google and Forum Search are some of your best tools!!!! |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Thu Jun 11, 2009 11:30 am |
|
|
Quote: | every new version has newer stupid bugs |
I think, the statement is missing the point somehow. It's a usual problem in software development, that new bugs are introduced occasionally. I'm not under the impression, that this happens with CCS C considerably more often than with other, including major company products. There are known issues with some new features, e.g. fixed point numbers, that apparently don't work stable up to the most recent version. There seem to be also a tendency at CCS to favour innovation above compatibility. I have PCM and PCH projects frozen at V3, because they would need rework to operate correctly with V4. That's a bit annoying, but can be accepted.
The 8-Bit (PCB - PCH) compilers are more or less stable, in my opinion. I see mainly problems with PCD, that still appears as a Beta product in several regards, altough I managed to use it for a complex product firmware. I continue to find stupid bugs in PCD operation, but they are basically unrevealed old ones.
In can imagine to have a bug tracking system for CCS C as usual with some public domain software projects. But I fear, that CCS won't like it very much at present. Now, you get possibly support status reports like below, even several months after reporting a bug:
Quote: | The e-mail has been reviewed, however, an answer is not yet ready. A priority has not yet been determined for this issue. |
Would you like to disclose it to all users? |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
a searchable known issue database right ? |
Posted: Thu Jun 11, 2009 2:11 pm |
|
|
Merely having a background awareness of issues that might arise is helpful - hence my perpetual interest in what are reported as "bugs".
I am more inclined to be GRATEFUL to know in advance that there might be a problem with say Structure composition - or modal problems with specific hardware on a PIC family.
I don't hold some bugs against a tool maker who reveals the issues they are struggling with.
and HEY ! BECAUSE it is C for PICS - && the LST is ordinarily helpful and revealing && it is SO easy to introduce a snippet of my own inline ASM -
I have never had a beef with CCS over the various small deficiencies i know of.
My ONLY A** burn Issue is that bug FIXES only get mentioned in the most oblique and USELESSLY non-specific way when a new version makes a dash for freedom. The language that DOES BUG me is " some problem,
with some number formats were fixed." next to the release number.
not confidence inspiring at all.
Working AROUND or THROUGH an issue is pretty much the same to me these days, and time beefing on the forum is time wasted from finding
what the LST dump can tell me.
To Paraphrase Winston Churchill:
"CCS is the WORST compiler there is, except for ALL THE REST!" |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Fri Jun 12, 2009 3:15 am |
|
|
Just a newly found (probably old) PCD V4.093 bug from the road:
In the below compare with a conditional expression, the involved numeric
variables are int16, is_f130 has int1 type. PCD is erroneously using byte
moves.
Code: | ... if (crc.d != (is_f130?recvdata.f130.crc16:recvdata.f11.crc16))
048EE: BTSS.B 1540.0
048F0: BRA 48F8
048F2: MOV.B 1366,W0L **** MUST BE MOV 1366,W0
048F4: GOTO 48FA
048F8: MOV.B 12F0,W0L **** MUST BE MOV 12F0,W0
048FA: CP 12E4
048FC: BRA Z,49DC |
It's apparently too complicated for PCD, you have to tell it more simply...
Code: | temp16 = is_f130?recvdata.f130.crc16:recvdata.f11.crc16;
if (crc.d != temp16) |
|
|
|
Franck26
Joined: 29 Dec 2007 Posts: 122 Location: Ireland
|
|
Posted: Sat Jun 13, 2009 11:01 am |
|
|
Hi,
I don't think that CCS compiler is worse than others. Anyway, what I don't like is that CCS doesn't admit their issues and it doesn't look like they try to fix it...
Some examples:
- when I bought the compiler I was hoping using the multi-compilation unit... still didn't work on V4.072.
- I bought the CCS Load and Go 1 year ago, I should have read the comment on the forum before: I was not able to use it for 1 year. With the new update it starts working for some CPU, of course not for mine!!!
- I bought the IDE too, I spend my time clicking on the end button on my key board because when you try to add text at the end of a line, it add thousand of space before or write it in the middle of your line code...
- Ctrl+Z is nearly stable, but don't try Ctrl+Y, you would lost part of your code!!!
- The examples supplied with the compiler have a lot of bugs and they are full of warnings when you compile it (ex13b.c generate more than 30 warnings).
But as said before what is very annoying is that when you send them emails, it looks like those issues are not important to them, they prefer adding new features instead of correcting the old problems...
Anyway, I've never tried other compiler for pic, maybe it's the fact that pic are middle range CPU, so less used by professional (no offence).
C.U.
Franck. |
|
|
cabel Guest
|
|
Posted: Mon Jun 15, 2009 2:01 am |
|
|
I'm talking about the IDE bugs. For example:
- sometime appears the message "the software is unregistered"
- I assign a shortcut to program chips, but I lost it on the next launch of PCW
- sometime the compile window doesn't disappear
- in the tools->program chip menu there is the command "tìtle2=title2=title2=title2=title2=icd" |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
OH - the IDE---- |
Posted: Mon Jun 15, 2009 7:23 am |
|
|
Sorry - I thought you meant the compiler, which at the LOW and MIDDLE end of the spectrum is working - great for me.
But the IDE ? who uses that ?
I tried for a short time, it but it is too clumsy and buggy, and the way it "absorbs" existing code , for no useful , functional reason led me to abandon it - and never look back.
For code creation - I use a self-customized version of Multi Edit that has served me very well over time for managing multiple code windows - and has easy cut paste etc between screens. |
|
|
Loyal CCS user Guest
|
|
Posted: Mon Jun 15, 2009 11:10 am |
|
|
cabel, don't back down. You'll notice that most of the old timers aren't commenting. That's because they know CCS constantly has bugs and not only that, they break things that worked in previous versions. 80% of the coolest features CCS advertises don't fully work.
addressmod occasionally generates the wrong number of bytes
#import cuts the imported file in half if you specify the correct range
The keyword ROM mostly works but some pointers to rom always return 0xFF
write_configuration_bits recently had problems
PCD is just now starting to be usable and was just recently riddled with I2C problems
The list just goes on and on. Why don't I give more examples? Because this is the part of CCS that I am bored to death with.
Yesterday at about 11PM I discovered that the latest CCSLOAD erases firmware if the HEX includes values for the EEPROM.
I think CCS has/had the PIC compiler world by the tail. But I don't think they make the right decisions to keep the grip. I don't want to add insult to injury but Microchip bought Hi Tech instead of CCS. Why is that.
The unique CCS approach to code is a great one and I will remain a loyal user until they force me to do something else. I hope to be blown away by version 4.100 |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Jun 15, 2009 11:14 am |
|
|
OK, I'll comment. I avoid the IDE bugs by using MPLAB. I avoid other
problems by not using extra features such as addressmod. |
|
|
Franck26
Joined: 29 Dec 2007 Posts: 122 Location: Ireland
|
|
Posted: Mon Jun 15, 2009 11:18 am |
|
|
Hi PCM,
Just a small question:
Does the CCS ICD-U40 debugger works well with the microchip IDE?
With the same functionalities?
Thanks,
Franck. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Jun 15, 2009 11:28 am |
|
|
I use MPLAB with the Microchip ICD2. I don't use ICD-U40. |
|
|
Loyal CCS user Guest
|
|
Posted: Mon Jun 15, 2009 11:29 am |
|
|
And I respect that.
But why should we have to avoid an extremly powerful concept like addressmod just because CCS won't ring it out. All I ask is that they finish it and leave it alone. After all, they got the hard part right. They just didn't always recognize the correct number of bytes in a variable.
I worked around it and reported it but like everyone is saying; who knows if it got fixed. If I really wanted to know I'd have to drudge up that project again and recompile. Just don't have the time for it. LOL Too busy beta testing for them. |
|
|
|