• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 1574 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C UART_Params_Init Read Timeout

Eric Kaltenbacher
Intellectual 480 points

Other Parts Discussed in Thread: TM4C1294NCPDT

I'm using the UART_Params_Init() function to initialize com ports on a TM4C1294NCPDT.  What timer is used for the read timeout initialized with this call?  Does the external peripheral interface contain its own timer hardware, or does it utilize one of the eight timers in the general purpose timer module?

Thank you!

Eric

  • 0
    TI__Guru**** 244440 points
    Moving it to the TI RTOS forum
  • 0
    TI__Genius 10260 points
    Hi Eric,

    Opening a UART driver instance does not use a timer. The timeouts are actually how many system clock-ticks to wait before unblocking and returning, so the timeout is only dependent on the system clock. By default the TM4C1294NCPDT uses 1 peripheral timer as the source for the system clock.

    Hope this helps,
    -- Emmanuel
  • 0 in reply to Emmanuel Trinidad - Alicea
    Intellectual 480 points
    Thanks Emmanuel.

    I believe the TM4C parts utilize Timer0 by default for the BIOS clock ticks - is this true?. I was planning on using the BIOS clock to post semaphores to a few tasks at a slow rate (.5 Hz). If I understand correctly, I'll need to create a clock using a different timer so I don't mess with the operation of the UART blocking.

    Eric
  • 0 in reply to Eric Kaltenbacher
    TI__Genius 10260 points

    Hi Eric,

    Yes, the BIOS clock will use ANY by default, but if no other timer is created in your *.cfg file it will use Timer 0.  

    Eric Kaltenbacher said:

    If I understand correctly, I'll need to create a clock using a different timer so I don't mess with the operation of the UART blocking.

    Not necessarily, (Warning: a simplified explanation) when the clock ticks it verifies if there is anything which needs to be unblocked/executed (like pending Semaphores with timeouts, sleeping Tasks, Clock objects, etc).  All objects which are unblocked run based on priorities.  So for example, if a SWI & your UART_read() unblock at the same clock tick, the SWI will execute first (higher priority) and the task which called UART_read() will resume execution after the SWI.  If this is acceptable, then you need not worry about interference.

    As for posting semaphores at separate frequencies you have a couple of options:

    • If semaphores are to be released in multiples of clock ticks, you could create clock objects which will execute a function periodically (or one-shot).  These objects rely on the system tick, so effectively you only use 1 peripheral timer.
    • You can create Timer instances for each function (each with it's own period) which will post the semaphores.  In this scenario, you would use as many timers as you would functions to post semaphores.

    Hope this helps,

    -- Emmanuel