Using multiplexed 7 segment display outputs as inputs at the same time

I am working with a couple of premade clock and counter boards that I am building a wireless system around to allow them to be xbee remote controlled.

While reading over their datasheets, I discovered something that I had not seen before.

It appears that they are using the MCU pins for simultaneous input and output. They are constantly outputting a multiplexed signal for a display, but if at any time one of those pins is pulled high by a button, the MCU responds.

I know that this is not really an arduino thing, but one of the MCUs involved is still atmel (ATtiny2313) so I think some of this might apply to arduino as well. Additionally, you guys on this forum seem to know just about everything, so I figured I would give it a shot.

I know that it is possible to directly read the pin register using "PIND" for instance. This should theoretically give you the current value of the pin regardless of whether it is set as an input or an output.

I also dont know quite what is actually happening when we drive an output. Can the pin remain in a "tristate" or "high impedance" state, but still be pulled high or low by the MCU? This could allow an external switch to override the state set by the MCU.

If anyone actually wants datasheets to these boards, one of the devices is the MXA069, datasheet HERE.

My questions are much more general than project specific though.

Thanks!

Hi, I can see how the mcu reads those switches. What I can't figure out is how the circuit avoids the switches affecting the display. Seems to me that when any switch is closed (and 2 of them are jumpers, so may be continuously closed), the corresponding transistors driving the cathodes would be switched on, preventing the mcu from displaying the required digits on the display. A puzzle!

The only theory I have right now is that when a switch is closed, the current has to pass throught both the 1K and 3K resistors. But when the mcu makes a pin high, the current only has to flow through the 3K. That seems to rely on a slightly lower current not switching on the transistors, and a slightly higher current switching them on.

Paul

PaulRB:
Hi, I can see how the mcu reads those switches. What I can’t figure out is how the circuit avoids the switches affecting the display. Seems to me that when any switch is closed (and 2 of them are jumpers, so may be continuously closed), the corresponding transistors driving the cathodes would be switched on, preventing the mcu from displaying the required digits on the display. A puzzle!

Paul

This was confusing to me as well. To further that puzzle, I messed around with holding those buttons, and cannot get it to affect the numbers displayed.

I am totally lost.

On second thoughts I can't understand how it reads the switches either. I'm pretty sure that mcu does not have internal pull-down resistors (afaik no other 8 bit avr does).

PaulRB: The only theory I have right now is that when a switch is closed, the current has to pass throught both the 1K and 3K resistors. But when the mcu makes a pin high, the current only has to flow through the 3K. That seems to rely on a slightly lower current not switching on the transistors, and a slightly higher current stitching them on.

Paul

This made me think of another possibility, though I may be missing something. If the MCU was driven low, the path through the MCU would be lower resistance than the path through the 3K. I am pretty certain that the ATTiny can sink a decent amount of current. That could mean that the MCU is simply sinking the current low, which would make sense. This would mean that the MCU could turn on and off the display with no problem regardless of the state of the switch or jumper.

The following is from the ATTiny datasheet,

"Port B is an 8-bit bi-directional I/O port with internal pull-up resistors (selected for each bit). The Port B output buffers have symmetrical drive characteristics with both high sink and source capability. As inputs, Port B pins that are externally pulled low will source current if the pull-up resistors are activated. The Port B pins are tri-stated when a reset condition becomes active, even if the clock is not running."

This leads me to believe that the port could sink the current necessary to keep the transistor deactivated, or source enough to activate it, regardless of the position of the button or jumper. Simple mental math says that 5v/1000ohm gives 5mA of current, which should not be out of sinking range..

This brings us right back to where we started. If the MCU is truly sinking the current, how the heck is it detecting a voltage? Or can it actually detect a current flow? Or a voltage drop across itself? Can it detect a voltage when it is actively sinking that voltage?

I am really scratching my head on this one.

ianahner: If the MCU is truly sinking the current, how the heck is it detecting a voltage?

I think it might work like this:

At some point in the sequence of multiplexing the display, the mcu pins are switched to be inputs rather than outputs. The 3K resistors act as pull-downs, sinking a small current through the npn transistor bases and causing the mcu pins to read low. Then, if any switch is pressed, the pin would read high, because the pull-up resistor is only 1K. The 1K and 3K resistors then act as a voltage divider and give a voltage of 5 * 3 / (3+1) = 3.75V at the mcu pin, enough to read as a high.

While the mcu pins are acting as outputs to drive the displays, the following happens:

If a pin is high, enough current flows from the pin through the 3K to switch the npn transistors on.

