hub75: fix data buffering

[ehime-iyokan]

I fixed buffering of red data. ( #691 (comment) )

The red data seems to be misaligned, so the display position is incorrect;
however, the other colors are fine.

// Sample code for order of operations
package main

import "fmt"

func main() {
	bitSelect := 2
	data_1 := 0x05
	data_2 := 0x05

	fmt.Println("before")
	fmt.Printf("%08b\n", data_1)
	data_1 = data_1 &^ 1 << bitSelect
	fmt.Printf("%08b\n", data_1)

	fmt.Println("after")
	fmt.Printf("%08b\n", data_2)
	data_2 &^= 1 << bitSelect
	fmt.Printf("%08b\n", data_2)
}

// before: it setting bits to 1 in unintended positions.
// after: it is clearing the bits in the intended positions.
$ go run .    
before
00000101
00010000
after
00000101
00000001

[ehime-iyokan]

I have confirmed sample-program works without any problems. ehime-iyokan/DisplayWeatherInfoOnLEDmatrix@4ec0054

[deadprogram]

@conejoninja PTAL

[conejoninja]

It's on my list, I need to check it doesn't have any unintended consecuences

[conejoninja]

I'm having some hardware issues that doesn't allow me to test this, adding @aykevl just in case I can't review it before next release

[ehime-iyokan]

It's on my list, I need to check it doesn't have any unintended consecuences

I'll try to consider test patterns. @conejoninja
However, I don't have much experience contributing, so I'd appreciate any advice.

[ehime-iyokan]

I have summarized the code fix and test patterns. @conejoninja

🔧 Details of Fix

• Terminology:
  • The if clause refers to the processing starting at line 168.
  • The else clause refers to the processing starting at line 170.

🛠️ Fix Implementation

• The else clause should be corrected as follows:

  d.buffer[c][offsetR] &^= 1 << bitSelect

• This ensures that only the bit at the bitSelect position is cleared, leaving other bits unaffected.

🔍 Observations

• Expected Behavior:

  • The if clause sets the bit at the bitSelect position to 1.
  • Correspondingly, the else clause should set the bit at the bitSelect position to 0.

• Current Implementation Issue:

  • The current code in the else clause is as follows:

    d.buffer[c][offsetR] = d.buffer[c][offsetR] &^ 1 << bitSelect

  • This produces the same result as the following incorrect operation:

    d.buffer[c][offsetR] = (d.buffer[c][offsetR] &^ 1) << bitSelect

  • This does not achieve the desired behavior of clearing the specific bit.

• Analysis:

  • The goal is to set the bit at the position indicated by bitSelect to 0.
  • The current implementation is incorrect and needs to be fixed.

🧪 Sample Code for Behavior Verification

• Go Playground Sample
  • before: Demonstrates behavior before the fix.
  • after: Demonstrates behavior after the fix.

---

📝 Test Verification

Verification of Red LED Operation

• Test Steps:
  • 1. Illuminate all red LEDs.
  • 2. Turn off a single red LED while others remain on.
• Expected Result:
  • Only red LEDs should illuminate or turn off as expected, with no impact on green or blue LEDs.

No Interference with Other Colors

• Test Steps:
  • 1. Illuminate red and green LEDs simultaneously.
  • 2. Illuminate red and blue LEDs simultaneously.
• Expected Result:
  • Red and green, or red and blue, should display correctly without color interference.

Note

• Due to the complexity of the processing, such as differences in behavior depending on brightness (color depth), additional test patterns may be required.
• It might also be a good idea to check if there are any issues when using equipment other than the ones I used.
  • https://github.com/ehime-iyokan/DisplayWeatherInfoOnLEDmatrix?tab=readme-ov-file#environment

---

📋 Test Results

Test Case	Result	Notes
Red LED Operation	Pending	Red LEDs illuminate correctly
No Interference with Other Colors	Pending	No impact on green or blue
?	Pending	?

[sago35]

I believe the correctness of this PR is demonstrated by the following code. The intended behavior is to clear a specific bit, but the previous code cleared all bits below it as well.

https://go.dev/play/p/cVr8fXGKSSi

before 
11111110
11111100
11111000
11110000
11100000
11000000
10000000
00000000

after
11111110
11111101
11111011
11110111
11101111
11011111
10111111
01111111

This is evident when looking at the handling of other colors as well.

[deadprogram]

Thanks for review @sago35 and to @ehime-iyokan for the fix. Now merging.