[1.1.x] Tweaks and additions for MAX7219

[thinkyhead]

Adjustments made while playing around with a MAX7219 unit….

• Add an option to rotate the display in increments of 90° (CCW).
• Add an option to enable/disable the init test pattern.
• Slightly optimize the initialization test pattern.
• Add a spiral-shaped initialization test-pattern.
• Add some inline helpers to display dual-row quantities and indicators.
• Add functions to draw digits on 8-digit numeric displays.
• Fix buffer depth display, which was off by one.
• Use MAX7219_DEBUG_PRINTER_ALIVE as an opportunity to re-initialize.
• Allow TAIL/HEAD to be shown on the same line (as a range).

Counterpart to #11034

[Roxy-3D]

I'm guessing you now have a Max7219 LED matrix connected to your printer.

Aren't they cool?

[thinkyhead]

Aren't they cool?

Yes! I soldered one together last night and now have it connected to a bare Megatronics 3.1 for experimentation. It's a handy little device! Now I'm going to solder up another and daisy-chain them for even more coolness.

[Roxy-3D]

Now I'm going to solder up another and daisy-chain them for even more coolness.

Almost all of my printers have them. I have a few extra ones sitting around. If you make it a simple #define that says how many devices are in the chain... I'll connect up a 2nd one to at least two of my printers.

It might be good to have a dynamic MCode that controls how many MAX7219's are active. The reason being more of them takes more cycles to clock out the bits. Some times more lights are valuable. But other times, especially if you are outputting a lot of debug info to the LED's, the extra CPU time might not be acceptable.

Also... Just for kicks, I did a 'star burst' initialization test pattern. It would randomly pick a starting point and swell out (in a circle pattern) from there until it covered the entire matrix. And then it would pick a new location (at random) and start clearing the LED's in an expanding circle pattern. It does look pretty cool.

[thinkyhead]

If you make it a simple #define that says how many devices are in the chain

I haven't quite figured that out yet. The datasheet talks about using the NOOP register to skip devices that are "cascaded" so I'll have to experiment with that to see how it works.

I did add some code to draw numeric digits on an 8-digit numerical display. I'll have to get some of those units to play with too.

[Roxy-3D]

If you make it a simple #define that says how many devices are in the chain

I haven't quite figured that out yet. The datasheet talks about using the NOOP register to skip devices that are "cascaded" so I'll have to experiment with that to see how it works.

I was just suggesting something more simple. I was thinking just ignore the extra displays from what is specified. They would end up with noise. But certainly, using the NOP command would be a good way to do it.

I saw you changed the row and col parameters on the low level functions. That might not work for me. I have my display's orientated with the cable on the down side of the matrix. That is because I have them mounted in a printed corner piece that also holds some debug (and printer power and reset) switches. That keeps all the wiring hidden.

It might be easy to add a #define to shift the row and col orientation by 90 degrees. (So row is still row, and col is still the column).

[thinkyhead]

I was thinking just ignore the extra displays from what is specified.

When the displays are chained, in my testing the second one imply displayed the same content as the first one. (Well, sort of. The ALIVE LED displays the opposite.) The datasheet describes "cascaded" devices, which presumably would also support the single-unit 16x8 and larger matrixes.

I saw you changed the row and col parameters on the low level functions.

By default (with MAX7219_ROTATED disabled) everything should behave just as it always has. I changed col, row to x, y in the LED on/off functions to accommodate MAX7219_ROTATED.

It also seemed appropriate to modify the (as yet unused) Set/Clear Row/Column functions too, to make the API more consistent and abstract away the idea that a "row" always corresponds to a "register." Under the updated API a "row" is always a horizontal row, according to MAX7219_ROTATED.

It might be easy to add a #define to shift the row and col orientation by 90 degrees. (So row is still row, and col is still the column).

With the units I have, under normal conditions the display is upright with the cables on the right.

MAX7219_ROTATED rotates the display by 90° CCW so the cables can be oriented to the bottom.

