BeagleBoard/GSoC/SynchronousDataCollectionPRU

=BeagleBone synchronous data collection=

Easily set up a serial terminal server on a BeagleBone, configure and manage attached serial devices through an UI and read past I/O logs.

Student: Nishant Pani Mentors: Hunyue Yau Code: https://github.com/NP95/SyncData Wiki: http://elinux.org/BeagleBoard/GSoC/SynchronousDataCollectionPRU GSoC: [GSoC entry]

=Status= This project is currently just a proposal. I am collecting Ideas and thoughts on my blog and preparing for the project on GitHub

=Proposal= I made a to the gsoc-application repo

About me
IRC: NP95 Github:https://github.com/NP95 School: Birla Institute of Technology and Science,Pilani Hyderabad Campus (BPHC) Country: India Primary language: English,Hindi Typical work hours: 9 AM - 5 PM(IST)

About my project
Project name: BeagleBone-based Synchronous Data Collection

Synopsis
The project is aimed as an extension to the BeagleLogic project. The Beaglelogic project gives us the ability to use the Beaglebone as a logic analyzer. This is accomplished by the programming the two PRU's(Programmable Real Time Units) to sample and hold the data coming in through the EGPIO's. However a limitation on the Beaglelogic is that it captures the data in an asynchronous manner, i.e it takes snapshots of the signals. So in case of when the incoming signal is a signal synchronized with a clock we will not be able to capture the signal as it is.

The aim of this project is to be able to synchronously capture signals as accurately as possible. For example, a 25 Mhz I2C signal for being captured as it is on the BeagleLogic we have to sample it at a frequency of around 50 Mhz. With this module in place we can capture the signal in sync with the clock. This allows us to capture important information about the signal which may be lost when captured in an asynchronous manner.

Project Structure
The project can be divided into three main components which expose interfaces to other components. These components and interfaces describe the deliverables and will be provided to users through an image:
 * PRU Core for accessing serial devices via UART: Direct access to the serial devices will be done inside a C-library like component. It will enable the use of all four serial ports and handle communication with connected devices, keep track of all the configurations for each serial port and map the logging files to the appropriate serial port. The project was supposed to use already existing software like Screen or Minicom, but they are more appropriate for interactive tasks. Expect can be useful for scripted interaction, but the actual device access will happen through device nodes and might utilize the termios API. I'm aware of the requirement to track all I/O in a way that no inputs are missed. I examined UART and found that even with high baud rates and continuously spamming on the serial port we have 1041,6µs until the 16Byte input FIFO fills up. That should be enough to write a file to DRAM so that this library can handle the file writing in time and thus prevents FIFO overflows. However, I talked to m_w about modifying the serial device driver. According to him DMA is enabled by default and could be configured to write to a file. I will test these approaches before GSoC starts with the help of my Arduino as serial device. The library is accessed through an interface written in C. Stretch Goals: Also include SPI, I2C etc.
 * Kernel Drivers: This interface allows other applications, e.g. the front end, to access the library's features. Stretch Goal: Due to the project's architecture a CLI can be implemented on top of the library interface with less effort
 * NodeJS Bindings: As the terminal server component will be implemented with NodeJS I also need bindings to talk to my library. This component behaves like a wrapper.
 * Terminal Server: This provides a runtime for the web interface. The first goal for this component is to just delegate calls from the web interface to the binding. Stretch Goals: Autostart the web server on boot. For future use this component can be turned into a web server which exposes the HTML interface to the whole network. Note that functionality can be extended here without needing to modify the C library. This comes in handy when features like automation, action buttons, interconnection of serial devices, scripted interaction (etc) are added.
 * HTML Interface: Provides the web interface and other applications with an HTML interface. The scope of this component depends on the features implemented in the terminal server component. To allow access to new features this interface will have to be extended accordingly.
 * Web Interface: Any functionality added to the terminal server component can be included into the UI and will rely on the HTML interface. Implementation will happen with ReactJS unless I find an appropriate framework/template to start from. The UI provides the user with...
 * Configuration of UART communication (parity bit, baud rate)
 * Enable/Disable logging of I/O to files
 * Read logs and current messages
 * Send messages to a serial device
 * Handle multiple serial devices comfortably

Timeline
I will implement some samples and experiments useful for this project before and during the community bonding period. During that time I will also look out for existing software useful for this project which I have not seen in my research yet.

TODO recheck as soon as scope is approved...

Community Bonding period 2017-06-06: Milestone #1 2017-06-13: Milestone #2 2017-06-20: Milestone #3 2017-06-27: Milestone #4 2017-07-04: Milestone #5 2017-07-11: Milestone #6 2017-07-18: Milestone #7 2017-07-25: Milestone #8 2017-08-01: Milestone #9 2017-08-08: Milestone #10 2017-08-15: Milestone #11

Last week will serve as reserve or, otherwise, will be used for improving the existing code base in terms of code-style, docs and additional tests or implementing stretch goals

Experience and approach
As a part of my coursework I have completed courses in Microprocessor Interfacing and Computer Architecture and written programs in MIPS and x86 Assembly. This gives me a solid footing in understanding the concepts and details in the hardware documentation. I have done coursework in Java and C. In addition,I am comfortable in writing scripts in Python,Bash and Perl. I am completely comfortable in using GNU/Linux, Makefiles as Ubuntu is my regular OS.As a part of my current internship,I have worked on AM335 SoC and am comfortable with the boot process and basics of Embedded Linux. Also recently I have become comfortable in basic concepts of Linux drivers https://github.com/NP95/Linux-Device-Driver. Also in a previous internship I made a application in Qt for transmitting data between 2 PC's over the RS232 protocol.

I feel I have most of the required skills required to complete this project. The only part which I am lacking skills is in the UI design part. But I am confident if selected, I can learn the basic skills and concepts during the community bonding period and not let my present ignorance of these topics hinder me in completing this project. I will have no academic obligations during the GSOC coding period and can devote around 7-8 hours on weekdays and 10-12 hours on weekends.

Contingency
BeagleBone is an open source project, but even more important, its an open source community. If I get stuck on a problem and my mentor is not available I will ask the community for help and try to find a solution that way. Consulting the Docs is also one option for me or, if there still is no solution or there is something only my mentor knows, I can also proceed with different tasks until he is available again.

Benefit
The primary advantage of this module, if completed is the ability to capture synchronous signals very accurately. With the addition of this module to the Beaglebone ecosystem, along with Beaglescope,PRUDAQ and Beaglelogic,it makes the DAQ ecosystem in the Beaglebone much more mature and varied. This makes the Beaglebone a very attractive option for people who are interested in learning about Embedded Systems, as they can get the Beaglebone and for a very low cost have a complete debugging kit. The cost factor is also an important issue, as most modern logic analyzers and oscilloscopes are too expensive for the regular hobbyist.

Suggestions
I intend to dedicate most of my time to this project. This means that I will not attend university lectures or work elsewhere during the coding period except from one course which I will have to attend. That will require about 7h a week; I will make sure to provide up to 40h/week for GSoC and use the weekends for preparing that course.

I aim to specialize on embedded systems during my studies and regard GSoC as a great opportunity to dive into this topic; I enjoy working on projects I'm interested in and, in these cases, am comfortable with steep learning curves