hello! I am having an issue running the bodmer TFT_eSPI library with an esp32-s3-wroom module on a devkit board. I am following the bodmer tutorial for platformIO here: Installing on PlatformIO · Bodmer/TFT_eSPI Wiki · GitHub where i define my build flags in the .ini file which i have linked. my code is having trouble initializing the tft screen, it keeps crashing my esp32 and rebooting it, as visible from the serial monitor (also linked). I have no idea what is going on because it was working when i was using the arduino IDE, its only having an issue on platformIO. can any one of you guys help me understand what is going on? I’m new to platformIO
You did not specify a version. So the highest installed platform-espressif32 version will be used. Which one is this on your computer? Did you use pioarduino’s platform-espressif32 in some projects?
Fact is that bodmer/tft_eSPI does not work with Espressif Arduino 3.x (yet). If you have any pioarduino version installed, you have to go back to Arduino 2.x. platform = espressif32 @ 6.10.0 will use the latest official available 2.0.17 Espressif Arduino version.
Don’t forget to perform a deep clean before build when changing the platform version.
If somethings’s broken this must be the platform installation on the user’s computer.
Bad news/good news. The TL;DR is that you have options besides pinning your dependencies backward - there’s a new(ish) LCD driver in play that’s a good option.
It’s time to add Bodmer TFT_eSPI to the list of Arduino abandonware. He (?) had a heroic run with that software, but if you look at the GitHub page, it’s pretty clear that he’s flamed out, and there doesn’t seem to be anyone else stepping up to the plate to help. The last commit was 10 months ago. There are over 50 changes contributed and awaiting review feedback/integration that have been piling up. The list of open issues grows. It hasn’t been updated to Arduino 3, so it won’t work on most newer Espressif products.
As an open-source maintainer myself, I get it. Just having an inventory of basically every SBC/dev board, a dev environment, and a stack of every LCD panel ever built sounds backbreaking even before the growing support load takes a toll. This library is used in zillions of projects, yet the author is likely the proverbial dude in Nebraska. It’s a classic Tragedy of the Commons. I can relate.
The good news is that for modern processors (>= 32 bits, working DMA systems, etc.), which includes all the ESP family (up to and including the P4 that’s still only in limited release), SAMD, Teensy 4.1, etc., support is there in a replacement.
It’s optimized quite well for performance. It’s compatible enough with the traditional Adafruit drawing primitives, and it can slot in behind LVGL. For MOST people, it’s nearly a drop-in replacement. My favorite feature is that most CYDs and Waveshare-class products are selectable by name. (This would include things like M5Stacks and popular LilyGo or Adafruit board + LCD combos.) The two times I’ve tried to use it, it’s worked on the first try - no dinking with figuring out if the MISO line is readable or if the vendor swapped the reset and backlite lines over the previous model. It supports about 50 such boards by name. The source is actually quite readable and reasonable to work with, and it spends its tastefully constrained assembly budget on using the underused SIMD features of S3 instead of counting NOPS for an overclocked 8-bitter.
I have no axe to grind here and no relationship with either project. I don’t need a display enough to go modernize it myself, especially since the patches may languish without being committed, so you’re free to call me a hypocrite for not fixing it myself, and I fix other software that I DO need. The two times I needed a quick screen demo, bb_spi_lcd worked well for me on the first try. I did what I needed to do, and five minutes later, the displays were back in a cardboard box.
Why is pinning versions backward a bad thing? Well, first it indicates that nobody cares enough about it to update it formally. On a more local level, if you’re in the ESP/Arduino ecosystem right now, you have to choose between 2.x and 3.x - mixing them involves extreme pain. As more actively maintained libraries have adopted 3.x, it becomes a problem when everything BUT one driver is 3.x. Being up with current tools lets you use current/new chips and boards as well as other current tools, like libraries and the latest security fixes and such.
The driver integrates with his other projects like JPEG decoders, GIF & MPEG players, and his capacitive touch driver that makes enabling touch screens and plumbing that into LVGL from those named devices super easy.
Sooo, if you’re one of the ESP32 users stuck in the current Arduino jam and TFT_eSPI is what’s holding you up, you have another option now.
Oh, and best I can tell from the revision log, there wasn’t a commit that “fixed” Arduino3; the driver was just built from the ground up to use the documented interfaces and not try to end-run the API and honk on the hardware directly. I could be wrong on that, though. I’m pretty happy to NOT know that level of detail about the code.
