I have received a large number of mails regarding this topic, so I felt it would be best to address everyone here instead of sending out 20 mails to different people.
The important portion of this topic is the “hardware interfacing” portion. While the final deliverables will probably be Android apps and their associated native code, the apps themselves can be considered the less difficult part of the project. Thus, a strong proposal on this topic will focus more on interfacing with the hardware that it will on app development.
You should have three goals at the moment:
- Learn enough about the BBB to be able to explain the various hardware peripheral interfaces it offers.
- Be able to explain the general process for developing hardware interfacing code under Linux.
- Develop a proposal that explains how you plan on creating this hardware interfacing code and then adding it to an Android app.
If you are an app developer, then the third item should be very straightforward. Using an AsyncTask instance to call JNI code would be a valid approach, for example.
So, let’s say that you’ve read some documentation on the BBB and you like the idea of interfacing with GPIOs, I2C, SPI, etc. What next? Well, you can do a few Google searches and find some code that talks to these interfaces, or you could look through the BeagleBoard.org project list to find a few libraries that do this sort of interfacing via mmap() and file I/O. Can you build these libraries under Linux on the BBB? Do they work for you? If not, why? Do you think that, if you had the hardware, you would feel comfortable connecting components to the BBB and writing a few simple programs to use those libraries to talk to hardware?
Once you get that working, do you think that you could pull the necessary pieces of a library and your own code into an Android app and call it via JNI? How would you encapsulate the hardware interfacing logic into the native code so that it is fairly generic? Is your C/C++ strong enough that you can fully understand these existing interfacing libraries? Do you think you could create something that interfaces with hardware like the Bacon Cape?
IF YOU HAVE A BEAGLEBONE BLACK BOARD:
Have you ever interfaced with GPIOs before under Linux on your BBB? If not, have you googled for any tutorials (like in the tutorial links I posted earlier in this thread)? There are many examples out there for you to learn from. Which have you looked at and tried? If you have tried the very basics before, you’re well ahead of the game. You should try at least one simple hardware interfacing project under Linux prior to submitting your proposal so that you have an idea of what you are getting yourself into.
IF YOU DON’T HAVE A BEAGLEBONE BLACK BOARD:
What research have you done? Have you downloaded any Linux interfacing libraries for the BBB and looked at the code? Have you worked on any other Linux platform and interfaced with hardware before? Have you downloaded and read the BeagleBone Black System Reference Manual? Can you explain how I2C, SPI, PWM, ADC, etc. work?
I am seeing potential candidates interact with the mentors in one of three ways:
- “I have read XXX like you suggested. Now what do I do?”
This isn’t very hopeful for us as mentors, as we hope that you’ll take the suggested references as a starting point for your own exploration and research. Yes, it is good that you read them, but what did you learn? What do YOU think you should do next? Did you look at any existing projects or libraries that use what you learned? This project will be YOUR PROJECT. The mentors will help you define the scope and details of your project for your proposal, but it is up to you to become the “expert”.
- “I have read XXX like you suggested. I found a few examples that show how I can do ABC and XYZ, but I’m not sure if I will be able to do both ABC and XYZ together at the same time. Is this a common problem?”
This is far more promising. You’re clearly showing that you’ve read the starting references and then performed your own research to see what you should be doing and are asking for clarification on it. You may not be an expert, but you’re demonstrating that you can see a bigger picture on how everything fits together. GSoC will probably be very informative for you, but you will have to work hard this summer to get to where you need to be for success.
- “I am already familiar with XXX, and I read on this blog/mailing list/tutorial about a BeagleBone Black hardware interfacing library ABC under Linux. Do you think I could leverage this for the project? It provides interfaces for X, Y, and Z, but I don’t know if the interfaces have changed between the 3.8 and 3.14 kernel. I tried building it and it crashed on 3.14, so I tried it with the 3.8 kernel instead and it worked without a problem. What more can you tell me about this?”
This is the best-case scenario. You’re clearly interested in the topic, you’ve done the background research, and you have a general plan on how to approach the project. You may not know all of the details that you need, but you know enough that the details are only details. GSoC will probably be very rewarding for you and a lot of fun. You probably won’t struggle, but you might get stuck a few times. GSoC is designed to produce code that is useful and non-trivial while giving you the chance to take your skills to the next level.
This topic is about hardware interfacing. Yes, it does involve writing Android apps, but that is far less important than understanding hardware interfacing. If you are an app developer with no experience in hardware interfacing, I suggest that you consider a different topic.