Recently Mike Karlesky and I spent a week in the Baltimore area leading up a workshop-style training course. The intent of the workshop was to demonstrate Agile techniques applied in the embedded domain.

As part of the workshop, I created a small GTK application to demonstrate Presenter First and Model-View-Presenter. (Although a GUI application may not seem particularly embedded, the principle is the same: the view walls off some untestable library; the presenter and model allow us to test around it.) GTK turned out to be a good choice, since the events flying out of its widgets were much like the asynchronous events that come out of other windowing toolkits or hardware devices.

And here it is: the aptly named PF Calculator. Guess what? It’s a calculator. The calculator’s functionality is quite limited, in that it can only divide integers, but it still demonstrates Presenter First concepts quite well:

• The ApplicationPresenter responds to events from the ApplicationModel and ApplicationView.
• The ApplicationView fires events roughly corresponding to events coming from GTK widgets. Along the way, it does some translation to only relay the relevant information and remove traces of GTK in the event.
• The ApplicationModel is used to compute the “business logic” (haha, I love that term, especially when applied in such a silly context). The Model delegates to the NumberValidator to get some help when needed.
• And last (but not least), all of the above code was written Presenter First.

Everything is implemented in C. Here are a few notes about the implementation:

• In a language with automatic object construction, I’d have the Presenters wire up their events in their constructor methods. Since that strategy isn’t available here, I’ve instead implemented a Presenters_RegisterForEvents function. The purpose of the function is to rip through all of the Presenters and tell them to RegisterEvents. It would be trivial to have the build system automatically generate this file in a project with many Presenters.
• I only support one subscriptor to any single event. This is because I didn’t feel like implementing a bounded array or linked list to hold the function pointers. I did see something about a GSList data structure available in the GLib documentation, but I never got around to trying it out.
• I call the gtk_init function in main before firing up the application. I’m not wild about this GTK-specific knowledge leaking outside of the view, but for this very simple example, it was the cleanest way to handle this detail. In a real project I’d strive to keep GTK specifics confined to views.

I depend on a number of libraries and tools to get them job done. More notes:

• I’m using the Ceedling build and test harness developed by Mike Karlesky, Greg Williams, and Mark VanderVoord. Ceedling gives me easy access to unit testing via Unity, C mock generation via CMock, and C exceptions via CException. Ceedling also weaves everything together to create the executables.
  • Ceedling hasn’t had a 1.0 release yet, but the code available from the Sourceforge project is quite functional.
• I used this project as an excuse to monkey around with the PCRE library. I didn’t use it extensively, but it was enough to get a taste. It turns out PCRE is tasty.
• I also recently heard about bstring and tried it out. Again, I didn’t use it for much, but enough such that I’m sold on it.

Warning: I haven’t tried to build this code on anything other than my personal Linux system, so I can’t say how portable it is. Here are some details about my system:

• The Linux distribution is Ubuntu 10.04.
• The GTK development files have been installed via the libgtk2.0-dev package.
• The PCRE development files have been installed via the libpcre3-dev package.
• bstring is bundled with the project.
• The build system relies on Ruby and Rake. The build system uses pkg-config commands to gather the build flags for PCRE and GTK. Hopefully this means it will be easier to build the project on an arbitrary system.

To build and run the application, type rake. To run all the tests, type rake test:all. To test an individual module, like ApplicationModel, type rake test:ApplicationModel.c.

Big thanks to Mike Karlesky for assisting with Ceedling, CMock, and Unity. Also thanks to Greg Williams and Mark VanderVoord for helping develop this great software.

Resources:

• The pf_gtk repository hosted on GitHub.
• pf_gtk tarball
• Presenter First information at Atomic Object.
• Ceedling build system and other useful C tools.

Edit July 13, 2010: The article was initially published without the Ubuntu package names filled in. This has been corrected.

(So, in reality, D probably isn’t all that little, but here’s to it making it up the mountain.)

A good while ago I wrote a post about my hope for the D programming language as an up-and-comer in systems and embedded programming. D promises to bring a number of modern language concepts and constructs to low-level systems while yet producing a fairly efficient runtime. It’s 3 years on since my original post, but I’m still hopeful.

Just a few days ago a comment came in on my original post. My friend Mark VanderVoord responded in that comment thread. I thought I’d make the content of the thread a bit more visible (below) as it’s concerned with using D in the real world.

