serial monitor upgrade

[Emmanuel Robert]

Hello

I would like to have a serial monitor able to display colors and to have at least a clearscreen function.

All these commands already exists as "ANSI escape sequences". We do not have to start with all the commands (underlining, blinking, moving cursor, etc). But at least these forementionned (text color and clear screen)

This would be really usefull when debugging.

If people are interested then new functions could be added depending of user expectations.

Who would be interested ? Am I the only one ?

Thank you for all the great job done !

Emmanuel

[Mark Sproul]

I think this would be a good idea as well. I would recommend implementing VT100 command set as they are the most widely used for terminal manipulation.

Mark

> --
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Matthijs Kooijman]

> I would like to have a serial monitor able to display colors and to have at
> least a clearscreen function.

Also see https://github.com/arduino/Arduino/issues/3654

(tl;dr: Arduino doesn't support control characters, better use an
external full terminal emulator. Pull Requests welcome)

I personally don't think this should be much of a priority, though it
would be nice to have proper terminal support. If this happens, this
should really use some pre-existing library, though, since
reimplementing this from scratch is probably too much effort (and will
likely result in an incomplete, possibly incorrect subset, which
IMHO would be worse than having none at all).

Also note that if this is done, the performance should be kept into
account. Significant effort has been made to make sure the current
serial monitor can sustain high bandwidth of serial data (e.g. attained
using some native USB boards). I remember Paul Stoffregen making points
about this on the Arduino issue tracker.

Gr.

Matthijs

[kpe...@blinksoft.com]

We need to be careful and remember there are people with vision problems even to blindness using these libraries. MSDOS went nuts once and made things where blind folks couldn't use the text prompt. So lets please stay away from pure graphical screen writes for something that is just a text interface.

Unless of course there is some kind of API to interface with it and allow those of us who can't see to get the information.

[Peter Willard]

ANSI support does not imply "pure graphical" at all.   It is an implementation of ASCII terminal control codes that add maybe 2 to 3 characters of unprintable codes that control cursor position, text style, global functions like 'clear screen' and send to printer (or not)  etc that was created when terminals stopped being "printing terminals" and became "screen" based terminals. 

[kpe...@blinksoft.com]

I never said it did.  The funny thing is many of us coders take the easiest road to support things.  There are views that support this and are not accessible.  So all I was pointing out is that it should be remembered we should code for the lowest denominator rather than shoot for a 4k solution.

 

Ken

[Paul Stoffregen]

I like this idea for color support, but I worry about the performance
impact.

Not so long ago, before 2015, placing a single SerialUSB.print() in your
loop() function on Arduino Due would cause the Arduino IDE to completely
lock up, also causing you to lose all your unsaved work.  Excessive
printing at slower speeds caused the Java JRE to overflow its maximum
memory allocation.  This turned out to be a very tough problem to solve.

https://github.com/arduino/Arduino/issues/2233

Even now, I believe the slowness of the serial monitor is holding back
fast boards like Arduino Due.  Back in late 2014 I did some
benchmarking, comparing the serial monitor against a do-nothing native C
program which simply discarded the incoming data.  Due was able to
transmit about 4 Mbyte/sec to the C code, but only 210 kbytes/sec to the
serial monitor.  USB has end-to-end flow control built in, so this is
the expected behavior if the PC side isn't able to keep up.  The speed
on both sides matters!

In other words, the fixes for issue #2233 keep the IDE from crashing or
running unusably slow, but we _still_ aren't running efficiently enough
to keep up with today's fast native USB boards, not to mention the much
faster hardware on the horizon.

If anyone does work on this, please test with Arduino Due's native port
and/or Teensy 3.6.  A simple Serial.print("hello world") and toggle a
pin in loop() is plenty.  Measure the pin's frequency to gauge the
actual throughput.  Another Arduino with the FreqCount lib will do if
you don't have a fancy frequency counter.

Please, if anyone does work on this, I beg of you to test performance
with these faster native USB boards.  Especially in Java, it's very easy
to unwittingly cause the serial monitor to crash the entire IDE.

[Brian Cook]

> Even now, I believe the slowness of the serial monitor is holding back
> fast boards like Arduino Due.  Back in late 2014 I did some
> benchmarking, comparing the serial monitor against a do-nothing native
> C program which simply discarded the incoming data. 

Speaking of discarding data, is that be a reasonable choice to ensure
the Serial Monitor does not cause problems like locking-up the IDE? 
Should data be dropped if Serial Monitor cannot keep up?

Given the need for speed would something designed-from-scratch for fast
parsing be a better choice than ANSI terminal commands?

Brian

[Adrian Godwin]

I think it would be useful to be able to catch the serial stream in a generic way and pass it - perhaps via a buffer - to another program. At present, the serial monitor and the plotter work slightly differently - the monitor can cope with a programming cycle but the plotter can't, it complains about the port being in use (unless that's been fixed recently). Maybe a telnet connection so it could be linked to one of many existing good emulators - unix terminals, kermit, putty etc.

