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.

Custom UART driver for use in TI-RTOS



I need to interface to a radio module, namely an ANT AP2 module that has some specific requirements for serial communications. The module needs the host to obey the RTS line, which it uses to signal when it can accept more data, and when a message was received. It also has "sleep", "suspend" and "reset" lines that are used for low power states, resetting the module and the like. I should point out that the RTS is not strictly standard.

In the past, I created a driver that operated from the MSP430 interrupts and controlled these signals. Now, the new project is based on the MSP432 and TI-RTOS, and since the RTOS is a new concept for me, I am not sure the best way to proceed.

Would I be better to

1) try and create a new "UART.c/h" and "UART432.c/h" to handle the timing on the IO lines, and try to recreate the RTOS driver for my application

2) Use an Hwi (34) to catch the uart rx and tx interrupt and use more traditional techniques in parallel with the RTOS, and not use the TI-RTOS UART driver, but MSPWare instead.

3) Use some hooks in the RTOS (I can't find any at a character level) to block the sending of characters from the TI-RTOS ring buffers to the hardware when not allowed by the module

4) other (please suggest)

I am not keen on 1), as these are likely to change as upgrades and bugfixes in the RTOS are implemented, and these may break the driver in unusual ways, plus ensuring the RTOS remains stable may be above me.

Many thanks,

Josh

  • Josh,

    There are pros and cons for the options you list.  I’d say that if the functionality of the UART driver provided by TI-RTOS is close to what you want, to clone that to create your own driver, and add the special RTS and state control logic.  But if the existing driver has more features than you care about, to just go with approach #2.  

    It ultimately depends on your use case and plans to carry this forward.

    As far as the UART.h definitions – I don’t think there are any plans to change the top level UART APIs any time soon.  There were many discussions to come up with this API definition, with the intent that it would be fixed for the forseeable future.

    I know this isn’t a very definitive answer, but hopefully it helps some...

    Regards,
    Scott