No I do not see any message like that. How would I tell if I have multiple PlatformIO Cores in the system? Can you tell anything from the installation output I posted? Let me know if there is anything else I can do to get the debug code running.
- Please open Windows Task Manager and kill all
- Repeat again instructions from Serial Monitor Slow Startup (New Issue) - #11 by ivankravets
Does it work now?
Hi Ivan, there weren’t any other python.exe processes running. There are several python programs in the environment path variable so I started a command shell, removed all the python programs from the path variable and started Visual Studio Code from there and tried running the pip install command again. I get the same output result which is, if I’m reading it correctly, indicating that it is not updating any of the packages in the zip file to my system. I unzipped the package and I can see in the finder.py file that you’ve added debug code but when I look at the finder.py file on my system I can see that it is not getting updated to the version from the zip file. Is there some way to force pip to install the changes? Are the changes extensive, i.e. could I go and make the same changes in my installed files myself or are there too many changes for me to make manually? Sorry I don’t understand the python environment better to help get past this install issue.
OK, I’m back from Burning Man (very dusty this year). Is there anything I can do now to help track the problem down?
I forgot to mention that, in addition to the large shark, our camp created two art pieces intended to show support for Ukraine: 1) a glass/steel sculpture of sunflowers; and 2) a piece called “The World is Watching”, consisting of 20 sets of eyes painted by different artists. We met some Ukranians who gifted a flag that we attached to the sunflowers.
@ivankravets I’m having the same issue with the slow monitor startup, how can i help?
heres my sys info:
and my device list:
(COM14 is the arduino uno that i want to monitor)
pio upgrade --devbut still slow
i installed your pio core with debug info:
how do i proceed?
thanks for the help!
(i can only embed one pic in every reply, pic2 and pic3 will follow below)
Hi Ivan, I went ahead and made the changes to finder.py myself and than ran the pio device monitor command. Here is the output from that command:
Start device finder 1663019704.4218063
Using board config 1663019706.7640707 None
Using knowing PID/VIDs 1663019706.809987 COM25 - USB Serial Device (COM25)
Find any UART device 1663019732.6389482 COM25
Looks like it finds the COM25 port it is supposed to use pretty quickly (about 2 seconds) but then takes another 25 secs before outputting the last line and actually coming up with the serial prompt. Let me know if there is anything else you need.
Ok, put in a little more debug code and it looks like the problem is that the ensure_ready flag is now being set on the SerialPortFinder class. I get this debug output:
Start device finder 1663020855.75193 True
Using board config 1663020858.1718574 None
Using knowing PID/VIDs 1663020858.2057676 COM25 - USB Serial Device (COM25)
Checking COM10 1663020858.2436926 True
Checking COM7 1663020863.4307485 True
Checking COM3 1663020863.4367244 True
Checking COM6 1663020863.4407125 True
Checking COM8 1663020863.4457023 True
Checking COM9 1663020863.4506857 True
Checking COM14 1663020863.455732 True
Checking COM12 1663020868.5873647 True
Checking COM11 1663020873.7119913 True
Checking COM25 1663020878.837271 True
Checking COM13 1663020878.8412602 True
Find any UART device 1663020883.9747658 COM25
Forcing the ensure_ready flag to False I get the following output:
PS C:\Users\randy\Documents\PlatformIO\Projects\File Player> pio device monitor
Start device finder 1663020895.1570961 False
Using board config 1663020897.5518823 None
Using knowing PID/VIDs 1663020897.578812 COM25 - USB Serial Device (COM25)
Checking COM10 1663020897.6157124 False
Checking COM7 1663020897.6167288 False
Checking COM3 1663020897.6167288 False
Checking COM6 1663020897.6167288 False
Checking COM8 1663020897.6177225 False
Checking COM9 1663020897.6177225 False
Checking COM14 1663020897.6177225 False
Checking COM12 1663020897.6177225 False
Checking COM11 1663020897.6187127 False
Checking COM25 1663020897.6187127 False
Checking COM13 1663020897.6187127 False
Find any UART device 1663020897.6197164 COM25
As you can see the serial monitor starts up much faster when the ensure_ready flag is not on and it doesn’t try to check and see if it can open all the serial port devices. I’ll see if I can find where that flag is getting set (the class defaults it to False if not created with that flag being forced to True).
Hi Ivan, I did a little more digging in the new serial port finder code. I believe the problem was introduced with commit 7c9e039 on Jul 29 (Improved device port finder when using dual channel UART converter). I believe the following couple of lines should to be added:
Before the code attempts to loop through all the serial ports trying to pick the best PID:VID USB device around line 147. I added these two lines and re-enabled the ensure_ready (that I had disabled) and it now starts up fast again. Let me know if you think this is the right change.
Hi Ivan, have you seen my updates for this issue?
Thanks for helping to debug this issue. Yes, it was a bug and we have just fixed it. Could you re-run
pio upgrade --dev? Does it work now?
Hi Ivan, yep that fixes the issue just fine!
Oh, good to see that the serial console should actually be fast. I’ve only started using PlatformIO a few weeks or so ago and this thing has always been totally slow to start. No comparison with the ESP-IDF extension that I used before. But where should I type that command? In a normal Windows command prompt? I’m just regularly upgrading VSCode and the extensions so I hope things will automatically resolve.
I’m the guy who started this thread back in August. Sorry, I’ve been distracted and haven’t been able to fully follow all the developments, but it seemed like the issue was resolved. But now that I’m back to using PIO, I have to report that the problem remains, and is actually a bit worse than before. I tried “pio upgrade --dev” to upgrade to 6.1.6a4 from 6.1.5, but that didn’t make a difference.
The behavior that I’m seeing now is more inconsistent/unpredictable than before: After uploading code, regardless of whether the serial monitor was previously running for not, the serial monitor startup time varies from a couple of seconds to about 12 seconds. But now, when the startup time is long, the serial monitor is completely unresponsive to messages from the target. If I kill and restart the serial monitor, it usually (not always) starts working, but by then I’ve missed a bunch of messages.
I now have time available to gather whatever information you need to resolve this issue. It’s really slowing down my development progress.
I’m hitting the same issue on my 2019 macbook pro —
pio device monitor routinely takes upwards of 20 seconds to show the first line. I accidentally realised that running
pio device monitor outside my project directory was much further. This seemed to indicate that the problem must be something in my platformio.ini file.
Upon further stripping out of various configs in
platformio.ini file, the culprit seems to be the
esp32_exception_decoder. Removing that from the
monitor_filters alone makes
pio device monitor show up output in a couple of seconds. The exception decoder is useful to have enabled all the time, so is there any way to make that filter any faster?
I’m using the Teensy 4 MCU, and the solution I got (from the PJRC Teensy forum) was to stop using the “graphical” uploader program, and instead use the command line version. Specifically, I added this to my platformio.ini:
upload_protocol = teensy-cli
If you’re using ESP32, I don’t know if the situation is equivalent.
Thank you @ketanpadegaonkar ! I’ve been banging my head on this problem for months, with some projects having the slow serial problem and others not.
You nailed it: the problem occurs if you have
monitor_filters = esp32_exception_decoder in the
Oh boy - Thank you! This has plagued me recently! @ketanpadegaonkar and @jackjansen