Gotcha. I may have to look into those! Do you know if there’d be any way (or any other things I should try) to make the Adafruit libraries work in the meantime?
@Pete, I will investigate.
@peekay123, I appreciate that. I’ve done a bit of research (granted, I’m not very knowledgeable in any of these areas), and found a few sources that suggested changing SETLOWCOLUMN to 0x02. Bummer that it didn’t work for me. Finding an even comparison of the actual ssd1306 and sh1106 libraries has proven to be sketchy at best for me so far. Hopefully you have a bit more luck!
After searching some more, I found one (and only one!) place where somebody has reproduced the issue that I’m having: https://github.com/adafruit/Adafruit_SSD1306/issues/14
Unfortunately, that person’s issue was solved by simply switching over to the u8glib. Talk about avoiding your problems! 
Hi again! After a few days of not making any progress, I may give it up. I asked a question over on the Arduino forum specifically about how I could go about porting SSD1306 to work with SH1106 displays, but it turns out switching one into the other isn’t a trivial task. After getting some good starting suggestions from the u8glib dude himself, I tried lots of different things to modify Adafruit_SSD1306 over the past few days, but largely haven’t seen any change in behavior. The screens still show up with just as much junk as they did before, with the working demo running in the top ~20% of the pixels on the screens.
@peekay123, I’m not sure if you had any other ideas, or if you got just as stuck as I did. It’s frustrating because the demo is obviously translating to the screen and it is running just fine in the top portion of it, so it couldn’t be impossible to make it work. So it’d be super nice to find out a solution.
In any case, I did a bit more research and ended up ordering a few Digoles. Everything I’ve read on the spark forums point to them working like a charm. I assume I’ll be able to multiplex them just like I did the screens I currently have? That’s functionality that ought to be separate from the display logic, but since they’re touted as “smart” displays I thought I’d make sure that they didn’t add a feature that I overlooked and would make it impossible to run four of them independently at once.
Thanks again for all your help!
@Pete, the only lead I had was another arduino library with different setup codes. But it turns out the SSD1306 also does transactions differently so, not having any of these displays to play with, I just don’t feel it’s worth chasing.
The beauty of the digole is that you can set the I2C address via firmware (once) for each display and address them individually after that. They have their own fonts, display memory and high-level commands so no code needed for that. The library I worked on with @timb has extra geometric primitives you can use. Which model did you purchase?
1 Like
@peekay123, ah, that’s awesome! Makes me wish I would have heard of those babies sooner 
I went with these blue 1.3-inch ones to start out with, although once I get the concept proved out we may pick the white displays instead.
Thanks so much for all your help with my newbie questions getting started. It’ll be exciting to finally get it to work!
1 Like
@Pete, let me know how it goes. I have a lot of knowledge on using those displays and their hidden “treasures”.
1 Like
Sweet! Thanks for all your help!
1 Like
So @peekay123, the screens came! I got them all hooked up via I2C, and upon plugging in the spark they all booted up with the Digole welcome screen. Good start!
I went to the big thread on the Digole library on this forum, and copied over the library and basic example files (from here: https://github.com/timothybrown/Spark-Core-Sundries) into a new project. At first I got some compile errors, but after removing the example code for SPI/UART/SoftSPI, I got it to compile. I also played around with the DigoleSerialDisp() constructor, and placed the included setI2CAddress() method inside, so that I could set the screens to any address from the example file.
However, neither the original example nor my modified example did anything to change the screens from their welcome page. Is there something else that I could have overlooked when setting everything up? Also, is setI2CAddress actually the way you’re supposed to go about setting the device’s I2C addresses? I’m not quite sure how I can make that work, so that each of the four screens have a unique I2C address.
Thanks!
@Pete, first you need to only hook up ONLY one display. You cannot put the setI2CAddress() inside the constructor call. The digole display object needs to exist before you can use that function. So the address is 0x27 by default. This should allow you to run the demo.
Once the demo is working, you can add the setI2CAddres() call in setup() so you can change the display’s I2C address. I think that once you set a display’s I2C address, it is stored in the displays memory and from that point on, you can now address the panel at that new address. So assuming this is true, you will need to hook up one panel at a time and change its address to a unique one so as not to interfere with the other displays.
Once you have each display INDIVIDUALLY tested and their address programmed, THEN you can hook up all the displays together. The demo code is designed to only write to one display so you will have to modify it if you want to do all 4 displays. 
1 Like
Hi @peekay123, thanks for responding! That all makes sense. I re-copied the example code verbatim and tried it again, this time with only one screen connected. However, I got the same result - the display never moved off of the “welcome” screen. Is there a chance I have something plugged in wrong?
on the top of the welcome screen us there some words? they usually say what mode they are in like uart or i2c. there are little solder jumpers on the back to set the mode, mine came set for uart
@Hootie81, ah ha! I didn’t think much of it, but it does show “uart” at the top of the welcome screen. I should have read the manual more closely! I’ll give that a shot and report back.
@Hootie81, you are faster to the draw then I am @Pete, he is dead on with the jumper. Most folks get these displays and don’t RTFM! Digole makes that jumper super tiny and that is pretty well my only beef with their displays. Let me know how you progress
1 Like
@Hootie81 and @peekay123, the jumper wasn’t bad to solder when I knew to look for it 
It looks like the display is set to I2C mode, but other than that I’m still getting no change in outcome. Here’s what the screen looks like after I flashed the example code to the Spark:
Any ideas on where to go from here?
Have you still got 2 sets of resistors? i think you only need 1 set for multiple displays… looks like the 2 on the left are still connected even with the other screen out
Hi @Hootie81, yes, those resistors are still plugged in from when I was testing out the four screens at once. But for right now I’m only testing the one display, so that’s the only pair of resistors in use.
could you post a pic of the whole breadboard, spark and all so we can see the wiring?
Sure! I pulled out all the superfluous wires, so here’s the bare-bones, one screen setup:
