add esp32 example

[ettoreleandrotognoli]

Hello, I'm not sure if is the best way to add an example for the ESP32, but I hope it can help

[IniterWorker]

@ettoreleandrotognoli, thank you for your contribution!

I appreciate your efforts in contributing to this project. After reviewing your PR, it seems that there might be a potential issue related to the unstable build-std = "core" feature being activated. But, I am not sure, yet. This feature could introduce error into the build process, and it's important to handle it carefully.

I've taken a look at https://stackoverflow.com/questions/76580751/how-to-set-cargo-unstable-options-for-a-target, and it provides some insights into how to set unstable options for a specific target using Cargo. But, it looks like a workaround.

Creating a sub-project without a direct workspace relation could indeed be a viable solution if we encounter difficulties with the unstable build-std = "core" feature. This approach could help isolate and manage any issues that might arise without affecting the entire workspace.

I will investigate the potential effects of build-std = "core" on the Blackpill project at a later time.

[kkettinger]

Thanks for the example @ettoreleandrotognoli (and for the driver @IniterWorker). I've tried out the example on a ESP32-S3, but it hangs indefinitely when converting it into the buffered graphics type:

let mut display = driver.into_buffered_graphics();

I don't think this is related especially to your example, but as you are using a ESP32 too, maybe you came accross this issue.

When enabling the watchdog, the devices resets. Without watchdog, it just hangs there. Sadly i don't have a debugger to go into this deeper.

[rsov]

Could it board specific issue? I tried this on Arduino ESP32-S3 and the example worked

[ettoreleandrotognoli]

Hello @kkettinger I had a similar issue, take a while to me figure out If I'm not wrong my issue was because this method was trying to get more memory than was availbale, I had to change some settings to increase the stack memory size

I added a file sdkconfig.defaults with this:

CONFIG_ESP_MAIN_TASK_STACK_SIZE=8000

https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/kconfig.html#config-esp-main-task-stack-size

[kkettinger]

I'm using a Waveshare ESP32-S3-Touch-LCD-1.28 module, which worked with the firmware that was already on it, so it shouldn't be defective.

@ettoreleandrotognoli: Maybe i'm wrong, but your esp32 example doesn't use IDF? Are the sdkconfig options even relevant there?

I've now switched over to your esp32 example instead of including the driver into mine: The example crashes directly after flashing:

[2024-04-01T11:16:07Z INFO ] 🚀 A new version of espflash is available: v3.0.0
[2024-04-01T11:16:07Z INFO ] Serial port: 'COM8'
[2024-04-01T11:16:07Z INFO ] Connecting...
[2024-04-01T11:16:07Z INFO ] Using flash stub
Chip type:         esp32s3 (revision v0.2)
Crystal frequency: 40MHz
Flash size:        16MB
Features:          WiFi, BLE
MAC address:       84:fc:e6:50:a3:a4
App/part. size:    46,272/16,384,000 bytes, 0.28%
[00:00:01] [========================================]      14/14      0x0                                               [00:00:00] [========================================]       1/1       0x8000                                            [00:00:02] [========================================]      28/28      0x10000                                           [2024-04-01T11:16:12Z INFO ] Flashing has completed!
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x38 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fce3818,len:0x16f8
0x3fce3818 - _ZN5esp3212__INTERRUPTS17h3774396fc90fb4f1E
    at ??:??
load:0x403c9700,len:0x4
0x403c9700 - _ZN17compiler_builtins3mem6memcpy17h0df16b12da7e8da3E
    at ??:??
load:0x403c9704,len:0xc00
0x403c9704 - _ZN17compiler_builtins3mem6memcpy17h0df16b12da7e8da3E
    at ??:??
load:0x403cc700,len:0x2eb0
0x403cc700 - _ZN17compiler_builtins3mem6memcpy17h0df16b12da7e8da3E
    at ??:??
SHA-256 comparison failed:
Calculated: 9e7b8c8d53c0514c12b6eb2f4d48f985182d9c70a488ad4caf71e08902c97372
Expected: 3499e4149a363c2b1ee4ee9709ca5031f50ee6b595a532f697c8659516763ae3
Attempting to boot anyway...
entry 0x403c9908
0x403c9908 - _ZN17compiler_builtins3mem6memcpy17h0df16b12da7e8da3E
    at ??:??
I (48) boot: ESP-IDF v5.1-beta1-378-gea5e0ff298-dirt 2nd stage bootloader
I (48) boot: compile time Jun  7 2023 08:07:32
I (49) boot: Multicore bootloader
I (54) boot: chip revision: v0.2
I (57) boot.esp32s3: Boot SPI Speed : 40MHz
I (62) boot.esp32s3: SPI Mode       : DIO
I (67) boot.esp32s3: SPI Flash Size : 16MB
I (72) boot: Enabling RNG early entropy source...
I (77) boot: Partition Table:
I (81) boot: ## Label            Usage          Type ST Offset   Length
I (88) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (95) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (103) boot:  2 factory          factory app      00 00 00010000 00fa0000
I (111) boot: End of partition table
I (115) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=02938h ( 10552) load
E (123) esp_image: Segment 0 0x3f400020-0x3f402958 invalid: bad load address range
0x3f400020 - ??
    at ??:??
0x3f402958 - _ZN5esp3212__INTERRUPTS17h3774396fc90fb4f1E
    at ??:??
