Weekly Progress Report Thread: Parallel Bidirectional Bus

[Deepankar Maithani]

Hello All

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
  
• Update the blog posts
  

[Deepankar Maithani]

Hello All

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
  
• Wrote first test code for shift register.
• Wrote a simple GPIO chip driver
  
• Added a new blogpost about mapping pins  PRURegisterMapping
  

Resolutions to blockers:

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
  
•  Getting the 74HC595 up and running with PRU
  
• Update the blog posts

[Deepankar Maithani]

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
  
• Added a new blogpost about  shared memory  A quick guide to shared memory
•  Also sharing the video of interfacing that i  made last week but forgot to share Interfacing 74hc595
  

On-going blockers:

• N/A
  

Plans for the week:

• Build understanding of Ring Buffers and  interrupts
  
•  Reading data from shared memory in a PRU Code
  
• Update the blog posts

[Deepankar Maithani]

This is a Week 3 report for GSoC2020 project Parallel Bidirectional Bus.

Accomplishments:

• Implemented communication between ARM and PRU using rpmsg
  
•  Now a userspace code can send msg to the PRU core  and then PRU converts it into binary data
  
• I could send and receive messages from  arm to PRU and vice versa
• The code and Readme on the repository  has been updated and schematic is also added to interface 74hc595.
  

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
  
•  Updating blog post
  

[Deepankar Maithani]

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.

[Deepankar Maithani]

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
  
•  Updating blog post

• resolution the blocker
  

[Hunyue Yau]

Hi Deepankar,

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.





On Monday, July 06, 2020 14:39:06 Deepankar Maithani wrote:
> This is a *Week 3 *report for GSoC2020 project Parallel Bidirectional Bus
> <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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
> - Updating blog post

>
> On Tuesday, June 30, 2020 at 3:23:03 PM UTC+2, Deepankar Maithani wrote:
> > Also i forgot to mention. One of my Pull Request was merged

> > <https://github.com/dinuxbg/pru-gcc-examples/pull/6.> 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.
> >
> > On Tuesday, June 30, 2020 at 3:00:10 PM UTC+2, Deepankar Maithani wrote:

> >> This is a *Week 3 *report for GSoC2020 project Parallel Bidirectional Bus
> >> <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_bus>.
> >> *Accomplishments:*
> >>
> >> - Implemented communication between ARM and PRU using rpmsg
> >> - Now a userspace code can send msg to the PRU core and then PRU

> >> converts it into binary data

> >> - I could send and receive messages from arm to PRU and vice versa
> >> - The code and Readme on the repository has been updated and

> >> schematic is also added to interface 74hc595.
> >>

> >> *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
> >> - Updating blog post

> >>
> >> On Monday, June 22, 2020 at 8:25:29 PM UTC+2, Deepankar Maithani wrote:

> >>> This is a *Week 2 *report for GSoC2020 project Parallel Bidirectional
> >>> Bus
> >>> <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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
> >>> - Added a new blogpost about shared memory A quick guide to shared
> >>> memory <https://deebot.github.io/sharedMemory.html>
> >>> - Also sharing the video of interfacing that i made last week but

> >>> forgot to share Interfacing 74hc595

> >>> <https://www.youtube.com/watch?v=R-aSw67c1D4>
> >>>
> >>> *On-going blockers:*
> >>>
> >>> -
> >>>
> >>> *N/A *
> >>>
> >>> *Plans for the week:*
> >>>
> >>> - Build understanding of Ring Buffers and interrupts
> >>> - Reading data from shared memory in a PRU Code
> >>> - Update the blog posts

> >>>
> >>> On Monday, June 15, 2020 at 10:34:50 PM UTC+2, Deepankar Maithani wrote:
> >>>> Hello All
> >>>>

> >>>> This is a *Week 1 *report for GSoC2020 project Parallel Bidirectional
> >>>> Bus <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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
> >>>> - Wrote first test code for shift register.
> >>>> - Wrote a simple GPIO chip driver
> >>>> - Added a new blogpost about mapping pins PRURegisterMapping
> >>>> <https://deebot.github.io/PRURegisterMapping.html>
> >>>>
> >>>> *Resolutions to blockers:*

> >>>>
> >>>> 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
> >>>> - Getting the 74HC595 up and running with PRU
> >>>> - Update the blog posts

> >>>>
> >>>> On Sunday, June 7, 2020 at 11:56:26 AM UTC+5:30, Deepankar Maithani
> >>>>
> >>>> wrote:
> >>>>> Hello All
> >>>>>

> >>>>> This is a *Week 0 *report for GSoC2020 project Parallel Bidirectional
> >>>>> Bus
> >>>>> <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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

> >>>>> <https://deebot.github.io/blogs.html>
> >>>>>
> >>>>>
> >>>>> *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
> >>>>> - Update the blog posts

