• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 212 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.

IWR1843: UART_MODE_CALLBACK in SDK 03.05.00.04

Javier Fernandez
Prodigy 152 points
Part Number: IWR1843

Hi,

I have found references about UART_MODE_CALLBACK atribute on Texas Intruments documentation. However, in SDK 03.05.00.04 it is only explained the blocking mode:

Is there any way to perform non-blocking readings in SDK 03.05.00.04?

Moreover, in the documentation is explained something related to an interrupt: "Function that reads data from a UART with interrupt enabled". Which is this interrupt?

Best regards,

Javier

  • 0
    TI__Genius 14415 points

    Hello Javier,

    What are you trying to do with a non-blocking UART read? Are you encountering errors when reading? The blocking is lower in the UART driver and just blocks until the read has happened. This isn't typically a setup parameter that is modified.

    Regards,

    Jackson

  • 0 in reply to Jackson Thomas
    Prodigy 152 points

    Hi Jackson,

    Firstly, thank you for your quick answer.

    Regarding your question, I need a non-blocking UART because my program do more tasks than reading from de UART. I started from SRR example and now I have to read from the UART to get some information. Considering the second question, I am not encountering errors, but I do not want to wait until fill the buffer to do the rest of the task, maybe puting this reading in a separated task, it could be a better approach?

    The problem that I see with UART_read() or UART_readPolling() is that you will wait until you fill the buffer or you receive the new line character, and if there is any problem in the communication bus you will be blocked for ever. Can be configured any timeout policy?

    I saw the non-blocking implementation here but It looks like for other HW.

    Thank you for your support,

    Regards,

    Javi

  • 0 in reply to Jackson Thomas
    Prodigy 152 points

    Hi Jackson,

    I update the issue with the new improvements. Currently I am using UART_read() mthod with the following configuration:

    And I perform the reading like this:

    If I send an array of 40 characters, for instance, I only receive 20 characters (As I configured that size in the method) and then get blocked again in UART_read(). But I do not get the next 20 characters pending, it looks like just disappeared.

    Also, I try to change the reading size to 1, but, if it does not trigger as many times as the number of character sent. For example, if I send a 20char array, the UART_read method only return 4 times.

    Is it the expected behaviour or what I am doing wrong?

    Thank you for the support,

    Javier

  • +1 in reply to Javier Fernandez
    Prodigy 152 points

    Hi,

    I just found the issue, the problem is "System_printf()" method, it can not be called after a "UART_read()".

    Also I found a timeout variable inside of UART parameters.

    And I think that there is only one approach when is used the UART_read(). The non-blocking method is not implemented. Maybe here Jackson can throw light on it.

    Regards