Common Anode 7-Segment Display Option

[Anonymous]

Hello all,

Here's an easy one-line addition to the "7Segment.h" include file. First, the reason. I have a Matrix Multimedia development board from the UK. The four digit, seven-digit display uses common anode devices. GC Basic assumes common cathode devices. With the addition of a single line, one can invert the code sent to the displays, and make it work out correctly.

Here's how:

Open the "7Segment.h" file.

Scroll down to the DisplaySevenSeg macro, and look for:

'Show number on new display
If DispTemp.0 = On Then DISP_SEG_A = On
If DispTemp.1 = On Then DISP_SEG_B = On
If DispTemp.2 = On Then DISP_SEG_C = On
etc.

Now simply insert the following line right before all the IF's commence.

DispTemp = not DispTemp

By the way, I manually inserted this inversion in the include file and it works. My common anode displays works fine now.

To the keeper of the "7Segment.h" file, might it be possible to incorporate a new constant, to automate this? For example, in the program source code, one might have:

#DEFINE COMMON ANODE
or
#DEFINE COMMON CATHODE

where the keyword COMMON can have either the value ANODE or CATHODE, indicating whether to include or exclude the inversion appropriately.

Thomas Henry

[Anobium]

Nice and easy.

If you are up to the testing. I can update the header file to cater for the common anode devices.

We need to ensure backwards compatibility, so, I like the approach to add a new #define to cater for the option.

Anobium

[kent_twt4]

I like the idea of using the #define CommonAnode, it has been discussed off and on going way back.

If multiplexing displays then it's not as simple, DisplaySelectA etc. and Disp_SEL_1 etc. need to be initialized to ON (and then set to OFF), same with any Ports, because you are using pnp's or pfet's.

Port's and Lat's could come into play on enhanced midrange here too?

[Anobium]

@Kent. I have a version ready for testing that supports common anode usage. I have used a #define.

@All: Anyone ready for some testing?

@Kent: Regarding port's and lat's. I cannot start adapting until I have someone willing to test. I do not have a suitable seven segment display. We need someone with an enhanced midrange chip and a seven segment display and some time - but, it should not take too long as I now have an approach to handle the condition. But, do we have a reported issue with port's and lat's?

[kent_twt4]

I could do some testing later today. I kind of gave up using 7segs on most recent project, and thinking of going with some MC74HC595's instead. I was having problems with ghosting on the multiplexed 7seg's.

When using a 16f1783 at 32Mhz the 595/7seg combo stopped working using Port's, Lat's handled it O.K. Have to check to see if same with LCD.h.

[Anobium]

This is a test version that supports common anode only. You need rename to 7segment.h and place in the low level folder.

The new command is DisplaySevenSegCommonAnodeType, please therefore use

 #define DisplaySevenSegCommonAnodeType

Let me know the results.

[Anonymous]

Hey guys,

I'm no expert, but am willing to test things. I'm using a Matrix Multimedia development board. Like I said earlier, the hand-changed single instruction addition worked just fine on a multiplexed (two digit) display for me. I just used the example from the help file with the inversion instruction added manually.

I can also breadboard externally if that makes a difference.

I generally use 16F88 but have a few other newer chips around. I'll check.

Thomas Henry

[kent_twt4]

Here is a prelim 7segment.h low include file with #define CommonAnode. It blanks segments/ports and turns chip select lines off/on according to the #define. The header file is untested at the moment, and LATx not implemented yet, if it is decided it is needed.

EDIT: Reword original post. Ooops, I see Anobium has already posted one while I was sleeping...zzzzz

[Anobium]

@Kent. Do we need to merge these two approaches? You also have other changes in the file. What is the best way forward?

[Anonymous]

I just tested Anobium's version on my Matrix Multimedia development board with common anode devices, and it works just fine. In particular, I ran the two digit multiplexed example from the Help file (counted from 00 to 99), using a PIC16F88 at 20MHz.

May I humbly suggest we change the name of the constant simply to CommonAnode. This is far easier to remember and type than the one Anobium proposed.

[Anobium]

