Month: August 2015

So there’s a real-world problem I’ve run into on the Arduino that I realized could be a reasonable interview question. I’ve been thinking through some of the answers. The question goes something like this:

You have an Arduino development board, and you have a state machine that could be in one of sixteen states at any given moment. How would you design a method for indicating the current state to someone looking at the board?

That’s version one of the question. And the person might answer something like:

I’d hook up two seven-segment LEDs to the board to display the status.

But that would chew up 14 pins on an Arduino, which is quite a lot of digital I/O just for status. So the follow-up question could be something like:

Would there be a way to cut the number of seven-segment LED modules you’d need in half?

And after thinking, the answer would come to mind:

Yes, you could use a single seven-segment LED module. Since you’re only displaying a value up to 16, you could display the value as hexadecimal 0 – F, instead.

But let’s constrain the problem further. That’s still 7 pins on an Arduino, which is a mighty waste on the smaller Atmel chips (like on the Arduino Nano).

Would there be a way to cut the number of pins you’d need, to drive the seven-segment display, to a single pin?

And the person might think a bit, and answer something like:

Well, you could use something like a serial-in-parallel-out integrated circuit, like the 74HC595, and some logic in the software, to control the 8-output-pins in a way that generate the values 0 – F.

And that would be another correct answer. But then, let’s say we really want to constrain things.

How about if you wanted to do this with zero external components, just what is on the Arduino board itself, how would you do it?

Keep in mind that most Arduino boards, as long as they follow the reference design, have a controllable LED tied to Pin 13. This would be something an interviewee might or might not know, but at some point you could tell them this, and see what they do with the info.

The idea that’s been forming in my mind, to do this, and I think could be the right answer, is to light the LED in a way that corresponds to one of sixteen values. I considered using on-and-off as two possible binary states, to convey the 0 and 1 bits of a 4-bit value. But then I realized that there’d need to be a way of marking the start boundary of the value. This is an issue you see with all normal serial protocols, RS232 can use 1 or 2 stop bits, if I remember right. Which basically means the protocol waits two bit times, then proceeds with the next byte.

The problem with just using a simple on-off coding is also the question of what happens when multiple identical bit values happen back-to-back. As in, let’s say you wanted to blink the value 11 to the LED, which would be 1011 in binary. The last two bits would smear together, and it would be tricky for a human to tell what the value was. It would look like:

ON-OFF-ON (longer)

Visually, the answer I came up with is to use a short blink (say, 250ms) and a long blink (say, 750ms) to represent 0 and 1. Between blinks, there would be a pause of 50ms or so (or this is up for tweaking, as I haven’t written the system yet). Then there would be a pause of one second, and the sequence would repeat.

It’s nothing too special, but this might be a workable system. The real challenge, then, is how to implement this using just a millisecond timer and a few C functions.