I was actually able to solve my own problem before I came here, but I figured it might help some other folks if they were struggling to get their SSD1309 OLED connected correctly.
I initially bought the pod, but after seeing Carl’s Olearia project I really wanted to mess around with an OLED screen, so I picked one up to test some things out with. Just a standard 7 pin, SPI configured SSD1309.
I tried to follow the directions in the “hid_oled_display.cpp” source file - but I wasn’t getting any output - so I turned to the patch schematic and that got me sorted. I decided to make this little graphic so that I wouldn’t have to puzzle over the schematic each time I hook up the OLED:
He’s using the “daisy_patch.h” header file, but using the connections I noted above it should still display the main screen - so you can make sure you have all the pins connected correctly. (Carl posted a picture of the main screen on his thread here: Olearia: a collection of applets for the Daisy Patch)
After working out the pin connections, I did update “daisy_pod.cpp” and “daisy_pod.h” in …/DaisyExamples/libdaisy/src to include all the necessary display pin definitions and function calls so I could use pod.display.Fill(), pod.display.Update(), etc. in my pod projects.
I really just looked at “daisy_patch.cpp” and “daisy_patch.h” and just copied any OLED related stuff out of those files and pasted them into the respective pod files.
Once you make those changes, though, you need to rebuild the libraries. You can do that by navigating to your working directory (I’m just using /Desktop/DaisyExamples) and running “./rebuild_libs.sh”.
Is I2C supported with the current driver? It looks like the header file (hid_oled_display.h) in libdaisy includes a comment that says “add I2C Support.”
If you wrote your own driver - more power too you! Beyond my skillset, haha!
Sure! I’ve uploaded some example code to my github. A very rudimentary oscilloscope example. I’ve also included the updated libdaisy “daisy_pod.cpp” and “daisy_pod.h” files with the OLED related code included from the PATCH source files.
Hey @kreiff thanks a lot!
It works. I just had to comment out this function which stopped the build of libdaisy
src/daisy_pod.cpp: In member function 'void daisy::DaisyPod::ChangeAudioCallback(dsy_audio_callback)':
src/daisy_pod.cpp:129:10: error: 'class daisy::DaisySeed' has no member named 'ChangeAudioCallback'
129 | seed.ChangeAudioCallback(cb);
| ^~~~~~~~~~~~~~~~~~~
src/daisy_pod.cpp: In member function 'void daisy::DaisyPod::ChangeAudioCallback(dsy_audio_mc_callback)':
src/daisy_pod.cpp:134:10: error: 'class daisy::DaisySeed' has no member named 'ChangeAudioCallback'
134 | seed.ChangeAudioCallback(cb);
| ^~~~~~~~~~~~~~~~~~~
make: *** [build/daisy_pod.o] Error 1
I’ve made the changes to the files you suggest and unfortunately can not get the display going. In order to find out whether it is a wiring (or build) problem (I tested the display with an arduino and found that it is working well, so the display is not the problem) I would like to ask you to make available a binary file, so that I can maybe find out what is going wrong.
sorry to revive an old thread (and as my first post no less), but i was wondering if anyone could tell me if these same connections would work on a patch submodule? obviously pin numbers are different, but the patch submodule seems to have SPI MISO, SPI MOSI, USRT1 Rx, SPI SCK and SPI CS pins.
Anyone got an OLED working with their patch submodule yet who can run through what it took? Ive arrived to daisy from arduino and it feels like just a slight step up, so i could do with a little guidence!
Also USRT1 Rx is not some special pin used by display, you can use any GPIO pin instead. It’s just a reset pin that you need to toggle when display is initialized. For smaller displays with fairly dumb controllers (i.e. SSD1309/1306) you won’t need the MISO pin, it’s used for reading data from a slave device and is usually only needed for bigger displays in some cases.
So I’ve interfaced an SSD1306 with my pod via SPI with the SPI pins SPI CS SPI SCK SPI MOSI SPI MISO
which looks like i see them on the patch sub module, so if you have those pins available you can try that
Another OLED problem from a noobie here. Jumping into this existing thread as it’s the same OLED with SPI. I’m trying to use the OLED example for Seed.
I basically have the thing wired up as per the handy diagram supplied by OP. If I hit the reset button, the Daisy starts up and 70% of the time will flash some garbage on the screen for half a second, and then the screen goes blank. Sometimes I can make out some of the letters of the word “Daisy” amongst the garbage, which is coming from the OLED example file.
The display itself is working absolutely find under Arduino with the Adafruit library.
I managed to fix this. I had to go into libDaisy and change the ssd130x file and amend the SPI PreScaler value. It was set to PS_8. Trying PS_4 gave me some gibberish on the screen which settled down after a few seconds and produced the correct output. With it set to PS_2, everything works properly as expected.
Pretty annoying that I don’t seem to be able to pass in an SPI config when configuring the OLED screen in the code - it’s all statically defined in the oled class. I’m not very familiar with C++ at all, so wouldn’t know where to begin with extending the class to be more flexible. so I just went with editing libDaisy directly
I agree that the SpiHandle::Config should be a part of the OLED driver config struct. If you look at the I2C transport, you’ll notice that this is how I implemented it there. Unfortunately I was only using I2C modules at the time I implemented the driver, and didn’t notice the SPI config is hard coded.
It’d be awesome if you could submit a PR for this. If not, I’ll try and find some time for it myself.
I didn’t realize that you couldn’t pass in the SPI config – I thought that there was some sort of way of accessing it via some connected TransportConfig, but that might just be the pins themselves.
I’ve opened a github issue to document this. If someone here wants to open a PR to resolve this that would be awesome.
Also, @opb2k I haven’t seen any particular issues with running SPI slower speeds when going to the display – where are/were you calling the Update function, and do you have a lot of other stuff going on in your program?
