MarlinUI for Creality DWIN (ie. Ender 3 v2)

[The-EG]

Description

I'm still tweaking some things and there are a few TODOs still, but this is at a point that I think it warrants some discussion, testing and a PR.

A MarlinUI implementation for the DWIN screen included with the Ender 3 v2. Based on Thinkyhead's initial work in #19371.

Includes both landscape and portrait modes, Marlin bootscreen, custom icons and fonts.

Status screen layout is based heavily on the DOGM status screen with some liberties taken for the differences in sizes/ratios.

Landscape:

Portrait:

Menus:

Halted screen:

As with #19371, this is enabled with one of two options in Configuration.h:

• #define DWIN_MARLINUI_PORTRAIT
• #define DWIN_MARLINUI_LANDSCAPE

Additionally, the LCD will need to be flashed with new assets. See DWIN_SET.zip below.

The fonts are based on the marlin 'fixed' 6x12 BDF font file that I scaled up and manually smoothed out. The resulting HZK does not contain the additional 16x16 glyphs, so only ascii 0-127 is supported for this font, currently.

Tested (both landscape and portrait modes):

• Printing from a host (OctoPrint), including setting progress and remaining time via M73
• Printing from SD card
• UBL Mesh Edit menu (visual interactive grid)
• HALT screen
• Boot screen
• Editing values (temp, fan, etc)
• Moving manually
• About/Info menu items

While I did start with Thinkyhead's commit, this has diverged quite a ways from that. Notably, I moved some of the code around into different files:

• src/lcd/dwin/marlin/ui_common.cpp - these are the MarlinUI functions that should work for any similar DWIN even at different resolutions, assuming that the proper defines are setup
• src/lcd/dwin/marlin/ui_status_480x272.cpp - these are the MarlinUI functions (mostly the status screen) that will only work for a 480x272 DWIN screen.
• src/lcd/dwin/marlin/marlinui_dwin.h - this was ultralcd_dwin.h, but since I split ultralcd_dwin.cpp into the above files I think this name is more appropriate

I also created an additional class, DWIN_String. This is modeled after TFT_String and is used heavily throughout the code to enable sending entire strings at a time instead of single characters. Sending entire strings is absolutely necessary in order for the menus to be usable.

TODO:

• Another clean up pass (remove old commented coded, etc)
• Smooth the larger font sizes (24x48 and up are still pixelated)
• BABYSTEP_ZPROBE_GFX_OVERLAY / MESH_EDIT_GFX_OVERLAY
• LCD_SHOW_E_TOTAL
• Verify the 'old' UI still works with these changes
• Add bdf->hzk script

Requirements

A 480x272 DWIN screen with an encoder, ie. the DWIN included with the Ender 3 v2.

Updating the DWINs assets (see DWIN_SET.zip below)

Benefits

Implements the standard MarlinUI status screens and menus for this DWIN LCD. Specific features do not require updates to the DWIN assets, etc.

Configurations

Ender 3 v2 configuration
Ender3v2.zip

DWIN firmware and assets (DWIN_SET):
DWIN_SET.zip

edit:
If you come across this PR because you have an Ender 3 v2 and are interested in testing, please do!

If you aren't familiar with how to do that:

1. Get this branch. You can either clone my fork and checkout the marlinui-crealitydwin branch . Or, you check it out from your existing clone of the main marlin repo:
   1. First, fetch this pr into a branch: git fetch origin pull/22211/head:marlinui-crealitydwin
   2. Then check it out: git checkout marlinui-crealitydwin
2. Use your desired Ender 3 v2 configs or start with mine, linked above (Ender3v2.zip).
3. Update your configuration to use the DWIN MarlinUI:
   1. Comment #define DWIN_CREALITY_LCD
   2. Uncomment #define DWIN_MARLINUI_PORTRAIT or #define DWIN_MARLINUI_LANDSCAPE
4. Build and flash as normal
5. Flash the LCD using the files in DWIN_SET.zip above (detailed directions here )

[The-EG]

Annnd, it appears that this does break the stock v2 UI. I'll take a look at that too.

[ETE-Design]

Will Manual Mesh Bed Levelling also work with this PR?

[The-EG]

Will Manual Mesh Bed Levelling also work with this PR?

@ETE-Design I haven't verified it directly, but it should since 'anything' that would work with a standard LCD screen with the standard MarlinUI menus should work with this without additional modification.

