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.

MAX232: Device recommendation to pair with MAX232 for data and clock generation

Part Number: MAX232
Other Parts Discussed in Thread: TCA5405, SN74LV8153, TSU6111A, TCAL9539-Q1

Hey Interface team,

I have a customer working on a project and we were hoping to get your advice on possible solutions to a design challenge we are running into. Here is a summary of the application along with a block diagram to better visualize the system:

Customer design challenge: We're looking for a solution that receives 40-bit UART (RS232) stream and put this to 40 dedicated outputs. Current idea is to use a TI MAX232 to get TTL-signaling and then put this stream into a serial shift register like 74xx4096 device. The current problem is to get rid of the protocol bits like start, stop and parity bits, as well a generate a clock signal out of the UART stream. Is there a device which can do that? The solution shall use devices without any programming, strapping is OK. The 74xxx4096 should drive a low ESR FET; therefore a 5V surrounding would be great, but a 3.3V plus level shifter would be also OK. 

At first glace, I figured an MCU may be needed to generate the appropriate data bits and clock signal but I figured it was worth running by your team to see if you know of any solutions that can do this bit stream manipulation in HW without the need for coding or programing. 

Please let me know if you need any further clarification or have any follow-up questions!

Best regards,

Matt Calvo

  • Hi Matt,

    I am not aware of any devices that can do what is being asked - a hardware implementation is most likely possible but I don't think it would simple because essentially you would be targeting the middle of each UART frame to only capture the data and most likely would have to be tuned to one data/frame rate  with a clock generation needing to happen elsewhere - as the issue is I don't think any of our clock generators accept UART inputs. An MCU would most likely be the best bet - it would receive the information from the RS-232 device and be able to  target specific bits in the bitstream - and since there is a reference bit clock for the MCU to handle incoming/outgoing UART signals it would likely be easier to get the clock signal that they would want to. 

    Ultimately  - I think an MCU implementation would be the simplest way forward - I understand they don't want to need software - but this is an application where the hardware approach is much more complex as the firmware should be relatively simple to implement  as its essentially just bitwise operations on the MCU - it is most likely the preferred solution and ultimately going to be more flexible.

    Please let me know if you have any other questions and I will see what I can do!

    Best,

    Parker Dodson

  • The UART protocol is inherently asynchronous, so with arbitrary data bytes, it is not possible to reconstruct the clock. To detect the length of a clock cycle, you need to include a fixed bit pattern (01) in each frame so that the bit period can be measured.

    TI makes two such devices. The TCA5405 has a fixed address, so it cannot provide more than five output bits for a UART line. The SN74LV8153 has three address bits, so you could have up to 8×8 data bits. Please note that the UART transmitter must format the bytes properly for the SN74LV8153.

  • Thanks for the feedback Clemens and Parker!

    Based on your advice and some research on their own, they're now considering slightly modifying the signal chain. They would like to receive a standard PC interface, such as USB or UART, and generate outputs for a Hardware in Loop (HIL) environment. To do this, they plan to use a UART to I2C bridge. See the updated block diagram below!

    As you can see, data is expected to come in through a USB hub, pass through a USB to UART switch (TI TSU6111A), get converted from UART to I2C (NXP SC18IM704), and then get fed into an I/O expander (TI TCAL9539-Q1).

    I appreciate the support and if you have any concerns on this new approach above we are open to feedback! 

    -Matt

  • Hi Matt,

    This implementation seems sound. I think the only consideration when designing is to consider prop delays and capacitance from long traces going to the IO expanders. 400pF is the cap limit when using standard or fast mode on the IO expanders. The prop delays I am not so much worried about, since I would predict these delays would be in the ns range, which wouldn't effect much on the I2C side of things. 

    Regards,

    Tyler

  • The TSU6111A cannot convert between USB and UART. It is a passive switch, which can connect another UART device directly to the data lines of a USB port (which does not conform to the USB specification, but is sometimes used for debugging).

    TI does not make a USB/UART bridge.

  • Hi Matt,

    Sorry I made a mistake in my previous reply concerning the TSU6111A. I now agree with Clemens comment about the device being a passive switch. The TSU6111A does not make the conversion from USB to UART, i.e. it can't take a differential signal from USB and convert it to UART single wire signal. TSU6111A makes either makes USB to USB, or UART to UART in SPDT switch configuration. 

    TI does not have a device comparable to the SC18IM704 UART to I2C converter. Our portfolio does not support a device like this. 

    My comments on prop delays and parasitic capacitance are still true from my last response. 

    Regards,

    Tyler

  • Hi Matt,

    So I think from a HW perspective you have what you can get from TI - as a note the switch that you have (USB -> UART) is just a switch that can handle USB or UART - its not a USB to UART bridge and I don't believe TI has those parts directly. 

    Best,

    Parker Dodson

  • Thank you everyone for the advice and feedback!

    This has all been extremely useful info; I'll go ahead and pass all of this along to my customer so that we can determine the best pathway forward.

    Best regards,

    Matt Calvo

  • Hi Matt,

    No problem - if you have any other questions please let me know and I will see what I can do!

    Best,

    Parker Dodson