platformio

[way5]

• platformio compatibility (latest arduino-framework, webSockets)
• AsyncWebServer is replaced with standard solution for the sake of memory saving
• WiFi module has been rewritten (excluded PersWiFiManager)
• overal optimization, fixed backup/restore

"pio" branch still contain the beta version, a few features may not work as expected.

[ramapcsx2]

Hey, I'm confused here. Didn't we just have a PIO thing?
#507

[way5]

Hi @ramapcsx2 . I my case it didn't worked, so I've fixed things a bit and I'd change them even more to order up, clean and prepare it to CI. If you, guys don't mind.
However if this is not an objective of this project it's ok, just let me know. :)
I'd also add a version to the firmware. Can you give me a hint where we are now in terms of versions?
Thanks

[ramapcsx2]

@Metaln00b Heya, could you share your thoughts?

[way5]

I would also dare to:

• move all the web things onto the flash (this is a headache to reflash the complete firmware every time you changing something in UI).
• split the fat main.cpp into various modules
• change the project file structure as per PIOs recommendations, and
• implement one click build for the whole project or even better the CI/CD

[Metaln00b]

@Metaln00b Heya, could you share your thoughts?

Well, it has nothing to do with PlatformIO, at least not directly. But I see a lot of changes that might break the environment for the main developers. That's not to say that the changes are bad :P

If I see it correctly, debug messages were moved to the websocket, spiffs were changed to LittleFS, a few endpoints regarding AccessPoint were adjusted etc.

[Metaln00b]

I would also dare to:

• move all the web things onto the flash (this is a headache to reflash the complete firmware every time you changing something in UI).
• split the fat main.cpp into various modules
• change the project file structure as per PIOs recommendations, and
• implement one click build for the whole project or even better the CI/CD

Would it be okay for you to describe the pull request in more detail, what it changes?

Platformio is not the best headline right now 😅

But first of all, thank you for your support with this project🙏

Most developers are currently busy with other projects and can't look at the whole changes of code, so it would be very important to have a description of the changes, especially changes to folder structures etc.

[way5]

Right. I am sorry for the vague description.
In the beginning this branch was named "littlefs" since my initial objective was just to a bit change the source code in terms of 100% compatibility with PIO (such as silent build with no warnings, low memory-low flash :) , using latest framework maybe, just in one click) and change spiffs to littlefs.

Since my first attempt of the rapid dive into the large gbs-control.ino was not so rapid because of the high project entropy, I've decided to groom it a bit and that is how it all started.
The source code is actually rising the learning curve too much to allow people participating by doing small and rapid changes. Touching one thing pulls needless tests of other features.

No-offensive criticism here btw. :)

Now about the changes were made:

1. gbs-control.ino was converted into main.cpp and three additional modules were spawned:
   • wserver.cpp - with all the webserver's stuffs
   • wserial.cpp - supposedly all the serial and WS related functionality
   • wifiman.cpp - replacement for an overloaded PersWiFiManager.cpp
2. SPIFFS -> LittleFS (since soon it becomes deprecated)
3. all (or at least the most) of the static data moved into flash (PGM)
4. some thing were reorganized in terms to be able to build with the latest arduino-framework
5. AsyncWebServer -> ESP8266WebServer (synchronous) it allowed to spare 3-5% of RAM.
6. platformio.ini been changed a bit.

I believe this is it...
The only warning which is left for now with OLEDMenuItem, since sizeof nonexistent object is not allowed.

The only environmental problem I see here is that you cannot use Arduino IDE for building and uploading anymore, which is I believe even better since you're moving onto PIO which encourages you to use VScode instead.

[ramapcsx2]

That all sounds reasonable, and I'm impressed someone went and started a cleanup here :p
May I suggest that you treat this more like a fork, all depending on whether you want to continue working on it or whether you consider it done?

I'm open to merging, but if this is still in the make and break stages, then I'd prefer waiting a bit, so the way to build this doesn't change every 2 weeks, seemingly :)

[ramapcsx2]

