Allow specifying the initial 'rom-baudrate' in constructor

[pkendall64]

By allowing the user to specify the rom_baudrate at construction time this allows devices that are programmed via serial-passthrough to perform any pre-flashing commands they may need to do before calling the main_fn and not have the main function change the baudrate.

We use this in ExpressLRS as we need to perform passthrough initialisation of a flight-controller before calling the main_fn etc to perform the flashing. The flight controller talks to the receiver at 420k, and will do the passthrough at another specified rate, but cannot change rate, so the initial rom_baudrate and the baudrate used by change_baud must be the same in our case.

[balloob]

As a workaround, you can close the port before passing it to ESPLoader. That's how we do it in ESP Web Tools: https://github.com/esphome/esp-web-tools/blob/9fee26fbab6b2a53ff82010c4e6b36dd74fee754/src/install-dialog.ts#L828-L830

[pkendall64]

As a workaround, you can close the port before passing it to ESPLoader. That's how we do it in ESP Web Tools: https://github.com/esphome/esp-web-tools/blob/9fee26fbab6b2a53ff82010c4e6b36dd74fee754/src/install-dialog.ts#L828-L830

No, not really. Because we need the baud rate to be at 420k for RC receivers and if the connection is not already connected then ESPLoader passes a default of 115200 and our flashing will fail. By being connected first at 420k and telling ESPLoader to use 420k when it comes to do the change_baud call it all works out ok.

I can store a connected flag in webserial.js and if you call connect and it's already connected, just return rather than error out so there would be no changes to ESPLoader.

[pkendall64]

Perhaps another, nicer way, would be to allow the rom_baud (with a default 115200) to be specified in the constructor as well as the stub_baud, which is what the current baud is.

EDIT: I tested this locally and this will work for my code.