 |
 |
| View previous topic :: View next topic |
| Author |
Message |
noizy
Joined: 17 Sep 2003
Posts: 7
Location: Vienna, Austria
|
| Interrupt while accessing a Float or Long |
 Posted: Thu Oct 16, 2003 12:11 pm |
 |
|
Hello,
has anyone looked at the way multi-byte-variables are accessed in the compiled code? I wonder what happens if an interrupt routine changes such a variable while the main program is just reading the same variable.
Afaik there is no warning in the documentation...
Thank you, Roland. |
|
 |
Neutone
Joined: 08 Sep 2003
Posts: 839
Location: Houston
|
|
| Posted: Thu Oct 16, 2003 12:34 pm |
|
|
| When I use interupts to recieve a packet of data I set a flag from within an interupt to cause a reply packet to be generated in main. If I were to create the reply packet from within the interupt my interupt would run a long time between packets and I could create a packet with data that is half current half old. If I check for a flag in main to create a reply packet there is no update in progress and the half old half new problem is not possiable. If you have to modify a value in main that is used in an interupt, you can disable interupts around the code that makes the change to the value. In general I keep the code within interupts as small as posiable. During interupts I set flags for main to perform functions. When main performs said function the flag gets cleared. This is how I can get near real time performance of multiple task. |
|
|
noizy
Joined: 17 Sep 2003
Posts: 7
Location: Vienna, Austria
|
|
| Posted: Thu Oct 16, 2003 12:57 pm |
|
|
Hello,
the method you describe prevents possible problems; but I'm curious: Did you select this approach because you encountered troubles, or just to make sure? (I'm already at 99% of ROM use...)
Roland. |
|
|
Neutone
Joined: 08 Sep 2003
Posts: 839
Location: Houston
|
|
| Posted: Thu Oct 16, 2003 1:46 pm |
|
|
| More or less both learning from my mistakes and preventing new ones. If you fail to learn from the past you are doomed to repeat it. I did intermittently encounter problems because of this. If the problem only happens one time in a thousand loops by chance alone is that too often? How often can you afford to fail? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Oct 16, 2003 2:14 pm |
|
|
| Quote: | | Has anyone looked at the way multi-byte-variables are accessed in the compiled code? I wonder what happens if an interrupt routine changes such a variable while the main program is just reading the same variable. |
The compiler doesn't automatically insert code to disable interrupts
when you access such a variable. You have to do it. |
|
|
noizy
Joined: 17 Sep 2003
Posts: 7
Location: Vienna, Austria
|
|
| Posted: Fri Oct 17, 2003 1:26 am |
|
|
Thank you for answering this question.
Regards, Roland. |
|
|
Ttelmah
Guest
|
|
| Posted: Fri Oct 17, 2003 2:20 am |
|
|
| noizy wrote: | Thank you for answering this question.
Regards, Roland. |
It is one of the areas, where you are 'walking the line', between the power of the compiler, and the dangers of dealing with a device that accesses data in bytes, yet does a lot of arithmetic on larger 'entities'. I would suspect that most users who have 'moved up' from assembler, would add protection automatically in these circumstances, but that users coming from languages that are based on larger data types, might well walk into this as a problem.
I looked at the code generated in the past, and realised that when dealing (for instance), with long integers, or floating values, that are changed both in the interrupts, and the main code, protection would be necessary. It is also worth realising that some operations/tests, are inherently 'safe', while others will require care.
As an example, suppose you have a 'long', used as a clock, incremented in the interrupt routine, but tested in the main code. In this case, if (for instance), you were looking for 'clock==val', the potential exists for this to incorrectly test as true in some circumstances.
For instance:
val = 0x4FF
clock=0x3FF
If the 'test', reads the LSB first. it gets 'FF', and then an interrupt occurs between this read, and reading the MSB. Clock, advances to 0x400, and the MSB is fetched as '04', resulting in the test returning 'true', despite the value being 0x400!...
If instead you implement 'clock', to count down, read the MSB first, and check for the result equaling zero, the operation is inherently 'safe'. It can only test as 'true', when the MSB has reached zero, and the LSB is also zero. In the similar case to above, where the count decrements from 0x100 to 0xFF, the test has read the '01' allready from the top byte, and still tests as false, and can only return true when both bytes are zero.
I suspect the lack of warnings about this, is based on the thinking that programmers who understand the chip's architecture, will be aware of this. A 'dangerous' assumption.... :-)
I have allways added protection for this sort of operation.
Best Wishes |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
