This is a Week 0 report for GSoC2020 project Parallel Bidirectional Bus my mentors for the project are Jason Kridner,KumarAbhishek,Saketh, Drew Fustini, Hunyue Yau and , rma. I will publish all my weekly reports through this thread,
I have also created a blog website for progress tracking and for posting .Also some blog posts explaining how to do some important stuff can be seen on Blog posts
Accomplishments:
Installed PRU-GCC , compiled simple codes that run on PRU and worked with remoteproc to load firmware
Resolved installation issues with Beaglelogic and set it up to view communication with shift registers
Wrote simple character driver to understand the intricacies
Went through gpio chip driver.
Resolutions to blockers:
N/A
On-going blockers:
When i connect my Pocketbeagle and Beaglebone wireless with my Laptop at the same time , i can only log in one of them. The issue is because on both the boards the usb interfaces are assigned same IP address. I need to figureout a way to solve this as i would be using beaglelogic on my beaglewireless to analyse communication between PRU of pocketbeagle and shift registers
Plans for the next week:
Introductory YouTube video.
Writing simple gpio drivers
Understanding more about PRU and writing code for 74hc595
This is a Week 1 report for GSoC2020 project Parallel Bidirectional Bus. My approach is to move a little from both the ends ie the PRU code and GPIO chip driver and then finally connect both the parts.
Accomplishments:
Understood how the inline ASM works as some include files were using it and wrote a code to alter only specific pin values using masking bits
Figured out how R30 and R31 bits corresponds to the pins on the Header
It dawned upon me . that there is no need to connect beaglebone black wireless running Beaglelogic with the laptop, it can work by connecting over wifi. The other issue where i was not able to see the signals on the pulseview was solved by reinstalling updating and readjusting the Sampling rate and number of samples.
On-going blockers:
N/A
Plans for the week:
Figureout how will the GPIO driver send commands to PRU
This is a Week 2 report for GSoC2020 project Parallel Bidirectional Bus.The 74hc595 was up and running and I spent most of the time this week studying about accessing the physical memory and writing and reading to it. SInce it was very new domain to me
it took alot of time to get my head around it. Concrete accomplishments are less for this week but i went through all the background that was needed to achieve my objective. Went through several documents and stackoverflow posts but two note worthy resources i focused on are:
chapter Name: Using I/O Memory: in book titled Linux Device Driver 3rd Edition , page no 249 Onwards
Chapter Name: Kernel Memory Managment: in book titled Linux Device Driver Development-John Madieu
Accomplishments:
Studied about the memory mapping and memory access
Wrote a basic driver to read and write from OCMC shared memory space
Also i forgot to mention. One of my Pull Request was merged This will make it easy and quick to understand input and output control using PRU for anybody starting to work with PRUGCC. Unlike the earlier examples this code manipulates specific pin values rather than the whole register.
his is a Week 4 report for GSoC2020 project Parallel Bidirectional Bus. I had to travel out of the country and had an exam last week so couldnot spend much time
Accomplishments:
Reconfigured the hardware as i had to disassemble everything to bring along with me on my journey
Made a dummy code by translating the truth table for 74hc299
On-going blockers: code doesnot
Sometimes the code running on pru 1 gives a warning pruss_intc_irq_set_affinity: event 16 not configured and data is not pushed out
Plans for the week:
Implementation of PRU firmware for IC 74hc299 Universal register
I am trying to understand this update. Specifically, I am trying out why you're
spending what appears to be a lot of time making dummy code for the 74hc299.
If you got things going with the '595, is the '299 really necessary? At least
that's what your update suggests. Any insight would be useful. GSoC is short!
The 74HC299 is a 20 pin device.
- 8 of them are the parallel in and out (no connect or check with a scope/LA)
- 2 of them are the output ends of the shift register
- 2 of them are the input ends of the shift register
- 2 are power and ground
- 2 are output enables
- 2 mode selects
- Reset
- Clock
For the simplest setup -
VCC, RESET tie to power
GND, both OE to GND
Since you're clocking from the PRU, tie one of the mode to power and the other
to GND.
Then clock and one of the ends of the serial input to the PRU. The end will be
from the mode select config.
If you need to read from the parallel bus:
- Disconnect OE from GND and make it toggleable from the PRU.
- Connect the mode switch to the PRU
- Connect one of the SR outputs to the PRU.
But this can be a second setup. Getting parallel output would be a start and
that requires min connections.
What part of the above is delaying things?
Also, I know you mentioned on IRC the previous code uses regular GPIO, you
should be able to change those access to a register access.
By dummy code i meant the the raw text notes that i write after understanding the truth table and before i actually write the actual code. Rest all the codes are actual working codes that i have tested with 74hc595 and 74hc299. Now about the necessity to spend time on 74hc299 when 74hc595 is already working is because in 74hc299 i can switch between SIPO mode and PISO modes which is necessary for bidirectional communication. It was during the initial days that the hardware was not available and i could buy 74hC595 from store nearby i started with it. Further since it is readily available IC somebody in the community can easily work using it and have atleast a unidiretional bus. For us Since we are making a bidirectional bus so the data flow should be in both the directions. To explain my understanding of it further . A little example would be, suppose i have a user space code which will send a decimal number lets say 255. This number is passed to the PRU through a driver implementing rpmsg. once the PRU gets this data it converts it to binary no. and sends it out to the Shift register and from there it will be pushed to 8 output pins. This is how it will control the outputs. Similarly for the inputs, the userspace code will send a flag and then the PRU will first configure the shift register in PISO mode. Once in this mode the data at 8 inputs will go inside the shift register on a low to high transition of clock and this register will be read by the PRU and the data will be send back to the userspace application. This is how i understand the implementation. Now on 74HC595 this PISO mode is not possible.So if you would look at the codes for 74hc299 and 74hc595 in my repository they have a variable which will get the value from the userspace. So it is not that these are just some codes in isolation they will be connected to the GPIO chip driver in the comming days.
Also you emphasis alot on focusing on the software and i understand your concern but for me to test out the codes if they actually work or not and be certain i need to test them on a actual hardware. Isnt it?
But this can be a second setup. Getting parallel output would be a start and
that requires min connections.
Yes parallel outputs are working on both the ICs.
What part of the above is delaying things?
The codes for SIPO on 74HC595 and 74HC299 are working perfectly on the hardware. Also on 74HC299 code to implement PISO is done but is not tested. Since there is no way to read and printout the values on the PRU, i tried to use PRUDEBUG to see if the data being read can be confirmed but i think when writing in c i dont have control in which register is my value stored. Now i am trying to send the variable back to the userspace .
The other issue which is a hindering the progress is that the interuppt is not working correctly when msg is shared between PRU0 and ARM, it works well when commuicating between PRU1 and ARM, But here for my application i need to run it on PRU0 since all the pins with enhanced PRU capability which are exposed on the headers on the pocketbeagle corresponds to PRU0.
Any further pointers or suggestions are most welcome.
If there was a lot of time, sure. It seems like a lot time is spent on these
basics. Exposing a GPIO chip is not the end goal of this project anyways; it
is suppose to be an intermediate/precursor and we are not there yet. My
concern is time - the impression I am getting from the reports is a lot of
time is being spent on "truth tables" of the chip. Keep in mind these chips
are just building blocs; it is very well possible to do all this in a small
PLD, CPLD, FPGA etc.
Have you documented what you need and how that maps to the chip?
Also, while it is true the 595 is a lot of limited, the 299 isn't a panacea
since you're doing a intermediate step of exposing a GPIO chip. What it comes
down to is -
'595 - 8 outputs
'299 - 8 inputs or outputs but you cannot configure them separately.
Also, since you are doing the intermediate goal of gpiochip, why are you even
talking to userspace directly? Why isn't the gpipchip SW implemented? This way
you can use the gpio framework to debug it and not care where the request is
coming from.
his is a Week 5 report for GSoC2020 project Parallel Bidirectional Bus. This week i worked on the resolution of previous week blocker and succeeded in resolving it and then i worked on the gpiochip driver. To achieve my objective i first had to build my understanding of how everything works and why do we need this driver when we already have a char driver. So I had a extra meeting with saketh and Abhishek apart form my scheduled wednesday and thrusday meetings. With the new understanding i could proceed with my coding. I also went through documentations and gpio driver samples . Some important mentions are: sysfs, gpio, chapter 14 and 15 in John Madeu book titled Linux device driver development .
Accomplishments:
Wrote a gpiochip driver to expose the interfaces in sysfs.
Resolved the issues with interrupt and channel settings so that the rpmsg code could be run on PRU0. Updated and tested my 74HC299 code to include rpmsg.
Wrote a patch to port the hc-sr04 range sensor codecode, which currently can run on PRU1 . Now can also be run on PRU0 after applying the patch. Here is the pull request
Wrote a BlogPost to explain about the differences in resource table and other files to implement rpmsg on different PRU cores.
On-going blockers:
The issue was because of the Host to channel mapping in the resource table file was not set properly. More can be read about it in the Blogpost
Plans for the week:
Finish the GPIO driver and start with Platform driver.
This is a Week 6 report for GSoC2020 project Parallel Bidirectional Bus. This week i worked on improving the gpiochip driver and resolving the issues related to sending multiple bits.I went through gpio driver documentation . Further along with my mentors i established structure of a protocol for communication and mode setup. Also explored the new chardev interface for gpio control and gpiolibc userspace library.
Accomplishments:
Extended the driver to send a byte .This was one key issue that needed tweaking the driver to understanding the internal working of offsets and masking procedure . Finally made use of offsets and masking to build a byte from data obtained from each of the 8 exported gpio interfaces and sent over rpmsg to the PRU
Discussed a protocol to setup PISO and SIPO modes and agreed on a protocol where the first 8 bit sent to the PRU will determine the mode and then the data further sent will be the data to be pushed out/in of the PRU.If a 0 is sent in the beginning, the PRU will configure the shift register in SIPO mode and when 1 is sent it will configure it in PISO mode. After configuration the actual data can flow in or out. To change the direction configuration data need to be sent again.
While working with the GPIOchip driver i had to start stop and load new firmware multiple times so i extended the makefile from pru-gcc repo such that now after the build the PRU firmware is automatically loaded and PRU is restarted. Pull request is pending.
On-going blockers:
N/A
Plans for the week:
The protocol that i agreed upon with my mentors abhishek and saketh need to be implemented and a pull request need to be made in the beaglebone linux repo.
A blogpost on sys interface and gpio control through it.
I’m writing to check on the status of deliverables that were agreed during our previous e-meeting. One of them being the implementation of a protocol for the
communication and the other being, providing user space functions that would allow to send data to the gpios from userspace without having to manually
modify values on every pin/line in the offset range. I’d like to point out that the implementations were agreed to be delivered on or before 23 July EST.
( To make sure that things are working as expected, testing the code with the hardware would be better.)
Please feel free to write back or ask questions if any, to make sure the agreed upon deadlines are met.
I have implemented the user space functions to allow sending data and have also implemented protocol to switch the modes. I am working reading the data from the kernal to the userspace.
This is a Week 6 report for GSoC2020 project Parallel Bidirectional Bus. So i would start with briefly summerising the main achievements of the project so far. So now user can send data from the userspace to the kernel and then kernel passes it on to the PRU using rpmsg .PRU receives 9 bit of data and depending upon the 9th bit being 1 or 0 it configures it as SIPO or PISO shift registor . Also data can flow from shift register to PRU to linux kernal to linux userspace. Here there is a issue in transfering data from kernal to userspace.This is currently a blocker. I spent time resolving it but as i also had exam on 27 July, So i couldnot completely resolve it,
Accomplishments:
Wrote user space application to send and receive data. The GPIOchip driver exposes chardev interface which is used along with libgpiod to send and receive data.
Implemented a protocol to switch modes . The gpiochip driver controls 9 lines out of which 8 are used to send required data and 1 for sending the mode data
Tested the modes on the hardware
On-going blockers:
In PISO mode data received from the PRU in the kernal module could not be assigned to the value interface from where it could be read using the userspace code.
This is a Week 7 report for GSoC2020 project Parallel Bidirectional Bus. So last week i worked on studying the different ways to implement a parallel bus. Went through the documentation for SPI bus, parallel address and data bus in 8088 and the communication between the parallel port and printer.
Accomplishments:
worked on the possible protocol to implement a parallel bus on pocket beagle and wrote it in a Blog.
Wrote a skeleton code for parallel bus similar to the bus in 8088.
Resolved the blocker: I was not able to transfer data from kernel module to the userspace through my gpiochip driver. This works now.
On-going blockers:
The shift register in PISO mode seems to send constant value 0xae everytime irrespective of the state of buttons connected to the input pins. This need to be fixed
Plans for the week:
Resolving the blocker
Further plans i will update after the meeting today. From the comments on my previous evaluation , it seems i only have to implement a gpiochip driver now. But will seek further clarification from the mentors and will update
This is a Week 8 report for GSoC2020 project Parallel Bidirectional Bus. I worked on finishing up my bidirectional communication and documentation. The blocker last time is not completely solved but now the data can flow in both the direction. In one of the meeting abhishek pointed out that my earlier implementation of getting the data from the payload received is not correct. So i corrected it. However i am still not getting correct data values inside the kernel module. There seems to be some issue in getting the inputs from shift register.Linux module part is performing as it should. I tried several things to resolve it. I replicated the same code as in PRU in the Arduino and i was able to get the right input values in the PISO mode, then i checked the bitwise operations multiple times on online compiler like python-tutor.com where i could visualize the intermediate values, the only thing that i could gather from there is that the bit wise operations that i am doing are right.I also tried to see the inputs on beaglelogic but it is not working for me,I am able to connect to it using the sigrock it doesnot show anything. I also worked on the issue with my primary mentor on remote desktop connection but still no solution. Further, as per my discussion with my primary mentor i am asked to go down the gpiochip path and raise a PR to the beaglebone linux repo as my end goal.
Accomplishments:
The repository has been restructured and code has been cleaned, link
This is a Week 9 report for GSoC2020 project Parallel Bidirectional Bus. I finally resolved the blocker that i had last time. Further added shell scripts and unit files to configure the required pin configuration automatically on boot. Also finished most of documentation in the readme files.
Accomplishments:
Updated all the readme files with content that would help others understand and execute the code. gitlink
Added shell scripts and unit files to automate PRU pin configuration on boot.
Resolved the blocker form last time. Resolution to blockers:
The issue was due to the fact that the the pulse width of clock pulse was too less to be registered by the shift register.
Plans for the week:
Will be discussing the next steps with Jason and Saketh tomorrow in a googlemeet
Will finish up the wiki page
Will Write some blog posts about the tricky things that i observed while working with pocketbeagle.
Can you elaborate a little bit on the timing issue you found? In particular,
can you walk through the timing using the timing data found in the shift
register datasheet, the AM335x datasheet, and expecting timings on the PRU?
I think a quick write up like this would be useful for other PRU interfacing
applications. Pointing which timing spec was violated and how to avoid writing
code that violates timing. Right now, it seems like you have learned by
experience that the PRU is fast enough to violate 74HC logic timing so having
a quick recipe so others don't do the same thing would be valuable.
Historically, these timings are largely a hardware thing but the use case of
the PRU exposes purely software programmers to the same issue.
I forgot to mention in the mail post here that as DS2 suggested to write about the timing issues, i was thinking of posting a blogpost with signals recorded using beaglelogic to explain the timing but unfortunatly my beaglebone wireless is not working. I tried to boot it but may be i fried it when measuring something 5v. I have gone through some timing data of how fast PRU can toggle from the exploring beaglebone book. I will use the data from there and some data from the shift register IC to and will explain about the timing in my next post
that there is no need to connect beaglebone black wireless running Beaglelogic with the laptop, it can work by connecting over wifi. The other issue where i was not able to see the signals on the pulseview was solved by reinstalling updating and readjusting the Sampling rate and number of samples.