Stochastic Geometry

So it seems that getting shot in the face by a robot can actually pay long-term dividends.

By which I mean that after all the time I spent building and debugging hardware in the now-defunct Computer Vision and Robotics Research Group, I’m now one of the decreasing handful of people in the CS department who knows hardware. Which sounds odd from the outside I suppose – most non-computer people I know seem to think that anyone with a degree in computer science or computer engineering knows how to do anything and everything to do with computers. It doesn’t actually work that way, the same way that a neurosurgeon wouldn’t be able to deal with a pandemic; the field is specialised in both cases to the point where specialists aren’t interchangeable anymore, at least at the deeper levels of specialisation.

That’s not to say that there’s no knowledge of hardware outside of the few people who’re working on hardware-level research; it’s more that those working in (for example) formal methods would be misspending their time if they spent time building hardware. It’s got nothing to do with what they’re working on.

At any rate, because of this, I’ve been assigned to teach the CS7004 course, which is the introduction to embedded systems on the Mobile and Ubiquitous Computing MSc course. I’ve done a lecture or two before, along with six years demonstrating to various courses and three years TAing for two other courses and teaching commercial courses outside of college but this is my first actual post as a college lecturer. I’m rather looking forward to it.

And we’ve got some nifty hardware to use as a platform; we’re moving away from the chips we used to use (68000’s, 8051’s, PIC chips, BASIC stamps, SunSpots and so forth) and several of the hardware courses are now going to standardise on using the ARM7TDMI core in an LPC2468 microcontroller chip, on a Keil MCB2460 evaluation board:

There’s a lot of useful stuff on there; the LPC2468 is on the red daughterboard in the centre; there’s a QVGA resolution LCD on the side, with a touchscreen. So for later exercises, setting up a user interface may well be useful. There are four push-button switches and LEDs controlled from an I2C-linked chip, A/D converters, CAN and UART interfaces, an SD card slot, built-in ethernet, the works.

In fact, one of the main problems I have is that the board does too much – the traditional “push a button and turn on an LED” exercise becomes more complex when the buttons and LEDs are controlled by an i/o chip linked over an I2C bus!

The main challange I’m encountering in fact, is similar – embedded systems is such a large field that any introductory course has to pick and choose. And how do you decide what’s important? And how deeply do you cover topics? In a way, the course winds up being a reflection of the lecturer.

There is, of course, a lot of research that has been done into how to teach embedded systems courses, what should go into them and so forth – the ACM in particular has published a lot on this – and that’s my current reading pile. Hopefully it’ll prove useful – certainly the didatic analysis paper by Grimheden and Tomgren has helped crystallise some ideas. And hoepfully, I’ll get to continue to comment on the course during the semester.

But I definitely wouldn’t have seen this coming the day that I shot myself in the face with the ceramic remains from a power transistor which popped after a bug in the code burnt into the programmable logic on the board shorted a pair of 12V lead-acid batteries across it. Hopefully, I can teach this course so those taking it don’t learn their lessons in such a visceral fashion…