olliw42
Bridge configuration without GPIO0 connection
Allow AT mode configuration at power on for bridges without gpio0 connected Demonstrate power on wireless bridge configuration on R9M tx
Tested on pocket internal elrs and RM9M + M5 stamp pico
Note; this also speeds up configuration just a bit with GPIO0 in some cases by removing the fixed delay and relying on the retry/baud loops. The maximum total delay is now about the same as before we increased ESP_CMDRES_TMO_MS from 50 to 70 in the last PR.
This is working quite reliably now both with and without GPIO0 and reset connected. Obviously, when we don't have reset, we need to power cycle the Tx/bridge manually when the bridge configuration is changed.
niccceee it seems we are going to a model which is entirely based on relying on timing, right anyway, doesn't this say we could/should remove the gpio0 thing entirely from the Arduino sketch?
I'm not so sure if adding it as default to the R9M code is the right thing to do. It seems to me we rather should not, I'm not sure how common it will be for users to use it that way
I suppose we could remove gpio0 signaling and rely just on the reset for "integrated" bridges too. Though, there may be some slight speed advantages to keeping gpio0 (don't have to wait for the esp to boot up twice).
You already were listening for AT commands without needing gpio0 at reset/power up time. I just improved the timing a bit and provided a way to end the AT parsing without gpio0.
As far as the R9M, I think many, probably most R9M users will go with one of the two recommended M5 stamp examples because it is such an easy and neat way to deal with the inverted serial nightmare and the 2.4gHz wireless doesn't interfere with 900 MHz, so there is no motivation to avoid WiFi like there is with 2.4gHz mLRS. Having the official builds for R9M support AT mode doesn't mean it won't work without the AT mode on the bridge or serial inverter side. It's just some garbage sent at power up which will be ignored by the ground station. And the extra power on delay is only about 1.5 seconds (this can probably be reduced if you think it is too long). So, I'd definitely prefer to include this in the distributed R9M binary firmware and it would be nice to distribute images for the M5 stamp modules as well.
I think that other Tx modules without integrated wireless bridges don't need bridge configuration in the distributed binary firmware. But, if I remember correctly, the betafpv-micro-1w-2400 Tx module has an integrated bridge without reset/gpio0. I would have liked to add support for that to this PR, but I don't have one to test on. If I add it "blind" could you or @jlpoltrack test it?
I did some more thinking. I do not agree with the R9M. There had been some users asking for the inverter thing which makes me believe that there are some users using it that way. They all would get now some glibberish on their serial, potentially breaking their setup. I do not think we should behave that way.
So, I kindly ask you to split the PR into the part which is only about the AT+DONE, and a part which brings it to the R9M. For the R9M I think we will have to do two firmwares, I can't see another way of how we could discriminate.
I think that we could remove the gpio stuff in the .ino. Was ugly anyway. I guess we would need to look again what was in v .04 and what came in now, but I think we should keep the gpio0 handling for the moment in the main code, for backwards compatibility, for those not updating the wireless.
The BetaFpV-1W I actually could do, I do have one.
I think it might also be good to remove the gpio0 stuff on the .ino side in a separate PR. That way it's easier to put back if we decide we need it for some reason in the future. So, I'll revert the hal change for this PR and do a separate PR for the BetaFPV for you to test. Then, when these two are merged, I'll work on the R9M and cleaning up the gpio0.
yo ... I must say that I'm not so happy with the direction this goes ... timing increases more and more or is delicate, crap on the uart may be transmitted, etc ... looks to me like things rather deteriorate, feels a bit like a wrong path
Hi, even if it's not perfect, I still like to tinker with it.
In general I am very happy with Brad's latest improvements of the wireless bridge. The version of May 10th fits exactly my needs. At the field mLRS is connected via UDP. For setting changes etc at home UDPSTA in a local network works fine. I like a configurable bridge for R9M too. Why? We are not alone and with a configurable bridge I can manage/reduce the impact on 2.4G RC systems of my flying buddies.
