Due and 7 segment displays

Looks like I found an easier solution: https://cdn-shop.adafruit.com/datasheets/sn74lvc245a.pdf

EDIT: Maybe this is where the problem is -- that people are not understanding the word 'emulator.'
I am writing an emulator for the HARDWARE of a 6502 based machine. This emulator runs 6502 software that talks to the hardware in a very specific way. For matters of this discussion, the 6502 software handles multiplexing the LEDs on its own. I can't change that. My emulator needs to behave as much like the original hardware as possible.
The original machine multiplexed the LEDs via its data ports. Right now, I'm intercepting that and turning it a MAX-compatible output. The MAX doesn't like having its LEDs externally multiplexed so I need to drive the LEDs directly off the Due's pins.
But the Due is a low-current device that can't drive a 7-segment display.

The rest of the original post continues.

(Post edited -- I should not post when I am this tired. A form of dyslexia slipped in and I typed the wrong phrase a couple of times.)

I am trying to connect a six digit, seven segment display up to a project running on the Due. (To be more accurate, I am hooking up a 4 digit and 2 digit display, creating my own six digit -- but I know how to handle that part.)

The parts in question are

  • 2 Bit 0.56" Anode
  • 4 Bit 0.56" Anode

From this EBAY listing

I am making a KIM-1 emulator -- a heavy expansion of the KIM-1 emulator that already exists but emulating as much of the hardware as possible and not shimming the ROM drivers.

Currently I am using a MAX7219 device as part of my proof of concept. The MAX device in use.

The KIM-1 handles multiplexing the LED by port manipulation. I am creating a virtual software port and sending the correct commands to change the LEDs. However, using SPI is slow enough that there is a visual flicker on the LEDs.

This is NOT the result of my emulation, as even native Arduino code flickers when manually multiplexing the LEDs. (I can provide a demo sketch if needed.)

Driving the LEDs directly seems to be the best solution, but the Due cannot handle as much power through its pins as the Uno can.

According to this URL, the max power I can draw from any pin is 15 milliamps, while the max sink is around 9 mils.

Due: Pin mapping and power

  • Does anyone have experience hooking up a 7-segment display?
  • What is the current draw of these displays? (Currently using a generic Chinese import.)
  • Could I run the pins through a level shifter? For those who inquired what a level shifter is: Adafruit Level Shifter. I couldn't find any specs on how much current the level shifters could carry.
  • Should I take this question to the electronics page and ask about switching transistors?

Since everyone keeps recommending I stay with the MAX driver, I am including my demo that shows the SPI transfer rates add unwanted flicker.

Again -- the system that I am coding already multiplexes the LEDs itself. I am looking for information on how to directly drive the LEDs from the Due ports given the very limited current output of the Due.

#include <stdio.h>
#include <SPI.h>

#include "LedControl.h"

#include <SPI.h>


#include "bitBangedSPI.h"
#include "MAX7219.h"


// Changing the displayspeed to zero (or removing the delay) gets even stranger.
#define delayspeed 1
#define LED_CS 15
MAX7219 display(1, LED_CS);

/* This code emulates the behavior of the hardward that I am emulating by manually multiplexing the 
 *  LEDS.
 *  
 *  The flicker is VERY visible.
 */


void setup() {

    display.begin();
    display.setIntensity(15);

#define FF(x)                     \
  {                               \
    display.sendChar(x, '0' + x); \
    delay(delayspeed);            \
    display.sendChar(x, ' ');     \
  }

    while(true )
    {
      FF(7);
      FF(6);
      FF(5);
      FF(4);
      FF(3);
      FF(2);
      FF(1);
      FF(0);
    }


}

void loop() {

}

slowmax.zip (6.62 KB)

What you should do, is to start by actually explaining your situation.

A MAX7219 drives LED seven segment displays, not LCD. So which one are you talking about?

Where is the Web link to the display? Any other parts you are using (apart from the DUE)?

Why would you expect someone on this forum to have experience hooking up a 7-segment display? Or for that matter, the "Displays" forum where the same people hang out. :roll_eyes:

