Michael Rigby-Jones wrote:

>> Jason Hsu wrote:
>>> I tried using count as a local variable initially, but the the debugger
>>> (SIM) showed that it wasn't working properly.  For some reason, the
>>> local variable would be undefined or stuck at 0.  Given that I had
>>> problems when I used count as a local variable but no problems when I
>>> used count as a global variable, I chose the latter.
>> 
>> Good choice!  You gotta do what it takes to work around the compiler
>> sometimes. 
>> 
>> Not being able to generate and use a local variable correctly is a
>> pretty serious problem, though.  I wonder if it was a problem with the
>> connection to MPSIM - I've seen that before with some compilers; the
>> code works, but the variable access while debugging is broken.
> 
> It almost always caused by compatibility problems between the
> simulator/debugger and the debug file emitted by the compiler IME.
> Reducing optimisation level can help, but obviously isn't going to be a
> good move for a delay loop!

On a side note: Even though I'm really a fan of programming in something
more comfortable than pure assembly, I think such delay loops are an
example where resorting to assembly (embedded in C) makes sense. The reason
is that the exact number of cycles may vary between different versions of a
compiler, and rather than counting them every time a version changes,
getting it once right in assembly seems to be a better choice.

The way I do this generally is to let the compiler generate code that does
what I want (the creation of the local variable and how to access it in the
counting loop; the compiler usually generates special symbols for local
vars), then transform the loop part into embedded assembly. (If there is a
hardware timer available, I use this instead of relying on counting
instructions.)

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist