This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EK-TM4C123GXL: Shortest Possible "Wait" Time?

Part Number: EK-TM4C123GXL

Hi all, a question about the shortest amount of time one can "wait" using the TM4C123G.  The processor can be configured to run at a max speed of 80 MHz using the following:

(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN);

...and the shortest way I know to "wait" is to use:

SysCtlDelay(1);

So, if the processor is running at 80 MHz, that means 12.5 nanoseconds per cycle.  But clearly a line of code will take more than one cycle to execute and, if I understand correctly, an assembly instruction will take more than one cycle to execute.  For what it's worth the assembly of the SysCtlDelay(1) line of code is this:

SysCtlDelay(1);
0000057a: 2001      movs  r1, #1
0000057c: F000F958  bl    #0x830

SysCtlDelay():
00000830: 1E40      subs  r0, r0, #1
00000832: D1FD      bne   SysCtlDelay
00000834: 4770      bx    lr

The way I time sections of code is toggling a pin which is hooked up to my logic analyzer.  Example code: 

while(1)
{
   GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_7, 0x80);
   SysCtlDelay(1);
   GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_7, 0x00);
   SysCtlDelay(1);
}

^This is simply setting the PA7 pin high and then setting it low with the shortest possible wait in between.  When measuring this with my logic analyzer I see the pin is high for 280 nanoseconds and then low for 360 nanoseconds.  I suppose that seems about right, agree?  This would mean the little block of assembly above, plus whatever assembly is required to toggle the pins on/off are taking roughly a few hundred nanoseconds, or cycle wise, ~300/12.5 = ~24 cycles.

Just wondering if my analysis here is correct and if there is any other way to wait for a shorter period than a few hundred nanoseconds?

  • Apologies, I messed up embedding the first two snippets of code above and it appears I cannot edit.  Those two snippets of code are:

    (SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN);

    and

    SysCtlDelay(1);

  • Terence D said:
    ... toggle the pins on/off ...  is any other way to wait for a shorter period ...?

    I've combined two of your sentences to illustrate that which I believe to be unclear.      It is suspected that you seek:

    • highest achievable GPIO Toggle Speed
    • or the creation of the shortest "wait (delay)"

    Highest toggle speed results from employing the MCU Timer in its PWM Output mode - this should approach 1/2 of "F_System_Clock."

    To achieve a consistent and (even) shorter "delay" - again the Timer - usually set in "one-shot" or "periodic mode" - seems to best serve that need.

    Note that if you, "back to back" your earlier "4 function calls" - say by a factor of 5 (so that 20 code lines result) the impact of the "while" will be reduced and the toggle rate improved...

  • cb1 - Thanks for the quick reply!  Apologies, I should've been more clear.  Let me cut right to the chase at what I'm after.

    If you would, please recall this recent thread, where you very kindly gave me advice on LCD displays and recommended NHD-14432WG-ATFH-V#T-ND which I promptly purchased and received a few days ago and have now been trying to get to work.

    What I'm currently struggling with are the timings on the timing diagram shown on page 8 of the datasheet.  The width of the "enable pulse width", "Tpw" is only 140 nanoseconds.  Am I misreading or misunderstanding this?  I'm not sure how I'm supposed to accomplish having such a brief low-to-high-back-to-low transition.

    Any thoughts?

  • Terence D said:
    What I'm currently struggling with are the timings on the timing diagram shown on page 8 of the datasheet.  The width of the "enable pulse width", "Tpw" is only 140 nanoseconds.  Am I misreading or misunderstanding this?

    The timing tables in the NHD-14432WG-ATFH-VT datasheet are confusing since they are missing the column headings to indicate which of the columns are the Min, Typical or Max values:

    Traditionally the first column of number are the Minimum values, the second column are the Typical values and the third column are the Maximum values.

    If you follow the link to the ST7920 controller data sheet, the ST7920 data sheet shows the timing as:

    What this means is that the width of the "enable pulse width" pulse needs to be greater-than-or-equal to 140 nanoseconds. I.e. you can generate a "enable pulse width" of longer than 140 nanoseconds.

  • Terence,

    Not to overrule the other comments here - which are much more relevant for the "real issue" - but just to add a direct answer:

    The ROM_ version of SysCtlDelay() is guaranteed to take 3 CPU cycles.

    Of course, it is still non deterministic, because you can never be sure that your processor is not doing something else, like serving an ISR, in the meantime... (well, actually, you could turn off global interrupts - but this will eventually cause problems elsewhere).

    Bruno
  • Chester Gillon said:

    The timing tables in the NHD-14432WG-ATFH-VT datasheet are confusing since they are missing the column headings to indicate which of the columns are the Min, Typical or Max values:

    ...What this means is that the width of the "enable pulse width" pulse needs to be greater-than-or-equal to 140 nanoseconds. I.e. you can generate a "enable pulse width" of longer than 140 nanoseconds.

    Doh!  Thank you, Chester.  I had looked at the ST7920 datasheet but missed the table there that was placed near the end of the document ( page 40 of 49).

  • Bruno Saraiva said:
    Terence,

    Not to overrule the other comments here - which are much more relevant for the "real issue" - but just to add a direct answer:

    The ROM_ version of SysCtlDelay() is guaranteed to take 3 CPU cycles.

    Of course, it is still non deterministic, because you can never be sure that your processor is not doing something else, like serving an ISR, in the meantime... (well, actually, you could turn off global interrupts - but this will eventually cause problems elsewhere).

    Bruno

    Thank you, Bruno.  I'm curious where you found this information?  Also, I'm curious what books or other documentation you or others might recommend for best understanding the internals of how the ARM Cortrex-M4 works?

  • Terence D said:
    Thank you, Bruno.  I'm curious where you found this information?

    Entry "26.2.2.10 SysCtlDelay", page 493, of SW-TM4C-DRL-UG (User Guide), found in the /docs folder of your TivaWare installation.

    That's 708 pages of good fun. Once you're done with that, enjoy the utils guides, and other docs of the same folder - much better than reading the "Great Again" best seller...