Movin’ on up, to the east side

Posted by svec on January 7, 2011 1 comment

After eight years in Austin my wife and I recently moved to Boston.*  Austin was a great place to live, but we were ready for a change, and we’ve enjoyed visiting the Boston area so much that we wanted to move there.  And here we are!

Sadly, leaving Austin meant I had to leave my job at Silicon Labs.  I really liked that job and my coworkers; I highly recommend Silicon Labs to anyone in the Austin area.

Fortunately I found a great job at Ember in the Seaport District of Boston. I’m working on embedded software for our ZigBee chips.  My team has been really welcoming and I’m coming up to speed as quickly as I can.

So far working and living in the Boston area has been great!  We’ve played tourist a bit, and we finally found a good place to live after much searching.  Oh, and we were here for the great “Blizzard of 2010!” I had to dig our car out from under the snow, so perhaps I’ve even earned some winter-weather-survivor cred.

The biggest differences between Austin and Boston so far:

  • The weather.  Today in Austin: sunny and a high in the 70′s.  Today in Boston: snowing and low 30′s. I’m adjusting to the cold much quicker than I thought, which is good.
  • The commute.  Public transit isn’t very developed in Austin, so I drove everywhere.  In Boston I take the subway + bus in to work every day.  It’s really convenient and I can use the time to read, work, or whatever.
  • The accent. Austin has some southern accents, Boston has some Boston accents. Austin has water fountains, Boston has bubblers.

I’m looking forward to settling in to our new home.  Hello, Boston!

—

* And yes, Caustin will be the next city we move to.

Embedded software and open source

Posted by svec on October 5, 2010 0 comments

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.

Creation, Ownership, Drive, and Motivation

Posted by svec on August 22, 2010 0 comments

Ben Pieratt says:

“Creation is entirely dependent on ownership.

Ownership not as a percentage of equity, but as a measure of your ability to change things for the better. To build and grow and fail and learn. This is no small thing. Creativity is the manifestation of lateral thinking, and without tangible results, it becomes stunted. We have to see the fruits of our labors, good or bad, or there’s no motivation to proceed, nothing to learn from to inform the next decision. States of approval and decisions-by-committee and constant compromises are third-party interruptions of an internal dialog that needs to come to its own conclusions.”

Check out Ben’s full post: http://pieratt.tumblr.com/post/977179815/in-praise-of-quitting-your-job

Don’t let the title of “In Praise of Quitting Your Job” fool you into thinking it’s a negative post – it’s not.  It’s a positive post, which lines up well with Daniel Pink’s book, “Drive: The Surprising Truth About What Motivates Us.”

Drive looks at “the three elements of true motivation—autonomy, mastery, and purpose,” which is another way of talking about what Ben calls “ownership.”

Assigning Task Priorities with RMA

Posted by svec on August 15, 2010 0 comments

Embedded gurus Michael Barr and David Stewart have written a couple of great articles about assigning task priorities with RMA (the Rate Monotonic Algorithm):

  1. Introduction to Rate Monotonic Scheduling, by David Stewart and Michael Barr
  2. 3 Things Every Programmer Should Know About RMA, by Michael Barr

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.

Computers and Pigs in Space

Posted by svec on August 15, 2010 0 comments

The first computer went into space on March 25, 1965, according to this PragPub article by Dan Wohlbruck: http://www.pragprog.com/magazines/2010-08/when-did-that-happen

It took 12 more years to launch Pigs in Space: http://muppet.wikia.com/wiki/Pigs_in_Space

Only history can judge which was the greater accomplishment.

“Shaping Things” by Bruce Sterling

Posted by svec on July 11, 2010 0 comments

I just finished “Shaping Things,” by Bruce Sterling.  It’s a very broad look at the way technology, people, and society have changed – and changed each other – over time.  And since it’s by Bruce Sterling, it’s mostly focused on the possibilities of tomorrow.

My favorite quote:

