Hi, my name is Deepak Khatri and I am currently pursuing B.E. from Netaji Subhas University of Technology. I am very much interested in working for the Beagle Board Organization this summer. I am mainly interested in the “Cape compatibility layer for BeagleBone Black and BeagleBone AI” Project.
I have done an internship on Embedded Electronics under the TI University Program and worked primarily on BeagleBoneBlack, there I also completed a project called Mausam national PFA the image for the same, I designed the Board in Eagle CAD and etched it myself. The project used 3 MQ sensors, 1 DHT11 sensor, Nokia LCD and some tactile switches with the BBB, which allowed us to monitor the air quality but there was a twist in the project. It can connect to the internet using wifi dongle (not shown in the picture) and get the real-time data from the AIR monitoring system in our university and calibrate the sensors, I used python for the project, It mainly involved programming for hardware interfacing and web scraping. I had also received the Electronics Maker Contest Award in 2017 and I was one of the Quater Finalists in IICDC 2017, In both of the contests I received EVMs from Texas Instrument and I have a good understanding of using the boards using CCS and Energia.
I am currently working on writing Device Driver for ADS1292, I have created the prototype board using KiCAD and using ESP8266 as the Controller board. After getting this to work, I am also interested in making a Biopotential signal CAPE for BBB that can measure EEG, EMG, ECG, etc.
I have followed the basic requirements guide and completed all the requirements for the application. I am sharing my resume PFA for the same. I need some guidance in moving forward, Can you please let know what things I should do next so that I can hopefully get the project 
Best Regards,
Deepak Khatri,
(https://deepaklorkhatri007.github.io/)
Copy of Deepak Khatri Resume - Hardware.pdf (101 KB)
Hi, my name is Deepak Khatri and I am currently pursuing B.E. from Netaji Subhas University of Technology. I am very much interested in working for the Beagle Board Organization this summer. I am mainly interested in the “Cape compatibility layer for BeagleBone Black and BeagleBone AI” Project.
Have you thought about what a programming layer might look? Have you started drafting a project proposal?
I have done an internship on Embedded Electronics under the TI University Program and worked primarily on BeagleBoneBlack, there I also completed a project called Mausam national PFA the image for the same, I designed the Board in Eagle CAD and etched it myself. The project used 3 MQ sensors, 1 DHT11 sensor, Nokia LCD and some tactile switches with the BBB, which allowed us to monitor the air quality but there was a twist in the project. It can connect to the internet using wifi dongle (not shown in the picture) and get the real-time data from the AIR monitoring system in our university and calibrate the sensors, I used python for the project, It mainly involved programming for hardware interfacing and web scraping. I had also received the Electronics Maker Contest Award in 2017 and I was one of the Quater Finalists in IICDC 2017, In both of the contests I received EVMs from Texas Instrument and I have a good understanding of using the boards using CCS and Energia.
I am currently working on writing Device Driver for ADS1292, I have created the prototype board using KiCAD and using ESP8266 as the Controller board. After getting this to work, I am also interested in making a Biopotential signal CAPE for BBB that can measure EEG, EMG, ECG, etc.
I have followed the basic requirements guide and completed all the requirements for the application. I am sharing my resume PFA for the same. I need some guidance in moving forward, Can you please let know what things I should do next so that I can hopefully get the project 
Beautiful. For GSoC, we try to make contributions about software rather than hardware. For this project, it is all about how we can create a single set of software at the userspace level to use cape resources and to make it easier for folks who have developed capes for BeagleBone Black to migrate to BeagleBone AI.
If you can take a bit of time to document what you might think the migration challenges are, we might be able to work together on approaches for solving them.
Please use all communication avenues available to you and be sure to summarize in your project proposal and to this discussion list.
Hi, sorry for late reply i was thinking about how we can implement the required changes for the compatibility layer for BeagleBone Black and BeagleBone AI and i believe these are some tasks/challenges we have to overcome.
-
Making pin names same for both the boards.
-
Updating the device tree for matching the aliases provided by the device tree.
-
Making userspace examples compatible.
-
To be able to use serial port and userspace i2cdev/spidev.
-
Accessing pins using pin names under libgpiod.
I tried finding some insights for solving these tasks, i am sharing what i think might be a possible way of solving the tasks. please give me follow up links and source for learning more and correct me if i am wrong any where.
-
For making pin names same for both the boards we have to create a new device tree source include file for am5729 that will map pin names to the actual pins. We have "am335x-bone-common-universal-pins.dtsi" that implements the same for beagle bone black, we can create a similar file like "am5729-beagleboneai-****common-universal-pins.dtsi" for beagle bone ai.
-
We have to make sure that all the aliases in “/sys/firmware/devicetree/base/aliases” should match, i am not sure what files of kernel source compiles to creating these aliases. After reading about device tree i got to know that one of the top-level nodes under the root of device tree is an aliases node, to define shortcuts to certain nodes.
-
For making the usespace examples of the capes compatible with the beagle bone ai we are required to have same pin name and aliases so that we can can use device tree overlays. Cape’s eeprom will provide the details about pin modes.
-
I have read some posts on eLinux.org and kernel.org about using i2c-dev and spidev for using these peripherals from userspace but i am not sure about any solution for this.
-
I tried using libgpiod and it’s utilities on my BBB and watched this talk from Bartosz Golaszewski. I got some idea of what it does and how we can get info of pins, set the state, get the state and so on. I belive we have to do the device tree part discussed above for this one.
All of the task are interlinked in someway or another and i have got some basic idea on how i can go about doing this project. please provide your comments and some follow up knowledge source for better understanding.
Making pin names same for both the boards.
Hi, I read about how we do the pin naming of GPIOs, P8 and P9 header pins of BeagleBoneBlack. I am working on the proposal which can be found here.
Hi, I have completed my proposal for the project, https://elinux.org/BeagleBoard/GSoC/2020Proposal/DeepakKhatri
please give your valuable feedback on the same.
Thanks!
I guess Google Docs do provide some advantages for feedback, but, I’m happy not to be loading down my system with dozens of instances of that.
Under the section “Description”, can you elaborate a bit more? I didn’t see any reference to https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec. I think we need to get down to a bulleted list of what will be enabled to be consistent between the two boards.
Also, there needs to be some consideration of the default pin modes as well. I think Robert’s boot patches are in https://github.com/RobertCNelson/Bootloader-Builder/tree/master/patches/v2019.07-rc4/am57xx_evm and https://github.com/beagleboard/beaglebone-ai/tree/master/SW/u-boot with the DT at https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti/src/arm/am5729-beagleboneai.dts, but honestly even I get confused when not touching it everyday. Anyway, not only do the peripherals need to be aliased, which I hope you can fully work out for a good subset of peripherals, but the pinmuxes need to be in the right modes as well.
In the timeline, what do you mean by running example codes on Black?
Much of the learning seems to be scheduled for during the project execution and this adds lots of risk. If you can try to address a bit more of it now, that’d be good. I know a lack of hardware can be a barrier, but you can still be compiling device trees and make assumptions that can be validated once you have hardware. You can also reach out to the community for feedback on edits. For example, you can make some small edits to the bb.org-overlays or BeagleBoard-DeviceTrees repos on BeagleBoard.org · GitHub via forks and create pull requests. You can post your pull requests to this list, both #beagle and #beagle-gsoc as well as the main BeagleBoard Google Group to see if anyone can give feedback on the change and maybe even try it out. This will allow you to validate your assumptions early and get ingrained into the community.
Capes I’d give priority to are the ones listed on BeagleBoard.org - Capes. I’d send you an entire set of those capes. The most involved one is Robotics Cape. I got started on migrating the support for it at https://github.com/jadonk/librobotcontrol/tree/bbai. At this point, I really only did the PRU stuff as that is what I needed to drive motors. At the application level, I did some really ugly hacks to utilize GPIOs:
Avoid ambiguous statements in the milestones, even if you don’t quite know at this stage. At least put a placeholder and ask for help filling it in. “More capes” isn’t something I can hold you accountable for. “Get XYZ working on Cape ABC” is something I can track.
Look at the BeagleBoard.org - Capes in detail. Think about how userspace code would need to look for each. I have some less-than-desired userspace code in https://github.com/jadonk/beagle-tester (https://github.com/jadonk/beagle-tester/blob/master/beagle-tester.c#L3823-L4331) that pokes various outputs on the capes. Think how this should look in a more structured app and think about inputs as well. Doing a fork of this app might be a helpful way of enabling your solution to act as an on-going regression test!
Hi, I have made the changes you suggested and I have created some pull requests under BeagleBoard-DeviceTrees namely #8 #9 and #10. Please take a look at my edited proposal https://elinux.org/BeagleBoard/GSoC/2020Proposal/DeepakKhatri and let me know what you think. Also, I would like to have a discussion with you on some questions I asked on IRC, please take a look at them.
Hi, I have made the changes you suggested and I have created some pull requests under BeagleBoard-DeviceTrees namely #8 #9 and #10. Please take a look at my edited proposal https://elinux.org/BeagleBoard/GSoC/2020Proposal/DeepakKhatri and let me know what you think. Also, I would like to have a discussion with you on some questions I asked on IRC, please take a look at them.
Nice progress on the Device Trees as well as the proposal. Robert appears to have liked the Device Tree changes enough to go ahead and merge them as-is.
Against my previous recommendations, I’ve created and shared a Google Doc with you with some more specific feedback. I suggest you look at them, but continue to keep the eLinux page up to date. The eLinux page is searchable by web crawlers and many other benefits that don’t exist in Google Docs—but trying to annotate your text is a bit of a challenge without posting it all here.
Hi,
I have made all the required changes in the Google Doc you shared with me. please take a look and let me know what you think. I have also worked on the device tree files and submitted the pull requests under BeagleBoard-DeviceTrees namely #11 #12 and #13.
So @lorforlinux all the overlays for the BBAI are in place and can now be found here right?
Or is there somethings left to be done? If so please can you make a list of things todo?
yes, that is the correct place for the compatible overlays for BBB and BBAI.
1 Like