Shiftout too fast for my ribbon cable.

I have a current project that uses 15 shift registers ( TPIC6B565 ) to light 7seg LED displays.

I am using Shiftout, which I have had good results from on many previous projects.

This particular project ( the project from hell ) has 3 banks of 5 displays ( 5 shiftregisters per bank ) with ribbon cable disychaining the 3 panels together.

There is 2.5 m of ribbon cable all told for the 3 banks, and it looks like the capacitance of the ribbon cable is causing erratic displays when everything is connected.

Most of the 6 units ( 36 banks in all ) are fine, so I am obviously working on the edge of reliable communication here .

I scoped the data and clock lines at the far end of the daisy chain, and they are a bit rounded.

I can simulate the same type of errors by using my test unit that has resistors in each data line ( to save micros when testing the freshly soldered pcbs with occaisional shorts )

I could probably solve it by taking the last displays "out" data connection back to the receiver/decoder module, but this would need a new cable, doubled over at the receiver end. Luckily I made the serial data pins the end ones of the ribbon cable, so I could snip that on the return side.

The problems of "them" plugging it in the wrong way round, plus the expense and time for making 12 new cables, lets me think it would be easier to just slow down the shiftout pulses.

I found an answer on http://arduino.cc/forum/index.php/topic,39341.0.html where BenF solved a members similar problem by recommending changing the Shiftout function.
It looks easy , but where do I find it ? its all in the main part now, not a library.

Or is there an easier way nowadays ?

The problems of "them" plugging it in the wrong way round,

Nah, that wouldn't happen would it?

The shiftOut() function is in

\hardware\arduino\cores\arduino\wiring_shift.c

But I wouldn't modify it in situ, I'd grab the code and create your own version.


Rob

How about buffering the signals instead of messing with your code?
In all likelihood, the SCK signal is getting hosed by the length or capacitance, it will still be hosed even if it is applied at a less frequent rate.
Split the load in half, or buffer it halfway down the chain.

Boffin1:
I found an answer on http://arduino.cc/forum/index.php/topic,39341.0.html where BenF solved a members similar problem by recommending changing the Shiftout function.
It looks easy , but where do I find it ? its all in the main part now, not a library.

The linked paragraph has the complete shiftOut() function. So there's no need to go messing around in the core libraries, instead just copy in into you sketch and slightly alter the name and a add delay before the clockpin is toggled. Then substitute the new name for all the places you use shiftOut() in your sketch.

Thanks guys, I am sure I can sort it out now.

@Crossroads - I dont really want mess around with the hardware after all I have been through with this job, as I say a new ribbon cable feeding both ends would do it, but I would rather get away with a bit of software tweaking - its more educational :slight_smile:

And it doesn't matter if I slow down the speed of the scoreboard refresh - have you seen how fast a game of cricket is ? :slight_smile:

Let me see what I can do with my limited experience and a bit of help from the forum !

You could try just adding termination resistors at the far end - like a 4.7K pullup to 5V, similar to I2C.
Slowing the data rate down will not clean up the edges; the TPIC6B595's are clocked devices, looking for good edges.

CrossRoads:
You could try just adding termination resistors at the far end - like a 4.7K pullup to 5V, similar to I2C.
Slowing the data rate down will not clean up the edges; the TPIC6B595's are clocked devices, looking for good edges.

Yep. Pullup resistors are your friend.

Yes, thats actually on my whiteboard for last Sunday - adding terminating resistors - but I never got to reading the whiteboard ! thanks for the reminder .

OK, my fault, I am testing the panels hooked up together, but without the frames screwed together as they will be in the display units, so the LEDs current was sharing the logic ground ( which has 6 ribbon wires )
Linking the grounds solved it of course - I am definately not thinking clearly the last week with this project.

But on the bright side I did learn how to take a bit of code from the core, and make it into a new function, I love learning.

Thanks guys for the help.

You are quite welcome; and it's good to know you got everything sorted out, no matter what the ultimate cause.