Thoughts on terminal emulator for serial interface

[lindsay.wilson.88]

Not strictly PIC or CCS related, but I'm curious about what people think is the best way to interact with a simple menu system over a serial connection. More over-thinking as usual on my part ;-)

As part of my current thingamajig, I have a PIC running a 3-level menu system to allow the user to control various settings and features. By 3-level, I mean there's three different menus, accessed one from the other.

I initially started off using a program called Termite (https://www.compuphase.com/software_termite.htm) which is an extremely basic serial terminal. I've used it a lot over the years and like it because it can be run standalone with pre-configured settings, handy if I need to send it to a customer so they don't need to mess around setting things up. It has just one single dialog for configuration settings.

Here's an example of my menu system running using Termite to talk to it:

https://www.youtube.com/watch?v=hYLoYs2klSo

Termite has a box at the bottom of the window where you enter stuff in a line, then the entire line is sent over the serial port when return is pressed. You can see how everything just scrolls up the page as new text is received. This is alright, but perhaps a bit cluttered.

My next alteration was to simply print a bunch of newlines before the menu, which has the effect of clearing the display. Here's the behaviour now:

https://www.youtube.com/watch?v=PoP_8EKU-nc

I then remembered that "proper" terminal emulators have the ability to interpret escape codes, such as clearing the display, set cursor to top-left, turn bold text on, and so forth. Both PuTTY and Tera Term are examples of emulators like this. Here's an example of my menu running over PuTTY:

https://www.youtube.com/watch?v=ZGxZTtSsyhE

The PIC sends two escape codes to clear the display and set the cursor to the top-left before printing each menu. I'm also using the get_string() function in input.c which echoes back received characters and also handles backspace.

While it's cool using the proper terminal emulator, I'm still attracted by the simpler usage of Termite. I suppose that a typical command line behaves exactly like Termite does, with everything scrolling up the page, so maybe there's really no need to look any further.

Thoughts welcome ;-)

[temtronic]

Years ago I used 'DELPHI' to code the PC side of a PIC based keyboard testing unit. The big reason was that DELPHI produces 'stand alone' code, doesn't use Windows stuff( well, that's what I was told...).
I do know the same program( .exe.) ran on 4 different PCs/ Window versions so pretty sure the guy was right cause no way am I THAT lucky !

[newguy]

I'm actually finishing up a VT100 user interface. I like RealTerm for the PC side.

I prefer a static screen as opposed to scrolling, but that's just me. VT100 command codes suit me fine.

[temtronic]

sigh ... VT100
I remember when they came out and the VT52..
For some reason neither survived the 'clean the terminal with water while plugged in' test......

[dyeatman]

[Ttelmah]

This is actually quite an important question for a lot of uses.
Personally, my bigger projects using a PC (on some a Linux, and others
Windows), I have always ended up here writing a program to do this.
Have to agree that Delphi is probably the way to go for this.
However for a few smaller things I have used TinyTerm. This has the
advantage of being small and simple, but also supporting a scripted
wake-up. So you can launch it, with the terminal window size preset,
no need to configure the serial, etc. etc.. It's small size also makes it great
for running on small SSD based machines. With this you can program it
to send a 'I am here' message to the PIC program, and then have this
send the commands to draw the initial window.

[diode_blade]

Hi, in the past I have used a program called "Windmill ComDebug", its free to download.
Easy to use.
Below is what it can do.
Just for clarity I have used there software and hardware products before.
Very usefull simple program.

ComDebug Features

No programming required
For instruments communicating over RS232, RS422, RS485, Modbus and TCP/IP
Understands ASCII, binary and hexadecimal data
For serial instruments that continually send data and those that need prompting
Quickly identify and correct communication errors
Insert cyclic redundancy checks (CRCs)
Send 4-byte (32-bit) integers, 4-byte words (double words), ASCII characters, hexadecimal, signed bytes, bytes, bits, 4-byte floating point, 4-byte reverse floating point…
Control the state of the PC's serial port output lines
See the state of the serial port input lines
See all bytes sent and received, even non-printing characters like carriage returns. This is crucial when dealing with binary data.
Send acknowledgements
For Windows 10, 8, 7, Vista, XP, 98 and 95
Data logging from one instrument.

[Ttelmah]

I don't think it has a terminal emulation though. Just serial data directly
displayed.

[lindsay.wilson.88]

Thanks for the tips everyone, some good pointers there.