PRU Bridge : Weekly Progress Reports

[Apaar Gupta]

Week 1 :

What has been achieved:

• Introductory video,blog and github repo up.Links here
• Basic driver working including
• glue code
• exposing sysfs to userspace
• figured out/implemented access of DRAM shared memory in the pru
• DTS and test firmware running.
  

Issues:

• Base address for shared memory took some effort to find.
• Accessing the memory needed i/o mapping,lost some time figuring it out.

Weekly Goals(next week)

• Implement circular buffers in shared memory in a day or two.
• Figure out and implement writing to a sysfs file from the driver and exporting of interrupts from PRU->ARM to allow for PRU->ARM data transfer.
• Define control channel's contents and functioning/algo to enable efficient data transfer

Regards,

Apaar Gupta

[Apaar Gupta]

Week 2 :

What has been achieved:

• Sysfs read/write(show/store) implemented for a single channel.
• Creation of circular buffers in shared memory.
• Basic skeleton firmware written(not tested)

Code can be found the github repo and am hoping to start updating every two days instead of once in a week :)

Issues:

• A beaglebone fell from my table brutally ripping its mini-USB port out.Had to replace the port and get it soldered.(it works now :)

Weekly Goals(next week)

• Get circular buffers read/write from firmware running(the code need to be tested)
• Define and implement control channel
• Discuss number of channels and size of each channel

Regards,

Apaar Gupta

[Apaar Gupta]

Week 3 :

What has been achieved:

• Control channel implemented and tested
• Variable buffer size implemented but the size must be multiples of 4
• Multiple channel support provided(5 channels for now just incrementing a macro and adding a sysfs handler will add a channel)

Code can be found here

Issues:

• ARM only allows ioremap of physical addresses which are multiples of 4.Took some effort to figure that out.
• Realtime nature of the pru shared memory being used by both the driver and pru may impeded by blocking nature of memory access/write.
• Failed at updating repo every two days :P

Weekly Goals(next week)

• Extensive testing of the drive and firmware for performance and bugs.
• Develop and implement a algorithm to make memory access hard realtime if not ensure at least soft realtime.
• Possibly update readme/wiki

Regards,

Apaar Gupta

[Apaar Gupta]

Week 4 :

What has been achieved:

• Channels now carry integers instead of characters.
• Checks in read to read only if data is available in both pru and driver
• Code commented and readme updated
• Userspace c api basic work done needs a little cleaning up

Code can be found here

Issues:

• Realized a bit late that a basic api will have to be written before testing can start
• Realtime issue still not solved due to lack of documentation regarding PRU->pru shared memory buffering(check week 3). ds2 has recommended that we test performance and proceed accordingly.

Weekly Goals(next week)

• Testing continues. Benchmarking realtime performance by using dummy data 
• Finish Userspace C API 

Regards,

Apaar Gupta

[Apaar Gupta]

Week 5 :

What has been achieved:

• Channels are now byte oriented ie you can different datatypes.
• Code refactored to get rid of pointers in the channel headers as it was a pain to debug and glitchy
• There is now no need to re-initialize the pru instances of the structures carrying data.
• Userspace c api done

Code can be found here

Issues:

• Constant messing up the buffer pointer in each channel led me to spend a bit abolishing them and replacing them with a array but maintaining the variable size of channels.

Weekly Goals(next week)

• Testing continues. 
• Python userspace API to be done

Regards,

Apaar Gupta

[Apaar Gupta]

Week 6 :

What has been achieved:

• C API and firmware tested for stream and one-off data transfer.
• Basic python api done(will commit after testing a bit)
• License updated

Issues:

• Had forgotten to put checks on the buffer counters(head,tail,index_data) in the driver so they were going into int overflow in some cases of bad init or large data :P

Weekly Goals(next week)

• Complete python API
• Evaluating the speed of data transfer
• Write example codes for multiple use cases utilising both the c and python api's

Regards,

Apaar Gupta

[Apaar Gupta]

Week 7 :

(Got the week number wrong in the last post)

What has been achieved:

• Python API working
• Read up on testing transfer speeds

Issues:

• Fell ill.Was down for 4-5 days with mild conjunctivitis and fever.Am better now :)
• There is some issue with the multiple reads from a file in the c api that needs solving(rewind did not seem to solve it)

Weekly Goals(next week)

• Evaluating the speed of data transfer(pending from last week)
• Need to implement checks for data/input sanity
• Investigate possible applications of PRU-Bridge

Regards,

Apaar Gupta

On Wednesday, July 15, 2015 at 7:24:57 PM UTC+5:30, Apaar Gupta wrote:

Week 6 :

What has been achieved:

• Python API working
• Read up on testing transfer speeds

Issues:

• Fell ill.Was down for 4-5 days with mild conjunctivitis and fever.Am better now :)
• There is some issue with the multiple reads from a file in the c api that needs solving(rewind did not seem to solve it)

Weekly Goals(next week)

• Evaluating the speed of data transfer(pending from last week)
• Need to implement checks for data/input sanity
• Investigate possible applications of PRU-Bridge

Regards,

Apaar Gupta

[Apaar Gupta]

Week 8 :

What has been achieved:

