{"id":4319,"date":"2019-05-29T20:00:47","date_gmt":"2019-05-29T18:00:47","guid":{"rendered":"https:\/\/msalamon.pl\/?p=4319"},"modified":"2025-12-27T19:31:33","modified_gmt":"2025-12-27T18:31:33","slug":"no-more-gpio-multiplexing-max7219-in-action-part-3","status":"publish","type":"post","link":"https:\/\/msalamon.pl\/en\/no-more-gpio-multiplexing-max7219-in-action-part-3\/","title":{"rendered":"No More GPIO Multiplexing! MAX7219 in Action, Part 3"},"content":{"rendered":"\n

It\u2019s time to use MAX7219<\/a> in a slightly different way than it was probably originally designed for. We will create graphic LED displays controlled by a higher-level graphics library. This will work exactly the same way as, for example, OLEDs. See how simple it is \ud83d\ude42<\/p>\n\n\n\n\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

Complete post series:<\/p>\n\n\n\n

No more multiplexing on GPIO! MAX7219 in action part 1<\/a><\/p>\n\n\n\n

No more multiplexing on GPIO! MAX7219 in action part 2<\/a><\/p>\n\n\n\n

No more multiplexing on GPIO! MAX7219 in action part 3<\/a><\/p>\n\n\n\n

MAX7219 \u2013 matrix multiplexing<\/h1>\n\n\n\n

The fact that these chips are intended for 7-segment displays doesn\u2019t mean they can\u2019t be used differently. The digit decoder can be disabled, and then the data can be written freely. Since one digit means 8 LEDs and the chip controls eight digits, the math is simple \u2013 we can drive 64 LEDs in any way. Of course, our friends from China have made sure you don\u2019t have to struggle with wiring these diodes. There are 8\u00d78 pixel matrices with common cathode available, which are multiplexed in the same way as ordinary 7-segment displays. The LEDs are just arranged differently.<\/p>\n\n\n\n

You can buy single, double, or quad modules. All are chained, which makes the whole connection easier. Each subsequent module is also connected in cascade, so data transmission looks the same as for digits, with the difference that now we have a graphic display.<\/p>\n\n\n\n

Since these are individual pixels, why not use these matrices just like, for example, an OLED I wrote about some time ago<\/a>. The idea is to use the GFX_BW library, which is used to draw simple graphics and bitmaps very easily. <\/p>\n\n\n\n

How is the matrix wired?<\/h2>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

As you remember, with the OLED we worked on a RAM buffer that mirrored what was to be on the display. For MAX7219<\/a> matrices I did the same. GFX_BW needs only a function that sets a single pixel to operate. Pixel (0,0) is located in the top-left corner of the display. As a reminder \u2013 X increases to the right, and Y downward.<\/p>\n\n\n\n

So how does the MAX7219<\/a> accept data when used with matrices? I think the drawing explains it best.<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

R[0\u00f77], i.e. rows \u2013 are the subsequent digits that are written into the MAX7219<\/a>. C[0\u00f77], on the other hand, are the corresponding bits contained in each digit (the transmitted byte). To sum up. To set pixel (0,0) you must set the seventh bit of digit zero in the MAX7219. To set, for example, pixel (4,2) you must light BIT3 of the second digit.<\/p>\n\n\n\n

Now it\u2019s enough to properly assign this data to the buffer that will be pushed to the MAX7219<\/a> chips. During tests I discovered that there are two types of modules on the market \ud83d\ude41 They differ in almost nothing. Well, almost<\/strong>. There is one small detail \u2013 the connections between the IC and the LED matrix are different. They are exactly as in the drawing below.<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

The difference lies in a mirror connection of digits and their bits. A bit like swapping little-endian to big-endian or vice versa. This makes the buffer fill based on the first connection incorrect for the second one and, as a result, text and images are displayed incorrectly, as I reported on my fanpage<\/a>.<\/p>\n\n\n\n

Fortunately, I handled this at the level of the pixel-setting function, so the higher layers are completely unaffected.<\/p>\n\n\n\n

Ultimately, the pixel drawing function looks like this:<\/p>\n\n\n\n

MAX7219_STATUS MAX7219_SetPixel(int x, int y, MAX7219_Color Color)\n{\n\tif ((x &lt; 0) || (x &gt;= MAX7219_X_PIXELS) || (y &lt; 0) || (y &gt;= MAX7219_Y_PIXELS))\n\t\treturn MAX7219_OUT_OF_RANGE;\n\tswitch(Color)\n\t{\n\t\t#if(MAX7219_MODULE_TYPE == 0)\n\t\tcase MAX7219_WHITE: Max7219PixelsBuffer[(x\/8) + (y*MAX7219_COLUMNS)] |= (0x80 &gt;&gt; (x&amp;7)); break;\n\t\tcase MAX7219_BLACK: Max7219PixelsBuffer[(x\/8) + (y*MAX7219_COLUMNS)] &amp;= ~(0x80 &gt;&gt; (x&amp;7)); break;\n\t\tcase MAX7219_INVERSE: Max7219PixelsBuffer[(x\/8) + (y*MAX7219_COLUMNS)] ^= (0x80 &gt;&gt; (x&amp;7)); break;\n\t\t\n\t\t#elif(MAX7219_MODULE_TYPE == 1)\n\t\tcase MAX7219_WHITE: Max7219PixelsBuffer[(x\/8) + ((MAX7219_PIXELS_PER_DEVICE_ROW-1) - ((y%8)) + ((y\/8)*MAX7219_PIXELS_PER_DEVICE_ROW))*MAX7219_COLUMNS] |= (1 &lt;&lt; (x&amp;7)); break;\n\t\tcase MAX7219_BLACK: Max7219PixelsBuffer[(x\/8) + ((MAX7219_PIXELS_PER_DEVICE_ROW-1) - ((y%8)) + ((y\/8)*MAX7219_PIXELS_PER_DEVICE_ROW))*MAX7219_COLUMNS] &amp;= ~(1 &lt;&lt; (x&amp;7)); break;\n\t\tcase MAX7219_INVERSE: Max7219PixelsBuffer[(x\/8) + ((MAX7219_PIXELS_PER_DEVICE_ROW-1) - ((y%8)) + ((y\/8)*MAX7219_PIXELS_PER_DEVICE_ROW))*MAX7219_COLUMNS] ^= (1 &lt;&lt; (x&amp;7)); break;\n\t\t\n\t\t#endif\n\t\t\n\t\tdefault: return MAX7219_ERROR;\n\t}\n\treturn MAX7219_OK;\n}<\/pre>\n\n\n\n
You choose which kind of module you will be dealing with via the MAX7219_MODULE_TYPE<\/em><\/strong> constant. Type set to 0<\/strong> is the first one I showed \u2013 more human-friendly. If you have the second module, set this constant to 1<\/strong>.<\/p>\n\n\n\n
Library settings<\/h3>\n\n\n\n
Besides the matrix type mentioned above, you need to set a few more constants.<\/p>\n\n\n\n
First, the number of devices, i.e. how many MAX7219<\/a> chips you have in the setup. For a chain of 7-segment displays this was one value. Here I made two: <\/p>\n\n\n\n