Update esp8266 framework to most recent version (2.5.3, core 2.7.1)

[positron96]

I've tried to incorporate an LCD display with u8g2 library, but stumbled upon bug in older versions of esp8266 arduino core. So I tried to update the version but it appeared that there are some breaking changes in SD libraries. SdFat now contains duplicate headers, so I removed it, as well as FileWrapper because core's File class is used in all storage backends, and it can be used instead.
All this allowed to use the most recent version of esp8266 framework. It compiles both esp8266 and esp32 versions, but I can not test it at the moment. If anyone fancies testing, please go forth.

Also, CS pin can be specified in begin().

PS. SPIFFS is now deprecated in ESP8266, so I tried to change it to LittleFS, but SPIFFSEditor from AsyncWebServer seems to be still using it, so I left SPIFFS in place.

[probonopd]

Hello @positron96, thanks for your PR.

As far as I remember, we are actually not using SPIFFSEditor at all at the moment, so maybe it would be a good idea to remove SPIFFSEditor adn go with LittleFS. What do you think?

https://github.com/lorol/ESPAsyncWebServer/tree/master/examples/ESP_AsyncFSBrowser seems to use LittleFS. Looks like it's all still pretty new.

Were you able to run longer prints successfully with your modified versions? We had some unexplainable lockups with longer GCODE in the past, e.g., #150. I wonder whether the new core might resolve them...

[positron96]

Hi.

Actually, once I've given some thought to replacing SPIFFS with LittleFS, I think there is a serious issue with it. There would be problems for existing users who upgrade a board to a new version, because backend SPI layout is different for these 2 libraries. So users will loose their SPI contents once they upgrade. Maybe it's better to plan this to some 2.0 version?

Honestly, at the moment I have difficulties (organisational) with accessing the internals of my printer, so I have not yet hooked the new version to the printer.

[probonopd]

I think it is no problem if upgrading means that the file stored on the printer can no longer be used - as long as we clearly put this into the release notes.

No hurries. This is a slow-moving project. Just ping me once you have tested everything and it is working reliably with real hardware, with and without an SD card. Thanks!

[probonopd]

Hello @positron96, did you further test this?

Were you able to run longer prints successfully with your modified versions?

[positron96]

Hi. Unfortunately, no.
Since I've started using WirelessPrinting, I've realized the shortcomings of the method (the need to keep the PC running, less control of the process via printer's LCD), so I switched back to stand-alone printing from SD card and haven't performed extensive testing of the feature.

[probonopd]

The whole purpose of WirelessPrinting is so that you DON'T need to keep the PC running, and the control via the printer's LCD should be the same as when using a SD card. What made you assume otherwise?

[positron96]

Ah, I probably wasn't clear enough. What I mean is that I frequently start a print without the PC. I do it with printer's LCD, select file, and print it from printer's SD card. With WirelessPrinting the files are stored on ESP (or ESP's SD card) and I can start a job only from PC web browser or Cura (but the latter only allows to upload new file, not print existing, doesn't it?). I also do a lot of babystepping during first layer to make sure it sticks well.
An ideal for this workflow would be either:

• to upload file to printer's SD card via WiFi. I tried that with ESP--UART--Marlin, and the speed is just appalling. There is another approach with sharing an SD card between printer and ESP, but it's hackish and, frankly, I haven't been able to make it work on a breadboard.
• to attach another LCD with buttons to ESP so that it has an UI to start printing. I'd still need printer's LCD to control babystepping and other hardware parameters (yes, I know that they can be controlled remotely with gcodes, but that needs to be implemented on ESP's side, that probably means having half of Marlin's UI on ESP).

[probonopd]

Ah, I understand now. Indeed, let's not reimplement half of Marlin. At that point it'd probably be easier to add WLAN uploading to Marlin.