TL;DR Worked as a GSoC intern at BeagleBoard.org and would love to thank all the people involved.
I had some serious fun this summer.
I’d love to thank Dave for all the amazing guidance that he has been giving us throughout the summer. I, and Parav too, started working on the project even before the student list was put up. We were making small changes to the Dave’s Energia fork then. He has been pushing us in the right direction ever since, and I hope that he continues to do so.
mdp(Matt) and bradfa(Andrew) have been helping us out with a lot of things. We’ve had loads of discussions on #userspace-arduino about coding style, do’s and don’ts in our implementation, pros and cons of implementing a certain thing in a certain way
We were able to complete all the core functionality and were able to add support for commonly used libraries.
Because of GSoC, I got introduced to a *very* helpful community. #beagle and especially #beagle-gsoc have been very forthcoming with any and all kinds of help. The weekly meetings were a fun way to hang out with everyone. I learned how to ask questions (still a bit rusty), etiquette’s of IRC, how FOSS projects really work (basically people from anywhere in the world, having fun, coding and helping out each other). I learned how to write wikis. I learned how much more you can learn from actively participating on community forums and groups. In my case this was the G+ Beagleboard.org group.
A bit unrelated, but because of my association with the community and this project,
- I gave a lightning talk at PyconIndia on using Python with the BBB
- I conducted a workshop at my local hackerspace on using OpenCV with BBB
- I am using the Black for my Bachelor’s thesis which is about Cloud Robotics
- We are building a quadcopter at my local hackerspace using the Black.
Although this formally concludes the Google Summer of Code ’13 part, this is in no way the end. There are a lot more things in the project that have to be done. I’ll be helping to maintain the project along with adding functionality to it.
During the entire summer, I came across a lot many new project ideas. Implementing them during GSoC was not entirely possible because I had to make sure that the promised objectives from my project proposal would be completed. Here’s a list of some associated ideas that I want to work on
- Work on making Userspace-Arduino truly generic
Right now there are some parts in the libraries which are BBB specific. For example, the analogWrite/PWM bit is hard coded for the Black. Get rid of all such bits in the code
- Support more boards
This is basically building up on the above point. Once we have a generic platform, we can easily add more and more boards
- Create custom dts
I had this idea that one should be able to create a custom dts based on the code that has to be compiled. (Assuming that particular function is available in the mux of that pin). Jason Kridner has something similar in BoneScript here. I’d like to create a framework in which we can have a file containing all the possible pin_mux values for each pin for a particular board. Once you give a source file ( in our case a .ino file), it’ll parse the source code and generate a symbol table of sorts with each pin used and the desired pin_mux for it. Based on existing templates, a custom .dts file will be created, compiled and loaded.
Dave had this idea of having a cape on similar lines to the Bacon Board that will make it easier for newbies to get started with all the different interfacing protocols that are available with the Black. So we have I2C, SPI, CAN and Serial on board. A cape which has all the interfaces in a more usable format, with all the right connectors along with software support in the form of the right dts and demo codes.
Have created a project page here. Hopefully it’ll be easy to get started with an idea like this by looking at the works of Michael Leonard and others who participated in the TI Intern cape design contest.
Open Source and Me hereafter:
Before GSoC I was a very passive user of all things FOSS. I relied heavily on it in my projects, but would never contribute back. That was probably because of lack of confidence and a notion in my head that the guys behind these projects are some kind of Jedi masters who know the secrets of the Force (or in this case Source). All of this has changed for the better now, I guess. I feel less intimidated to meet me people, in real at conferences or in forums,channels, etc online, talk to them and share ideas.
The most important thing that I realized during this time was that it’s not about code. It’s not *just* about code. It’s about having something which people would use willingly. Something they’d love to invest their time in to improve. Something which adds value.
I attend quite a few conferences. But now when I think of a conference, I think how I can talk about some topic there. How it’d be cool present such and such topic there and what all I can include in that.
A lot many people who made it big in the open source world started out with Google Summer of Code. My favorite read was about webchick from Drupal who is a core contributor there now. There are plenty of such examples everywhere.
A well spent summer. A good start to for my FOSS journey.
Been a while since I posted what’s cooking with GSoC and userspace-arduino. College has been really catching up on me. The senior year project aka Bachelor’s thesis is taking up a lot of time (luckily that’s using BBB too).
Highlights of what I’ve been upto lately with userspace-arduino
- Updated the wiki. Cleaned up the getting started wiki . Added a new support wiki to list the boards supported.
- Support for LiquidCrystal. It doesn’t require any <avr/*> headers, so was fairly easy. It depends on the Print class which is a part of the core framework. I have a working a sample code here. I have to verify that this actually works yet. So that’s one thing this week.
- millis and micros functions. They have been a pain really. Time is not really a very easy thing to do in Linux, especially if you want to something like millis and micros. Rough overview is that Linux has a lot of processes going on as opposed to a microcontroller. Hence to get a very high degree of accuracy is difficult.
- The Stepper lib depends on the millis function. It has been included in our repo and it compiles with the dummy definition of millis, but it won’t be usable unless I have millis sorted out.
- I have been reading about recipes, so as to help me with packaging the project that we have done.
opkg install userspace-arduino #Write your .ino file like you'd do for an Arduino # to compile userspace-arduino HelloWorld.ino # to run userspace-arduino run HelloWorld.ino
Or something on similar lines. One other way is by using pkg-config, which is a helper tool to link to the appropriate libs. But I am not really sure if this is going to play well with the structure of the project in its current form. I am looking at how opencv does this because I use pkg-config when I am doing computer vision stuff with cpp.
It’s almost the end of Google Summer of Code now. It’s hardly a week more.
I have the following objectives for the next 10 days ( firm pencil’s down is on 23rd Sept)
- Finish SPI. That requires some tinkering with the dts.
- millis and micros function definition
- Have Fritzing images for all the sample codes along with a decent enough explanation where required
This will take some effort as I have to do this for Stepper, SPI, LiquidCrystal as well as PWM and GPIOs.
- Fine tune the getting started page
- An up to date Libraries page
- Populate the ToDo page with what’s remaining
- Have Fritzing images for all the sample codes along with a decent enough explanation where required
- PACKAGE THE PROJECT
- Do something about the pin_mux to make it more generic. This will mean that we have only one BeagleBone Black specific file. That’ll pave the way for more boards in the future (Pi, Minnowboard, xM, etc)
Cheers till then !
This week was week #10 at GSoC.
So this week we got a new assignment from prpplague ! Design a board/cape that you can use with the Black to learn about the different forms of interfaces that are available with it.
So for example, the Bacon board is a good starting point to learn how to use PWM and ADC because it has a slider pot as well as a RGB led on it. Similarly, to use and learn about SPI, I2C, CAN, Serial we can have a cape that has all these interfaces in a usable format with the right connectors. hatguy had the idea of including an audio out too.
The EEPROM will take care of loading the appropriate pin mux. I have created a project here. Will have a working sketch by next week hopefully.
Apart from working on this, I bought a stepper and a servo motor.
For servo, the arduino library is implemented using interrupts, which I haven’t understood completely yet but seems like too much of an effort to replicate on Linux. I have a few ideas on how to have an alternate implementation, but the thing is that we do need interrupts in the Arduino core which haven’t been implemented yet. So maybe I can get two things if I stick to interrupts.
Stepper on the other hand seems fairly straightforward. It doesn’t require any external avr specific libs, so I can use the libs as is under Linux. I have some issues with the stepper I got, but it’ll most probably done by tomorrow if not earlier.
PS: I am attending PyCon India this weekend, and was thinking of giving a simple demo of OpenCV+Tornado webserver+Adafruit-BBIO there (thanks to Koen for helping me out with the python-opencv package). Hopefully I’ll get a slot for a lightning talk and can brag the BBB’s capabilities.
Have created a repo where I keep simple demos for BBB which I can use when I go for a conf or at a workshop.
The last 2 weeks have been kinda slow to be honest.
Well almost the entire last week I wasn’t able to do much because of internet connectivity issues. My oh-so-reliable ISP showed it’s true colors. Crappy customer service combined with technical incompetence is a real pleasure to deal with.
To come back to the point this week and the previous I have been working on some cleanup. Got done with analogWriteResolution. There are some issues with the way I implemented I think, but I’ll come back to that later.
Cleaned up almost all the files using checkpatch.pl so that we now are adhering to the kernel style of C coding (the spaces the tabs etc etc).
Apart from this, I am slightly stuck up on millis and micros function implementation under linux. What i need these functions to do is keep a record of the time spent executing the current function. So what I have to basically do is have store a timestamp when the function starts and then every time millis and micros is called, I get the latest timestamp and subtract it from the stored one and display the time. I have tried doing this with gettimeofday from sys/time.h but the tests had very inconsistent results. I added a usleep of 1000 ms in between taking readings and the output should have (ideally) been 1 sec between each printf. But there was a huge variation in between readings.
Millis and micros are one of the core Arduino functions, so to speak. They aren’t part of any library and are expected to work out of the box. So I am going to have to figure out how to solve this sooner or later.
Apart from this I am really hoping to get done with Serial, I2C and SPI. Serial is a bit tricky I guess, but the other 2 can be dealt with pretty quickly. And they are 2 of the most commonly used libraries I guess.
PS: I cleared the mid term evaluations. 🙂
The past week was the 5th week at GSoC !
This week I finally got done with the video
It’s a bit long and the quality is crappy, but I guess I’ll make one more soon enough and will probably have better quality.
The week started with cleanup in preparation for the mid term evaluations next week. That mostly included moving things around.
Apart from that I organized the wiki this week. Created a category for Userspace Arduino and we have 3 wiki pages now, instead of one.
The libraries wiki needed a lot of work initially but now the initial setup is done and won’t change much. We are going to be providing links to arduino.cc in case of functions whose implementation hasn’t changed (stuff like delay, etc) and we’d be providing an on page reference for functions whose implementation is BBB specific (analogRead, etc)
Once I had the functions listed on the wiki ( in color, mind you 😉 ), I started working on the some of the VERY simple ones. Stuff like bit manipulation, min, max, map(), etc.
So basically, video+clean up+wiki+some minor functions this week.
This week onwards we’ll get on to some of the big stuff like Serial, I2C etc. There is already a lot of talk going on how to go about implementing these on the IRC.
Cheers till next time !
Last week was the 4th Week of GSoC ’13 at Beagleboard.org !
Just like the previous week, this week we were working on getting demos working for the Bacon Cape. We now have the PWM, the ADC and the shift register working.
Basically that means that you can display different colors on the RGB LED, use the slider to get analog values and use the 7 segment LED to display your favorite single digit number 🙂 !
I started out with a little clean up of the previous weeks code and then went on to tackle the 7 segment bit. It was fairly easy as prpplague had already got the shift_out in place. Some of the useful bits were found in the Danger cape demo (an Arduino shield similar to the Bacon Cape) from Sparkfun. Apart from that panto has written a neat bash script to test all the features of the Bacon.
Using that script, the next thing I tackled was the PWMs (well I had said that I’d be doing ADC and hatguy would be doing PWM in my previous post, but then later on we traded our to dos). So I added 2 new functions, one the pwm_export function to load the PWM pins from init(). The other one was the analogWrite function in wiring_analog. It was a slight headache to get all the pins right ( the port pins, the pwm_pins, the ones from gpioDescription, the Arduino pins, etc etc).
Apart from that hatguy and prpplague got the ADC working. Also, prpplague tested some of our code on the Minnowboard and it worked fine ! So that’s a good indication that our code is generic enough and will support loads of other devices in the future.
This week we will be working on clean up and testing mostly. A lot needs to be straightened out. Some demos work as is for some people while some of the mentors are having trouble getting them to work. So we will be working on getting all the documentation right. mdp and bradfa will be helping us out with this part a lot. Me and Parav are already getting a lot of feedback from all 3 mentors about the stuff that’s already up, and this week we’ll be working on getting some more and straightening out the wiki, etc
All in all, a good week 🙂
Till next time !
Last week was the 3 week at GSoC ’13.
Most of the week was spent on clean up of the existing code that I had written for the sysfs functions. Apart from that I also added the set_direction pin for GPIO.
The second major thing was adding error control to the existing functions.
After this, we started working on demos for the Bacon board. hatguy whipped up a demo for the user button on the board, whereas I am working on the 7 segment LED. Arduino has a library for 7 segment LEDs, which we will adhere to, and there are a few demo scripts for Beacon board too. This requires device tree overlays, as this 2 of the 3 pins are not muxed as per required.
This week we will be working on getting more demos for the Bacon board, hatguy has already started working on the PWM for analog write (think RGB LEDs on the Bacon). I’d be most probably working on the ADC bit once I have 7 segment in the bag
Till next time !