Project Outline no.2

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

Basic functionality designed to be extended easily

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

Expose HTTP interface to clients/network

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

More features

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.

Project Outline no.2

Project Draft No.1

After chatting on IRC with some other students I was able to better understand the Serial Terminal Server project, its goals, requirements and complexity. I think that I’m definitively going to apply for that project, so I ordered a BeagleBone Black now. Since I have no experience with BeagleBone, RaspberryPi and similar boards I think that exploring the BeagleBone Black before starting to code is a good idea. I already thought of some solutions, one of them is shown in the sketch below which involves the PRUs for buffering I/O data. I checked out the BegleScope project from ZeekHuge which also uses the PRUs for buffering, so that might help me in getting some ideas. A slightly different solution I came up with was to use DMA to transfer data from the PRUs (or maybe directly from the UART pins) into the I/O buffer. Yet, this attempt seems to cause people some headaches, as some have already tried it and did not succeed. I will focus for now on using the PRUs along with RPMsg for communication with the A8 and let the PRUs write the buffers.

First architecture draft

Open questions on which I will focus on now are:

  • How will communication between the two PRUs happen?
  • Is there a better solution than passing commands through all instances or can we make calls directly to the UART device?
  • How can multiple UART devices be monitored without loosing inputs?
  • Is the driver really the right instance to copy the PRUs buffer to the sd card or should this task be done by another instance?
  • Is there another solution which does not rely on the PRUs?

When talking to ZeekHuge it turned out that it should be possible to reuse and modify some of his code in order to buffer UART I/O. In the days to come I will check out more of his code and explore how to write drivers, how to write code for the PRUs and how to deploy everything so that it’s easy to set up.

Project Draft No.1

Setting up my development environment for cross compilation

As I intend to apply for the PRU or Terminal Server projects mentored by BeagleBoard I now set up my development environment. This involved (finally) installing Linux as dual boot on my Laptop (until now I had it running in VirtualBox) and installing all the required packages and libraries on my fresh installation. I chose to use gcc-arm-linux-gnueabi after some research (alternatives were angstrom and linaro) and qemu as emulator.

sudo apt-get gcc-arm-linux-gnueabi build-essential qemu

After installing everything I just forked the gsoc-application project from GitHub which is a task all applying students have to perform. Here is my repo in case you want to see it:

Now I’m going to make a pull request and will eventually get in touch with the community in the days to come.

Setting up my development environment for cross compilation

My Favorites

Alright, I spent some time examining all the projects listed below and found my favorite projects. I decided to pay more attention to what I am interested in. Working on things I like makes it always easier for me to learn new skills. Also, I want the project to teach me some new skills instead of just asking me to reproduce stuff I already can do, but also have some parts in it I am familiar with in order to find a starting point. And after all, I checked if the project is mentored by a community I would like to engage with even after GSoC. So here we go:

Continue reading “My Favorites”

My Favorites

GSoC research before official announcements

As many of my exams take place right after Google officially announces all selected organizations I need to do some research in advance. That way I can not only find enough time to learn but also get some information about projects I might be interested in.

I started my research mid January. After attending the Operating Systems lecture during the winter term I discovered my love for hardware controlling code right next to my empathy for Apps and UI design. But I think my Java skills are still greater than my C skills, so it probably makes more sense to watch out for a Java project.

During my research I payed attention to the skill set required to accomplish the project, the license applied to the product, the documentation and sources for help, how active the community is and to my level of interest in the organization as a whole and in the project in particular.

So, here are the organizations and communities I want to give a closer look to:

Continue reading “GSoC research before official announcements”

GSoC research before official announcements