• It's really good to split up the big .ino file. Please just try to not segment it all too much :)
• SPIFFS -> LittleFS : sounds good. There is no preference, just whatever works is fine
• Remember that static data in flash will incur some latencies. Sometimes it's good to have frequently used data in RAM
• PIO / Arduino: Some people are used to their toolchains, and it would be great to keep compatibility with the main ones. If a pure Arduino and a pure PIO setup can both build the project, I'm good :)

[way5]

That all sounds reasonable, and I'm impressed someone went and started a cleanup here :p May I suggest that you treat this more like a fork, all depending on whether you want to continue working on it or whether you consider it done?

That is not done yet definitely. I'd like to make some changes to ease the burden :) for all those who're going through the debris when they join the project. I agreed to leave it as a fork in my personal repo, so your repo would stay unmodified. However that would bring more ambiguity and confusion over there.

I'm open to merging, but if this is still in the make and break stages, then I'd prefer waiting a bit, so the way to build this doesn't change every 2 weeks, seemingly :)

My plan is to finish implementing a few more changes in this branch so it can be merged into the master and spawn a new one to fix the project structure there.

Let me know what do you think on that.

PS: taking into account your next comment on the arch and especially the two IDEs-type building possibility. I believe there is no problem with it especially because Arduino IDE is less demanding than PIO.

I also expect collaboration on that from other members of the project. If someone do not agree with something, I'd like to hear that before the big changes, and maybe return to the "yet another fork" version. ;)

[nyanpasu64]

I'm a bit rusty in my understanding of the project, but:

• There is currently no versioning system that I'm aware of.
• Porting away from AsyncWebServer is a good idea (as it causes memory corruption and stack overflow from handling Wi-Fi operations in a deeply nested yield()), if you've made sure that handling one request at a time doesn't break any operations in the web UI (the more concurrent operations include saving/loading presets with/without per-slot filters, preset upload/download), and that the new server doesn't have the same issues.
• If you switch build systems it's nice to add docs for the new system. You probably should fix the docs if you remove the old build system.

[ramapcsx2]

What's been said. Feel free to go ahead and work on it, and as long as it still works at the end, there will be no problem merging it :)

[way5]

I've been going through all the previous commits and I think there are two main milestones:

1. throughout the whole project is the video IO thing (adding, fixing, improving)
2. UI update, including web UI and user interaction schema with physical controls, wireless things

Thus in terms of versions I propose to assign version 3 (major) to the code in current branch. However, having in mind "keep it simple" principle I believe that would be more clearly to use the date of release markings for now, ex.: 24.0501 or 24.0502b (beta), etc

Please share your opinion.

[way5]

I have a few questions related to the architecture:

1. Why there are userOptions and runtimeOptions and could they be merged in one structure of runtimeOptions?
2. What is the difference between rto->presetID and uopt->presetPreference?
3. What is the difference between Resolutions, Presets and Slots?
4. Why resolution change causes selecting custom preset?
5. Why "Presets" as a term can't be merged with Slots, so resolutions could be one of the options for each slot?
   ...

Concerning WebUI (master version):

1. Does backup/restore functionality works without an issue ?
2. Is there "remove preset" functionality currently in master?
3. Does OTA works without an issue ?
4. Does "reset/restore" functionality works properly?
   ...

~Thanks

[ramapcsx2]

I can confirm one odd thing about pretty much all Espressif platforms: Their reset circuitry is a recommendation, which is often not followed correctly by every implementation, and so their software to toggle the reset has seen multiple tweaks and versions over time.
Reset to upload is simply shaky every time. Find a setting that works, and it'll be good. But change too much (different USB port, different devkit, etc), and another setting might be needed.
Simply switch the upload baud rate setting a bit around, and I bet one other one will work :)

[nyanpasu64]

I am not using a prebuilt GBS-C, but a self-assembled unit with a NodeMCU v3.x.

In Arduino IDE, I upload with the NodeMCU v1.0 board configuration. On your branch, if I change platformio.ini to upload_resetmethod = nodemcu (tested on Windows) or remove the line (tested on Linux), I can upload to the board from PlatformIO.

