ESP32-HUB75-MatrixPanel-DMA
ESP32-HUB75-MatrixPanel-DMA copied to clipboard
mrcodetastic
Single panel issue with 1/8 scanning
Hello,
I've been using a 64x32 LED Matrix display with 1/8 scanning. I couldn't seem to get your library to work with the 1/8 example. However, as I was trying to make it work I found out that the "ESP32-VirtualMatrixPanel-I2S-DMA.h" has some code in it;
// Stupidity check if ( (vmodule_rows == 1) && (vmodule_cols == 1)) // single panel... { coords.x = x; coords.y = y; return coords; }
which checks if there is a single panel and returns normal coordinates, but since it doesn't do any change on the coordinates, it doesn't work with a 1/8 display. However, when I removed this part of the code, it worked. I wanted to create a pull request with this part removed, but I don't know what effect it will have on other users. For me, it seems to work with 1 and 2 panels with this part removed. Otherwise it doesn't work. Can you check if we can remove this part or can you make any other suggestion to fix this issue?
Thanks for your help.
For 2 panels you do not need to remove this part of code, it should work anyway (because of the fact that "stupidity check" condition is not true). In case of single panel would be better do not remove the code but slightly edit the condition:
if ( (vmodule_rows == 1) && (vmodule_cols == 1) && ( _panelScanRate != ONE_EIGHT_32)) // single panel...
What does this check do? I can't seem to find any functional difference when I remove it. And why you don't want to run the rest of the code for a single panel?
I can try to push a PR but can only do it at the end of June. The addition of the special panel types broke the flow as it seems.
What does this check do? I can't seem to find any functional difference when I remove it. And why you don't want to run the rest of the code for a single panel?
since the 1/8 scan example was designed for chained panles, what these lines do is that if only 1 display is defined, it just ignores it and dosent modify the coordinates to make it compatible with 1/8 panles. honestly i myself dont understand why it was done but what you can do is add 2 copies of the library one that is modified and one that is stock.
I think you mean compatible with 1/16 panels? If I understand it correctly, you can set it to be 1/16 displays by giving the display type at the beginning anyways, so I don't understand what this code do. Can we remove it if it is not affecting anyone?
Can we remove it ?
Better make the change that I proposed in first reply, it should fixing your problem with 1/8 code and do not broke anything else
I don't see it doing anything useful. Can you explain to me why it is there? I don't see any use scenario where this would be useful.
I don't see it doing anything useful. Can you explain to me why it is there? I don't see any use scenario where this would be useful.
well yea idk why its there too, maybe some panels will have issues if the lines are removed but after removing it my 32x32 (1/8) also worked fine, all library functions were intact, i even ported some stock examples to 1/8 scan and they also worked fine. what i think the issue is that, as many people have said that 1/8 scan panels come in a lot of variety so making a universal driver is quite complex, maybe the panels that the author tested it with worked with those lines of code enabled. so a pull up request wont make much sense, as it might fix support for some panels and break it for the others. but then again it might as well be something that we can define in the code, ah im confused myself. perhaps mentioning this in the documentation is the way to go as it might save someone quiet some time
It doesn't change anything about how the displays are driven. It only looks for the number of displays, and doesn't touch the pixels if there is only 1 panel.
I believe it is put there for creating virtual panels, not anything to do with the scan rate. It checks if there is a single panel, and doesn't perform the calculation if there isn't more. Since you don't need to create a virtual matrix for a single panel. We might be able to incorporate it better by changing some stuff maybe.
Sorry for the delay but I just pushed PR (#295) #307 which should fix the logic flow issue. Please let me know if you encounter any issues :)