I'm using 3 timers to build a clock pattern. The data output is created inside an ISR an output via SPI, sent off first thing in the ISR code.
I noticed that when I add a wait after the code for sending the data, there are delays added to my data output. The same if change port state on a port not used in the ISR. I guess this is about GCbasic being clever only saving context it decides is needed.
I could use #option NoContextSave to get around these changes in timing, but I also need some slow code in the main do-loop.
The help says in #Option NoContextSave: ...you may need to save several variables. These are: For Microchip PIC microcontrollers 12F1/16F1/18F: W, STATUS, PCLATH, PCLATU, BSR
So if I save these registers, then the stuff in the main do-loop should be fine, when returning out of the ISR?
Or should wait until I have finished polishing the code in the ISR and then finetune the timing of the data output?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To answer my own question, adjusting for ISR onset delay to match the current code seems a way to go. PLEASE ARGUE if there are reasons why this is a bad idea!
Working with audio, I can do much of the programming, supervising the output through the 8bit built in DAC and every now and then adjust the serial stream delay for the to the high quality i2S serial DAC output. I can see that now, when I finally got the i2S to DAC working again.
Is there any reason to believe that the ISR onset delay may vary during runtime? (There is plenty of unsused instruction cycles left when the ISR routine has finished)
Last edit: Roger Jönsson 2026-08-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using 3 timers to build a clock pattern. The data output is created inside an ISR an output via SPI, sent off first thing in the ISR code.
I noticed that when I add a wait after the code for sending the data, there are delays added to my data output. The same if change port state on a port not used in the ISR. I guess this is about GCbasic being clever only saving context it decides is needed.
I could use #option NoContextSave to get around these changes in timing, but I also need some slow code in the main do-loop.
The help says in #Option NoContextSave: ...you may need to save several variables. These are: For Microchip PIC microcontrollers 12F1/16F1/18F: W, STATUS, PCLATH, PCLATU, BSR
So if I save these registers, then the stuff in the main do-loop should be fine, when returning out of the ISR?
Or should wait until I have finished polishing the code in the ISR and then finetune the timing of the data output?
To answer my own question, adjusting for ISR onset delay to match the current code seems a way to go. PLEASE ARGUE if there are reasons why this is a bad idea!
Working with audio, I can do much of the programming, supervising the output through the 8bit built in DAC and every now and then adjust the serial stream delay for the to the high quality i2S serial DAC output. I can see that now, when I finally got the i2S to DAC working again.
Is there any reason to believe that the ISR onset delay may vary during runtime? (There is plenty of unsused instruction cycles left when the ISR routine has finished)
Last edit: Roger Jönsson 2026-08-02
I can share... that the interrupt will be consistent in terms of latency.