BeagleBoard/GSoC/SynchronousDataCollectionPRU
Contents
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.
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
