View previous topic :: View next topic |
Author |
Message |
MikeW
Joined: 15 Sep 2003 Posts: 184 Location: Warrington UK
|
Help, am I stupid or what ? |
Posted: Tue Nov 29, 2005 3:57 am |
|
|
I just cant see the wood for the trees, why wont this go round the loop 50 times ?, it just falls through.
I can see why, because the BRA instruction is an unconditional branch.
is it me, or is it a compiler error V3.238 pchw, PIC18F4480
------------
for (LED_Counter=50;LED_Counter>=0;LED_Counter--)
{
Flow_LED_Brightness=LED_Counter;
}
------------
compiles to
................... for (LED_Counter=50;LED_Counter>=0;LED_Counter--)
183C: MOVLW 32
183E: MOVWF LED_Counter
.................... {
....................
.................... Flow_LED_Brightness=LED_Counter;
1840: MOVFF LED_Counter,Flow_LED_Brightness
....................
.................... }
1844: DECF LED_Counter,F
1846: BRA 1840
..... |
|
|
Ttelmah Guest
|
|
Posted: Tue Nov 29, 2005 4:47 am |
|
|
Change LED_COUNTER, to a signed type.
The problem is that for an unsigned value, LED_COUNTER>=0, must _always_ be true. Hence no test is done, and there is a permanent loop.
Best Wishes |
|
|
MikeW
Joined: 15 Sep 2003 Posts: 184 Location: Warrington UK
|
dont like to used signed |
Posted: Tue Nov 29, 2005 5:12 am |
|
|
thanks for your reply.
I think i prefer to do this though...
for (LED_Counter=50;LED_Counter!=0;LED_Counter--)
{
Flow_LED_Brightness=LED_Counter;
}
Mike |
|
|
Ttelmah Guest
|
|
Posted: Tue Nov 29, 2005 5:18 am |
|
|
However this gives one less count. If you want to have the same number of counts as before, you need to increase the initial value by one.
Best Wishes |
|
|
MikeW
Joined: 15 Sep 2003 Posts: 184 Location: Warrington UK
|
|
Posted: Tue Nov 29, 2005 5:50 am |
|
|
Ttelmah, once again, many thanks.
the actual count in this instance is not important for me since I am just testing the PWM'ing of some LEDS to test varying brightness, but i do take your point.
Mike |
|
|
gremlin Guest
|
|
Posted: Tue Nov 29, 2005 8:39 am |
|
|
It is actually quite interesting, that the compiler optimisation is 'smart' enough, to realise that the original test, could never go 'false'. This is one of an increasing number of cases, where this sort of thing happens. I'd have expected that there may actually be a 'warning', that the condition is always true (there are quite a few warnings like this, that only appear if the error reporting is turned up, since they are normally an 'annoyance').
Best Wishes |
|
|
|