|
|
View previous topic :: View next topic |
Author |
Message |
Ttelmah Guest
|
|
Posted: Fri Mar 30, 2007 2:39 am |
|
|
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....
Unfortunately, the compiler still does not do 'what it says on the tin'...
Best Wishes |
|
|
rmozer
Joined: 06 Jun 2005 Posts: 17
|
|
Posted: Fri Mar 30, 2007 8:58 am |
|
|
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.
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
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. 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: 1909
|
|
Posted: Fri Mar 30, 2007 10:37 am |
|
|
rmozer wrote: | What does everybody use use as the guideline for switching compilers? |
A long period of minimal 'b$%ching' on this thread.
No, seriously. |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Fri Mar 30, 2007 11:01 am |
|
|
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
|
|
Posted: Fri Mar 30, 2007 2:42 pm |
|
|
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 |
Posted: Tue Apr 03, 2007 3:13 pm |
|
|
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? |
Posted: Tue Apr 10, 2007 8:41 am |
|
|
Hi folks: I write pretty simple code - Any known issues with RS232, Printf and interrupts with the latest V4?
Thanks,
Steve H. |
|
|
frequentguest Guest
|
|
Posted: Tue Apr 10, 2007 8:54 am |
|
|
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... |
Posted: Tue Apr 10, 2007 1:07 pm |
|
|
Thanks - I don't use Floats - I use Fixed Point for precision. |
|
|
picoid Guest
|
|
Posted: Wed Apr 11, 2007 5:26 am |
|
|
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
|
Memset broken in V4.030-V4.032, maybe others. |
Posted: Wed Apr 18, 2007 10:01 am |
|
|
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 |
Posted: Wed Apr 18, 2007 7:09 pm |
|
|
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
|
V4.32 is a lot bettter. |
Posted: Thu Apr 19, 2007 2:23 am |
|
|
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
|
|
Posted: Thu Apr 19, 2007 2:34 pm |
|
|
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
|
|
Posted: Tue Apr 24, 2007 5:57 am |
|
|
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. |
|
|
|
|
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
|