[WIP] MarlinUI for Creality DWIN

[thinkyhead]

This PR provides the beginning framework for a MarlinUI implementation supporting the DWIN screen with click-wheel control that comes stock on the Ender 3 V2. With a little more work this can be extended to handle touches on the CR-6 SE as we do with other touch displays.

This PR is currently in very rough alpha shape, and needs a lot of work. At this stage the firmware compiles and some elements of the display will update, but the drawing is not yet stable, and we still need to gather information to handle text encoding.

So, this is a starting-point to fix up the drawing code and get the full MarlinUI implementation fleshed out for this display in both Portrait (initially) and Landscape mode. Although this aims to initially work without the need for extra assets installed, just drawing basic boxes, for completeness the final version should have a full Status Screen that requires our own color assets to be installed on the display.

[CRCinAU]

@thinkyhead I think you missed some White -> Color_White changes in Marlin/src/lcd/dwin/e3v2/dwin.cpp with these changes...

Also:

Marlin/src/lcd/dwin/marlin/ultralcd_dwin.cpp: In function 'void _draw_bed_status(bool)':
Marlin/src/lcd/dwin/marlin/ultralcd_dwin.cpp:203:9: error: 'planner' was not declared in this scope
         planner.leveling_active && blink ? '_' :

[enigmaquip]

Can we pull from the libiconv library for text encoding? https://git.savannah.gnu.org/gitweb/?p=libiconv.git;a=blob_plain;f=lib/gb2312.h;hb=HEAD
or do we just need a simple character map?

[thinkyhead]

Can we pull from the libiconv library for text encoding?

We first need to know what character encodings and font formats these HMI / DWIN screens understand and then simply do the usual translation, as we do for any screen with limited capabilities.

[enigmaquip]

Can we pull from the libiconv library for text encoding?

We first need to know what character encodings and font formats these HMI / DWIN screens understand and then simply do the usual translation, as we do for any screen with limited capabilities.

Per the T5UIC1 application guide it expects GB2312.... I pulled the font file for the screen apart here
https://github.com/enigmaquip/T5UIC1_Font
All the GB2312 stuff is 16x16 but the documentation makes it seem like it'll scale to the font size passed in the send string

[CRCinAU]

Still getting:

Marlin/src/lcd/dwin/marlin/ultralcd_dwin.cpp: In function 'void _draw_bed_status(bool)':
Marlin/src/lcd/dwin/marlin/ultralcd_dwin.cpp:203:9: error: 'planner' was not declared in this scope
         planner.leveling_active && blink ? '_' :                                                                      
         ^~~~~~~                                                                                                       

Is that a definition issue or a required change missing?

I should note that I'm attempting to do this with a BLTouch enabled...

[CRCinAU]

I'm not quite sure this is the intended output?

Images

Are the only changes required to disable DWIN_CREALITY_LCD and enable DWIN_MARLINUI_PORTRAIT?

[enigmaquip]

Not sure if this helps, but this is the character mapping, I can format this any way needed

charmap.txt

Also did a quick scan through the translation files and noted anything not mapped

not_in_gb2312.txt

[Sebazzz]

FYI - the Creality CR-6 SE source code is now also available if you need to take a look. Currently available on a Google drive link as it has been release through Naomi Wu, so not yet via the official website.

EDIT: Source code of Creality appears to have been based on commit 25a7cea. I've "merged" their changes on top of that commit 25a7cea, so can see the changes they've made: Sebazzz@f3876e8

[thinkyhead]

I'm not quite sure this is the intended output?

This draft is pre-alpha and it has been made public for collaboration.

[thinkyhead]

but landscape-oriented and without hardware controls

Generally, you'll just tailor the drawing to whatever DWIN / HMI system you have installed on the display.

This PR is built on the assumption that the basic assets included by Creality3D will be installed on the display, but later we'll add our own custom images in the form of JPG files and draw parts of those. And, I have the original asset files from Creality, so I can edit those in the appropriate tools, which exist only for Windows, or replace their assets entirely, and generate our own ICON assets. I just want to get this into working order with the basics in place first, and then I can start doing more enhancements.

Since your display doesn't have a knob, you could start out just trying to make a Status Screen that draws temperatures, fan speed, SD status, status message, etc., in the landscape layout. You'll notice that other fancy color displays which could do a Status Screen layout more suited to the extra space are —for the moment— just following the layout of the DOGM128 display. You can imitate the DOGM128 layout if you want to, but don't feel constrained.

[The-EG]

