Is there an IC that can shift-in, store and shift-out serial data [closed]

Question

I want to storing serial data from an Arduino, and make it available for a second Arduino to read. Is there an IC that can receive serial data, store it, and send it out when needed?

One solution that that I have come up with is to pair a serial-to-parallel shift register with a parallel-to-serial shift register. Then I could, shift-in data from the first Arduino into the serial-to-parallel shift register. After that, the data could be shift-out of the parallel-to-serial shift register and read by the second Arduino.

^{simulate this circuit – Schematic created using CircuitLab}

I would like to find one chip that could do this. Does one exist?

Answer 1

There are some companies that produce Serial Data Buffers, like here. Of course, that specific one is just a custom programmed Microchip PIC microcontroller.

Depending on how much data, how fast, or how often you need to access it, you could just make one from a spare Arduino. An ATMEGA328, with custom code to act as a serial buffer shouldn't be too hard. Here is one project that acts as a Serial Relay, the arduino relays the serial input to a different serial device. Nothing particularly big or complex. Just If data in, data out.

Also see Can the Arduino be used to "spy" on a UART connection between two devices? and RS-232 Buffer circuit for more info. A sniffer intends to capture data between two devices, which is essentially what you want here.

Answer 2

As Andy Aka's comment says, there is very likely more to this than a single pin for sending and receiving data, and currently the question is missing important detail. However, outlining one of the options might help you understand the detail that an answer needs.

Some examples of the type of detail which may be important, in no particular order, to answer the question:

• Data rate - how fast does the data need to be transferred?
• latency - how long can the delay be between sending and receiving data?
• is the data bit or byte orientated, and is it arbitrary binary?
• is the transfer one way or are their some use-cases which require bidirectional transfers?
• e.g. can either end initiate a transfer; can Arduino 2 request data, or is it only controlled by Arduino 1?
• e.g. will the 'slave' always be ready to receive data, or is their a possibility that it will be unavailable or could lose data, and so may need a retransmit?
• how many Arduino pins are available to implement the transfer mechanism?
• how much CPU overhead is acceptable to achieve the data rate on
  sender and receiver, is 20% available, or 10µs/byte, can either or both ends 'block' waiting for a transfer?
• over what distance is the transfer going to happen, inches (cm), yards (m), miles (km)?

You're outline diagram suggests that there is only a small amount of data in each transfer, but even that is not clear.

The simplest solution is to connect the Arduinos' ATmega SPI peripherals together, Arduino 1 as master, and Arduino 2 as slave. This requires at least two pins, clock and MOSI, between Arduino 1 and Arduino 2. It is the same number of pins as would be used by any synchronous shift-register based solution using external chips; the ATmegas on-board SPI peripheral is designed to implement the same mechanism.

If the transfer might sometimes be faster or earlier than the slave, Arduino 2, can use the data, then a buffer would be some RAM in the receiving (slave, Arduino 2) ATmega. Or an extra pin could be used to send data back from the slave, Arduino 2 , to the master, Arduino 1 to control the transmission rate. Flow-control would be handled in software, and not by the SPI peripheral.

The ATmega's SPI peripheral transfers 8 bits at a time, which looks comparable to your solution outline.

The ATmega SPI peripheral is synchronous, and so has a clock signal, generated by the master. The clock can stopped while there is no data to transfer. The slave SPI will set a flag when a byte has been received. So there is a way to inform the slave that data is ready.

Further, the slave SPI peripheral can raise an interrupt when a byte has been received, so an interrupt service routine running on the slave can copy the byte into an in-RAM buffer. So the transfer does not need to be limited to one byte.

Also, the master SPI peripheral can raise an interrupt when the transfer of a byte is complete, so an interrupt service routine could send multiple bytes of data from an in-RAM buffer with a relatively small overhead.

The SPI peripheral is capable of simultaneously sending and receiving data, so any 'handshaking' that the software running on the master might need to ensure it isn't sending data too fast can also be implemented in your software.

Also, because the SPI peripheral data rate can be up to 4Mbit/second the data rate is higher than an asynchronous transfer, and is as quick as the ATmega could transfer data over any serial connection to an external device. Further, the latency (time lag) between sending data from the master to the slave can be quite low, at a few clock cycles over 2µs. At this rate, it might make sense to send smaller amounts of data if the data transfer needs are less than a byte at a time.

Finally, the SPI peripheral also supports an enable or select signal, so that more than one slave device can be driven by one master.

Of course, all of this could be implemented in software, without the use of the SPI peripheral, but using only digital read and write of GPIO pins. Some benefit would be a software approach could use any available pins, and the transfer wouldn't need to be byte orientated, or use a byte-size 'packet. Software will transfer more slowly, and have a larger CPU overhead than the hardware SPI peripheral, but it is more flexible.

Answer 3

You have 74LS164, 74LS165, 74HC595 for 8-bit serial/parallel shift register, and 74F673, 74F674 16-bit shift register.