Hello! I’ve had a string of trials and tribulations over on this thread ( http://community.spark.io/t/using-u8glib-for-spark-super-beginner-question-alert/5794 ) in trying to get OLED screens to work with my Spark. Since I’ve settled on Digole displays and am having a specific issue with them I figured it would be better to start a new thread here.
I ordered four Digole OLED displays (http://digole.com/index.php?productID=878), and am trying to hook them up to my Spark via I2C. I soldered the jumper on the back, and when I first plug in a screen it shows up with the welcome page:
I also copied over the libraries and simple demo file from here - https://github.com/timothybrown/Spark-Core-Sundries - into my own app on the Spark Build platform. I uncommented the lines #define _Digole_Serial_I2C_ and DigoleSerialDisp digole(0x27); in the demo file, but when I flash the app to my Spark, nothing happens. I’ve tested on all four screens, with and without pullup resistors, and no matter what I try it never moves off the welcome page.
At this point, my only thought is that the D0 or D1 pins on the Spark are bad, but I don’t know of any way to test that hypothesis. Does anyone else have an idea on how I can get the demo to work on my Digole displays?
@Pete, I just finished testing with a 128x64 display and Digole backpack. Here items you need to do:
In DigoleSerialDisp.h, DISP_W should be 128 and DISP_H should be 64
In the demo program make sure you uncommend ONLY #define _Digole_Serial_I2C and DigoleSerialDisp digole(0x27);
Connect the SDA and SCL jumpers closer to the Spark for good measure.
This should allow your code to run. I compiled with Spark CLI and flashed via OTA and USB and it worked. I also compiled on the web IDE and that worked as well. If it still doesn’t work, let me know.
@peekay123, thanks for the response. All of the above are checked, and still no cigar. I ended up ordering a new Spark, so hopefully I’ll have more luck with that one
Could you use the SPI interface instead? only 1 extra pin needed… I use mine in SPI mode… i have the digole display, SDcard, FRAM and RFID reader all running on a single SPI bus… only 7 pins all up for all those things
SPI is faster too, and besides having to uncomment different lines there is nothing different…
for 4 displays you will probably need a minimum of 6 lines… unless all the screens will display the same? then its only 3
@Dave, I did indeed try a few different breadboards/wires, just to make sure that wasn’t the issue (it’d be pretty infuriating if it were after all this time :P)
@Hootie81, good point! I guess I’ve been fixating on I2C since it seemed like the easiest protocol to work with, and speed isn’t much of a concern of mine. I went ahead and tried it with “SoftSPI” uncommented (and the pins connected to D2/D3/D4, as in the example code), and viola! One screen is happily displaying “Hello World!”
A quick question, if I may. What pins can/should I use for multiple displays? I don’t understand SPI all that well, and I tried plugging a different SS pin into another screen (and adding a second “DigoleSerialDisp” object in the code) to no avail. Thanks a ton!
You shouldnt need soft SPI, use the normal hardware one… save some processing power
That uses A3 for CLK and A5 for MOSI then for CS you can use whatever you like… except maybe A4
Hi @Hootie81, the regular SPI doesn’t seem to be working, even for one screen (it isn’t moving off of the welcome page, just like when I was attempting to use I2C). I have the “DATA” pin connected to A5, “CLK” connected to A3, and “SS” connected to A2, and the constructor for the display passing in the parameter A2.
If I can get SPI to work by simply connecting SS to any other pin, that’d be brilliant. Thanks again!
@Hootie81, the display IS working with SPI since the software SPI worked The question is why is the hardware SPI not working? timb and I had issues with timing with the hardware SPI so that may be part of the problem. Why the heck I2C did not work I do not know.
@Pete, make sure to grab the latest code from timb’s repo. I modified the begin() code to pass the chipselect pin specified in the constructor to the SPI.begin() function. That way, you can A2 or any other pin for chipselect. I am assuming that since software SPI worked, you changed the Serial/I2C/SPI jumper on the Digole. I will test the hardware SPI with my display later today and let you know how it goes.
@Pete, I tested the hardware SPI with my Digole 1.8" Color OLED unit. I tested with the both A2 and D2 as the chipselect line and everything worked just fine. I had to fix the DigoleGeometry_GeoDemo.cpp file since it was missing a digole begin() call! You can use that demo program if you set the display height and width in DigoleSerialDisp.h (as outlined in an earlier post). The only thing is the colors won’t appear so the demo will seem odd at times. The point is to run SPI data through it.
I will try and test my 128x64 monochrome LCD as well later. As @Dave pointed out, you should switch you jumpers, breadboard and USB cable just to be sure.
Hi @peekay123, I copied over the updated code but the SPI demo still didn’t work SoftSPI is also being quite spotty, so I’ll have to do some more testing there. I really appreciate you continuing to help me troubleshoot this. Once the new Spark comes in I’ll have to see if I get any better results.
@peekay123, yep, I switched them over so that it now displays “SPI:SS enable V2.7” at the top of the welcome screen. After unplugging and re-plugging in the display, I got SoftSPI to work with the demo code and loop through drawing a bunch of different shapes, which is neat. If I don’t end up getting the hardware SPI to work, I’ll have to figure out how to connect multiple screens via SoftSPI.
@peekay123 and @Hootie81, the new Spark finally came! For whatever reason, the screens seem to be responding on this one better than they did on the last one. Meaning, I currently have two displays set to SPI and connected to the spark, and they both do stuff :).
Now I’m just having a few issues getting started, probably since I’m not familiar with SPI like I am I2C. The Geometry demo from github seems to be running fine, but I’m confused about why that’s the case. The constuctor for mydisp passes in ‘SS’, which I don’t see defined anywhere. One of the displays has its SS pin connected to A2 on the Spark, while the other one is currently connected to A0. But in the constructor call, it doesn’t matter if I pass it ‘SS’, ‘A2’, or something else - the same demo still runs the same on both displays.
The other issue I’m having is I can’t get the print() method to display any text to the screen. If I add a print() call it simply does nothing and then moves onto the next method (drawing triangles, or whatever). I know it can display text, because in the “draw some random pies” section of the demo it occasionally outputs random letters to the screen. I’m guessing this is a side effect of when it’s setting different colors, since the displays are monochrome.
For the record, I have each display powered via 3.3v and connected to ground, both “data” pins connected to A5, both “clk” pins connected to A3, and one screen’s “SS” pin going to A2 and the other’s going to A0. If screenshots or a video of the setup/symptoms would help, I’m more than happy to post some. Thanks!
@Pete, SS is defined in the deep bowels of the core-firmware code and it is the same as A2. Arduino has the same definition (different pin obviously).
The fact that both displays work at the same time tells me that something is weird. First, the demo is written for only one display. Second, I have not thought about having multiple instances of the digole display object! When we ported the Arduino library I did not give any thought to that. So having two “separate” constructors may really be only creating one. I will look at the code and do some testing.
For now, try connecting a single display but on a different chipselect line like A0 and make the corresponding changes in the constructor to see if it works. Then hook up the SS line from the display to 3.3V to disable the display. Run the demo to see if any displays (it should not). Then we can go from there.
Hi @peekay123, I left the display that was connected to A0 plugged in and took the other one out, as well as changed the constructor to pass in A0 instead of A2. The demo began running again, and, as you said, once I connected the screen’s SS line to the Spark’s 3.3V pin it shut off. As soon as I disconnected it from the 3.3 pin the demo continued running. When I left the display’s SS line connected to the Spark’s 3.3V pin, the screen stayed blank for a good thirty seconds and then every single pixel lit up. Not sure if that means anything or not.
Then I tried disconnecting the display’s SS line from the spark completely and re-flashing the program. Sure enough, the demo still ran! Perhaps if there’s no SS detected SPI will just send data to anything connected to the data/clk lines? I don’t know enough about SPI to know if that’s normal behavior or not.
Here’s a quick video of the Geometry demo running on the display. I don’t know how it’s supposed to look, so perhaps you could see if there are any anomalies based on the output. Sorry about the poor video quality, but hopefully you get the gist
@Pete, did you change the width and height parameters in DigoleSerialDisp.h to your display’s dimensions? The demo does not look quite right. The problem with that demo is that it uses a color palette which your display does not support. I created a monochrome version for you here.
SPI is not too complicate. The Spark is the master and the display is the slave. The master sends data to the slave via the MOSI (Master Out Slave IN) line. The data is clocked to the slave using the SCK (clock) line. The Slave Select (SS) pin is activated by the master to enable the slave. This line is typically active low so a high on the pin causes all outputs of the slave into a “disconnected” (tri-state) mode. Leaving a device’s SS pin floating could cause it to be activated (or not) so it is important to set the pin HIGH when not active.
The question is why is the hardware SPI not working? timb and I had issues with timing with the hardware SPI so that may be part of the problem. Why the heck I2C did not work I do not know.
SoftSPI is also being quite spotty, so I’ll have to do some more testing there. I really appreciate you continuing to help me troubleshoot this. Once the new Spark comes in I’ll have to see if I get any better results.