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!
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!
Oops, forgot how incomplete the software is. I should probably order a Daisy.
Edit: I just ordered a Pod.
Hey kreiff,
could you post your patches (or a diff) and an example usage?
I am trying the same thing with my DaisyPod and a 7 pin OLED…
Best regards
Hey void,
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.
You can check it out here:
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
Now I see blue sinuses dancing \o/
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!
Hi @NonVerbalPoetry,
It should work, sure.
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.
awesome this is so helpful thanks so much. thats actually a relief to hear rst doesnt need USRT1, as that frees up an extra adc on the patch submodule
oop wait no my mistake, i was thinking of the adcs on MISO and MOSI. but if MISO is not needed i do get that adc back
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.
Any suggestions would be much appreciated!
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?
@shensley Sorry for the delayed reply, been on holiday
The program is literally the OLED example from the examples folder - nothing else going on in there. I’m not completely on top of SPI clock configs, so I’d assumed that what I’d done by moving from PS_8 to PS_2 was to slow down the SPI connection. My theory was that my Arduino worked flawlessly with a clock speed 1/20 of that of the daisy, so if daisy SPI was getting garbled it was (in my mind) more likely to be because it was too fast than too slow. I just played with the PS_x settings in the SPI library and found PS_4 and then PS_2 to be more reliable than, say, PS_16 or PS_32, which just didn’t work at all (just like PS_8, the default).
@opb2k Glad to hear you found a solution. I agree the SPI stuff should be configurable from the outside.
With regards to the Prescaling, it’s basically a clock division. So PS_8 will mean a tick will come out of every 8 ticks of the underlying clock. That is to say that bigger numbers are in fact slower.
The oled should work at the slower speeds however so we’ll need to look into this some more.
Details on another thread but just to let folks know, SPI oleds don’t seem to currently work on the patchSM, it seems because the SPI oled library uses SPI1 pins, and the patchSM only exposes SPI2 pins.
I submitted a PR to fix this issue. After this gets merged, the SPI peripheral configuration will be exposed when setting up the OLED transport.
Just responding here as well, in case people end up here instead of the thread @NonVerbalPoetry posted above.
This PR is merged, and ready to go!