Trouble using serial 7-segment display over SPI

Components & Accessories Displays
1

I’m trying to use a S7S as a display for a countdown timer. I have it connected to UNOR3, both at 5V. (I tried using I2C, but it kept dropping messages, so I switched to SPI.). I have only SCK and SDI connected, and a 10K pullup on SS. I am running this on a breadboard setup, and am keeping the wires as short as possible

It kept acting flaky, so I decided to use the sample code from the Sparkfun S7S documentation. I used the code verbatim, and still get strange behavior. It appears to be either adding a byte or dropping a byte, and I haven’t figured out what makes it do one or the other. It may have to do with warming up. The following table shows what is sent and what is displayed:

Column 1 Column 2 Column 3 Column 4
-HI- HI-_ -HI-
I-__ 0HI-
___0 __0_ __00
___1 _10_ ___1
___2 21__ _201
___3 2__3 __30
___4 __43 0__4

(In the above I used underline where a blank really appears.)

The first column is what is being sent, which I have verified using println(). Note that in the second column the displayed data is rotating to the left, as if a character is being dropped. (Indeed, when it is in this mode I can add code to print a single character before the four in the display function, and this character is not displayed and the rest of the data is not rotated.). In the third column the displayed data is rotating to the right, as if a character (sometimes 0, at other times a blank) is being added. The sample sketch never does a “position cursor” command but expects 4 characters to be sent each time. It is semi-random where the cursor starts out. Also, the “set brightness” command sometimes takes and sometimes doesn’t.

I see this same behavior whether I am running the S7S with power from the UNOR3, or with both running off an external supply. I have verified with current-sense resistors that the S7S uses only about 50ma.

I’m not sure where to go from here. Should I scrap the S7S? Should I try to re-flash it? Is it worth putting a logic analyzer on it? I have a Pro Mini that I could try, but it refused to work with I2C, so I’m skeptical of it.

2

Sorry, I fibbed a little. I didn’t use the code verbatim, but changed the display update from 100Hz to 1Hz. I don’t see how that would affect whether it works or not.

3

I think it’s a matter of framing loss, not device failure. SS timing instability corrupts byte boundaries in Serial Seven Segment display. The first fix is to make SS a fully driven, actively controlled signal from the microcontroller. It should not be floating or weakly pulled. It must go LOW just before transmission. It should remain stable for the entire 4-byte frame. Then return HIGH only after the full transfer completes. There should be no drift in its state during communication.

10K pullup on SS is often too weak. If SS is floating even briefly, the display will interpret mid-byte transitions as new frames. You will see shifted or missing characrters.

Loose breadboard wiring may cause error too. The breadboard Ground rail must be solid. Use solid connectors. Proper connectors improve signal stability in prototypes. Always choose the suitable Wire to Board Connectors.

S7S protocol behavior is explained in official guide. Please confirm you are doing everything according to this Hook up guide.

4

Thanks for your help. I modified the header on the S7S so that it would plug directly into the UNOR3 (pins 10 (my SS), 11, and 13). That got the breadboard out of the picture, except for PWR/GND. I also soldered a 4K7 pullup directly to the S7S. And now the example sketch works fine. Of course, with the S7S blocking most of the UNO’s header I’ll be hard pressed to connect all the other inputs and outputs, but I think I have the confidence to go directly to perfboard or PCB. And I managed not to lift any pads (yet).

Of the three interfaces to the S7S, what is their ranking as to tolerance of using a breadboard? I would guess serial is most tolerant, and SPI is apparently least tolerant. But maybe they are all sensitive to timing and framing, and noise.

Thanks again.