MAX7219 controlling 2 7-segment display ! help !

[firashelou]

Firashelou,
Here is the data sheet for the display:

https://www.sparkfun.com/datasheets/Components/General/COM-09622-MAX7219-MAX7221.pdf

Here is how you use the SPI:

https://www.arduino.cc/en/Reference/SPI

Read these until you have some understanding of them. Don't ask us to write
your code for you. When you have specific questions please come back we will
be glad to help you but you need to be asking a specific question.
The answers to the questions you've asked are in these two locations. If some part
of one of these is not clear, ask us about that part that isn't clear.
If you write some code and it doesn't work, you can ask about it.
Dwight

ok thank you i found some examples for CA display with the MAX7219 so i hope it would work

and by the way what is your opinion for the last time about Paul's method ?

[CrossRoads]

You'd need to know when each digit was driven so that
you could rewrite the brightness control to match the number
of segments turned on at that time.

I can't see that working as the MAX7219 multiplexes at 800 Hz.
With common cathode, we assume the anodes are driven, and one cathode goes low to turn on one digit.
With a common anode display, it'd be like the same segment of all digits was driven at the same time. So that'd be even harder to control the brightness.


The uneven brightness is more likely from the Scan register in the MAX7219 not being set to match the number of digits selected.
The Max7219 is just a bunch of registers.
To control them via SPI is pretty simple:

Code: [Select]


digitalWrite (ssPin, LOW);
SPI.transfer(registerAddress); // 00 to 15
SPI,transfer (dataToWrite);
digitalWrite (ssPin, HIGH);






addresses 0x09, 0A, 0B, 0C, 0F are usually written in setup() and then not changed.  0A may be changed in loop() for brightness control.
0x01 to 0x08 are the individual digits. You send the data you want displayed for the 8 segments each register controls.
For common cathode 7-segment display, one register is one digit. You can set the scan limit register to 2 to only have 2 digits being driven.
For common anode 7-segment displays, one register is one segment across the 8 digits. So you can see how writing a font is a little funny, with 1 bit of register 1 thru 8 would make up a digit. You'd need the scan limit register set to 7 or 8 to ensure that all segments were being controlled. Bits 0,1 of each register would only be used for the 2 digits for example.
The font might look like

Code: [Select]


byte fontArray[] = {
0b11101101, // segment a
0b10011111, // b
0b11111011, // c
0b01101101, // d
0b01000101, // e
0b01110001, // f
0b01111100, // g
0b00000000, // dp
};

with bit 0 = 0, 1 =1, 2 =2 , 3 =3, 4=4, 5=5, 6=6, 7=7. More bytes are needed for 8,9,0 other letters.
1 in a position = segment on.
So you'd set the NoDecode register to NoDecode mode, and send all 8 digits out.

Code: [Select]