• Implemented some checks for data sanity
• More examples created
• Some major bug fixes(look in issues)
• Benchmarking ongoing(i am mostly done for single byte lossless data transfer from pru->arm)

Issues:

• The write sysfs handler was returning strlen(buf).But when a zero was passed it considered that as a empty buffer and returned 0 ,placing the sysfs handler in a retry infinite loop.
• Multiple successive reads in C Library were failing for 4 bytes upwards. fflush was needed to clean the buffers(i am not to sure of the reason)

Weekly Goals(next week)

• Finish benchmarking (this has dragged on due to the issues)
• Python API needs upgrades :P
• Start with applications

Regards,

Apaar Gupta

[Apaar Gupta]

Week 9 :

What has been achieved:

• Benchmarking mostly done
• Channel numbers increased and read in channels 9 and 10 flush the entire buffer in one go(theoretically to do away with the multiple syscalls for larger types thus reducing time taken per byte).
• Python API upgraded from single byte only to larger sizes
• Investigated/understood codebase for applications like porting PRU Speak

Benchmarking results : 

Driver Side using the C Library : This is for writing and reading

• One byte at a time without printk logs in the driver : 12-15 μs per byte
• One byte at a time with printk in driver : ~20 - 25 μs per byte
• Four bytes(uint32_t) at a time without printk logs  : 36-52 μs or 9-13 μs per byte
• 16 bytes(4 element integer array) at a time without printk logs : 97-114 μs or 6-7.2 μs per byte
• The channels 9/10 flush the entire buffer in one go(tested for 100,500 and 1000 bytes at a time) : ~5-7 μs per byte(only for reads and need more working on)

PRU-Bridge firmware library

• Four bytes per write : 352 clock cycles = 0.44 μs per byte but this is including cycles for calculating number of clock ticks between each write (code here) 
• Did basic testing for jitter. Ran a code for the pru to continuously write and driver reading simultaneously for a while and there seems to be no jitter on pru side :)

Issues:

• Wrong base address resulted in a time lost and feeling extremely stupid once the issue was resolved(Issue found thanks to Abhishek :)
• Will be moving to hostel soon ,will be busy shifting for a bit and internet will be quite bad

Weekly Goals(next week)

• Porting PRU-Spreak and investigation further applications
• Code clean up currently there is limited documentation and licenses need to be added to the newer stuff

Regards,

Apaar Gupta

[Apaar Gupta]

Week 10 :

What has been achieved:

• Optimization of pru firmware - reduced 4 byte write cycles from 352 cycles to 192 cycles to write a 32 bit integer .This includes cycles taken for obtaining number of clock ticks and calculating time delay.
• More intensive testing 2MB of data sent both ways in chunks of 1 byte,4 byte and 16 byte
• Code clean up and shell scripts to install and run

Issues:

• Moving to hostel took 2-3 days and took a while to set up the internet(my hostel has no lan/wifi network)

Weekly Goals(next week)

• Porting PRU-Spreak and possible implementation of RPC 
• Python API read needs to be made multiple bytes at a time

Regards,

Apaar Gupta

[Apaar Gupta]

Week 11:

What has been achieved:

• PRU-Speak Userspace ported to PRU Bridge and tested
• Licences and little documentation added
• Very slight firmware performance upgrade from 192 cycles to 188 cycles :P

Issues:

• Pruspeak code took a little while to fully understand firmware port is half done but still broken

Weekly Goals(next week)

• Finish pru_speak port 
• Add more documentation and comments

Regards,

Apaar Gupta

[Apaar Gupta]

Week 12:

What has been achieved:

• PRU-Speak ported to PRU Bridge currently testing.
• Licences ,documentation and readme added
• Converting pru_bridge to a plugin driver ongoing

Weekly Goals(next week)

• Test conversion to plugin driver and the pruspeak port
• Final wrap up for code submission

Regards,

Apaar Gupta

[Apaar Gupta]

Final Report:

Aim : The aim of this project is to create a generic, multi channel bridge between userspace Linux and PRU, allowing developers to send and receive data seamlessly between ARM and PRU via creation of plugin driver.

What has been achieved in the GSoC Timeframe:

• PRU-Bridge driver coded and tested.It allows for passing of type agnostic data(data is passes byte by byte) via sysfs files to the PRU shared memory.
• The driver allows for creation up to 10 uni-directional channels of variable size(max size 11500 bytes)
• Userspace libraries in Python and C allow for extremely easy utilization of PRU-Bridge to pass data(Library details in readme)
• PRU side library allows for realtime data transfer at a performance of ~30 cycles a write(it gets better as the size of data being passed increases)
• Code is decently documented and the readme updated
• PRU-Speak ported testing shows that the port seems to break in some cases still working on that one

I have learned a lot while working on this project tried to accomplish as much as i could during the GSoC coding period.Some areas like creation of more example apps/programs and porting the new pruss framework will be worked on after GSoC as in the proposal. Code repository can be found here.

I would like to thank Alexanderhiam ,ds2, Karki,Abhishek and the rest of the community for helping me with the rather interesting albeit at times stupid errors and issues i faced :P and for their support.This experience has been extremely insightful and enjoyable and i would love to continue enhancing/improving PRU-Bridge and contributing to the Beagleboard community :) 

Regards,

Apaar Gupta