Making the serial console a dockable screen again?

Development Tools IDE 2.x
1

Any chance of this happening as I often have a serial console running during debug cycles while editing sketches and prefer the console to be on a second monitor while doing so. I also may have more then one sketch open and its console and having both side by side on the second screen is very convenient.
Cannot understand why this feature was removed?

Regards Colin

PS: I do use Termite for static access to my current projects but cannot use at the same time as the IDE - get comms conflicts...

This has been outstanding for some time - any updates yet???

Regards Colin

1 Like
2

It has been mentioned a number of times here on the forum. And I think that there is a request on github; can't search now.

3

Hi @lensman11. The Arduino IDE developers are tracking this request here:

If you have a GitHub account, you can subscribe to that issue to get notifications of any new developments related to this subject.

The plan is to make the Serial Monitor a dedicated window, as it is in Arduino IDE 1.x and as the Arduino IDE 2.x Serial Plotter is already.

1 Like
4

Just curious if there has been any progress on this? Any idea when this might be done?

Note: For working on teensy boards, I typically use TyCommander for the Serial input/output, which works great, but would be nice to be able to use the built in Serial.

5

Sadly the ide2 serial monitor is too limited and too buggy for me. Having tried Putty and its friends I now use termite

1 Like
6

It depends on your perspective. The lead developer of the project, Akos Kitta had proposed that the Serial Monitor rewrite be based on Monaco, which is already used for the Arduino IDE 2.x editor component. This would provide the same excellent select/copy/find functionality we have in the editor for the Serial Monitor as well.

We know that some members of the community are very concerned with the throughput of Serial Monitor, so this has been a consideration in all the work done on Serial Monitor after the original quick "proof of concept" implementation:

https://github.com/arduino/arduino-ide/issues/105#issuecomment-1030897403

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.

Akos did an investigation into the feasibility of the Monaco proposal and unfortunately encountered some problems with Monaco as applied to this specific use case.

So not really visible progress, but investigating the possible approaches is part of the process of software development even if it doesn't produce any lines of code that make it into the codebase.

That is something only the project managers could answer. They must make the decision about when the limited resources will be allocated to the task.

1 Like
7

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.