Digole OLED displays not working?

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!

EDIT: I found this cheat sheet ( https://community.spark.io/t/spark-core-help-sheets/3820 ), and those look to be the right pins for SPI.

hmmm very strange! i cant explain that one!

very strange that I2C and SPI are not working for you!

Spark Docs site has a tab for ‘spark core datasheet’ which i also find very useful

@Hootie81, the display IS working with SPI since the software SPI worked :stuck_out_tongue: 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. :smile:

@peekay123, thanks! I’ll try the new code this evening.

@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. :smile:

1 Like

Hi @peekay123, I copied over the updated code but the SPI demo still didn’t work :frowning: 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.

@Pete, just to check, do you have the Digole jumper set to SPI?

@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.

Off to test some more!

@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 :smile:

@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.

Hi @peekay123, thanks a bunch for responding, and for the layman’s explanation of SPI :slight_smile: I’ll need to do some more testing, it appears. I also was never able to get text to output to the screen via the print() method. So in the meantime, I tried using SoftSPI again. I was able to create two instances of DigoleSerialDisp and pass different text messages at the same time without a hitch. Yay!

I hope you can figure out a way to get this working! Using SPI should make it simple but double check the data sheet, and see if you have to do anything special. As for printf once you can print anything to the screen I recommend sprintf to help get text displayed, you can find more about this at http://www.cplusplus.com/reference/cstdio/sprintf/. Would you mind showing the code you are using to initialize the display and what library are you calling fro the display?

1 Like

I, too, couldn’t get hardware SPI to work ( 2 different cores, 2 different digole 128x64 OLED white modules with data= A5, Clk=A3, and SS=A2). Had a wild guess that it was a timing issue and found that changing line 60 in
github.com/timothybrown/Spark-Core-Sundries/blob/master/DigoleSerialDisp.h from delayMicroseconds(1); to delayMicroseconds(5); got it to work reliably for DigoleSerialDisp_Demo.cpp. Haven’t tried the geometry demo yet.

1 Like

Hi bpr, thanks for the response! I tried doing what you suggested, but unfortunately there are still no dice. For the moment, I’m happy with SoftSPI working fine, so thanks for all help everyone :slight_smile:

Pete, in case you want to try again, I ultimately found I needed to change another line. The lines I changed were the two delayMicroseconds calls like so:

SPI.setDataMode(1);
        SPI.begin(_SS);
    }
    
    void end(void) {
        pinMode(_SS, INPUT);
        SPI.end();
    }

    size_t write(uint8_t value) {
        
        PIN_MAP[_SS].gpio_peripheral->BRR = PIN_MAP[_SS].gpio_pin; //Low
        delayMicroseconds(10); //10 fixes it **********************
       
       
        //SPI.setDataMode(3);
       
        SPI.transfer(value);
        
        
       // SPI.setDataMode(0);
    
        delayMicroseconds(100); //100 fixes it **************************

        PIN_MAP[_SS].gpio_peripheral->BSRR = PIN_MAP[_SS].gpio_pin; //High
        return 1;
    }
#endif

Hi bpr, I’m not sure what I’m doing wrong but I still get no output with hardware SPI, even with your changes. Honestly though, it isn’t too big a deal since I can still use SoftSPI, but I appreciate y’all still trying to help :slight_smile: