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

Status
Not open for further replies.

russell

Member
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?
 
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.
 
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?
 
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
 
Status
Not open for further replies.
Back
Top