I come from the 8080/8085 era. I used to hand write the code on paper then type the opcodes into an EPROM programmer. If that didn't work, I figured it out and did it again. I developed some pretty complex code that way. Since then, I've never lost sight of the fact that small is beautiful.

After reading Jack Ganssle's article "Small is Beautiful" (March 9, 2009, www.embedded.com/21580130), I felt like we were brothers from a different mother. In this world, the constant drumbeat of "more, more, more" is pounded into our heads so much that the concept of "simple is best" is lost. Everyone gets "creeping featuritis," and soon the whole place is infected with features no one wants or even needs. I'm here to tell you that it doesn't have to be that way.

The first time our hardware engineer brought a proposal to me and said it has an 8-bit processor, I said "are you nuts?" Yet, when all was said and done, I have to say I was impressed. The processor our hardware guy proposed was the Freescale MC9S08. Originally he wanted a simple super loop that he could write himself and not get the firmware guys involved. He was concerned about us catching creeping featuritis and turning the super loop into a huge 32-bit machine with way too many bells and whistles. I convinced him that that would not be the case and that I would write the firmware for it myself. My first concern was that the super loop starved other parts of the system, so I started researching what was out there that I could use.

I read Miro Samek and Robert Ward's great article in the July 2006 Embedded Systems Design magazine (www.embedded.com/190302110) on the simple task switcher because I have always preached that "good developers write good code, great developers steal." I didn't use this task switcher because I was also concerned with starvation. Their system had higher priority tasks run to completion and was based on state machines that are amazingly useful but limited when dealing with time constraints. Events get backed up waiting for other events to run to completion.

I then looked at Helium (http://helium.sourceforge.net). A great little tasker but too much overhead for what I was looking for and it was based on priorities as well. I needed something where every task has the same priority, gets its share of the CPU, and yet can have a different "weight" in the system. When I say weight, I mean a little bit more of the task's share of the CPU is going to that task. This is not to be confused with priority over the other tasks; instead, it's just that one task needs another tick or two, while all the other tasks are still geting their share. More on this later.

So after not finding anything I could (ahem) borrow, I set out to create a small multithreaded tasker that can run on an 8-bit MCU and lets every task have access to the CPU more or less when they needed it. Enter FLIRT (Friendly Little Interrupt Tasker). In the end my implementation consumed a whopping 144 bytes of flash.