Hi Michael, 2010/10/22 Michael Adeyeye <[email protected]> > (financial and academic) from the community.The research areas would require > buying some SDKs. I have been able to classify them into three, namely User > Equipment, Communication/Network, and Andriod SDKs.
I have generally been careful with hardware commitments for courses. It moves at a fairly rapid pace (or the software supporting it does), and our capacity to constantly redesign courses is often limited. So, my comments are from the perspective of someone who looks at hardware investments in courses with a view that the equipment will see 5 years of use. > User Equipment Software Development Kit > Deliverables: Students will be guided on how to develop and port Operating > Systems (OSs), applications and packages to the UEs. Each course has its > deliverables; so, the kits could also be used in some other courses. This strikes me as a very ambitious goal. Do you have a very strong programme in C and hardware-level development already? OS development and porting is, as far as I know, absolutely non-trivial work. My graduate course in Operating Systems used NachOS (see http://www.cs.washington.edu/homes/tom/nachos/), where we had a complete OS for MIPS, a complete emulator for MIPS, and we would write OS components that would be linked into a known-good environment. We then used GDB (and, admittedly, the occasional printf) to debug our (say) filesystem implementation. This was doable because a crash on a virtualized MIPS due to memory corruption or similar was... virtualized. If your intent is for students to do OS-level (driver, etc.) work on real hardware, you're going to need more than just the hardware. I think you're also going to need very powerful debugging tools (ICE, or in-circuit emulators), so that the students' code can be executed and single-stepped on the actual device. See http://elinux.org/BeagleBoardJTAG for some example hardware. (Jeffrey Osier-Mixon may have more to say on this, and I think he's on this list. In fact, he works at a company that does Linux OS work for embedded systems, so he should have some insight here...) (http://www.oscon.com/oscon2010/public/schedule/speaker/44871) I am *not* saying that real hardware in student hands is a bad idea. I am saying that I would think hard about doing board-level work in a course, unless you are a hardcore ECE programme that expects students to have this experience. > Quote > > The required kit is Beagleboard (ARM kit); see > http://search.digikey.com/scripts/DkSearch/dksus.dll?PName?Name=296-25798-ND&Site=US&Lang=EN > for the ARM kit (also see http://beagleboard.org/hardware-xM for some > information on the ARM processor) > Product = KIT DEV BEAGLEXM > Unit Price = $179 > Number of units = 3 > Total price = $537 The Beagleboard has seen one shipping hardware rev in less than three years -- this will be "out-of-date" by the time you use it, but should have a 5-year utility for you overall. You really should invest in at least one JTAG for the Beagleboard, and someone else on this list can recommend a good choice. You may want to consider building small enclosures for the boards, so that the students are less inclined to touch/poke at the board and possibly damage the electronics through electrostatic discharge. (This will add a cost to each board.) Also, is it your intent to dedicate monitors to them, or will the students plug-and-unplug the boards? Note, if you want to explore operating systems in the small (and, perhaps, *too* small), you can look at projects like those listed here for the AVR: http://www.edaboard.com/thread25778.html You can get into AVR-based boards for $20-30, meaning you could get 20 for the price of two BeagleBoards. That said, they're far less capable in other ways. > In addition, I would need 2 ARM cameras; see > http://shop.leopardimaging.com/product.sc?productId=50&categoryId=10 > Product = 5M MT9P031 Camera Board > Unit Price = $79 > Number of units = 2 > Total price = $158 If you ever wanted to use your boards as robot controllers, you'd want a lot more. Also, do you have soldering irons and other equipment for light electronics work? Do you think you will need it? > Network/Communication Software Development Kit > Network software refers to applications that run on connecting devices. Focus > here is on Wifi/access point (AP) devices. Unlike UE equipments that use ARM > processors, most network devices use MIPS processors. This will give us the > opportunity to explore the two processor architectures. > Deliverables: Research interests include porting lightweight Operating > Systems and packages to the network devices and development of some new > services. I have the same deliverables concerns. Given a full semester and nothing else to do, I think I could take on the task of porting a small OS or similar to a new architecture... maybe. I don't know your expertise, your programme, or your students, though, so this may be a reasonable deliverable. > The required MIPS kit is http://store.mips-store.com/dev-boards.html (see > http://www.mips.com/products/development-kits/linux-starter-kit/ for some > information on the kit) > Product = MIPS-based Development Boards > Unit Price = $149 > Number of units = 3 > Total price = $447 I would make a case for why real MIPS hardware is desirable vs. an emulator for this. Having *some* real hardware is a Great Thing, but it is hard to master multiple architectures quickly. My personal recommendation would be to invest in one architecture (ARM), and stick with it. While it is true that there are different architectures out there, students who master one will be in a good position to master others, while students who have not mastered any will, perhaps, just become confused between assembly languages, calling conventions, symbolic register constants, interrupt vectors, and the like. > Software Development Kit for Andriod Devices > > While the UE software specifically refers to Linux OSs and applications, > android applications would also be considered. > Deliverables: Students will also be guided on how to develop and port > Andriod, its applications and packages to the andriod UEs. > Quote > > The required kit (andriod porting kit) is > http://02f0fbc.netsolstores.com/arribaandroidadoptionkit.aspx (also see > http://www.mips.com/products/software-tools/arriba-android-porting-kit/) Again, I have no idea what kind of academic programme you are working in. Do you have classroom full of operating systems ninjas? The dev board you pointed to is a professional piece of equipment designed to support development and testing of code for shipping hardware. If you want your students to explore Android development, they can do it cheaply with an emulator (which will be debuggable, with a debugger, directly in Eclipse, which is free too). You could get some cheap Android devices and give the students the opportunity to develop apps *for* Android as well as test patches to the OS that they made in their emulators... but they wouldn't be able to debug OS crashes on the real devices. That said, though, it strikes me that they have a lot more opportunity to be creative and innovative if they have actual endpoint devices (and more than one) rather than a single dev board. > Product = Arriba Andriod > Unit Price = $995 > Number of units = 3 > Total price = $2985 For this price, you could probably get 5-6 Droids, and possibly more if this community worked with you to find a way to source them at less than market cost. > and cheaper kits I could use. Is there any other software or kits my students > could also try out? Please let me know. Braindumps on what has worked and has > not worked at your end are also welcome. I tried to give you some ideas. I have absolutely no context for your programme or your students. What I do know is that I have never taught anywhere that I could put the $4000 of equipment you describe to good use. The BeagleBoards I could use for end-user development in an embedded context, but I would be hard pressed to use them to teach the fundamentals of operating systems, as I would not consider OS-level driver development and the like to be accessible/appropriate on real hardware... unless I was *explicitly* out to teach how to do hardware level development for a *particular* architecture on a *particular* board. It sounds like you want students to explore: * Embedded Linux * Android These are two very different operating environments, which alone is worth thinking about. You seem to be proposing all low-level work, which is *very hard* work. Again, I don't know you, or your students -- this might be "what you do." I, myself, have found porting a virtual machine (or runtime environment for a parallel programming language) to the AVR to have plenty of ups-and-downs, and I don't have lots of time to hack on it other than on breaks. If there are no "ready-to-go" curricula for what you propose, you're going to find that you have *lots* of work to do to adapt traditional operating systems course material to, say, doing development work directly on real hardware. Those are my concerns/questions. I'm 100% in favor of having real hardware/devices in students hands, but I'm also 100% about students having positive, successful experiences in doing so. Its the latter part that I'm concerned about from your descriptions, largely because I know I personally would be very hard pressed to do what you describe in the kind of time your students will have to do the work. Cheers, Matt _______________________________________________ tos mailing list [email protected] http://teachingopensource.org/mailman/listinfo/tos
