GUI - Fix bitmap display on AVR

[AbsoluteCatalyst]

Was just using the wrong XBM function. (Finally got AVR to stop rebooting. My watchdog was still turning on after all.)

[repetier]

I see. Same reason I had problems at the start. Where 32 bit processors make no difference it gets important for AVR:-(

[AbsoluteCatalyst]

Speaking of which, I saw you changed the MOTOR_NAMES macro to use the Com class variables for them instead of PSTR. (Since PSTR inside the array doesn't work on AVR, right?)

Do you think there's any better solution to easily storing progmem strings inside an array like that in the config? Makes it a little difficult for users to add their custom strings.

Example: I was changing our sd extension check function and created these:

#define SD_GCODE_EXTENSION_NUM 5
#define SD_GCODE_EXTENSIONS \
    { ".gcode", ".gco", ".gc", ".g", ".nc" }

#define SD_TEXT_EXTENSION_NUM 3
#define SD_TEXT_EXTENSIONS \
    { ".md", ".txt", "readme" }

[repetier]

Yes that is the reason. But I also have added the IO_STRING(name, text) macro to create custom strings that way.

Requires still the split config and config_io but only solution to get extra strings in flash memory instead. For reasonable frequent codes we can misuse Com strings. For example these extensions are unlikely to be changed by users once they are in default config and we can use them as fallback more easily.

BTW: What are the text extensions for? Just to exclude them?

[AbsoluteCatalyst]

Oh sweet, I forgot I saw that new IO_STRING module in my last merge. That works.

The text extensions are for a new function I created recently. I made it so we can view gcode and text files through the sd card. (I'm using small text to fit the most) Looks a little like this

I made it just for fun originally, but I realized it might have considerable use for a printer manufacturer to have readme's included.

Definitely optional to have it if anything, and probably won't work for AVR's anyway. (I'm using dynamic memory to load them.) It works for 20x4's too but er, even less screen space there.

And after that we can hide anything else that isn't either text or gcode.

[repetier]

I see - a readme or txt files describing gcode might in deed be handy here. AVR might be limited to very small files if it is only local memory in a function. If you read full text I guess avr should have disabled it. No problem since it is no essential function.

[AbsoluteCatalyst]

Yeah, even on an 32bit SKR; it'll eventually run out of memory for large files. I'm storing the difference between indexes of each word wrap newline point as you scroll on; but even then. Can usually read a few thousand (60k~) lines or so though.

PS. I've been playing with some experimental changes to the UI here and there. What do you think about this popup menu concept for selecting files?

I made a similar popup for special prompts (You have to wait until you can press OK):

[repetier]

Looks good. How does it woek? Just draw 1 level lower and then current level without clearing? Other question what to do on 20x4 display. Guess here it is just a new level without content a level higher?

[AbsoluteCatalyst]

Yup, My refresh function looks like this:

    lcd.firstPage();
    do {
        lcd.setFontMode(0u);
        int origLevel = level;
        while (pageType[level] == GUIPageType::PROMPT_POPUP) {
            level--;
        }
        while (origLevel != level) {
            if (pageType[level] != GUIPageType::PROMPT_POPUP) {
                callbacks[level](GUIAction::DRAW, data[level]);
            }
            level++;
        }  
    } while (lcd.nextPage());
    callbacks[level](GUIAction::DRAW, data[level]);

It should allow multiple popups ontop of each other if it happens (I think i'm probably going to disallow it though) I also had to add another parameter to menustart to optionally disable the status bar rendering.

For the 20x4's er, I haven't made it yet; despite my main printer using one. Probably going to see about making it today.

[Plebejer258]

Hi, sorry for my comment on this functions. Why you spend time and effort to integrate this functions in an very old Display System, with limited Memory Resources and timing issues. Most of the Users today want a graphical Display with Touch functions. They are very cheap today and offered with Open Source Software too. This Displays have there own MCU with plenty of Memory and Power. From my Standpoint it makes more sense to spend your time and knowledge there. I have made a Repetier Version for the BTT TFT35, which you can find under my User ID. It is not perfect yet but covers most of the Functions which you have with the existing Display and with Repetier Host. A good starting point for further developments. Even WIFI is possible. This is just my 2 cent, but from a Business standpoint the Future is with the Graphical Displays. Regards F.E

[repetier]

Just what I thought:-) So for 20x4 we just add a new page for PROMPT_POPUP and are still compatible.

@Plebejer258 This is an easy and direct solution with less points of failure. The TFT looks better but as you already saw it also has the problem the the firmware flexibility makes problem when it comes to configuration etc. My dream is still to have a combination where you have some simple functions on the TFT and a nice front screen for some modes but in an expert screen or copy screen you mimic the gui just in nice. I mean that is why we have special pages like warning, wait, input which can be made as nice tft screen with colored icons, back icon, ... All we need is a way to communicate the gui data in a standard way and you get all the config stuff and special functions more or less for free. When I'm done with the LPC processor I plan to have a closer look into your solution and help adding such a mode in addition. That would be a better (means nicer) solution then mimic the lcd on a tft which I also have seen somewhere.