In case anyone is interested:
I spent some time today getting this building against current bugfix. It's currently on my fork in my marlinui-crealitydwin branch.

It boots up and 'works' on my Ender 3 V2, which is a step more than I got the last time I played with it. You can cherry-pick the last
two commits from that into your own branch (or just check mine out) if you want to play around with it yourself.

Some notes:

• I used my 'normal' ender 3 v2 configuration.h with some modifications:
  • Both bootscreens disabled
  • M73 progress disabled
  • #define LCD_SERIAL_PORT 3
  • #define DWIN_MARLINUI_PORTRAIT
• planner is now undefined here and I wasn't able to figure out what the proper fix is yet.

Current state (as-is, unchanged):

• Hotend and Bed temp
• X/Y/Z positions
• Feedrate
• SD percentage/elapsed time
• Status line
• Clicking the encoder does bring up the menu but it's not functional enough to use.

PXL_20210613_185730337.mp4

Note the blink on each refresh.

That's about all my motivation for this Sunday afternoon, but now that's it's building and booting again I will probably poke around with it..and hopefully this will spur some others too!

[mriscoc]

In case anyone is interested:
I spent some time today getting this building against current bugfix. It's currently on my fork in my marlinui-crealitydwin branch.

It boots up and 'works' on my Ender 3 V2, which is a step more than I got the last time I played with it. You can cherry-pick the last
two commits from that into your own branch (or just check mine out) if you want to play around with it yourself.

Some notes:

• I used my 'normal' ender 3 v2 configuration.h with some modifications:

  • Both bootscreens disabled
  • M73 progress disabled
  • #define LCD_SERIAL_PORT 3
  • #define DWIN_MARLINUI_PORTRAIT

• planner is now undefined here and I wasn't able to figure out what the proper fix is yet.

Current state:

• Hotend and Bed temp
• X/Y/Z positions
• Feedrate
• SD percentage/elapsed time
• Status line
• Clicking the encoder does bring up the menu but it's not functional enough to use.

PXL_20210613_185730337.mp4
Note the blink on each refresh.

That's about all my motivation for this Sunday afternoon, but now that's it's building and booting again I will probably poke around with it..and hopefully this will spur some others too!

Seems very good, I will try to replicate your goals and do something also.

[The-EG]

A tiny bit of progress, but menus are almost usable:


https://youtu.be/CRcmNWD_nL4

There's an additional commit in my branch linked above with these changes. Note: these changes are very messy but I'm putting them out here in case it may help someone else who's looking at this before I get the chance to try some more.

edit: as you can probably see, the display is slow. Poking around, this appears to be because everything is sent one. character. at. a. time. I would think for this particular case, it would probably make more sense to build the strings first and then send them once...but that can be refactored later.

another edit: I've added another commit that switched things from being sent 1 character at a time to sending full strings. What a difference! With that change, the menus are very functional. There's still a few things missing, like the confirmation screen and UBL screens, etc..but it is minimally useable at this point.

I've also been working on arranging the status screen like the DOGM128 display, with some icons pulled in from the existing assets (yeah they are kind of tiny):

This isn't in my branch yet, but I'll add another commit for it once I'm at least somewhat happy with it.

[The-EG]

