From c66b592e9fcde0767aa8dc912100c25433c8c5db Mon Sep 17 00:00:00 2001
From: mrfaptastic <12006953+mrfaptastic@users.noreply.github.com>
Date: Sat, 28 Jan 2023 21:54:09 +0000
Subject: It's 'COLOR'
---
doc/BuildOptions.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
(limited to 'doc')
diff --git a/doc/BuildOptions.md b/doc/BuildOptions.md
index a5bbe64..9069b83 100644
--- a/doc/BuildOptions.md
+++ b/doc/BuildOptions.md
@@ -24,11 +24,11 @@ build_flags =
| **USE_GFX_ROOT** | Use [lightweight](https://github.com/mrfaptastic/Adafruit_GFX_Lite) version of AdafuitGFX, without Adafruit BusIO extensions | You **must** install [Adafruit_GFX_Lite](https://github.com/mrfaptastic/Adafruit_GFX_Lite) library instead of original AdafruitGFX|
| **NO_GFX** | Build without AdafuitGFX API, only native methods supported based on manipulating DMA buffer. I.e. no methods of drawing circles/shapes, typing text or using fonts!!! This might save some resources for applications using it's own internal graphics buffer or working solely with per-pixel manipulation. | Use this if you rely on FastLED, Neomatrix or any other API. For example [Aurora](/examples/AuroraDemo/) effects can work fine w/o AdafruitGFX. |
| **NO_FAST_FUNCTIONS** | Do not build auxiliary speed-optimized functions. Those are used to speed-up operations like drawing straight lines or rectangles. Otherwise lines/shapes are drawn using drawPixel() method. The trade-off for speed is RAM/code-size, take it or leave it ;) | If you are not using AdafruitGFX than you probably do not need this either|
-|**NO_CIE1931**|Do not use LED brightness [compensation](https://ledshield.wordpress.com/2012/11/13/led-brightness-to-your-eye-gamma-correction-no/) described in [CIE 1931](https://en.wikipedia.org/wiki/CIE_1931_color_space). Normally library would adjust every pixel's RGB888 so that luminance (or brightness control) for the corresponding LED's would appear 'linear' to the human's eye. I.e. a white dot with rgb(128,128,128) would seem to be at 50% brightness between rgb(0,0,0) and rgb(255,255,255). Normally you would like to keep this enabled by default. Not only it makes brightness control "linear", it also makes colors more vivid, otherwise it looks brighter but 'bleached'.|You might want to turn it off in some special cases like:
- Using some other overlay lib for intermediate calculations that makes it's own compensation, like FastLED's [dimming functions](http://fastled.io/docs/3.1/group___dimming.html).
- running at low color depth's - it **might** (or might not) look better in shadows, darker gradients w/o compensation, try it
- you run for as bright output as possible, no matter what (make sure you have proper powering)
- you run for speed/save resources at all costs
|
-| **FORCE_COLOUR_DEPTH** |In some cases the library may reduce colour fidelity to increase the refresh rate (i.e. reduce visible flicker). This is most likely to occur with a large chain of panels. However, if you want to force pure 24bpp colour, at the expense of likely noticeable flicker, then set this defined. |Not required in 99% of cases.
+|**NO_CIE1931**|Do not use LED brightness [compensation](https://ledshield.wordpress.com/2012/11/13/led-brightness-to-your-eye-gamma-correction-no/) described in [CIE 1931](https://en.wikipedia.org/wiki/CIE_1931_color_space). Normally library would adjust every pixel's RGB888 so that luminance (or brightness control) for the corresponding LED's would appear 'linear' to the human's eye. I.e. a white dot with rgb(128,128,128) would seem to be at 50% brightness between rgb(0,0,0) and rgb(255,255,255). Normally you would like to keep this enabled by default. Not only it makes brightness control "linear", it also makes colours more vivid, otherwise it looks brighter but 'bleached'.|You might want to turn it off in some special cases like: - Using some other overlay lib for intermediate calculations that makes it's own compensation, like FastLED's [dimming functions](http://fastled.io/docs/3.1/group___dimming.html).
- running at low colour depth's - it **might** (or might not) look better in shadows, darker gradients w/o compensation, try it
- you run for as bright output as possible, no matter what (make sure you have proper powering)
- you run for speed/save resources at all costs
|
+| **FORCE_COLOR_DEPTH** |In some cases the library may reduce colour fidelity to increase the refresh rate (i.e. reduce visible flicker). This is most likely to occur with a large chain of panels. However, if you want to force pure 24bpp colour, at the expense of likely noticeable flicker, then set this defined. |Not required in 99% of cases.
## Build-time variables
| Flag | Description | Note |
| :------------ |---------------|-----|
-| **PIXEL_COLOR_DEPTH_BITS=8** | Color depth per color per pixel in range 2-8. More bit's - more natural color. But on the other hand every additional bit:- eats ~2.5 bits of DMA memory per pixel
- reduces matrix refresh rate in power of two due to nature of [BCM](http://www.batsocks.co.uk/readme/art_bcm_5.htm)
| For large chains of panels (i.e. 6 x 64x64 panels) you WILL need to reduce the colour depth, or likely run out of memory. Default is 8 bits per colour per pixel, i.e. TrueColor 24 bit RGB.
For higher resolutions, from 64x64 and above it is not possible to provide full 24 bits colour without significant flickering OR reducing dynamic range in shadows. In that case using 5-6 bits at high res make very small difference to the human’s eye actually. Refer to the [I2S memcalc](i2s_memcalc.md) for more details.
+| **PIXEL_COLOR_DEPTH_BITS=8** | Colour depth per pixel in range 2-8. More bit's - more natural colour. But on the other hand every additional bit:- eats ~2.5 bits of DMA memory per pixel
- reduces matrix refresh rate in power of two due to nature of [BCM](http://www.batsocks.co.uk/readme/art_bcm_5.htm)
| For large chains of panels (i.e. 6 x 64x64 panels) you WILL need to reduce the colour depth, or likely run out of memory. Default is 8 bits per colour per pixel, i.e. True colour 24 bit RGB.
For higher resolutions, from 64x64 and above it is not possible to provide full 24 bits colour without significant flickering OR reducing dynamic range in shadows. In that case using 5-6 bits at high res make very small difference to the human’s eye actually. Refer to the [I2S memcalc](i2s_memcalc.md) for more details.
--
cgit v1.3.1
From 572e310fc49f7f03cd94a031373490facd0d3a4a Mon Sep 17 00:00:00 2001
From: mrfaptastic <12006953+mrfaptastic@users.noreply.github.com>
Date: Mon, 30 Jan 2023 04:19:26 +0000
Subject: Update BuildOptions.md
---
doc/BuildOptions.md | 3 +++
1 file changed, 3 insertions(+)
(limited to 'doc')
diff --git a/doc/BuildOptions.md b/doc/BuildOptions.md
index 9069b83..b2fbf03 100644
--- a/doc/BuildOptions.md
+++ b/doc/BuildOptions.md
@@ -15,6 +15,9 @@ build_flags =
-DNO_GFX=1
(etc.....)
```
+Or if using Arduino: 'Tools' menu > 'Core Debug Level' > Select 'Debug'
+
+... and use the Serial output to see the debug information.
## Build flags
--
cgit v1.3.1
From fbce0fdcbce1d57ee6b45f94b2ae78a8e593cd1c Mon Sep 17 00:00:00 2001
From: mrfaptastic <12006953+mrfaptastic@users.noreply.github.com>
Date: Tue, 31 Jan 2023 21:14:52 +0000
Subject: Document SPIRAM_DMA_BUFFER compile option
Use SPIRAM/PSRAM for the HUB75 DMA buffer and not internal SRAM. ONLY SUPPORTED ON ESP32-S3 VARIANTS WITH OCTAL (not quad!) SPIRAM/PSRAM, as ony OCTAL PSRAM an provide the required data rate / bandwidth to drive the panels adequately.
---
doc/BuildOptions.md | 1 +
1 file changed, 1 insertion(+)
(limited to 'doc')
diff --git a/doc/BuildOptions.md b/doc/BuildOptions.md
index b2fbf03..d620d52 100644
--- a/doc/BuildOptions.md
+++ b/doc/BuildOptions.md
@@ -29,6 +29,7 @@ Or if using Arduino: 'Tools' menu > 'Core Debug Level' > Select 'Debug'
| **NO_FAST_FUNCTIONS** | Do not build auxiliary speed-optimized functions. Those are used to speed-up operations like drawing straight lines or rectangles. Otherwise lines/shapes are drawn using drawPixel() method. The trade-off for speed is RAM/code-size, take it or leave it ;) | If you are not using AdafruitGFX than you probably do not need this either|
|**NO_CIE1931**|Do not use LED brightness [compensation](https://ledshield.wordpress.com/2012/11/13/led-brightness-to-your-eye-gamma-correction-no/) described in [CIE 1931](https://en.wikipedia.org/wiki/CIE_1931_color_space). Normally library would adjust every pixel's RGB888 so that luminance (or brightness control) for the corresponding LED's would appear 'linear' to the human's eye. I.e. a white dot with rgb(128,128,128) would seem to be at 50% brightness between rgb(0,0,0) and rgb(255,255,255). Normally you would like to keep this enabled by default. Not only it makes brightness control "linear", it also makes colours more vivid, otherwise it looks brighter but 'bleached'.|You might want to turn it off in some special cases like: - Using some other overlay lib for intermediate calculations that makes it's own compensation, like FastLED's [dimming functions](http://fastled.io/docs/3.1/group___dimming.html).
- running at low colour depth's - it **might** (or might not) look better in shadows, darker gradients w/o compensation, try it
- you run for as bright output as possible, no matter what (make sure you have proper powering)
- you run for speed/save resources at all costs
|
| **FORCE_COLOR_DEPTH** |In some cases the library may reduce colour fidelity to increase the refresh rate (i.e. reduce visible flicker). This is most likely to occur with a large chain of panels. However, if you want to force pure 24bpp colour, at the expense of likely noticeable flicker, then set this defined. |Not required in 99% of cases.
+| **SPIRAM_DMA_BUFFER** |Use SPIRAM/PSRAM for the HUB75 DMA buffer and not internal SRAM. ONLY SUPPORTED ON ESP32-S3 VARIANTS WITH OCTAL (not quad!) SPIRAM/PSRAM, as ony OCTAL PSRAM an provide the required data rate / bandwidth to drive the panels adequately.|ONLY SUPPORTED ON ESP32-S3 VARIANTS WITH OCTAL (not quad) SPIRAM/PSRAM
## Build-time variables
--
cgit v1.3.1
From a0f9ab6830e5377bf0799f46356781807482e3fc Mon Sep 17 00:00:00 2001
From: mrfaptastic <12006953+mrfaptastic@users.noreply.github.com>
Date: Tue, 31 Jan 2023 21:29:32 +0000
Subject: Update BuildOptions.md
---
doc/BuildOptions.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'doc')
diff --git a/doc/BuildOptions.md b/doc/BuildOptions.md
index d620d52..aa31ab7 100644
--- a/doc/BuildOptions.md
+++ b/doc/BuildOptions.md
@@ -29,7 +29,7 @@ Or if using Arduino: 'Tools' menu > 'Core Debug Level' > Select 'Debug'
| **NO_FAST_FUNCTIONS** | Do not build auxiliary speed-optimized functions. Those are used to speed-up operations like drawing straight lines or rectangles. Otherwise lines/shapes are drawn using drawPixel() method. The trade-off for speed is RAM/code-size, take it or leave it ;) | If you are not using AdafruitGFX than you probably do not need this either|
|**NO_CIE1931**|Do not use LED brightness [compensation](https://ledshield.wordpress.com/2012/11/13/led-brightness-to-your-eye-gamma-correction-no/) described in [CIE 1931](https://en.wikipedia.org/wiki/CIE_1931_color_space). Normally library would adjust every pixel's RGB888 so that luminance (or brightness control) for the corresponding LED's would appear 'linear' to the human's eye. I.e. a white dot with rgb(128,128,128) would seem to be at 50% brightness between rgb(0,0,0) and rgb(255,255,255). Normally you would like to keep this enabled by default. Not only it makes brightness control "linear", it also makes colours more vivid, otherwise it looks brighter but 'bleached'.|You might want to turn it off in some special cases like: - Using some other overlay lib for intermediate calculations that makes it's own compensation, like FastLED's [dimming functions](http://fastled.io/docs/3.1/group___dimming.html).
- running at low colour depth's - it **might** (or might not) look better in shadows, darker gradients w/o compensation, try it
- you run for as bright output as possible, no matter what (make sure you have proper powering)
- you run for speed/save resources at all costs
|
| **FORCE_COLOR_DEPTH** |In some cases the library may reduce colour fidelity to increase the refresh rate (i.e. reduce visible flicker). This is most likely to occur with a large chain of panels. However, if you want to force pure 24bpp colour, at the expense of likely noticeable flicker, then set this defined. |Not required in 99% of cases.
-| **SPIRAM_DMA_BUFFER** |Use SPIRAM/PSRAM for the HUB75 DMA buffer and not internal SRAM. ONLY SUPPORTED ON ESP32-S3 VARIANTS WITH OCTAL (not quad!) SPIRAM/PSRAM, as ony OCTAL PSRAM an provide the required data rate / bandwidth to drive the panels adequately.|ONLY SUPPORTED ON ESP32-S3 VARIANTS WITH OCTAL (not quad) SPIRAM/PSRAM
+| **SPIRAM_FRAMEBUFFER** |Use SPIRAM/PSRAM for the HUB75 DMA buffer and not internal SRAM. ONLY SUPPORTED ON ESP32-S3 VARIANTS WITH OCTAL (not quad!) SPIRAM/PSRAM, as ony OCTAL PSRAM an provide the required data rate / bandwidth to drive the panels adequately.|ONLY SUPPORTED ON ESP32-S3 VARIANTS WITH OCTAL (not quad) SPIRAM/PSRAM
## Build-time variables
--
cgit v1.3.1
From 15763b12b115c71f4a8327dde16adb8f5cf461dd Mon Sep 17 00:00:00 2001
From: mrfaptastic <12006953+mrfaptastic@users.noreply.github.com>
Date: Wed, 1 Feb 2023 21:04:19 +0000
Subject: Update documentation on higher scan rate panels
Also breaks the VirtualMatrixPanel backward compatibility for 1/4 scan panels.
---
README.md | 115 +++++++++-------
doc/ScanRateGraphic.jpg | Bin 0 -> 113911 bytes
doc/ScanRateGraphic.odp | Bin 0 -> 35732 bytes
examples/Four_Scan_Panel/Four_Scan_Panel.ino | 153 +++++++++++++++++++++
examples/Four_Scan_Panel/README.md | 7 +
.../One_Eight_1_8_ScanPanel.ino | 151 --------------------
examples/One_Eight_1_8_ScanPanel/README.md | 7 -
src/ESP32-VirtualMatrixPanel-I2S-DMA.h | 32 +++--
8 files changed, 242 insertions(+), 223 deletions(-)
create mode 100644 doc/ScanRateGraphic.jpg
create mode 100644 doc/ScanRateGraphic.odp
create mode 100644 examples/Four_Scan_Panel/Four_Scan_Panel.ino
create mode 100644 examples/Four_Scan_Panel/README.md
delete mode 100644 examples/One_Eight_1_8_ScanPanel/One_Eight_1_8_ScanPanel.ino
delete mode 100644 examples/One_Eight_1_8_ScanPanel/README.md
(limited to 'doc')
diff --git a/README.md b/README.md
index 55568db..31ca561 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-# HUB75 RGB LED matrix library utilizing ESP32 DMA Engine
+# HUB75 RGB LED matrix panel library utilizing ESP32 DMA
__[BUILD OPTIONS](/doc/BuildOptions.md) | [EXAMPLES](/examples/README.md)__ | [](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-DMA/actions/workflows/pio_build.yml)
@@ -28,43 +28,57 @@ __[BUILD OPTIONS](/doc/BuildOptions.md) | [EXAMPLES](/examples/README.md)__ | [!
- [Thank you!](#thank-you)
## Introduction
-This ESP32 Arduino/IDF library for HUB75 / HUB75E connector type 64x32 RGB LED 1/16 Scan OR 64x64 RGB LED 1/32 Scan LED Matrix Panel, utilities the DMA functionality provided by the ESP32's 'LCD Mode'.
+* This is an ESP32 Arduino/IDF library for HUB75 / HUB75E RGB LED panels.
+* This library 'out of the box' (mostly) supports HUB75 panels where TWO rows/lines are updated in parallel... referred to as 'two scan' panels within this library's documentation.
+* 'Four scan' panels are also supported - but please refer to the Four Scan Panel example.
+* The library uses the DMA functionality provided by the ESP32's 'LCD Mode' for faster output.
### Features
-- **Low CPU overhead** - once initialized pixel data is pumped to the matrix inputs via DMA engine directly from memory
-- **Fast** - updating pixel data involves only bit-wise logic over DMA buffer memory, no pins manipulation or blocking IO
-- **Full screen BCM** - library utilizes [binary-code modulation](http://www.batsocks.co.uk/readme/art_bcm_5.htm) to render pixel color depth / brightness over the entire matrix
-- **Variable color depth** - up to TrueColor 24 bits output is possible depending on matrix size/refresh rate required
-- **CIE 1931** luminance [correction](https://ledshield.wordpress.com/2012/11/13/led-brightness-to-your-eye-gamma-correction-no/) (aka natural LED dimming)
-- **Adafruit GFX API** - library could be build with AdafruitGFX, simplified GFX or without GFX API at all
+- **Low CPU overhead** - Pixel data is sent directly with the use of hardware-backed DMA, no CPU involvement
+- **Fast** - Updating pixel data involves only bit-wise logic over DMA buffer memory, no pins manipulation or blocking IO
+- **Full screen BCM** - Library utilizes [binary-code modulation](http://www.batsocks.co.uk/readme/art_bcm_5.htm) to render pixel color depth / brightness over the entire matrix to give reasonable colour depth
+- **Variable color depth** - Up to TrueColor 24 bits output is possible depending on matrix size/refresh rate required
+- **CIE 1931** luminance [correction](https://ledshield.wordpress.com/2012/11/13/led-brightness-to-your-eye-gamma-correction-no/) (aka natural LED dimming) implemented
+- **Adafruit GFX API** - Library can be built with AdafruitGFX, simplified GFX or without a GFX API at all
+
+## ESP32 variants supported
+* Original ESP32 - That being the ESP-WROOM-32 module with ESP32‑D0WDQ6 chip from ~2017.
+* ESP32-S2; and
+* ESP32-S3
-If you wanna ask "*...OK, OK, than what's the price for those features?*" I'll tell you - "[memory](/doc/memcalc.md), you pay it all by precious MCU's internal memory (SRAM) for the DMA buffer".
+RISC-V ESP32's (like the C3) are not supported as they do not have the hardware 'LCD mode' required for this library.
-Please use the ['Memory Calculator'](/doc/memcalc.md) to see what is actually achievable with a typical ESP32.
-
+## Memory is required!
+"*What's the price for those features?*" - It's [memory](/doc/memcalc.md), you pay it all by precious MCU's internal memory (SRAM) for the DMA buffer".
-Note: Things are better for more recent ESP32 variants, refer [below](#memory-constraints) on how to use external SPIRAM/PSRAM for the DMA buffer which drives the HUB75 panels.
+A typical 64x32px panel at 24bpp colour uses about 20kB of internal memory.
+Please use the ['Memory Calculator'](/doc/memcalc.md) to see what is *typically* achievable with the typical ESP32. 
-## ESP32 Supported
-This library supports the:
-* Original ESP32 - That being the ESP-WROOM-32 module with ESP32‑D0WDQ6 chip from 2017. This MCU has 520kB of SRAM which is much more than all the recent 'reboots' of the ESP32 such as the S2, S3 etc.
-* ESP32-S2; and
-* ESP32-S3
+For the ESP32-S3 only, you can use SPIRAM/PSRAM to drive the HUB75 DMA buffer when using **Octal SPI-RAM** (i.e. ESP32 S3 N8R8 variant). However, due to bandwidth limitations, the maximum output frequency is limited to approx. 13Mhz, which will limit the real-world number of panels that can be chained without flicker.
+
+To enable PSRAM support on the ESP32-S3, refer to [the build options](/doc/BuildOptions.md) to enable.
-RISC-V ESP32's (like the C3) are not, and will never be supported as they do not have parallel DMA output required for this library.
+For all other ESP32 variants (like the most popular ‘original’ ESP32), [only *internal* SRAM can be used](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/issues/55), so you will be limited to the ~200KB or so of 'free' SRAM (because of the memory used for your sketch amongst other things) regardless of how many megabytes of SPIRAM/PSRAM you may have connected.
-## Panels Supported
-* 64x32 (width x height) pixel 1/16 Scan LED Matrix 'Indoor' Panel, such as this [typical RGB panel available for purchase](https://www.aliexpress.com/item/256-128mm-64-32-pixels-1-16-Scan-Indoor-3in1-SMD2121-RGB-full-color-P4-led/32810362851.html).
-* 64x64 pixel 1/32 Scan LED Matrix 'Indoor' Panel.
-* 32x16 pixel 1/4 Scan LED Matrix 'Indoor' Panel using an ingenious workaround as demonstrated in the 32x16_1_4_ScanPanel example.
-* 126x64 [SM5266P](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/issues/164) 1/32 Scan Panel
+
+## Suported panels
+### Parallel scan lines
+* 'Two scan' panels where **two** rows/lines are updated in parallel.
+ * 64x32 (width x height) 'Indoor' panels, such as this [typical RGB panel available for purchase](https://www.aliexpress.com/item/256-128mm-64-32-pixels-1-16-Scan-Indoor-3in1-SMD2121-RGB-full-color-P4-led/32810362851.html). Often also referred to as 1/16 'scan panel' as every 16th row is updated in parallel (hence why I refer to it as 'two scan')
+ * 64x64 pixel 1/32 Scan LED Matrix 'Indoor' Panel
+
+* 'Four scan' panels where **four** rows/lines are updated in parallel.
+ * 32x16 pixel 1/4 Scan LED Matrix 'Indoor' Panel using an ingenious workaround as demonstrated in the Four_Scan_Panel example.
+ * 126x64 [SM5266P](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/issues/164)
Ones interested in internals of such matrices could find [this article](https://www.sparkfun.com/news/2650) useful.
Due to the high-speed optimized nature of this library, only specific panels are supported. Please do not raise issues with respect to panels not supported on the list below.
-## Panel driver chips known to be working well
+
+
+### Driver chips known to be working well
* ICND2012
* [RUC7258](http://www.ruichips.com/en/products.html?cateid=17496)
@@ -72,28 +86,19 @@ Due to the high-speed optimized nature of this library, only specific panels are
* SM5266P
## Panels Not Supported
-* 1/8 Scan LED Matrix Panels are not supported.
* RUL5358 / SHIFTREG_ABC_BIN_DE based panels are not supported.
* ICN2053 / FM6353 based panels - Refer to [this library](https://github.com/LAutour/ESP32-HUB75-MatrixPanel-DMA-ICN2053), which is a fork of this library ( [discussion link](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-DMA/discussions/324)).
* Any other panel not listed above.
Please use an [alternative library](https://github.com/2dom/PxMatrix) if you bought one of these.
-## Cool uses of this library
-There are a number of great looking LED graphical display projects which leverage this library, these include:
-* [128x64 Morph Clock](https://github.com/bogd/esp32-morphing-clock)
-* [FFT Audio Visualisation](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/discussions/149)
-* [Clock, GIF Animator and Audio Visualiser](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/discussions/153)
-* [Aurora Audio Visualiser](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/discussions/188)
-* [Big Visualisation](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/discussions/155)
-* [Clockwise](https://jnthas.github.io/clockwise/)
-
# Getting Started
## 1. Library Installation
-* Dependency: You will need to install Adafruit_GFX from the "Library > Manage Libraries" menu.
-* Download and unzip this repository into your Arduino/libraries folder (or better still, use the Arduino 'add library from .zip' option.
-* Library also tested to work fine with PlatformIO, install into your PlatformIO projects' lib/ folder as appropriate. Or just add it into [platformio.ini](/doc/BuildOptions.md) [lib_depth](https://docs.platformio.org/en/latest/projectconf/section_env_library.html#lib-deps) section.
+* Dependancy: You will need to install Adafruit_GFX from the "Library > Manage Libraries" menu.
+* Install this library from the Arduino Library manager.
+
+Library also tested to work fine with PlatformIO, install into your PlatformIO projects' lib/ folder as appropriate. Or just add it into [platformio.ini](/doc/BuildOptions.md) [lib_depth](https://docs.platformio.org/en/latest/projectconf/section_env_library.html#lib-deps) section.
## 2. Wiring the ESP32/ESP32-S2/ESP32-S3 to an LED Matrix Panel
@@ -113,7 +118,7 @@ If you want to change the GPIO mapping at runtime, simply provide the wanted pin
#define B_PIN 19
#define C_PIN 5
#define D_PIN 17
-#define E_PIN -1 // required for 1/32 scan panels, like 64x64. Any available pin would do, i.e. IO32
+#define E_PIN -1 // required for 1/32 scan panels, like 64x64px. Any available pin would do, i.e. IO32
#define LAT_PIN 4
#define OE_PIN 15
#define CLK_PIN 16
@@ -136,25 +141,18 @@ Various people have created PCBs for which one can simply connect an ESP32 to a
Please contact or order these products from the respective authors.
+### Can I use with a larger panel (i.e. 64x64px square panel)?
+If you want to use with a 64x64 pixel panel (typically a HUB75*E* panel) you MUST configure a valid *E_PIN* to your ESP32 and connect it to the E pin of the HUB75 panel! Hence the 'E' in 'HUB75E'
+
+
## 3. Run a Test Sketch
Below is a bare minimum sketch to draw a single white dot in the top left. You must call begin() before you call ANY pixel-drawing (fonts, lines, colours etc.) function of the MatrixPanel_I2S_DMA class.
Once this is working, refer to the [PIO Test Patterns](/examples/PIO_TestPatterns) example. This sketch draws simple colors/lines/gradients over the entire matrix and it could help to troubleshoot various issues with ghosting, flickering, etc...
->Note: Requires the use of [PlatformIO](https://platformio.org/), which you should probably use if you aren't already.
-# More Information
-## Build-time options
-Although Arduino IDE does not [seem](https://github.com/arduino/Arduino/issues/421) to offer any way of specifying compile-time options for external libs there are other IDE's (like [PlatformIO](https://platformio.org/)/[Eclipse](https://www.eclipse.org/ide/)) that could use that. Check [Build Options](doc/BuildOptions.md) document for reference.
-
-## Memory constraints
-If you are going to use large/combined panels make sure to check for [memory constraints](/doc/i2s_memcalc.md).
-
-NOTE: You can use SPIRAM/PSRAM to drive the HUB75 DMA buffer only on the ESP32-S3 and with Octal SPI-RAM (i.e. ESP32 S3 N8R8 variant). However, due to bandwidth limitations, the maximum output frequency is limited to approx. 16Mhz, which will limit the real world number of panels that can be chained without flicker being obvious. This is enabled at compile time, refer to [the build options](/doc/BuildOptions.md) to enable.
-For all other ESP32 variants (like the most popular ‘original’ ESP32), [only *internal* SRAM can be used](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/issues/55), so you will be limited to the ~200KB or so of 'free' SRAM regardless of how many megabytes of SPIRAM/PSRAM you may have connected.
-
-## Can I use with a larger panel (i.e. 64x64px square panel)?
-If you want to use with a 64x64 pixel panel (typically a HUB75*E* panel) you MUST configure a valid *E_PIN* to your ESP32 and connect it to the E pin of the HUB75 panel! Hence the 'E' in 'HUB75E'
+Note: Requires the use of [PlatformIO](https://platformio.org/), which you should probably use if you aren't already.
+# Further information
## Can I chain panels?
Yes!
@@ -168,7 +166,7 @@ Resolutions beyond 128x64 are more likely to result in crashes due to [memory](/

- ## Panel Brightness
+## Adjusting Panel Brightness
By default you should not need to change / set the brightness value (which is 128 or 50%) as it should be sufficient for most purposes. Brightness can be changed by calling `setPanelBrightness(xx)` or `setBrightness8(xx)`.
@@ -185,7 +183,8 @@ Serial.begin(115200);
```

-
+## Build-time options
+Although Arduino IDE does not [seem](https://github.com/arduino/Arduino/issues/421) to offer any way of specifying compile-time options for external libs there are other IDE's (like [PlatformIO](https://platformio.org/)/[Eclipse](https://www.eclipse.org/ide/)) that could use that. Check [Build Options](doc/BuildOptions.md) document for reference.
## Latch blanking
If you are facing issues with image ghosting when pixels has clones with horizontal offset, than you try to change Latch blanking value. Latch blanking controls for how many clock pulses matrix output is disabled via EO signal before/after toggling LAT signal. It hides row bits transitioning and different panels may require longer times for proper operation. Default value is 1 clock before/after LAT row transition. This could be controlled with `MatrixPanel_I2S_DMA::setLatBlanking(uint8_t v)`. v could be between 1 to 4, default is 1, larger values won't give any benefit other than reducing brightness.
@@ -209,6 +208,16 @@ This project was inspired by:
* 'SmartMatrix': https://github.com/pixelmatix/SmartMatrix/tree/teensylc
* Sprite_TM's demo implementation here: https://www.esp32.com/viewtopic.php?f=17&t=3188
+
+## Cool uses of this library
+There are a number of great looking LED graphical display projects which leverage this library, these include:
+* [128x64 Morph Clock](https://github.com/bogd/esp32-morphing-clock)
+* [FFT Audio Visualisation](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/discussions/149)
+* [Clock, GIF Animator and Audio Visualiser](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/discussions/153)
+* [Aurora Audio Visualiser](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/discussions/188)
+* [Big Visualisation](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/discussions/155)
+* [Clockwise](https://jnthas.github.io/clockwise/)
+
# Thank you!
* [Brian Lough](https://www.tindie.com/stores/brianlough/) ([youtube link](https://www.youtube.com/c/brianlough)) for providing code contributions, hardware and suggestions
* [Vortigont](https://github.com/vortigont) for his game changing code contributions and performance optimisations
diff --git a/doc/ScanRateGraphic.jpg b/doc/ScanRateGraphic.jpg
new file mode 100644
index 0000000..a875316
Binary files /dev/null and b/doc/ScanRateGraphic.jpg differ
diff --git a/doc/ScanRateGraphic.odp b/doc/ScanRateGraphic.odp
new file mode 100644
index 0000000..84b98a1
Binary files /dev/null and b/doc/ScanRateGraphic.odp differ
diff --git a/examples/Four_Scan_Panel/Four_Scan_Panel.ino b/examples/Four_Scan_Panel/Four_Scan_Panel.ino
new file mode 100644
index 0000000..856d7e5
--- /dev/null
+++ b/examples/Four_Scan_Panel/Four_Scan_Panel.ino
@@ -0,0 +1,153 @@
+/*************************************************************************
+ * Description:
+ *
+ * The underlying implementation of the ESP32-HUB75-MatrixPanel-I2S-DMA only
+ * supports output to HALF scan panels - which means outputting
+ * two lines at the same time, 16 or 32 rows apart if a 32px or 64px high panel
+ * respectively.
+ * This cannot be changed at the DMA layer as it would require a messy and complex
+ * rebuild of the library's internals.
+ *
+ * However, it is possible to connect QUARTER (i.e. FOUR lines updated in parallel)
+ * scan panels to this same library and
+ * 'trick' the output to work correctly on these panels by way of adjusting the
+ * pixel co-ordinates that are 'sent' to the ESP32-HUB75-MatrixPanel-I2S-DMA
+ * library.
+ *
+ **************************************************************************/
+#include "ESP32-HUB75-MatrixPanel-I2S-DMA.h"
+
+/* Use the Virtual Display class to re-map co-ordinates such that they draw
+ * correctly on a 32x16 1/8 Scan panel (or chain of such panels).
+ */
+#include "ESP32-VirtualMatrixPanel-I2S-DMA.h"
+
+
+ // Panel configuration
+ #define PANEL_RES_X 64 // Number of pixels wide of each INDIVIDUAL panel module.
+ #define PANEL_RES_Y 32 // Number of pixels tall of each INDIVIDUAL panel module.
+
+
+ #define NUM_ROWS 1 // Number of rows of chained INDIVIDUAL PANELS
+ #define NUM_COLS 2 // Number of INDIVIDUAL PANELS per ROW
+
+ // ^^^ NOTE: DEFAULT EXAMPLE SETUP IS FOR A CHAIN OF TWO x 1/8 SCAN PANELS
+
+ // Change this to your needs, for details on VirtualPanel pls read the PDF!
+ #define SERPENT true
+ #define TOPDOWN false
+
+ // placeholder for the matrix object
+ MatrixPanel_I2S_DMA *dma_display = nullptr;
+
+ // placeholder for the virtual display object
+ VirtualMatrixPanel *FourScanPanel = nullptr;
+
+ /******************************************************************************
+ * Setup!
+ ******************************************************************************/
+ void setup()
+ {
+ delay(250);
+
+ Serial.begin(115200);
+ Serial.println(""); Serial.println(""); Serial.println("");
+ Serial.println("*****************************************************");
+ Serial.println("* 1/8 Scan Panel Demonstration *");
+ Serial.println("*****************************************************");
+
+/*
+ // 62x32 1/8 Scan Panels don't have a D and E pin!
+
+ HUB75_I2S_CFG::i2s_pins _pins = {
+ R1_PIN, G1_PIN, B1_PIN, R2_PIN, G2_PIN, B2_PIN,
+ A_PIN, B_PIN, C_PIN, D_PIN, E_PIN,
+ LAT_PIN, OE_PIN, CLK_PIN
+ };
+*/
+ HUB75_I2S_CFG mxconfig(
+ PANEL_RES_X*2, // DO NOT CHANGE THIS
+ PANEL_RES_Y/2, // DO NOT CHANGE THIS
+ NUM_ROWS*NUM_COLS // DO NOT CHANGE THIS
+ //,_pins // Uncomment to enable custom pins
+ );
+
+ mxconfig.clkphase = false; // Change this if you see pixels showing up shifted wrongly by one column the left or right.
+
+ //mxconfig.driver = HUB75_I2S_CFG::FM6126A; // in case that we use panels based on FM6126A chip, we can set it here before creating MatrixPanel_I2S_DMA object
+
+ // OK, now we can create our matrix object
+ dma_display = new MatrixPanel_I2S_DMA(mxconfig);
+
+ // let's adjust default brightness to about 75%
+ dma_display->setBrightness8(96); // range is 0-255, 0 - 0%, 255 - 100%
+
+ // Allocate memory and start DMA display
+ if( not dma_display->begin() )
+ Serial.println("****** !KABOOM! I2S memory allocation failed ***********");
+
+
+ dma_display->clearScreen();
+ delay(500);
+
+ // create FourScanPanellay object based on our newly created dma_display object
+ FourScanPanel = new VirtualMatrixPanel((*dma_display), NUM_ROWS, NUM_COLS, PANEL_RES_X, PANEL_RES_Y, SERPENT, TOPDOWN);
+
+ // THE IMPORTANT BIT BELOW!
+ FourScanPanel->setPhysicalPanelScanRate(FOUR_SCAN_32PX_HIGH);
+ }
+
+
+ void loop() {
+
+ // What the panel sees from the DMA engine!
+ for (int i=PANEL_RES_X*2+10; i< PANEL_RES_X*(NUM_ROWS*NUM_COLS)*2; i++)
+ {
+ dma_display->drawLine(i, 0, i, 7, dma_display->color565(255, 0, 0)); // red
+ delay(10);
+ }
+
+ dma_display->clearScreen();
+ delay(1000);
+/*
+ // Try again using the pixel / dma memory remapper
+ for (int i=PANEL_RES_X+5; i< (PANEL_RES_X*2)-1; i++)
+ {
+ FourScanPanel->drawLine(i, 0, i, 7, dma_display->color565(0, 0, 255)); // blue
+ delay(10);
+ }
+*/
+
+ // Try again using the pixel / dma memory remapper
+ int offset = PANEL_RES_X*((NUM_ROWS*NUM_COLS)-1);
+ for (int i=0; i< PANEL_RES_X; i++)
+ {
+ FourScanPanel->drawLine(i+offset, 0, i+offset, 7, dma_display->color565(0, 0, 255)); // blue
+ FourScanPanel->drawLine(i+offset, 8, i+offset, 15, dma_display->color565(0, 128,0)); // g
+ FourScanPanel->drawLine(i+offset, 16, i+offset, 23, dma_display->color565(128, 0,0)); // red
+ FourScanPanel->drawLine(i+offset, 24, i+offset, 31, dma_display->color565(0, 128, 128)); // blue
+ delay(10);
+ }
+
+ delay(1000);
+
+
+ // Print on each chained panel 1/8 module!
+ // This only really works for a single horizontal chain
+ for (int i = 0; i < NUM_ROWS*NUM_COLS; i++)
+ {
+ FourScanPanel->setTextColor(FourScanPanel->color565(255, 255, 255));
+ FourScanPanel->setCursor(i*PANEL_RES_X+7, FourScanPanel->height()/3);
+
+ // Red text inside red rect (2 pix in from edge)
+ FourScanPanel->print("Panel " + String(i+1));
+ FourScanPanel->drawRect(1,1, FourScanPanel->width()-2, FourScanPanel->height()-2, FourScanPanel->color565(255,0,0));
+
+ // White line from top left to bottom right
+ FourScanPanel->drawLine(0,0, FourScanPanel->width()-1, FourScanPanel->height()-1, FourScanPanel->color565(255,255,255));
+ }
+
+ delay(2000);
+ dma_display->clearScreen();
+
+ } // end loop
diff --git a/examples/Four_Scan_Panel/README.md b/examples/Four_Scan_Panel/README.md
new file mode 100644
index 0000000..2fd55b9
--- /dev/null
+++ b/examples/Four_Scan_Panel/README.md
@@ -0,0 +1,7 @@
+# Using this library with 32x16 1/8 Scan Panels
+
+## Problem
+ESP32-HUB75-MatrixPanel-I2S-DMA library will not display output correctly with 1/8 scan panels such [as this](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/issues/154) by default.
+
+## Solution
+It is possible to connect 1/8 scan panels to this library and 'trick' the output to work correctly on these panels by way of adjusting the pixel co-ordinates that are 'sent' to the underlying ESP32-HUB75-MatrixPanel-I2S-DMA library (in this example, it is the 'dmaOutput' class).
diff --git a/examples/One_Eight_1_8_ScanPanel/One_Eight_1_8_ScanPanel.ino b/examples/One_Eight_1_8_ScanPanel/One_Eight_1_8_ScanPanel.ino
deleted file mode 100644
index d44bb76..0000000
--- a/examples/One_Eight_1_8_ScanPanel/One_Eight_1_8_ScanPanel.ino
+++ /dev/null
@@ -1,151 +0,0 @@
-/*************************************************************************
- * Description:
- *
- * The underlying implementation of the ESP32-HUB75-MatrixPanel-I2S-DMA only
- * supports output to 1/16 or 1/32 scan panels - which means outputting
- * two lines at the same time, 16 or 32 rows apart. This cannot be changed
- * at the DMA layer as it would require a messy and complex rebuild of the
- * library's DMA internals.
- *
- * However, it is possible to connect 1/8 scan panels to this same library and
- * 'trick' the output to work correctly on these panels by way of adjusting the
- * pixel co-ordinates that are 'sent' to the ESP32-HUB75-MatrixPanel-I2S-DMA
- * library.
- *
- **************************************************************************/
-#include "ESP32-HUB75-MatrixPanel-I2S-DMA.h"
-
-/* Use the Virtual Display class to re-map co-ordinates such that they draw
- * correctly on a 32x16 1/8 Scan panel (or chain of such panels).
- */
-#include "ESP32-VirtualMatrixPanel-I2S-DMA.h"
-
-
- // Panel configuration
- #define PANEL_RES_X 64 // Number of pixels wide of each INDIVIDUAL panel module.
- #define PANEL_RES_Y 32 // Number of pixels tall of each INDIVIDUAL panel module.
-
-
- #define NUM_ROWS 1 // Number of rows of chained INDIVIDUAL PANELS
- #define NUM_COLS 2 // Number of INDIVIDUAL PANELS per ROW
-
- // ^^^ NOTE: DEFAULT EXAMPLE SETUP IS FOR A CHAIN OF TWO x 1/8 SCAN PANELS
-
- // Change this to your needs, for details on VirtualPanel pls read the PDF!
- #define SERPENT true
- #define TOPDOWN false
-
- // placeholder for the matrix object
- MatrixPanel_I2S_DMA *dma_display = nullptr;
-
- // placeholder for the virtual display object
- VirtualMatrixPanel *OneEightMatrixDisplay = nullptr;
-
- /******************************************************************************
- * Setup!
- ******************************************************************************/
- void setup()
- {
- delay(250);
-
- Serial.begin(115200);
- Serial.println(""); Serial.println(""); Serial.println("");
- Serial.println("*****************************************************");
- Serial.println("* 1/8 Scan Panel Demonstration *");
- Serial.println("*****************************************************");
-
-/*
- // 62x32 1/8 Scan Panels don't have a D and E pin!
-
- HUB75_I2S_CFG::i2s_pins _pins = {
- R1_PIN, G1_PIN, B1_PIN, R2_PIN, G2_PIN, B2_PIN,
- A_PIN, B_PIN, C_PIN, D_PIN, E_PIN,
- LAT_PIN, OE_PIN, CLK_PIN
- };
-*/
- HUB75_I2S_CFG mxconfig(
- PANEL_RES_X*2, // DO NOT CHANGE THIS
- PANEL_RES_Y/2, // DO NOT CHANGE THIS
- NUM_ROWS*NUM_COLS // DO NOT CHANGE THIS
- //,_pins // Uncomment to enable custom pins
- );
-
- mxconfig.clkphase = false; // Change this if you see pixels showing up shifted wrongly by one column the left or right.
-
- //mxconfig.driver = HUB75_I2S_CFG::FM6126A; // in case that we use panels based on FM6126A chip, we can set it here before creating MatrixPanel_I2S_DMA object
-
- // OK, now we can create our matrix object
- dma_display = new MatrixPanel_I2S_DMA(mxconfig);
-
- // let's adjust default brightness to about 75%
- dma_display->setBrightness8(96); // range is 0-255, 0 - 0%, 255 - 100%
-
- // Allocate memory and start DMA display
- if( not dma_display->begin() )
- Serial.println("****** !KABOOM! I2S memory allocation failed ***********");
-
-
- dma_display->clearScreen();
- delay(500);
-
- // create OneEightMatrixDisplaylay object based on our newly created dma_display object
- OneEightMatrixDisplay = new VirtualMatrixPanel((*dma_display), NUM_ROWS, NUM_COLS, PANEL_RES_X, PANEL_RES_Y, SERPENT, TOPDOWN);
-
- // THE IMPORTANT BIT BELOW!
- OneEightMatrixDisplay->setPhysicalPanelScanRate(ONE_EIGHT_32);
- }
-
-
- void loop() {
-
- // What the panel sees from the DMA engine!
- for (int i=PANEL_RES_X*2+10; i< PANEL_RES_X*(NUM_ROWS*NUM_COLS)*2; i++)
- {
- dma_display->drawLine(i, 0, i, 7, dma_display->color565(255, 0, 0)); // red
- delay(10);
- }
-
- dma_display->clearScreen();
- delay(1000);
-/*
- // Try again using the pixel / dma memory remapper
- for (int i=PANEL_RES_X+5; i< (PANEL_RES_X*2)-1; i++)
- {
- OneEightMatrixDisplay->drawLine(i, 0, i, 7, dma_display->color565(0, 0, 255)); // blue
- delay(10);
- }
-*/
-
- // Try again using the pixel / dma memory remapper
- int offset = PANEL_RES_X*((NUM_ROWS*NUM_COLS)-1);
- for (int i=0; i< PANEL_RES_X; i++)
- {
- OneEightMatrixDisplay->drawLine(i+offset, 0, i+offset, 7, dma_display->color565(0, 0, 255)); // blue
- OneEightMatrixDisplay->drawLine(i+offset, 8, i+offset, 15, dma_display->color565(0, 128,0)); // g
- OneEightMatrixDisplay->drawLine(i+offset, 16, i+offset, 23, dma_display->color565(128, 0,0)); // red
- OneEightMatrixDisplay->drawLine(i+offset, 24, i+offset, 31, dma_display->color565(0, 128, 128)); // blue
- delay(10);
- }
-
- delay(1000);
-
-
- // Print on each chained panel 1/8 module!
- // This only really works for a single horizontal chain
- for (int i = 0; i < NUM_ROWS*NUM_COLS; i++)
- {
- OneEightMatrixDisplay->setTextColor(OneEightMatrixDisplay->color565(255, 255, 255));
- OneEightMatrixDisplay->setCursor(i*PANEL_RES_X+7, OneEightMatrixDisplay->height()/3);
-
- // Red text inside red rect (2 pix in from edge)
- OneEightMatrixDisplay->print("Panel " + String(i+1));
- OneEightMatrixDisplay->drawRect(1,1, OneEightMatrixDisplay->width()-2, OneEightMatrixDisplay->height()-2, OneEightMatrixDisplay->color565(255,0,0));
-
- // White line from top left to bottom right
- OneEightMatrixDisplay->drawLine(0,0, OneEightMatrixDisplay->width()-1, OneEightMatrixDisplay->height()-1, OneEightMatrixDisplay->color565(255,255,255));
- }
-
- delay(2000);
- dma_display->clearScreen();
-
- } // end loop
diff --git a/examples/One_Eight_1_8_ScanPanel/README.md b/examples/One_Eight_1_8_ScanPanel/README.md
deleted file mode 100644
index 2fd55b9..0000000
--- a/examples/One_Eight_1_8_ScanPanel/README.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Using this library with 32x16 1/8 Scan Panels
-
-## Problem
-ESP32-HUB75-MatrixPanel-I2S-DMA library will not display output correctly with 1/8 scan panels such [as this](https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/issues/154) by default.
-
-## Solution
-It is possible to connect 1/8 scan panels to this library and 'trick' the output to work correctly on these panels by way of adjusting the pixel co-ordinates that are 'sent' to the underlying ESP32-HUB75-MatrixPanel-I2S-DMA library (in this example, it is the 'dmaOutput' class).
diff --git a/src/ESP32-VirtualMatrixPanel-I2S-DMA.h b/src/ESP32-VirtualMatrixPanel-I2S-DMA.h
index b2aba42..c79c376 100644
--- a/src/ESP32-VirtualMatrixPanel-I2S-DMA.h
+++ b/src/ESP32-VirtualMatrixPanel-I2S-DMA.h
@@ -9,9 +9,17 @@
grid.
However, the function of this class has expanded now to also manage
- the output for 1/16 scan panels, as the core DMA library is designed
- ONLY FOR 1/16 scan matrix panels.
-
+ the output for
+
+ 1) HALF scan panels = Two rows updated in parallel.
+ * 64px high panel = (incorrectly) referred to as 1/32 scan
+ * 32px high panel = (incorrectly) referred to as 1/16 scan
+ * 16px high panel = (incorrectly) referred to as 1/8 scan
+
+ 2) FOUR scan panels = Four rows updated in parallel
+ * 32px high panel = (incorrectly) referred to as 1/8 scan
+ * 16px high panel = (incorrectly) referred to as 1/4 scan
+
YouTube: https://www.youtube.com/brianlough
Tindie: https://www.tindie.com/stores/brianlough/
Twitter: https://twitter.com/witnessmenow
@@ -36,9 +44,9 @@ struct VirtualCoords
enum PANEL_SCAN_RATE
{
- NORMAL_ONE_SIXTEEN,
- ONE_EIGHT_32,
- ONE_EIGHT_16
+ NORMAL_TWO_SCAN, NORMAL_ONE_SIXTEEN, // treated as the same
+ FOUR_SCAN_32PX_HIGH,
+ FOUR_SCAN_16PX_HIGH
};
#ifdef USE_GFX_ROOT
@@ -129,7 +137,7 @@ protected:
bool _chain_top_down = false; // is the ESP at the top or bottom of the matrix of devices?
bool _rotate = false;
- PANEL_SCAN_RATE _panelScanRate = NORMAL_ONE_SIXTEEN;
+ PANEL_SCAN_RATE _panelScanRate = NORMAL_TWO_SCAN;
}; // end Class header
@@ -198,18 +206,18 @@ inline VirtualCoords VirtualMatrixPanel::getCoords(int16_t &x, int16_t &y)
coords.y = (panelResY - 1) - coords.y;
}
- /* START: Pixel remapping AGAIN to convert 1/16 SCAN output that the
+ /* START: Pixel remapping AGAIN to convert 1/2 SCAN output that the
* the underlying hardware library is designed for (because
- * there's only 2 x RGB pins... and convert this to 1/8 or something
+ * there's only 2 x RGB pins... and convert this to 1/4 or something
*/
- if (_panelScanRate == ONE_EIGHT_32)
+ if (_panelScanRate == FOUR_SCAN_32PX_HIGH)
{
/* Convert Real World 'VirtualMatrixPanel' co-ordinates (i.e. Real World pixel you're looking at
on the panel or chain of panels, per the chaining configuration) to a 1/8 panels
double 'stretched' and 'squished' coordinates which is what needs to be sent from the
DMA buffer.
- Note: Look at the One_Eight_1_8_ScanPanel code and you'll see that the DMA buffer is setup
+ Note: Look at the FourScanPanel example code and you'll see that the DMA buffer is setup
as if the panel is 2 * W and 0.5 * H !
*/
@@ -238,7 +246,7 @@ inline VirtualCoords VirtualMatrixPanel::getCoords(int16_t &x, int16_t &y)
Serial.print("to ("); Serial.print(coords.x, DEC); Serial.print(","); Serial.print(coords.y, DEC); Serial.println(") ");
*/
}
- else if (_panelScanRate == ONE_EIGHT_16)
+ else if (_panelScanRate == FOUR_SCAN_16PX_HIGH)
{
if ((y & 8) == 0)
{
--
cgit v1.3.1