“Tomorrow composts today.”

Very cool – both the quote, and the book.

Sterling looks at five classes of technosocial relationships:

  • Artifacts / Hunters and Farmers
  • Machines / Customers
  • Products / Consumers
  • Gizmos / End-Users
  • Spimes / Wranglers

Definitely worth a read.

I got it from the library, and I’m going to hang on to it for a little while longer and read it again.  It’s short, but conceptually dense.

Definitely worth a re-read.

I love embedded, and so does Woz!

Posted by svec on July 5, 2010 0 comments

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.  :-)

Hacks and Hack-Nots

Posted by svec on April 18, 2010 0 comments

The world is divided into two kinds of people: Hacks and Hack-Nots.

Hacks people hack.  They want hardware and software (aka “technology” or “tech”) they can change, optimize, use as they please, modify, destroy, etc. – in short, they want to hack.

Hack-Nots people do not hack. They don’t want to know what “hacking” means. They want their hardware and software to Just Work.  They don’t want to be aware of technology at all, they just don’t care.  They want to email, work, check Facebook, etc. – in short, they want to do something other than use the tech.  Technology is a means to an end, nothing more.

Hacks check email, Facebook, blogs, etc. just like Hack-Nots, but for Hacks the journey is more important than the destination.  The experience of checking email is more important than the email itself.  Configurability is key.  Even if it Just Works out of the box, Hacks will optimize it to their liking.  Technology is an end in itself.

For Hacks, optimization and configurability are more than just a Nice To Have, they are Moral Imperatives.  They believe it is actually morally wrong to not be able to mess with their technology.  They believe that being told they can only use C++ is slavery.  Even if C++ is their favorite programming language in the world, not having a choice is wrong.

For Hack-Nots, optimization and configurability are a distraction. Putzing around with settings is a waste of time.  They do not want to mess with technology that already works.  They do not care that software can only be written in C++.  They do not know what C++ is, and they will never care.

Until the last five or ten years most computing technology was made by, and for, Hacks.  Recently this trend has changed. Most technology is still made by Hacks, by definition.  Somewhere, however,  someone with an eye for the desires and dollars of the Hack-Nots took notice and is now telling the Hacks what to make.

Not in all cases, of course.  Most technology is still Hacks-only.

But the Hack-Nots are coming, and technology is on its way to meet them.  Hack-Nots will drive the marketplace simply because they are more numerous than the Hacks.

Book Review: “Hardware/Firmware Interface Design”

Posted by svec on January 24, 2010 0 comments

I just finished Hardware/Firmware Interface Design: Best Practices for Improving Embedded Systems Development, by Gary Stringham.  Gary sent me a review copy of the book, btw, but I get no money for reading or reviewing it.  Though if you buy the book via my Amazon link, I get a bit of cash.

Anyway – the book is very good.  Gary says, “This book is written by a firmware engineer but is directed primarily to hardware engineers.”  I’ve been a hardware engineer and a firmware engineer, and I think both groups should read this book.

Gary has been in the trenches of firmware/hardware co-design for 20+ years and this book shows it.  The book gives 300+ “Best Practices” which are actually usable and practical – a departure from many software or hardware design books.  Gary talks about low-level concepts like interrupts, register definitions, and debugging, as well as higher level concepts like planning, documentation, and block partitioning across multiple product generations.

Summary: You should read this book if you’re a hardware or firmware engineer.

This is one of the books that I’ll probably revisit a couple of times a year to refresh myself on A Right Way to do hardware/firmware co-design.

‘Nuff said.

The Importance of Selective Importance

Posted by svec on November 30, 2009 0 comments

Bob Sutton quoting Bill Vlasic quoting Terry Woychowski about bureaucratic and measurement inflation at GM:

“But as soon as everything is important, nothing is important.”

That quote applies to pretty much any area of life.

Like money, priorities and importance can be devalued through inflation.

Plan, measure, and react accordingly.