Thank you for testing. May I be so bold to recommend an alternative?

#define 7SegmentCommonAnode

I want to retain the functional area of the command. If this is acceptable then I will document and upload later this week.

[Anonymous]

Well, okay. I only mentioned it because I kept mistyping things, having to go back and look it up again. But having the feature available is far more important than the inconvenience of typing in a long-winded word.

So, go for it!

[kent_twt4]

@Thomas
Are you selecting multiplex display driver or enable pins outside the 7Segment.h?, because the original file doesn't handle pnp or pfet drivers.

@Evan
My thoughts are to incorporate Port/Seg blanking and selection lines code (i.e. multiplexing) for the common anode display drivers. I am assuming pnp or pfet sourcing the displays, but maybe I'm all wet?

[Anonymous]

@Kent

I'm using the Matrix Multimedia development board which has a four digit 7-segment common anode display. I only used two of the digits. I didn't do anything special to the code, but just ran it directly from the GCB Help file section on 7-segment commands. Here's the program:

;Common Anode 7-Segment Display Demo

;----- Configuration

#chip 16F88, 8          ;PIC16F88 running at 8 MHz
#config mclr=off        ;reset handled internally
#config osc=int         ;use internal clock

;----- Constants

#define DISP_SEG_A PORTB.0
#define DISP_SEG_B PORTB.1
#define DISP_SEG_C PORTB.2
#define DISP_SEG_D PORTB.3
#define DISP_SEG_E PORTB.4
#define DISP_SEG_F PORTB.5
#define DISP_SEG_G PORTB.6

#define DISP_SEL_1 PORTA.0
#define DISP_SEL_2 PORTA.1

#define DisplaySevenSegCommonAnodeType 1

;----- Program

Do
  For Counter = 0 To 99
    'Get the 2 digits
    Number = Counter
    Num1 = 0
    If Number >= 10 Then
        Num1 = Number / 10
        'SysCalcTempX stores remainder after division
        Number = SysCalcTempX
    End If
    Num2 = Number

    'Show the digits
    'Each DisplayValue will erase the other (multiplexing)
    'So they must be called often enough that the flickering
    'cannot be seen.
    Repeat 500
      DisplayValue 1, Num1
      Wait 1 ms
      DisplayValue 2, Num2
      Wait 1 ms
    End Repeat
  Next
Loop

I found a schematic of my unit on the Web. I see only four NPN drivers; look at the upper right-hand quadrant of page 3. The current is sourced from their emitters.

http://www.matrixmultimedia.com/datasheets/HP-488-00-3.pdf

[kent_twt4]

@Thomas
Thanks for the schematic it helps explain the mystery I think. On the matrixmultimedia board their are two Vcc's, one prior to the 7805 regulator and one after. So the npn transistors must be using the Vcc prior to the regulator in order to get 0.7V + Vcc (after regulator) to drive the npn as a high side switch for the displays.

@All
Perhaps npn high side driver is more common than I thought. Could use a different define to control Disp_Sel_X's pnp or pfets like #define 7SegHighSide_Switches. Or, just skip it altogether?

[Anonymous]

Hi all,

Okay, I got a little time to look into this a bit more, based upon Kent's comments.

I went over the schematic for my Matrix Multimedia board more carefully, and have come to the conclusion the way they did the 7-segment stuff is not the way I would have approached things. It certainly works, but I do think the arrangement is a bit non-standard.

Even though the single inversion command makes my unit work, I believe Kent is correct: in general that is not going to be the case for other affairs.

So, it probably would be good to have an additional constant to flip the sense of the digit selects. With that my unit would work by ignoring it, but also homebuilt stuff would too by including it.

In a nutshell, for true generality, may I propose that we have two constants:

#define 7SegmentCommonAnode 'choose common anode versus common cathode
#define 7SegmentSource      'choose digit current source versus sink

Get it? Someone using a common cathode device would ignore both of these. On the other hand, me, using my Matrix Multimedia development board would use only the first of these. Finally, someone building a common anode device from scratch with PNP transistors in the usual fashion would use both.

These two constants would cover all three cases, without really complicating the include file all that much.

