The bad habit of silent compiler changes

FvM · Joined: 27 Aug 2008 Posts: 2337 Location: Germany

A year ago, I reported some irregularities in PCD's understanding of flash protection bit, partly cause by
an inconsistent Microchip documentation.
http://www.ccsinfo.com/forum/viewtopic.php?t=36155

Now I realized, that CCS has changed the PCD behaviour in this regard, unfortunately without telling a word,
neither in the version log nor in readme.txt. I didn't become aware the change immediately, because I set
the fuses only when flashing the bootloader, the most recent version has been compiled with V4.098.
Luckily, I got it before giving the update to the customer.

The below fuses have been working up to V4.098 to protect Page 0..3 (area 0..0xFFE) and Configuration bits

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

This is related to the previous thread. What's your suggestion for CCS ?

I think they could do one of several things:

1. Release vs. 4.100 in its current state, with whatever new features are
ready. If some new features aren't yet ready, release them at a later
date in vs. 4.010 or 4.020 (etc). But start doing bug fixes with normal
version updates again.

2. Declare that vs. "4.100" is behind schedule. Its release will be
postponed, and will be done as vs. "4.200" at some future date.
(This announcement might be made with some embarrassment).
Start doing normal bug fixes again with vs. 4.100, 4.101, etc.

3. Continue delaying "vs. 4.100" for weeks or months, while doing hidden
bug fixes.

They are currently doing #3. I favor them doing #1, or even #2.
But stop the hidden updates.

FvM · Joined: 27 Aug 2008 Posts: 2337 Location: Germany

Although the above issue is somewhat special, it's a good idea to discuss it in conjunction with V4.099/V4.100 problem.

Regarding the present situation, missing or blocked bug fixes are the more serious problem, I fear. The said hidden subversion problem http://www.ccsinfo.com/forum/viewtopic.php?t=40492 is only the "tip of the iceberg".

I don't know, which changes are actually involved with V4.100. From the advertising, I would expect some more basic changes than just a simple update. Probably, you shouldn't port an active project to V4.100 before assuring, that there aren't any unexpected side effects.

From a marketing view, it's unacceptable to cancel the V4.100 milestone. So releasing clearly identifiable subversions for the time being is the best solution in my opinion.

Coming back to the addressed PCD fuses problem. The basic problem is, that PCD is in part still a construction site. There's a number of unfixed reported bugs and probably additional bugs (e.g. with hardware related built-in functions), that didn't yet reveal. You can be sure, that customers don't report each bug to CCS, if they already found a workaround. That's simply a matter of economic developing.

Personally, I would prefer a detailed revision history, that lists all changes of the compiler.

At least, a clear warning must be issued for functional changes, that possibly affect existing applications, as in the present case.

As an example of a detailed revision history, see the below BECK IPC RTOS release notes:
http://www.beck-ipc.com/de/download/load.asp?f=/releasenotes/SC13V0126_ReleaseNotes.pdf

Ttelmah · Guest

This is not specific though to the work towards V4.100. CCS have done this from day one. A search through old threads will find the many moans about it. You can reckon that the 'documented' changes to a compiler version, probably represent less than 10% of what has actually been done. This is why in the past there were three bits of advice commonly posted:
1) Unless a new version fixes a specific problem that you _need_ the fix for, treat all new versions as beta's till you have had a good chance to try them.
2) When loading a new version, keep the last one as well, till you are sure what the effects of the new version are.
3) When working on a project, store the compiler version used, with the project's own archive, so that you have it available if going 'back' at a future data.

It is one of CCS's annoying habits, and one that may people have moaned about... :(

Best Wishes

dyeatman · Joined: 06 Sep 2003 Posts: 1934 Location: Norman, OK

One of the "biggies" that has been promised is the the Microchip TCP/IP stack would directly compile in version 4.100. That kind of compatibility is a huge change and I would expect that's part of the holdup.
_________________
Google and Forum Search are some of your best tools!!!!

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

What bothers me is that with that level of a change, we might have to
wait until vs. 4.165 to have a fully working compiler. I would rather that
they didn't do that.