for (byte x=0; x<8; x=x+1){
digitalWrite (ssPin, LOW);
SPI.transfer(registerAddress+1); // result is 1 to 8 for addresses
SPI,transfer (fontArray[dataArray[x]]); // double look up!
digitalWrite (ssPin, HIGH);







The fontArray, dataArray would need a little more thinking. I'm not convinced the mapping I describe above would work, this is my first time looking at it this way.

[CrossRoads]

(freaking forum! messing up my simple code example with color tags. Arrgh!)
(alright, all cleaned up now)

[dwightthinker]

and by the way what is your opinion for the last time about Paul's method ?

You set the Maxim chip to the direct mode, as would be done for 64
LEDs ( read the Maxim spec ). The only issue you will have is that you'll
need to map the segments to the right locations ( some binary logic in your code ).
I recommend you first build the bytes into a memory array of 8 bytes.
You'll need to put one digits segments in as a specific bit of each byte.
Then send the bytes to the display, once build up.
To help out, make a map on a page to see what you need 8x8 map.
I see now I was incorrect about the intensity. If you draw the map, you'll see
what is going on.
Each location on the grid is one segment of your LED. By transposing the axis,
segments for digits, instead of lighting one LED digit up at a time with the
multiplexing, you are doing it sideways across the display.
You just can't use the ROM inside the display to convert the number 1 into
two segments on one digit of the display.
You need to make a table of each segments to light up for each number.
You are switching rows for columns to write to the display.
As an example, you wanted to write the number 5 in the first digit of you display.
Looking at the spec, that is segments A,C,D,F and G.
So, translated, that would be,
Byte0, D0 =1  // your G
Byte1, D0 =1  // F
Byte2, D0 =0  // no E
Byte3, D0 =1  // D
Byte4, D0 =1  // C
Byte5, D0 =0  // no B
Byte6, D0 =1  // A
Byte7, DP?

If you wanted the next digit to show 4, that would be B,C,F and G.
or
Byte0, D1 =1  // your G
Byte1, D1 =1  // F
Byte2, D1 =0  // no E
Byte3, D1 =0  // D
Byte4, D1 =1  // C
Byte5, D1 =1  // no B
Byte6, D1 =0  // A
Byte7, DP?

so the bytes built up for the display would be
0x03,0x03,0x00,0x01,0x03,0x02,0x03
and would display 54 on the first two digits.
I hope this makes some sense.
Dwight

[Paul__B]

then how do you program this chip ?!!

By writing code to put the data that I want, into the registers in the chip.

give me an example please online

Sorry, that would take a lot of research!

all they use is the LedControl library which here on this website too !

Well, not having used it, I can't really help with it.  Maybe some day I will, but so far I haven't.

but why not ! i mean we know the connection and how they work, it lets the proper DIG opens so instead we can connect the DIG to a logic gate that will give 0 out from 1 in it's simple

No, it isn't.  As I explain below, the MAX7219 does a whole lot of work for you.  Adding "logic" (level shifting) unless there is no other way (such as when driving 12V displays), defeats the whole purpose.

there is no array no nothing, all are in the library all i have to do is know how to use the function provided

You are stuck then!  

Paul, I was wrong about the software multiplex but I think the problem is the uneven brightness.  You'd need to know when each digit was driven so that you could rewrite the brightness control to match the number of segments turned on at that time.
The digit control is just a pull high if used for segments, it doesn't know how many are driven. One could make a small circuit to sample the first digit out. It could then synchronise to the display with updated brightness controls.

Total and complete nonsense!

The whole point of the MAX7219 is that it is an array driver to drive an array of 64 - 8 by 8 LEDs.  It does not care what the array looks like, it just drives eight at a time, the same time for each eight, and it controls the current to each of the eight LEDs that it may be driving.  All segments - if it is driving an array of segments - get equal attention.

The uneven brightness is more likely from the Scan register in the MAX7219 not being set to match the number of digits selected.

Equal nonsense.  Gah!  You didn't manage to remove the colour garbage!  I give up quoting any more of your post.

If you are scanning by segment instead of digit, then the scan register is set to the number of segments - either seven or eight if you are actually using decimal points as well.  That's it!  That's all the scan register has to do with it, and all segments - in all digits - get equal brightness.  Of course, if you only have two displays, then you are only ever driving two anodes at any time.

You - and dwightthinker who has added stuff since I wrote this - have the array buffer concept correct.

[dwightthinker]

Total and complete nonsense!

Yep, I had to draw out the array before I figured that out. If you read my
last post, I corrected my self.
Thanks for checking
Dwight

[CrossRoads]

I don't know, I think the scan register may still come into play:

Scan-Limit Register
The scan-limit register sets how many digits are displayed,
from 1 to 8. They are displayed in a multiplexed
manner with a typical display scan rate of 800Hz with 8
digits displayed. If fewer digits are displayed, the scan
rate is 8fOSC/N, where N is the number of digits
scanned. Since the number of scanned digits affects
the display brightness, the scan-limit register should
not be used to blank portions of the display (such as
leading zero suppression). Table 8 lists the scan-limit
register format.
If the scan-limit register is set for three digits or less,
individual digit drivers will dissipate excessive amounts
of power. Consequently, the value of the RSET resistor
must be adjusted according to the number of digits displayed,
to limit individual digit driver power dissipation.
Table 9 lists the number of digits displayed and the
corresponding maximum recommended segment current
when the digit drivers are used.

I've only driven digits as common cathode tho, and made my own font array when I did this 8x32 display:
https://www.youtube.com/watch?v=hwYqgyMc5S4
Looks a lot brighter in person, haven't got filming LEDs down yet.

[Paul__B]

I don't know, I think the scan register may still come into play

No.

The scan-limit register sets how many digits are displayed,
from 1 to 8.

So if you have swapped digits for segments, the scan register defines how many segments you may connect - which is clearly either seven or eight.

[CrossRoads]

the scan register defines how many segments you may connect 

Disagree - there is no register setting to use Common Anode vs Common Cathode, so all 8 segments will always be driven - but not all 8 digits (anodes) unless the scan register is set to 8.

[dwightthinker]

What he is saying is that if using digits to run segments, that register
controls the number of segments since the segments are wired to the chips
digit drivers.
Yes, there is not common cathode/anode switch ( although there should have
been ).
There is a switch so that one can treat the array as 64 individual LEDs.
That means, with the right data, it can be used as either cathode/anode.
Dwight

[runaway_pancake]

http://forum.arduino.cc/index.php?topic=121174.0

[firashelou]

http://forum.arduino.cc/index.php?topic=121174.0

seems interesting but there is a problem with the links when you share it it opens in new tab with this : http://"http//forum.arduino.cc/index.php?topic=121174.0%22

[CrossRoads]

(Offtopic - Pasting in links seems to vary day by day as well - I often see extra http & %22 added, but some days not - links I have created today typing in [ url ] and [ /url ] are working, but I have not tried any forum links today. Forum link pasting yesterday with Chrome seemed to work ok. Very aggravating at times.)

[runaway_pancake]

I don't know why that happens either.
Clicked on the 'View source' button and fixed the hyperlink.
[ If typed in as it is/was shown, that works (of course). ]

[dwightthinker]

I always cut and paste links anyway for security reasons.
I want to know where I'm connecting if possible.
Dwight