I do have some raw common anode devices and am willing to test if anyone cares to float a trial coding.

Thomas Henry

[kent_twt4]

I've got a 3 digit pnp setup going using DisplayPortX. Went to test using Display_Seg_X and Whoop, back to the drawing board. My use of #ifdef's were a little fast and loose it appears. Maybe tomorrow I'll have something worth looking at.

I don't have any common cathode 7 segments, so backward compatibility would still need to be tested.

[Anobium]

@Kent..... I promise. No code from me on this one whilst you sleep. :-)

[kent_twt4]

Ha, ha, no need to wait, to move the ball forward :)

Yesterday I accidentally trashed the email with your header file. It can get a little confusing sometimes with the way that Yahoo mail stacks up common email replies into one subject.

[Anobium]

I am sorting the download options.... over to you!! :-)

[kent_twt4]

@Evan
Yikes!! I'll pretend I didn't here that :)

@All
O.K. here is a code example using bs250p pfet's (only way to go) for revised 7Segment library (not able to test CommonCathode). It uses two defines, #define 7Seg_CommonAnode, and #define 7Seg_HighSide.

Everything holds together using extended midrange at 32Mhz using DisplayPortX. Using individual segments stable up to 16 Mhz, see erroneous segments at 32Mhz.

'A CommonAnode 7 Segment display example using bs250p pfets
'and revised 7Segment library
'KS 4/1/2014
'Chip model
#chip 16f1783,8
#define 7Seg_CommonAnode
#define 7Seg_HighSide         'pfet or pnp high side drivers

'#define DisplayPortA = PortC
'#define DisplayPortB = PortC
'#define DisplayPortC = PortC

#define DISP_SEG_A PORTC.0
#define DISP_SEG_B PORTC.1
#define DISP_SEG_C PORTC.2
#define DISP_SEG_D PORTC.3
#define DISP_SEG_E PORTC.4
#define DISP_SEG_F PORTC.5
#define DISP_SEG_G PORTC.6
'#define DISP_SEG_DOT PortC.7

#define Disp_Sel_1 PortA.1
#define Disp_Sel_2 PortA.2
#define Disp_Sel_3 PortA.3

dim count as word
dim number as word

Main:
For count = 0 to 999
    number = count
    Num2 = 0
    Num3 = 0
    If number >= 100 Then
      Num3 = number / 100
      number = SysCalcTempX
    End if
    If number >= 10 Then
      Num2 = number / 10
      number = SysCalcTempX
    end if
    Num1 = number
    Repeat 10
      DisplayValue 1, Num1
      wait 5 ms
      DisplayValue 2, Num2
      wait 5 ms
      DisplayValue 3, Num3
      Set PortC.7 Off     'CA manually inserted dp, like in a voltage reading
      wait 5 ms
      Set PortC.7 On
    end Repeat
Next
Goto Main

[kent_twt4]

I'd like to say that somewhere during this journey that I don't see the ghosting problems that I had experienced earlier, very clean display now.

Just as a cautionary note, the on time of the multiplexed segments could be reduced a bit, depending on what kind of supply voltage and resistors are employed.

[Anonymous]

I just tested Kent's include file on my Matrix Multimedia development board, using the 7Seg_CommonAnode constant, but not the 7Seg_HighSide constant (since that's what this board requires).

It works fine.

A quick note: Anobium doesn't use the underscore character in the constant, whereas Kent does. So, we probably ought to get together on which way it should go.

I'm going to breadboard next with PNP's and will report back.

[Anonymous]

Okay, I just tested Kent's include file on a two-digit, common anode display, using 2N3906 PNP transistors. I used both constants this time.

It works fine.

I'll go back and breadboard a common cathode version just to make sure nothing got broken in the process. More, later...

[Anonymous]

And I just tested Kent's include file with a two-digit, common cathode display.

Again, it works fine.

So, with the addition of these two constants, I believe we have all bases covered nicely. A person can use either common-anode or common-cathode, with current sources or current sinks, or any combination thereof.

Thanks, guys.

Thomas Henry