[Roxy-3D]

The bottom picture is how I have mine configured. So... I would prefer the lower left corner is (X,Y) = (0,0) And the lower right is (X,Y)=(7,0) And the upper right is (X,Y)=(7,7)

But... If you don't feel like doing that... I can mess with what you have currently defined to make that possible.

Also, now might be a good time to agree (or come to consensus) that going forward, the lower left is (X,Y) = (0,0) And the lower right is (X,Y)=(7,0).

MAX7219_ROTATED rotates the display by 90° CCW so the cables can be oriented to the bottom.

UPDATE: I didn't see that you already addressed this!

THANKS!

[Roxy-3D]

Apparently the "native" orientation for this unity would prefer the cables on the left (with the text upright), so that the top-left LED is Register 1, Bit 7, and the bottom-right LED is Register 8, Bit 0.

Yes. That is true on the units I have also. But it is easy to flip the orientation by just doing a (7-x) or (7-y) after doing the range checking.

Does this mean we may need a #define ROTATED_180_DEGREES also?

[p3p]

I seem to remember having issues with the orientations when working with them, not helped by the circuit board getting manufactured wrong having the displays rotated and in the wrong order.. or something it was long ago.

Here is my library I used at the time though, looking through I had to be amused by the blit function I must have been feeling ambitious with what I was going to display, ended up just being a bar graph and a rotating diamond screen saver if I remember rightly.
max7219lib.zip

This is the numeric font I used as well, though I don't think you will be wanting scrolling numeric data

//8x8 number fonts                               
uint8_t large_number_font[10][8] = {    {0x00, 0x3E, 0x7F, 0x59, 0x4D, 0x7F, 0x3E, 0x0},
                                        {0x00, 0x04, 0x06, 0x7F, 0x7F, 0x00, 0x00, 0x0},
                                        {0x00, 0x42, 0x63, 0x71, 0x59, 0x4F, 0x46, 0x0},
                                        {0x00, 0x22, 0x63, 0x49, 0x49, 0x7F, 0x36, 0x0},
                                        {0x18, 0x1C, 0x16, 0x13, 0x7F, 0x7F, 0x10, 0x0},
                                        {0x00, 0x27, 0x67, 0x45, 0x45, 0x7D, 0x39, 0x0},
                                        {0x00, 0x3C, 0x7E, 0x4B, 0x49, 0x79, 0x30, 0x0},
                                        {0x00, 0x01, 0x01, 0x71, 0x79, 0x0F, 0x07, 0x0},
                                        {0x00, 0x36, 0x7F, 0x49, 0x49, 0x7F, 0x36, 0x0},
                                        {0x00, 0x06, 0x4F, 0x49, 0x69, 0x3F, 0x1E, 0x0}  };

ps. I remembered what the blit method was for, .. the scrolling numeric values

[thinkyhead]

I've modified the code so you can set the CCW rotation between -270 … +270 in increments of 90.

[Roxy-3D]

Wouldn't +/- 180 degrees be enough?

On this line:

  #define MAX7219_ROTATE     0  // Rotate the display counter-clockwise (multiple of +/- 90°)

I would suggest we give the user some clue how to know the proper number. For example, "if your wires are at the bottom of the Max7219 Matrix, you need -90. If the wires are at the left side, you need -180.

[thinkyhead]

Wouldn't +/- 180 degrees be enough?

For my unit, the result is:

  0 = Wires on the left
 90 = Wires on the bottom
180 = Wires on the right
270 = Wires on the top

[thinkyhead]

I would suggest we give the user some clue how to know the proper number.

I'm not sure this is universal. It will depend on how the unit is constructed.

[Roxy-3D]

I'm not sure this is universal. It will depend on how the unit is constructed.

I think all the units commonly available are the same. They all follow the 'reference design'. And I've gotten them from 3 different sources and everything is the same.

What I meant was depending on where the user's wires are located, we should be able to communicate the 'correct' rotation. It probably would be good if everybody has the status lights and such in the same location and orientation.

