• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 34 subscribers
  • Views 4235 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.

RTOS/TM4C123GH6PM: Bridge two UART interfaces

Volker Weber
Intellectual 570 points
Part Number: TM4C123GH6PM


Tool/software: TI-RTOS

Hi,

i was just wondering (again :-) ) if there are any RTOS tools to tunnel a UART interface to another. Right now I am handling this with different threads and UART_read functions in UART_MODE_BLOCKING mode. I could use the UART_MODE_CALLBACK to prevent a blocking thread from processing, what I actually have to do if I want to break the blocking read. Could this be prevented or done an easier way?

\edit: Changed thread title from "tunnel" to "bridge" but left the description as it was

  • 0
    TI__Guru* 96960 points
    HI Volker,

    I'm not clear what you mean by tunneling here. I understand tunneling in general (e.g. sending one protocol across a different protocol), but don't see what you are trying to do. Can you give some more details? For example, when you say "tunnel a UART interface to another", what explicitly does "interface" mean here...a specific UART peripheral (e.g. UART7 on a TM4C12x device)? Also what is "another"...another UART or another peripheral.

    Todd
  • 0 in reply to ToddMullanix
    Intellectual 570 points

    Hi Todd,

    I admit that I was a little unclear about my question. For clarification: I just want to pass one UART input and output to another UART and vice versa, e.g. UART 0 to UART 1 on my TM4C12x device. As a result, the two participants on the two mentioned UART lines can "see" each other directly through the TM4C12x but I am able to "sniff" the data packets transmitted. I think you can speak of a link, but I am missing the correct term here.

  • 0 in reply to Volker Weber
    Guru 13040 points
    Volker,

    Not coming from a RTOS point of view, if the destination handles same or faster speed than the incoming, the most simple solution is to add a UARTCharPutNonBlocking() for each byte read from the Rx FIFO buffer. That can be stripped down to a instruction that is probably only 3-4 clock cycles... (wild guess to illustrate it is really simple)

    Are both uart's running on the same speed? If the output is slower, you'll need a buffer (in case you are receiving sporadic packages that can be stored and forwarded), or of course you things will collapse if the incoming is continuous.

    If you want to enable/disable this tunneling during run time, and would like to avoid one decision point for every byte received, you could test writing two different ISR's: one that forwards the bytes and the other that only captures them to your memory, and register the adequate one when the tunnel is set on/off. Such probably applies for the RTOS environment as well.

    Bruno
  • 0 in reply to Bruno Saraiva
    Intellectual 570 points
    Hi Bruno,

    thanks for your detailed answer, I really appreciate it.

    The RTOS-Driver for UART handling has a similiar handling to the low-level implementation: you can establish it with a non-blocking behavior. As in my example both are running with the same speed (I don't consider cases with different speeds), I do not have to care about buffering. Furthermore the µC has enough time to complete its task before the next message arrives.

    In my current implementation I do nearly the same things that you describe: two different task handle the two data directions. It works, but is not totally tested. As a result I wondered, if the RTOS can provide any means to handle this actions itself.

    Volker
  • 0 in reply to Volker Weber
    Guru 13040 points

    No worries!

    Volker Weber said:
    I wondered, if the RTOS can provide any means to handle this actions itself.

    I would not expect so. Whatever actions the RTOS driver does, they are just a sequence of program lines. I understand that TI-RTOS has some pre-made solutions that include UART Rx/Tx with buffers and even DMA, but it is nothing magic in ROM.

    If you are not using "line-by-line" Tivaware commands to manage your uart, but rather a higher level TI-RTOS library, can't you open the source code and take a look? Also, there is the equivalent to the "Driverlib User Guide" for TI-RTOS as well, and the existing functions are (I assume) all listed there... What do you think?

    Bruno

  • 0 in reply to Bruno Saraiva
    Intellectual 570 points

    Hi Bruno,

    thanks again. I looked into the implementation but didn't find a hint for this functionality. Nor does studying the documentation. I am always a little bit uncertian about the completeness of the User Guide, so I started my inquiry here. Anyway, I will stay with my implemented solution as I was able to entirely test it. Furthermore, I marked your last answer as the solution.

    Again, grazie mille.

    Volker

  • 0 in reply to Volker Weber
    Guru 13040 points
    Prego!

    And per other's pertinent suggestions here, maybe you want to avoid using the term "tunneling" for that purpose, just so that your team don't get confused in the future. As for the choice of denomination... maybe "port forwarding"?
  • 0 in reply to Bruno Saraiva
    Intellectual 570 points
    Hi Bruno,

    yes, I already changed that in my documentation and paraphrased it. However, I am not happy with other terms like e.g. my suggestion with "link". Perhaps a bridge?
  • 0 in reply to Volker Weber
    Guru 13040 points
    Sure, I like "bridge".
    :)

    If no one here screams against it till the end of the day, maybe you should edit the thread title to use it.
  • 0 in reply to Bruno Saraiva
    Intellectual 570 points

    Done.

    Coming from processes and data flow, the term "pipe" could also apply here. Nevertheless I will stay with "bridge" now (-:

  • 0 in reply to Volker Weber
    Guru 27665 points
    aha!

    From that improved description. It won't be built-in to the driver but the RTOS will have IPC primitives to support this (pipe, fifos or queues).

    Robert
  • 0 in reply to Robert Adsett
    Guru 117855 points
    "Tunneling" far better (and understandably) describes the method of "crossing from Jersey to NYC" - when (not) Bridging...
  • 0 in reply to Robert Adsett
    Intellectual 570 points
    Thanks for another confirmation and indeed: the TI RTOS provides some useful tools with which die data streams are really easy to handle.