Fix for the Mini12864 and SD card access on the BTT SKR Mini E3 V3

[RzTen1]

Description

This fixes the issue if the Mini12864 screen going blank when an SD card is inserted. This changes the SPI code to add a slight wait state before activating the chip select as the SD card operates in mode 0 and the display operates in mode 3. Normally the change happens too fast for the screen to pick up and won't clear until the display is reset on SD card removal.

This enables the use of the onboard SD card slot. The SD card slot on the display can also be used as long as two additional wires for SD chip select and SD insertion detection are added and the pins defined. This pull does not make the changes required for that.

Requirements

A BTT Mini12864 v2.0, FYSETC Mini 12864 v2.1, or equivalent display.
A BTT SKR Mini E3 V3 motherboard.
A BTT SKR Mini Screen Adapter.

Benefits

This allows the display to function when a SD card is inserted into the onboard SD card slot.

Configurations

The following must be set:

#define MOTHERBOARD BOARD_BTT_SKR_MINI_E3_V3_0
#define FYSETC_MINI_12864_2_1
#define SKR_MINI_SCREEN_ADAPTER
//the following are needed for the screen backlight
#define NEOPIXEL_LED
#define NEOPIXEL_TYPE NEO_RGB 
#define NEOPIXEL_PIXELS 3
#define NEOPIXEL_BRIGHTNESS 200

Related Issues

• [BUG] Mini 12864 on SKR Mini E3 V3 display issue #27103

[thisiskeithb]

Thanks for this PR!

There are some quirks with these Mini 12864 displays on some other STM32G0 boards like the Manta M4P (without adapter board) as well as the STM32F4-based BTT002, so I'll see if similar changes work for those configs.

The SD card slot on the display can also be used as long as two additional wires for SD chip select and SD insertion detection are added and the pins defined. This pull does not make the changes required for that.

I can check this as well.

[RzTen1]

Thanks for this PR!

There are some quirks with these Mini 12864 displays on some other STM32G0 boards like the Manta M4P (without adapter board) as well as the STM32F4-based BTT002, so I'll see if similar changes work for those configs.

The SD card slot on the display can also be used as long as two additional wires for SD chip select and SD insertion detection are added and the pins defined. This pull does not make the changes required for that.

I can check this as well.

Welcome and thanks! I suspect that this may apply to other boards with the similar processors but I've only got the one. I think the STM32F might need more work. When I was poking through there it looked like code for software SPI hadn't been written yet. I played around with the hardware SPI mode briefly on mine and I think the issue there is similar, it's just too fast, but I wasn't able to get the clock divider working. Every time I requested a lower frequency the scope kept reporting that the SPI bus was running over 4Mhz. Software SPI never appears to exceed 1Mhz. Approximately anyway, the intermittent nature of the clock signal made locking onto it a real pain.

[RzTen1]

Actually this may be a bit premature. It looks like the screen is still stalling out on some SD card reads. I'm able to clear the screen by hitting the button, but I have to do it after every card read when it's printing. Let me dig into it a bit more. It's still better than it was but I wouldn't call it fixed.

[RzTen1]

Well, I feel silly. I had assumed forcing the LCD into software SPI mode put everything into software SPI mode, it does not. My issue was due to the SD card enabling hardware SPI, which breaks software SPI as it won't let it drive the pins while hardware's grabbed it. I've added a tweak to the HAL for the STM32 so that if the LCD is in software mode everything else is as well. My tests are all working now so we should be good to go.

[thinkyhead]

This would be a good opportunity to make some tweaks to clarify the difference between SOFTWARE_SPI and FORCE_SOFT_SPI, as sometimes a pins file will define one or the other, and it isn't clear which one should be used. It may be that we should always use FORCE_SOFT_SPI, since SOFTWARE_SPI is also defined by HAL/**/spi_pins.h for cases where the defined SPI pins don't correspond to the hardware SPI pins, or where the pins are shared between a DOGLCD and an SD card.

The question is, does Marlin (almost) always look for ANY(SOFTWARE_SPI , FORCE_SOFT_SPI), or does it make a distinction sometimes? If there is a consistent distinction, then one of these defines might benefit from being renamed for more clarity. If there isn't a real distinction, then maybe FORCE_SOFT_SPI should just cause SOFTWARE_SPI to be defined.

Anyway, there's an LCD Pins Refactoring PR in progress which would be tripped up by making any big change to these defines in the pins files, so any big cleanup of this area can wait till after that gets merged.

[MCFFHAB]

I am having a problem with this commit - please see #27221 - To resolve my problem outlined on #27221 I reverted the commit for "SW SPI Mode 3 for U8G on STM32 (#27111)" and now all works well. I did apply all other commits that were introduced at the same time: "U8G_SPI_USE_MODE_3 for *_MINI_12864", "USE_SOFTWARE_SPI => SDFAT_USE_SOFTWARE_SPI", "Misc. SPI cleanup". All of these did not create a problem.