--
Hunyue Yau
http://www.hy-research.com/

[Deepankar Maithani]

Hello, thanks for the message

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.

[Hunyue Yau]

Deepankar,

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.

To reiterate - GSoC is short.

[Deepankar Maithani]

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.
  

[Deepankar Maithani]

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.
  

[Saketha Ramanujam]

Hi Deepankar,

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.

Thanks,

Saketh.

[Deepankar Maithani]

Hi Saketh

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.

[Deepankar Maithani]

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.

Plans for the week:

• Resolving the blocker
• Work on the Platform Bus/parallelport
• blogposts on GPIOchip driver and usage

[Deepankar Maithani]

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
  

[Deepankar Maithani]

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
  
• Added wiki page wiki
  

On-going blockers:

• The shift register in PISO mode  doesnot  provide right  state of inputs
  

Plans for the week:

• Resolving the blocker
• Finishing  the documentation
  

[deepank...@gmail.com]

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.

[Hunyue Yau]

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.


On Monday, August 17, 2020 18:43:57 deepank...@gmail.com wrote:
> This is a *Week 9 *report for GSoC2020 project Parallel Bidirectional Bus
> <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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

> <https://github.com/deebot/Beaglebone-BidirectionBus/tree/dev>
> - 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.
>
>
>
> On Wednesday, August 12, 2020 at 4:17:58 PM UTC+2 deepank...@gmail.com
>
> wrote:

> > This is a *Week 8 *report for GSoC2020 project Parallel Bidirectional Bus
> > <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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
> > <https://github.com/deebot/Beaglebone-BidirectionBus/tree/dev>
> > <https://deebot.github.io/whatsnext.html>
> > - Added wiki page wiki
> > <https://github.com/deebot/Beaglebone-BidirectionBus/wiki>
> >
> > *On-going blockers:*
> >
> > - The shift register in PISO mode doesnot
> >
> > *provide right state of inputs *

> >
> > *Plans for the week:*
> >

> > - Resolving the blocker
> > - Finishing the documentation

> >
> > On Tuesday, August 4, 2020 at 9:08:05 AM UTC+2, Deepankar Maithani wrote:

> >> This is a *Week 7 *report for GSoC2020 project Parallel Bidirectional Bus
> >> <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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.

> >> <https://deebot.github.io/whatsnext.html>
> >> - 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
> >>
> >> On Tuesday, July 28, 2020 at 1:17:22 AM UTC+2, Deepankar Maithani wrote:

> >>> This is a *Week 6 *report for GSoC2020 project Parallel Bidirectional
> >>> Bus <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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.*

> >>>
> >>> *Plans for the week:*
> >>>

> >>> - Resolving the blocker
> >>> - Work on the Platform Bus/parallelport
> >>> - blogposts on GPIOchip driver and usage

> >>>
> >>> On Tuesday, July 14, 2020 at 7:43:02 PM UTC+2, Deepankar Maithani wrote:

> >>>> his is a *Week 5 *report for GSoC2020 project Parallel Bidirectional
> >>>> Bus <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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

> >>>> <https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt>, gpio
> >>>> <https://www.kernel.org/doc/Documentation/gpio/sysfs.txt>, 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

> >>>> <https://github.com/dinuxbg/pru-gcc-examples/pull/12>
> >>>> - Wrote a BlogPost <https://deebot.github.io/rpmsgPRU.html> 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

> >>>> <https://deebot.github.io/rpmsgPRU.html> *

> >>>>
> >>>> *Plans for the week:*
> >>>>

> >>>> - Finish the GPIO driver and start with Platform driver.

> >>>>
> >>>> On Monday, July 6, 2020 at 11:40:51 PM UTC+2, Deepankar Maithani wrote:

> >>>>> his is a *Week 4 *report for GSoC2020 project Parallel Bidirectional
> >>>>> Bus
> >>>>> <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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
> >>>>> - Updating blog post
> >>>>> - resolution the blocker

> >>>>>
> >>>>> On Tuesday, June 30, 2020 at 3:23:03 PM UTC+2, Deepankar Maithani
> >>>>>
> >>>>> wrote:
> >>>>>> Also i forgot to mention. One of my Pull Request was merged

> >>>>>> <https://github.com/dinuxbg/pru-gcc-examples/pull/6.> 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.
> >>>>>>
> >>>>>> On Tuesday, June 30, 2020 at 3:00:10 PM UTC+2, Deepankar Maithani
> >>>>>>
> >>>>>> wrote:

> >>>>>>> This is a *Week 3 *report for GSoC2020 project Parallel
> >>>>>>> Bidirectional Bus

> >>>>>>> <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_bus>.
> >>>>>>> *Accomplishments:*
> >>>>>>>

> >>>>>>> - Implemented communication between ARM and PRU using rpmsg
> >>>>>>> - Now a userspace code can send msg to the PRU core and then

