Connecting to doit.am boards fails
Connecting to doit.am boards fails
I am pretty new to the MicroPython world and started experimenting with two doit.am boards [1,2].
I successfully erased the flash, flashed the MicroPython firmware and programmed the chip with mpfshell and rshell.
Unfortunately establishing a connection with mpfshell and rshell is a very unreliable business.
To illustrate this i wrote a little test case. The test case counts the number of failed connections.
###############################
#!/bin/sh
NOT_CONNECTED=0
N=100
for i in `seq 1 $N`;
do
timeout 2 mpfshell --loglevel DEBUG -n -c "open ttyUSB0" > /dev/null
RET=$?
if [ $RET -eq 124 ]; then
NOT_CONNECTED=$((NOT_CONNECTED+1))
fi
sleep 1
done
echo Failed connections: $NOT_CONNECTED/$N
###############################
Executing the above script yields:
###############################
johannes:~/esp/Micropython % ./testcase.sh
Failed connections: 54/100
johannes:~/esp/Micropython % ./testcase.sh
Failed connections: 49/100
johannes:~/esp/Micropython % ./testcase.sh
Failed connections: 53/100
#################################
You see that approximately 50% of the connections failed. This applies to both boards i bought.
It would be great to hear if someone with a similar board experiences the same behavior.
I cannot imagine that it is normal that connecting to the esp32 is such a unreliable process.
Best regards and i hope for some feedback
[1]: http://www.smartarduino.com/view.php?id=95103
[2]: https://github.com/SmartArduino/SZDOITWiKi/wiki
I successfully erased the flash, flashed the MicroPython firmware and programmed the chip with mpfshell and rshell.
Unfortunately establishing a connection with mpfshell and rshell is a very unreliable business.
To illustrate this i wrote a little test case. The test case counts the number of failed connections.
###############################
#!/bin/sh
NOT_CONNECTED=0
N=100
for i in `seq 1 $N`;
do
timeout 2 mpfshell --loglevel DEBUG -n -c "open ttyUSB0" > /dev/null
RET=$?
if [ $RET -eq 124 ]; then
NOT_CONNECTED=$((NOT_CONNECTED+1))
fi
sleep 1
done
echo Failed connections: $NOT_CONNECTED/$N
###############################
Executing the above script yields:
###############################
johannes:~/esp/Micropython % ./testcase.sh
Failed connections: 54/100
johannes:~/esp/Micropython % ./testcase.sh
Failed connections: 49/100
johannes:~/esp/Micropython % ./testcase.sh
Failed connections: 53/100
#################################
You see that approximately 50% of the connections failed. This applies to both boards i bought.
It would be great to hear if someone with a similar board experiences the same behavior.
I cannot imagine that it is normal that connecting to the esp32 is such a unreliable process.
Best regards and i hope for some feedback
[1]: http://www.smartarduino.com/view.php?id=95103
[2]: https://github.com/SmartArduino/SZDOITWiKi/wiki
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Connecting to doit.am boards fails
It's hard to provide support when you don't have the hardware I note you've tried rshell; in my opinion rshell under Linux is the gold standard for connecting to MicroPython hardware. I use it exclusively for connecting to a range of MicroPython targets including the reference ESP32 boards. It should work.
I can only suggest checking hardware, notably power supply voltage and the integrity of connections.
I can only suggest checking hardware, notably power supply voltage and the integrity of connections.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: Connecting to doit.am boards fails
Thanks for your reply Peter.
I also tried it with rshell and the connection fail rate is about the same: approximately 50 failed connections out of 100. This connection issue makes the programming workflow really annoying and i wonder if i'm the only one experiencing it.
I tried to check the power supply voltage and the integrity of connections. Unfortunately i don't have sophisticated lab equipment at hand. However checking the board with a good multimeter yields a supply voltage of 3.298 V (VDD of the uC against GND) and until now i found no broken connections.
You wrote that you use reference ESP32 boards and I guess you don't have a problem with failed connections. Maybe you can estimate the number of failed connection you have encountered with these boards in the past so i have something to compare with. And it would be great if you can post a link to the boards you are working with. After many tries i don't think that i make something wrong. I really think the boards are the issue. Maybe it has something to do with the USB-to-UART converted chip (SILABS CP2102)!?
I also tried it with rshell and the connection fail rate is about the same: approximately 50 failed connections out of 100. This connection issue makes the programming workflow really annoying and i wonder if i'm the only one experiencing it.
I tried to check the power supply voltage and the integrity of connections. Unfortunately i don't have sophisticated lab equipment at hand. However checking the board with a good multimeter yields a supply voltage of 3.298 V (VDD of the uC against GND) and until now i found no broken connections.
You wrote that you use reference ESP32 boards and I guess you don't have a problem with failed connections. Maybe you can estimate the number of failed connection you have encountered with these boards in the past so i have something to compare with. And it would be great if you can post a link to the boards you are working with. After many tries i don't think that i make something wrong. I really think the boards are the issue. Maybe it has something to do with the USB-to-UART converted chip (SILABS CP2102)!?
Re: Connecting to doit.am boards fails
Not sure which doit board you have, but if it's the one that has the arduino uno form factor, it's notorious for not wanting to "do it". In contrast, the Wemos boards seem to work pretty well.
Re: Connecting to doit.am boards fails
I have this board: http://www.smartarduino.com/view.php?id=95103
Its form factor is more like the one of the arduino nano.
Maybe you have any references at hand that go into more details about the issue with the doit boards.
I already looked into the boards that are build by Wemos. However in my country there are mostly the old retired lolin32 boards [1] available. I guess the new D32 boards [2] are more reliable!? Maybe you can share your thoughts about that matter regardig the two board versions?
I really like to play with technologies but i don't want to mess with devices that are reliable as flipping a coin.
[1]: https://wiki.wemos.cc/products:lolin32
[2]: https://wiki.wemos.cc/products:d32
Re: Connecting to doit.am boards fails
Regarding the boards you've mentioned, I don't have any insights to offer. Sorry. My remarks related to a different board, which you apparently aren't using.
Good luck!
Good luck!
Re: Connecting to doit.am boards fails
I made further tests and I have discovered a special case:
If there is an infinite loop (while True: ...) inside main.py and the script runs on the uC, rshell is not able to connect to the uC anylonger. Out of 100 tries there was not one successful attempt.
Since i'm very new to the esp32 and i have limited knowledge about the internas of Micropython i would like to know whether this is the normal behavior even if one uses a working development board or it is normal to get access to the uC with rshell although the uC is stuck inside a infinite loop!? Or other way around: does an attempt to connect to the uC raises an interrupt that stops the execution of my main.py and continues to execute the repl and wait for user input!?
If there is an infinite loop (while True: ...) inside main.py and the script runs on the uC, rshell is not able to connect to the uC anylonger. Out of 100 tries there was not one successful attempt.
Since i'm very new to the esp32 and i have limited knowledge about the internas of Micropython i would like to know whether this is the normal behavior even if one uses a working development board or it is normal to get access to the uC with rshell although the uC is stuck inside a infinite loop!? Or other way around: does an attempt to connect to the uC raises an interrupt that stops the execution of my main.py and continues to execute the repl and wait for user input!?
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Connecting to doit.am boards fails
I use the Espressif reference hardware. I don't recall ever having a failed connection.johannes wrote: ↑Mon Oct 22, 2018 12:11 pm...
You wrote that you use reference ESP32 boards and I guess you don't have a problem with failed connections. Maybe you can estimate the number of failed connection you have encountered with these boards in the past so i have something to compare with. And it would be great if you can post a link to the boards you are working with. After many tries i don't think that i make something wrong. I really think the boards are the issue. Maybe it has something to do with the USB-to-UART converted chip (SILABS CP2102)!?
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: Connecting to doit.am boards fails
Today i received a new development board: Goouuu-ESP32.
Now almost everything works as expected. After flashing the newest Micropython firmware to the device my testcase yields:
However after Uploading boot.py and main.py with an infinite loop things become unpleasant again. The main.py just looks like
Regarding my development cycle: stucks at
However performing step 2 with mpfshell works like a charm although main.py runs. I just have to invoke
and I can continue with step 3 and continue the cycle.
Is my way of how to copy scripts to the board with rshell right?
(Maybe i should start a new thread discussing this issue!?)
Now almost everything works as expected. After flashing the newest Micropython firmware to the device my testcase yields:
Code: Select all
johannes:~/esp/Micropython % ./testcase.sh
Failed connections: 0/100
Code: Select all
while True:
print("test")
time.sleep_ms(1000)
Regarding my development cycle:
- edit scripts (boot.py and main.py)
- copy scripts to uC
- evaluate script and jump back to 1
Code: Select all
rshell -b 115200 -p /dev/ttyUSB0 rsync . /pyboard/
Code: Select all
johannes:~/esp/Micropython/MyExamples % rshell -b 115200 -p /dev/ttyUSB0 rsync . /pyboard/
Connecting to /dev/ttyUSB0 ...
However performing step 2 with mpfshell works like a charm although main.py runs. I just have to invoke
Code: Select all
johannes:~/esp/Micropython/MyExamples % mpfshell -n -c "open ttyUSB0; put main.py; put boot.py"
Is my way of how to copy scripts to the board with rshell right?
(Maybe i should start a new thread discussing this issue!?)