E (131) boot: Factory app partition is not bootable
E (137) boot: No bootable app partitions in the partition table
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0x38 (SPI_FAST_FLASH_BOOT)
Saved PC:0x403cdd51
0x403cdd51 - _ZN17compiler_builtins3mem6memcpy17h0df16b12da7e8da3E
    at ??:??
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fce3818,len:0x16f8
0x3fce3818 - _ZN5esp3212__INTERRUPTS17h3774396fc90fb4f1E
    at ??:??
load:0x403c9700,len:0x4
0x403c9700 - _ZN17compiler_builtins3mem6memcpy17h0df16b12da7e8da3E
    at ??:??
load:0x403c9704,len:0xc00
0x403c9704 - _ZN17compiler_builtins3mem6memcpy17h0df16b12da7e8da3E
    at ??:??
load:0x403cc700,len:0x2eb0
0x403cc700 - _ZN17compiler_builtins3mem6memcpy17h0df16b12da7e8da3E
    at ??:??
SHA-256 comparison failed:
Calculated: 9e7b8c8d53c0514c12b6eb2f4d48f985182d9c70a488ad4caf71e08902c97372
...

I've then updated the dependencies of esp32-test to the latest version (with minor changes to the code related to Spi) and used specific esp32s3 feature-flags (instead of the generic esp32 flags) with the result, that it now works 😄

Here are the changes in the Cargo.toml for the esp32-test example:

 [dependencies]
-esp-backtrace = { version = "0.9.0", features = [
-    "esp32",
+esp-backtrace = { version = "0.11.1", features = [
+    "esp32s3",
     "panic-handler",
     "exception-handler",
-    "print-uart",
+    "println",
 ] }
-esp-println = { version = "0.7.0", features = ["esp32"] }
+esp-println = { version = "0.9.1", features = ["esp32s3"] }
 embedded-graphics = "0.8.1"
 embedded-hal = "0.2.7"
-hal = { package = "esp32-hal", version = "0.16.0" }
-gc9a01-rs = { path = "../gc9a01-rs" }
\ No newline at end of file
+hal = { package = "esp32s3-hal", version = "0.15.1" }
+gc9a01-rs = { path = "../gc9a01-rs" }

And the changes due to the newer dependencies in the file esp32_test.rs:

-    let spi = Spi::new_no_cs_no_miso(
-        peripherals.SPI3,
-        sck,
-        mosi,
-        40u32.MHz(),
-        spi::SpiMode::Mode0,
-        &mut clocks,
-    );
-
+    let spi = Spi::new(peripherals.SPI3, 40u32.MHz(), spi::SpiMode::Mode0, &clocks)
+        .with_sck(sck)
+        .with_mosi(mosi);

Thanks for the help!

[kkettinger]

I now found out why my own project didn't work with the driver: When flashing the esp32-test example (release or debug), it is using these profiles in the cargo.toml:

# cargo build/run
[profile.dev]
codegen-units = 1
debug = 2
debug-assertions = true
incremental = false
opt-level = 3
overflow-checks = true

# cargo build/run --release
[profile.release]
codegen-units = 1
debug = 2
debug-assertions = false
incremental = false
lto = 'fat'
opt-level = 3
overflow-checks = false

When i flash my own example with cargo build --release, my example works, but not with cargo build (debug build, without using the above profiles). I also noticed that my build in debug mode is way bigger then from the esp32-test example, which is a hint at the optimization levels.

By using an opt-level above 0 seems to resolve the issue:

[profile.dev]
opt-level = 1

Not using an opt-level or setting opt-level = 0 results in a non-working example (at least for the esp32s3 chip).

[IniterWorker]

I'm using a Waveshare ESP32-S3-Touch-LCD-1.28 module, which worked with the firmware that was already on it, so it shouldn't be defective.

It seems like we should provide an esp32 example.

@kkettinger is this pull request working for you ? On my side I need to take some time for https://github.com/IniterWorker/gc9a01/pull/3#issuecomment-1790659926.

By using an opt-level above 0 seems to resolve the issue:

Seems related to https://github.com/IniterWorker/gc9a01/pull/3#issuecomment-2028966228

[kkettinger]

@kkettinger is this pull request working for you ? On my side I need to take some time for #3 (comment).

No, not without the changes mentioned in my comment.

[IniterWorker]

Hi @kkettinger,

I've made some adjustments based on @ettoreleandrotognoli's work. Could you please create a new pull request with your changes? Also, if necessary, remember to use the = symbol for version locking.

Looking forward to your contribution!

B.r

[kkettinger]

I've made the PR.

And if anybody is interested, i've made an example project for my esp32s3 based development board: https://github.com/kkettinger/rust-waveshare-esp32s3-lcd-gc9a01-example

[IniterWorker]

Hey @ettoreleandrotognoli and @kkettinger, huge shoutout to both of you for your contributions! Your enthusiasm and encouragement have reignited my passion for this project. With your support, I've been able to dive back in and make some exciting updates.

You're going to love what's coming in version 0.2.0 :rocket: ! I've incorporated the latest embedded-hal v1.0.0, and there's a special treat for you, @kkettinger – I've put together a tailored example for your esp32s3-lcd-1.28 from Waveshare.

And hey, if anyone else wants to join in the fun, we're using esp-idf-svc in the esp32-s3-touch-lcd-1.28. Let's make this collaboration even more awesome!

Cheers,

[kkettinger]

Great to hear! Going to embedded-hal v1.0.0 was a good move. And very thanks for the example, just tried it out on my waveshare board and it worked on the first try!