Issue with LED mapping when using an ESP32, MAX7219 IC and a 10 Segment LED bar graph

[Muhammad-Alli]

I experienced this issue using the ledcontroller library version 2.0.2

This is the code i used:

// Include the LedController library using standard angle brackets for installed libraries
#include <LedController.hpp>

// Define the ESP32 pins connected to the MAX7219
#define DIN_PIN 23  // Connected to MAX7219 DIN (Data In)
#define CS_PIN 5    // Connected to MAX7219 CS/LOAD (Chip Select)
#define CLK_PIN 18  // Connected to MAX7219 CLK (Clock)

// The LedController object setup:
// We are using 1 segment/module of MAX7219 (the first number in the template)
// The second number (1) means we are using it in a mode where each segment has 1 row of LEDs available
// For a bar graph, we are essentially treating 2 of the 8 available digits as bar graph segments.
sakurajin::LedController<1, 1> lc = sakurajin::LedController<1, 1>();

void setup() {
  Serial.begin(115200);
  Serial.println("ESP32 MAX7219 10-Segment Bar Graph Test");

  // Initialize the LedController with software SPI configuration
  sakurajin::controller_configuration<1, 1> config;
  config.useHardwareSpi = false; // Use Software SPI
  config.SPI_MOSI = DIN_PIN;     // DIN
  config.SPI_CS = CS_PIN;        // CS
  config.SPI_CLK = CLK_PIN;      // CLK
  lc.init(config); // Initialize the controller with the defined config

  // Wake up the MAX7219 and set brightness
  lc.activateAllSegments(); // Corrected from powerOn()
  lc.setIntensity(15);       // Set brightness to a medium level (0-15)
  lc.clearMatrix();         // Clear all LEDs
}

void setBarGraph() {
  // Clear both digits first
  lc.setRow(0, 1, B00000000);
  delay(2000);

  lc.setRow(0, 1, B10000000); // LED 1 ON
  delay(2000);

  lc.setRow(0, 1, B11000000); // LEDs 1-2 ON
  delay(2000);

  lc.setRow(0, 1, B11100000); // LEDs 1-3 ON
  delay(2000);

  lc.setRow(0, 1, B11110000); // LEDs 1-4 ON
  delay(2000);

  lc.setRow(0, 1, B11111000); // LEDs 1-5 ON
  delay(2000);

  lc.setRow(0, 1, B11111100); // LEDs 1-6 ON
  delay(2000);

  lc.setRow(0, 1, B11111110); // LEDs 1-7 ON
  delay(2000);

  lc.setRow(0, 1, B11111111); // LEDs 1-8 ON (Digit 0 full)
  delay(2000);

  // Digit 1 for LEDs 9-10
  lc.setRow(0, 2, B1000000); // Clear Digit 1
  delay(2000);

  lc.setRow(0, 2, B11000000); // LEDs 9-10 ON (assuming wiring maps MSB → LED 9)
  delay(5000);

  Serial.println("Switching bar graph OFF");
  lc.setRow(0, 1, B00000000);
  lc.setRow(0, 2, B00000000);
}


void loop(){
  Serial.println("Switch LED bar graph ON in steps");
  setBarGraph();
}

This was the connection setup:

Also figured from experimentation with LED 1 to 8 that the connection must be according to the table for leds 1 to 10:

LED	MAX7219 pin (segment)	Bit in LedController setRow()
1	DP	Bit 7 (MSB)
2	SEG A	Bit 6
3	SEG B	Bit 5
4	SEG C	Bit 4
5	SEG D	Bit 3
6	SEG E	Bit 2
7	SEG F	Bit 1
8	SEG G	Bit 0 (LSB)

All of the above cathodes connected to DIG1 (before that i had it connected to DIG0)

LED	MAX7219 pin	Expected bit in setRow()
9	DP	Bit 7
10	SEG A	Bit 6

All cathodes to DIG2 (before that had it connected to DIG1)

This was the result:

1. DIG-0 (LEDs 1–8)

• Wiring: LED1 → DP, LED2 → SEG A, LED3 → SEG B, …, LED8 → SEG G, all cathodes to DIG-0.
• Behavior: LEDs light sequentially in the expected order (1 → 8) when lc.setRow(0,0,mask) is used.
• Bitmask mapping is logical and predictable.

2. DIG-1 (LEDs 9–10 in original setup)

• Wiring: LED9 → DP, LED10 → SEG A, cathodes to DIG-1.
• Behavior: LEDs light in an unexpected order — LED10 lights before LED9 when using the same bitmask approach that worked for DIG-0.
• Sequential mapping breaks; same bit → segment mapping as DIG-0 does not hold.

3. DIG-1 and DIG-2 in test setup

• When DIG-0 is repurposed for LEDs 1–8 and DIG-1 for LEDs 9–10:
  • DIG-1 now behaves as DIG-0 did (logical sequential behavior).
  • DIG-2 behaves like DIG-1 did in the original setup: LEDs light in the “wrong” order (LED10 before LED9).

I was not able to identify the cause for the issue, just wanted to bring it to your attention.
When i tested similar code on version 17.2, i did not have this mapping issue.