There’s been respectable progress toward D becoming viable in the mainstream. I’ll venture a guess that it’s going to be several more years until it truly is.

Update (7/1/2010): We don’t often attract a great many comments on our posts. But we have here. I point it out because there’s good resources, background, and perspective on D in the comments. Take a read. The original comment thread that sparked this post can still be found beneath this update.

Since our comments can’t contain links, I’m listing & linkifying here what our commenters have referenced:

1. Steve Klabnik pointed out a new kernel project written in D (Steve is one of the authors)
2. Kevin Bowling recommends the book The D Programming Language written by another of our commenters Andrei Alexandrescu
3. Descent is an Eclipse plugin for D
4. Several have compared/contrasted D to the new Go programming language by Google

Update (7/6/2010): Commenter devdanke suggested Apple as a D corporate backer. Google seems to be pursuing Go; why not Apple getting behind D? Apple certainly has a lot invested in LLVM of late. Apple may just be up to something—though I’m doubtful it’s D. Time will tell…

slide Says:
June 25th, 2010 at 07:35 PM

Is there any active development that you know of to get D running on embedded, bare-metal type platforms?

Mark Says:
June 25th, 2010 at 11:01 PM

slide:

This is the current state of things as far as I know:

The official D versions (D1 and D2) by Digital Mars (DMD) are only x86 so far

GDC – this is a D front-end with a gcc backend. Theoretically this means you can target anything gcc can (which is almost everything). The work I’ve done with it (mostly ARM) has been pretty tricky to get working, though.

LDC – this is a D front-end to LLVM. Again, this means you should be able to target anything LLVM can. LLVM has a lot of momentum lately… and this port seems to be pretty active too. I have done some small experiments with getting it to target an ARM9. It seemed to work well. I hope to have more time to work on that in the future.

For either LDC or GDC, you’re getting D version 1, which is missing some of the new (in-progress) features. But, they’re more stable, so that’s nice.

D links easily to C, so bringing in libraries, RTOS’s etc is pretty easy.

I hope this helps.

Mark

When asked what sports they play, most high school students typically respond “football,” “baseball,” “basketball,” or “soccer.” I, however, get to respond with something much more interesting: “robotics.”

The sport I am referring to is the FIRST Robotics Competition, a high school level competitive robot building competition. Teams from around the world, 1,808 to be exact, compete against each other every year in a world wide challenge that culminates at the Championship held in Atlanta, Georgia.

I first started competing with the only FRC team in Grand Rapids, Creston High School’s robotics team, but eventually several members and I began looking into forming our own team closer to where we lived. In late October of 2009, those of us who lived in the Forest Hills, Ada, and Cascade areas of Grand Rapids decided to form the COMETS (Creating Outstanding Minds Embracing Technology and Science) only a couple months before the 2010 season began.

This year our challenge was to build a robot that could play a game called Breakaway basically a mixture of soccer and steeplechase, where robots competed against other robots in games of three vs. three. With the help of many local area sponsors, and great mentors (local engineers, programmers, and businessmen who guide team members in their efforts), we were able to build a highly competitive robot in the six weeks we were given. In fact, we won the West Michigan District event, placed 20th in the state, and won our division in the Championship. Not too bad for a rookie team.

But the most important part of the season was definitely not our win/loss record. It was the fact that students learned new skills in CAD and metal fabrication, programming, web design, 3D animation, and marketing. Just as important is the fact that students experienced how much fun science and technology can be, and built partnerships throughout our community (in fact, it was through Atomic’s sponsorship of local area teams that I first became aware of their internship program).

However, it’s easy to say that in retrospect.

In the three years that I have been involved with robotics, I’ve had seasons where the team has lost almost every single match, as well as seasons (recently) where we did incredibly well. But in all honesty, I only remember a handful of matches we played. What I do remember is the important stuff.

For example, I remember how in 2008 I scoured the Internet and Home Depot to find a material that would trigger the robot’s photoeyes when our ‘bot’s elevator passed them. I remember in 2009 when the FRC switched from a PIC based microprocessor to the powerPC based cRIO from National Instruments, and how I had to learn a new, object oriented language that came with it. I also remember how this year the other programmers and I wrote multi-threaded Java software so our robot could efficiently manage user input and a live camera feed.

