Difference between revisions of "BeagleBoard/GSoC/BeagleBone-based-Serial-Terminal-Server"
(→Benefit) |
(→Timeline) |
||
Line 60: | Line 60: | ||
|- | |- | ||
!Week !! Plan | !Week !! Plan | ||
+ | --------------------------- | ||
|- | |- | ||
− | | 1 || Discuss with mentor and finalise available commands/features | + | | 1 || '''Discuss with mentor and finalise available commands/features'''<br> |
+ | * 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 | + | | 2 || '''Enable all UARTs, write code to read from UART and log'''<br> |
+ | * 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 | + | | 3 || '''Implement non-interactive live log display'''<br> |
+ | * 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 | + | | 4|| '''Implement piping of stdin to uart device'''<br> |
+ | * 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 | + | | 5 || '''Implement basic attach/detach functionality'''<br> |
+ | * 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 | + | | 6 || '''Implement CLI commands decided during week 1, Add scripting support'''<br> |
+ | * 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 | + | | 7 || '''Add scripting support'''<br> |
+ | * Extend script support to allow scheduled and periodic execution of expect scripts | ||
+ | * Could be implemented using cron, or a timer thread | ||
+ | --------------------------- | ||
|- | |- | ||
− | | 8 || | + | | 8 || '''Extend scripting support, Test scripting'''<br> |
+ | * 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 || | + | | 9 || '''BUG fixing and documentation'''<br> |
+ | * 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 || | + | | 10 || '''Finalise makefile targets'''<br> |
+ | * Add an install target to the makefile that would install the binaries and set up the software | ||
+ | * Test the installer | ||
+ | * After this, setting up the serial terminal server should be as simple as "make install" | ||
+ | --------------------------- | ||
|- | |- | ||
− | | 11 || | + | | 11 || '''Prototype cape'''<br> |
+ | * Prototype a cape with DB9 connectors and [http://www.ti.com/lit/ds/symlink/max232.pdf MAX232] RS232 to TTL converter | ||
+ | --------------------------- | ||
|- | |- | ||
− | | 12 || | + | | 12 || '''Make CAD files for cape''' |
+ | * Optional: I could also have a piece fabricated if time permits | ||
+ | * This week is also a buffer for any work that is left to be completed | ||
|} | |} | ||
Revision as of 00:25, 21 March 2018
Contents
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:
- 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.
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
|
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 CLI commands decided during week 1, Add scripting support
|
7 | Add scripting support
|
8 | Extend scripting support, Test scripting
|
9 | BUG fixing and documentation
|
10 | Finalise makefile targets
|
11 | Prototype cape
|
12 | Make CAD files for cape
|
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.
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