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.

CCS/CC2640R2F: CC2640R2 programming problem

Part Number: CC2640R2F

Tool/software: Code Composer Studio

We are trying to use TI RTOS UART code on the CC2640R2 processor to send and receive RS232 data on an external device.  The problem is that the device immediately echoes the data as it receives it, and then appends its response.  In other words, UART data comes back from that device before we finish the UART_write() command in our code.

There may be more than one way to handle this, but it seems that we must use the nonblocking mode of either the UART_read() or the UART_write() command.  Let's say we made the READ nonblocking.  That would mean we'd code it like this:

-Start the Read nonblocking
-Start the Write (blocking)
-Handle the Read data when the read finishes

Reading what documentation I can find, it says:
1. Create another task
2. Put the nonblocking read function in that new task
3. Point params->readCallback to that function

4. When the nonblocking read function is called by the hardware interrupt when the read is done, it sets a semaphore that tells the main task that the read data is available
5. The main task then gets the data

I've scanned through E2E and other TI documentation.  This should be simple, but I cannot find a simple example.  So here are some basic questions.  I'm probably not the only person who would like a nice, simple, all in one place example of this to follow in their code.

Some basic, simple questions:
1. How do I create another task and put the nonbocking read function in it?
    A.  After that readback function is called, what happens to that task?
    B.  Does it do a return at the end of that readback function?  If so, where does it return to?
    C.  Should the main task delete that task when the read is finished?  If so, how?
    D.  Should the main task then recreate that task every time it wants to do another nonblocking UART Read?

2. The documentation refers to semaphores.
    A.  How do we create them?
    B.  How do we make sure that both the main and the newly created readback task access the exact same semaphore?  They might create different instances of it and thus not communicate
    C.  Do we need to recreate the semaphores each time we create the readback task?

3. Some other unanswered questions.
    A. The data read back in our case is of undetermined length, and has multiple carriage returns in it.  We should be able to terminate the read with a timeout after a reasonable time and get all the data.  There is a value called readTimeout that I think we can use.  What units is that in?  Microseconds, milliseconds, seconds?  Why not put that information in the description in the header file?

A simple example of all the above could be in one place in response to this question.  It could include an example of how to do everything I asked above.  It could help other people searching for answers on how to set up and use UART commands in the nonblocking mode.

Thanks for any help you can give.
Dan Benkman
Innowave

  • Hello Daniel,

    You can use the UART callbacks to transmit and receive data. Did you refer the following forum post? It has an example code that shows how to configure and use UART Read callback.

    Thanks,

    Sai

  • That E2E message about call backs is unclear, at least to me.  There is no sample code of how to set up callbacks, no sample of how to create a task in which to put a callback function, no sample code on how to finsh when the callback is handled.

    I have a different, more basic issue now..  When doing a UART_Read(), the data received is actually from the previous read.  If I number the messages being sent, then the message being read back contains the data from the previous message.  For example:

    Send msg 1
    Read msg 1  The data read back is garbage

    Send msg 2
    Read msg 2  The data read back is from message 1, not from message 2

    Send msg 3
    Read msg 3  The data read back is from message 2, not from message 3

    Send msg 4
    Read msg 4  The data read back is from message 3, not from message 4

    If I now try this:
    Send msg 5

    Send msg 6

    Send msg 7
    Read msg 7 The data read back is from message 4, not from message 7

    In other words, the message returned from the UART_Read() is from the last read message, not the current message.  It's like the UART_Read() does this:
    -Return the local read buffer contents to the caller 
    -Then fill the local buffer with the new read data

    Is this the way it is supposed to work?  Is there any way around this?

    Thanks for your help.
    Dan Benkman
    Innowave

  • Hello Daniel,

    Daniel Benkman said:
    Send msg 1
    Read msg 1  The data read back is garbage


    How you initiated the read buffer?

    Daniel Benkman said:
    That E2E message about call backs is unclear, at least to me.  There is no sample code of how to set up callbacks, no sample of how to create a task in which to put a callback function, no sample code on how to finsh when the callback is handled.


    The referred E2E topic provides this link: dev.ti.com/.../_u_a_r_t_c_c26_x_x_8h.html

    Sample code is there.

  • I was trying to do a nonblocking write followed by a read.  The data coming back from a UART write to the chip we are interfacing with does an echo and sends back its response immediately.  The UART read does not appear to work correctly during a nonblocking UART write.

    I found that we can do a nonblocking UART read before starting the blocking UART write, and the read will in fact read the data, even as it comes back during the write.

    I also found that a nonblocking read can indeed have a timeout, so that it can stop reading even if it doesn't receive the number of characters it requested.  We need that feature, because we don't know exactly how many characters we will get, and we don't want the read to not terminate if it doesn't get the number it requested.

    So once again I figured out how to handle our problem without E2E's help.  I guess I'll mark this as resolved.