Some questions about Thonny

[srogers]

I have Version 3.3.13 of Thonny and
MicroPython v1.18 on 2022-01-17; Raspberry Pi Pico with RP2040

Type "help()" for more information.
I have done quite a bit of development with it in the past week or so.

First Question:
I was investigating the machine.RTC class. In the REPL window, I did the following:

>>> from machine import RTC
>>> rtc = RTC()
>>> print (rtc.datetime())
(2022, 2, 9, 2, 1, 11, 37, 0)

I had never done rtc.init().
Does this mean that Thonny (at least in the REPL window) initializes the RTC for you?
The date shown is correct for me.

Second Question:
I am finding that when I first start Thonny with the Pico Pi plugged in, I have a hard time establishing a serial connection to the board. After a number of 'Stop/Restart the backend' commands (sometimes as many as 20 or more), I finally get a

MicroPython v1.18 on 2022-01-17; Raspberry Pi Pico with RP2040
prompt, which allows development and usually sticks around pretty good.
But when I lose communications, it is again a fight with the Stop/Restart the backend' command to finally get the communications going again.

[scruss]

Does this mean that Thonny (at least in the REPL window) initializes the RTC for you?

Yes, it does.

I am finding that when I first start Thonny with the Pico Pi plugged in, I have a hard time establishing a serial connection to the board.

Do you have a 'main.py' running at boot? If so, it's likely due to this (unfixed) issue: Ctrl+A followed by Ctrl+C gets serial input stuck since 1.17 · Issue #7867 · micropython/micropython

[srogers]

Well, I seem to have resolved the problem, but not in a way that makes any sense to me.

I simply moved my USB cable to another USB port on my laptop. When I did this, everything went back to normal. And...none of the parameters for my COM port in Device Manager changed. I'm still at COM 4.

I also tried running Thonny as an admin (but all my users (me and admin) are admin anyway).

So its a mystery that I can live with until it (hopefully never) rears its ugly head again.

[srogers]

OK, I have come to a final resolution of this COM communications problem. It happened when I got a new Pico Pi and I tried to get it to respond. After loading the UF2 file for MicroPython 1.18, I had the same problem (on the port I thought no longer had the failed to connect problem) and I found that I was able to connect only after say every 25-50 tries. This was the same problem on the other laptop port. And I was sick and tired of fighting it. So back to Google--Google is your friend.

I found a post that indicated that if you have Malaware Bytes and you have Ransomware Protection turned on, if you turn off Ransomware Protection, the COM port connection problems completely disappear everywhere. So I have turned off Ransomware Protection and have posted a trouble ticket with Malaware Bytes. We will see what happens.

Hudathunkit!

[hippy]

if you have Malaware Bytes and you have Ransomware Protection turned on, if you turn off Ransomware Protection, the COM port connection problems completely disappear everywhere.

Modem drivers and Whiteboard software are often responsible for serial port access problems, but I would never have anticipated MalwareBytes or other AV causing similar problems. So thanks for the info which is very useful to know.

[KJM]

USB on Windows is a bit of minefield. Regardless of which IDE I'm using for the ESP32 I've learned to never have Cura open. Why a slicer with no serial port I/O would cause havoc with USB connectivity leaves me shaking my head in disbelief.

[srogers]

On the same day that I discovered that turning off RansomWare Protection on MalAware Bytes fixed my serial port problem, I got a notice to upgrade to MalAware Bytes V 4.5.4. After installing the new version, I turned on RansomWare Protection, and now there is no interference vebtwen this setting and any serial port on my laptop.

So I assume the MalAware folks were aware of the problem and fixed it.

[scruss]

Regardless of which IDE I'm using for the ESP32 I've learned to never have Cura open. Why a slicer with no serial port I/O would cause havoc with USB connectivity leaves me shaking my head in disbelief.

The D32 uses a CH340 USB-serial interface chip. This is the same interface chip used in many 3D printers. Cura assumes any serial ports it finds are 3D printers, so will attempt to talk to them in G-code. This will make your D32 quite annoyed.

CH340s are good and reliable and really cheap, but they've got no way to signal to a host system that they're anything other than a generic USB serial device. Other vendors provide limited means for saying "Hey, I'm a serial port, but I'm really a ____ device", but not WCH. So Cura can't tell that your D32 isn't something that it should talk to.

[KJM]

Ah, a logical explanation, tnx! I'll keep an eye out for ESP32s with the CP2102 in future.