Difference between revisions of "BeagleBoard/GSoC/BeagleBone-based-Serial-Terminal-Server"

From eLinux.org
Jump to: navigation, search
(Timeline)
(Benefit)
Line 136: Line 136:
  
 
===Benefit===
 
===Benefit===
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.
+
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. The final goal of making a ready-to-use serial terminal server image for BeagleBone would make it appealing to hardware hackers who can treat this as another tool that works "out of the box".
  
 
Quotes from IRC:
 
Quotes from IRC:
Line 175: Line 175:
 
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<br>
 
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<br>
 
2018 Mar 20 17:43:11 <m_w_> not saying you have to use kermit but it would be nice to have similar features<br>
 
2018 Mar 20 17:43:11 <m_w_> not saying you have to use kermit but it would be nice to have similar features<br>
 +
-------------------------
 +
2018 Mar 22 09:15:12 <Wormo> the focus at the end could be to use image builder to generate terminal server images that end users can use, and document how to generate an updated one from latest debian
 +
2018 Mar 22 09:18:50 <Wormo> think about what kind of integration might need to be done to make the image a real turn-key system for users, appeal to some of the hw hackers who could want to treat this as another hw tool that works "out of the box" though customizable if desired
 
</blockquote>
 
</blockquote>

Revision as of 09:47, 22 March 2018


BeagleBone based Serial Terminal Server

Student: Harikrishnan R
Mentors: Michael Welling
Code: TBD
Wiki: http://elinux.org/BeagleBoard/GSoC/BeagleBone-based-Serial-Terminal-Server
GSoC: TBD

Status

This project is currently just a proposal.

Proposal

About me

IRC: illustris
Github: https://github.com/illustris
School: BITS Pilani, Goa campus
Country: India
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.

Description

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.

Deliverables

The project will have the following features:

  1. User connects to the terminal server over SSH.
  2. A command line interface will allow users to configure and select the interfaces to monitor and log.
  3. Logs will be split and archived every 24 hours.
  4. User will be able to attach to and detach from individual serial terminal sessions, similar to tmux/screen.
  5. User will be able to view logged data from the serial device.
  6. Kermit style expect-send scripts can be attached to interfaces from the prompt.
  7. Arbitrary scripts/executables can be attached to interfaces for automation through redirection of stdio.
  8. Scripts can be scheduled for periodically connecting to devices, performing actions and logging the output.

Implementation

  • 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.

Timeline

Week Plan
1 Discuss with mentor and finalise available commands/features
  • This will involve making a detailed document that outlines every aspect of the UI and functionality
  • Clearly defining the goals of the project before coding starts will help speed up the work

2 Enable all UARTs, write code to read from UART and log
  • Write the functions that will become the core threads responsible for interacting with and logging output from serial
  • Live mirroring of output requires writing to and reading from the logs without a buffer
  • Escape sequences and control characters from serial need to be written to the logs to avoid mangling of the output

3 Implement non-interactive live log display
  • The logs need to be read and displayed without buffering
  • control characters need to be read and printed verbatim to ensure things like ncurses UIs don't get mangled

4 Implement piping of stdin to uart device
  • First step towards interactive control
  • User should be able to attach to serial devices from the prompt
  • The program needs to forward sequences like ctrl-c to the serial device

5 Implement basic attach/detach functionality
  • The program should catch a dedicated sequence used for detaching from the device
  • Optional: Add a tmux-style UI for switching between sessions

6 Implement CLI commands decided during week 1, Add scripting support
  • Commands would include basic UART configuration, hex viewer etc.
  • Work on scripting support would start this week
  • Add support for one-time execution of expect scripts

7 Add scripting support
  • Extend script support to allow scheduled and periodic execution of expect scripts
  • Could be implemented using cron, or a timer thread

8 Extend scripting support, Test scripting
  • Extend scripting support to arbitrary languages
  • This can be achieved by redirecting STDIO of the script
  • Test different scenarios like automated FTP, automated periodic login/execute/logout

9 BUG fixing and documentation
  • Thoroughly test every aspect of the project to identify bugs or abnormal behaviour
  • Fix any bugs identified during testing
  • Start writing documentation for the project

10 Easy installer
  • Add an install target to the makefile that would install the binaries and set up the software on top of an existing linux installation
  • Test the installer
  • After this, setting up the serial terminal server should be as simple as "make install"

11 Image builder
  • Use image builder to to generate terminal server images
  • Document the procedure for generating an updated image one from the latest latest Debian release

12 Buffer time
  • Optional: make CAD files for serial terminal capes
  • This week is a buffer for any work that is left to be completed

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.

Contingency

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.

Benefit

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. The final goal of making a ready-to-use serial terminal server image for BeagleBone would make it appealing to hardware hackers who can treat this as another tool that works "out of the box".

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 16 08:34:28 <Wormo> I am partial to CLI interfaces myself, especially if there is tab completion


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


2018 Mar 22 09:15:12 <Wormo> the focus at the end could be to use image builder to generate terminal server images that end users can use, and document how to generate an updated one from latest debian 2018 Mar 22 09:18:50 <Wormo> think about what kind of integration might need to be done to make the image a real turn-key system for users, appeal to some of the hw hackers who could want to treat this as another hw tool that works "out of the box" though customizable if desired