• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 3787 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/MSP432-RTOS: Data lost when different tasks are reading data from different UARTs

user4996012
Prodigy 210 points
Part Number: MSP432-RTOS

Tool/software: TI-RTOS

We’re encountering an UART issue in TI-RTOS during  application debugging.

There’re two tasks assigned with different priorities, the high priority task (let’s say task A) is reading & handling commands from UART1, the low priority task (let’s say task B) is reading & parsing GPS data from UART2. When task B is reading data from UART2, task A cannot read any data from UART1 even if task B completed reading data. It looks that the data reached to one UART will be lost when another task is reading data from another UART.

Could you please looke inside this issue?

Thanks,

Tony

  • 0
    Guru 35680 points
    I suggest you implement a circular buffer:
    www.simplyembedded.org/.../
  • 0 in reply to Keith Barkley
    Prodigy 210 points

    Thanks Keith. It's very helpful for understanding the root cause and implementing the solutions without OS.

    We're using TI-RTOS, I suppose the OS should already implement circular buffer for UART.  In addition, the high priority task should preempt low priority task when data is ready to read. However no data can be read in the high priority task. It looks like this is an issue of the OS.

  • 0
    Intellectual 420 points
    It depends how UART driver implemented in your RTOS.
    If receive code is implemented as

    while (!UART_DataAvailable(UART1_BASE));

    no one RTOS will correctly handle this situation. In multithreading application you should highly rely on interrupts and semaphores. So, if you're using interrupt based receive, you should enable interrupt and wait for semaphore, interrupt handler should signal the semaphore and RTOS scheduler will execute task preemtion.

    Another way to do simultaneous communication is to use DMA. You can check available data by software timer and "transmission completed" interrupt.
  • 0 in reply to Dmitry Sharihin
    TI__Guru* 96960 points

    What are the priorities of the two tasks (look in Tools->ROV->Tasks->Detailed to confirm on the target)? Why do you say the higher priority task is blocked by the lower one? Can you confirm this in ROV or does it just seem like it is?

    Todd

  • 0 in reply to user4996012
    Mastermind 8905 points

    In general, RTOS only means the kernel providing multi-tasking and inter-task communication. Unlike Windows or Linux which already built-in a lot of "drivers". In RTOS, the driver is independent from the kernel. So, don't mix them up.

    TI have provided some drivers based on TI-RTOS. But, you can (should?) design your own drivers to have better efficiency and to meet your use-case. To design a device driver, e.g. UART driver, you should keep in mind: don't block CPU when there is no need. For example, this following is really bad:

    while (!isReady);

    And this is better:

    while (!isReady)
    sleep(10);

    where sleep(10) is a kernel API to tell kernel that this task won't use CPU for 10ms. Well, all RTOSes have their own version of sleep(). Check the TI-RTOS documentation for correct API name.

    And the following one is the best:

    if (semaphore_pend(&uart_sema, 1000)) {
    // got data

} else {
    // timedout after 1000 ms
}

    No CPU time is wasted if you use semaphore and interrupt service routine (ISR) to design the device driver. Again, check TI-RTOS documentation for correct semaphore API names.

    I don't use TI-RTOS so I can't give you a ready-to-test example. But the basic concept is the same.

  • 0
    TI__Mastermind 26380 points
    Tony,
    Just following up here to see if you have the issue figured out or had any follow up questions?
    -Priya

**Attention** This is a public forum