SSD1332 and SSD1331 fast drivers

Status
Not open for further replies.
Many? did you mean multiple instances on the same CPU? On Teensy it's possible (in theory) have many OLED 1331 by sharing MOSI,SCLK,DC, just CS should be separate for each display, but I need to do some extra work for multiple instances...

I am trying to run 3-5 instances of a 1331 OLED on a arduino MEGA.
But unfortunately it doesn't work :(

I am defenetly shareing MOSI and SCLK and have tried shared as well as separate DC. CS was always separate of course.

You mentioned that you need to do some extra work for multiple instances - my question would be if you had the chance to put this work into the library yet?

Thanks for your support!!

PS: Eventually I'll swich from Aruino MEGA to a Teensy - but as I display rotating bitmaps only the performance of the MEGA should work for my application.
 
DC, MOSI and SCK should be possible to share. Each display needs a separate CS signal.

Yes - that's how its supposed to work - but it's not unfortunately.

Instanciating one is fine and by changing the CS each display works.

Instanciating two displays only one (normally the last one) is working.
 
What library are you using? Does it properly support multiple Instances? I have played around with Teensy 3.6 with multiple ILI9341 displays...
 
Firstly, THANK YOU for building this library, I love it and it has enabled me to do exactly what I want to do with my OLED, the performance is amazing!

I am having one issue, though - when I use tft.setRotation(3) to put my OLED into portrait mode, it will not draw text on the "lower" part of the portrait orientated screen. This can easily recreated by adding tft.setRotation(3) in the setup() section of your example "bigtest" - the text portion doesn't draw on the lower part of the now portrait screen, but the graphics functions work fine. The behavior seems to be that it is cutting off at the original Y height of 64 and not the new rotated height of 96. I'm using the Adafruit 0.96" 16 bit color OLED that uses SSD1331 and using a Trinket Pro to drive the display.

Everything else is working great, so thanks for this!
 
Hi,
I'm using sumotoy's SSD_13XX library with a ssd1332, and text is mirrored, I can't seem to find an option in the code to mirror the screen, have I missed something? Any hints?
 
您好, 我想買ssd1331 晶片 請問您可以幫忙嗎 ? 謝謝

Translated?:: Hello I want to buy a ssd1331 you can help me thank you

Those are common on Ebay, Alibaba and Amazon and other places - like Adafruit
 
Never saw this before ... until I quoted the prior non-English text?
defragster
Thank you for posting! Your post will not be visible until a moderator has approved it for posting.
 
I have a 7-pin SSD1331 connected to a Teensy 3.2. I have CS on 10, DC on 9 and RST on 8 and I added digitalWrite(8, HIGH) in first line of setup so it gets 3.3V (tried both ways, no difference). SCL goes to pin 19, SDA goes to 18.

I run the basicSetup sketch and errorCode equals 0, so no Init error. I get nothing displaying on the screen though. This is the one I have: https://www.amazon.com/HiLetgo-Disp...e=UTF8&qid=1498780426&sr=8-4&keywords=ssd1331

I also connected it to an Arduino Mega 2560 and used the Adafruit library and it did work so I know the screen is good.
 
Last edited:
I got a second screen from a different vendor today and connected it to the Teensy. I also verified that the SSD_13XX_settings.h file has #include "../_display/SSD_1331_96x64.h" uncommented and the boards I have look identical to the first one in the README file.
 
FYI, The connections below work with a Teensy3.2 and a *generic 1.44" SSD1351 128x128 OLED display that has 7 pins (and no SDcard). This board does have a 13V converter to boost the 3.3V.

The display PCB has 7 pins that are labeled as follows (L-R)
GND, VCC, SCL, SDA, RES, DC, CS

