Student: Harikrishnan R
Mentors: Michael Welling
This project is currently just a proposal.
School: BITS Pilani, Goa campus
Primary language: English
Typical work hours: 11:30 PM to 4.30 PM UTC
Previous GSoC participation: No previous participation.
About my project
Project name: BeagleBone based Serial Terminal Server
Task Completion: Pull request.
Often in embedded development it is valuable to have a serial terminal server which can retain a serial port connection along with buffered past I/O separate from a typical host PC, either for longer term logging of serial port data or to enable remote management of a device via serial port. Commercial units which have this capability are very expensive, with even single port serial terminal servers consting hundreds of dollars. The BeagleBone has 4 highly capable UARTs exposed besides UART0 through the cape connectors. A simple cape hardware could easily enable a BeagleBone to physically have all the interfaces needed to be a serial terminal server.
The project will have the following features:
- User connects to the terminal server over SSH.
- A command line interface will allow users to configure and select the interfaces to monitor and log.
- Logs will be split and archived every 24 hours.
- User will be able to attach to and detach from individual serial terminal sessions, similar to tmux/screen.
- User will be able to view logged data from the serial device.
- Kermit style expect-send scripts can be attached to interfaces from the prompt.
- Arbitrary scripts/executables can be attached to interfaces for automation through redirection of stdio.
- Scripts can be scheduled for periodically connecting to devices, performing actions and logging the output.
- A new user will be added to the BeagleBone for users to connect to.
- The new user will have a custom prompt instead of bash.
- termios will be used to configure serial interfaces.
- Incoming data will be piped to a log file without buffering.
- When a user attaches to a session, the log will be tailed to display the serial output.
- Input from the user will be piped to the serial device in interactive mode.
- A cron job will handle log archiving.
- The native "expect" program will be used to parse expect scripts.
- On running a script, the output of UART will be piped to the script, and the output of the script will be piped to UART.
- scheduling of scripts will be handled by a separate thread.
|1||Discuss with mentor and finalise available commands/features|
|2||Enable all UARTs, write code to read from UART and log|
|3||Implement non-interactive live log display|
|4||Implement piping of stdin to uart device|
|5||Implement basic attach/detach functionality|
|6||Implement "configure" CLI command to configure UARTs|
|7||Add scripting support|
|8||Add and test scripting support|
|10||BUG fixing and documentation|
|11||BUG fixing and documentation|
|12||Package into installer|
Experience and approach
As the controls engineering lead of Hyperloop India, I have worked extensively with embedded electronics and software. One of the nodes used in the pod electronics was built around a BeagleBone with a device tree overlay for enabling DCAN1. I have also ported FreeRTOS to a RISC-V processor I helped design.
What will you do if you get stuck on your project and your mentor isn’t around?
If Michael and Stephanie are unavailable, I would try asking for help on IRC. I would also consult relevant manpages and documentation.
This project will allow users to monitor up to 4 UART devices over ethernet without having to use either an expensive serial terminal server, or an always-online computer with USB hubs and multiple USB-TTL converters. This will also allow users to automate monitoring by using expect, python and other scripting languages.
Quotes from IRC:
2016 Mar 04 17:40:03 <m_w> I like the serial terminal idea
2016 Mar 04 17:43:02 * nerdboy would like to see a cape with a set of pins and db9's, each one selectable...
2016 Mar 04 17:44:45 <nerdboy> m_w: my really like that idea too, i might be able to talk her into co-mentor 2016 Mar 04 17:44:51 <nerdboy> *my boss even
2016 Mar 04 17:46:57 <nerdboy> use case is up to 5 controller boards 2016 Mar 04 17:47:04 <nerdboy> simultaneous
2017 Mar 16 16:00:53 <m_w> the trick is making an interface that is more user friendly 2017 Mar 16 16:01:45 <m_w> just ssh'ing into the target and running minicom is not going to be enough
2017 Mar 16 16:06:19 <m_w> perhaps a TUI or web interface to configure the terminals 2017 Mar 16 16:06:55 <m_w> baud rate, bits, parity, logging file, etc 2017 Mar 16 16:08:09 <m_w> another nice feature to have would be a hexadecimal viewer 2017 Mar 16 16:09:13 <m_w> perhaps timestamps would be useful 2017 Mar 16 16:10:12 <m_w> the trick is packaging the software in a way that you would expect from a consumer product
2017 Mar 19 17:48:08 <ordsen> m_w: hey I looked through commercial terminal servers and found that some companies also include pattern matching, messaging when certain events occur and tunneling to interconnect 2017 Mar 19 17:48:54 <m_w> maybe we can add some of those features as stretch goals
2018 Mar 20 15:57:15 <m_w_> serial logging and sessions are gimmies we need a UI of some sort and maybe some integrated scripting support 2018 Mar 20 15:58:28 <m_w_> this project was close to making the cut for the last few years so a good proposal would really up it's chances of being accepted
2018 Mar 20 16:19:28 <m_w_> illustris, is there going to be an attempt at making some supporting hardware? if so it needs to be ready soon
2018 Mar 20 16:24:46 <m_w_> scripting and logging are critical features
2018 Mar 20 16:52:42 <m_w_> serial automation is especially important in embedded test fixtures
2018 Mar 20 17:42:36 <m_w_> illustris, kermit allows for an expect like interface to poll for expected serial output and conditionally send data out 2018 Mar 20 17:43:11 <m_w_> not saying you have to use kermit but it would be nice to have similar features