New GUI based serial terminal for embedded development (Linux and Windows)
Hi all, just wanted to let everyone know of my new open-source serial (and TCP/IP) terminal program aimed at embedded developers.
I wasn't happy with what was available on Linux, so I decided to write my own. The goals were to have a modern GUI (tab based, pull out panels, etc) and I wanted support for binary protocols.
It has support for ANSI escape sequences, XModem (up/down), binary blocks, hex dumps, bridging 2 open connections, and more.
This looks great. I don't do serial/embedded stuff too often at the moment; ESPHome took away much of my need to hand-build stuff (happy and sad about that), but when I do I always find it slightly irritating to remember the syntax to connect with minicom or screen (I'm a Linux user).
I'm sorry I can't give more useful feedback at the moment, but this is certainly encouraging me to come up with an idea for an embedded project so I can try it!
Oh damn, this could easily replace my own bespoke serial monitors.
Can a plugin filter the list of available ports? For instance serial over Bluetooth creates two virtual ports for initiating and accepting connections (on windows at least). My bespoke monitor filters these and only shows the outbound ports to the user. It also pulls in the Bluetooth device name from WinRT, etc.
Thinking about it a bit more, if someone wanted to filter the comports like this you could copy the standard comport IO driver and make a new plugin that only listed the outbound ports (you could also restrict the list to Bluetooth devices).
Internally the comport IO driver is just a plugin that gets compiled into the main exe (any plugin can be made into a built in, just add the source to the .pro file, add a call to the register function and now the extern plugin is built in).
So you could copy the existing comport IO driver, change the 'REGISTER_PLUGIN_FUNCTION_PRIV_NAME' and 'COMPORT_URI_PREFIX' defines to something else (so it doesn't conflict with the built in 'COM' one). Change the code so filter any comport that isn't for the Bluetooth device. Compile the source and package the resulting .dll using the ExternPluginMaker tool. Done
When the new plugin is installed the new connection dialog you will list your detected "devices" listed along with all the other types (you could prefix them with bluetooth for example).
Feel free to email me if you would like more details.
There isn't any filtering of serial ports (it lists everything it finds).
However it does support bookmarks. With bookmarks you open the serial port you want to use then select to bookmark it. WhippyTerm will take the current config you are using and save it for later. You can then just pick the bookmark later to reopen that connection. Bookmarks also store some of the settings (like is it a binary or text connection, terminal size, colors, etc).
This is neat. The send buffers and live display give it a nice edge over something like Tera Term. One nitpick: I couldn't find the option to disable autoscroll on incoming serial streams. Like 'Auto scroll only in bottom line' in Tera Term. Thanks!
Can't really help with exact instructions for other distros, but the "in a nutshell" is you need to install qtcreator and QT5.
After you have them installed and working all you have to do is load the .pro file from the Project directory (https://github.com/TheBeef/WhippyTerm/tree/main/Project) you should be able to just hit the green debug/go button and it should work (you do need to be using the gcc toolchain). This is the same for the Windows build.
New GUI based serial terminal for embedded development (Linux and Windows)
Hi all, just wanted to let everyone know of my new open-source serial (and TCP/IP) terminal program aimed at embedded developers.
I wasn't happy with what was available on Linux, so I decided to write my own. The goals were to have a modern GUI (tab based, pull out panels, etc) and I wanted support for binary protocols.
It has support for ANSI escape sequences, XModem (up/down), binary blocks, hex dumps, bridging 2 open connections, and more.
Source link: https://github.com/TheBeef/WhippyTerm
This is the first release (version 1.0), and I am hoping people will have a look (and hopefully like it).
This seems really nice, thank you! Does it support auto-reconnect, like `tio` does?
It doesn't currently support it, but I was planning in the next release (a number of people have asked for it so it's a definitely going to add).
This looks great. I don't do serial/embedded stuff too often at the moment; ESPHome took away much of my need to hand-build stuff (happy and sad about that), but when I do I always find it slightly irritating to remember the syntax to connect with minicom or screen (I'm a Linux user).
I'm sorry I can't give more useful feedback at the moment, but this is certainly encouraging me to come up with an idea for an embedded project so I can try it!
Oh damn, this could easily replace my own bespoke serial monitors.
Can a plugin filter the list of available ports? For instance serial over Bluetooth creates two virtual ports for initiating and accepting connections (on windows at least). My bespoke monitor filters these and only shows the outbound ports to the user. It also pulls in the Bluetooth device name from WinRT, etc.
Thinking about it a bit more, if someone wanted to filter the comports like this you could copy the standard comport IO driver and make a new plugin that only listed the outbound ports (you could also restrict the list to Bluetooth devices).
Internally the comport IO driver is just a plugin that gets compiled into the main exe (any plugin can be made into a built in, just add the source to the .pro file, add a call to the register function and now the extern plugin is built in).
So you could copy the existing comport IO driver, change the 'REGISTER_PLUGIN_FUNCTION_PRIV_NAME' and 'COMPORT_URI_PREFIX' defines to something else (so it doesn't conflict with the built in 'COM' one). Change the code so filter any comport that isn't for the Bluetooth device. Compile the source and package the resulting .dll using the ExternPluginMaker tool. Done
When the new plugin is installed the new connection dialog you will list your detected "devices" listed along with all the other types (you could prefix them with bluetooth for example).
Feel free to email me if you would like more details.
There isn't any filtering of serial ports (it lists everything it finds).
However it does support bookmarks. With bookmarks you open the serial port you want to use then select to bookmark it. WhippyTerm will take the current config you are using and save it for later. You can then just pick the bookmark later to reopen that connection. Bookmarks also store some of the settings (like is it a binary or text connection, terminal size, colors, etc).
It's a lot like bookmarks in a web browser.
This is neat. The send buffers and live display give it a nice edge over something like Tera Term. One nitpick: I couldn't find the option to disable autoscroll on incoming serial streams. Like 'Auto scroll only in bottom line' in Tera Term. Thanks!
It seems like I missed this option. I'll be adding it to the list of things to do for version 1.1 :)
Thanks for the feed back.
Can you add Linux build instructions for people not on Debian/Ubuntu?
I didnt see anything on the github or in the source download.
Alternatively an AppImage or Flatpak is a nice way to test software.
Can't really help with exact instructions for other distros, but the "in a nutshell" is you need to install qtcreator and QT5.
After you have them installed and working all you have to do is load the .pro file from the Project directory (https://github.com/TheBeef/WhippyTerm/tree/main/Project) you should be able to just hit the green debug/go button and it should work (you do need to be using the gcc toolchain). This is the same for the Windows build.
Hope this helps.
Why no macOS support?
I don't have a mac. I did have a guy who was going to add support for it but he backed out.
The main GUI is built in QT so making a mac port shouldn't be too hard (the serial port detection would be the hardest part I think).
Kudos for going with Qt. It looks nice.