This, like the ability to  call out to a favourite editor, would allow for more complex plotting or logging of output. It makes more sense to use another program than stuff everything into the IDE.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[newc...@flounder.com]

I had this idea, a while back, which is why I joined this group. And I
immediately fell into three black holes, and have not been heard of since.

What I wanted to do was to produce a "device" compatible with the
Adafuit_GFX library, that would pass drawing commands back to the serial
monitor. I wanted to create a "canvas" within the serial monitor window
that was MxN pixels, and all graphics commands would be passed to this
component for rendering..As another task, to report mouse clicks in the
canvas as "finger touches" on a capacitive or resistive active surface of
the displays. And in the longer term, handle SD card requests mapped to a
file on the host. I had trouble understanding how the plotter interfaced
to the general serial mechanism. So I jointed this group.

I will probably be active once I can finish these three plates of
spaghetti. But if anyone is considering a rewrite of the serial port, I
would be grateful if the idea of integrating a graphics component was
considered. Yes, it may require an extended VT-100 or other escape
sequence be sent back, but i would appreciate if the structure did not
fight me in the task of adding such a feature. Note that I still want to
allow text output via the serial port, so, unlike the serial plotter, the
serial port and the graphics canvas could co-exist in a friendly fashion.
Writing the graphics code is easy. I have been doing graphics for
decades. Integrating into the complex class hierarchy in the IDE is a bit
more challenging.
joe

>> email to developers+...@arduino.cc.

>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to developers+...@arduino.cc.
>

[newc...@flounder.com]

The choice of using graphics is one the developer makes. I would not
think serial port output would be supported in a product. Thus, if the
developer has vision problems, the developer might choose to not use
colored text, graphics, etc. That should not preclude putting the feature
in. My vision is nowhere near what it was 50 years ago, and I would be
disinclined to use the Flyspeck 3x2 font, but why should I deny a
20-year-old with 20/20 vision the option of using graphics?
joe

[Emmanuel Robert]

Thank you for all your comments. It helps to give me a vision of future problems

I am surprised that some of you are worried of performance impact : I would have thought that with our cray something we are now abble to display terminal with VT100 colors without any problem... ;-)  Probably the problem comes from java that would be to slow : do we really need java for serial monitor ? Is java imposed for cross platform support ? I often uses several instances of Arduino IDE serial monitoring at the same time (up to 5 instances at 115200) and notices no problem with my I5 "super computer".

I would have try, before using existing libraries to test with just one color/one escape code to see what's happening, no ?

About blindness : that could be seen later if needed or expected : one pb at a time.

[Adrian Godwin]

Colours are probably not a major performance impact, but it would be seen as a part of general escape handling for cursor positioning etc. Some of these include screen scrolling and can be very slow.

btw VT100 didn't have any colours except inverse video - it was a monochrome terminal. It did handle ANSI escape sequences, which now - after PCs were used as terminals - include colours.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[William Westfield]

 I worry about the performance impact.

    :

Even now, I believe the slowness of the serial monitor is holding back fast boards like Arduino Due.

...

but only 210 kbytes/sec to the serial monitor.

Hmm.  How fast do you need a display aimed at presenting text to a user to work?  210kbytes/second should update a 60x132 page of text at close to 30 frames per second (updating every character.). IMNSHO, f you want higher speeds, you should talk to something other than the Serial Monitor…

Adding bells and whistles to the Serial monitor probably won’t affect performance that much; it’s already going through JAVA JFrame APIs that are probably giving you the “expense” of all the fancy features anyway.  I don’t know if Java has a “simpler and more efficient” text-only interface; I sorta doubt it; at the hardware level you probably still need to be dealing with variable-sized fonts on a high-res bitmap display…

I’m more in favor of implementing some sort of support for third-party terminal programs; the “special” features needed by Arduino (suspend and resume access to the serial port, essentially?) should be relatively easy to add to anything…

(Did your benchmarking include any testing with more traditional terminal emulator packages?)

BillW/WestfW

[Andrew Kroll]

If it is too slow, you're doing it wrong. 

Use a virtual buffer and update display canvas with a low thread priority with some maximum rate.

All updates can get thrown into an array representing a NORMAL 80 width display, with something like a sane 1000 lines of scroll back.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[William Westfield]

> If it is too slow, you're doing it wrong.

> Use a virtual buffer and update display canvas with a low thread =

priority with some maximum rate.

Well, my Java isn't up to the skill level needed to do that, or even recognize if it's already being done.
It's all buried under layers and layers of abstraction that obscure any details of efficiency.

> SerialMonitor
>> AbstractTextMonitor
>>> .AbstractMonitor
>>>> JFrame
>>>>> Frame

Bleh. No wonder embedded programmers dislike Java and other "Object Oriented" languages!

