CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Version 4 Comments
Goto page Previous  1, 2, 3 ... 14, 15, 16, 17, 18, 19  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Ttelmah
Guest







PostPosted: Fri Mar 30, 2007 2:39 am     Reply with quote

As an 'update' on the state of the compiler, I have been playing with some parts of 4.030. Some things that were not working, are now operational. Addressmod, now seems to work OK. :-) Several bits that had bugs in the former releases do appear to work, with basic I2C, serial etc., all working. Pointers to constant strings have 'problems', but in part are working. The declarations don't work using 'const' as given in the manual, but limited functionality is there, using 'ROM'. This with all three different 'configuration' options (CCS3,4,ANSI). However there are are some serious 'screw ups', in quite basic operations at times...
Code:

      //Limit range
      if (dampval<0>1023) dampval=1023;

      //Check not below minimum
      if (dampval<lowval>120.0) value=120.0;
         if (value<0.0) value=0.0;
      }

Now, 'dampval', is a signed int16, sent across I2C from another chip, having a possible range of 0-1023. The first couple of lines clip any 'fliers', and ensure that the value cannot be outside this range. 'Lowval', is a signed int16, set to zero as the chip wakes up, and 'disp_div', is a float at 10.24. Latter these are set, so that a smaller part of the adc range, corresponds to 0-100%. However on boot, the maximum output possible, should be about 99.9%.
In 3.249, and several older releases, this works fine. In 4.030, it gives an output value of 120.0!. Now if you think about this, that is impossible, and implies that something radical is going wrong in the maths. It woks OK, if the division is moved onto a separate line, suggesting that the fault here is with a 'temporary' value used internally by the compiler...
Stepping through with MPLAB, has all the values as expected before the arithmetic.
It does mean, that anyone relying on the result of arithmetic, would be wise to be using another release, or 'double check' the sums do behave as expected.... Crying or Very sad
Unfortunately, the compiler still does not do 'what it says on the tin'...

Best Wishes
rmozer



Joined: 06 Jun 2005
Posts: 17

View user's profile Send private message

PostPosted: Fri Mar 30, 2007 8:58 am     Reply with quote

