Hi Everybody,
how can I mark the whole content of the serial monitor?
Is there a hotkey for this ?
ctrl-A marks the sourcecode
shift-cursor-down does not mark all
so what else can I use ?
or
does it simply not work?
Is there a work-around through using a separate serial terminal-software?
or am I forced to use a special non-influencing second TTL-2-USB-COM-Port-adpater in parallel to the Tx-Pin?
best regards Stefan
I have a new name and a new logo for the new IDE
"beta" is the second letter in the greek alphabet
There are open bugs/issues on this including the one I opened about a year and a half ago:
Missing "Select All" capability for Serial Monitor · Issue #812 · arduino/arduino-ide (github.com)
The Arduino IDE developers are tracking this bug here:
So as the arduino-Team started to integrate a source-code debugger
which is a very complex task and is a never ending project on its own
Will this serial-monitor-bug ever be solved?
I don't know what you definition of "started" is, but the IDE has had a debugger for the last 3.5 years:
It is not so simple as you might think. One of the goals set for the Arduino developers when creating Arduino IDE was to provide the capabilities missing from Arduino IDE 1.x that forced Paul Stoffregen to create a modified version of the IDE (Teensyduino) rather than the far more simple and user friendly approach of adding Teensy board support to the official IDE via a boards platform installable by Boards Manager. Beyond the immediate benefit to the Teensy community, the hope was that these capabilities would also support the similar requirements that other advanced boards platforms (official and 3rd party both) might have, and in fact they are already in use by several platforms including the "Teensy" boards platform.
One of Paul Stoffregen's requirements was Serial Monitor support for the high USB data rates the modern boards are capable of. Paul Stoffregen found the performance of the Arduino IDE 1.x Serial Monitor to be insufficient and had to create a separate Serial Monitor in Teensyduino that was used when a Teensy port was selected:
https://www.pjrc.com/improving-arduino-serial-monitor-performance/
The Arduino developers found it quite challenging to achieve similar performance in the Arduino IDE 2.x Serial Monitor, but were successful in the end:
Potential performance impacts must be considered when evaluating any work done on the Serial Monitor. Unfortunately the developers have found that some of the more attractive solutions for the limitations of the current Serial Monitor significantly impact the performance. For example:
PaulStoffregen commented on Feb 6, 2022
Please be careful to consider performance impact. Arduino 1.8 uses a lightweight editor (jTextArea). Even just supporting USB1 speed required a lot of work. When data arrives at sustained USB2 speed, its memory & CPU usage quickly spirals out of control, crashing the whole IDE on Windows and freezing the GUI on Linux. A couple years ago I poured a lot of work into improving the performance. Ultimately the problem is data management algorithms designed to support the arbitrary changes a text editor needs can end up performing very badly when used as a FIFO for high speed data.
The Arduino community is very welcome to submit high quality pull requests for the changes you are anxious to see made to the Serial Monitor of the free open source Arduino IDE 2.x:
I guess, to conclude it all, the best bet is to click select at one point and drag to the top.
thats even worse.
I think this was not the problem with 1.x?
This is interesting, but I'm a little confused. What's the point of supporting high data rates to a screen when the data will arrive faster than you can see it?
At 775972 lines per second as shown in the image the only way the data is useful is if you can move it to another application for further analysis.
Performance for the sake of performance? This feels like putting a 10,000 HP motor a car and having the tires melt off before you get out of the driveway.
Even in an application where there is no need to output data at a high rate, the users are still going to end up doing it simply because it is easier to just dump the Serial.print calls into loop than setting up the code necessary to print at a more sensible interval. We know from experience that beginners have difficulty understanding how to use millis in this way.
If the Serial Monitor can't keep up then you end up with a situation where the output printed in Serial Monitor is seconds or minutes behind what is happening. During the pre-release development phase of Arduino IDE 2.x, it actually had this problem and it caused a lot of confusion even for some fairly advanced users:
In the article by Paul Stoffregen, they reported that high data rates even caused the application to crash.
Thanks. Fair point.
very frustrating.
sigh!
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.
