Bridge configuration without GPIO0 connection #331
Conversation
Allow AT mode configuration at power on for bridges without gpio0 connected Demonstrate power on wireless bridge configuration on R9M tx
|
niccceee 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. |
|
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. |
|
|
||
| #if defined DEVICE_HAS_ESP_WIFI_BRIDGE_ON_SERIAL && defined USE_COM_ON_SERIAL | ||
| #error ESP: ESP wireless bridge is on serial but board has serial/com ! | ||
| // #error ESP: ESP wireless bridge is on serial but board has serial/com ! |
There was a problem hiding this comment.
why that ???
I had added this for a reason, pl revert
There was a problem hiding this comment.
Would you care to share that reason? :-)
There is no reason I can think of that a Tx module like the R9M which has only one serial port and defines DEVICE_HAS_SERIAL_OR_COM shouldn't also be able to configure the WiFi Bridge.
There was previously no cases like this, but this is exactly the case for the R9M which I would like to be able to use.
mLRS/CommonTx/esp.h
Outdated
|
|
||
| //ESP_DBG(if (esp_read("AT+NAME=?", s, &len)) { dbg.puts("!ALL GOOD!\r\n"); } else { dbg.puts("!F IT!\r\n"); }) | ||
| if (esp_read("AT+NAME=?", s, &len)) { dbg.puts("!ALL GOOD!\r\n"); } else { dbg.puts("!F IT!\r\n"); } | ||
| ESP_DBG(if (esp_read("AT+NAME=?", s, &len)) { dbg.puts("!ALL GOOD!\r\n"); } else { dbg.puts("!F IT!\r\n"); }) |
There was a problem hiding this comment.
I'd like to have that as it was
it's otherwise difficult to diagnose issues
|
|
||
| // needs a delay of e.g 1 ms from the reset, but this should be ensured by calling esp_enable() early | ||
| esp_gpio0_low(); // force AT mode | ||
| delay_ms(500); // not so nice, but it starts up really slowly ... |
There was a problem hiding this comment.
pl revert this
I understand what you are intending here, but IMHO it's not a good strategie. I rather prefer a "clean" communication.
I haven't retested and my memory is not 100% sharp here, but it could be that this is actually why it's not working for the esp82xx anymore
There was a problem hiding this comment.
I understand what you are intending here
I'm not convinced you actually know why I removed this. If we put it back, we will have to further increase startup_tmo_ms in AtMode::Init() for use without GPIO0 connected. Notice #332 (comment) that we have discovered that when the main processor is an esp32 instead of an STM that this time is already too small for that use case.
I rather prefer a "clean" communication
I'm not 100% sure what you mean by "clean". I'm guessing you might mean that when the baud does not change, we always communicate only at the right speed and don't actually need the cc loop. Is my guess correct? If so, should we specify this delay as a #define in the hal so it can be different for different Tx modules?
but it could be that this is actually why it's not working for the esp82xx anymore.
What use case is not working which worked before?
There was a problem hiding this comment.
@olliw42 Note that if we pass the baud rate to tTxEspWifiBridge::esp_read(), we can calculate ESP_CMDRES_TMO_MS instead of defining it for the worst case and significantly speed up the process of finding the correct baud rate. Are you interested in my implementing this?
|
This is seems to be stalled. Any more comments @jlpoltrack @olliw42? |
|
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. |
3 participants
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.