The Serial Killer

A little over a year ago, I decided to write my own Serial Terminal.  Most people’s reaction to this is “why?”  Serial comms is a technology well on its way out, and what they see as the critical hit, a bunch of terminal programs already exist.  Many of which are even open source.  So why would I bother?

To begin with, the current applications didn’t do all of what I needed, how I needed it.  Because of the nature of the kind of people who use Serial Ports with some regularity, Serial Terminal programs tend to be written by people whose day-jobs are very low level.  This is wonderful if you want to be confronted with a program that resembles the cockpit of your average jumbo jet:


Now, no offence is intended to the good folk who wrote this cross-platform program and this particular one was recommended to me after I announced my own application.  You can do everything with it, but just starting to do anything is somewhat intimidating.  Now fair’s fair, so here’s my app’s interface for you to poke at:

Serial Killer on Windows 7

The features I require are:

• “friendly-connect” (if I start typing in the terminal and it’s not connected, it should attempt to connect to the current settings)
• Being able to function in both ascii / plain text and raw hex
• connecting at different baudrates
• being able to convert to the two modes with existing data
• knowing the time when each piece of data arrived or was sent
• works on both linux and windows
• being able to save data from a session to a text file
• being able to use the thing without having to twiddle a thousand knobs first.
• automatically switching baudrate upon seeing a special packet go past (this one isn’t implemented yet)

None of these is asking particularly much, I would have thought and yet, my searching came up short.  I use Serial Terminals at my place of work, so I also got to piggy-back off the searching of my many colleagues and yet, the terminal program used most often there is Terra-Term.  Gtkterm was the one I liked the most, with its main disadvantage being that it only runs on linux.  Linux is the development OS for the firmware of these devices, but the programming software only runs on windows, so most of the interaction is done plugged into the windows machine and un-plugging and re-plugging is a hassle I don’t need.

The more astute of you will notice that Gtkterm is open source, using GTK (obviously) so making it run on windows shouldn’t be too big a deal, right?  Well, actually, yes.  It is.  I have pulled the source code and have managed to get some patches accepted.  These patches were mostly clean-ups, with the exception of one, which was a Ux improvement for the logging functionality (which I’m pleased to say has made it into the 13.10 release of Ubuntu).  I had three problems in my quest to move this cross-platform.

1.  It turns out that they use a linux-only widget for the Terminal itself
2. Finding a decent C Open Source Serial Port library for windows is more difficult than it should be.  The closest I came across was that bundled with ruby-serialport, which I could have eventually adapted to my needs.
3. But most importantly, the act of getting patches accepted was quite a hassle.

The maintainer has a full time job and a life, and took over this project after it was more or less abandoned by its previous maintainer.  I have a lot of respect for people who do that sort of work, especially considering that it’s what I think to be a quality program.  But the effort required to get simple patches accepted was, as mentioned, too much for me.  It would take him around two weeks to reply to simple translation (the original source is in French) patches, so imagine if I sent in something with real functionality changes?

So one day, I decided I would have a bash at seeing what I could put together in an afternoon.  Turns out, using C# and my previous GTK knowledge, I was able to make a program that sent and received characters across a serial port at a bunch of different speeds.  On windows.  Not bad for a single afternoon.  If it weren’t for the fact that mono doesn’t implement event-based serial comms, it would have worked on Linux out of the box, too.  So with a small amount more work, I had something usable working on two platforms in less time that it would have taken to get a single clean-up patch into gtkterm.

And the final reason I wrote my own seems to be something abhorred by the software community.  I reinvented the wheel, because I wanted to learn how to make better wheels.  It’s not a trivial task to weave usability and functionality together, something where most other comparable programs have, in my opinion, mostly failed.  So now I’ve got a program I like to use and I have the ability to effect change with relatively short notice.  Really, that’s all I wanted.

In my next post, I’ll dissect how I built it, focusing on some of the more interesting techniques, so that others can benefit from my wheel-making learnings.  In the mean time, see here for the source code.