Interrupts, again!

My favorite interview question is so easy, so simple. The fact that it weeds out about 65% of candidates is mind boggling. I have interviewed many engineers who are experienced embedded software developers. There resumes claim that they have done it all and seen the world.

Why is it, when asked “What happens to the software when an interrupt happens?” the strong crumble. Seriously, this is one of my first technical questions. It always cuts the weak from the heard.

Two things have to come out of the resulting discussion. First, some how, via some hardware magic or voodoo, the current state of the software gets put onto a stack. Where the stack is, if it goes bottom to top or top to bottom is not at all important. Just the state gets saved, and saved to the stack. Second, while the interrupt is happening other interrupts are not, and you have to turn interrupts back on at the end. The special iret instruction might do this for you, but some how, some where, this happens on purpose.

Wrong answers are ‘the OS handles that’, ‘it gets written to disk’, ‘small systems don’t have a stack’, ‘the hardware does everything’, and ‘dunno’. Those are all real answers I have been given in interviews.

My point is you need to understand interrupts, or the next few posts about multicore interrupts are not going to make much sense.

Proof of my over-thinking

I am always searching for innovative ideas, and new things. I especially love startup business ideas.
Because I and my friends are software, hardware and technical people, our ideas tend to be complex and technical.
This video brings us back to a grounded state. We are totally over-thinking these things.

I bet this guy makes a zillion dollars and has to outsource his workload.

Back soon!

Sorry, too much hullabaloo around Haloween, plus we have all been down with a cold or flu. I will get back to regular posting this week.