View previous topic :: View next topic |
Author |
Message |
pfournier
Joined: 30 Sep 2003 Posts: 89
|
Camparison bug PCWH 3.182 to 3.190 |
Posted: Wed May 19, 2004 7:51 am |
|
|
Here is my code using 3.182
.................... if( (signed int16)(timer_100ms-timeout2) >= 0 )
51FC: MOVF x94,W
51FE: MOVLB 0
5200: SUBWF x95,W
5202: MOVLB 1
5204: MOVWF x9C
5206: MOVF x95,W
5208: MOVLB 0
520A: SUBWFB x96,W
520C: MOVLB 1
520E: MOVWF x9D
5210: BTFSC x9D.7
5212: GOTO 5216
.................... {
Here is my code using 3.190
.................... if( (signed int16)(timer_100ms-timeout2) >= 0 )
51FC: MOVF x94,W
51FE: MOVLB 0
5200: SUBWF x95,W
5202: MOVLB 1
5204: MOVWF x9C
5206: MOVF x95,W
5208: MOVLB 0
520A: SUBWFB x96,W
520C: MOVLB 1
520E: MOVWF x9D
5210: BTFSS x9D.7
5212: GOTO 5216
.................... {
Note that BTFSC got changed to BTFSS !!!!
This isn't right, what happened! _________________ -Pete |
|
|
Haplo
Joined: 06 Sep 2003 Posts: 659 Location: Sydney, Australia
|
|
Posted: Wed May 19, 2004 5:41 pm |
|
|
Actually you'd still have to look at what is happening at the locations 5214 and 5216. The 3.190 compiler may have swapped the code in those two locations.
But if you believe this is a bug you should report it to CCS so they can fix it in the new version, as this is a dangerous one. |
|
|
DaveMorris
Joined: 13 Oct 2003 Posts: 6 Location: Stourbridge, England
|
Bug With V3.190 - I Agree |
Posted: Thu May 20, 2004 11:20 am |
|
|
Hi
Your bug within the if() statement - I tend to agree, I had a similar problem when I went from v3.188 to V3.190. I have not yet had time to look into my problem deeply but it is the same type of instruction and data type - so it does strongly suggest a compiler error! |
|
|
pfournier
Joined: 30 Sep 2003 Posts: 89
|
|
Posted: Thu May 20, 2004 12:33 pm |
|
|
Sent it onto CCS they said it would be fixed in the next release.
-Pete _________________ -Pete |
|
|
C-H Wu Guest
|
Re: Bug With V3.190 - I Agree |
Posted: Thu May 20, 2004 7:41 pm |
|
|
Dear DaveMorris:
Do you mean that 3.188 does not have this bug ?
Thanks a lot |
|
|
C-H Wu Guest
|
3.190 Bug |
Posted: Thu May 20, 2004 9:32 pm |
|
|
I wrote a simple code to check it out, to my surprise,
there _IS_ a bug in 3.190 for the following,
if( (signed int16)(timer_100ms-timeout2) >= 0 )
but, why not simply use
if ( timer_100ms >= timeout2 )
there is no bug for it.
Anyway, thanks a lot for pointing out the bug, I decided to go back 3.188. |
|
|
pfournier
Joined: 30 Sep 2003 Posts: 89
|
Re: 3.190 Bug |
Posted: Fri May 21, 2004 6:32 am |
|
|
C-H Wu wrote: | I wrote a simple code to check it out, to my surprise,
there _IS_ a bug in 3.190 for the following,
if( (signed int16)(timer_100ms-timeout2) >= 0 )
but, why not simply use
if ( timer_100ms >= timeout2 )
there is no bug for it.
Anyway, thanks a lot for pointing out the bug, I decided to go back 3.188. |
That's cause I didn't give the whole code
I want to test a condiction for 500ms:
unsigned int16 timer_100ms=0; //incremented in a 100ms timer interrupt
unsigned int16 timeout2; //use to calculate delays
timeout2=timer_100ms + 5; // this sets the timeout to 5*100ms
while(conditions)
{
if( (signed int16)(timer_100ms-timeout2) >= 0)
{ result of timing out performed here }
}
doing it in this manner gets rid of wrap around difficulties but obviously only works if my while checks the condition more often the period of a complete cycle of timer_100ms through its 16 bit values.
Credit for this algorithm goes to the programmers at Rabbit Semiconductor, I don't know where they got it from. _________________ -Pete |
|
|
C-H Wu Guest
|
|
Posted: Sun May 23, 2004 2:43 am |
|
|
Got it, I might try this algorithm with my next project.
Thanks for your explaination. |
|
|
|