I started with "B" before there was "C" (yes it's true) and have used the CCS compiler since it became commercial. I still learn new tricks and enjoy looking at the comments and replys that some of the regulars around here provide like Ttelmah and PCM programmer. I always learn something new from them. Very Happy

After several tries with Version 4, it appears that 4.030 is starting to do a pretty good job of compiling at least my code (highly modified version of the Microchip TCP/IP port).

Version 3.249 has several issues such as a problem displaying certain floating point numbers that I never understood. As an example if you do something like
Code:

void main(void) {
float t;
  t=4513.829;
  printf(user,"%f \r\n",t);
}

You will get the number 218.862593 printed Confused

With version 4.030 the same code will give you the expected result of 4513.82 (although not rounded properly).

On the other hand using version 4.030 and doing something as simple as writing 8 bit data to flash like shown below, will fail when the ICD program tries to verify memory. Apparently the expected results are saved but I don't like delivering any code that says it failed the program verify. Rolling Eyes This works fine with 3.249...
Code:

#include <18F6722.h>
#FUSES ... (doesn't matter)

#ROM int8 0xF00000 = {1,2,3}
#ROM int8 0xF00003 = {4,5}

void main()
{
 // Just testing #ROM directive...
}



Although I have a lot of production code, my code is pretty simple (few complex statements, crazy relationships, or wild creative use of pointers). Still, testing 20K plus lines of code is a very time consuming task and impossible to be 100% (just ask Microsoft).

Since I have a lot of field experience with a lot of installed devices using code compiled with 3.249, I at least know of some of the problems and am very cautious about switching to a whole new set of problems with version 4.

Since I have issues with both versions, I'm kinda in a pickle trying to determine which way to jump. What does everybody use use as the guideline for switching compilers?
newguy



Joined: 24 Jun 2004
Posts: 1903

View user's profile Send private message

PostPosted: Fri Mar 30, 2007 10:37 am     Reply with quote

rmozer wrote:
What does everybody use use as the guideline for switching compilers?


A long period of minimal 'b$%ching' on this thread. Very Happy

No, seriously.
treitmey



Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA

View user's profile Send private message Visit poster's website

PostPosted: Fri Mar 30, 2007 11:01 am     Reply with quote

rmozer:
I start with a new compiler when starting a new project.
If I run into a bug, I revert back to an older compiler that hopefully had the bug fixed. All production code is in ms sourcesafe with the compiler used for it. If I need to update a tiny chunk of code for production hardware I'll do it using the original compiler. That all being said, I'll update from some real OLD compiler if I feel the upgrade path will be smooth. ie:2.xx ->3.249


btw
imho
jump towards 3.249
Ttelmah
Guest







PostPosted: Fri Mar 30, 2007 2:42 pm     Reply with quote

At the moment I'd say use 3.249. The 'float' problem you mention, doesn't happen, provided you specify an output field width (and keep it reasonable).
4.030, is starting to look reasonable in parts, but seems to have introduced some new oddities (like my arithmetic one, and your #ROM one), which I'd reckon on at least half a dozen more versions, before these are fixed.
V4, is getting 'close' to testable now, but is still much more likely to have an 'unexpected' error, than 3.249.

Best Wishes
Guest








Find is broken in 4.031
PostPosted: Tue Apr 03, 2007 3:13 pm     Reply with quote

Confirmed by CCS today, Find is broken in ver 4.031, causes a crash !

But they have added the code insight function (where holding the cursor over a function or variable shows details about it's type or parameters) though thats still a bit buggy as well.

Jim
shageman
Guest







How about RS232, printf and interrupts?
PostPosted: Tue Apr 10, 2007 8:41 am     Reply with quote

Hi folks: I write pretty simple code - Any known issues with RS232, Printf and interrupts with the latest V4?

Thanks,

Steve H.
frequentguest
Guest







PostPosted: Tue Apr 10, 2007 8:54 am     Reply with quote

No, as a general rule, the problems appear in more complex parts of the code. I have seen few bugs with the basic parts of the compiler (unless you consider floats basic).
steve_hageman
Guest







Thanks...
PostPosted: Tue Apr 10, 2007 1:07 pm     Reply with quote

Thanks - I don't use Floats - I use Fixed Point for precision.
picoid
Guest







PostPosted: Wed Apr 11, 2007 5:26 am     Reply with quote

Men, i am terribly disappointed with this compiler, seriously. I've tried three serious projects so far with 4.023 and all of them have ended at the trash bin, as i got stunned in front of an unexplainable problem, which later would appear as a bug, after some hours of low-level debug.

The compiler's inline asm traduction is the worst i've ever seen. It may be optimized, whatever, but i think it's unforgivable to bank-switch twice at the same bank. Have the programmers (the compiler's ones) ever wondered about checking out if the previous instruction has already switched to the correct bank?
At the development of a very time critical application segment (i said segment, about 15% of the app; dev-ing totally in asm would drive me crazy) it's very disappointing to see how the compiler wastes time switching banks where you don't need to. Yeah, asm ASIS may be the solution... okay, here we go... hmmm, now the problem is that the compiler (or the linker) does not point to the correct adresses.

I'm sure you'll shout at me, telling me that we're at initial release stages. Okay, true... but i think stability (i can tell you more minor bugs) and compiler's reliability is something that we apreciate so much. How about rewarding bug reporters? That may be a good idea to increase your "bug report income", so that more bugs are solved in less time.

I don't know which your disappointment level may be, but paying this amount of money, and the update license fees, is rather annoying, considering that many people (affortunately me not) rely on your tools for the wellness of their enterprises, which depend on the design and production of consumer (or any other category) electronics.

Disappointed, though.
Jim Hearne



Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK

View user's profile Send private message Send e-mail Visit poster's website

Memset broken in V4.030-V4.032, maybe others.
PostPosted: Wed Apr 18, 2007 10:01 am     Reply with quote

Watch out if you use Memset in versions after 4.020 (not sure exactly which version) as CCS have just found that the problem in my project which meant it worked in 4.020 and not 4.030-4.032 was that memset was clearing too much memory and overwriting another variable.
It's going to be fixed in the next release.

Jim
SteveH
Guest







Ver 4.032 Info
PostPosted: Wed Apr 18, 2007 7:09 pm     Reply with quote

Just a note - I was able to compile a decent sized app of mine that was originally written in V2.6xx with V4.032 - All I had to do was add ADC=10 and change one printf statement that the compiler didn't like now. The new app uses 48% of memory, down from 52%. It uses a few more ram variables. So even though I know there are still bugs I'm decently happy that the port was so painless. It went better than I expected frankly!

I hadn't upgraded since V2.6 because I was tired of chasing bugs. Finally I decided that I needed more chip support and the ICD support also. So I guess I'm in the 21st Century now!

;-)
Just my 2 cents worth - HTH - Steve H.
Jim Hearne



Joined: 22 Dec 2003
Posts: 109
Location: West Sussex, UK

View user's profile Send private message Send e-mail Visit poster's website

V4.32 is a lot bettter.
PostPosted: Thu Apr 19, 2007 2:23 am     Reply with quote

Ver 4.32 is now pretty much useable, of the last 4 projects i've updated to from 3.xx to 4.xx.
One worked straight away, 2 needed & casting (now they've made it ANSI compliant) and one wouldn't work properly because of the memset bug(fixed in 4.33 they say).
Most of the IDE bugs that were annoying me now seem to be fixed and i'm using 4.xx rather than 3.xx when i can.
The latest project used a 18lf6722 with more than 64k of code (admittedly about 50% fonts) and a dozen source files so it seems to be able to handle big projects as well.

I guess CCS are a bit less overwelmed with bug reports now as i now usually get replys within a day and they persist until they find the cause of the bug.

Jim
Ttelmah
Guest







PostPosted: Thu Apr 19, 2007 2:34 pm     Reply with quote

The '&' change, didn't make it ANSI compliant, but made it 'C' compliant!...
It was always a 'bug' really. The behaviour differed from the original K&R book here.
I do agree. It looks as if early 4.3x, marks the point at which the compiler really starts to be a reasonable 'beta'. Now the question becomes how many of the 'new' features work. Several of the ones listed in the original 'what does V4 have' page, posted about a year ago, still don't work, but I'd say at last it does compile most projects using the older commands, with some newer syntax features working OK.
Pointers to ROM, still only partially work for example.
If this was what had originally been released as 'V4', I'd have considered it a reasonably good try....

Best Wishes
quack
Guest







PostPosted: Tue Apr 24, 2007 5:57 am     Reply with quote

My big question:

Why did ccs jump from 3.249 to 4.000? Did they think that their 3.xxx compiler was very mature so that new version number could be assigned? Instead, they thought that adding new devices and vista appearance was enough for it? Or they had to do it, to give the compiler a "new era" label, so that new and former customers are attracted again?

Still don't know. 3.249 version should have been followed by 3.250, 3.251, 3.252 ...

Looking at the "what's new in v4", it can be seen that the changes made are not as much as to jump to 4.000.
I think the most acceptable jump would have been 3.3 or 3.5, because as people around here say, the compiler has some kind of beta feeling.

PD: The post was written assuming that the last 3.x version was 3.249, didn't check it. I may be wrong.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2, 3 ... 14, 15, 16, 17, 18, 19  Next
Page 15 of 19

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group