Difference between revisions of "BeagleBoard/GSoC/SynchronousDataCollectionPRU"
| Line 43: | Line 43: | ||
====Project Structure==== | ====Project Structure==== | ||
| − | The project can be divided into | + | The project can be divided into 4 main phasesr |
| − | + | *'''PRU Core:''' | |
| − | *'''PRU Core''' for | + | 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. |
| − | + | ||
| − | + | *'''Kernel Drivers:''' | |
| − | *''' | + | 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. |
| − | + | ||
| − | + | *'''Sigrok Bindings:''': | |
| − | + | 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. | |
| − | + | ||
| − | + | *'''JSON bindings & HTML Interface''': | |
| − | + | Provides the web interface and other applications with an HTML interface. This is the part where the end user can view the data and select number of samples. | |
| − | |||
===Timeline=== | ===Timeline=== | ||
Revision as of 06:47, 3 April 2017
Contents
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 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
I made a [1] 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)
Linkedin:https://www.linkedin.com/in/nishant-pani-b910b8b2/?locale=en_US
About my project
Project name: BeagleBone-based Synchronous Data Collection
Description
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
- PRU Core:
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.
- Kernel Drivers:
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.
- Sigrok Bindings::
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.
- JSON bindings & HTML Interface:
Provides the web interface and other applications with an HTML interface. This is the part where the end user can view the data and select number of samples.
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. 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
This project is divided into three 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:
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