Do you have any idea what a "level shifter" is? Can you cite one? :astonished:

A MAX7219 drives LED seven segment displays, not LCD. So which one are you talking about?

I apologize. I am dyslexic and sometimes type the wrong word entirely. I have corrected my post.

Where is the Web link to the display? Any other parts you are using (apart from the DUE)?

I have included links to all relevant parts currently in use.

Why would you expect someone on this forum to have experience hooking up a 7-segment display? Or for that matter, the "Displays" forum where the same people hang out.

Because it is an LED display. I was tossed back and forth between this and the "Displays" forum but I chose this one since it was based more on the LED-specific electrical connections rather than driver-related issues. It could have gone in electronics as well.

Do you have any idea what a "level shifter" is? Can you cite one? :astonished:

A level shifter is device that will convert between two different logic levels such as 3.3v and 5v. What is unclear is if it will handle enough current to drive LEDs at 5v or if it only converts low-current logic signals.

  1. Yes
  2. Probably maximum 20mA per segment. But you don't have to use that much. And multiplexing will reduce the average current.
  3. No. These are logic level shifters and won't handle much current.
  4. Here is fine.

I read your post several times, but your plan is not clear to me. You mentioned using max7219 in your proof of concept design, but then started talking about driving the display with Due pins, and about flickering. So why do you not want to continue to use max7219 in the future version? Do you want the display to flicker, for a more authentic representation of the KIM-1?

jstarcher:
Because it is an LED display. I was tossed back and forth between this and the "Displays" forum but I chose this one since it was based more on the LED-specific electrical connections rather than driver-related issues. It could have gone in electronics as well.

I was having a "leg pull" - a joke. Obviously, any of these forums would be the perfect place for such a query. :grinning:

jstarcher:
A level shifter is device that will convert between two different logic levels such as 3.3v and 5v. What is unclear is if it will handle enough current to drive LEDs at 5v or if it only converts low-current logic signals.

Yes, what you need is the proper driver.

The display you cite is perfect for the job and is exactly what you should use. It is easy to program and performs all the multiplexing for you. On the other hand, if you want to emulate a flickering display, then the processor you have is so much faster than the original 6502 that you can emulate this in software under precise control.

So there really is no reason to do it any other way. The MAX7219 will accept 3.3 V logic levels just fine (as long as your 5 V supply is well regulated) as you would have already found. You can use the display as-is with one or two digits blanked out, or wire your own displays to it. :sunglasses:

PaulRB:
I read your post several times, but your plan is not clear to me. You mentioned using max7219 in your proof of concept design, but then started talking about driving the display with Due pins, and about flickering. So why do you not want to continue to use max7219 in the future version? Do you want the display to flicker, for a more authentic representation of the KIM-1?

Because the MAX driver is causing additional lag and flicker that I don't want.

If the software that I am emulating happens to add flicker, that's one thing... but native code at full speed still flickers. I am looking to drive the LEDs, as directly as possible, so that if there is any flicker is caused by the emulation itself.

#define FF(x)                         \
    {                                 \
        display.sendChar(x, '0' + x); \
        display.sendChar(x, ' ');     \
    }

    for (int i = 0; i < 7000; i++)
    {
        FF(7);
        FF(6);
        FF(5);
        FF(4);
        FF(3);
        FF(2);
        FF(1);
        FF(0);
    }

jstarcher:
Because the MAX driver is causing additional lag and flicker that I don't want.

Err, no! :roll_eyes:

and not shimming the ROM drivers.

I suppose that is your dyslexia kicking in. No problem I am dyslexic myself, but does this mean shimmering display? Because if it means shimming the ROM then I am lost.

Because the MAX driver is causing additional lag and flicker

No it is not, if you think that then you are not understanding what is going on.

That piece of code you posted makes little sense. We always ask you to post all your code not just a small part, so we can make sense of it.

Grumpy_Mike:
I suppose that is your dyslexia kicking in. No problem I am dyslexic myself, but does this mean shimmering display? Because if it means shimming the ROM then I am lost.

