I’m trying to hook up an SPI oled to my patch submodule.
I’m comfortable hooking up the hardware but since the patch sm uses different pin names to the daisy seed, I’m pretty sure I need to set up the screen pins in the code myself?
I took a look at the docs and understand all the other screen drawing/refreshing functions, but am a bit stuck on the init fucntion.
Docs say:
Where pin_cfg is a pointer to an array of OledDisplay::NUM_PINS dsy_gpio_pins
Does anyone have an example of how this is done? I probably just need to learn a bit more about pointers in cpp as I’m still a noob in these more advanced areas (most my experience has been with programming teensys in Arduino before this, where a lot of this setup is done for you in the background it has a lot of code examples)
The DaisyPatch uses a display, and can serve as an example of how to initialize it.
I fear the docs may be a bit out of date, based on the snippet you shared.
you can declare a display as:
OledDisplay<SSD130x4WireSpi128x64Driver> display;
The template-syntax can be intimidating, and if you have to retype it, it can be annoying. So you can “rename” it:
// Somewhere near the top of your file, or custom header.
using MyDisplay = OledDisplay<SSD130x4WireSpi128x64Driver>
// and then
MyDisplay display;
Then to initialize it:
// create a configuration struct
MyDisplay::Config display_config;
// Populate it with the pins you want:
display_config.driver_config.transport_config.pin_config.dc
= hw.GetPin(PIN_OLED_DC);
display_config.driver_config.transport_config.pin_config.reset
= hw.GetPin(PIN_OLED_RESET);
// And initialize
display.Init(display_config);
where PIN_OLED_DC and PIN_OLED_RESET are the pins you’re connecting.
and then connect the SPI1 (SCK, MOSI, and NSS/CS) to the OLED as well.
Once you’ve done that, you can use the drawing functions, and Update to populate the screen.
Awesome thanks so much! Yea I was confused why the daisy patch example code and the docs seemed so different, this honestly seems a lot easier than than what was in the docs! I assume the drawing functions from the docs all still apply though, it’s just the initialising that is different?
I’ve gotten a SSD1306 display working with the Daisy, so I’ve been doing some digging through the source to determine why it doesn’t seem to work with my patch_sm.
I think there may be an issue with the oled_ssd130x implementation that is causing an incompatibility with the patch_sm. It looks here as if the patch_sm exposes SPI_2 for SPI communications. It seems like SPI_2 uses a different set of pins, and perhaps different internal SPI hardware than the Daisy uses for communication with an SPI display?
Looking at the Daisy oled_ssd130x implementation here, it seems like it defaults to SPI_1 and a different set of pins, with no option to configure which SPI hardware/pins are used. (other than DC/CS) Unless I’ve missed something, I think it’s impossible to get these SPI displays working with the daisy oled_ssd130x library without modifying the libDaisy source code so that it uses the SPI hardware exposed on the patch_sm.
I gave it a shot by changing the peripheral handle to SpiHandle::Config::Peripheral::SPI_2 and modifying the pins used in oled_ssd130x.h but didn’t have any luck getting the display to work. Unfortunately I don’t know quite enough about the Daisy/patch_sm hardware to hack a working fix together.
Just to add another data point, I was also never able to get my oled working with the patch SM.
As @eris mentioned above, it seems connecting SPI1 is impossible on the patchSM, as it only exposes SPI2 pins.
Would really appreciate a fix, I have a patchSM project on halt right now until I can get the oled working. Slightly regretting not going for an i2c oled now.
I submitted a PR which when merged, should make it possible achieve your goals. Now the entire SPI peripheral configuration is exposed when setting up the OLED transport.
Thanks to the quick work of @recursinging we’ve got this merged in to the master branch! (We’re making a v5.0.0 release of libDaisy today that includes this update.)
You should now be able to use the new SSD130x4WireSpiTransport::Config::spi_config member to configure the SPI 2 peripheral, and select the pins available on the patch sm.
The constructor will set all of the defaults for the actual communication protocol (data size, speed, etc.). So you should only have to override the spi_config.periph, spi_config.pin_config, and the two standalone pins (dc and reset), which can use any available GPIO.
I actually was just thinking, “now that the config is exposed, users can do soft CS”, but there’s no mechanism to manage it internally yet.
I’ll open an issue on GitHub so we don’t forget to add it! If anyone else feels like adding that before our team can get around to it, the contribution would be more than welcome
I’ve discussed this with someone recently and he got it working, but the code is not suitable for libDaisy as is (just a custom class with a bunch of changes, hardcoded values, etc). Still might be useful a bit.
