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

TM4C1294NCPDT: uart echo example in 9 bit mode

Priya Nadathur70
Expert 2795 points
Part Number: EK-TM4C1294XL


Can the uart echo example be set up in 9 bit mode?

At this time, I don't have a slave address to set up. Do I still need to use the UART9BitAddrSet

before UART9BitEnable? UART5_BASE is the master, the slave is a dummy address.

I added the UART_INT_9BIT mask when enabling the uart interrupt.

I have the uart and PuTTY setup for odd parity.

When I run the project, I see enter text. When I begin typing, the LED starts to blink and then stops.

No text is displayed. Maybe 9 bit mode won't work for text at all?

Thanks,

Priya

  • 0
    Guru 27665 points
    What are you trying to do?

    9-bit mode doesn't make sense for a terminal application. 9 bit mode is for network applications.

    Robert
  • 0
    TI__Guru**** 191906 points
    Hi Priya,
    The PuTTY does not know the master is operating in 9bit mode so it is treating the 9th bit as a parity bit. Likely it fails the parity check. Try disable parity check and see if it makes a difference.
  • 0 in reply to Charles Tsai
    Expert 2795 points
    I have just the EK at this time-- EK-TM4C1294XL, no external peripherals yet. I'm not seeing any options in PuTTY to disable parity checking. Do you know of any?

    I tried setting parity to ODD and NONE, neither option works. With ODD parity, I set the PuTTY parity also to odd.

    ROM_UARTConfigSetExpClk(UART5_BASE, g_ui32SysClock, 115200,
    (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
    UART_CONFIG_PAR_NONE));

    UART9BitAddrSet(UART5_BASE, 0x00, 0xFF);
    UART9BitEnable(UART5_BASE);

    //
    // Enable the UART interrupt.
    //
    ROM_IntEnable(INT_UART5);
    ROM_UARTIntEnable(UART5_BASE, UART_INT_RX | UART_INT_RT | UART_INT_9BIT);

    Thanks,
    Priya
  • 0 in reply to Priya Nadathur70
    Guru 10570 points

    Priya Nadathur70 said:
    I'm not seeing any options in PuTTY to disable parity checking. Do you know of any?

    There probably aren't any. The standard PC UART doesn't support 9-bit operation*. It also doesn't make sense for a terminal. What are you trying to accomplish?

    Robert

    * It can be emulated with parity modulation but even realterm doesn't support that AFAIK.

  • 0 in reply to Robert Adsett72
    Expert 2795 points
    I figured the keyboard can't do 9 bit mode, and maybe not the putty either. I am waiting for a peripheral device to implement the MDB protocol with the 9 bit uart.
  • 0 in reply to Priya Nadathur70
    Guru 10570 points
    You could do a lot of testing using two boards while you are waiting. Also it looks like you need to design and test a transceiver for use with the protocol.

    Robert
  • 0 in reply to Robert Adsett72
    Expert 2795 points
    Robert-- At this time I only have one board the EK TM4C1294XL. I'm assuming the peripheral will come with some firmware in it for the MDB. I will think more about the MDB messages. Feel free to add pointers.
    Thanks,
    Priya
  • 0 in reply to Priya Nadathur70
    Guru 10570 points

    Priya Nadathur70 said:
    I'm assuming the peripheral will come with some firmware in it for the MDB

    If it's sold as an MDB device, it should. You will however still need to design, build and test a transceiver.

    Robert

  • 0 in reply to Robert Adsett72
    Expert 2795 points
    I have been thinking along those lines, may have more questions for later. Thanks!
    Priya
  • 0 in reply to Priya Nadathur70
    Guru 10570 points
    A second board would still be useful, you can test things using two boards that are difficult or impossible to test with just one board and a peripheral. Besides you need multiple boards to guard against single board faults and to act as backups.

    Robert
  • 0 in reply to Robert Adsett72
    Guru 117855 points

    Robert Adsett72 said:
    You will however still need to design, build and test a transceiver.

    We are wondering if (reasonably) normal RS-485 transceivers - intended for use when "multiple devices appear" - might, "speed & ease" poster's challenge.

    It would seem that, "all RS-485 bus connected devices (must) be able to receive at (all) times."    (i.e. so that they do not "miss" (either) a "broadcast" message or one addressed (only) to them.)

    In contrast - always & only - ONE transceiver should be "enabled" to transmit.     (so as to avoid bus contention)      Most such RS-485 transceivers (beyond the most basic ones) provide a separate, "output enable" pin and/or similar means - to strictly control "when" transmission is allowed.

    IIRC - one "missing link" here is when another device "starts transmitting" and "receiver software" is too slow (or unable) to detect this - and then that (second) device starts transmitting - as well...  (causing the dreaded "bus contention.")

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:

    We are wondering if (reasonably) normal RS-485 transceivers - intended for use when "multiple devices appear" - might, "speed & ease" poster's challenge.

    It doesn't appear so. A quick read says the MDB (multi Drop Bus) uses a 12V or higher open collector one wire bus. I don't know why they didn't use RS-485, either it wasn't contemporary or they wanted to save a few cents per connection and a dollar or two in wiring.

    cb1_mobile said:
    It would seem that, "all RS-485 bus connected devices (must) be able to receive at (all) times."    (i.e. so that they do not "miss" (either) a "broadcast" message or one addressed (only) to them.)

    cb1_mobile said:
    IIRC - one "missing link" here is when another device "starts transmitting" and "receiver software" is too slow (or unable) to detect this - and then that (second) device starts transmitting - as well...  (causing the dreaded "bus contention.")

    It's a master/slave bus so contention should not be an issue and I didn't see any note of broadcast. Broadcast in such a system usually doesn't allow replies.

    That is a reason you would want a second board to check for 'impossible' conditions though.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points
    Ouch! I have proved my "MDB" illiteracy... (always "diplomatic" staff notes that "MDB" stands (not) quite alone...)