Java program for a better serial monitor .

so i have been working with arduino for some time now . i was thinking about a better serial monitor , where you can write text , delete it or write it at specific positions . you can add buttons and color display or visual stuff like that . and you would set some serial commands for each thing . it's like having a certain resolution of pixels that the arduino would be able to freely manipulate .

i think i can write such a program , but is the idea stupid ? or can it be somehow useful ?

for example if you get some analog input , the arduino would draw patterns instead of sending numbers at random 'just a little example), or if you use an ultrasonic sensor you can get stuff working more visually . i know you can get such a thing working with "processing" the interface that the IDE is based on . but this would make it much more simple .

There are lots of 3rd party "Terminal emulators" including ones with cursor positioning and/or advanced graphics capabilities. I'd much rather see Arduino better support "add-on" programs for the Serial monitor than see "yet another smart terminal program."

So you’re thinking of having the serial monitor be able to act like a TFT/graphics LCD display?

i did write a simple interface for that and a little serial protocol so that window looks nearly like the serial monitor one .

in that example sends commands via serial to create two rectangles and write "led on" and "led off" on them , then wait untill the cursor is over one of them , then you can trigger something that looks like a button . i did test that and it works good , a led on pin13 lights up when you press the first button and lights off when you press the second .


here is something else for a common input . instead of numbers , i wrote commands that would draw two grey lines then drawing green lines and the curves in between them using simple math .


the thing is , the program to outputs the first buttons and the second data on the screen is the same on the computer , the arduino though has the button data and the output data . it costs the arduino almost nothing since the instructions for the output do not cost the processor and memory anything more than "Serial.print" does .

What happens if a fast board like Teensy 3.1 or Arduino Due uses Serial.print() without any delays? Can this handle a continuous stream of numbers as fast as these 32 bit boards can transmit?

look at the arduino serial programming process and how fast that is . the limitations are the limitations of the serial port of the computer i think .

some tests when i tried to ramp the speed of the serial transmission up , i tried to get the color of the box to change when the mouse hovers over them . so the computer sends commands to inform about the position of the cursor and the arduino checks it , then the arduino has to send an instruction to draw on other box with a lighter color and rewrite that "led on" on it with yet an other instruction .

even though the arduino is the one doing all the action via serial ,it looks like the computer is doing the whole thing , when i hover the mouse over the dark grey box it lights up decently fast.

besides i did test some viltage monitoring program where you have to draw a green representation of changing values on the palette and that one was fast to .

like i said , the speed limitation , are those of the computer serial port and the code that is handling the serial communication . though for a 16mhz or 20mhz arduino(overclocked) it runs decently . it highly depends on the rate.

+the arduino IDE serial monitor does not use the full 0->255 range of values that a byte range provides . so basically this serial monitor boots up the same way then the arduino sends instructions to turn on the palette at a requested resolution .

For Arduino Uno & Mega (and clones), you are correct. The slow rate of serial data limits how fast things can run.

For Arduino Due (native port) and Teensy 3.1, and even the slower Arduino Leonardo and Arduino Zero (native port) and Teensy LC & 2.0, the communication runs at the full USB speed. It is NOT limited by a serial baud rate. On those boards, regardless of the number used with Serial.begin() or SerialUSB.begin(), the communication always occurs as fast as the USB ports on both ends can deliver data.

If you've only ever used Arduino Uno & Nano (or clones), you've probably never experienced the speed of modern USB-based boards. They've very fast.

Before Arduino 1.6.0, the Arduino Serial Monitor would consume all the Java virtual machine memory in a matter of minutes. Massive CPU usage occurred too, effectively crashing the Arduino IDE on many slower computers, before the memory crash could happen.

I personally redesigned the serial monitor, shortly before Arduino 1.6.0. Others had tried. Many attempts to limit memory usage caused a lot more CPU usage, which made the crashes even worse. A lot of difficult work went into making the Java-based serial monitor able to keep up with maximum rate data from these faster boards. Especially Teensy 3.1 could massively overwhelm the older Arduino IDEs (even though Due should be theoretically faster).

If you've never used any of these faster boards, I highly recommend you get one and try testing your code with the fast rate of data it can send. Slow serial-based boards are still widely used, but already fast native USB boards are less expensive (eg, Teensy LC or Leonardo clones) than a serial board with a USB-serial converter, so native USB is certainly the future.

If you're developing and testing new software, don't you think it'd be a good idea to test with modern native USB hardware, rather than only older and slow baud rate limited serial?

thank you for the interesting point . i did work with high speed USB . also did work with data transmission at super high speeds (USB or other ...) . though with the right protocol , even such elements can be covered (i think) . though before starting to think about such details , i still don't know if this idea is worth investing time on .

i will leave it to the community , i expect nothing i, return , it's just something i think would make the simple low level arduino experience much closer to beginners in this field .

an other use for this also , is that you can get the interface or the "monitor" to detect all keyboard inputs including arrow buttons .. etc , mouse movements and even external controllers . all of that can be considered as useful input .