Capturing stream of serial bits(CBUS) with arduino

Is it possible to capture stream of 32 bits from 16F74 PIC with arduino?

The line seems to be CBUS, or at least the stream is for an LCD display which is being driven with PCF2111C.

The PCF2111C takes in following signals:

CLB Clock burst input (CBUS)
DLEN Data input enable

So, I want to capture this stream of 32 bits between 16F74 and PCF2111C.

Any example code available? I have been trying to find this kind of code, but all seem to capture one word which is 8 bits long.

If this is not possible, I might be able to capture the bits I need from PCF2111Cs output (parallel, takes 16 IOs...), i only need 16 bits from that stream that would be usable for me (they drive certain parts of the LCD screen). But if there is any other way to get that whole stream to arduino it would be great..

Help :slight_smile:


but all seem to capture one word which is 8 bits long.

I'm assuming the problem is a little more complicated than calling the 8 bit code four times?

Does it call 8 bits or 8 bits + 2 for parity and such?

"Beginner" =)

No, no parity, just consecutive bits.
Looks to be a fairly simple protocol, just sampling the data line when the clock is high
Never used it though, just looking at a datasheet.

So, i basically:

If DLEN = HIGH then do while CLK = HIGH -> Check the DATA line state?

Hopefully Arduino has enough speed to handle the stream, if i recall, it could have been 250kb/s...

More like

while (DLEN) {
while (!CLK) ;
bit = DATA;
//shift into place

Thank you, I will try and check how this works out.

I decided to try if I can read the DATA directly with serial.available, with no DLEN or clock or others.

Ok, the data seems to be consistent, but being a newbie, its hard for me to understand how to combine the bytes to a single "line" this.

What I get with serial.available is (for example):

Is it possible to make it look like this :
00000000 00000001 00100000 00110000

The thing is that I want to "see" which bits gets changed in the stream.

The basic code is the...just the basic code:

void loop() {

// send data only when you receive data:
if (Serial.available() > 0) {

// read the incoming byte:

incomingByte =;

// say what you got:
Serial.print("I received: ");
Serial.println(incomingByte, BIN);



Yours, Learner

I don't think using the serial library is going to work - serial expects one start bit, eight data bits and one stop bit. There is no clock and no DLEN.
CBUS doesn't really look like that.

Any suggestions how could I read it then :slight_smile: ?

I thought (as mentioned earlier) that those bits are just consecutive bits when read like that ..?

that those bits are just consecutive bits when read like that

Yes, they are consecutive (that's what they look like to me), but asynchronous serial lines have start and stop bits which only signal the beginning and end of the data frame, but don't actually form part of the data, so they'll be ignored and won't form part of your result.
You have a clock line; use it to sample the data line, that's why it's there.
I honestly think you're wasting your time pursuing using the serial library.

What is wrong with the approach posted by groove?

[edit]There's a simplified timing diagram on page 9 here: Fig.7[/edit]

Well, propably nothing wrong with that thing groove mentioned, my learning curve is the problem :slight_smile:

Difficult to tell from the diagram, but I'd suggest sampling the data on the falling edge of CLB

Lets see if I am going in the right direction...this is just a start...but correct me if I need to do this some other way (shifting into idea about that =)


const int DLEN = 2; // the number of the DLEN pin
const int CLOCK = 3; // the number of the CLOCK pin
const int DATA = 4; // the number of DATA pin

int DLENState = 0;
int CLOCKState = 0;
int DATAState = 0;

void setup() {

pinMode(DLEN, INPUT);
pinMode(CLOCK, INPUT);
pinMode(DATA, INPUT);

void loop()

DLENState = digitalRead(DLEN);

if (DLENState == HIGH) {
Serial.print("DLEN ACTIVE ");

else {
Serial.print("DLEN IDLE ");

You're heading there , but don't bother with the serial prints for reading the data line - if this line is going at 250 kbit/s, you're not going to get sensible results printing the line state.

Remembered incorrectly that. Real line speed is 57600.

Makes little difference - you need to get 10 bits out of the serial output for every character you wan’t to print.

How would you check the the line status? Forgive me for asking these questions. I am eager to learn, but learning without helping hand is frustrating.

(Serial print is just for me to see if my code is working at least some way, will remove these as soon as i get the code fully functional)

You might be able to get away with triggering an interrupt off the falling edge of the clock. But, even with the PIC bit-banging the protocol, it might be cranking out bits at a rate too fast to handle via interrupts.

btw, according to the datasheet, you need to capture a sequence of 35 bits in order to get at the 16 you want.

One approach I would consider are using a string of 5 8-bit shift registers (like 74HC595s) to capture the bits, generating an interrupt at the end of the sequence, then doing something like multiplexers or 3-state buffers to access only the bits you want in small chunks. Or using a Mega to get more digital I/O pins and reading the shift register outputs directly. You'd need one or two cheap CMOS chips to generate the shift register clock and load lines from the LCD bus.

Another possibility is using the Parallax Propeller as a "smart shift register" to capture and buffer the data, with an I2C interface to the Arduino. You'd need to confirm that the Propeller can keep up with the LCD data, but that appears to be the case from the limited reading I've done about it. The cost would be only a couple of bucks higher than using the shift registers, and it would be significantly easier to wire.

I think I will wire directly to LCD drivers output and get the state of those pins directly from there. That way I don’t have to worry about speed or anything else. More wiring but might be easier to do…