Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: 9-bit UART with non-standard baud on a teensy 3.5?

  1. #1
    Junior Member
    Join Date
    Dec 2014
    Posts
    12

    9-bit UART with non-standard baud on a teensy 3.5?

    Hi,

    I'm working on a project to man-in-the-middle a half-duplex serial bus (where tx and rx share a wire) between some Intel 8031 microcontrollers in an old IBM wheelwriter typewriter. Generally, the project is to intercept bytes coming from the keyboard controller, decode and send them to a serial port to an external computer, receive bytes from the external computer, and re-encode and send them to the motor-driver part of the typewriter. The protocol involves sending some bytes, and having them ACK'd (mostly by an all-zero response). According to my logic analyzer, the data appears to be using the so-called mode 2 of the 8031 uart, where a ninth bit is used to indicate whether the 8 preceeding bits are an address of a slave microcontroller. I read that the teensy 3.5 supports a 9-bit mode that would seem to be compatible, but the bit rate the typewriter is using is something around 190k, not one of the standard ones. To complete the man-in-the-middle, I'm wanting three UARTs, one to talk to the keyboard controller, one to talk to the motor-driver board (both talking 190k 9n1), and one (115200 8n1) to talk to the external computer.

    What am I going to need to do to support the weird baud rate and a normal one at the same time?

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,929
    For 9 bit mode, you'll need to edit HardwareSerial.h, to uncomment this line:

    Code:
    // Uncomment to enable 9 bit formats.  These are default disabled to save memory.
    //#define SERIAL_9BIT_SUPPORT
    For unusual baud rates, just use Serial1.begin(baud). All 6 serial ports on Teensy 3.5 support high-res baud rates, so 190000 should be fine. Each port can have a different baud rate, but on the same port, transmit and receive always run at the same baud.

    Serial1 and Serial2 have FIFOs, so best to use those ports for the streams you expect to carry the most data. But 190k is pretty slow, so don't worry too much. The FIFOs are really only critical when you use megabit range baud rates.

  3. #3
    Junior Member
    Join Date
    Dec 2014
    Posts
    12
    Awesome. I'm mostly on my way. I'm currently thinking about how to deal with the combined rx/tx line. I'm thinking about running the transmit through a open-collector transistor arrangement, to pull the data line low (using SERIAL_9N1_TXINV) and tying the rx to the data line, but I'm anticipating that I'll probably see my own transmitted bytes on the rx. Is there any clever solution to this? I saw LOOPS and RSRC in Section 47.3.3 of https://www.pjrc.com/teensy/K20P64M72SF1RM.pdf. Relevant?

  4. #4
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,565
    I have used the half duplex code with a T3.x for Robotis Servos (Dynamixel)... It uses the TX pin for the Usart

    So at my init code, yes I do set the Loops and in my case I enable the Pullup resistor on the TX pin
    Code:
            UART0_C1 |= UART_C1_LOOPS | UART_C1_RSRC;
            volatile uint32_t *reg = portConfigRegister(tx_pin);
            *reg = PORT_PCR_DSE | PORT_PCR_SRE | PORT_PCR_MUX(3) | PORT_PCR_PE | PORT_PCR_PS; // pullup on output pin;
    When I wish to TX: on the pin I do something like:
    UART0_C3 |= UART_C3_TXDIR;

    And to go into RX mode:
    UART0_C3 &= ~UART_C3_TXDIR;

    This is assuming Serial1... You would need to change which register for other Serial ports

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •