| ??? 12/09/07 23:43 Read: times |
#148015 - Interrupts and shared resources Responding to: ???'s previous message |
Well.
Coding interrupts is both fun and nasty. With interrupts You can do things that make othervise hard tasks simple. On the other hand misbehaving interrupts can drive You nuts by altering the contents of Yer registers without warning. One good candidate for register altering is the MCU status register. If You don't save (and restore) the contents of it Your comparisons may fail occasionally, the math library is rendered useless etc. Some MCU's do this automagically but some (AVR) have to be programmed to do this. Actually ANY shared resource (used by main program and the interrupt code) has to be either restored to it's original state before exiting the ISC (Interrupt Service Code) or has to be sheduled between the users. Saving and restoring is usually simpler to do. Shared resources are not only MCU registers. It can also be the ports, timers and other hardware stuff. Therefore, when initializing the hardware consider turning the interrupts off while doing this. There are numerous cases where You do not want the interrupts to occur. One example would be the ArrrggghVR who has some 16 bit registers which have to be loaded on two successive 8 bit transfers. Those transfers have to happen right after each other without interventions. If an interrupt strikes right between the transfers the 16 bit register is not written properly. This is because there is a 8 bit temp register which is a shared resource for many 16 bit transfers. A simple solution is to disable the interrupts while doing this and then enable them again. It is not a good idea to enable / disable the interrupts while serving an interrupt (Inside ISC). Most MCU's turn off the interrupt while serving one. Some on the other hand keep on serving them as if nothing had happened. Enabling the interrupts on a level triggered ISC might cause stack overflow - just to give one example. The ISC should: - be over in a timely manner - not change the state of "Interrupts Enabled" - save and restore all registers it uses including the status register - not manipulate shared resources Propably the best solution on a MCU for serving serial data RX is to use a so called ring buffer. In ring buffer You have a buffer of some lenght and two pointers (or indexes if You prefer) to that buffer. One is pointing to next write location and the other to the next read location. The idea is to let the ISC manipulate the write pointer and the buffer and the main code the read pointer. The buffer is empty when both pointers are the same and full when the write pointer would be the same as read pointer after advancing it. The "ring buffer" name comes from the advancing of the pointers. When a pointer is advanced and it points outside the buffer (out of the end) then it is adjusted to point to the start of the buffer and this goes on and on like an endless "ring". |
| Topic | Author | Date |
| PWM code thoughts and help? | 01/01/70 00:00 | |
| Some thoughts and help | 01/01/70 00:00 | |
| very good help Russ | 01/01/70 00:00 | |
| cheers! | 01/01/70 00:00 | |
| character for 32 | 01/01/70 00:00 | |
| Good | 01/01/70 00:00 | |
| A & R4 fatal occurence | 01/01/70 00:00 | |
| Info on interrupts | 01/01/70 00:00 | |
| Right next to me... | 01/01/70 00:00 | |
| Aha | 01/01/70 00:00 | |
| tell the truth! | 01/01/70 00:00 | |
| Take a few deep breaths | 01/01/70 00:00 | |
| no arteries popping | 01/01/70 00:00 | |
| hows this? :) | 01/01/70 00:00 | |
| Better, but still has problems | 01/01/70 00:00 | |
| running out of subject line ideas | 01/01/70 00:00 | |
| re: running out of subject line ideas :) | 01/01/70 00:00 | |
| Some comments | 01/01/70 00:00 | |
| Interrupts and shared resources | 01/01/70 00:00 | |
| a thought - if it is help is up to you | 01/01/70 00:00 | |
| More on the PWM program | 01/01/70 00:00 | |
Purpose of my question | 01/01/70 00:00 |