The FRC creates an environment where being interested in science and technology is alright. That environment then goes on to encourage problem solving, creativity, and a strong team spirit. For me, this environment gives me an outlet where I can learn and create with people who have the same interests as I do. I could go on, but I think that you get the idea: this robotics competition is actually much more than just a sport.

Our first publicly available iPhone application is now available in the iTunes Store. It's an application for the book A New Earth by Eckhart Tolle. Working with our partners at Six Voices, we developed a framework called TapStack which provides a card-based system for viewing and navigating content on the iPhone. The application was designed to provide a very realistic sensation of working with a deck of cards.

You can check it out on iTunes.

There were some interesting experiences with iPhone development that we'll cover in future blog post. One useful tip to know is that the UIImage class will try to manage its own memory if you construct it using the initWithContentsOfFile: method. This means it will unload and reload the image from the file as needed, which can kill performance if you're dealing with a lot of offscreen images that need to be shown on screen quickly. Using initWithData: using an NSData will let you manage the memory yourself.

Jack Ganssle gave a great talk at XP West Michigan last night. The theme of his talk was famous software failures and lessons learned. His personal mission seems to be raising awareness of the root causes of failures to help the embedded community improve its craft. The astounding thing I learned from Jack’s talk was the mundane nature of the common root causes of these failures.

Read the rest of this entry

Everybody who gets excited about requirements management and documentation – raise your hand. Okay. Thank you. You’re free to go. For those left – you can mate automated tests with a bit of convention and scripting magic to simplify your requirements management life. Here’s how.

Read the rest of this entry

Greg and I attended Embedded Systems Conference Boston 2008 a couple weeks ago. We presented an Agile Project Management class and a session on Feature-Driven Design with our friend and colleague Mark Vander Voord.

It was a markedly different experience this year versus last.

Read the rest of this entry

It’s been a long time coming. Funny how real work can get in the way.

• Unity – Unit Test Framework for C
• CMock – Mock Object Generation Framework for C
• CException – Exception Handling in C

Unity and CMock began life as quick and dirty little tools Atomic Object used internally for our first client embedded projects. CException was born in our most recent X-Rite work. Our colleague at X-Rite, Mark Vander Voord, made significant contributions to all three – especially CException since he wrote the whole darn thing.

Video from my presentation at RubyConf 2007 (Enhancing Embedded Development with Ruby) is now available at the Confreaks website.

See the full video

I’ve just given this presentation at Rubyconf 2007. And now you can enjoy it too:

Keynote file: Enhancing Embedded Keynote

PDF version: Enhancing Embedded PDF

Video: Full Video from Confreaks

Greg and I have been working on an embedded project for one of AO’s longtime clients X-Rite. At the beginning of the project our team (X-Rite + AO) set up a dedicated build server with cruisecontrol.rb and a custom-made build status indicator.

Our build indicator is an upside-down ceiling fan globe with a small microcontroller and super powerful LEDs inside. It goes blue when newly checked-in code triggers a build, and then it displays either green for tests passing or red for tests failing at the conclusion of that build (and all of the engineering department can see it).

Just recently our X-Rite project manager Scott came over and upgraded our build status light for Halloween. We’re pretty sure it’s our automated unit and system tests that will keep evil spirits away, but every little bit helps…

I've just now gotten around to posting the materials I've presented at the OSCON and Agile conferences in the last month. The Agile paper discusses what we learned on our first embedded projects; the OSCON presentation focuses in on the tools and techniques we now apply to embedded development.

OSCON presentation

Agile paper + presentation

Rapid Growth is a very cool, weekly online magazine covering the development and transformation of Grand Rapids. They published a short article about us.

“GR software firm’s growth projections anything but atomic“

Methods & Tools is a quarterly software development e-publication with a distribution list of 45,000. The summer edition of Methods & Tools is now available. It includes an article on our embedded development approach and tools (the PDF version can be found at the preceding link).

Over the last year I’ve been working on a Ruby extension for Measurement Computing’s miniLAB 1008 device; version 1.0.0 is now available on Rubyforge.

miniLAB is a simple analog and digital input and output device we’ve used to help system test our embedded projects. The minilab Ruby extension wraps the miniLAB’s native C library into something addressable by Ruby. I’ve also simplified the interface so that you can refer to the miniLAB’s pins by their labeled name rather than their assigned C constant (for those unfamiliar, the label on the device and the actual value you’d pass to the C library are often wildly different).