Hmm. app/src/processing/app/AbstractMonitor.java does have:
>
> updateBuffer = new StringBuffer(1048576);
> updateTimer = new Timer(33, this); // redraw serial monitor at 30Hz
> updateTimer.start();

So I guess something like that is happening? I can't figure out where the serial port is actually being read, though.
arduino-core/src/processing/app/:Serial.Java, perhaps?

BillW/WestfW

[Paul Stoffregen]

On 06/21/2018 05:25 PM, Andrew Kroll wrote:
> Use a virtual buffer and update display canvas with a low thread
> priority with some maximum rate.

That is pretty what I did for issue #2233.  Incoming bytes are piled up
in a big buffer and the GUI is updated from the buffer at no more than
30 Hz refresh.  That code has been in the IDE for the last 2 1/2 years.

> All updates can get thrown into an array representing a NORMAL 80
> width display, with something like a sane 1000 lines of scroll back.

As least when I worked on this, dealing with line counts turned out to
be too heavy (at least in Java using the available classes) and
ultimately limiting the buffer in terms of total characters was the key
to keeping the CPU usage low enough to avoid locking up the entire IDE
when dealing with a fast incoming stream from Arduino Due.

Maybe someone much better with Java could make this work?  But I'm a bit
skeptical, since multiple people worked on the IDE lockup &
out-of-memory problem in 2013-2014 and even just that turned out to be
quite difficult.

[William Westfield]

> dealing with line counts turned out to be too heavy (at least in Java using the available classes) and ultimately limiting the buffer in terms of total characters

Yeah, I did once go looking for Java libraries that treated a “screen” as an array of characters (24x80 or whatever) that it would then put up on the actual display.
I didn’t find anything (although I didn’t look THAT hard, and navigating published Java classes is … daunting.) It’s difficult to do a VT100-like emulator when the underlying abstractions are so fundamentally different. :-(

BillW/WestfW

[newc...@flounder.com]

There are several approaches to this problem. The simplest one is to
create an array of String objects. Set the start index to 0 and the end
index to 0. Then you interstate from start index to end index -1. As
lines come in, you add them to the end of this array. When the maximum is
reached, the next insertion consists of advancing start to 1 and the
current line to 0. Thus, once it fills up the maximum number of lines, it
becomes a circular buffer, so there is nearly zero cost to putting a new
line in. There is also a "current first line" pointer, which gets reset
when you scroll, modulo keeping the circularity of the buffer. This is a
fairly simple assignment, I have given it to first-semester students back
in the days when I taught programming. It has the advantage that although
it requires some tricky code to always handle the wraparound, it allows an
arbitrary scroll back.

In real products, I added the ability to "mark" the end of the prolog, so
the startup messages were never lost. I could imagine this being done by
sending a VT character from setup() so all the messages issued by setup()
would be retained. This was similarly tricky, because it ended up being a
circular buffer only from 0 to lock-line, and ran from lock line to the
end. One trick was that when I did the first wrap, I added one more line
to the fixed set, which said ====Mesages earlier than this one have been
deleted===== so when I scrolled back (scrolling had to deal with showing
the first messages when the current buffer-start was hit). SMOP, but
efficient in terms of what had to be managed. There is no Java class that
does this, but it can be based on embedding a simple array inside a
user-defined class, with primitives like SetLockIndex(), Add(),
SetDisplayPos(), Scroll(), EnableScrolling(), and I need to know how many
lines are being displayed. I'd be happy to work with someone on this, but
I don't have time to do it myself.
joe

[Ricardo JL Rufino]

I found this library that can be integrated:

https://github.com/JetBrains/jediterm

"The library is used by JetBrains IDEs like PyCharm, IDEA, PhpStorm, WebStorm, AppCode, CLion, and Rider."

[Andrew Kroll]

Old topic, but I did find something that could indeed be a gigantic improvement over the current serial terminal.
https://github.com/galan/jalita
Java, vt100, light weight, swing based, and looks to be easily adapted as a replacement.

Visit my github for awesome Arduino code @ https://github.com/xxxajk

[kpe...@blinksoft.com]

 

Did you test it for accessibility?  You can run Narrator on your windows box and then see if it reads as the serial input comes in.

 

Ken

 

From: Andrew Kroll <xxx...@gmail.com>
Sent: Saturday, October 6, 2018 2:16 PM
To: Arduino Developers <devel...@arduino.cc>
Subject: Re: [Developers] serial monitor upgrade

 

Old topic, but I did find something that could indeed be a gigantic improvement over the current serial terminal.

[Michel Firholz]

+1

Please keep is simple and stupid and provide as a first step a simple clearscreen byte. (e.g. serial.write(12); // Form Feed)

Just that simple improvement would allow to build static screens for menus.

Concerns about accessibilty are imho just show stoppers, since the narrator will get trouble processing the current serial output anyway.

Regards

Michel