Building and uploading the firmware

After pulling your latest branch changes (bf8aebf, minus your latest commit), I can build on Windows now.

I didn't know the filesystem had to be uploaded separately from the firmware. I had assumed it was unchanged from master, where the web UI's source code is embedded as byte arrays into the firmware image, and the program is fully functional when the flash filesystem is cleared (files are written as you change settings or save presets).

• Does this mean that users will have more steps to flash a working GBS-Control image?
• Will changes to the web UI's HTML file require flashing a new filesystem (I think containing file __index)? This erases saved presets and settings, which I don't think is a pleasant development experience (if I'm working on Web UI changes, I'd want to keep saved presets), though end users flash firmware less often.
  • To workaround this as a user, you can save all presets and reupload them after flashing a clean filesystem image. Maybe this is safer than "patching" the existing filesystem image with new system files (which could accumulate latent filesystem corruption like Race conditions, hanging, exceptions, and filesystem corruption when saving presets #421 and eventually break both saved presets and system files). It's still extra work that could be avoided by storing index.html in the firmware image directly.
    • I hope this PR prevents Race conditions, hanging, exceptions, and filesystem corruption when saving presets #421 from happening anymore, but we'll have to see if it still pops up during usage.
• I'm concerned that storing system files on the filesystem instead of the firmware image makes them vulnerable to corruption during flash writes. It also allows the web UI to desynchronize with the underlying firmware, which can result in partial firmware updates (where the C++ code is uploaded but the web UI isn't) and broken systems if the communication protocol between the browser and firmware changes.
  • Is there a specific reason you didn't leave index.html as part of the firmware image?

Unfortunately, on Windows "Upload Filesystem Image" generates an error and the GBS-C webserver sends the same 404 error as before.

WebUI ready to compress
'.' is not recognized as an internal or external command,
operable program or batch file.
*** Error 1
Building file system image from 'data' directory to .pio\build\d1_mini\littlefs.bin
/webui.html

I think this error results from running package.json's "build": "tsc --project ./tsconfig.json && cd ./public/scripts && node ./build.js && ./html2h.sh" in a cmd shell, which interprets a / as a flag for a program rather than a path separator. I do not know how to make the same shell command work on both Linux and Windows (perhaps look into https://www.google.com/search?q=package.json+scripts+windows+linux ?).

If I run this shell script manually from Git Bash, then "Upload Filesystem Image" again, I finally get a working page over Wi-Fi.

