Today I finally got to try my MEPROM-equipped Lego Mindstorms robot with a larger group of kids. As expected, this did not go quite as expected.
When I got the Lego Mindstorms robotics kit that I have been blogging about before (1,2,3), one of my goals was to try my hands on some graphical “model-driven” programming. Thanks for the various tips for other more traditional programming environments that I have received over comments, Facebook, and personal email. But my main goal was really to try to use the NXT environment as a graphical, domain-specific, rapid programming environment. Having played around with some simple projects for a couple of months now, it is clear that somethings are easier to do than others.
As discussed in my previous blog post about Kindergarten robots, I wanted to see if I can teach kids the core idea of programming. This project has now progressed to the point that I have a working prototype of a programmable robot.
Essentially, the robot is programmed by putting colored Lego bricks in a sequence on top of the robot. This should be accessible and direct enough to work with kids — and with no computer needed, just direct physical interaction with the system. For some reason, I think the extra level of abstraction from a screen to a robot is just an unnecessary obstacle at this level.
The discussion on my previous blog post about “the ideal ESL language” made me think some more about the purpose of a hardware modeling or description language. If you look closely, you realize that there are two quite different goals being pursued by the tools and languages discussed there.
On one hand, we have the task of supporting the design of new hardware bits, for the purpose of creating it. On the other hand, we have the task of describing a particular design for the purpose of simulating it. These two are not necessarily the same.
One of my little projects while on parental leave has been to play around with my Lego Mindstorms NXT 2.0 robotics kit. Apart from being fun for a serious dad like myself, I always had in mind how I could use it with kids to get them interested in technology.
When I was a PhD student in Uppsala back around 2000, we bought a pile of the Lego Mindstorms RCX kits, for use in real-time courses. Obviously, the students loved the opportunity to play with Lego (including the few females). What was less obvious and much more interesting was what happened when we brought in a bunch of children from a local kindergarten to visit — they really took a liking to our little yellow robots running around a classroom. They treated the robots as little animals, wondering what they were doing and why…
With that in mind, I decided to try to reprise this myself with my own son and his kindergarten friends. 
Last week, I took my robot kit with me and went to meet the kids.
We recently had a malfunction in our spam filters at work, so I had to go back and review the catch for possible false positives. I sort things into two bins using spamassassin, one for most likely spam, and one for probable spam. When things started to go bad, the most likely folder had reached more than 2 GB, and the probable some 500 MB.
In his most recent Embedded Bridge Newsletter, Gary Stringham describes a solution to a common read-modify-write race-condition hazard on device registers accessed by multiple software units in parallel. Some of the solutions are really neat!
I have seen the “write 1 clears” solution before in real hardware, but I was not aware of the other two variants. The idea of having a “write mask” in one half of a 32-bit word is really clever.
However, this got me thinking about what the fundamental issue here really is.
An embedded researcher friend of mine has posted some data on code sizes from various compilers at http://embed.cs.utah.edu/embarrassing/. The “embarrassing” bit is the idea that compiler writes should be ashamed when other compilers do better than theirs. It is worth looking over the data, even though the methodology and benchmarks are not yet perfect by any means.
Last week, I finally got the last “OK” from the maintainers of GDB, the Gnu Debugger, indicating that my contribution to the GDB project was accepted. This is my first contribution to an open-source project, and the piece of code that has my name on it is positively puny. It is actually not really code at all, it is just a piece of documentation, for the extensions to the GDB-MI command set needed to support reversible debugging. The actual code doing the work was contributed by a colleague of mine, Tomas Holmberg, credit where credit is due.
I just won a battle against Eclipse, managing to finally rid myself of a string of strange out-of-heap warnings. It is a long story, involving lots of web searching and fiddling with the eclipse.ini file options for the JVM. It just never seemed to work as I wanted it to, despite changing the -Xmx VM argument to 256, then 512, and finally 1024m.
For my parental leave, I have just bought myself a Lego Mindstorm NXT 2.0 kit. It is not much fun for our youngest, who mostly gets a bit scared by a piece of Lego driving around making noises, but I hope to be able to use it to teach my older child (almost five) to program. Let’s see how that turns out. It looks hard to make the NXT environment provide the kind of Roborally-style programming blocks that I had hoped to create, as I cannot for some reason get a sufficiently custom icon onto custom blocks.
It also presented me with an opportunity to try some domain-specific high-level graphical programming. The programming environment provided for the NXT series of Mindstorms kits is based on LabView from National Instruments, and it really does seem to work. It even features parallel tasks, which I tried to use…
For the next few months, I will be on parental leave, so there is likely to be less blogging about technical subjects (and less blogging overall). There is simply less inspiration about virtual platforms, and a bit more about toys.
During the Christmas holidays, I got the chance to compare my oldest child’s brand new Lego set with some from the mid-1980s. It is quite striking how much larger the things in the sets have become, and how much more affordable (in relative terms) Lego has become since then.
We bought some ski goggles for our kids… and look who have infiltrated that business:
Continuing on my series of posts about checkpointing in virtual platforms (see previous posts Simics, Cadence, our FDL paper), I have finally found a decent description of how CoWare does things for SystemC. It is pretty much the same approach as that taken by Cadence, in that it uses full stores a complete process state to disk, and uses special callbacks to handle the connection to open files and similar local resources on a system. The approach is described in a paper called “A Checkpoint/Restore Framework for SystemC-Based Virtual Platforms”, by Stefan Kraemer and Reiner Leupers of RWTH Aachen, and Dietmar Petras, and Thomas Philipp of CoWare, published at the International Symposium on System-on-Chip, in Tampere, Finland, in October of 2009.
