v1.2.16 sPWM Register Config Finder

[board707]

• Add partial STM32duino (Arduino Core STM32) support (Add STM32duino (Arduino Core STM32) support for DMD_RGB alongside Roger Clark core #210 by @asultanov )
  Currently implemented:

  • Monochrome Parallel and SPI modes (with and w/o DMA transfer)
  • RGB modes via bit-bang
    RGB DMA and SPWM features still available on Roger Clark's core only.

• Add sPWM config register finder (Register Config Finder #219 by @kingdo9 )
  It allows you to try different sets of configuration values ​​interactively, making it easier to configure the library for new panels with sPWM drivers. See examples/STM32F4_RP2040/dmd_spwm_panel/register_test/README.md for details.

---

This discussion was created from the release v1.2.16.

[kingdo9]

I'm just tweaking the register test.

The frame content is currently only uploaded once and then repeatedly scans until the STM32 Key button is pressed.
I think its more realstic to make it perform continuous frame updates as a normal demo would.

From my display when these frame updates are continuous, it is easier to pick the correct register because you can see ghosting pixels on the text and flickering differences.

This is how I found a better register for my display, as the ghosting pixels disappeared on the register that was suited for my display.

[board707]

@kingdo9
After testing the Finder I think it would be interesting to make possibility to tune selected register value in small steps on each button press rather than upload an entire register set.
I think this mode will be useful when setting parameters such as brightness or the number of PWM groups.

[board707]

Hi @kingdo9
Let me return to the image yellowing effect I mentioned earlier, which occurs after several loads.
I conducted an experiment where I commented out the profile increment in your Finder code so that the same profile would load every time the button was pressed. Theoretically, the image shouldn't change, but that isn't the case. Around the sixth load, the hue of all the gradient colors shifts toward yellow, and this shift intensifies with each subsequent press over the next three attempts. After the ninth press, the image stops changing. The only way to restore the original colors is to power-cycle the panel.
This effect occurs with all profiles, meaning it is independent of specific values.

I tried to record the process on video, however, the color reproduction turned out poor because the panel is too bright for the phone.
Nevertheless, I think the effect is visible. To make it easier to track the loading stages, I added a toggle between the labels "REG" and "RE" with each button press.

https://youtu.be/RH_iVSq9aro

[kingdo9]

ok, I did similar as you. I've never seen that issue.
SM16380SH and FM6363
I'm using an STM32F411CEU6

fm6363_edit.mp4

SM16380sh_edit.mp4

Also, my new method where it constantly does frame updates instead of just scanning. Although with this method you can see a slight flicker noticeable on the darker colors. With it being a full display, it is more noticable, not sure if that can be resolved.

The brightness is changing on different registers quite noticeable, but camera doesn't pick it up. In a normal way not that strange yellow tint.

video_2026-07-27_23-19-22.mp4

[board707]

I just take captures after each button press to analyze the pulses.
But it's late at night for me now, so I'll continue tomorrow.

[kingdo9]

Is your chip exactly 6363C ?
That is what mine is with DP32020A

[board707]

Hi @kingdo9
I ran a few more tests regarding the yellow shift. The panel with the SM16380SH driver doesn't have this issue, though I do observe image jitter while the configuration is loading. There is no jitter when displaying a static image.

Overall, it seems to me that your Finder makes for an excellent tool for testing panels and code—even for scenarios completely unrelated to configuration registers :)

Is your chip exactly 6363C ?

yes, I have a two different 6363 panels and there are FM6363C on both. Also, both panels with TC7262 row driver (138 type)

[kingdo9]

On that demo showcase I've done,
I made the register finder keep refreshing the frame instead; this causes a continuous "jitter" on some panels you described when loading each config. This way did help me find a SM16380SH config with a reduced flicker on that image compared to other configs.

Is it because that gradient image has darker colors? the flicker is more noticable?
You should find that the FM6363 handles it better from my experience and I don't see any flicker.

[board707]

You should find that the FM6363 handles it better from my experience and I don't see any flicker.

Yes, that's true, the gradient image is more stable on FM6363. However, there's may be another types of distortion that appears in rapidly changing images. Furthermore, adjacent lines in the gradient image are barely distinguishable from each other, which may hide the interference caused by incorrect scanning. So, I think it would be useful to add a demo with a scrolling text to Finder.

[kingdo9]

You should find that the FM6363 handles it better from my experience and I don't see any flicker.

Yes, that's true, the gradient image is more stable on FM6363. However, there's may be another types of distortion that appears in rapidly changing images. Furthermore, adjacent lines in the gradient image are barely distinguishable from each other, which may hide the interference caused by incorrect scanning. So, I think it would be useful to add a demo with a scrolling text to Finder.

Yup seems useful, just working on it. The text scrolls top middle and bottom.
example on SM16380SH - Reg2 everytime the text scrolls on the middle row only, I get a row0 glitch
Reg1 was completely fine.

[kingdo9]

Probably best to put this here as very minor issue, but I've seen it across both projects.

With the new Register Test, when we get the text scroll on the middle row across both halves.

FM6373 and ICND1065L there can be a misalignment issue.
It was the first test I have noticed this on clearly.

I've found that increasing the row cycles per frame resolved it.
on my fork I had to do
FM6373 - SPWM_END_OF_FRAME_EXTRA_ROW_CYCLES=60 ish
ICND1065l - SPWM_END_OF_FRAME_EXTRA_ROW_CYCLES=16

SM16380SH - No issue
FM6363 - No issue

I tested the ICND1065L and saw the same thing on your project. Not sure if you have an FM6373 to test?
I'm guessing you can probably explain the reasoning.
It is a minor problem and don't think its worth the performance decrease with adding more row scans per frame.

[board707]

Thanks for information. I will see it when I will be at home . I can test the issue as I have a panels with FM6373 (as well as every chip in your Finder except ICN1065).

[board707]

@kingdo9
A few words about going further after your PR . It would be great if we can able to use a selected config profile with regular library code without needs to include a full set of register set header files. Do you think it is possible?
I am going to figure it out myself but will be glad to hear your suggestions ( or objections ?) on this subject.

[kingdo9]

@kingdo9 A few words about going further after your PR . It would be great if we can able to use a selected config profile with regular library code without needs to include a full set of register set header files. Do you think it is possible? I am going to figure it out myself but will be glad to hear your suggestions ( or objections ?) on this subject.

sure, whatever you think is best for it.

Do you mean like manually specifying the below somewhere else? so the user would just copy the one config somewhere? Not sure where would be best to put it? It would probably be messy to have at the top of the main dmd_spwm_panel.ino ?

#define DMD_SPWM_FM6373_REGTYPE_22_INCLUDED
    // fm6373_regtype22: P3 - FM6373 - HX6258 - 1/13
    // Scan membership: Scan_13
    {
        22, 41,
        {
            {
                0x020c, 0x0345, 0x0402, 0x0508, 0x0602, 0x0740, 0x0c0a, 0x0d01,
                0x0e04, 0x0f01, 0x10c2, 0x1121, 0x1201, 0x1308, 0x1400, 0x1500,
                0x1600, 0x17f0, 0x180f, 0x19c1, 0x1a1f, 0x1b10, 0x1cff, 0x1d52,
                0x1e52, 0x1f02, 0x2044, 0x2101, 0x221c, 0x2300, 0x7000, 0x7100,
                0x7200, 0x7300, 0x7400, 0xf000, 0xf100, 0xf200, 0xf300, 0xf400,
                0xf500
            },
            {
                0x020c, 0x0345, 0x0402, 0x0508, 0x0602, 0x0740, 0x0c10, 0x0d01,
                0x0e04, 0x0f01, 0x10c2, 0x1121, 0x1201, 0x1308, 0x1400, 0x1500,
                0x1600, 0x17f0, 0x181f, 0x1911, 0x1a1f, 0x1b10, 0x1cff, 0x1d52,
                0x1e56, 0x1f20, 0x2046, 0x2101, 0x221c, 0x2300, 0x7000, 0x7100,
                0x7200, 0x7300, 0x7400, 0xf000, 0xf100, 0xf200, 0xf300, 0xf400,
                0xf500
            },
            {
                0x020c, 0x0345, 0x0402, 0x0508, 0x0602, 0x0740, 0x0c10, 0x0d01,
                0x0e04, 0x0f01, 0x10c2, 0x1121, 0x1201, 0x1308, 0x1400, 0x1500,
                0x1600, 0x17f0, 0x181f, 0x1941, 0x1a1f, 0x1b10, 0x1cff, 0x1d52,
                0x1e58, 0x1f20, 0x2048, 0x2101, 0x221c, 0x2300, 0x7000, 0x7100,
                0x7200, 0x7300, 0x7400, 0xf000, 0xf100, 0xf200, 0xf300, 0xf400,
                0xf500
            }
        }
    },
#endif  // DMD_SPWM_FM6373_R

[board707]

so the user would just copy the one config somewhere?

No, not just the copy.
I was thinking about letting the user select a config number—like in the current Finder—but having the minimal set of tools for loading the profile reside within the library itself, rather than in the Finder files.
Right now, your Finder consists of three source files (excluding the profiles themselves), with the profile-loading code embedded in the demo mode code. I’m planning to extract just the loading logic and move it to a separate source file.

[board707]

@kingdo9
About the issue:

FM6373 and ICND1065L there can be a misalignment issue.
if you have an FM6373 to test?

I just run this test on my FM6373 and below is the result:

Unfortunately, for my FM6373 panel (64x32, 1/8 scan), there is only one configuration set available in your profiles—and it clearly doesn't suit my panel. As you can see in the photo, all the lines are doubled or even tripled; consequently, even the "27" of the preset number is hard to read on the screen. However, the misalignment issue you observed isn't present here :)
However, I have observed that effect on other panels—specifically the ICN2055 and SM16380—where it appears or disappears depending on the profile used. This suggests that the distortion can be eliminated by selecting the correct configuration.

