Difference between revisions of "User:Hjhee/GSoC2018"

From eLinux.org
Jump to: navigation, search
(delete page)
(Tag: Blanking)
Line 1: Line 1:
[[Category: BeagleBoard]]
[[Category: GSoC]]
[[Category: GSoCProposal]]
=BeagleBone synchronous data collection=
''IRC Nick'': hjhee<br>
''Student'': [http://elinux.org/User:Hjhee Jianhang He]<br>
''Mentors'': Hunyue Yau, Kumar Abhishek<br>
''Code'': https://github.com/hjhee/GSoC_SynchronousDataCollectionPRU<br>
''Wiki'': http://elinux.org/BeagleBoard/GSoC/SynchronousDataCollectionPRU<br>
<div style="clear:both;"></div>
This project is currently just a proposal.
==About me==
''IRC'': hjhee<br>
''Github'': https://github.com/hjhee<br>
''School'': [https://www.tu-darmstadt.de/ Technische Universität Darmstadt]<br>
''Country'': Germany<br>
''Primary language'': Chinese<br>
''Typical work hours'': 17-22 (CET)
==About my project==
''Project name'': BeagleBone-based Synchronous Data Collection<br>
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 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 received the devices, which is very useful for software debugging.
====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.
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).
[[File:EGPIO Parallel.png|thumbnail|EGPIO Block Diagram]]
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
* 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)
====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 Synchronous 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
* set up development environment for Linux kernel
====Week 7====
* review code and comment
* write development notes
* update the code of the example app
* buffer week
====Week 8-10====
* adding new API for web server
* tcp-server-go
* tcp-server-node
* update web interface
====Week 11====
* receive feedback
* review documentation
====Week 12====
* buffer week
===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 [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 am familiar with [https://github.com/hjhee/gas_fEnd 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 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.
BeagleLogic users will have an alternative sampling mode. The community will have one more example about PRU development. The PRU is very powerful and should deserve more attention from the community.
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.

Latest revision as of 07:45, 11 April 2021