Shimming is a software term. The KIM was a 6502 computer that had a small ROM that handled basic input and output. When you "shim" a ROM you intercept the ROM call and 3xecute your own code instead

When i get home I'll post a complete demo of the MAX lag.

PaulRB:

  1. Yes
  2. Probably maximum 20mA per segment. But you don't have to use that much. And multiplexing will reduce the average current.
  3. No. These are logic level shifters and won't handle much current.
  4. Here is fine.

I read your post several times, but your plan is not clear to me. You mentioned using max7219 in your proof of concept design, but then started talking about driving the display with Due pins, and about flickering. So why do you not want to continue to use max7219 in the future version? Do you want the display to flicker, for a more authentic representation of the KIM-1?

Thank you -- that is a key thing I was looking to find. I was having a hard time sifting through datasheets, but you confirmed what I rather suspected.

Grumpy_Mike:
That piece of code you posted makes little sense. We always ask you to post all your code not just a small part, so we can make sense of it.

I have included a demo of the behavior that I am describing. If I remove the delay entirely I get an unreadable screen.

jstarcher:
I have included a demo of the behavior that I am describing.

Where?

I see you updated the original post. Is that the exact sketch causing the flicker? If so, that's the problem, not the max chip itself. Given how that code is written, I am not surprised if flickers!

The max7219 performs multiplexing itself. You don't have to perform the multiplexing in code. If you try, it will be certain to cause terrible flicker. With this chip, you only send commands to the chip when you want the display to change.

PaulRB:
Where?

I see you updated the original post. Is that the exact sketch causing the flicker? If so, that's the problem, not the max chip itself. Given how that code is written, I am not surprised if flickers!

The max7219 performs multiplexing itself. You don't have to perform the multiplexing in code. If you try, it will be certain to cause terrible flicker. With this chip, you only send commands to the chip when you want the display to change.

Yes! I know! Exactly!

Which is why my post is asking how to move AWAY from the MAX and drive the LEDs directly.

I mentioned the MAX because I'm using it in my proof-of-concept for the emulator.

I received replies that said that said the MAX was the best solution because it handled the current issue for me and that the MAX was fast enough.

I am writing an emulator for a system that behaves - exactly - as the code I posted does.

Therefore, I get flicker on the MAX.

Again my question is: How do I drive 7-segments on a Due with its extremely limited current output, WITHOUT using the MAX.

PaulRB:
You don't have to perform the multiplexing in code. If you try, it will be certain to cause terrible flicker. With this chip, you only send commands to the chip when you want the display to change.

I have updated my original post yet again trying to explain WHY I am multiplexing the LEDs on my own.

I am writing an emulator for a system that behaves - exactly - as the code I posted does. Therefore, I get flicker on the MAX.

So you are simply writing the code to drive the MAX incorrectly if you don't want the flickering. If you do want the flickering then you know how to drive the MAX.

If you want to do your own multiplexing then you have to boost the current capability and voltage of the Arduino pins by using transistors on the pins. You need NPN transistors for the cathodes and a NPN and PNP transistor for the anode. You can not simply use a PNP transistor because the Arduino Due's pin will not go high enough to directly turn a PNP transistor off.

Grumpy_Mike:
If you want to do your own multiplexing then you have to boost the current capability and voltage of the Arduino pins by using transistors on the pins. You need NPN transistors for the cathodes and a NPN and PNP transistor for the anode. You can not simply use a PNP transistor because the Arduino Due's pin will not go high enough to directly turn a PNP transistor off.

Thank you Mike. Do you know of any examples or tutorials on that to help get the math right?

I also came across called a 'buffer' (74HC4050 Hex Non-Inverting Buffer (DIP)) that looked promising.

I also came across called a 'buffer' (74HC4050 Hex Non-Inverting Buffer (DIP)) that looked promising.

No it is not what you want or need. That is an analogue buffer you get no voltage or current advantage. This is what you want to do:-

Grumpy_Mike:
This is what you want to do:-

Awesome! I'm much much more of a software guy than a hardware guy so it will take me a while to understand all of that but it is an amazing place to start.

Can't tell you how much I appreciate the help.