It’s been a while since I published my first project outline here. I talked to the project mentor, Michael Welling, and he was able to answer my questions related to the project goals. Using the PRUs is a bit oversized, there is no need at all for that. What I will try instead is to configure the UART driver so that he writes input data into a file. That file will be used as log file and can be accessed through the UI.

Did I say UI? Yeah, the last project outline didn’t show that. But a UI is definitively a part of the project and will ease the usage of the program. That way, people with a chronic command-line-phobia will also like to use the serial terminal server.

So what is this about now? Well, there is a UI, probably a web interface, provided by the BeagleBone. This interface will be accessed by a PC and allow the user to access and manage serial devices connected via UART to the board. As you can imagine, there will be something like a middleware needed to connect the web interface to the serial ports. Additionally, all I/O will be logged and will be accessible through the interface.

I created the following component diagrams which show the scope for each stage of the project. I divided it into 3 stages. Stage 1 will be the one which I will definitively implement during GSoC. It includes basic functionality and fulfills the project’s goals. Stage 2 extends the scope and could also fit into the 12 week timeline, depending on my progress with Stage 1. in contrast, Stage 3 will probably be difficult to implement completely during the summer as it introduces a set of extra features which will consume much time to implement. Note that each stage will be divided into several milestones.

stage 1

I payed attention to hide implementation details behind interfaces which allow for easy access, use and extension of single components. I want to make it easier to both include new serial devices (I2C, SPI, etc.) as well as including new features into the terminal server or UI (e.g. see Stage 3).

Features introduced in this stage:

• set up serial UART connections through UI
• edit baud rate, parity bit
• send messages to devices
• read current messages from devices
• log input for each UART device along with a timestamp in a file
• packaging everything into an image (not exactly a feature, but also a goal)

I am still looking for what’s the best solution to connect the terminal server with the client, but probably it would make sense to include Stage 2 which adds an HTML interface:

Stage 2

This basically prepares the project for Stage 3. As pretty much everything can use HTTP interfaces, it makes sense to me to add this interface to the web server. Client applications now also have the option to use the HTTP interface and thus will not need any dependencies to the serial management.

Additional features introduced with this stage:

• HTTP interface exposed to the network

Stage 3

Additional features introduced with this stage:

• automation rules (e.g. automatically send a mail when an event occurs)
• tunneling to interconnect serial devices
• pattern matching
• upload log to external server/host pc
• hexadecimal viewer

These functions are regarded as “stretch goals”. I might be able to implement some parts during the summer, but most of it will probably wait until past GSoC. As I really like these ideas I have also personal interest in implementing them even after GSoC ends, so stay tuned.
I also created a draft which showed how the architecture would look like if I implemented an additional server ( / socket) in C. That server would be responsible for all features introduced with Stage 2 and Stage 3. Yet, that would nearly double the complexity of the project. Using C for the web server means that there are in fact two web servers running: One to provide a backend to the web interface and the other one for tunneling and the automation rules stuff. Note that here we would also need an API which would allow other servers to access our server.. To my mind, if you really need something like this you could use the C-Library within your solution, but for the GSoC project it will make much more sense to just use the web server for all this stuff. Plus, it fits better into the timeline as I’m faster with JavaScript.

Past Stage 3 we can include more serial interfaces like I mentioned before. Due to the HTTP interface, also IoT applications can build up on this project or we can use the C-Library to access serial devices without going through the hassle of using device nodes. Adding a cape to turn the BeagleBone physically into a serial terminal server and including it into the library can be another task.

I guess some of the library functionality already exists inside of other projects out there, I will see if I find something useful. Same applies to the web server component.