I'm having a bit of difficulty wrapping my head around what happens when ISRs are used when there is another process which consumes more time than the rate at which ISR triggers are known to be occurring...
I am using an ILI9341 2.8" display and have famebuffering enabled. When measuring the time it takes to perform the tft.updateScreen() I find that this process requires ~24ms to complete.
I have two ISRs setup to monitor incoming pulses for engine RPM and vehicle speed.
Engine RPM pulses will vary from 42Hz at idle up to 370Hz at 7400RPM. 24ms to 2.7ms, respectively.
Vehicle speed pulses will vary from 0Hz up to 280Hz by 200MPH.. 0ms to 5ms, respectively.
Within these two ISR code sections (for engine RPM and vehicle speed), I have reduced both of them down to a bare minimum of 3 lines of code to capture the duration of time between the current pulse and the previous pulse.
This elapsed time between pulses are used in another section of code for displaying this information.. after performing the necessary math to convert the time metric into the respective units of RPM and MPH.
This arrangement works flawlessly and the reported vehicle speed and engine RPM are accurately shown at each refresh of the ILI9341 display over the full range of engine RPM as well as speeds upwards of 150MPH.
.
.
.
Considering 5000RPM at 90MPH... The RPM ISR is being triggered every 4ms and the speed ISR is being triggered every 7.9ms.. but the tft.updateScreen() process takes 6x longer than the RPM ISR trigger interval and ~3x longer than the vehicle speed ISR trigger interval.
Am I to understand that in this 5000RPM/90MPH condition when the tft.updateScreen() process is called, the micro is interrupting said process ~6 times for the RPM ISR AND ~3x for the vehicle speed ISR?
I am using an ILI9341 2.8" display and have famebuffering enabled. When measuring the time it takes to perform the tft.updateScreen() I find that this process requires ~24ms to complete.
I have two ISRs setup to monitor incoming pulses for engine RPM and vehicle speed.
Engine RPM pulses will vary from 42Hz at idle up to 370Hz at 7400RPM. 24ms to 2.7ms, respectively.
Vehicle speed pulses will vary from 0Hz up to 280Hz by 200MPH.. 0ms to 5ms, respectively.
Within these two ISR code sections (for engine RPM and vehicle speed), I have reduced both of them down to a bare minimum of 3 lines of code to capture the duration of time between the current pulse and the previous pulse.
This elapsed time between pulses are used in another section of code for displaying this information.. after performing the necessary math to convert the time metric into the respective units of RPM and MPH.
This arrangement works flawlessly and the reported vehicle speed and engine RPM are accurately shown at each refresh of the ILI9341 display over the full range of engine RPM as well as speeds upwards of 150MPH.
.
.
.
Considering 5000RPM at 90MPH... The RPM ISR is being triggered every 4ms and the speed ISR is being triggered every 7.9ms.. but the tft.updateScreen() process takes 6x longer than the RPM ISR trigger interval and ~3x longer than the vehicle speed ISR trigger interval.
Am I to understand that in this 5000RPM/90MPH condition when the tft.updateScreen() process is called, the micro is interrupting said process ~6 times for the RPM ISR AND ~3x for the vehicle speed ISR?
Last edited: