When GC Basic processes an interrupt, does it have to finish the Basic statement that was interrupted before it can process the interrupt? For instance, if a 1 second WAIT was being executed when the interrupt occurred, would the beginning of the interrupt processing be delayed as much as 1 second until the WAIT is finished?
In general, what are the pro's/con's of handling interrupts within GC Basic vs handling them in assembler?
Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An interrupt will begin to be processed during the next instruction cycle after it occurs, which may or may not be in the middle of a Basic statement. There are a few points that should be taken into account.
If an interrupt occurs during a Wait, it will be processed straight away. However, the time taken for the interrupt code to run will be added to the delay - if there is a 100 ms delay, and an interrupt that takes 10 ms to run occurs in the middle, the delay will end up taking 110 ms. If you need a precise delay, make sure to turn off interrupt handling before the delay (using the IntOff command) and then turn it back on after (using IntOn). Also, it's a good idea to keep interrupt handlers as short as possible - don't put any Wait commands inside them if it can be avoided.
Another thing to take into account is that GCBASIC will automatically call context saving code between the interrupt occurring and the interrupt handling code being run. This will only take a few instruction cycles – typically less than 30 – or a delay of under 6 us on a 20 MHz PIC, or less than 3 us on a 10 MHz AVR. There will also be context restore code called after the interrupt handler is finished – this will take the same amount of time to run. However, you should have this code in assembly as well – the difference is that GCBASIC will automatically add the code, so you might not notice it on first inspection.
Generally, I’d recommend that you handle all interrupts in GCBASIC, using On Interrupt if possible. There won’t be much more overhead than in assembly, a few microseconds at most, and it will make your code far more portable from one chip model to another. If you use On Interrupt, you don't need to worry about setting enable bits and checking flag bits - the compiler should do this automatically (if it doesn't, please let me know!)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Hugh! This is the answer I was hoping to hear. The commercial Basic compiler Im presently using requires an assembler interrupt handler if you need fast response to an interrupt. Sounds like you implemented it in a much better way.
Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i dont thing that GCBASIC interrupt response is fastest, but it is good, because it save context registers and You don't need to worry about W register and flags during interrupt. also this interrupt code automatically handle interrupts source (timer irq or pin irq etc.). after assembling code I allways chech all stuff in MPLAB to make sure that everything is OK. In situations when I need to handle only one interrupt (timer), I am modifying ASM to remove CALL and RETRUR commands. Jus simply copy subrutine commands and paste them in interrupt handler. this add some performance and reduce stack usage. by this You can win another 1uS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When GC Basic processes an interrupt, does it have to finish the Basic statement that was interrupted before it can process the interrupt? For instance, if a 1 second WAIT was being executed when the interrupt occurred, would the beginning of the interrupt processing be delayed as much as 1 second until the WAIT is finished?
In general, what are the pro's/con's of handling interrupts within GC Basic vs handling them in assembler?
Joe
An interrupt will begin to be processed during the next instruction cycle after it occurs, which may or may not be in the middle of a Basic statement. There are a few points that should be taken into account.
If an interrupt occurs during a Wait, it will be processed straight away. However, the time taken for the interrupt code to run will be added to the delay - if there is a 100 ms delay, and an interrupt that takes 10 ms to run occurs in the middle, the delay will end up taking 110 ms. If you need a precise delay, make sure to turn off interrupt handling before the delay (using the IntOff command) and then turn it back on after (using IntOn). Also, it's a good idea to keep interrupt handlers as short as possible - don't put any Wait commands inside them if it can be avoided.
Another thing to take into account is that GCBASIC will automatically call context saving code between the interrupt occurring and the interrupt handling code being run. This will only take a few instruction cycles – typically less than 30 – or a delay of under 6 us on a 20 MHz PIC, or less than 3 us on a 10 MHz AVR. There will also be context restore code called after the interrupt handler is finished – this will take the same amount of time to run. However, you should have this code in assembly as well – the difference is that GCBASIC will automatically add the code, so you might not notice it on first inspection.
Generally, I’d recommend that you handle all interrupts in GCBASIC, using On Interrupt if possible. There won’t be much more overhead than in assembly, a few microseconds at most, and it will make your code far more portable from one chip model to another. If you use On Interrupt, you don't need to worry about setting enable bits and checking flag bits - the compiler should do this automatically (if it doesn't, please let me know!)
Thanks Hugh! This is the answer I was hoping to hear. The commercial Basic compiler Im presently using requires an assembler interrupt handler if you need fast response to an interrupt. Sounds like you implemented it in a much better way.
Joe
i dont thing that GCBASIC interrupt response is fastest, but it is good, because it save context registers and You don't need to worry about W register and flags during interrupt. also this interrupt code automatically handle interrupts source (timer irq or pin irq etc.). after assembling code I allways chech all stuff in MPLAB to make sure that everything is OK. In situations when I need to handle only one interrupt (timer), I am modifying ASM to remove CALL and RETRUR commands. Jus simply copy subrutine commands and paste them in interrupt handler. this add some performance and reduce stack usage. by this You can win another 1uS.