View previous topic :: View next topic |
Author |
Message |
Andys Guest
|
Slow down in compiler updates |
Posted: Thu Nov 13, 2003 6:33 am |
|
|
Is it just me or has the rate of changes to the compiler slowed way down. I seem to remember at one point having to decide if it was worth downloading a new update almost every week. Now it seems once a month or so. Is this becuase
a) The compilers are now very stable, all the bugs fixed and there are no new optimizations?
b) Everyone is working on "new stuff" like ICDs and real time kernels?
From my own point of view I would tend towards option (a) which is a good thing. Certainly there do not seem to be many big problems to work around these days (though I'm sure there are stil optimizations to do!). As for new stuff (which I guess should also include the 18 series compilers), well good if you want it but if you are a 16 series user that likes to use the MPLAB tools then some of these are of limited interest. It does raise an interesting question of is it worth paying for support in the future....
Just a thought... Now if you tell me that one of the "new stuff" will include a full blown linker so we can have compiled modules and mix C and other code that might be worth knowing.......
Andy |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1934 Location: Norman, OK
|
Slowdown in Compiler Updates |
Posted: Thu Nov 13, 2003 4:35 pm |
|
|
I wouldn't doubt it if they quit putting out updates so quickly because they keep getting hammered by someone every time they do. Over and over again it has been said on this board that the newsest releases should be treated as beta and to use the stable one on the right side of the download page (right now 3.148) if you want to avoid problems, but the same thing keeps on happening time and again.
When I am working a production project I always use the stable version and only use the beta when I am prototyping. Any time I download a new version I ALWAYS keep the old one and switch back immediately (it takes about 30 seconds) if I encounter a serious problem to see if the compiler version is the cause. Almost ten times out of ten it is something stupid I have done and not the compiler.
I do wish CCS would actually set up a BETA release area and a FINAL/STABLE RELEASE area to ease the confusion of the folks that keep stumbling into problems and save CCS quite a bit of grief as well. (Darren R. I hope you happen to read this...:-).
CadSoft/Eagle does this and it works very well. The software even comes up and says it is Beta when you run it.
I personally am very glad CCS tries to get fixes/updates out quickly to folks who may need them. There are MANY companies who are not nearly as responsive! CCS just needs to tweak the way they do it....
FWIW,
Dave. |
|
|
Guest
|
|
Posted: Fri Nov 14, 2003 9:50 am |
|
|
IMHO,
The slow down rate of CSS new versions goes hand in hand with my own experience:
The number of times I suspect the compiler doing something wrong instead of myself has dropped to almost zero.
So, I can say I'm a satisfied CCS user.
Regards,
Ron |
|
|
Ttelmah Guest
|
|
Posted: Fri Nov 14, 2003 11:21 am |
|
|
Anonymous wrote: | IMHO,
The slow down rate of CSS new versions goes hand in hand with my own experience:
The number of times I suspect the compiler doing something wrong instead of myself has dropped to almost zero.
So, I can say I'm a satisfied CCS user.
Regards,
Ron |
I think this is the 'key'. Historically, when users did find repeatable problems, CCS, were fast to issue a 'bugfix' version. The 'plus', was that the user with the problem, usually had this fixed in a few days, but the 'downside', was that the fixes often introduced unexpected side-effects...
Unfortunately, instead of publishing these versions as 'interim' releases, and stating the problem they fixed, they tended to be posted as the new version.
The number of problems of this sort has declined, and with it, so has the rate of 'updates'.
Best Wishes |
|
|
Neutone
Joined: 08 Sep 2003 Posts: 839 Location: Houston
|
|
Posted: Fri Nov 14, 2003 1:42 pm |
|
|
The last bug I found was fixed the next day with 3.180 and I'm not sure if it was a bug that was fixed or a new feature added.
Code: |
int16 register1;
#bit ESD_CMD = register1.11
|
There used to be a limit of 0-7 as the bit identifier. This code now works.
I'm very pleased with support. |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Fri Nov 14, 2003 3:12 pm |
|
|
Nope, CCS was just afraid would run out of version numbers too quick |
|
|
MarkD
Joined: 09 Sep 2003 Posts: 3 Location: Toronto, Canada
|
|
Posted: Sun Nov 16, 2003 9:11 am |
|
|
[quote="Neutone"]The last bug I found was fixed the next day with 3.180 and I'm not sure if it was a bug that was fixed or a new feature added.
[quote]
Well I've found a bug that appears to be in 3.180:
I use MPLAB 6.31 and an ICE2000 and develop code for the 18F452. In the watch window, I see some GLOBAL variables that are not displayed - it says "out of Scope". But PCWH 3.173 allows these same variables to be watched. (just don't try to go back to 3.178 from 3.180, it's not simple)
Now if the compiler was really stable, there would not be such a big difference beteeen the recommended version (3.148) and the latest (3.180) That's 32 revs later! |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1934 Location: Norman, OK
|
Slow compiler updates |
Posted: Sun Nov 16, 2003 10:25 am |
|
|
When jumping on CCS please be objective here.. I know I sound like a CCS "defender" but I am just a professional programmer that understands the issues from both sides of the fence and don't want to see them (or anyone else) unfairly accused without all the information. I have dealt with my share of CCS issues and frustrations on occasion, but I have also been in their shoes. I have users that upgrade to the latest version and then blame every problem they immediately encounter on my software. Many of these existed before, but they just weren't "looking" for them or they installed something else at the same time which interacted and I couldn't possibly have known about the combination they would pick (there are thousands!!!)
Just to be completely fair we don't know for sure if the problem is CCS or MPLAB. There could be a change in the debug file format that wasn't documented properly by Microchip, you just never know. You also have to remember that CCS is not fully responsible for the CCS=>MPLAB interface since it is not directly program compile related. It is a nice sideline "feature" that CCS accomodates for us users (but is not required for the compiler to operate properly) and Microchip shares a lot of responsibility here. This same kind of problems either exist in the other compilers or they don't support MPLAB at all, so it could be worse!
All of these type issues are why I finally converted fully to PCW (where I have not experienced this problem by the way..). I may be all the fault of CCS but who knows at this point?
My 2 cents worth.... :- )
dave |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Sun Nov 16, 2003 1:59 pm |
|
|
Well if all he did was upgrade the compiler and now it doesn't work then it must be CCS since he didn't change a thing with MPLAB.
Also, it is to CCS's advantage to make their compiler work with MPLAB. There is a big difference between the price of just the compiler or the full IDE. The low price on the compiler is what makes CCS attractive to many users. And besides, will the ICE2000 or 4000 even work with CCS's editior? |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1934 Location: Norman, OK
|
Slow Compiler Updates |
Posted: Mon Nov 17, 2003 6:52 am |
|
|
Maybe, but not necessarily. CCS may have made a change to conform to an MPLAB spec or take advantage of something in MPLAB they hadn't in prior versions.
Last spring Lockheed Martin published an interface spec to me for a simulator system I designed for our field offices. In the spec it says I should be able to send a certain message a get a response from their software. In the preliminary vesion they sent me it worked well. However, they tried to fix something at the last minute before their S/W was sent to the field offices and did not make me aware of the change. Result, my simulator crahed (at the worst time of course!) I duplicated the crash conditions here and found no problem. I was scratching my head trying to figure out why it did not work in my lab. When I called L/M they said "oh yeah, we didn't send you the change because we didn't think it would hurt anything" .
I will agree the odds are good that CCS has the problem I this case but, since I have been on the other side, I like to be fair and keep an open mind just in case. I know in my case when users call me up beat on me, and it isn't my fault, it makes me leery to try and stay on top of fixes in the future for fear of incurring users wrath for something else that might break in the process so i just leave it be. I also don't try to implement new "features".
Dave |
|
|
|