But when MicroPython is claimed to be supported, it needs more than a vague link.
A fair comparison will be announcing support for Arduino but only provide a link to Arduino website.
I have a fair amount of boards with support for MicroPython or CircuitPython and I have at least a proper firmware for the board.
Drivers exists for LoRa and screen, I was successful in the past with a previous T-Watch.

Once more a company launch a product and do not provide proper documentation.
Maybe it's time to start shaming those companies as it is now a trend to push hardware to the market without anything on software side.

I'm trying to compile the micropython environment for my T-Display S3 (TFT, non-amoled) with the following commands:

git clone https://github.com/Xinyuan-LilyGO/lilygo-micropython
    (...)
cd lilygo-micropython/
cp config_T-DisplayS3 config
make

But then, I get the following error:

(...)
Now at patch patches/003-adapt-to-esp-idf-v4.0.2.patch
/home/thomas/p/lilygo-micropython/libs/LilyGo-EPD47
make[2]: Leaving directory '/home/thomas/p/lilygo-micropython/libs/LilyGo-EPD47'
make[1]: Leaving directory '/home/thomas/p/lilygo-micropython/extmod/display/epd'
make[1]: Entering directory '/home/thomas/p/lilygo-micropython/extmod/display/lcd'
Download lcd_binding_micropython-59bbbdae5ecc9ae84b986ce54c089250a13cb768.tar.gz over git
Cloning into 'lcd_binding_micropython'...
fatal: reference is not a tree: 59bbbdae5ecc9ae84b986ce54c089250a13cb768
Download lcd_binding_micropython-59bbbdae5ecc9ae84b986ce54c089250a13cb768.tar.gz over git
Cloning into 'lcd_binding_micropython'...
fatal: reference is not a tree: 59bbbdae5ecc9ae84b986ce54c089250a13cb768
Download lcd_binding_micropython-59bbbdae5ecc9ae84b986ce54c089250a13cb768.tar.gz over git
Cloning into 'lcd_binding_micropython'...
fatal: reference is not a tree: 59bbbdae5ecc9ae84b986ce54c089250a13cb768
unpack lcd_binding_micropython-59bbbdae5ecc9ae84b986ce54c089250a13cb768.tar.gz
tar: /home/thomas/p/lilygo-micropython/dl/lcd_binding_micropython-59bbbdae5ecc9ae84b986ce54c089250a13cb768.tar.gz: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
touch: cannot touch '/home/thomas/p/lilygo-micropython/build_dir/esp32s3/lcd_binding_micropython/prereq': No such file o
r directory
make[1]: *** [Makefile:17: all] Error 1
make[1]: Leaving directory '/home/thomas/p/lilygo-micropython/extmod/display/lcd'
make: *** [Makefile:54: extmod] Error 2

Any ideas?

Many thanks for your help!

I managed to install the firmware (GENERIC_S3-20230426-v1.20.0.bin) once but I can't connect most of the time. I manage to access the file system but not to connect Pymark or Thonny correctly. Do you have this kind of problem, is there a particular manipulation?

esptool.py v4.6.1
Serial port /dev/cu.usbmodem1234561
Connecting......................................

A fatal error occurred: Failed to connect to ESP32-S3: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

Command returned with error code 2

then continue the same code

All USB devices are software driven; some more than others. The esp32s3 is designed to implement a USB device. By default it implements a composite device of both a serial device and a JTAG interface.

The devkit version of the chip I purchased had a second console interface. By default it is independent and has nothing to do with uploading software to the chip or the JTAG. The virtual console can be configured to use either the real serial to usb chip or the virtual usb one. The are some situations where the virtual serial port can stop working so it can be good to use a dedicated serial to usb chip.

There are also some "efuses" that you can trip to permanently configure the chip to use alternative pins on the esp32s3 for jtag. But on the t-display-s3 those appear to be used by the display. So for the t-display-s3 you have the virtual serial port and jtag devices. Those are referred to as "builtin".

The builtin software device is a composite device that has two interfaces. More or less two devices in one. On Windows 10... can't speak for any other version... both devices are installed with the "usbser" (USB Serial) device driver. I have no idea why. You use the "Zadig" utility to more easily tell Windows to switch to using the WinUSB driver that you installed with tools. But you only do that with "interface 2". Leave "interface 0" set to the default "usbser". Once you have used Zadig and only on interface 2 be sure to disconnect and reconnect the usb cable. If you did it right the JTAG device will no longer be listed in the device manager under "ports" but rather will be listed under "universal serial bus devices". Hopefully you will now be able to connect with: openocd -f board/esp32s3-builtin.cfg

Hope this is correct and helps others.

Selecting a ESP32-WROVER and executing this code ...

log_d("Total heap: %d", ESP.getHeapSize());
log_d("Free heap: %d", ESP.getFreeHeap());
log_d("Total PSRAM: %d", ESP.getPsramSize());
log_d("Free PSRAM: %d", ESP.getFreePsram());

The console output is ...

[D][WifLib.ino:15] setup(): Total heap: 343784
[D][WifLib.ino:16] setup(): Free heap: 317564
[D][WifLib.ino:17] setup(): Total PSRAM: 4194252
[D][WifLib.ino:18] setup(): Free PSRAM: 4194252

Thanks.

The ESP is ...

fddfdb04-13b7-4f66-a272-914419bf9583-image.png

hal/rmt_ll.h:

hey, I just had the same problem. just comment this header, and everything will compile correctly.
arduino already have these headers.