Support using the built-in UART peripherials of a Raspberry Pi

[bugadani]

This PR is heavily in the draft state, especially because it requires a nightly compiler at its current state and it's currently untested.

Raspberry Pis don't have hardware support for DTR, so their internal UART peripherials can't direcly be used in espflash. This PR adds rppal to manage two user-configurable GPIOs as RTS/DTR. This requires some platform-specific code, for which I have introduced the Interface struct (name pending), and a cargo feature called raspberry.

Some follow up work:

• I need to actually test if this works
• espflash now reports an error if
  • GPIO isn't available (used or doesn't exist)
  • or if DTR is not set for Unknown serial ports (assuming internal peripherial is covered here)
• README has not yet been updated with the RPi-specific input params.

Implementation depends on trait_upcasting because of https://github.com/esp-rs/espflash/pull/234/files#diff-9b8216d416248667f4612fb114829cb89c5754ca818d5784b3b0d879ec0d4ee6R266-R267 but the feature has been proposed to be stabilized in rust-lang/rust#101718 I'm open to suggestions if there is a way to avoid this feature requirement. See 5a25044 for my solution

[bugadani]

Together with #238 I was able to read the serial output of my board, so this PR technically works. I've decided to allow USB serial adapters while overwriting RTS/DTR, because why not 😅

[bugadani]

Example setup:

# /boot/config.txt excerpt

dtoverlay=uart0,txd_pin=14,rxd_pin=15

$ ./espflash serial-monitor --dtr 16 --rts 17 --monitor-speed 921600 /dev/ttyAMA0

[bugadani]

@jessebraham barring CI failures, I think this PR is ready for review. I've been using this to flash and monitor a device and I'm happy with its stability.

[jessebraham]

Awesome, thank you for implementing this! I don't have a Pi handy right now but I have asked @JurajSadel to test this out on some hardware. I will review the code shortly!

[JurajSadel]

Hello @bugadani!
I'm trying to test this PR, but I'm not sure about the wiring setup.
The --dtr and --rst are the ESP DTR and RST pins, please?

[bugadani]

@JurajSadel

--dtr and --rts correspond to high-active DTR and RTS pins on external USB - UART converters. They should be fed into a circuit like https://espressif-docs.readthedocs-hosted.com/projects/espressif-esp-iot-solution/en/latest/_images/Auto_program.png to produce EN and IO0 signals for an ESP32.

[bugadani]

Also note that I believe the linked circuit is named using low-active RTS/DTR signals. This means that active-high signals need to be connected "backwards", i.e. the --dtr pin to the nRTS on the circuit and vice versa. I was a bit negligent here because espflash probably shouldn't keep all the possible hardware configurations/naming conventions in mind.

[bugadani]

GitHub really should notify authors if their patches no longer merge.... I've squashed and rebased the PR.

[jessebraham]

Thank you for your patience, finally got chance to look through this code today. Overall I think it looks really good, don't have anything noteworthy to say about it. So thanks for making my job easy 😁

I have not tested this on hardware yet, but you've been around these parts long enough that I trust you when you say its working. I'm going to try and wrangle up a Pi this weekend to verify it myself, but if I'm unable to then I will merge this on Monday regardless and we can deal with any issues if they arise.

[jessebraham]

I ultimately was not able to find my Raspberry Pi this weekend (moved awhile back, it's gotta be in a box somewhere...), so let's just get this merged. I don't plan on releasing for awhile so there will be time to fix issues if they pop up.

Unfortunately just need one more rebase (sorry!) and it should be good to go.

[bugadani]

Done - again, github really should ping me when my PR needs a rebase... :(

[jessebraham]

Thanks for doing that. I agree, it's kind of annoying having to constantly keep an eye on your PRs like that 😅