The Teensey is powered by the +5V USB cable, (which can also get power from pin26, but does not _give_ power on pin 26 - I made that assumption at first and the display did not work because it was not being powered by VCC - good thing because my display needs 3.3V not 5!


OLED Display Pin <-> Teensy3.2 Pin

GND -> Pin 1 Ground.
VCC -> Pin 24 (The Teensy3.2's 3.3Vcc regulated output)
SCL(SCK) -> Pin 13 (SCK)
SDA(MOSI) -> Pin 11 (DOUT)
RES <- No connection (A pull up R to 3.3V is OK)
DC -> Pin 15 (A1)
CS -> Pin 10 (CS)

Software config:
Teensyduino 1.36 @ 24MHz (The display does not work at 48/72/96 MHZ)
Arduino 1.8.1
Library version 1.0 of "teensy_ssd1351-master"

* I bought the board here: https://www.amazon.com/gp/product/B01HHPOD44/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
 
OLED Display Pin <-> Teensy3.2 Pin

GND -> Pin 1 Ground.
VCC -> Pin 24 (The Teensy3.2's 3.3Vcc regulated output)
SCL(SCK) -> Pin 13 (SCK)
SDA(MOSI) -> Pin 11 (DOUT)
RES <- No connection (A pull up R to 3.3V is OK)
DC -> Pin 15 (A1)
CS -> Pin 10 (CS)

I'm looking at the Teensy schematic and it says 19 is SCL0 and 18 is SDA0. I was thinking those were SPI but now I see that they are I2C and 11 and 13 are SPI. Thanks!
 
I'm trying to connect a second SSD1331 to a single Teensy 3.2. I'm sharing Pin 11 (DOUT) and Pin 13 (SCK) between the screens. Screen 1 has CS = 10, DC = 15. Screen 2 has CS = 9 and DC = 14. I'm trying to display a bitmap. I either get a working screen 1 and a blank or garbled screen 2. If I disconnect screen 1 entirely screen 2 still doesn't work. Another thread said that any pin could be CS for Teensy SPI.

My understanding of SPI is that I should share DOUT and SCK (clock) signals. Am I right? Any ideas?

for code I'm using

SSD_13XX tft1 = SSD_13XX(10, 15);
SSD_13XX tft2 = SSD_13XX(9, 14);

void setup()
{
tft1.begin();
tft1.setRotation(0);
tft1.drawImage(0, 0, &eye0); // &eye0 is in a separate file
tft2.begin();
tft2.setRotation(0);
tft2.drawImage(0 , 0, &eye0);
}
 
Last edited:
Very late (but hopefully not too late) to this party, but I've only recently been getting to grips with the SSD_13xx libraries using two SSD1331 96x64 RGB OLED boards (from eBay but identical to the Adafruit ones) and a Teensy 3.2.

I'm using the stock image_eyeAnimation example that Sumotoy provides with the library as a starter - the intention being to eventually run one animated eye of my own creation in each OLED. It all works fine, but I can only get it to work if a) the Teensy is set to run at 16MHz or lower, and b) the image is black and white.

I would normally use the Teensy at 72MHz (i.e. maximum speed without overclocking). The animation runs plenty smooth enough at 16MHz but I was wondering if this was a fundamental constraint of the library or whether I should expect to be able to use this at 72MHz, perhaps with some minor tweaking? I appreciate I probably won't see an appreciable difference in OLED animation rendering speed but it may help speed up some other routines I want to run at the same time.
 
Maybe it is driving the SPI faster than your displays can handle?

Since T3.2 using the SSD_13XX library the file SSD_13xx/_includes/_cpuCommmons.h tries to set the max SPI speed of 30000000

Depending on your F_CPU speed, lets say 72mhz, then F_BUS = 36mhz. So max SPI is 36/2 or 18mhz, which maybe your display can not handle...

So maybe edit the header file looking for the setting for Teensy and change the 30mhz to maybe 8mhz and see if it works.
 
Thanks KurtE I'll give that a go.

FYI the Adafruit SSD1331/GFX library test example runs fine at 72MHz on the hardware MOSI/SCLK pins, but I appreciate they're using bit-banging. I can just about get the SSD13xx eye animation to run at 24MHz, but it's flaky - which I think is consistent with your analysis.

Cheers
 
So maybe edit the header file looking for the setting for Teensy and change the 30mhz to maybe 8mhz and see if it works.

Changed the _cpucommons.h Teensy 3.x entry to 8MHz and it all works a treat with the CPU at 72MHz!

You are a gentleman and a scholar, sir.
 
Has there been any update on getting multiple independent SSD1331 SPI OLED displays running on the same CPU (e.g. Teensy 3.2)? I'm using 2 displays and following standard SPI practice - shared MISI, SCLK and DC but separate CS and RST - but the best I can get (using the Adafruit SSD1331 libraries) is both displays showing identical images even when they're instantiated as separate objects. I understand this is because the libraries available use a single memory buffer.

With the SSD13xx libraries I get variable results but never more than one screen working at a time.

Is this possible with the SSD13xx libraries?
 
You are welcome.

Sorry, I don't know enough about this library to tell you how well it works with multiple displays...
Also I have not seen the author of the library up here in awhile. Hopefully he is doing OK.
 
Hi,

I think I figured it out, I at least have 2 screens running in fast SPI mode.

(This will be based on my Teensy 3.2 pin numbers)
As I understand it it has to do with which pins you select for CS and DC, they have to be valid CS pins. The examples for this uses pin 10 as the CS which gives you register mask 0000 0001 and pin 9 as DC which gives you register mask 0000 0010. This combo will give you the register mask 0000 0011.

The problem for me was that I was trying to use pin 2 or 6 for my second screen, because they passed the CS setup error detection in the constructor. The problem how ever is that the register mask for pin 2 is the same as for pin 10 (which I was using for CS1) and pin 6 gives the same mask as pin 9 (which I was using for DC). When I changed my CS2 pin to pin 20, every thing worked like a charm for 2 screens.

So technically you should be able to use 4 screens at the same time using this fast SPI register mask magic.
 
Has anyone tried the Cache to Disk or SuperMesher Operators
with particle flow with a Solid StateDrive, and if so, was it blazingly fast?
 
Hi, one question I didn't find a very good answer for.
I had a look at https://github.com/sumotoy/SSD_13XX which has a benchmark table.
It says beta 2 does a screenfill in 406us.
Does it really mean that it can do 2463 frames per second?

I'm getting 86fps with the current adafruit driver on ESP8266 and hardware SPI on screen fills.

I did some math, which could be wrong to see the theorical limit, and I see:
96*64*16 = 98304 bits per frame
HWSpi is 80Mhz max, at least on ESP8266, so if you ignore signalling (mostly out of band) and anything else, that seems to imply a maximum FPS of 80000000/98304 = 813fps

Is my math correct?
Is https://github.com/sumotoy/SSD_13XX really getting 2463 FPS?
Thanks :)
 
Last edited:
Status
Not open for further replies.
Back
Top