• Unfortunately storing critical files on the filesystem and rebuilding it when uploading, means that building and flashing this project now depends on having tsc installed (eg. from npm), which is an added dependency. Without tsc, PlatformIO on Windows still uploads the partial filesystem image, but the file is effectively empty (compresses to about 1 kilobyte or so) since you don't (properly?) abort the build process on failure.
  • IMO this makes it harder for users to build and setup a GBS-Control unit, unless we also offer prebuilt firmware images (in releases based on snapshots of known-good commits, and/or in CI which builds every push like Add CI workflow with artifact creation for binary flashing #540).

(edit before posting) I just noticed that "separate build/upload/filesystem" is described in the altered README.md, including in a PRO Tip. It's quite unintuitive that "Build or Upload Filesystem Image" is necessary but not visible until after you build.

---

It's possible some of my objections to the build system ignore the ways it's more self-contained than the old one (IIRC requiring manually running shell scripts to build a web UI file from templates, then gzip and convert to a header). I think that prebuilt binaries would avoid the tsc issue (but not the "storing system files together with options/slots" issue).

Usage

Resolutions:

• Weirdly the default preset says 240p in the slots list, even though the Wii is feeding 480p and the GBS-C is outputting 960p.
  • (observation) You moved the output resolution picker from the first "presets" tab to the second "control" tab?
• The web UI's Restart button does not work.
• Your resolution options are misnamed and partially broken. The 240p button actually outputs 960p (but incorrectly shifted to the right). The 960p button does not switch resolutions, but reinitializes video output (screen goes blank and returns) while reusing the currently enabled scaling preset (eg. passthrough, 480p, or 960p).
• If I switch to a fixed resolution on the second tab, then power-cycle the GBS-C, it reloads the currently selected custom slot. This differs from prior behavior where it would reload a fixed output resolution instead of a custom user-saved slot. Is the new behavior more intuitive to users? I suspect both are confusing?
• If I select Pass Through, save a slot, and power-cycle the GBS-C, I get no image until I click 240p (produces a 960p output), then return to Pass Through.

Wi-Fi:

• When the GBS-C is acting as an AP, and I close and reopen my M1 MacBook Air, I often cannot access the server at 192.168.4.1 until I disconnect and reconnect. I don't know if this error happens on master or not, and if it's a firmware bug or not.
  • After trying to scan for access points and reconnecting, when trying to reload the web UI, I get an error like 7968 it's not enough memory.... The number changes when I reload. The error fixes after disconnecting and reconnecting to the AP.
  • I have not tested for errors when using the GBS-C as a Wi-Fi client.
• I'm getting FrameSyncManager::runFrequency() debug prints (when using clockgen-based frame sync), which I had hidden behind a commented-out debug define when writing this code. The messages clutter the log when you're looking for input signal change/loss issues, most users probably don't want to see them (and honestly even master probably prints "unnecessary" messages that confuses users, see remove "harmless" framesync frequency warnings, when debugging is turned off? #473).

There may be more things I've missed, but I wanted to get this post out reasonably soon.

[way5]

In Arduino IDE, I upload with the NodeMCU v1.0 board configuration. On your branch, if I change platformio.ini to upload_resetmethod = nodemcu (tested on Windows) or remove the line (tested on Linux), I can upload to the board from PlatformIO.

Fixed, now it's uploading fine.

Building and uploading the firmware

After pulling your latest branch changes (bf8aebf, minus your latest commit), I can build on Windows now.

The last commit even more optimized for Windows

I didn't know the filesystem had to be uploaded separately from the firmware. I had assumed it was unchanged from master, where the web UI's source code is embedded as byte arrays into the firmware image, and the program is fully functional when the flash filesystem is cleared (files are written as you change settings or save presets).

• Does this mean that users will have more steps to flash a working GBS-Control image?

if someone wish to make a clean install we can not forbid that on the contrary, we must make the process clear for everyone.

• Will changes to the web UI's HTML file require flashing a new filesystem (I think containing file __index)? This erases saved presets and settings, which I don't think is a pleasant development experience (if I'm working on Web UI changes, I'd want to keep saved presets), though end users flash firmware less often.
  • Is there a specific reason you didn't leave index.html as part of the firmware image?

As I've mentioned before in terms of ease development I excluded WebUI data from image (temporary I believe). I don't have anything against to store it in flash while it's stored correctly.

• To workaround this as a user, you can save all presets and reupload them after flashing a clean filesystem image. Maybe this is safer than "patching" the existing filesystem image with new system files (which could accumulate latent filesystem corruption like Race conditions, hanging, exceptions, and filesystem corruption when saving presets #421 and eventually break both saved presets and system files). It's still extra work that could be avoided by storing index.html in the firmware image directly.

Such things like #421 were not happening to me. May be because pio branch uses LittleFS already, as it is faster that SPIFFS. I can see the only threat when FS corruption may happen. It is when someone commits a faulty code, which actually may happen, we're all human. Anyways, there is BACKUP functionality working fine. It dumps all the contents of the flash, except system (__(.+)) files.

• I'm concerned that storing system files on the filesystem instead of the firmware image makes them vulnerable to corruption during flash writes. It also allows the web UI to desynchronize with the underlying firmware, which can result in partial firmware updates (where the C++ code is uploaded but the web UI isn't) and broken systems if the communication protocol between the browser and firmware changes.

In my practice it happened only if I mess somewhere in the code. Right now I have running few ESP32s which are logging 24/7 onto its flash (with system files on flash). I am aware of flash wearing, but too long time should pass and too many read/writes must happen to flash till it fails.
As I mentioned above, ...someone must commit a faulty code.

Unfortunately, on Windows "Upload Filesystem Image" generates an error and the GBS-C webserver sends the same 404 error as before.

WebUI ready to compress
'.' is not recognized as an internal or external command,
operable program or batch file.
*** Error 1
Building file system image from 'data' directory to .pio\build\d1_mini\littlefs.bin
/webui.html

Fixed.

• Unfortunately storing critical files on the filesystem and rebuilding it when uploading, means that building and flashing this project now depends on having tsc installed (eg. from npm), which is an added dependency. Without tsc, PlatformIO on Windows still uploads the partial filesystem image, but the file is effectively empty (compresses to about 1 kilobyte or so) since you don't (properly?) abort the build process on failure.

I tgink for now the data directory could be removed from ignore to simplify the whole procedure for a user.

• IMO this makes it harder for users to build and setup a GBS-Control unit, unless we also offer prebuilt firmware images (in releases based on snapshots of known-good commits, and/or in CI which builds every push like Add CI workflow with artifact creation for binary flashing #540).
  ... I think that prebuilt binaries would avoid the tsc issue (but not the "storing system files together with options/slots" issue).

That is why I had /builds directory there. The reason is to make it easy for everyone even without knowledge.
CI is actually an objective. But I don't know when/if I actually make it :)

(edit before posting) I just noticed that "separate build/upload/filesystem" is described in the altered README.md, including in a PRO Tip. It's quite unintuitive that "Build or Upload Filesystem Image" is necessary but not visible until after you build.

I fixed some sentences there. That is mostly WIP areas that will be changing.

Usage

Resolutions:

• Weirdly the default preset says 240p in the slots list, even though the Wii is feeding 480p and the GBS-C is outputting 960p.

This part requires testing and fine tuning. I could not yet do the comprehensive test on various devices.

• (observation) You moved the output resolution picker from the first "presets" tab to the second "control" tab?

Correct, this is because resolutions will not be as a special presets, I believe users may wish to change resolutions independently of presets. The diagram that I've posted (in README) is actually about that.
The old code has deep ambiguity whether you change slot+preset
or
switching resolutions+presets
or
a preset is set automatically and then user select a slot and then when he/she changes resolution everything falls apart.
I believe that resolutions could be changed by user at any moment without changing other parameters, and to be stored as a parameter of each slot.

• The web UI's Restart button does not work.

👍 Already fixed, goes with the next commit.

• If I switch to a fixed resolution on the second tab, then power-cycle the GBS-C, it reloads the currently selected custom slot. This differs from prior behavior where it would reload a fixed output resolution instead of a custom user-saved slot. Is the new behavior more intuitive to users? I suspect both are confusing?
• If I select Pass Through, save a slot, and power-cycle the GBS-C, I get no image until I click 240p (produces a 960p output), then return to Pass Through.

The system behavior while switching resolutions may change a bit in future, however "I believe that resolutions could be changed by user at any moment without changing other parameters, and to be stored as a parameter of each slot."

• I'm getting FrameSyncManager::runFrequency() debug prints (when using clockgen-based frame sync), which I had hidden behind a commented-out debug define when writing this code. The messages clutter the log when you're looking for input signal change/loss issues, most users probably don't want to see them (and honestly even master probably prints "unnecessary" messages that confuses users, see remove "harmless" framesync frequency warnings, when debugging is turned off? #473).

Fixed.

TODO:

• > * When the GBS-C is acting as an AP, and I close and reopen my M1 MacBook Air, I often cannot access the server at 192.168.4.1 until I disconnect and reconnect. I don't know if this error happens on master or not, and if it's a firmware bug or not.

this may be mDNS or network specific issue or may be it's somehow related to M1 MacBook Air. I couldn't reproduce this case.

• > * After trying to scan for access points and reconnecting, when trying to reload the web UI, I get an error like 7968 it's not enough memory.... The number changes when I reload. The error fixes after disconnecting and reconnecting to the AP.

I could not reproduce this failure, however measures were taken to prevent possible service denials because of insufficient memory.

• > * Your resolution options are misnamed and partially broken. The 240p button actually outputs 960p (but incorrectly shifted to the right). The 960p button does not switch resolutions, but reinitializes video output (screen goes blank and returns) while reusing the currently enabled scaling preset (eg. passthrough, 480p, or 960p).

That is something to check because it seems to be working fine to me.

[way5]

@nyanpasu64, why was "matched presets" functionality added?
The following is taken from original WebUI help message:

If enabled, default to 1280x960 for NTSC 60 and 1280x1024 for PAL 50 (does not apply for 720p / 1080p presets).

This statement says 1280x960@NTSC 60 and 1280x1024@PAL 50 will be forceable used except cases of 720p/1080p resolutions.
Why is that? Is there an issue with output resolutions on some devices?

---

UPD:
line number 4253 in master:

if (uopt->matchPresetSource && (result != 8) && (GBS::GBS_OPTION_SCALING_RGBHV::read() == 0)) {
    SerialM.println(F("matched preset override > 1280x960"));
    writeProgramArrayNew(ntsc_240p, false); // pref = x1024 override to x960
} else {
    writeProgramArrayNew(ntsc_1280x1024, false);
}

and then for PAL input (line 4269):

if (uopt->matchPresetSource) {
    SerialM.println(F("matched preset override > 1280x1024"));
    writeProgramArrayNew(pal_1280x1024, false); // pref = x960 override to x1024
} else {
    writeProgramArrayNew(pal_240p, false);
}

it is somewhat confusing logic, I believe there was a purpose to do so, but it is not clear to me.

[Aleksandr-S12]

Не хочет собираться на Arduino 1.8.19 Выдает ошибку gbs-control\src\wifiman.cpp:48:9: note: in expansion of macro '_DBGF'
_DBGF(PSTR("(WiFi): got IP: %s\n"), WiFi.localIP().toString());
Пожалуйста укажи версии библиотек. Пробовать каждый раз на угад, это полное безумие.
Что касается кода, он так неудобно разбит на множество отдельных файлов. Хотел в твою версию добавить OSD, но разобраться, где что находиться практический невозможно, сразу отпала желание. Оригинальный код намного удобнее редактировать , там все важные функции в одном файле, а у тебя разбиты на сто файлов! Не визжу в этом смыла, создавать столько вкладок, сам же потом запутаешься. Могу быть не прав, так как не являюсь программистом

[ramapcsx2]

I think the auto translator had tea time on this one ;p

[Aleksandr-S12]

Hello ramapcsx2! This comment was left for Sergey Ko (way 5). My opinion is that what he did with the original GBS_C code is unacceptable. He split the main code into many tabs and renamed the variables, you don't need to do that! Complicated the procedure for installing firmware on the Arduino IDE platform, not everyone can use Visual Studio Code (PlatformIO). I will hope that the merge will not happen with the original GBS_C firmware. I didn't want to offend anyone here, that's my opinion from the outside!

[ramapcsx2]

Wo gehobelt wird, fallen Späne.
This is a major revamp of a bunch of code that really needs it. As long as it ultimately comes together, this is fine by me.
(But it does have to come together ;p)

[nyanpasu64]

Personally I think it's reasonable to keep this PR as a "fork" of the GBS-C codebase, and edit the README to point to the updated/changed fork as another choice. The advantage is that it would avoid breaking existing flashing/usage workflows (I don't fully understand the rewrite and last time I tested it changed the UI and had bugs in existing functionality) and I/rama/etc. can keep developing the old code and incorporating changes as needed. The disadvantage is that having multiple options for firmware may fragment development time and fixes, and confuse end users (until a consensus develops on which branch to officially continue going forward).

[Aleksandr-S12]

Thank you, I understand everything. If a merge occurs, you will have to start work on embedding the on-screen menu again. I don't know for sure, but in the near future they may appear on Aliexpress GBS_C with an on-screen menu. Here is a photo of the GBS_C_OSD motherboard

[Aleksandr-S12]

[way5]

Приветствую!

В первую очередь, эта тема не для обсуждения проблем установки. Это запрос на слияние, что означает обсуждение вопросов по его подготовке и проведению, включая архитектуру продукта. В будущем; если у кого-то появилась проблема, милости прошу в issues.

Не хочет собираться на Arduino 1.8.19 Выдает ошибку gbs-control\src\wifiman.cpp:48:9: note: in expansion of macro '_DBGF' _DBGF(PSTR("(WiFi): got IP: %s\n"), WiFi.localIP().toString());

Указанная ошибка - есть нонсенс. Такое может произойти в случае если часть файлов была скопирована в ветку master вручную. В данной ветке (pio) с первых коммитов опубликован обновлённый README, где пошагово изложен процесс сборки (вместе с файловой системой) и установки. Ошибки при сборке случаются у тех, кто не читает инструкции. В данном случае инструкция = 6 простых шагов.
Я озаботился и проверил, сделав установку всего начисто. То-есть удалил библиотеки Arduino IDE, клонировал последние версии в папку libraries в ТвоиДокументы/Arduino/:

git clone https://github.com/Links2004/arduinoWebSockets.git
git clone https://github.com/pavelmc/Si5351mcu.git
git clone https://github.com/ThingPulse/esp8266-oled-ssd1306.git

Затем, клонировал репозиторий, удалил main.cpp и собрал последний коммит без каких-либо проблем.
Отчёт о сборке приложен ниже.

Пожалуйста укажи версии библиотек.

Самые актуальные версии. Больше нечего сообщить.

Пробовать каждый раз на угад, это полное безумие.

Наугад не надо. Следует потратить 3 минуты и ознакомиться с README

Что касается кода, он так неудобно разбит на множество отдельных файлов.

Подобное заявление кажется странным, особенно если ты не программист. Никто не запрещает использовать версию из оригинального master. Ветка pio создавалась с другой целью.
So, why the functional approach, for instance in PHP, is better than MVC in 21st century? 😄

Хотел в твою версию добавить OSD, но разобраться, где что находиться практический невозможно, сразу отпала желание.

В "моей" версии OSD работает также, как и в мастере. Функционал OSD уже существует.

Оригинальный код намного удобнее редактировать , там все важные функции в одном файле, а у тебя разбиты на сто файлов! Не визжу в этом смыла, создавать столько вкладок, сам же потом запутаешься. Могу быть не прав, так как не являюсь программистом

"Дельный" совет от не-программиста? Not to be rude, again, you're free to use original master with all its heavy mess in code, obsolete sources, memory leaks and more if you wish. pio branch has been created for someone who wish to learn source code fast and have an easy and flawless install. You have failed both objectives... pity..

build.txt

[way5]

Personally I think it's reasonable to keep this PR as a "fork" of the GBS-C codebase, and edit the README to point to the updated/changed fork as another choice.

Again, as I said earlier, I am perfectly OKAY with maintaining this branch myself on my repo as "yet another fork", IF everyone decides that.
However in that case I'd prefer do not to be mentioned in

...the README to point to the updated/changed fork as another choice.

who knows what I'd implement there 😄, so you may feel uncomfortable to have links to a poor copy in the official repo.

The advantage is that it would avoid breaking existing flashing/usage workflows (I don't fully understand the rewrite and last time I tested it changed the UI and had bugs in existing functionality) and I/rama/etc. can keep developing the old code and incorporating changes as needed. The disadvantage is that having multiple options for firmware may fragment development time and fixes, and confuse end users (until a consensus develops on which branch to officially continue going forward).

I have to admit you're blazing fast😄 While someone is asking questions of the code, there is mostly stunning silence but everything changes when a "non-developer" reports of a non-existing problem. Rare ability to foster. 😄
There are also faithful followers in your team. 😁

Same with a dummy-locker commit shortly after this request was published. Initially I had in mind that local folks are interested in GBSC's evolution, but it seems the "to be or not to be" questions are more important nowadays.😄