[The-EG]

Annnd, it appears that this does break the stock v2 UI. I'll take a look at that too.

It's building successfully now, but I haven't had the chance to reflash the stock assets and actually boot it up yet.

[The-EG]

It's building successfully now, but I haven't had the chance to reflash the stock assets and actually boot it up yet.

Confirmed that these changes are compatible with the Creality/Stock DWIN UI and that switching back and forth works as expected.

Note: the below font file will need to be added to the stock DWIN_SET files in the example configs for those that may wish to flash back to stock after using this.
0T5UIC1.HZK.zip

[thinkyhead]

Thanks for your efforts! With #19371 I got stuck on the correct handling of screen drawing commands and simply never got back around to solving them. Looks like I can close that, and/or cherry-pick parts of this that fill in where I fell down.

Annnd, it appears that this does break the stock v2 UI. I'll take a look at that too.

I think it's totally OK to completely replace the DWIN UI when using MarlinUI, replacing all the assets. Of course, if there's enough room for both, we can just put the MarlinUI assets in their own files. In the long run we'll most likely replace the existing DWIN/E3V2 code with the code by Jyers, at which point we'll make a super-hybrid DWIN_SET with as many assets as needed for all of the still-supported E3V2 user interfaces.

This looks really good so far, and I look forward to going forward from here! I've got to take a pass at the PR pile and then put out a quickie minor release, but later on I will flash this on my E3V2 and start messing around.

[The-EG]

I think it's totally OK to completely replace the DWIN UI when using MarlinUI, replacing all the assets. Of course, if there's enough room for both, we can just put the MarlinUI assets in their own files. In the long run we'll most likely replace the existing DWIN/E3V2 code with the code by Jyers, at which point we'll make a super-hybrid DWIN_SET with as many assets as needed for all of the still-supported E3V2 user interfaces.

It was actually broken at a code level originally, I've fixed it so that it builds for either UI now. (You do have to switch assets to swap back and forth, of course).

Trying to support both with a single set of assets is going to come down to the font: It doesn't appear possible to have more than 1 font installed and select it at runtime. I think the font I created looks better than the stock, and you could just use it for both...but I'm sure you could find someone who prefers the stock UI who would complain that it doesn't match.

The icons are also a bit finicky. It seems possible to install multiple icon libraries and reference them, but it didn't always work. I had the best luck just overwriting the existing 9 icon library instead. For this, we could just cram everything into a single icon library.

It's also worth mentioning: I fixed some bugs in the original DWIN UI code (src/lcd/dwin/dwin_lcd.cpp). I'm guessing they were put in originally (by Creality?) and just never used.

I've been using this as a reference:
T5UIC1 Kernel Application Guide_V23 - google translate.pdf
Which is a Google Translated version of:
T5UIC1 Kernel Application Guide_V23.pdf

Note that the guide is for v23 and all of the DWIN_SET assets I've seen floating around are all v20, so not all of the functions there seem to work. Notably draw bitmap. I couldn't get that one to work even after upgrading to v23.

This looks really good so far, and I look forward to going forward from here! I've got to take a pass at the PR pile and then put out a quickie minor release, but later on I will flash this on my E3V2 and start messing around.

Thank you!

[The-EG]

I've added the additional bdf font files I created and a Python script that will create the HZK font based on them to buildroot/share/fonts. If there is a more appropriate location, let me know.

Also, if you happen to take a look at the new fonts, not all of them have been smoothed and for those that have, only 1-128 have been since that's all the HZK font can hold!

[thinkyhead]

I tweaked the code to draw editable values in menu items in a different color, but now those values flicker on menu redraw. It might be due to the way these particular strings are drawn. The title is printed first, and then the value in the other color. Interestingly, the titles in white don't flicker. So, maybe there is some erase step happening before the value draw.

[The-EG]

I tweaked the code to draw editable values in menu items in a different color, but now those values flicker on menu redraw. It might be due to the way these particular strings are drawn. The title is printed first, and then the value in the other color. Interestingly, the titles in white don't flicker. So, maybe there is some erase step happening before the value draw.

Strange, I pulled the changes down, built and flashed and it seems fine for me:

PXL_20210705_001310041.mp4

I've gone to some lengths to keep that sort of flickering from happening, because as you allude to, doing multiple draws across the same area on the same 'pass' can cause that.

