Context Navigation

Final_Report

Timestamp:: 10/07/15 16:17:49 (9 years ago)
Author:: Gedare Bloom
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

GSoC/2015/Final_Report

-                      v3
+                      v4
 All of the students were new to RTEMS. We also had three outstanding new mentors: Ben Gras and Cyrille Artho, who are veteran mentors from other projects, and Ed Sutter, who is new to GSoC but a long-time contributor to open-source. Student projects once again spanned the range of RTEMS: low-level embedded systems work with pins, ports, and protocols; kernel hacking backed-up by formal methods; networking support; video and graphics; application porting; and GUI development for improving the configuration and compilation of RTEMS.
 ref
 Due to widespread student interest, 7 of our 10 projects were in two categories targeting the Raspberry Pi/Pi2 and BeagleBoard Black (BBB) embedded systems platforms, respectively. We carefully divided the labor in these projects to avoid inter-dependency, overlapped the mentors in each category, and strongly encouraged the students to interact and collaborate. Additionally, some of the projects in both boards work with the same subsystem in RTEMS and thus were inter-related. <strong> Grouping related, independent projects together with team mentorship and group collaboration was successful beyond our expectations.</strong> The students were able to help each other overcome similar problems, and the mentoring time was less than if all projects were only loosely related, as in the past. Of special note, Ragu Nath, working with the BBB, was able to help out Yurii Shevtsov when he was stuck for a long time on a problem that his mentors were unable to resolve.
+Due to widespread student interest, 7 of our 10 projects were in two categories targeting the Raspberry !Pi/Pi2 and !BeagleBoard Black (BBB) embedded systems platforms, respectively. We carefully divided the labor in these projects to avoid inter-dependency, overlapped the mentors in each category, and strongly encouraged the students to interact and collaborate. Additionally, some of the projects in both boards work with the same subsystem in RTEMS and thus were inter-related. '''Grouping related, independent projects together with team mentorship and group collaboration was successful beyond our expectations.''' The students were able to help each other overcome similar problems, and the mentoring time was less than if all projects were only loosely related, as in the past. Of special note, Ragu Nath, working with the BBB, was able to help out Yurii Shevtsov when he was stuck for a long time on a problem that his mentors were unable to resolve.
 In preparing for this year’s GSoС, we decided to continue our past tradition of weekly “all-hands” meetings. Student progress, next steps, goals, and problems were discussed in an IRC meeting moderated by Gedare Bloom and Joel Sherrill, two of the RTEMS Organization Administrators. These meetings have continued to be vital for engaging students and defusing problems before they explode. This year students had to post summaries of their status updates on [https://devel.rtems.org/wiki/GSoC/2015 a Wiki page in our Trac dedicated to GSoC 2015]. The same page includes a table with project-related links for each student. The consolidated status updates and project links has made monitoring students easier, and should prove useful for posterity and the next generation of RTEMS developers.
 …
 == Ketul Shah: Beagleboard BSP Improvement ==
 The main goal of this project was to design and implement the different device drivers for BeagleBone Black running RTEMS. The project mainly proposed for major three drivers that are General Purpose Input/Output (GPIO) , Analog to Digital Converter (ADC) and Inter-Integrated Circuit (I2C). These drivers could make RTEMS a great platform for interfacing different sensors and actuators on Beaglebone Black, a popular and cheap single chip computer.
+The main goal of this project was to design and implement the different device drivers for !BeagleBone Black running RTEMS. The project mainly proposed for major three drivers that are General Purpose !Input/Output (GPIO) , Analog to Digital Converter (ADC) and Inter-Integrated Circuit (I2C). These drivers could make RTEMS a great platform for interfacing different sensors and actuators on Beaglebone Black, a popular and cheap single chip computer.
 As a GSoC results the major accomplishments we are able to achieve are GPIO and ADC driver, working on hardware. And we are happy to announce that GPIO driver implementation has been merged with mainline that supports BeagleBone Black and White. With that we could be able to improve Generic GPIO layer. For I2C code it requires more debugging and testing on the hardware. In this project the student learned carefully reading the TRM for the AM335x SOC (BBB & BBW SOC), learning to program the hardware, implementing this in the bsp, and writing a test app for it.
+As a GSoC results the major accomplishments we are able to achieve are GPIO and ADC driver, working on hardware. And we are happy to announce that GPIO driver implementation has been merged with mainline that supports !BeagleBone Black and White. With that we could be able to improve Generic GPIO layer. For I2C code it requires more debugging and testing on the hardware. In this project the student learned carefully reading the TRM for the AM335x SOC (BBB & BBW SOC), learning to program the hardware, implementing this in the bsp, and writing a test app for it.
 The GPIO implementation was done in parallel with the Raspberry Pi BSP. A nontrivial part of this GSOC was coordinating with the Raspberry Pi effort toward not only a single GPIO API for 2 different BSP’s, but also shared C code for the BSP-generic GPIO layer.
 …
 * Started off with creating a draft of the gui and asking my mentors for suggestions and recommendations. Based on the feedback, I had modified the initial draft and sent a new one which was satisfactory and I was advised to start working on it.
 * Created the basic layout of the gui initially - added menus and menu items with event handlers. Created multilayered tab set - to display the options in an organized manner. Also added each option to a group - for displaying in tabs - general, build, network and storage.
 * Using functions written by Amar, I was able to get the options and used general Panels to display it. Later I created option-type (Boolean/Integer/String/StringList) specific panels (True/False radio button for Boolean, Text box for String) with a reset button, enabling users to edit the values.
+* Using functions written by Amar, I was able to get the options and used general Panels to display it. Later I created option-type (!Boolean/Integer/String/StringList) specific panels (!True/False radio button for Boolean, Text box for String) with a reset button, enabling users to edit the values.
 * Created a starting Panel to choose the BSP(s). Passed the chosen bsps to the next panel and only required options are displayed. The options are displayed on tabs - general, host, bsp, [main architecture] and [specific bsp] and each further having multiple tabs based on the groups those options belong to. eg: The bsp arm/beagleboneblack would give the following top tabs: general, host, bsp, arm, arm/beagleboneblack.
 * Obtained values from the gui for the displayed options and using some existing functions in BuildConfig() I was able to update these values and create a config.cfg file in the parent and main waf folder (containing wscript file). Now the users can configure rtems via the gui and run waf configure and waf build from command line for building with the new options.
+* Obtained values from the gui for the displayed options and using some existing functions in !BuildConfig() I was able to update these values and create a config.cfg file in the parent and main waf folder (containing wscript file). Now the users can configure rtems via the gui and run waf configure and waf build from command line for building with the new options.
 * Then I started work on additional features - running waf configure, waf build and other waf targets from the gui itself. I added a output console (a new frame) to the gui in order to display the outputs of these commands.