SSD130x4WireSoftSpiTransport

[eh2k]

At the moment the hardware SPI2 on the Submodule does not seem to work properly. After some trial and error, using an OLED display via software spi is a viable alternative for me. The advantage is also that any gpio pins can be used. In contrast to spi_handle::BlockinTransmit no "ScopedIrqBlocker" is necessary.

[stephenhensley]

@eh2k thanks for the PR! This looks great.

Awesome that you included in an example as well!

The style-stuff can be fixed pretty easily with the fix style script if you have python and clang-format installed.
Otherwise, there's not a whole lot to fix by hand if you don't.
Let me know if you need any help with that.

What issues did you run into getting SPI2 to work on the Patch SM? Was a particular pin not functioning properly?

[GregBurns]

FYI, SPI2 has been working fine for me on the PatchSM to drive an OLED display. However it doesn't play well with USB. I have been unable to get the logger and display to work together. I posted a small test program on the Daisy forum.

…

On Tue, Dec 6, 2022, 8:22 AM Stephen Hensley ***@***.***> wrote: @eh2k <https://github.com/eh2k> thanks for the PR! This looks great. Awesome that you included in an example as well! The style-stuff can be fixed pretty easily with the fix style script if you have python and clang-format installed. Otherwise, there's not a whole lot to fix by hand if you don't. Let me know if you need any help with that. What issues did you run into getting SPI2 to work on the Patch SM? Was a particular pin not functioning properly? — Reply to this email directly, view it on GitHub <#551 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACESB6ZTJZANDTW3CFL7YLTWL5R6FANCNFSM6AAAAAASRGRDMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[eh2k]

@stephenhensley

My current issue/findings:

I have the SM rev 3, and with the current libDaisy and BOOT_SRAM the display stays black when I control it with the hardware SPI transport. I only got this to work with SpiHandle::Config::BaudPrescaler::PS_128 and if I used the ScopedIrqBlocker around the display.Update(). As far as I can remember, the ScopedIrqBlocker was only necessary when executing hw.StartAudio(). I also examined the whole thing with a LogicAnlyser and found that at the end the SPI sequence is somethig strange with the clock (at the end there is an unnecessary clock change).

I also noticed that the SPI ports D9, D8 are read by the ADC. I have removed these testwise from the ADC initialization (without success).
After some googling I found the stm32h7 errata, where it says that there are SPI problems at high clock rates. After further investigation I found out that the whole clock configuration in the System::Init() is skipped in the BOOT_SRAM case, or probably done in the bootloader (closed source).

Maybe there is still some other solution, but I thought that the SoftwareSPI implementation might be useful in general.

@GregBurns - Well - I recently started using the internal MidiUSBHandler - but i think it didn't work otherwise either.

[stephenhensley]

The soft transport looks good. So I'm going to merge it.

I've split out the notes about your issues with the hardware SPI to new issue #553