There are 9 posts filed in embedded (this is page 1 of 1).
I had a great time being interviewed on the CodeNewbie podcast hosted by Saron Yitbarek! The episode is called: Episode 133: Building Robot Vacuum Cleaners: An Intro to Embedded Systems
Thanks to Saron for having me on her show – she asked great questions to knit together my experience in chip design, embedded software, robots, and empathy.
I’m excited to announce that Elecia White, Chris White, Andrei Chichak, and I have started collaborating on a new embedded software engineering blog over at Embedded.fm/blog.
It’s slightly related to the Embedded.fm podcast because it’s about embedded software and embedded systems, but most the content will be separate from the podcast.
Andrei and I will both be writing about getting started in embedded systems (using two completely different approaches), Elecia will be sharing excerpts from her upcoming book about taking apart toys, and Chris White will be talking about various projects. Hopefully there will also be entertaining embedded-ish rants.
Please stop by and check it out! I’ve had a blast reading pre-published stuff that will show up on the blog, and I hope that you’ll enjoy it too.
Great quote from bunnie about Makers:
The Maker movement, I think, is less about developing products, and more about developing people. It’s about helping people realize that technology is something man-made, and because of this, every person has the power to control it: it just takes some knowledge. There is no magic in technology. Another way to look at it is, we can all be magicians with a little training.
That comes from an interview bunnie did with CSDN.net, which you can read here: http://www.bunniestudios.com/blog/?p=3234
Exciting news!
My chapter on FreeRTOS, the open source real-time operating system, has been officially published in The Architecture of Open Source Applications, Volume II!
You can buy it on Lulu.com here: The Architecture of Open Source Applications, Volume II, dead tree version
Or you can wait a week or two and find the complete text (of my chapter and all the others!) here for free: AOSA online
I’m very happy how it turned out; it was a lot more work than I expected, but it was worth it. Greg Wilson and Amy Brown edited the heck out of it, I would love to work with either (or both) of them again. Thanks to them for pulling the whole thing together! Thanks also to Richard Barry, the primary FreeRTOS developer, for his technical help.
I’m looking forward to reading the whole book myself; so far I’ve only read my chapter.
A few choice chapters that I’m particular looking forward to reading are:
So check out the book, either online or in paperback, and enjoy!
Exciting news: I’m writing a chapter about FreeRTOS for the next edition of The Architecture of Open Source Applications!
Greg Wilson, one of the editors of the book, (the other editor is Amy Brown) tweeted that they were looking for coverage for embedded software. Well, I thought, I’ve been wanting to learn about FreeRTOS, and that fits the embedded and open source bills, so here we go!
I learned a lot reading the current edition of the book, and I hope that others can learn something from my forthcoming chapter on FreeRTOS.
My company, Ember, is hiring for embedded software engineers and QA engineers in Boston:
http://www.ember.com/company_careers.html
We develop the chips, software, and tools for wireless sensor networks.
I’ve worked at Ember since December, and it’s the best place I’ve ever worked (and I’ve worked at some pretty good places!) And, no joke, all of my coworkers say the same thing. So either we’re that great of a place to work, or there’s something in the water, but either way, it’s awesome.
But, as Levar Burton says, you don’t have to take my word for it: We were just voted one of the top places to work in Boston: http://www.bizjournals.com/boston/news/2011/05/03/bbj-announces-best-places-to-work.html
Our QA engineers are more “developer-y” than many QA roles, so definitely check it out even if you’re not in the market for a more traditional QA position.
Email me if you’re interested!
Embedded guru and author Jack Ganssle’s latest “Embedded Muse” newsletter has a lot of good commentary on open source in embedded software projects:
http://www.ganssle.com/tem/tem199.htm
I subscribe to very few newsletters, and Jack’s is one of them. I read every issue, it’s that good.
If you work in embedded software, or software of any kind, you should subscribe! (I don’t get anything if you subscribe, I just think it’s a worthwhile read.)
While I’m in fanboy mode, I’ll also recommend Jack’s other articles – click on a random one, you’ll probably learn something. My personal favorite is his guide to debouncing. He does some good experiments and then shows hardware and software solutions to the pesky debouncing problems we embedded folks face.
Embedded gurus Michael Barr and David Stewart have written a couple of great articles about assigning task priorities with RMA (the Rate Monotonic Algorithm):
The first article lays out the basics: RMA is an algorithm that assigns static priorities to periodic tasks in order to maximize “schedulability.” That’s a mouthful: 16 words, 37 syllables. And one of the words isn’t real: “schedulability,” which means “able to be scheduled so that all tasks complete before their deadline every time.”
Let’s try again: RMA helps tasks get done in time. That’s better: 7 words, 9 syllables.
The second article expands on the basics of RMA, giving some additional guidelines for when it should be used, especially as it applies to interrupts (which it does!).
I want to talk a bit more about the basics of RMA. RMA is easy to describe: a task’s priority is based on how often it runs. The task that runs the most often gets the highest priority, the task that runs the second most often gets the next highest priority, and so on. Or, to quote the first article, “Assign the priority of each task according to its period, so that the shorter the period the higher the priority.”
RMA does not guarantee that your tasks will all complete in time; RMA does guarantee to find the optimal static prioritization assignment if one exists. If RMA doesn’t produce a “schedulable” task set then no “schedulable” static priority scheme exists.
RMA’s greedy nature makes intuitive sense: starting at time zero, assume all tasks are ready to run. Then run the task with the shortest period. Since this task runs more often than any other task, it “feels” right to run it first to give it the best chance of finishing before it has to run again. Next run the task with the next shortest period, and so on, until all tasks have been run.
Fortunately the intuition and “feel” that RMA works is backed by the fact that it does!
I’ve given a very basic overview of RMA here. Please check out Stewart and Barr’s articles for more about RMA.
I love working in the embedded world. Hardware + software = a great time and a great career.
I came across this fantastic quote by Steve Wozniak in “Making it Big in Software,” by Sam Lightstone. Woz is talking about designing the Apple II:
“And I did every piece of software from the ground up, through applications that you can’t pin down for any one of them. The hardware was so interrelated that I can’t really divide it into software and hardware alone. Those days were that way. Today, if you work on embedded processors, you put a little microprocessor into a small product. That’s the job in the world that I would love to this day! That’s what I did back then; it mixed both hardware and software.”
Sounds like Woz wants my job. 🙂