Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 3 of 3

Thread: T4 w/ ILI9341_t3n: Interrupt Question >>

  1. #1

    T4 w/ ILI9341_t3n: Interrupt Question >>

    As the title states, I'm using the T4 with the ILI9341_t3n driver for a 2.8" TFT.

    I am using Framebuffering.

    My question is: The tft.updatescreen event takes about 27ms to complete.

    I have an ISR setup that is monitoring a vehicle speed sensor that produces pulses spanning from ~70ms (@10MPH) between rising edges down to ~3.5ms @ 150MPH between rising edges.

    So during one of the tft.updatescreen events, if one of these rising edges from the speed sensor occur, does the T4 halt the tft.updatescreen process and immediately handle the speed signal pulse ISR... and then return back to the tft.updatescreen process?

    OR, does the tft.updatescreen event have to run to completion before the speed sensor pulse ISR is handled?

    ADDITIONALLY: Let's say that the system is processing through the routine that uses these variables within the ISR. If the speed ISR is triggered right in the middle of that routine using these variables in the ISR, is it possible that the values within these variables in the ISR will change and as a result, cause the latter half of the other routine that uses these values to use the new "updated" variable values?


    (SPD has been stored in MPH)

    void SpeedProcessor(){
    SPDKM/h = SPD * 1.60934;
    ******************************* AND lets say this is the very moment when the ISR is triggered **********
    SPDfts = SPD * 1.467;

    If the value of SPD has been changed because of the ISR, does that mean that the SPDfts value will be calculated using the new SPD value?

    The ISR code for the speed sensor is as follows: (It looks overly complicated for just determining speed from pulse timing.. just keep in mind that I'm using this information in order to perform a calculation for acceleration.. ;-)
    void ISRSpeed() {
      if (((micros() - OLDSPDPulse) > 4700) && OLDSPDPulse > 0) {        //  Check for false pulses & that the loop has been run once to set the OLDSPDPulse variable
        SPDPulseNow = micros();                     //  Store the current time into variable
        if (SPDPulse3 > 0) SPDPulse4 = SPDPulse3;  //  Check for storing SPDPulse3 has set this variable's value- Pulse4 is set to the previous pulsewidth
        if (SPD > 0) PrevSPD = SPD;                 //  Check that the nested loop for storing the SPD and PrevSPD has been set
        if (SPDPulse2 > 0) {                        //  Check that the nested loop for storing the SPDPulse2 has been set
          SPDPulse1 = SPDPulseNow - SPDPulse2;      //  Time interval between the last pulse and this pulse
          SPD = (706000 / SPDPulse1) * SpdCor;      //  CALC to MPH
          SPDPulse3 = SPDPulse1;                    //  Save SPDPulse3 for next loop
        if (SPDPulse4 >= 0) SPDTimeChange = (SPDPulse4 - SPDPulse3);  //  Check that the nested loop for storing SPDPulse4 has been set - calculate difference in PW from prev loop and curr loop
        if (PrevSPD > 0){
          SPDDiff = (SPD - PrevSPD); //  Check that PrevSPD has been set, then calculate the change in speed between the previous set of pulses vs. current set of pulses)
          SPDLoop = true;                           //  Boolean set to indicate to other routines that the full nest of routines have completed
        SPDPulse2 = SPDPulseNow;                    //  Store Current TIME to SPDPulse2
      OLDSPDPulse = micros();     //  set variable at current time to begin the nested looping for future speed sensor triggers

  2. #2
    Senior Member
    Join Date
    Jul 2020
    I believe that library can use DMA, so if its doing DMA transfer of the frame buffer its going to be
    asynchronous of the processor whatever its doing. Otherwise it may interrupt it (or if interrupts
    are disabled, it will be delayed - I don't know enough about that library to know which).

    I think what you may be thinking/worrying about is the need to use a critical section to interface
    to the ISR from the program body. To see a consistent state you have to defer interrupts while
    you are accessing the variables shared between your ISR and main program (which must be all
    declared volatile, incidentally, but I can't tell as you've not followed the forum rule...)

    So typically you'd go noInterrupts(), then read the variables into local copies, then go interrupts()
    immediately. Thereafter you can safely use the local copies as you like.

  3. #3
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    As mentioned: the updateScreen does it synchronous... That is it does not return until it completes.

    However the updateScreenAsync() uses dma to update the screen. Calling it, will simply start up the Update screen code (setup the update rectangle and write memory command), and then it will hold it over to the DMA code to output the rest. There is also an option to keep the code updating the screen for multiple frames... However there are issues you need to be aware of when you do so...

    The Readme file:
    describes some of these members... It could use anther pass through to clean it up and extend some of the descriptions... But I am only doing it for the fun of it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts