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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s