Previously

Give assignments

Since July, when I wrote Part 1, I got married, joined a C-based project, rolled off, joined a new project, and moved house.

One of the recommendations in Part 1 was “take assignments.” The reason I’m finally back for Part 2 is that I’m running a workshop on Saturday. If you’re having trouble making time to learn something, try committing yourself to teach it.

Trust your doubts

I’m supposed to deliver two hours of hands-on “Fundamentals of C and Embedded.” Having worked in C professionally for some weeks — and embedded systems for zero — I certainly don’t know any more than the fundamentals. It could be the case that I know less.

I don’t have to be an expert at C or embedded to deliver what I’ve promised. I do have to be an expert at noticing, of all the things I don’t know, what’s bothering me the most right now. Over and over again.

One question at a time

Even though a Raspberry Pi is a general-purpose computer, in the workshop we’re going to treat it as an embedded system. By that, I mean that even though we could easily develop software directly on the Pi, we’re going to pretend we can’t. Or another way: even though it’s actually reasonably quick and cheap, we’re going to pretend it’s slow and expensive to deploy and test on the “target” system.

As I was preparing the workshop, here’s what I didn’t know that bothered me the most, in order:

  1. Can I write C to drive some visible feature of the Pi? See whether I can get the onboard LED to toggle. Result: it works.
  2. Can I cross-compile some C code? Try adapting Roman Numeral Calculator to optionally target the Pi. Result: it works.
  3. Can I link with one implementation of an interface for the host and another for the target? Yes: the native Mac build prints “gonna toggle the LED” and the Pi build really toggles it.
  4. Can I instruct the Pi build (and not the native Mac build) to depend on that cross compiler, and to rebuild it if it’s missing? Yes (and I’m glad I kept my notes and got it right on the first try).
  5. Can I link with real system calls for the target and custom fakes for the host? Yes, and this supersedes what I learned in (3): with fakes for open(2)/ioctl(2)/close(2), I can get rid of the fake implementation of led_toggle().
  6. Can I now write microtests for led_toggle()? Yes, and in so doing I found and fixed some behavior that didn’t meet my expectations.
  7. Am I now qualified to run a workshop that claims we’ll “test-drive a Raspberry Pi from a Mac”? I believe so.

Conclusion

Am I ready to run the workshop? Not quite. I want to make sure that in our two hours as a mob, test-driving C in Vim, we get the satisfaction of toggling that LED.

How fast we get there depends on how well we test-drive (our company prides itself on this), how well we know C (depends on who shows up), and how well we can deal with Vim (same). It’s possible that our pace won’t be fast enough; I’ll want to have thought about how to speed us up. It’s also possible that we’ll blow right through it; I’ll want to have thought about what more we could do with our time.

I’m still no expert in C or embedded systems, but the state of my knowledge is no longer the bottleneck to delivering a valuable version of this workshop. Wish me luck!