Interfacing with an unknown 3 wire protocol

I want to interface with a device that uses three wires for it's communication. The first is a latch. A clock starts to pulse when the latch goes low. Data (3rd wire) is sent when the clock signal is high. I have to provide the clock signal.

To me, this looks like some sort of SPI. But its not the same; the communication is asynchronous.

What would be the best way to interface this device? I can use bitbanging, but that puts a strain on the performance of the Arduino. It would be great if some sort of IC exists that could help out. Does anyone know of the existence of such an IC?

To me, this looks like some sort of SPI. But its not the same; the communication is asynchronous.

I agree, this does look like some sort of SPI. What do you mean that communication is asynchronous? You haven't said anything about how data comes back from the device.

-- Check out our new shield: http://www.ruggedcircuits.com/html/gadget_shield.html

I think that the communication is asynchronous because there is only one data signal. Data is sent in 22 character bursts. I guess the position of the character determines the direction of the communication.

Ah, I think you mean that the communication is half-duplex rather than asynchronous. Asynchronous communication implies there is no clock signal.

So it’s like an SPI protocol with MISO and MOSI wired to the same line? That’s like TWI, are you sure it’s not TWI/I2C?

If not, then unfortunately no, I don’t know of any chip that will help out here :frowning: Maybe bit-banging is not so bad.


Check out our new shield: http://www.ruggedcircuits.com/html/gadget_shield.html

The first is a latch.

This sounds more like an SPI chip select than a "latch" signal, since your description gives the impression that this is an input device. If the device is an output, then "latch" is a more likely possibility.

If you're not doing a large volume fo data to/from this device, efficiency probably doesn't matter. Especially if you do a more-optimized driver for it, rather than using the simple, but not terribly efficient, library routines like digitalRead() and digitalWrite().

If you're doing lots of I/O to it, and optimizing the code isn't enough, you could offload the work from the Arduino CPU to another CPU chip. Even to another cheap Arduino, like an RBBB, that's been programmed to act as an I2C slave (Someone posted an example in "Exhibition" in the last few months of setting up two Arduinos to work as master and slave on an I2C bus). Or to something like an ATTiny chip with hardware I2C slave support.

Since it sounds like you're still a relative newbie, my suggestion is to do something based on the two-Arduino example I mentioned above: it costs a little more, but it's easier than learning a new CPU, or some other approach that a more-experienced person would consider "simple enough to feel confident tackling it" but is daunting for someone still learning the ropes.

I had a look again today. The communication looks like I2C when I look at the signals with my logic sniffer. The I2C protocol analyzer doesn't recognize the protocol. I guess I can rule out that I am looking at a standard I2C protocol communication.

The SPI protocol analyzer is able to read the data. So this could be an SPI like protocol with MISO and MOSI wired to the same line. My DSO tells me that the data line uses 4.5V, the clock line is 2.1 V.

I understand that the Arduino can do SPI at 125Khz at the slowest (when using a 16Mhz clock). I have measured that the clock line of my signal is beating at 50khz.

My conclusion for now is that am going to use bit banging. SPI is hard to use because of the slow clock rate and because of the strange voltages that I measured. 50Khz should be very possible especially when I access the I/O pins directly and by pass the digitalRead/Write functions. I will use the latch to trigger an interrupt so that I don't miss any data.