Some more updates to my branch. Started playing around with icons and animation (also found a bug in Creality's part of the DWIN code, shocker!).

This is all now in my branch, including the needed DWIN_SET (icons) and my configs I've been using for reference (theeg-configs).

This is currently usable enough that I'm actually printing on it, between making changes/flashing:

PXL_20210618_142311207.mp4

I'm going to move forward with more changes including landscape mode and then hopefully have it cleaned up and ready to create a separate PR soonish.

[CRCinAU]

If anyone happens to come across a screen mount for the Ender 3 V2 (being the main DWIN victim at the moment) that will do landscape, I wonder if it'd be worthwhile linking it in with the code...

[The-EG]

If anyone happens to come across a screen mount for the Ender 3 V2 (being the main DWIN victim at the moment) that will do landscape, I wonder if it'd be worthwhile linking it in with the code...

It's ultimately up to Thinkyhead I imagine, but I can't see why that'd be done in general. It would be one more thing to maintain (links go bad, etc.) and there are constantly new designs popping up, etc...

I imagine if enough people start using this in landscape mode multiple designs will pop up. In fact, I'm already thinking about how I'd design it...in addition to the issue of maintaining a link, I don't think we want to try to decide what design is 'best'! (and then have users submit issues because they disagree).

That being said....landscape is quite nice on this. I think it's officially resurrected mine from the 'stuff I might use one day' shelf:

(still needs some tweaking, but not bad imo)

[CRCinAU]

@The-EG That sounds fair on all accounts... I'll see what I can do about getting at least one design for a landscape screen mount done before we get a full PR done to give people a Day #1 option to go with. I like providing people with complete turnkey stuff :)

[The-EG]

Per the T5UIC1 application guide it expects GB2312.... I pulled the font file for the screen apart here

@enigmaquip , if I'm reading your comment & decode.go script correctly, it looks like the first part of the HZK font file is a set of 1-bit bitmaps, one for each size, for ascii 0-127.

Bitmaps meaning the very basic sense, literally just a set of 0/1 bits, arranged so that each font bitmap is 16 characters wide, with the data padded so that the rows are aligned to byte boundaries.
No file header or anything?

If that's the case, it should be pretty straightforward to convert the marlin fixed font to this HZK format, but it will have to be scaled up for the larger sizes.

I did find a program from DWIN that claims to be able to generate the font file automatically, but it appears to only work on TTF fonts, and they have to be installed on the system so you can't just pick any random font file.

[The-EG]

Bitmaps meaning the very basic sense, literally just a set of 0/1 bits, arranged so that each font bitmap is 16 characters wide, with the data padded so that the rows are aligned to byte boundaries.
No file header or anything?

I had it partially wrong here...it's actually more simple: the first part of the HZK file is made up of 1bit bitmaps for each glyph (0-127 for each font size, etc). Each row of the bitmap is byte padded, rows start at the top of the glyph, and it's all big endian.

This makes is very straightforward to convert BFD fonts to the HZK format (ignoring the second 16x16 part of the file). The only issue is that a BFD for each size is needed. I used Fony to upscale the existing Marlin fixed 6x12 font to the appropriate sizes and then created an HZK.

It works...albeit a bit ugly 😄

But, this allows us to get the proper special characters, like the menu arrows, degree symbol, etc:

At this point, the newly created BFDs can be manually edited to smooth the glyphs (I did the arrows above, and I think the result is quite good) or we could use some other font and just import specific glyphs from the marlin font. Maybe even generate something from a TTF font like the DWIN utils do, or just use the existing font...although that wouldn't be my first choice.

[ihrapsa]

This work you're doing is unbelievable! I'm really glad that this display is not dead yet. Someone above mentioned the BTT TFT display with the MarlinUI (that emulates the ST7920 LCD). I'm wondering if this implementation works in the same way. I'm asking this because I'd really like to have this display ported to Klipper as well. Currently klipper only supports basic LCDs but is able to work with that BTT TFT display through that ST7920 emulation.
Thanks!

Here is the reference for the BTT TFT support: Klipper3d/klipper#2231

[The-EG]

This work you're doing is unbelievable! I'm really glad that this display is not dead yet. Someone above mentioned the BTT TFT display with the MarlinUI (that emulates the ST7920 LCD). I'm wondering if this implementation works in the same way. I'm asking this because I'd really like to have this display ported to Klipper as well. Currently klipper only supports basic LCDs but is able to work with that BTT TFT display through that ST7920 emulation.
Thanks!

Here is the reference for the BTT TFT support: KevinOConnor/klipper#2231

Thanks!

Based on what I've seen while working on this: no, it wouldn't be nearly that simple. The concept is similar, the DWIN lcd is running it's own firmware and just listening to Marlin via a serial connection, but the protocol is completely different. I've linked the reference docs in my PR, #22211.

[ihrapsa]

This work you're doing is unbelievable! I'm really glad that this display is not dead yet. Someone above mentioned the BTT TFT display with the MarlinUI (that emulates the ST7920 LCD). I'm wondering if this implementation works in the same way. I'm asking this because I'd really like to have this display ported to Klipper as well. Currently klipper only supports basic LCDs but is able to work with that BTT TFT display through that ST7920 emulation.
Thanks!
Here is the reference for the BTT TFT support: KevinOConnor/klipper#2231

Thanks!

Based on what I've seen while working on this: no, it wouldn't be nearly that simple. The concept is similar, the DWIN lcd is running it's own firmware and just listening to Marlin via a serial connection, but the protocol is completely different. I've linked the reference docs in my PR, #22211.

I see. Should have checked your commit. Got excited and thought this was emulating some basic LCD. 😬

Anyways, if there are people still interested into porting this to Klipper as well I'd be more than happy to help with testing or anything. There's some success with touchscreen DWIN displays (T5UID1 based) but from what I've read, that one is DGUS based and works a bit different than this T5UIC1 on the E3V2 display.