Go Down

### Topic: [SOLVED] 8x8 Matrix with MAX 7219 chip (Read 4580 times)previous topic - next topic

#### hecho

##### Feb 18, 2014, 11:17 amLast Edit: Feb 20, 2014, 07:56 pm by hecho Reason: 1
Hello to all,

I'm using the library :

https://www.pjrc.com/teensy/td_libs_Matrix.html

to control a 8x8 display, but there is a problem:
Taking as reference the example:

http://wiring.org.co/learning/libraries/hellomatrix.html

and lighting the individual LEDs with the command:

Code: [Select]
`myMatrix.write (X, Y, HIGH);`

If I turn on the LED "Row 7", the LEDs of the "Row 0" as if turning on the LED "Row 0", the LEDs of the "Row 7",  it is as if the matrix on the display, was shifted by a "+1", having an address different from what you expect. In fact normally the "X" axis is directed as follows: 0,1,2,3,4,5,6,7 ... while in this library is as if it were addressed in this way: 7,1,2,3 ,4,5,6,0.

I used this simple code (taken from the examples of the library):

Code: [Select]
`#include <Sprite.h>#include <Matrix.h>Matrix myMatrix = Matrix(8, 10, 9);void setup (){  myMatrix.clear();  myMatrix.write (0,0, HIGH); //1  delay (1000);  myMatrix.write (0,7, HIGH ); //2  delay (1000);  myMatrix.write (7,0, HIGH ); //3  delay (1000);  myMatrix.write (7,7, HIGH) ; //4  delay (1000);}void loop(){}`

This code "should" turn on the LEDs in the four corners :

Instead, I turn on the two LEDs on the top corners, and then those immediately below:

To turn on the LEDs of the four corners I have to use the code:

Code: [Select]
`  myMatrix.clear();  myMatrix.write (0,0, HIGH); //1  delay (1000);  myMatrix.write (0,7, HIGH ); //2  delay (1000);  myMatrix.write (1,0, HIGH ); //3  delay (1000);  myMatrix.write (1,7, HIGH) ; //4  delay (1000);`

By analyzing the code in the "sprite_animation":

http://wiring.org.co/learning/libraries/spriteanimation.html

I noticed that to scroll the sprite on the screen, you use a "double" sprite:

Code: [Select]
`myMatrix.write (0,0, wave) // place sprite on screenmyMatrix.write (x-8,2, wave) // place sprite again, elsewhere on screen`

Indeed sprite "myMatrix.write (x-8,2, wave);" is translated to 8 positions to turn properly throughout the matrix, but why?

It's the same problem found in this post:

http://wiring.org.co/cgi-bin/yabb/YaBB.pl?num=1126118886/26#26

How so? how can I solve this problem in the matrix?

Using a different library, for example the LedControl:

http://playground.arduino.cc//Main/LedControl

The matrix work correctly. But for me as a beginner it is easier to use matrix.h and sprite.h not LedControl.

Below, I attach a video to let you understand better the "anomaly"

http://youtu.be/j544pL8sTTo

Thank you
Luc@

#### sensai

#1
##### Feb 19, 2014, 01:05 am
is it possible you got the max7219 wired wrong in a couple places?
What LED does this light up?
Code: [Select]
`myMatrix.write (6,0, HIGH ); `
you can narrow it down by testing each individually.

#### hecho

#2
##### Feb 19, 2014, 10:25 pm
No, it isn't. My MAX7219 wired correctly, infact with another library it works perfectly. The problem, differently from what I have said before, it isn't the inversion of "row 1" with "row 7", but it is as if the matrix on the display, was shifted by a "+1", having an address different from what you expect. In fact normally the "X" axis is directed as follows: 0,1,2,3,4,5,6,7 ... while in this library is as if it were addressed in this way: 7,1,2,3 ,4,5,6,0.

Below, I attach a video to let you understand better the "anomaly"

http://youtu.be/j544pL8sTTo

#### sensai

