update all dependencies to their latest versions, add appDescriptor

[0x53A]

I'm interested in using Doggy as a USB CAN adapter. Trying to flash it, I got the error from espflash about the missing app descriptor. Using this opportunity, I've updated all dependencies and added the descriptor.

There are a few details I'm unsure about. espflash threw an error about defmt, and that it only supports rzcobs, not raw. So I changed that in the cargo.toml, and also included writing the prefix, like esplog does. It no longer complains, but I also do not see any actual output when using --monitor.

I haven't used doggy before, and so, to test my changes, I flashed an esp32-c3-mini, attached it to a can network, and used a small python program to read data:

import can

def main():
    bus = can.Bus(interface='slcan', channel='COM15', bitrate=500000)
    print("Starting listening ...")
    for msg in bus:
        print(msg.data)

if __name__ == "__main__":
    main()

I can see data in the terminal, so it seems to work.

A few notes about my changes:

• feature "task-arena-size" has been removed from embassy-executor: https://github.com/embassy-rs/embassy/blob/b68253e1aa38a9251b10219df4da3519cecf33e7/embassy-executor/CHANGELOG.md?plain=1#L33

• "exception-handler" was moved from "esp-backtrace" to "esp-hal", it's enabled by default.

• "esp-hal-embassy" has been superseded by esp-rtos (https://crates.io/crates/esp-hal-embassy)

• "esp-wifi" has been superseded by "esp-radio" (https://crates.io/crates/esp-wifi)

• trying to run it without the ble feature, I got an error about missing the global allocator, so I rearranged that to always initialize the allocator, not just in the case of Bluetooth. I haven't checked which component uses the allocator.

• I have only tested doggie_esp32 on the esp32-c3, nothing else.

[GastonAznarez]

Hi @0x53A. First, thanks for the contribution, we really appreciate community contributions.

I will test the changes on each board variant, but it will take some time.

Regarding debugging, you're seeing nothing because when you run esp-flash with the --monitor flag, it attempts to use the USB as the debugging interface. However, that interface is already in use as the CAN bus serial interface. We have configured two other GPIOs as UART TX and RX for debugging.

For the ESP32-C3, we use UART0 for debugging with GPIO3 → TX and GPIO2 → RX.

To read the debug information, you'll need to connect a UART-to-USB adapter configured at 115200 baud and use the script at doggie/doggie_esp32/ monitor.sh.

More details about it on https://infobyte.github.io/doggie/hardware/diy/esp32/intro/

[0x53A]

I've continued work - first I just updated the esp projects ignoring everything else.

There is one conflict, where trouble-host depends on bt-hci@0.6.0 but cyw43 depends on bt-hci@0.4.0

Since both are embassy projects, I've asked them to release a new version of cyw43 on crates.io: embassy-rs/embassy#4864

This PR is on hold until then.

---

/doggie_bluepill
cargo build --bin doggie --release --no-default-features --features uart,int ✅
cargo build --bin doggie --release --no-default-features --features usb,mcp ✅

/doggie_pico
cargo build --release --bin doggie ❌
cargo build --release --bin evil_doggie --no-default-features --features=uart ✅

/doggie_esp32
cargo build --release --features=esp32 --target=xtensa-esp32-none-elf --bin doggie ✅
cargo build --release --no-default-features --features=esp32,faraday,twai --target=xtensa-esp32-none-elf --bin doggie ✅
cargo build --release --features=esp32 --target=xtensa-esp32-none-elf --bin evil_doggie ✅
cargo build --release --no-default-features --features=esp32 --target=xtensa-esp32-none-elf --bin evil_doggie ✅
cargo build --release --features=esp32c3 --target=riscv32imc-unknown-none-elf --bin doggie ✅
cargo build --release --features=esp32c3 --target=riscv32imc-unknown-none-elf --bin evil_doggie ✅

[0x53A]

Now that new versions of the embassy crates have been released to crates.io, this should be good to go.