Difference between revisions of "BeagleBoard/GSoC/SynchronousDataCollectionPRU"

From eLinux.org
Jump to: navigation, search
m (update author information for GSoC 2018)
(add description)
Line 29: Line 29:
  
 
===Description===
 
===Description===
 +
As written in the idea list, the goal of this project is to give [https://github.com/abhishek-kakkar/BeagleLogic/wiki BeagleLogic] the ability to sample Synchronous data.
  
−
====Synopsis====
+
====Synchronous Measurement and Asynchronous Measurement====
−
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.
+
Basically signals are transmitted in two ways: Synchronous transmission and Asynchronous transmission. The current implementation of BeagleLogic samples the input signals in a Asynchronous way. And that could cause a data loss if the sampling rate is not set correctly (referring to Sampling theorem should the sampling rate at least the double frequency of the signal). When one wants to measure a signal of higher speed (>100 MHz, e.g. DDR, PCI), it is not possible to prevent data loss without using Synchronous sampling. In Synchronous sampling mode BeagleLogic would enable the engineer to view actual the signal the devices would receive, which is very useful for software debugging.
  
−
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.
+
====PRU and EGPIO====
 +
[http://beagleboard.org/pru PRU] is the additional component of AM335x, which is intended for offloading real time tasks from the main processor. The main feature of PRU is, that it performs instructions in determined cycles.
  
−
====Project Structure====
+
BeagleLogic [http://theembeddedkitchen.net/beaglelogic-building-a-logic-analyzer-with-the-prus-part-1/449 utilizes] the PRUs on the BeagleBone processor AM3358 to perform high speed measurement, one for sampling data (PRU1), the other for pushing data to DDR RAM (PRU0). As written in the [https://github.com/beagleboard/am335x_pru_package/blob/master/am335xPruReferenceGuide.pdf AM335x PRU-ICSS Reference Guide], PRU has a special type of GPIO, named Enhanced GPIO, whose GPI can work in three mode: Direct Connection Mode and 16-Bit Parallel Capture Mode as well as 28-Bit Shift Mode. The project will allow user to change the GPIO working mode between Direct Connection Mode (for Asynchronous measurement) and 16-Bit Parallel Capture Mode (for Synchronous measurement).
−
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:'''
+
[[File:EGPIO Parallel.png|thumbnail|EGPIO Block Diagram]]
−
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:''':
+
====Implementation====
−
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''':
+
Currently BeagleLogic [https://github.com/abhishek-kakkar/BeagleLogic/blob/3cea157d312a685547a2ca9aa66cefacd1fd2cee/kernel/beaglelogic.c#L1262 loads] firmware to PRUs via [https://www.kernel.org/doc/Documentation/remoteproc.txt Remote Processor Framework]. As already mentioned, BeagleLogic [https://github.com/abhishek-kakkar/BeagleLogic/blob/3cea157d312a685547a2ca9aa66cefacd1fd2cee/firmware/beaglelogic-pru1-core.asm#L60 uses] Direct Connection Mode to perform internal clock triggered sampling. The project should
−
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.
+
 
 +
* update the firmware code of this two PRUs (PASM)
 +
* add a new sysfs attribute in the BeagleLogic kernel module to allowing changing sampling mode (C)
 +
* update test app (C)
 +
* update web backend (Node.js and Go)
 +
* update web app (HTML and javascript)
  
 
===Timeline===
 
===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
+
===Experience and approach===
−
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
+
In 5-15 sentences, convince us you will be able to successfully complete your project in the timeline you have described.
−
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
+
Graduated as bachelor in 2016 for Measurement, Control Technique and Instrumentation at Harbin Institute of Technology, China, I decided to continue my master in Germany. After language courses and tests, I got admitted into TU Darmstadt for Electrical and Computer Engineering (Elektrotechnik und Informationstechnik), which begins at 01. Apr 2018.
−
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
+
I have fundamental knowledge about measurement and instrumentation, including measurement error, sampling theorem, structure of an electrical instrument and so on.
−
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.
 
  
 +
I have experience with ARM (Cortex-M4, Cortex-M0+) and FPGA (Cyclone IV). I can implement DMA or make use of other peripherals from Cortex-M0+ independently.
  
−
Week 7-8:Integrating sigrok libraries
+
I also have experience in [https://github.com/hjhee/HOJ ACM-ICPC] (Gold, 2015, Asia Regional Shanghai Invitational), in which I've improved my ability to code in C. I've written an [https://github.com/hjhee/tiebaSpider crawler] in Go. I also have experience with Node.js and is familiar with [https://github.com/hjhee/gas_fEnd Angular].
−
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
+
I'm good at reading technical document, debugging software and solving hardware problems.
−
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:
+
===Contingency===
−
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===
+
What will you do if you get stuck on your project and your mentor isn’t around?
−
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.
 
−
<br />
 
−
 
 
−
===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===
 
===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:
+
If successfully completed, what will its impact be on the BeagleBoard.org community? Include quotes from BeagleBoard.org community members who can be found on http://beagleboard.org/discuss and http://bbb.io/gsocchat.
−
   
 
−
      Mar 22 17:21:30 <ds2> 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 <ds2> 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 <ServerProcessor> Yes Neo. Synchronous comm helps in error correction which is difficult to
+
===Suggestions===
−
          detect in async comm. Also, there may be data loss at high speeds.
+
Additionally I think the project should also consider utilizing the EDMA controller for data transmission. Because as another GSoC project ([https://elinux.org/BeagleBoard/GSoC/BeagleBone_PRU_DMA BeagleBone PRU DMA]) suggested, this allows PRU0 to perform some logic. For example the user can specify some trigger conditions like: "a falling edge on pin B when pin A is high", or "after 5 rising edges on pin C when pin D is high and pin E is low" and so on. These conditions is originally [http://theembeddedkitchen.net/beaglelogic-building-a-logic-analyzer-with-the-prus-part-1/449 suggested] by the author of BeagleLogic. PRU0 can be used in this situation as a state machine, and only request an Interrupt when the conditions are met.

Revision as of 04:21, 4 March 2018


BeagleBone synchronous data collection

IRC Nick: hjhee
Student: Jianhang He
Mentors: Hunyue Yau , Kumar Abhishek
Code: https://github.com/hjhee/GSoC_SynchronousDataCollectionPRU
Wiki: http://elinux.org/BeagleBoard/GSoC/SynchronousDataCollectionPRU

Status

This project is currently just a proposal.

Proposal

About me

IRC: hjhee
Github: https://github.com/hjhee
School: Technische Universität Darmstadt
Country: Germany
Primary language: Chinese
Typical work hours: 17-22 (CET)

About my project

Project name: BeagleBone-based Synchronous Data Collection

Description

As written in the idea list, the goal of this project is to give BeagleLogic the ability to sample Synchronous data.

Synchronous Measurement and Asynchronous Measurement

Basically signals are transmitted in two ways: Synchronous transmission and Asynchronous transmission. The current implementation of BeagleLogic samples the input signals in a Asynchronous way. And that could cause a data loss if the sampling rate is not set correctly (referring to Sampling theorem should the sampling rate at least the double frequency of the signal). When one wants to measure a signal of higher speed (>100 MHz, e.g. DDR, PCI), it is not possible to prevent data loss without using Synchronous sampling. In Synchronous sampling mode BeagleLogic would enable the engineer to view actual the signal the devices would receive, which is very useful for software debugging.

PRU and EGPIO

PRU is the additional component of AM335x, which is intended for offloading real time tasks from the main processor. The main feature of PRU is, that it performs instructions in determined cycles.

BeagleLogic utilizes the PRUs on the BeagleBone processor AM3358 to perform high speed measurement, one for sampling data (PRU1), the other for pushing data to DDR RAM (PRU0). As written in the AM335x PRU-ICSS Reference Guide, PRU has a special type of GPIO, named Enhanced GPIO, whose GPI can work in three mode: Direct Connection Mode and 16-Bit Parallel Capture Mode as well as 28-Bit Shift Mode. The project will allow user to change the GPIO working mode between Direct Connection Mode (for Asynchronous measurement) and 16-Bit Parallel Capture Mode (for Synchronous measurement).

EGPIO Block Diagram

Implementation

Currently BeagleLogic loads firmware to PRUs via Remote Processor Framework. As already mentioned, BeagleLogic uses Direct Connection Mode to perform internal clock triggered sampling. The project should

  • update the firmware code of this two PRUs (PASM)
  • add a new sysfs attribute in the BeagleLogic kernel module to allowing changing sampling mode (C)
  • update test app (C)
  • update web backend (Node.js and Go)
  • update web app (HTML and javascript)

Timeline

Experience and approach

In 5-15 sentences, convince us you will be able to successfully complete your project in the timeline you have described.

Graduated as bachelor in 2016 for Measurement, Control Technique and Instrumentation at Harbin Institute of Technology, China, I decided to continue my master in Germany. After language courses and tests, I got admitted into TU Darmstadt for Electrical and Computer Engineering (Elektrotechnik und Informationstechnik), which begins at 01. Apr 2018.

I have fundamental knowledge about measurement and instrumentation, including measurement error, sampling theorem, structure of an electrical instrument and so on.

I have experience with ARM (Cortex-M4, Cortex-M0+) and FPGA (Cyclone IV). I can implement DMA or make use of other peripherals from Cortex-M0+ independently.

I also have experience in ACM-ICPC (Gold, 2015, Asia Regional Shanghai Invitational), in which I've improved my ability to code in C. I've written an crawler in Go. I also have experience with Node.js and is familiar with Angular.

I'm good at reading technical document, debugging software and solving hardware problems.

Contingency

What will you do if you get stuck on your project and your mentor isn’t around?

Benefit

If successfully completed, what will its impact be on the BeagleBoard.org community? Include quotes from BeagleBoard.org community members who can be found on http://beagleboard.org/discuss and http://bbb.io/gsocchat.

Suggestions

Additionally I think the project should also consider utilizing the EDMA controller for data transmission. Because as another GSoC project (BeagleBone PRU DMA) suggested, this allows PRU0 to perform some logic. For example the user can specify some trigger conditions like: "a falling edge on pin B when pin A is high", or "after 5 rising edges on pin C when pin D is high and pin E is low" and so on. These conditions is originally suggested by the author of BeagleLogic. PRU0 can be used in this situation as a state machine, and only request an Interrupt when the conditions are met.

Retrieved from "https://elinux.org/index.php?title=BeagleBoard/GSoC/SynchronousDataCollectionPRU&oldid=462841"