Difference between revisions of "BeagleBoard/GSoC/SynchronousDataCollectionPRU"

From eLinux.org
Jump to: navigation, search
m (Experience and approach: add Experience)
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
 
[[Category: BeagleBoard]]
 
[[Category: BeagleBoard]]
 
[[Category: GSoC]]
 
[[Category: GSoC]]
Line 5: Line 4:
  
 
=BeagleBone synchronous data collection=
 
=BeagleBone synchronous data collection=
<!--{{#ev:youtube|Jl3sUq2WwcY||right|BeagleLogic}}  latest video will go here -->
+
''IRC Nick'': hjhee<br>
 
+
''Student'': [http://elinux.org/User:Hjhee Jianhang He]<br>
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.
+
''Mentors'': Hunyue Yau, Kumar Abhishek<br>
 
+
''Code'': https://github.com/hjhee/GSoC_SynchronousDataCollectionPRU<br>
''Student'': [http://elinux.org/User:NP95 Nishant Pani]<br>
 
''Mentors'': [http://elinux.org/User:ds2 Hunyue Yau ]<br>
 
''Code'': https://github.com/NP95/SyncData<br>
 
 
''Wiki'': http://elinux.org/BeagleBoard/GSoC/SynchronousDataCollectionPRU<br>
 
''Wiki'': http://elinux.org/BeagleBoard/GSoC/SynchronousDataCollectionPRU<br>
''GSoC'': [GSoC entry]<br>
 
 
<div style="clear:both;"></div>
 
<div style="clear:both;"></div>
  
 
=Status=
 
=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
+
This project is currently just a proposal.
https://github.com/jadonk/gsoc-application/pull/87 and the have outlined my plans for the project.
 
  
 
=Proposal=
 
=Proposal=
I made a [https://github.com/jadonk/gsoc-application/pull/87] to the gsoc-application repo
 
  
 
==About me==
 
==About me==
''IRC'': NP95<br>
+
''IRC'': hjhee<br>
''Github'':https://github.com/NP95<br>
+
''Github'': https://github.com/hjhee<br>
''School'': Birla Institute of Technology and Science,Pilani Hyderabad Campus ([http://www.bits-pilani.ac.in/hyderabad/ BPHC])<br>
+
''School'': [https://www.tu-darmstadt.de/ Technische Universität Darmstadt]<br>
''Country'': India<br>
+
''Country'': Germany<br>
''Primary language'': English,Hindi<br>
+
''Primary language'': Chinese<br>
''Typical work hours'': 9 AM - 5 PM(IST)<br>
+
''Typical work hours'': 17-22 (CET)
''Linkedin'':https://www.linkedin.com/in/nishant-pani-b910b8b2/?locale=en_US
 
  
 
==About my project==
 
==About my project==
Line 36: Line 28:
  
 
===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.
 +
 +
====Synchronous Measurement====
 +
Basically signals are transmitted in two ways: Synchronously and Asynchronously. With Synchronous transmission a clock signal indicates the correct time to read the values. The current implementation of BeagleLogic samples the input signals without respect to external clock signal. And that could cause a data loss if the sampling rate does not meet the Nyquist–Shannon sampling theorem (at least twice the frequency of the signal). When one wants to measure a signal of higher frequency (up to [http://standalone.beaglelogic.net/en/latest/logic_inputs.html 100 MHz], e.g. DDR, PCI, USB), it is not possible to prevent data loss without using Synchronous sampling. In Synchronous sampling mode BeagleLogic would enable the engineer to view the actual signal received the devices, which is very useful for protocol analysis.
 +
 +
The project will use BeagleLogic as the development/testing platform.
 +
 +
  Mar 05 10:01:28 <Abhishek_> The standalone version of BeagleLogic board has hardware support for the 17th pin of PRU input - the CLK pin. I'd be happy to ship a board to the selected student if the project is approved.
 +
 +
====Programmable Real-time Unit====
 +
In order to perform measurement without being disrupted by operating system, BeagleBone used the on board Programmable Real-time Unit to execute the program. [http://beagleboard.org/pru PRU] is an additional component of AM335x, which is intended for offloading real time tasks from the main processor. The main feature of PRU is, that all instructions can be finished in determined cycles. Furthermore PRU has direct access to peripheral, including GPIO.
  
====Synopsis====
+
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 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.
+
The project will allow user to switch the GPIO working mode between Direct Connection Mode (Asynchronous measurement) and 16-Bit Parallel Capture Mode (Synchronous measurement). Additionally the user can decide whether capture data on clock rising edge or falling edge.
  
====Project Structure====
+
[[File:EGPIO Parallel.png|thumbnail|EGPIO Block Diagram]]
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:'''
+
===Implementation===
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.
+
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, PRU1 [https://github.com/abhishek-kakkar/BeagleLogic/blob/3cea157d312a685547a2ca9aa66cefacd1fd2cee/firmware/beaglelogic-pru1-core.asm#L60 uses] reads data from GPI in Direct Connection Mode. The sampling process is a loop written in PASM:
  
*'''Sigrok Bindings:''':
+
1. setup gpio-related cfg register
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''':  
+
2. setup dst pointer
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.
+
 
 +
3. setup loop-related registers
 +
 
 +
4. loop reading pins once triggered
 +
 
 +
The project should modify <code>beaglelogic-pru1-core.asm</code> to setup cfg register based on user configuration (for example: GPI working mode). The firmware has both asm and C code for the two PRUs, and the project may further free PRU0 from data transferring by using DMA (see suggestion 1) in order to perform some logic like triggered start/stop, Mealy state machine as parallel->serial conversion. Configuration for sampling is set through sysfs attributes and thus the project should update C code related to kernel module. Test app should be updated to demonstrate the usage of newly added sysfs attributes. User should also be able to set/get sysfs attributes via tcp socket so the code of web server and web app should be reviewed. As written in suggestion 2, it is also considerable to implement PTP 1588 protocol for synchronous sampling. In summary:
 +
 
 +
* update the firmware code of this two PRUs (PASM)
 +
* add new sysfs attributes in the BeagleLogic kernel module for sampling configuration (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
+
The project has a loose timeline and leaves some time for implementing functions from suggestions.
  
Week 1:Capturing the Clock Signal
+
====Week 1====
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.
+
* Familiar with BeagleBone board and read datasheet
 +
* get the knowledge about registers of Cortex-A and PRUs
 +
* write testing programs for Cortex-A
  
Week 2:Capturing the External Signal in sync with the clock
+
====Week 2====
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.
+
* Familiar with PRU and read the manual
 +
* measure cycles of instructions of interes
 +
* design Synchronous sampling procedure
  
Week 3:Completing the PRU core
+
====Week 3-4====
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.
+
* implement clock triggered sampling in assembly code and C
 +
* test the program by feeding testing signals
  
Week 4-6 :Kernel Drivers
+
====Week 5-6====
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.
+
* Familiar with Linux kernel module development
 +
* understand the detail about Remote Processor Framework
 +
* add new attributes to module
  
 +
====Week 7====
 +
* review code and comment
 +
* write development notes
 +
* update the code of the example app
 +
* buffer week for DMA implementation
  
Week 7-8:Integrating sigrok libraries
+
====Week 8-10====
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.
+
* update web server
 +
* update web interface
 +
* buffer week for DMA implementation
 +
* buffer week for PTP implementation
  
Week 9-10: UI Integration
+
====Week 11====
A new UI will not be needed, we can extend the existing UI of beaglelogic
+
* receive feedback
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.
+
* review documentation
 +
* buffer week for PTP implementation
  
Weeks 11-12:
+
====Week 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.
+
* buffer week for entire project
  
 
===Experience and approach===
 
===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.
+
Graduated as bachelor in 2016 for Measurement, Control Technique and Instrumentation at Harbin Institute of Technology, China, I decided to continue my master at TU Darmstadt for Electrical and Computer Engineering (Elektrotechnik und Informationstechnik), Germany.
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.
+
I have fundamental knowledge about measurement and instrumentation, including measurement error, sampling theorem, structure of an electrical instrument and so on.
<br />
+
 
 +
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 [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've recently implemented a CoAP as well as HTTP server for an GIS System dealing with time series using Go and mongodb. I also have experience with Node.js and am familiar with Angular.
 +
 
 +
I'm good at reading technical document, debugging software and solving hardware problems. I'm familiar with Linux since 2007, including Ubuntu, Gentoo, Debian.
 +
 
 +
There are 3 major parts in this project: firmware programming, kernel module programming and web programming. I may reuse the existing code to speed up firmware and kernel module development.
 +
 
 +
  Mar 05 10:32:57 <zeekhuge> Abhishek_: ah, so are we focusing the "synchronous data" as only an addition to BeagleLogic ? or will it be more like a standard generic re-usable module ?
 +
  Mar 05 10:45:05 <Abhishek_> It can go both ways. If it's built as an extension of BeagleLogic, it can leverage the work already done there and the kernel driver.
 +
 
 +
The size of web server is not large and is easy to understand, so modify the code and add new options to the user is not a big problem. It may take some time to figure out the code from web app as I'm not familiar with these JavaScript libraries: WaveDrom, LargeLocalStorage, Q, and bower. However my task is based on the existing code so I have some reference.
  
 
===Contingency===
 
===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.
+
There is enough documents for independent development, including AM3358, PRU-ICSS, rpmsg, Linux kernel module, etc. I think I can find the solution on the Internet. Another possible way is to ask question on IRC, which may get respond slower.
 +
 
 +
Maybe I should get stuck in writing HTML/JavaScript code, so I leave some more time in the timeline. And when there is no enough time I would give up the suggestion parts and keep pace with the plan.
  
 
===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.
+
BeagleLogic users will have an alternative sampling mode. The community will have one more example about PRU development and references on remoteproc/firmware and EGPIO/peripheral. The PRU is very powerful and should deserve more attention from the community.
 +
 
 +
===Suggestions===
 +
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 operation. 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 act in this situation as a state machine, and only request an Interrupt to EDMA when the conditions are met. PRU0 may also run a Mealy machine, fed by external data, undertake protocol conversion, and transfer output using GPIO. One basic example for this is that BeagleLogic may transfer the sampled signal to other devices for further usage via serial. In this situation PRU0 is a parallel->serial converter.
 +
 
 +
Another interpretation of "Synchronous Data Collection" is to perform Synchronous Measurement with other instruments. In this situation BeagleLogic should implement [https://en.wikipedia.org/wiki/Precision_Time_Protocol IEEE 1588 protocol] to achieve accurate time triggered measurement. In other words, all instruments should perform measurement at a specified time. BeagleLogic is triggered by internal timer, set by Host via LAN. It is a kind of LAN-based Synchronous Data Collection. One should refer [https://en.wikipedia.org/wiki/LAN_eXtensions_for_Instrumentation LAN eXtensions for Instrumentation] for further information. One may furthermore wants to adapt LXI protocol to BeagleLogic. But one should also consider the limitations of BeagleLogic, both hardware and software, and check if it can be stated that BeagleLogic is LXI compliant. There my be not possible to get hardware timestamped packet and thus time precision suffers.
  
Quotes from the community IRC:
+
  Mar 12 08:09:27 <hjhee> ds2: any comment on implementing PTP 1588 for synchronous data collection?
 +
  Mar 12 16:05:38 <ds2> hjhee: the PRU has HW for that stuff but the pins aren't brought out, IIRC

Latest revision as of 12:00, 18 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

Basically signals are transmitted in two ways: Synchronously and Asynchronously. With Synchronous transmission a clock signal indicates the correct time to read the values. The current implementation of BeagleLogic samples the input signals without respect to external clock signal. And that could cause a data loss if the sampling rate does not meet the Nyquist–Shannon sampling theorem (at least twice the frequency of the signal). When one wants to measure a signal of higher frequency (up to 100 MHz, e.g. DDR, PCI, USB), it is not possible to prevent data loss without using Synchronous sampling. In Synchronous sampling mode BeagleLogic would enable the engineer to view the actual signal received the devices, which is very useful for protocol analysis.

The project will use BeagleLogic as the development/testing platform.

 Mar 05 10:01:28 <Abhishek_> The standalone version of BeagleLogic board has hardware support for the 17th pin of PRU input - the CLK pin. I'd be happy to ship a board to the selected student if the project is approved.

Programmable Real-time Unit

In order to perform measurement without being disrupted by operating system, BeagleBone used the on board Programmable Real-time Unit to execute the program. PRU is an additional component of AM335x, which is intended for offloading real time tasks from the main processor. The main feature of PRU is, that all instructions can be finished in determined cycles. Furthermore PRU has direct access to peripheral, including GPIO.

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 switch the GPIO working mode between Direct Connection Mode (Asynchronous measurement) and 16-Bit Parallel Capture Mode (Synchronous measurement). Additionally the user can decide whether capture data on clock rising edge or falling edge.

EGPIO Block Diagram

Implementation

Currently BeagleLogic loads firmware to PRUs via Remote Processor Framework. As already mentioned, PRU1 uses reads data from GPI in Direct Connection Mode. The sampling process is a loop written in PASM:

1. setup gpio-related cfg register

2. setup dst pointer

3. setup loop-related registers

4. loop reading pins once triggered

The project should modify beaglelogic-pru1-core.asm to setup cfg register based on user configuration (for example: GPI working mode). The firmware has both asm and C code for the two PRUs, and the project may further free PRU0 from data transferring by using DMA (see suggestion 1) in order to perform some logic like triggered start/stop, Mealy state machine as parallel->serial conversion. Configuration for sampling is set through sysfs attributes and thus the project should update C code related to kernel module. Test app should be updated to demonstrate the usage of newly added sysfs attributes. User should also be able to set/get sysfs attributes via tcp socket so the code of web server and web app should be reviewed. As written in suggestion 2, it is also considerable to implement PTP 1588 protocol for synchronous sampling. In summary:

  • update the firmware code of this two PRUs (PASM)
  • add new sysfs attributes in the BeagleLogic kernel module for sampling configuration (C)
  • update test app (C)
  • update web backend (Node.js and Go)
  • update web app (HTML and javascript)

Timeline

The project has a loose timeline and leaves some time for implementing functions from suggestions.

Week 1

  • Familiar with BeagleBone board and read datasheet
  • get the knowledge about registers of Cortex-A and PRUs
  • write testing programs for Cortex-A

Week 2

  • Familiar with PRU and read the manual
  • measure cycles of instructions of interes
  • design Synchronous sampling procedure

Week 3-4

  • implement clock triggered sampling in assembly code and C
  • test the program by feeding testing signals

Week 5-6

  • Familiar with Linux kernel module development
  • understand the detail about Remote Processor Framework
  • add new attributes to module

Week 7

  • review code and comment
  • write development notes
  • update the code of the example app
  • buffer week for DMA implementation

Week 8-10

  • update web server
  • update web interface
  • buffer week for DMA implementation
  • buffer week for PTP implementation

Week 11

  • receive feedback
  • review documentation
  • buffer week for PTP implementation

Week 12

  • buffer week for entire project

Experience and approach

Graduated as bachelor in 2016 for Measurement, Control Technique and Instrumentation at Harbin Institute of Technology, China, I decided to continue my master at TU Darmstadt for Electrical and Computer Engineering (Elektrotechnik und Informationstechnik), Germany.

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've recently implemented a CoAP as well as HTTP server for an GIS System dealing with time series using Go and mongodb. I also have experience with Node.js and am familiar with Angular.

I'm good at reading technical document, debugging software and solving hardware problems. I'm familiar with Linux since 2007, including Ubuntu, Gentoo, Debian.

There are 3 major parts in this project: firmware programming, kernel module programming and web programming. I may reuse the existing code to speed up firmware and kernel module development.

 Mar 05 10:32:57 <zeekhuge> Abhishek_: ah, so are we focusing the "synchronous data" as only an addition to BeagleLogic ? or will it be more like a standard generic re-usable module ?
 Mar 05 10:45:05 <Abhishek_> It can go both ways. If it's built as an extension of BeagleLogic, it can leverage the work already done there and the kernel driver.

The size of web server is not large and is easy to understand, so modify the code and add new options to the user is not a big problem. It may take some time to figure out the code from web app as I'm not familiar with these JavaScript libraries: WaveDrom, LargeLocalStorage, Q, and bower. However my task is based on the existing code so I have some reference.

Contingency

There is enough documents for independent development, including AM3358, PRU-ICSS, rpmsg, Linux kernel module, etc. I think I can find the solution on the Internet. Another possible way is to ask question on IRC, which may get respond slower.

Maybe I should get stuck in writing HTML/JavaScript code, so I leave some more time in the timeline. And when there is no enough time I would give up the suggestion parts and keep pace with the plan.

Benefit

BeagleLogic users will have an alternative sampling mode. The community will have one more example about PRU development and references on remoteproc/firmware and EGPIO/peripheral. The PRU is very powerful and should deserve more attention from the community.

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 operation. 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 act in this situation as a state machine, and only request an Interrupt to EDMA when the conditions are met. PRU0 may also run a Mealy machine, fed by external data, undertake protocol conversion, and transfer output using GPIO. One basic example for this is that BeagleLogic may transfer the sampled signal to other devices for further usage via serial. In this situation PRU0 is a parallel->serial converter.

Another interpretation of "Synchronous Data Collection" is to perform Synchronous Measurement with other instruments. In this situation BeagleLogic should implement IEEE 1588 protocol to achieve accurate time triggered measurement. In other words, all instruments should perform measurement at a specified time. BeagleLogic is triggered by internal timer, set by Host via LAN. It is a kind of LAN-based Synchronous Data Collection. One should refer LAN eXtensions for Instrumentation for further information. One may furthermore wants to adapt LXI protocol to BeagleLogic. But one should also consider the limitations of BeagleLogic, both hardware and software, and check if it can be stated that BeagleLogic is LXI compliant. There my be not possible to get hardware timestamped packet and thus time precision suffers.

 Mar 12 08:09:27 <hjhee> ds2: any comment on implementing PTP 1588 for synchronous data collection?
 Mar 12 16:05:38 <ds2> hjhee: the PRU has HW for that stuff but the pins aren't brought out, IIRC