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.
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 !
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 !