Difference between revisions of "Beagleboard/GSoC/Cape compatibility layer for BeagleBone Black and BeagleBone AI."

From eLinux.org
Jump to: navigation, search
Line 38: Line 38:
 
For GPIOs, examples would work using pin names under libgpiod. Pin MUX_MODE selection, pin naming and aliasing of P8 and P9 headers of BeagleBone AI will enable us to use different peripherals.BeagleBone cape interface spec shows further details on the active bus data of BeagleBone Black and BeagleBone AI. For the cape specific bus interface, the BeagleBone Cape Header Pins file gives us all the required information like which pins are used and also details on MUX_MODE are also provided there. For some of the capes, I am going to work on this summer.  
 
For GPIOs, examples would work using pin names under libgpiod. Pin MUX_MODE selection, pin naming and aliasing of P8 and P9 headers of BeagleBone AI will enable us to use different peripherals.BeagleBone cape interface spec shows further details on the active bus data of BeagleBone Black and BeagleBone AI. For the cape specific bus interface, the BeagleBone Cape Header Pins file gives us all the required information like which pins are used and also details on MUX_MODE are also provided there. For some of the capes, I am going to work on this summer.  
  
As per my research there is no cape available which is still available in stock. There do exist some capes which are designed for operating the 3D printers using Beaglebone hardware and those capes are BeBoPr++, The rosetta bone, CRAMPS(Cape version of RAMPS), BUMPS, t bone and replicape. I have compared all the information of all the capes [https://docs.google.com/spreadsheets/d/1-n_mQKIHlgG25_qJ2-12Aip9nh7IW9bZAaBB7q5kPqk/edit?usp=sharing here]. The major issue for these capes is that none of them is in stock for a while now, it becomes hard to tinker with the hardware.
+
As per my research there is no cape available which is still available in stock. There do exist some capes which are designed for operating the 3D printers using Beaglebone hardware and those capes are BeBoPr++, The rosetta bone, CRAMPS(Cape version of RAMPS), BUMPS, t bone and replicape. I have compared all the information of all the capes [https://docs.google.com/spreadsheets/d/1-n_mQKIHlgG25_qJ2-12Aip9nh7IW9bZAaBB7q5kPqk/edit?usp=sharing here]. The major issue for these capes is that none of them is in stock for a while now, it becomes hard to tinker with the hardware. Also, they are compatible with Beaglebone Black only till now. But there is no support available for other beaglebone boards.
 +
 
 
<gallery>
 
<gallery>
 
Capes info.PNG
 
Capes info.PNG

Revision as of 23:19, 11 May 2022

Cape compatibility layer for BeagleBone Black and BeagleBone AI.

Student: PADMALAYA RAWAL
Mentors: DEEPAK KHATRI
Wiki: http://elinux.org/BeagleBoard/GSoC/ProposalTemplate


Status

This project is currently just a proposal.

Proposal

Please complete the requirements listed on the ideas page and fill out this template.

About you

Github: ELECTROBOFFIN
School: Maharishi Markandeshwar (Deemed to be) University, Mulana, Ambala
Country: India
Primary language: English & Hindi
Typical work hours: 9AM-5PM ITC
Previous GSoC participation: None

About your project

Project name: Cape compatibility layer for BeagleBone Black and BeagleBone AI

Description

Enabling overlay compatibility U-boot(or Universal bootloader, an open source, primary bootloader used in embedded devices to boot the device’s operating system kernel is used by various computer architectures ARM, X86, RISC-V, etc. Beaglebone boards also use U-boot as their Tertiary Program Loader (TPL). The control of peripherals, symlinks, GPIOs boot time and other hardware specific device configurations is done by U-boot. Configurations can be controlled by updating the Flattened Device Tree( or FDT, a data structure that describes a machine hardware configuration such as base addresses, size of RAM, busses, pin multiplexing, etc. and it is derived from open firmware) for the hardware we wanted to support. Cape compatibility can be enabled using the boot time device tree overlays.Device tree overlay repo provides the overlays for most of the capes. The development of device tree overlay and loading it at the time of boot is the major task. Almost each and every cape has the EEPROM on them which is used to store the information related to the hardware of the cape and we can get the details of the pin configurations from the EEPROM.

As the device tree overlays of all the capes is available at device tree overlay repo so the code for the device tree overlays will be added to the same to make the cape compatible. Device tree overlays are the crucial part of the whole project; the same references will be used in the drivers for peripherals assigned to the same pin between both the boards BBB and BBAI.

Why is the Device Tree necessary?

With the influx of ARM systems in the past few years, there were a lot of confusions and conflicts in the linux kernel surrounding the ARM components, prompting linux Torvalds to push back. That push back eventually led to any new ARM boards essentially needing to use the FDT instead of the ARM file. Below is the device tree overlay for the UART1 device. It tells the kernel everything it needs to know in order to properly enable UART1 on pin P9_24 and P9_26.

For all the information related to pin muxing (or pin multiplexing which is a process to get your GPIO to work from code by configuring the pins as inputs, outputs, I2C, PWM, etc.) and the pin naming. The file am335x-boneblack.dts for BBB, am5729-beagleboneai.dts for BBAI and am335x-pocketbeagle.dts for BBpocket are used. The DTS files are normally distributed by kernel developers inside the linux sources for eg: in arch/arm/boot/dts/am335x-boneblack.dts for BBB. In device trees, the aliases node can be seen as a quick look up table, an index for another node. The function find_node_by_aliases() is used to find a node by its alias. The aliasing of interface buses like- I2C, SPI, UART, CAN, etc. is done according to the BeagleBone cape interface spec. For GPIOs, examples would work using pin names under libgpiod. Pin MUX_MODE selection, pin naming and aliasing of P8 and P9 headers of BeagleBone AI will enable us to use different peripherals.BeagleBone cape interface spec shows further details on the active bus data of BeagleBone Black and BeagleBone AI. For the cape specific bus interface, the BeagleBone Cape Header Pins file gives us all the required information like which pins are used and also details on MUX_MODE are also provided there. For some of the capes, I am going to work on this summer.

As per my research there is no cape available which is still available in stock. There do exist some capes which are designed for operating the 3D printers using Beaglebone hardware and those capes are BeBoPr++, The rosetta bone, CRAMPS(Cape version of RAMPS), BUMPS, t bone and replicape. I have compared all the information of all the capes here. The major issue for these capes is that none of them is in stock for a while now, it becomes hard to tinker with the hardware. Also, they are compatible with Beaglebone Black only till now. But there is no support available for other beaglebone boards.

Unlike other capes, Replicape provides plethora of features which are more than enough to control almost any 3D printer available till now. For this purpose Umikaze image (formely Kamikaze) is developed for the ease of user as it contains a ubuntu based operating system with all the necessary packages and configuration pre loaded. With the Umikaze image, there is no support for making cool looking timelapses. A large number of 3D printers brands use marlin flavor of firmware for their printers. But the replicape is little different because it use “Redeem” which is completely new 3D printer controller and is optimized to run on the BBB with Replicape. For migrating from Marlin to Redeem we have to configure redeem with marlin values for stepper motors, Bed levelling probes and end stops & home position.

I tried to run Octoprint on BBB, click here to watch the video

Enabling userspace and end-user compatibility

In symlink theory of operation with udev we can see that for allowing user space programs to use the devices with a custom name Symlinks allow us to define names/location of a peripheral. It’s quite similar with creating an alias for the peripheral but we can use this in userspace and it can be richer in information For example, let’s look at this new symlink I created for the uart1

In this node, we assign the value of "bone/uart/1" to the symlink property which we can call from userspace. Device tree creates an index of all the symlinks we define, In the device tree directory like for the SPI device for which we already have symlinks assigned in the current device tree.



Timeline

Provide a development timeline with a milestone each of the 11 weeks and any pre-work.

Apr 19 Proposal complete, Submitted to https://summerofcode.withgoogle.com
June 13 Pre-work complete, Coding officially begins!
June 20 Milestone #1 Introductory YouTube video Running cape examples and user space examples on BeagleBone Black. This will allow me to get more info on the process of setting up the software and hardware of the cape for future reference
June 27 Milestone #2 Cleaning up the code in beagle-tester and creating new examples Testing everything on BeagleBone Black
July 4 Milestone #3 Finalizing the compatibility of the header pins of the BeagleBone AI with the BeagleBone Black. A detailed discussion with the mentor on the work done till now
July 11 18:00 UTC Phase 1 Evaluation Milestone #4 Testing the pin control using libgpiod Running already available examples that demonstrate the proper working of pin control using libgpiod Finalizing everything done till now and submitting the Phase 1 report for evaluation
July 18 Milestone #5 Testing user space examples with BeagleBone AI Installation of Umikaze image to control the 3D printer using Replicape Taking notes and feedback from my mentor on the quality of the code
July 25 Milestone #6 Initial setup for using capes with BeagleBone AI. Everything will be already available to me as the process is already complete for BeagleBone Black Making the required fixes for running the userspace examples on BeagleBone AI Examples written during the BeagleBone Black testing and the code written inside the beagle-tester will be tested for the BeagleBone AI. During this week I will be testing Servo cape, motor cape, load cape and relay cape.
Aug 1 Milestone #7 Finalizing the device tree code and driver code Testing the Robotics Cape on BeagleBone AI using the newly created device tree and already available cape examples: servo motor and onboard sensors will be tested Detailed discussion on the work done till now
Aug 8 18:00 UTC Phase 2 Evaluation Milestone #8 Fixing the code and making the required changes for cape compatibility Testing octoprint with Replicape and Umikaze
Aug 15 Milestone #9 Testing the 4.3"Display Cape Code cleaning and proper commenting if not done already Taking notes and feedback from my mentor on the quality of the code
Aug 22 Milestone #10 completing the document Taking feedback from mentor
Aug 29 Milestone #11 Completion of YouTube video
Aug 5 - 12 18:00 UTC Final week: Students submit their final work product and their final mentor evaluation
Sept 12 - 19 18:00 UTC Mentors submit final student evaluations


Experience and approach

I have a good understanding of C, C++, and python. I have more than 2 years of hands on experience with 3d printers and its softwares( octoprint, Cura, prusaslicr, etc.) & hardware. I have done multiple internships viz.,
1. Research and Development Intern at Smartcircuits innovation Pvt. Ltd.
2. PCB designer intern at Smartcircuits innovation Pvt. Ltd.
3. Jr. Embedded engineer at Zeropoint robotics Pvt. Ltd.
4. Hardware design engineer at Upsidedown labs.


Webinars and Seminars:
1. I was the guest speaker at the Webinar conducted by Upsidedown labs
2. I organized a webinar for Zeropoint robotics.
3. I have also organized a Seminar and workshop on the occasion of ARDUINO WEEK 2022 to motivate the student to work in hardware domain.


I also the participated and won prizes in various Events:
1. Won 1st in a national Hackathon in which I created a medical related tool.(MORE INFO)

2. Won 1st prize in International Challenge organized by UpsideDown Labs in which I created a Wireless keyboard cum authenticated password manager with ducky script injector(MORE INFO)


Also, I have build some project using BBB:
On board LED blinking (Video)
LED pattern using 10 L.E.Ds (Video)


Other experience:
I have also designed and fabricated multiple PCB designs which were sponsored by PCBWAY, JLCPCB & Lion circuits for my YouTube channel & Instagram Page


Contingency

I believe that if I get stuck on my project and my mentor isn’t around, I will use the resources that are available to me. Some of those information portals are listed below.
1. Derek Molly's beagle bone guide provides all the information needed for getting up and running with my beagle.
2. Content on e-ALE.org is very useful for information that ranges from tutorials and walkthroughs to the level of very advanced stuff.
3. BeagleBone cookbook from Mark A. Yoder & Jason Kridner is the best source for test projects during the prototyping period.
4. The technical reference manuals provided by TI on am3358 and am5729 are the best source for getting the insights on the SoC used in Black and Ai.
5. Bad to the Bone Crafting Electronics Systems with Beaglebone and BeagleBone Black by Steven Barrett, Jason Kridner


Benefit

If successfully completed, the BeagleBoard.org community will be able to enjoy the compatibility of cape with both BBB and BBAI.Replicape support will also be added to the cape compatibilty layer. Last but not least the timelapse feature directly from the BBB and BBAI board.

Misc

Please complete the requirements listed on the ideas page. Provide link to pull request.

Suggestions

Is there anything else we should have asked you?