Various fixes
* Default to inverted clock phase because it's the second time this has happened, and it doesn't impact older panels. * Fix an issue with the Virtual Display Class
This commit is contained in:
parent
8b36964e68
commit
8d8b1fb215
3 changed files with 22 additions and 15 deletions
|
@ -262,12 +262,13 @@ struct HUB75_I2S_CFG {
|
|||
|
||||
/**
|
||||
* I2S clock phase
|
||||
* 0 (default) - data lines are clocked with negative edge
|
||||
* 0 - data lines are clocked with negative edge
|
||||
* Clk /¯\_/¯\_/
|
||||
* LAT __/¯¯¯\__
|
||||
* EO ¯¯¯¯¯¯\___
|
||||
*
|
||||
* 1 - data lines are clocked with positive edge
|
||||
* 1 - data lines are clocked with positive edge (default now as of 10 June 2021)
|
||||
* https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/issues/130
|
||||
* Clk \_/¯\_/¯\
|
||||
* LAT __/¯¯¯\__
|
||||
* EO ¯¯¯¯¯¯\__
|
||||
|
@ -291,7 +292,7 @@ struct HUB75_I2S_CFG {
|
|||
bool _dbuff = false,
|
||||
clk_speed _i2sspeed = HZ_10M,
|
||||
uint8_t _latblk = 1,
|
||||
bool _clockphase = false,
|
||||
bool _clockphase = true,
|
||||
uint8_t _min_refresh_rate = 85
|
||||
) : mx_width(_w),
|
||||
mx_height(_h),
|
||||
|
|
|
@ -59,6 +59,14 @@ class VirtualMatrixPanel
|
|||
virtualResY = vmodule_rows*panelY;
|
||||
virtualResX = vmodule_cols*panelX;
|
||||
|
||||
/* Virtual Display width() and height() will return a real-world value. For example:
|
||||
* Virtual Display width: 128
|
||||
* Virtual Display height: 64
|
||||
*
|
||||
* So, not values that at 0 to X-1
|
||||
*/
|
||||
|
||||
|
||||
_s_chain_party = serpentine_chain; // serpentine, or 'S' chain?
|
||||
_chain_top_down= top_down_chain;
|
||||
|
||||
|
@ -107,7 +115,7 @@ inline VirtualCoords VirtualMatrixPanel::getCoords(int16_t x, int16_t y) {
|
|||
|
||||
coords.x = coords.y = -1; // By defalt use an invalid co-ordinates that will be rejected by updateMatrixDMABuffer
|
||||
|
||||
if (x < 0 || x >= width() || y < 0 || y >= height() ) {
|
||||
if (x < 0 || x >= width() || y < 0 || y >= height() ) { // Co-ordinates go from 0 to X-1 remember! width() and height() are out of range!
|
||||
//Serial.printf("VirtualMatrixPanel::getCoords(): Invalid virtual display coordinate. x,y: %d, %d\r\n", x, y);
|
||||
return coords;
|
||||
}
|
||||
|
@ -127,14 +135,14 @@ inline VirtualCoords VirtualMatrixPanel::getCoords(int16_t x, int16_t y) {
|
|||
{
|
||||
// First portion gets you to the correct offset for the row you need
|
||||
// Second portion inverts the x on the row
|
||||
//coords.x = (y / panelResY) * (module_cols * panelResX) + (virtualResX - 1 - x);
|
||||
coords.x = (y / panelResY) * (module_cols * panelResX) + (virtualResX - 0 - x); // hack untested 9/june/21
|
||||
coords.x = (y / panelResY) * (module_cols * panelResX) + (virtualResX - x) - 1;
|
||||
|
||||
// inverts the y the row
|
||||
coords.y = panelResY - 1 - (y % panelResY);
|
||||
}
|
||||
else
|
||||
{
|
||||
// Normal chain pixel co-ordinate
|
||||
coords.x = x + (y / panelResY) * (module_cols * panelResX) ;
|
||||
coords.y = y % panelResY;
|
||||
}
|
||||
|
@ -146,8 +154,6 @@ inline VirtualCoords VirtualMatrixPanel::getCoords(int16_t x, int16_t y) {
|
|||
coords.x = (_cfg.mx_width * _cfg.chain_length - 1) - coords.x;
|
||||
coords.y = (_cfg.mx_height-1) - coords.y;
|
||||
|
||||
//coords.x = (this->display->getCfg().mx_width-1) - coords.x;
|
||||
//coords.y = (this->display->getCfg().mx_height-1) - coords.y;
|
||||
}
|
||||
|
||||
|
||||
|
|
|
@ -155,7 +155,7 @@ For example: If you want to chain two of these horizontally to make a 128x32 pan
|
|||
|
||||
Finally, if you wanted to chain 4 x (64x32px) panels to make 128x64px display (essentially a 2x2 grid of 64x32 LED Matrix modules), a little more magic will be required. Refer to the [Chained Panels](examples/ChainedPanels/) example.
|
||||
|
||||
Resolutions beyond 128x128 are more likely to result in crashes due to [memory](/doc/i2s_memcalc.md) constraints etc. You're on your own at this point.
|
||||
Resolutions beyond 128x64 are more likely to result in crashes due to [memory](/doc/i2s_memcalc.md) constraints etc. You are on your own after this point - PLEASE do not raise issues about this, the library can't magically defeat the SRAM memory constraints of the ESP32.
|
||||
|
||||
![ezgif com-video-to-gif](https://user-images.githubusercontent.com/12006953/89837358-b64c0480-db60-11ea-870d-4b6482068a3b.gif)
|
||||
|
||||
|
|
Loading…
Reference in a new issue