2
\$\begingroup\$

I’m looking for ways to serialise an I/O data bus write. This is for an x86 embedded system, where I have several on-board devices (accessed via I/O ports) that I want to situate some distance away from the main system, with minimal cabling.

This isn’t a student/homework question, despite it perhaps looking like one.

In a computer, software can instruct a CPU to write a byte (or larger) to an I/O port. This results in data on 8 signal lines (a data bus) that can be connected to a data latch within a peripheral.

I’d like to relocate this peripheral some distance from the CPU. Rather than having 8 data lines (wires) plus ground running over several metres, the data should be sent serially over a smaller number of lines (data, clock and ground as a minimum), and converted back to 8 bits in parallel at the far end.

I’m interested in a generic solution, not something that connects a known computer to a known peripheral where a proprietary solution may already exist. And discrete logic is preferable, at least to start with.

I wondered if I could use something like a 74HC165 to take an 8-bit input and serialise this, and a 74HC595 to convert that serial stream back to 8 bits in parallel. I’ve seen some examples of these being used with Arduino kit.

My simplistic use case above is write only. But a more generic solution would be bidirectional. And there would need to be some kind of acknowledgement signal so that a subsequent write operation wasn’t attempted until the previous one was completed fully. While my question above is for just 8 bits, I’d then scale this up to 32 bits or more.

Are there any approaches out there that might satisfy this requirement? Is what I’m describing already solved by SPI or I2C? I’ve yet to find an SPI data latch (e.g. a SPI-enabled 74HC373 type latch). A fully-fledged networking solution isn’t appropriate.

Adding to the question, following some comments: I have an initial use case in mind, where a legacy CPU board has an on-board header that connects to an on-board control/sensor device. I'm looking for a serialisation solution that goes between the on-board header and the control/sensor device that can then be relocated off-board, i.e. 2m to 5m away. While I can modify the software/firmware, I can't alter the existing hardware.

\$\endgroup\$
14
  • \$\begingroup\$ @periblepsis Your comments are helpful, no need to delete :-). 1. There's no DMA or DRAM concerns (no DMAC, SRAM only, it's not a PC). 2. I don't need to hold the bus. Having written to the port (e.g. out dx, al) I can wait (via software) until the far end has received the 8 bits and processed them \$\endgroup\$
    – David00
    Jan 19 at 17:14
  • \$\begingroup\$ Sure, there are both SPI and I2C "I/O expander" chips. Microchip MCP23017 and MCP23S17, for example. \$\endgroup\$
    – Dave Tweed
    Jan 19 at 17:16
  • \$\begingroup\$ @DaveTweed Thanks! I'd looked for these, but my search terms didn't find them. Are you familiar with these parts to the extent that you know whether they can provide the sort of serialisation I'm asking about? I did look at the associated App Note for interfacing to a matrix keyboard, but that's only half of the solution. Same as the Arduino examples above, they rely on a CPU providing the serial data. Also, I noticed that these require configuration. That's fine for the CPU end. But in my scenario, the far end (e.g. a 16 bit sensor) is dumb, there's no option to configure anything. \$\endgroup\$
    – David00
    Jan 19 at 17:32
  • \$\begingroup\$ Are you using x86 OUT instruction? This outputs both address and data, so is there some address decoding involved? IMO it would be much simpler to skip the serialization part, not use OUT, and just use SPI, I2C, or any other serial protocol... or just UART. Can you explain why you want to use OUT and not these? \$\endgroup\$
    – bobflux
    Jan 19 at 17:37
  • \$\begingroup\$ @bobflux: Fair point, I could do this. But it would mean a new board design. At the moment I have a legacy board with an on-board data header that is connected to an on-board legacy control/sensor-type device. So I was looking to connect a "serialisation solution" to this header. The other issue with SPI/I2C is that my far end cannot be configured, it's dumb - no CPU/microcontroller - and I don't really want to redesign this. So I may need a simpler/more primitive soloution using 74 series parts that don't require any config - if that's possible \$\endgroup\$
    – David00
    Jan 19 at 17:46

2 Answers 2

1
\$\begingroup\$

I’m answering my own question. To restate and simplify the use case (always easier to do after comments have been made):

There’s a legacy x86 CPU board. This has a 40 pin header that an onboard sensor connects to. The sensor is relatively dumb (no CPU/MCU), and uses the CPU's 32-bit data bus to exchange data, along with some control signals. The sensor needs to be relocated some distance from the CPU board. A 40 core cable is not ideal, and would need a lot of screening for noise.

I was looking for ways to serialize the data bus, and some of the control signals if possible without introducing any race hazards.

My initial thinking was to use 74-series parallel-to-serial and serial-to parallel converters. This looked onerous. Then wondered if an SPI or I2C based approach might work. But can’t find an SPI/I2C-enabled 74xx373-type latch. You can register-configure a more complex part to look like one – but my sensor is dumb, so that wasn’t an option.

I started looking at how a laptop’s main board connects to its LCD display, where the data is serialized so that only a small number of wires are passing through a screen hinge. While most solutions were FPGA-based, I came across the Fairchild FIN12AC/FIN24AC family of SerDes (Serializer/Deserializer) logic devices. These requires no software config, and provide a generic 12/24-bit bi-directional capability. They use differential signalling which is a bonus.

This looks like an almost exact solution for my use case. Another contender is the TI DS92LV16/DS92LV32 family, which has more availability. There are other discrete SerDes devices that appear more dedicated to specific industry needs.

I've found a few other posts that mention SerDes. I'd like to add SerDes as a tag to my original post, but don't have a high-enough points score yet.

\$\endgroup\$
2
  • \$\begingroup\$ This part might not be so easy to obtain, especially in qty of ones and twos. Also the packages are tiny, 5 x 5 mm and with dense pinouts and might cause grief. \$\endgroup\$
    – D Duck
    Jan 20 at 14:06
  • \$\begingroup\$ @DDuck: Yep, I saw that. It's in a 5mm MLP/QFN package, or BGA. But I could use an adapter. Availability is somewhat limited. Digikey stocks them, but as a bulk purchase. AliExpress seems to have some in stock. There are other (probably better) options, such as the TI DS92LV16/DS92LV32 family, which has more availability. I’ve updated my answer to note this. \$\endgroup\$
    – David00
    Jan 21 at 8:34
0
\$\begingroup\$

Since you haven't specified bit rate, I can offer a classic solution - a UART. A classic part would be the 6402. Bidirectional with two wires and everything is TTL compatible. The likely drawback is the bit rate - 125 kbps. Although there are versions which contain small FIFOs, so that can mitigate the issue if your communications are bursty.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks, you're spot on about the bit rate issue. It's the CPU's data bus that needs extending. While <10 Mhz, the 6402’s 125 Kbps wouldn't be suitable. Higher speed UARTs may require register config, which isn’t an option. The SerDes devices identified appear to offer other advantages. They’ve been designed specifically for this purpose without needing a lot of additional logic. There’s no register config required. Their transmission clock is triggered/encoded by the data. They use differential signalling. All of which gives confidence that data will be transferred coherently. \$\endgroup\$
    – David00
    Jan 21 at 9:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.