|
|
View previous topic :: View next topic |
Author |
Message |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
Arbitrary PCD changes |
Posted: Wed Mar 31, 2010 6:09 am |
|
|
I just noticed, that in PCD V4.106 previously existing interrupt definitions have been erroneously removed from the
device file, in this case INT_DMAERR for all PIC24FJ chips. It's rather annoying, that I apparently have to expect
compilation failure of existing applications with each new PCD version.
I would expect, that these kind of artefacts are avoided by basic quality control. |
|
|
dezso
Joined: 04 Mar 2010 Posts: 102
|
|
Posted: Wed Mar 31, 2010 7:08 am |
|
|
This is reason #27 why I hesitate to spend $600 on this. |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Thu Apr 01, 2010 9:24 am |
|
|
CCS support clarified, that the said INT_DMAERR isn't available in PIC24FJ hardware. Unfortunately,
it had been included in the PCD valid interrupts documentation up to V4.105.
So in this case, CCS didn't introduce a new bug, but intended to remove an existing specification error (that
did no harm yet). As usual, it's undocumented in the "recent changes" list. |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Sun Jun 27, 2010 4:27 am |
|
|
I was just aware, that the code for spi_read() built in function in PCD, that has been working for two years has been
replaced by erroneous code in V4.109. It's causing a watchdog reset in my application.
Code: | spi_read(0xAB);
CCS PCD C Compiler, Version 4.109 CAUSES WDT RESET AT A8BE/A8C0
0A8B0: MOV.B #AB,W0L
0A8B2: MOV.B W0L,248
0A8B4: BCLR.B 240.6 ; SPIROV
0A8B6: BTSC.B 240.1 ; SPIxTBF transmission started ?
0A8B8: BRA A8B6 ; No
0A8BA: BTSC.B 240.0 ; SPIxRBF
0A8BC: MOV.B 248,W0L ; Get received data TOO EARLY!
0A8BE: BTSS.B 240.0 ; SPIxRBF Receive complete? MUST BE DONE BEFORE READING SPIxBUF!
0A8C0: BRA A8BE ; LOOPS FOREVER IF SPIxRXB HAS BEEN READ BEFORE
CCS PCD C Compiler, Version 4.107 WORKING CORRECTLY
06FCC: MOV.B #AB,W0L
06FCE: MOV.B W0L,248 ; Put transmit data and start transmission
06FD0: BTSS.B 240.0 ; SPIxRBF Receive complete?
06FD2: BRA 6FD0
06FD4: MOV.B 248,W0L ; Get received data
06FD6: BCLR.B 240.6 ; SPIROV Clear possible overflow from previous receives |
I should add for explanation, that a combination of spi_read() and spi_write() has never been working correctly with
PCD because of an uncorrect handling of status bits, as reported before at CCS Forum. Using spi_read() both for
read and write worked perfectly, however. Possibly CCS tried to change this situation now, but the attempt backfired
completely. As in most cases, there isn't even a hint about changes to SPI functions in the version log.
I have to fall back to known operational V4.107 for the time being. |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1933 Location: Norman, OK
|
|
Posted: Sun Jun 27, 2010 6:33 am |
|
|
It does need to be said that 4.099 is the last version CCS considers a stable
release (shown on the upper right side of the download page). All releases
after that are considered beta. I keep two copies installed. One is the
stable release (version 4.099) I use for production and the other is the latest
release (4.109 in this case) for testing.
I have been hoping for years they would change the wording on their web
site to reflect this....maybe one day! _________________ Google and Forum Search are some of your best tools!!!! |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Sun Jun 27, 2010 9:20 am |
|
|
I didn't yet notice a remark on the update page about "stable" or beta versions. In my opinion, V4.099 has been kept because many changes have been officially introduced starting with V4.100. Does this mean, that V4.099 is more stable than later versions? I fear, it isn't. A large number of bugs has been continuously fixed with new releases, some are still continued, a few have been newly introduced, as in the present case.
But in any case, you should keep a compiler version, that has been used for a production release. |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1933 Location: Norman, OK
|
|
Posted: Sun Jun 27, 2010 9:14 pm |
|
|
Historically, since back in version 3, the version on the right of the Download
page has been the latest "full and stable" release and the version on the left
is considered beta. I have been a CCS user since 2003 and I believe that is
still the case. Like I said earlier, it would be nice if CCS was up front about
this.
PCM and TTelmah, please correct me if I am wrong, is this the way you understand it? _________________ Google and Forum Search are some of your best tools!!!! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19504
|
|
Posted: Mon Jun 28, 2010 2:04 am |
|
|
Basically yes.
Except when they are doing major updates, when the 'new' version is more like an 'alpha'....
The thing that makes it really hard to know what is likely to give problems, is the poor documentation of the changes. They basically report 'one thing' changed with a release, when in reallity most have several dozen parts tweaked.
My own approach is always to document in the source code, what compiler was used with it, and when I archive sources, archive the compiler used with it. When I try a new compiler, I keep the old, till I have verified that the code I am working on, works with the new version. Once this is 'true', update the note in the source, to say this. The note is always 'cumulative'. So (for example):
Code: |
//4.078 Original version
//4.084 Had to change calls to USB initialisation - see notes
//4.099 Worked well
//4.104 OK initially, but introduced new problems. USB code much smaller
//4.099 with 4.104 USB Current version
|
This is for one project I am currently using. Here I found that 4.104, added some new problems, but that the new USB includes worked better. So this is currently being compiled with 4.099, but using the 4.104 USB include files.
Because I keep the 'track back', I can step backwards if problems appear later. This happened here with me going back to 4.099, but trying the 4.104 includes with this...
Best Wishes |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Sun Aug 15, 2010 11:20 am |
|
|
spi_read() is O.K. again with PCD V4.110, also spi_write() seems to work finally as expected.
But why this #FUSE name has been changed?
Code: | #IF getenv("VERSION")>=4.110
#FUSES WDT128 //Watch Dog Timer PreScalar 1:128
#ELSE
#FUSES WPRES128 //Watch Dog Timer PreScalar 1:128
#ENDIF |
|
|
|
|
|
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
|