BeagleBoard/GSoC/SynchronousDataCollectionPRU

=BeagleBone synchronous data collection=

IRC Nick:NP95(Initially was Neo1995) Student: Nishant Pani Mentors: Hunyue Yau,Kumar Abhishek Code: https://github.com/NP95/SyncData Wiki: http://elinux.org/BeagleBoard/GSoC/SynchronousDataCollectionPRU

=Status= This project is currently just a proposal. I have done the basic preliminary tasks asked for applying to the project, the cross compiled Hello World program https://github.com/jadonk/gsoc-application/pull/87 and the have outlined my plans for the project.

=Proposal=

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) Linkedin:https://www.linkedin.com/in/nishant-pani-b910b8b2/?locale=en_US

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 4 main phasesr PRUs stands for Programmable Real-time Units it is low‐latency microcontroller subsystem. There are two independent PRU execution units with specifications of a custom 32‐Bit RISC architecture, 200Mhz single cycle execution,no pipeline. This means there is no unpredictability on the latencies. The PRU core will perform the task of sampling the clock signal and then sampling the external signal in tune with the clock signal. The code for this will be written in PRU Assembly.
 * PRU Core:

Since the PRU are treated as external periperhals to the ARM Cortex CPU of the Beaglebone, we would require kernel drivers to communicate with the PRU and collect the sampled data into the userspace for processing and display. This will be written in C.
 * Kernel Drivers:

The data collected by the kernel modules is to be processsed by sigrok-cli which processes the data into format which can be displayed on UI. This data will be sent to a node.js app which will act as the interface between the processed signal data and the display UI.
 * Sigrok Bindings::

Provides the web interface and other applications with an HTML interface. This is the part where the end user can view the captured data in form of waveforms and select number of samples.
 * JSON bindings & HTML Interface:

Timeline
Provide a development timeline with a milestone each of the 11 weeks. (A realistic timeline is critical to our selection process.) This is a rough timeline of the project, these are not meant to be strictly adhered but more of a guideline

Week 1:Capturing the Clock Signal This week would be spent in writing the PRU Assembly code to capture the clock signal as accurately as possible. For this is the basis of capturing the external synchronous signal.This would be captured asynchronously as in Beaglelogic, so the sampling code from beaglelogic will be useful here as a reference.

Week 2:Capturing the External Signal in sync with the clock The core of this project, capturing the synchronous signal in sync with the clock signal which has been captured. The actual details on how this will be done will be finalized in the community bonding period. This would be completely written from scratch in PRU Assembly.

Week 3:Completing the PRU core This week will be spent in testing and debugging the PRU core, that it works as intended here. Depending on how quickly I able to get it up and running in this week, I can start working on the kernel drivers.

Week 4-6 :Kernel Drivers The kernel drivers from beaglelogic will be reused for this phase.Individual breakup of weeks will come after discussion with mentors and completing the PRU core. The main purpose of the Kernel Drivers is to take the data captured in the first phase of the project and take it to userspace for processing and displaying on the front end.

Week 7-8:Integrating sigrok libraries After collecting the data,it is important to decode it in a manner amenable to displaying it on the front end, for this the best tool are the sigrok libraries. Existing beaglelogic code will be leveraged for this.

Week 9-10: UI Integration A new UI will not be needed, we can extend the existing UI of beaglelogic The main extensions will be adding an option for synchronous data collection and giving the user for the number of samples that can be captured,particularly in the sampling of the clock signal. Some other useful extensions will include placing marker on the displayed waveforms.

Weeks 11-12: Final wrapup including documentation(how it works and how to use it) and putting it as a tarball so that it can be installed into the system by a package manager. Regarding documentation,the plan is actually to properly document the work of each week and how to use it and integrate it into the final documentation.

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. Currently I am interning at GE, however my internship will wind down by mid June, with my workload almost negligible in the end, so it is not going to prevent me from dedicating sufficient time to this project. I will also 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
This project is divided into four phases. If at any phase I get stuck ,my first response will be to look into the documentation and find a link between what I know and what is needed to fix the issue,and my if mentors are not available, I will consult the community even if they may not know how to solve the specific issues, they would be valuable in pointing in me in the right direction.

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.

Quotes from the community IRC: Mar 22 17:21:30 with sync capture, you get the data as intended what Beaglelogic does is sample thing so it has to run faster to avoid aliasing... it gives slightly different info Mar 22 17:23:39 so if you capture it synchronously,you can potentially run slower,say a claim of 25MHz can look at a 25MHz signal...whereas an async capture would need to run faster then 50MHz to see the ame signal

Mar 01 13:53:37  Yes Neo. Synchronous comm helps in error correction which is difficult to          detect in async comm. Also, there may be data loss at high speeds.