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 number 9
Time’s flying now.
Some minor issues with SPI.
So the BBB has 2 SPIs, ones taken up by the HDMI virtual cape, so no worries there. (Although I’d love to add support such that when the HDMI cape is inhibited, I could use SPI1 as well. But that’s for laters.
BB-BONE-BACONE dts uses the SPI0 pins for the 7 segment leds.
So basically the pins are in mode 7. But we need them in mode 0 because we’d like to use spidev ( we could of course bit bang using these GPIO pins, and then we won’t need to work around the dtbo issue)
Right now I am using the dts found here, courtesy of Carl Johnson. But that doesn’t have the rest of the bits required by Bacon board, so I am running into all sorts of errors for PWM, etc. ( who expect them to be loaded by default ). This isn’t that big an issue really. We can change the BACONE dts to reflect SPI mux for the requisite pins, but then that’ll break most of the examples because they need the 7 segment.
Apart from this issue, I had a minor issue with #define SPI_CLOCK_DIVx bits. These are basically used to determine the clock speed of SCLK in SPI. Arduino defaults to 4Mhz which is one quarter of 16Mhz, the system clock freq. Now the dts I am using has a spi-max-freq of 24000000 (24Mhz). Now I want to make this compatible with Arduino without losing out the advantage of having a higher SPI clock rate than the same.
So #define SPI_CLOCK_DIV4 which means 4Mhz in Arduino, would mean 6Mhz in Beaglebone Black.
So do I want to keep it compatible to the SPI examples already with people, or do I want to utilize the full potential of the Black ?..
That’s one more issue I was facing.
Apart from that I had some minor issues with the SPI ICs I was trying out with my Arduino, but that’s done for now.
Really need to pick up speed now. Quite some ground to clear before September 20th.
This week was week #8 at Google Summer of Code.
We’d been planning to do serial for a while, but decided on Wednesday to tackle SPI and I2C first. Serial needs some thinking as we need a way to make things work on all platforms, and we might need serial for that. So that’s on hold for a bit now.
After a very *fair* online lucky draw, courtesy of Andrew, we decided that I’ll be doing SPI and Parav will do the I2C bit.
To get started with, we decided to have a libraries/ folder in our file structure so as to include non-core libraries like I2C, etc. So we had to make the requisite changes in the Userspace.mk file so as to dynamically link those non-core libraries that are included in the code that is being compiled. We already had something like that in our code, which would use some sed magic to get the names of the files that were included in our code and link to them by adding them to ARDUINO_LIBS variable in the makefile. But for some weird reason which I have to debug yet, I haven’t been able to do that. bradfa had the idea that we could include all the libs that are in the libraries folder instead of going through all of this, but for that we decided that I’ll run a few tests that will measure that time and space difference in the build with and without static linking. So that one thing I’ll be doing this week.
SPI is not a tricky bit to be honest. There exists a lot of kernel documentation around that. But the thing is that there are a lot many parameters made available in the structs. So the SPI class constructor will need a lot of defaults to match the defaults set in Arduino. I am referring the online docs at arduino.cc as well as the 1.5 ide branch of Arduino for the same.
I also thought that this would be a good time to reflect on the objectives achieved till now and the ones that are to be delivered by the end of the project. Honestly, there is much to do in this project. We could do so many sample codes, videos, documentation and support more and more boards. But the main objectives that I really want to achieve by the end of September, so that I can say I had a good summer of code are
- Have a very good documentation setup.
Wikis are looking good so far. I need to add details about the functions whose implementations have changed in the wiki. I have already linked the ones that have remained the same to arduino.cc
- Complete the core functions We are almost good on this part. I have listed all the core function on the wiki and most of them are green. Some need working, prominently millis/micros and the interrupt functions. I had began working on millis/micros but that turned out slightly more trickier that I thought. Will come back to that later. attachInterrupt, etc have to be tackled as of yet. But apart from these 2-3, we have all other done
- Most commonly used libraries
SPI, I2C, Serial are the prominent ones here. I’d love to get the LCD lib on board too (I happen to use that a lot on my arduino). Will have to talk with the mentors on this one though. They’ll have a better idea of the things which we should focus on
- Operating System support
Linux is easy. Mac and Windows are not that straight forward.
This bit is tricky. Initially we started working on the Energia IDE. But that got a bit haywire with the number of new repos that we were creating for different parts of the project. So we got it all together and decided to worry about the IDE later. That’s worked out pretty well for us though. Although I’ve mentioned in my proposal that I’d be working on getting all of this to work with the IDE, I am having second thoughts about it now. Never really like the Arduino IDE myself (Emacs user here), but I certainly don’t represent the majority of Arduino users. Having said that, I’d be really glad if we can have a uniform way in which we can have an IDE to write code on the host machine / BBB itself and have the code sent over the black for compilation. That way we make it easier for a user to start coding ( get rid of the cross compiling bit completely ). Plus we have the stdout which we can send back to the host machine if needed so that we can monitor what’s happening ( while compilation or even after that )
Is the Energia IDE the best way to do this ? Well that’s a tricky one. But if we can find a better way to do this I’d be more than glad to do it that way.
Have a couple of pretty decent videos. My last one was terrible to say the least.
That’s all for this week fellas !
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 !
The past week was my second one at GSoC 13.
To be honest, as compared to the first week, this week was slow. I lost the use of laptop, for some hitherto unknown reasons. It was a Dell Vostro 1520, which I was using for almost 4 years now. I still have no clue as to what happened, but I suspect a motherboard failure here (there was no LED activity at all).
So I spent the entire weekend fretting over that.
Luckily I now have access to another machine (a better one when it comes to specs) with almost everything I will be needing. I installed Ubuntu, instead of my usual Debian, to save time in configuring. I figure I have everything that’s needed now ( git repos, tool chains, ssh keys to devices, etc etc)
Before all of these distractions, I was working on setting up the basics for the blink code. Me and Parav have divided the work amongst ourselves for the blink part. I would be taking care of all the functions that will be required for accessing /sys/ as well as stuff like delay, etc. Also, communication over ssh is something else that I am taking care of.
Parav is working on the pin_mux as well as the Makefile. The makfile part is pretty cool. The aim is to enable anyone to just download the libraries and makefile and let them write code using the arduino like functions in their own IDE ( Emacs, Vim, etc). So basically this is for folks who are not exactly newb to programming in general, but are new to Embedded Linux and the BBB.
The testing part which I mentioned in my last post was good. I found out a few minor errors I’d done in my previous code ( value to be passed to the functions should be a char instead of int, among other things). Also, I pushed it here. If anyone would like to test the code, you can just clone the repo, setup ssh keys for your BBB using the instructions in the bash file. And run it as ./send_exec generic_function.c
The code will compile, upload and execute. Right now I have enough functionality to turn on/off a usr_led, export/unexport a gpio pin and set/get its value, direction, etc.
So the next thing I will be working on is the delay function which will allow me to blink a LED. I hope to get this up and running by Wednesday (for the weekly meeting). Once we have the core functionality up, we can tackle bigger things like pwm, adc, etc.
There exists an Internet of Things meetup in my city (Pune, IN), where Arduino hackers meet to work on awesome projects.
Most of the projects that are done here using the Arduino. But we also have a few Raspberry Pi enthusiasts amongst us.
So this week I gave a small demo of the BeagleBone Black (since I got it last week) and we had a nice discussion about the features of the Black, and the differences between the Arduino, Pi and the Black. I also talked about the userspace-arduino project and how we can use the same IDE and the same code/libraries for programming on the Black.
Till next week !
The number of ARM Linux boards is staggering. So is the number of people who are new to them. Actually the whole maker movement is gaining a lot of traction.
Most people start out with the Arduino, because of its simplicity, price, excellent documentation on the site as well as the quantity and quality of projects that have been done using the same. So all in all, the Arduino is the newbies de facto entry point.
A lot many projects have been started to make it easier to start embedded Linux development. Ours is a similar effort.
The project proposes to build a set of Arduino-like libraries for development on the BeagleBone Black. The libraries will be available inside of the familiar Arduino IDE( to be particular in the Energia IDE) . Also, we intend to work on various communication interfaces which will allows us to upload, execute and fetch the results of the code.
Look here for more details on that http://www.elinux.org/Userpace_Arduino
The major objectives that we have in mind are:
- Get the code for GPIO, I2C, PWM, SPI, ADC and Serial to work on the BeagleBone Black, as is. For example, it means a analogRead on a compatible pin on the BBB should work just like it would on the Arduino
- Ensure multiple methods of communication between the IDE and the board
- Ensure that enough documentation is there for someone to get started. It would mean creating or making things compatible to existing wikis.
I’ll be uploading a video with our objectives in detail soon enough.
Cheers till then !