The example of my 6373 panel prompts me to revisit the question of whether sorting configuration sets by the number of scans is optimal. The fact that there is only one set for eight scans in the profile significantly reduces the usability of the configuration selector in its current form.

[board707]

@kingdo9
Addition to misalignment issue.
I just compare your two last Finder commits and should to note that the latest ( 7cf29f2 ) show that issue almost to all config sets on my ICN2055 panel, while for the one before last ( 0d97ae0 ) there are configs that produce a clean image (although most still exhibit the issue).

[kingdo9]

@kingdo9 Addition to misalignment issue. I just compare your two last Finder commits and should to note that the latest ( 7cf29f2 ) show that issue almost to all config sets on my ICN2055 panel, while for the one before last ( 0d97ae0 ) there are configs that produce a clean image (although most still exhibit the issue).

Thanks, I'll test them both.
maybe related to the text speed that was changed

DMD_SPWM_REGISTER_TEST_TEXT_SCROLL_STEP_PIXELS 3UL

previous commit slower? could change to 1UL

[board707]

previous commit slower?

Quite the opposite.
if I understand correct, your previous commit shifted the text by 3 pixels by default, and there were no available settings to change that.

[board707]

@kingdo9
An interesting observation: in cases where the text misalign in the middle, the letters on the screen moves jerkily, even with the shift step set to 1 pixel. Conversely, when there is no central splitting effect, the line moves very smoothly, but artifacts appear in the zero line:

(128x64 s32, ICN2055, profile set 336)