[thinkyhead]

😁

[thinkyhead]

I won't add this, but it's handy for testing…

#if ENABLED(MAX7219_DEBUG)
  inline void gcode_M7219() {
    if (parser.seen('I'))
      for (uint8_t r = 0; r < 8; r++) Max7219_Set_Row(r, 0);
    else if (parser.seenval('R')) {
      const uint8_t r = parser.value_int();
      Max7219_Set_Row(r, parser.byteval('V'));
    }
    else if (parser.seenval('C')) {
      const uint8_t c = parser.value_int();
      Max7219_Set_Column(c, parser.byteval('V'));
    }
    else if (parser.seenval('X') || parser.seenval('Y')) {
      const uint8_t x = parser.byteval('X'), y = parser.byteval('Y');
      if (parser.seenval('V'))
        Max7219_LED_Set(x, y, parser.boolval('V'));
      else
        Max7219_LED_Toggle(x, y);
    }
  }
#endif

      #if ENABLED(MAX7219_DEBUG)
        case 7219: gcode_M7219(); break;                          // M7219: Set LEDs, columns, and rows
      #endif

[Roxy-3D]

I won't add this, but it's handy for testing…

Whoa! That's a good idea. An M7219 command!!! I think we should add it.

But what gives with all those bread board wires? You bought the pre-assembled units shown in #11033 (comment) , right? Why would you wire that up with discrete wires? Maybe it was so you could mess around with the 7 segment displays like these: https://www.ebay.com/itm/MAX7219-8-Digital-Segment-Digital-LED-Display-Tube-For-Arduino-51-AVR-STM32/201536584320?hash=item2eec843a80:g:6lAAAOSwoudW4Ss5

[Roxy-3D]

Also... Should we change STEPPER to PLANNER on the #define's too ? (not just the comments???)

-  #define MAX7219_DEBUG_STEPPER_QUEUE 0  // Show the current stepper queue depth on this and the next LED matrix row
+  #define MAX7219_DEBUG_STEPPER_QUEUE 0  // Show the current planner queue depth on this and the next LED matrix row

[Roxy-3D]

I was ready to test the rotation stuff and see if it handles my case... But sadly, this isn't merged yet.
Given all the code is conditionally enabled by:

#if ENABLED(MAX7219_DEBUG)

it is very low risk. How about we merge the new code (and hopefully the M7219 gcode also)? (as soon as Travis says OK!)

[thinkyhead]

But sadly, this isn't merged yet.

GitHub provides links to download any branch as a ZIP file.

https://github.com/thinkyhead/Marlin/archive/bf1_MAX7219.zip
https://github.com/thinkyhead/Marlin/archive/bf2_MAX7219.zip

Anyway, will merge soon…

[thinkyhead]

Here's a short video about using the Max7219 with Marlin…
https://www.youtube.com/watch?v=JXMEKXsmTpA

[Roxy-3D]

That was cool! I laughed when I saw my #define's on the screen.... Here is the OpenScad source code for my corner switch & LED debug lights. You can cut out what ever you don't want, but the mount for the LED matrix will save you some time when you decide where you want to put it on your printer. (This one clicks on the i2020 aluminum rails in the front corner of the Folger Tech i3-2020. (And... As you can see, the connector is pointed down with the LED Matrix glued into the printed plastic piece.)

Corner_Reset_Switch.zip

If you want to add debug (or reset) switches... These drop into the big holes in the part:

http://www.ebay.com/itm/2x-Black-Lockless-button-reset-switch-Push-OFF-ON-Car-Boat-Toys-12mm-427-SWTG-/223021069733?hash=item33ed1775a5

http://www.ebay.com/itm/10x-12mm-Red-Momentary-OFF-ON-Push-Button-Pushbutton-Car-Boat-Lockless-Switch-BB-/302715339391?var=&hash=item467b3d827f

[Roxy-3D]

I do like the spiral init pattern....