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.

TMDS62LEVM: Question about UART init for RTOS SDK

Part Number: TMDS62LEVM

Tool/software:

Hi,

I have a question regarding UART_init() function, or any other similar functions for other peripherals

From TI's example code perspective, it looks like the prefer way is to initialize all needed uarts at once. However, for our use case, we will only initialize one uart at a time, while keeping the debug uart on all the time so can print some error msgs like "overrun" etc., which is more a structure like

user_uart_init(uartn)

{

       initialize uart pin based on uartn ;

       enable uart clk based on uartn;

        UART_init();

        UART_open();

        return uart_handle;

}

user_uart_init(console_uart);

user_uart_init(uart5);

Will the mutex gUartDrvObj in the driver cause some potential unexpected behaviors if we initialize one by one? Like when uart5 is communicating in interrupt mode/polling mode but get some errors, debug uart won't be able to print?

Thanks,

Dazong

  • Hi,

    Thanks for your patience, as it was weekend, hence commenting on your question right now.

    Will the mutex gUartDrvObj in the driver cause some potential unexpected behaviors if we initialize one by one? Like when uart5 is communicating in interrupt mode/polling mode but get some errors, debug uart won't be able to print?

    Allow me sometime to look into the implementation and comment on the same.

    Regards,

    Vaibhav

  • Hi,

    Here are my comments.

    Like when uart5 is communicating in interrupt mode/polling mode but get some errors, debug uart won't be able to print?

    My initial answer would be a NO, there should be no problem the reason being

    /* Create instance lock */
    status = SemaphoreP_constructMutex(&object->lockObj);

    Seperate instance lock is created hence no overlapping between multiple instances of UART.

    A nice way to check this would to create a test case where, one UART fails and the other one keeps going on.

    To test this out you would need to create two instances of UART both on two different threads, hence it can be a Multithread application, once done, you can then check for the same.

    Regards,

    Vaibhav