#3
##### Feb 19, 2014, 11:29 pm
I totally had the same issue not so long ago. I rewired and it worked. Not sure what to tell you.

#### bperrybap

#4
##### Feb 20, 2014, 01:56 am

it is as if the matrix on the display, was shifted by a "+1", having an address different from what you expect. In fact normally the "X" axis is directed as follows: 0,1,2,3,4,5,6,7 ... while in this library is as if it were addressed in this way: 7,1,2,3 ,4,5,6,0.

I have some 8x8 matrix PCB kits coming in and so I was just going through the code
to get ready for my displays.

It is more than "as if it were addressed this way". It is coded in the library to do actually do that.

Here is the code that does this:
[ it is in the function, buffer() ]
Code: [Select]
`  // wrap shift relative x for nexus module layout  if (x == 0){    x = 8;  }  --x;`

I am assuming that this was coded to work with a particular matrix board
that didn't wire up the pins in the same order as the bits inside the 7219.

The internal register of the 7219 has bits mapped as follows:
Code: [Select]
`bit Segment0      G1      F2      E3      D4      C5      B6      A7      DP`

So I would assume that you would simply wire up bit 0
to the LSB and bit 7 to the MSB of the matrix pins and then bit 0 is X0, bit 1, X1, etc.. to bit 7 as X7
And in fact from looking at the schematic for the matrix boards that I have on order
this is how it was done.
Code: [Select]
`regbit LEDSeg   X  0      G     X0  1      F     X1  2      E     X2  3      D     X3  4      C     X4  5      B     X5  6      A     X6  7      DP    X7`

However, if you look on Paul's site:
https://www.pjrc.com/teensy/td_libs_Matrix.html
you will see that it recommends wiring up the matrix pins like this:
Code: [Select]
`regbit LEDSeg   X  7      DP    X0  0      G     X1  1      F     X2  2      E     X3  3      D     X4  4      C     X5  5      B     X6  6      A     X7`

Note that all the bits are rotated around because X0 started with DP rather
than G so now you can't simply have a one to one mapping of bits to X position.

So if you look at the code above,
It moves x value 0 to 8, but then always subtracts 1.
That has the net effect of rotating bits around to match this miswiring.

So now  if you have what I would consider as a "normal" wiring, it will scramble
exactly the way you are seeing.

Maybe this "nexus module layout" referred to in the comment is some pre-made board
that "mis-wired" the pins so this library is correcting for it in s/w.

Anyway, it is a simple s/w fix to remove that code.
You might want to ifdef it out rather than just delete to keep a reminder of the old
code in case it ever comes up again. (That's what I'll be doing)

In the mean time I'm going to send a note to Paul to have him update his page
to add a note that this library does not wire up the X location to match the register bits.

--- bill

#### hecho

#5
##### Feb 20, 2014, 01:12 pm
Great! to take a test I simply commented that part of the code and now the display works perfectly! okay this way?

Code: [Select]
` /* if (x == 0){    x = 8;  }  --x;*/`

Thanks!!

#### bperrybap

#6
##### Feb 20, 2014, 06:27 pm

Great! to take a test I simply commented that part of the code and now the display works perfectly! okay this way?

Code: [Select]
` /* if (x == 0){    x = 8;  }  --x;*/`

Thanks!!

using /* */ is not a good way to eliminate code and I would recommend
against that method.
While it works in this particular case,
it breaks if used on a block of code that contains comments.
The prefered method of "removing" code is to use a conditional
as it will always work even when the block of code contains comments.
i.e.

Code: [Select]
`#if 0 if (x == 0){    x = 8;  }  --x;#endif`

will always work since 0 is always false.
I'm going to use an ifdef so it can potentially be turned back on.
Perhaps something like this:
Code: [Select]
`#ifdef NEXUS_MATRIX  // wrap shift relative x for nexus module layout  if (x == 0){    x = 8;  }  --x;#endif`

--- bill

#### hecho

#7
##### Feb 20, 2014, 07:55 pm
thank you! The help was very useful

Luc@

Go Up