| Electronics > Beginners |
| Sorry to interrupt ... |
| << < (4/7) > >> |
| wraper:
--- Quote from: jpanhalt on June 01, 2018, 03:51:07 am ---1) If you are just going to set a flag in the interrupt and then poll that flag as recommended by some, why have an interrupt to begin with? Just poll the xyzIF. --- End quote --- So how often do you need to poll to not loose the event? :palm: If the event is so slow that you don't need to use interrupt, then sure. You shouldn't use interrupts right and left when there is no need for that. |
| Brumby:
That was one ^ ^ ^ ^ Another is if you needed to know the exact time the event occurred. Then there's handling multiple events that might occur during a single poll cycle. |
| MarkF:
--- Quote from: wraper on June 01, 2018, 06:50:43 am --- --- Quote from: jpanhalt on June 01, 2018, 03:51:07 am ---1) If you are just going to set a flag in the interrupt and then poll that flag as recommended by some, why have an interrupt to begin with? Just poll the xyzIF. --- End quote --- So how often do you need to poll to not loose the event? :palm: If the event is so slow that you don't need to use interrupt, then sure. You shouldn't use interrupts right and left when there is no need for that. --- End quote --- One example that I recently did was processing a rotary encoder. The interrupt routine read the encoder at a high fixed rate and saved the total number of clicks until the Display Loop was able to process them. The Display Loop run at a much slower rate and didn't need to see each event. Just the total number of clicks. The total number clicks was used in sequencing through menu items, incrementing/decrementing values, etc. In this case, a 1000Hz system timer created interrupt events to perform varies tasks (read the encoder and update some hardware at a fixed rate). The Main Loop processed the encoder inputs and updated a display in the background. Whether you poll for an event or use interrupts depends on the task(s) and rates required by your design. One thing to remember here is that you want the interrupt service routine to be fast (i.e. get in and get out as quickly as possible) so it is ready for the next event. Especially if you are looking for multiple events. Do the heavy processing in your main loop where things are NOT time critical. |
| mikerj:
--- Quote from: langwadt on May 31, 2018, 05:41:32 pm --- --- Quote from: mikerj on May 31, 2018, 05:19:46 pm --- --- Quote from: langwadt on May 31, 2018, 05:14:38 pm --- --- Quote from: mikerj on May 31, 2018, 05:04:25 pm ---The RETFIE instruction re-enables interrupts and pops the last address off the stack and loads it to the program counter. It's quite possible to use a normal "RETURN" at the end of an interrupt, the only difference is that interrupts will not be automatically re-enabled. If you jump to a specific location at the end of your inetrrupt rather than executing a RETFIE/RETURN then you will need to manually "pop" the saved address from the hardware stack by decrementing the STKPTR register. If you don't do this then the stack will quickly overflow. Note this is only possible on later versions of the 14 bit PIC core (such as the 16F1827) that allows access to the stack pointer, early devices had no way of doing this. --- End quote --- if the mainloop just pushed something on the stack before the interrupt, then returning from the interrupt to a different place in main those will never be popped off the stack and it'll just keep growing --- End quote --- Yes, that's what I said.... --- End quote --- you said pop the saved address, but the main loop could have pushed other things on the stack at the moment the interrupt happens if you return to a different place the code that pops those off again will never happen --- End quote --- The 14 bit PIC has a hardware stack purely for return addresses, it's not used to save or pass data between functions. |
| mikerj:
--- Quote from: Brumby on June 01, 2018, 06:52:08 am ---That was one ^ ^ ^ ^ Another is if you needed to know the exact time the event occurred. Then there's handling multiple events that might occur during a single poll cycle. --- End quote --- If the ISR is ONLY setting a flag, then you might as well poll the interrupt flag. It's only when the ISR is doing other stuff that polling may not be useful. |
| Navigation |
| Message Index |
| Next page |
| Previous page |