feat: Add new benchmark command to measure connection time and flash throughput.

[AnthonyGrondin]

Description

This adds a new command to benchmark the reading / writing / checksum md5 speed with a device. It's similar to what probe-rs does, by writing N bytes over a given sector range. The command asks for a base address, and by default uses a 1 MiB range. The sizes parameter takes a list to allow benchmarking over different sizes (In my experience it pretty much gives the same result, but it's there 🤷‍♂️).

I also reworked the handling of Ctrl-C to allow cancelling a pending operation.

Testing:

cargo run --release -- benchmark --address 0x10000

Commits

• feat: Add benchmark command to measure throughput with device.
• fix: Improve Ctrl-C handling for both binary and library usage.
  • This changes behavior whereas previously Ctrl-C wouldn't be exiting the
    program while a command is running. Now treat Ctrl-C as Error::Cancelled
    while dialoguer is driving serial-port selection so embedders can unwind
    cleanly instead of exiting from inside espflash::cli. Keep the handler
    scoped to active prompts, and fall back to the normal SIGINT exit path
    when no prompt is active.

[AnthonyGrondin]

I'm gonna mark this for review but it would be nice if a few people could run it to test if it works without issues.

I've tested it on esp32s3 and esp33c6.

[MabezDev]

Whilst this is cool, and probably useful - I wonder if this is better as a seperate tool? 🤔

The only interesting parts to benchmark are the library parts, which we could make into a separate CLI tool to exercise them. I could also live in this repo.

What do you think?

cc: @SergioGasquez I'm curious about your thoughts here too.

[SergioGasquez]

Whilst this is cool, and probably useful - I wonder if this is better as a seperate tool? 🤔

As it lives under the cli mod, which doesnt follow semver, it could also live inside espflash but, maybe a separate tool is better, as this is mostly an internal tool that most of the users won't need/use.

The only interesting parts to benchmark are the library parts, which we could make into a separate CLI tool to exercise them. I could also live in this repo.

If we do another tool, I would like it to live under this repo, having some HIL test so we see if a change reduces perfomance could be a great addition.

[MabezDev]

So maybe a new bin inside the espflash repo then.

having some HIL test so we see if a change reduces perfomance could be a great addition

Great idea! We should file an issue for this so we can implement it later.

[AnthonyGrondin]

I initially started my implementation by adding a new xtask command, for benchmark, calling APIs from the espflash crate, but I found it would be a better integration directly into espflash, so that end users could run their own benchmark without having to pull and build the whole espflash repo themselves.

Like Sergio said, living directly inside of espflash makes it easier to not have to mess with semver. I've been looking forward to have an HIL integration so that regressions (and improvements 👀) can be detected more easily.

Implementation wise, there's tinkering about where this should live, because too low-level inside of espflash, we lose the parity with real-time operation APIs, too high-level, using espflash's public APIs directly, as an imported crate, we lose some granular control and get further from raw throughput.

[SergioGasquez]

I would also go for another bin that lives in this same repo.

so that end users could run their own benchmark without having to pull and build the whole espflash repo themselves.

I dont think most of the users would run benchmarks, and those who do, I guess they wont mind installing another bin.