I don't see anything within MenuEditItemBase::draw that would be causing it. I do see the original call to //dwin_string.add(data) is commented out now that the part that draws the value in yellow is there below it...if that weren't commented out, it would draw it first in white, and then again in yellow. That could have caused flickering, maybe.

[thinkyhead]

You may want to flash again, as that Fan speed "0%" should appear in yellow.

I have also spaced out the menu items a bit because the skinny font can make them appear somewhat squished together. I'll also push a change shortly to move the menu item text a little bit in from the left edge.

[The-EG]

You may want to flash again, as that Fan speed "0%" should appear in yellow.

Nozzle, Bed and Fan Speed values are all yellow in my video, my phone just does a terrible job on auto white balance/brightness with the screen.

I have also spaced out the menu items a bit because the skinny font can make them appear somewhat squished together. I'll also push a change shortly to move the menu item text a little bit in from the left edge.

That makes sense! I've toyed around with bumping up the font size for the menus to compensate for the 'squished' feeling, but that didn't have the right effect either, so I just left it alone.

[thinkyhead]

Nozzle, Bed and Fan Speed values are all yellow in my video

When the knob is turned the yellow values flicker, so I'll still need to figure out why that is happening.

I've toyed around with bumping up the font size…

This is a good opportunity to improve some other areas and set a standard for other display UIs. For example, the edit screen is known to be relatively tall (i.e., it's definitely not a 16x2 character LCD) so it can draw everything centered across multiple lines, use the largest font for the numeric value, and show a "progress bar" at the bottom for values that have a range. I'll play around with some of that stuff today, and also try to sort out those flickering values.

[thinkyhead]

One thing I left off, but which could definitely be better applied, is the drawing / handling of menu items for a screen that has a persistent internal buffer and can scroll its contents.

The code provided by Creality only does drawing of the previously-selected item and the newly-selected item when the knob is rotated, and it uses internal DWIN methods to scroll the screen quickly. The current (menu.h) menu macros are tailored for a system that just re-draws all visible lines in a loop. For this screen, these macros should be re-defined (or augmented) to do minimal drawing, handle screen scrolling ahead of item drawing, and to run the selected item on knob click. So that is another thing I will explore.

[The-EG]

FWIW, I've been using this on my v2 since before I created this PR, and I've been reflashing as changes are made...probably at least 40-50 printing hours done so far (mostly via OctoPrint), with no major issues. So far the only big thing is OctoPrint disconnecting when I didn't have the LCD cable plugged in snugly (loose after moving it around, so self inflicted).

With that said, it seems very stable and I haven't run across anything that I felt was missing or wrong.

One caveat to that is that I do not use a Z probe and I use UBL with PROBE_MANUALLY, so I don't know what BABYSTEP_ZPROBE_GFX_OVERLAY or MESH_EDIT_GFX_OVERLAY are supposed to do/look like.

Also, the new edit screen looks very nice with the progress bar. The bar does make the encoder feel a bit slow...trying to trigger the 'fast' speed seemed a bit unreliable, but I could have just not noticed it before. I'll poke around with those settings.

And finally, if it hasn't been done by the time I have the chance to look at it: I'll see about adding an 'Info/question' icon to the assets and sprucing up the confirm/alert screen a bit, maybe more to the theme of the halt screen.

[thinkyhead]

The bar does make the encoder feel a bit slow….

Yes, it does highlight some areas that need improvement. Temperatures should definitely be "FAST" edit items, and the same is true for any item that has a very large range. I noticed that some items are intended only to display a message and not actually be editable, so I will have to hide the bar on those.

One caveat to that is that I do not use a Z probe and I use UBL with PROBE_MANUALLY, so I don't know what BABYSTEP_ZPROBE_GFX_OVERLAY or MESH_EDIT_GFX_OVERLAY are supposed to do/look like.

You can use the graphical LCD version of the code for reference. The graphics overlay shows how rotation direction will affect the value and Z motion, and it uses a couple of flags to decide which directions to show. During editing a nozzle graphic is drawn either raised up or lowered down to indicate the most recent direction moved, giving some feedback to make up for controller latency.

I'll see about adding an 'Info/question' icon to the assets and sprucing up the confirm/alert screen a bit…

Also a red stop sign with a white X for the KILL screen? It would be good to standardize our alerts, warnings, and fatal errors, and especially to give good feedback for certain procedures.

For example, during testing I noticed that if you start PID Tuning (from the screen or with M303) MarlinUI gives no indication that the procedure is going on except an initial status message. This is one procedure that would benefit a lot from having a good status screen (built around the select screen) showing the current temperature, current stage of M303, a progress bar, etc., and an option to cancel. The same goes for G29 and other lengthy processes. Of course, these enhancements should be optional, since they were originally omitted from Marlin to keep the binary small.

[The-EG]

BABYSTEP_ZPROBE_GFX_OVERLAY/MESH_EDIT_GFX_OVERLAY is now implemented:

Like the DOGM/LCD implementation, the nozzle and arrows move up/down a pixel based on the last movement.

You'll need to update the ICON asset:
9.ICO.zip
edit: Oops! I misnumbered the bed_on icon, so it overwrote the off icon...here's the corrected icon file:
9.ICO.zip
(put in DWIN_SET, flash the LCD, etc)

Since I was making icons, I also took the opportunity to remake the existing icons as SVGs and then rasterize them into JPGs. My lack of creativity/artistic skills aside (these are basically just the DOGM icons that have been colorized), I think they look better.

Hotend:

Bed:

Fan (animated when >0%):

For the halt/stop screen:

I also created a question and 'alert,' although they are currently not in use:

And some additional icons for the babystep overlay:
CW

CCW

Up

Down

Bed

[thinkyhead]

The look of the arrows is very clean, I like it! The trunks on the arrows could be slightly shorter, perhaps.

I would suggest using the common triangular ⚠️ design for the "warning" alert icon. It's a classic! Of course the customary "information" sign is a blue circle, so that's about perfect. If we want to make that more familiar too, the design and color should be more like…

For the bed icon, I think the fancier icon may be better going forward: as I also want to add indicators to show when bed leveling is enabled: small triangles in the negative space left and right of the bed trapezoid. (Currently it's a hassle to see that leveling is enabled or not.) For the flat-line bed, maybe triangles underneath the line could be used to indicate that leveling is enabled.

[thinkyhead]

Oops, I see that one of the fan frames is chopped off at bottom. I'll check whether that's code or the ICO….

[The-EG]

Ok, made some adjustments:
9.ICO.zip

• rotation arrow trunks a bit shorter:
• Question is blue/white:
• Alert is a triangle:
• And bed is the 'fancy' style (animated here for demo purposes):

Oops, I see that one of the fan frames is chopped off at bottom.

I made the fan icon square, because there's actually only a single svg now. It's just rasterized 4 times, with 3 of those being rotations (that are cropped to be square again). I've also updated the status screen code to account for this, but if you just flashed the new icons without flashing the new code it would be cut off on the bottom.

I also want to add indicators to show when bed leveling is enabled: small triangles in the negative space left and right of the bed trapezoid.

This would be a good point to start layering icons, I think. Actually, the nozzle and bed + on icons probably should be layered too, but it's simple enough to just have 2 separate icons...but adding in bed leveling would compound that. By layering, I mean enabling transparency so that we can 'stack' multiple icons on top of other. I was playing around early on and had this working, you just have to be careful with the JPG compression since the transparency is based on a single color. The current DWIN functions are just hard coded to not do this, but it would be fairly easy to make it an argument, I think.

For example, during testing I noticed that if you start PID Tuning (from the screen or with M303) MarlinUI gives no indication that the procedure is going on except an initial status message. This is one procedure that would benefit a lot from having a good status screen (built around the select screen) showing the current temperature, current stage of M303, a progress bar, etc., and an option to cancel.

I've been giving this some more thought too...encouragement to poke around at the code more! 😄

So, as an added bonus, after stumbling around some I've gotten to this:

It needs more cleanup, but hopefully it will be at a point where I can push up a commit with it soon.
Edit: this could also be a separate PR later on, too.

[The-EG]

This can help with the development of code for the DWIN display: https://github.com/mriscoc/Marlin_Ender3v2/raw/Ender3v2-Released/docs/DGUS%20DWIN%20T5UIC1.pdf

Thanks, but I had already posted a more complete version earlier: #22211 (comment)

[mriscoc]

Thanks, but I had already posted a more complete version earlier: #22211 (comment)

OK, deleted

[The-EG]

Only hiccup is that at the end of a print, the bed still showed the heating icon after the heater was turned off.

I haven't been able to reproduce this, so maybe I was just seeing things.

I did however confirm that the status message is no longer scrolling with STATUS_MESSAGE_SCROLLING enabled. This is probably related to the increase in font size.

[The-EG]

Only hiccup is that at the end of a print, the bed still showed the heating icon after the heater was turned off.

I haven't been able to reproduce this, so maybe I was just seeing things.

Nope, definitely not seeing things, it's just fairly random at the moment that it happens...

[thinkyhead]

the bed still showed the heating icon
STATUS_MESSAGE_SCROLLING

I'll have a look at those.
Maybe the heating status needs the solid background flag.
Scrolling should be based on the number of characters that fit horizontally, so the font size should factor into it.

[thinkyhead]

Turns out renaming that file to 6.ICO and changing the code to #define ICON 6 did the trick. So we can have a single DWIN_SET for both Creality's UI and the Marlin UI. I should have the status message scrolling fixed pretty soon. It's probably not scrolling due to the drawing optimization.

[thinkyhead]

…we can have a single DWIN_SET for both…

I might have spoken too soon. I need to consider the menu item images for English and Chinese too. One way I can save space is to move the boot screen elements into an ICO file, then only a single instance of the logo and accompanying text will be needed.

[mriscoc]

…we can have a single DWIN_SET for both…

I might have spoken too soon. I need to consider the menu item images for English and Chinese too. One way I can save space is to move the boot screen elements into an ICO file, then only a single instance of the logo and accompanying text will be needed.

I think that is time to get rid the menu item images for English, it had some sense when the resources were abundant, but now, I think that the display flash memory space can be used better.

[thinkyhead]

Here is the updated DWIN_SET for both CrealityUI and MarlinUI, containing the files…

0_start.jpg ...... CrealityUI Boot Screen
1_English.jpg  ... CrealityUI English Text
2_Chinese.jpg  ... CrealityUI Chinese Text
3.ICO  ........... MarlinUI Bootscreen bitmaps
4.ICO  ........... MarlinUI Status Screen bitmaps
7.ICO  ........... CrealityUI bitmaps
0T5UIC1.HZK
T5UIC1.CFG
T5UIC1_V20_4页面_191022.BIN

DWIN_SET-combined.tar.gz

Applied some fixes for CrealityUI…

• Fixed the "Control" Menu to draw titles from images when USE_STRING_TITLES is disabled, following the same pattern as the "Prepare" menu.
• Added the English and Chinese image title for "Advanced Settings."
• Better alignment of editable values with image titles.

More CrealityUI patches later…

• Need to highlight values under "Control" > "Motion" when editing.
• Need to add English and Chinese menu titles for the "Advanced Settings" menu
  (Finish New Advanced Settings menu for Ender3v2 with DWIN display #21534)
• Fix "Info" > "Back" so it returns to "Control" when activated from "Control."
• Scrolling Status Message.

[electronicm]

Is there actually a chance that umlauts can still be added?
The German typeface looks quite strange without äöü. : D

[The-EG]

Is there actually a chance that umlauts can still be added?
The German typeface looks quite strange without äöü. : D

That's going to be a challenge with most translations for this implementation, I think.

The font file on this DWIN supports only basic ASCII (0-127) and GB2312.

The basic ASCII doesn't include any accented, extended or special characters normally. MarlinUI already 're-purposes' some of the normally non-printable or otherwise unused characters for things like the menu arrows and the degree symbol, but I doubt there are enough left to create a full set of characters needed for many translations.

GB2312 is Chinese specific encoding, and the stock fonts are all Simplified Chinese characters appropriately. In theory you could use some of these characters to hold the extended characters needed, but they are a different shape. The ASCII characters in the font are rectangular, and have bitmaps for each size (ie. 6x12, 10x20, etc.). The GB2312 are square and are only 16x16.
The documentation states that the characters will be scaled to the proper size when used, but I'm a bit skeptical that they would look right if placed within text that uses the ASCII part of the font (square vs. rectangular - will there be extra space? etc.).
The code would of course have to be modified to send GB2312, which I'm admittedly completely ignorant as to how that would work. It could be quite easy, but I do have to wonder why Creality chose to use bitmaps for the menu items (both English and Chinese) if an 'easy' option was available otherwise...so I'm not too optimistic there.

My other thought on this is that we could 'steal' a few more of the ascii characters to use as accents, umlauts, etc. Then an extended character could be 'composited' together, by first drawing the normal character (with appropriate background) and then drawing the 'extension' character over the top of it, without a background. This approach would have the significant drawback of a drawing performance hit. Sending individual 'text' commands with single characters is much slower than a single call with all of the text. Doing this in a manner that is still performant would be challenging.

[thinkyhead]

The basic ASCII doesn't include any accented, extended or special characters normally.

The HD44780 support includes translation that maps accented characters to non-accented characters, for cases where the display only has Cyrillic or Japanese but not Western Accented. So, that same basic technique would need to be used to map an ASCII-127 font on other limited displays. Adding accents using extra calls would slow things down, but there aren't too many instances where lots of accented characters are needed at once, so it's worth experimentation. I'll be curious to figure out how to use GB2312 since 16x16 could be useful to make things more readable from a distance, and character-based Chinese support would be very welcome.

[thinkyhead]

I accidentally pushed bugfix-2.0.x here and closed the PR in a way that I couldn't re-open it. So, I rebased and squashed the current state and posted an updated PR #22594. (This PR could be re-opened, but you'd have to add my fork as a remote, pull down the commits, and push them up to your marlinui-crealitydwin branch, which is a minor hassle.)

The PR is just about ready, so I may just merge it into bugfix tonight, after I've done a little more tweaking of the status screens. With this merged I will be able to focus on the enhanced and jyers updates for the stock menu system.

It will be interesting to look at the GB2312 support soon and see what that entails, because it would be great to have Chinese support "for free."

[The-EG]

It will be interesting to look at the GB2312 support soon and see what that entails

Just a reminder: the font I created doesn't include the GB2312 glyphs. It would be simple enough to just copy them from the original font if needed.

[thinkyhead]

Ah, I see… I had the impression that the display included GB2312 as part of its ROM.

What is the extra cost for adding GB2312 to the DWIN_SET? I expect we are getting tight on available space.

[thinkyhead]

I finally merged this in somewhat refined form, with some minor changes in layout and support for up to 2 extruders. I'm sure there are many more improvements to be made. For example, if only one or two fonts are used then the others may be removed to recover space (if that helps). Maybe the standard menu font should be a size larger, at least as an option.

When a final version of the Enhanced / JyersUI extensions of the "Creality UI" is ready to deploy, at that point we could add the GB2312 translation layer as a start towards improved language support, and then look at Japanese, Cyrillic, Greek, etc. Of course, Western Accented support with ISO10646-1 would also be a welcome addition. The main advantage is that all fonts are monospaced bitmaps, so we really just need UTF-8 fonts with exact parity to the DOGLCD fonts (except of larger size) and then all the existing translation code would apply.

[llamaonaskateboard]

Hi! I'm trying out the MarlinUI from the current bugfix-2.0.x branch on my Ender 3 V2 and none of the icons seem to show up.
I also don't get any boot screen image, just the text "bugfix-2.0.x".
I've updated DWIN_SET from the bugfix-2.0.x examples with no change.

[electronicm]

@llamaonaskateboard I use these here with no problems:

DWIN_SET-combined.tar.gz

[The-EG]

For example, if only one or two fonts are used then the others may be removed to recover space (if that helps).

Unfortunately, that won't help, as I explained previously. According to DWIN, the font file is separate storage from the jpg/ico assets.

Even if the documentation is wrong, it's basically just an array of bitmaps. You could remove the larger sizes that we don't use, I think, but all of sizes including the largest we do use would have to be included. It's a very minimal format, no indexing or headers, literally just a series of 1bit-bitmaps one after the other. The firmware assumes they are all there, from what I can tell and is probably using hard coded offsets.

[llamaonaskateboard]

Worked it out, got bitten by SD card sector size and it wasn't actually flashing.

Can a note be added to the README in the examples to say the SD card must be formatted FAT32 with a 4096 byte sector size (Windows 10 default is 8192 bytes)?

[The-EG]

Can a note be added to the README in the examples to say the SD card must be formatted FAT32 with a 4096 byte sector size (Windows 10 default is 8192 bytes)?

I was just typing out this in a reply when your comment popped up. I would agree that this needs to be pointed out since the DWIN screen will still flash blue/orange very quickly when the card isn't being read properly.

[thinkyhead]

I've seen it pointed out here and there that FAT32/4K is required, but it can't hurt to add the note to all the pertinent README files in the Configurations repository.