> >>>>>>> PRU converts it into binary data

> >>>>>>> - I could send and receive messages from arm to PRU and vice
> >>>>>>> versa
> >>>>>>> - The code and Readme on the repository has been updated and

> >>>>>>> schematic is also added to interface 74hc595.
> >>>>>>>

> >>>>>>> *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
> >>>>>>> - Updating blog post

> >>>>>>>
> >>>>>>> On Monday, June 22, 2020 at 8:25:29 PM UTC+2, Deepankar Maithani
> >>>>>>>
> >>>>>>> wrote:

> >>>>>>>> This is a *Week 2 *report for GSoC2020 project Parallel
> >>>>>>>> Bidirectional Bus
> >>>>>>>> <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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
> >>>>>>>> - Added a new blogpost about shared memory A quick guide to
> >>>>>>>> shared memory <https://deebot.github.io/sharedMemory.html>
> >>>>>>>> - Also sharing the video of interfacing that i made last week

> >>>>>>>> but forgot to share Interfacing 74hc595

> >>>>>>>> <https://www.youtube.com/watch?v=R-aSw67c1D4>
> >>>>>>>>
> >>>>>>>> *On-going blockers:*
> >>>>>>>>
> >>>>>>>> -
> >>>>>>>>
> >>>>>>>> *N/A *
> >>>>>>>>
> >>>>>>>> *Plans for the week:*
> >>>>>>>>

> >>>>>>>> - Build understanding of Ring Buffers and interrupts
> >>>>>>>> - Reading data from shared memory in a PRU Code
> >>>>>>>> - Update the blog posts

> >>>>>>>>
> >>>>>>>> On Monday, June 15, 2020 at 10:34:50 PM UTC+2, Deepankar Maithani
> >>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>> Hello All
> >>>>>>>>>

> >>>>>>>>> This is a *Week 1 *report for GSoC2020 project Parallel
> >>>>>>>>> Bidirectional Bus
> >>>>>>>>> <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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

> >>>>>>>>> - Wrote first test code for shift register.
> >>>>>>>>> - Wrote a simple GPIO chip driver
> >>>>>>>>> - Added a new blogpost about mapping pins PRURegisterMapping
> >>>>>>>>> <https://deebot.github.io/PRURegisterMapping.html>
> >>>>>>>>>
> >>>>>>>>> *Resolutions to blockers:*
> >>>>>>>>>

> >>>>>>>>> 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
> >>>>>>>>> - Getting the 74HC595 up and running with PRU
> >>>>>>>>> - Update the blog posts

> >>>>>>>>>
> >>>>>>>>> On Sunday, June 7, 2020 at 11:56:26 AM UTC+5:30, Deepankar
> >>>>>>>>>
> >>>>>>>>> Maithani wrote:
> >>>>>>>>>> Hello All
> >>>>>>>>>>

> >>>>>>>>>> This is a *Week 0 *report for GSoC2020 project Parallel
> >>>>>>>>>> Bidirectional Bus
> >>>>>>>>>> <https://elinux.org/BeagleBoard/GSoC/2020_Projects/PRU_Bi-dir_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

> >>>>>>>>>> <https://deebot.github.io/blogs.html>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> *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

[deepank...@gmail.com]

This is a Week 10 report for GSoC2020 project Parallel Bidirectional Bus. I finally resolved the blocker that i had last time.

Accomplishments:

• Matched code with  kernel coding style and made necessary changes as suggested by jason
  
• Updated wiki and readme
  
• Raised the PR
• Added a blog post to  use nm-connection-editor to connect to internet   post.

Plans for next week

• Resolve any other querries for PR  and rebase
  
• FInish final video
• Write some posts
  

[deepank...@gmail.com]

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

[deepank...@gmail.com]

This is the final update for my project. The current state of project as of today  is that we have a functional bidirectional communication  between  ARM and PRU using  gpio interface in the sysfs and  char dev  interface in  /dev . Also PRU i/o has been extended using shift registers.

Following software has been implemented to achieve the end goal

1. Gpiochip driver is implemented.

2. Firmware to interface 2 shift registers  (74HC299  and 74HC595)and incorporate rpmsg is implemented

3. systemd service and  shell scripts to configure pin-modes has been implemented.

4. Userspace code in C language to send and receive data has been implemented

5. All the Documentation , technical description, code , how to use guides , blogpost links, references and future improvement scope  can be accessed  using this Wiki link.

Thanks for the opportunity, it has been a great learning experience for me. I could learn a lot of new concepts in this short time and explored new programming domains like kernel module programming . Also could interact with amazing people in the beagle-bone channels.Thanks to the mentors for their great support during the project. In the future  I will work on extending this implementation and improving it .

Looking forward to work on more exciting projects and long term association with the community.