If a pin is low, the npn transistors stay off, even if a switch is pressed, because if a switch is pressed, the current flowing through the 1K is shorted to ground through the mcu pin. Almost no current flows through the 3K, so the npn stays off.

The final piece of the jigsaw: when the mcu pins are switched to inputs to read the switches, and a switch is pressed, a current flows through both the 1K and 3K, switching the npn transistor on. But at that point in the multiplexing cycle, none of the pnp transistors connected to the display's common anodes are switched on, so nothing happens.

What do you think? Have I figured it out?

PaulRB: I think it might work like this:

.....

What do you think? Have I figured it out?

I thought about that, and it is the only way I can think of to do it as well. You are certainly as close to solving the puzzle as I am. I originally threw out that idea because of the speed requirement to do that. I am unsure whether you could stop the multiplex sequence for long enough to register inputs without causing a flicker in the display. I don't have a ton of experience with multiplexing systems, so I don't really know what the maximum unnoticeable delay is... Hopefully someone can confirm or correct this.

My biggest reason for asking this is that I may be rewriting the code on one of those MCUs to modify the functionality, and without the original code I was a bit lost. The one I would modify is actually a timer module using a PIC, but the input/output is exactly the same setup (except it pulls it low instead, and has a 10k pullup).

I think you are on the right track for sure! I look forward to seeing if anyone else can contribute, especially someone who has actually done this!

ianahner:
I originally threw out that idea because of the speed requirement to do that. I am unsure whether you could stop the multiplex sequence for long enough to register inputs without causing a flicker in the display.

Not a problem, the speed of the attiny will be more than enough. Checking the switches will mean a short delay when no digit is lit, but that will only cause a very slight drop in the brightness of the display, probably not even noticeable to the eye.

ianahner:
My biggest reason for asking this is that I may be rewriting the code on one of those MCUs to modify the functionality, and without the original code I was a bit lost. The one I would modify is actually a timer module using a PIC, but the input/output is exactly the same setup (except it pulls it low instead, and has a 10k pullup).

I guess you could unsolder the attiny. If it survives the process, reprogram it, otherwise replace it. Either way, I would then solder a chip socket onto the board so you can remove and reprogram the chip while debugging.

Not sure why you would want to try to use a pic, the pinout would be different, wouldn’t it?

If this were my project, I would forget those driver boards. Buy as many of the large digit boards as you need and drive each digit with a tpic6b595. Daisy chain the tpic chips and drive them all with a single Arduino Nano. That would result in much brighter display, since there would be no multiplexing.

PaulRB:
Not a problem, the speed of the attiny will be more than enough. Checking the switches will mean a short delay when no digit is lit, but that will only cause a very slight drop in the brightness of the display, probably not even noticeable to the eye.

I guess you could unsolder the attiny. If it survives the process, reprogram it, otherwise replace it. Either way, I would then solder a chip socket onto the board so you can remove and reprogram the chip while debugging.

Not sure why you would want to try to use a pic, the pinout would be different, wouldn’t it?

If this were my project, I would forget those driver boards. Buy as many of the large digit boards as you need and drive each digit with a tpic6b595. Daisy chain the tpic chips and drive them all with a single Arduino Nano. That would result in much brighter display, since there would be no multiplexing.

Ahhh, I wasn’t clear! The MCU is already in a socket. So my life is easy. Also, I would not be switching to a PIC form an ATMEL, there are actually two different boards. One uses ATMEL an runs a counter, this is the board I linked to. The other board is nearly identical, but uses a PIC and runs a timer. That device is the MXA025. I linked to the counter board because I only have a paper copy of the other schematic, and I am too lazy to scan it in. The circuit that has the simultaneous input/output is roughly the same, and that was the part that I was confused about, so the board I linked to was only an example of the multiplexed output and input bit.

The option of forgoing those boards is really out of the question, but I never explained that part either, so I totally get where you’re coming from. Otherwise I would agree with you. The company that I am doing this project for already has many of these boards in place and would like to continue using them, but with additional functionality. They get the driver boards together with the large digit displays for very very cheap, much cheaper than I could make something. My job in the matter is to simply wirelessly control them, and ultimately make a small change to the timer board programming to allow it to count DOWN from a preset time instead of UP from 0 which is the default functionality.

Either way, when it comes to that, I can simply pop the PIC out of the socket, reflash it, and be done. I have not yet checked the security bits, but I am guessing they are set. If I get really lucky though, they may not be, and I might be able to snag the existing code and break it back out into assembly. If I manage to do that and figure out how they have it working to begin with, I will certainly post back!