SmartMatrix without HW drive

#1

Hi Louis.
I am trying to implement FastLED_Functions example for an ESP32 on a homemade RGB-matrix 32x16.
The matrix is built out of WS2812 strips, that are driven by an Arduino accepting Glediator protocol.

So I am using the SmartMatrix3 for creating the matrix in RAM and my own ShowAsGlediator() that sends the pixels on Serial1 with baudrate 1000000.

The problem is, that as soon as I try to send the pixels with Serial1.write() the ESP32 reboots. So I suppose there is a collision with the SmartMatrix hardware (pins or DMA).
I am trying to use pins GPIO13, GPIO14 or GPIO33 for the Serial1 which I believed were available after studying the MatrixHardware_ESP32_V0.h

Is there a way to “disable” or remove the SmartMatrix hardware, so I do not crash with it?

I appreciate the time you are spending on answering all these questions and I hope you will find time for answering mine.

By the way - are you planning to write matrix rotation by degree-units (not only 90, 180, 270) ?

Thank you.

#2

Where in RAM are you reading the pixels? From the Background Layer, or from what’s generated during refresh?

Why are you using SmartMatrix Library vs some other library, maybe just FastLED? Maybe trying FastLED::NeoMatrix?

Is there a way to “disable” or remove the SmartMatrix hardware, so I do not crash with it?

If you don’t need the matrix refreshing to be run, maybe just don’t call matrix.begin().

By the way - are you planning to write matrix rotation by degree-units (not only 90, 180, 270) ?

No, the rotation in multiples of 90 degrees is basically “free” in CPU cycles, arbitrary rotation would be very expensive in CPU and probably wouldn’t look very good.

#3

Hi Louis, thank you so very much for answering.
These are lines of code I am using:

rgb24 *buffer = backgroundLayer.backBuffer();
static const int TX_BUF_SIZE = 1536;  // needed 512 * 3  (NUM_BYTES)

uint8_t *leds1_buffer;

leds1_buffer = (uint8_t*) buffer;   // remaping leds1 so that it is byte addresable
// UART init
const uart_config_t uart_config = {
    .baud_rate = 1000000,
    .data_bits = UART_DATA_8_BITS,
    .parity = UART_PARITY_DISABLE,
    .stop_bits = UART_STOP_BITS_1,
    .flow_ctrl = UART_HW_FLOWCTRL_DISABLE
};
uart_param_config(UART_NUM_1, &uart_config);
uart_set_pin(UART_NUM_1, TXD1_PIN, RXD1_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE);
// uart_driver_install(uart_port_t uart_num, int rx_buffer_size, int tx_buffer_size, int queue_size, QueueHandle_t* uart_queue, int intr_alloc_flags);
uart_driver_install(UART_NUM_1, RX_BUF_SIZE * 2, TX_BUF_SIZE * 2, 0, NULL, 0);

// writing to UART buffer
long txBytes = uart_write_bytes(UART_NUM_1, (const char *) leds1_buffer, TX_BUF_SIZE);

So the answer I guess is from the Background Layer.

I am using SmartMatrix Library only because I want to run some existing fancy examples, that I find on the net without modifying the code too much. Also I like the layer technik that is used in SmartMatrix and the text scrolling.

I am still investigating from where the crashes come that initiate the reboot.

For the arbitrary rotation:
I am trying to achieve something like text scroll rotation like the one implemented in Glediator application. My hope is that by using the simplified sin cos math in FastLED, I will be able to rotate the 32x16 matrix fast enough to make it with 30 frames per sec. I was asking if rotation was in your pipeline, because I hate the situation, when I am half way in something, that is solved already :slight_smile:

#4

I recommend checking out @marcmerlin’s demos ported to his FastLED::NeoMatrix driver, which I think is more what you need without the complexity of SmartMatrix Library:

#5

Hi again Louis.
After taking up the SmartMatrix again after a while finally I got the sketch FeatureDemo working to some extent. I started from scratch and used the Arduino genuine Serial1.write() technik instead of ESP32 freertos, so the crushes are gone.
My problem with replacing your HW-drivers with Glediator serial protocol is, that I do not have good knowledge of the SmartMatrix structure, which was partly documented in version 2, but a lot of things happened after that. I think, that even for other people to be able to write successful implementations of their ideas, it is important to understand the basic ideas of your building elements. Remember, that the useful documentation is more important for wide spreading the use of the library, than it’s smart solutions. Is there a more recent documentation of SmartMatrix on the web?
I understand, that you have backgroudLayer, scrollingLayer and indexedLayer. They are copying their data to their corresponding refreshLayers. This is happening with swapBuffers() right?
But looking at the sketch FeatureDemo, there are things going on with no swapBuffers call and still the LED-matrix is refreshed. Is it the mysterious callBack mechanics in the hidden underground?

So I tried:
rgb24 refreshRow[kMatrixWidth];
for (int y = 0; y < kMatrixHeight; y++) {
memset(refreshRow, 0, kMatrixWidth*3);
backgroundLayer.fillRefreshRow(y, refreshRow);
// indexedLayer.fillRefreshRow(y, refreshRow);
scrollingLayer.fillRefreshRow(y, refreshRow);
}

But I had to comment out the indexedLayer line, since it did not work right. How does SmartMatrix fill the HW with the content of all Layers? Is the order of filling from these three Layers correct with regards to the “foreground”/background thinking?

What is the actual purpose of the indexedLayer?

I have some more thoughts.
On my LED-matrix (homemade from Chinese strips WS2812B) there is not much contrast of scrolling text, so I can see it well on the background. Will you consider to create a black “border” around the text?

Also I have seen the discussion here about the ArtNet. Since I am using Jinx, I came to the physical limits of Glediator protocol (number of pixels vs. refreshrate), so I had to try something faster. My findings were, that WiFi in a usual city flat will very soon drop packets, which is critical because you have no feedback that all packets were received. So you end up using wired Ethernet, which is not very useful on clothes on stage. Also, Arduinos and even ESP32 are too slow to reliably handle the huge and continuous stream of data, so I implemented the ArtNet with Raspberry Pi4 instead, which works perfectly for me. Not only it has 4 extra UARTS for my Glediator protocol, but I don’t have to worry about memory limits and I have plenty of performance for tricks like arbitrary angle rotation etc.

Another thing is the color-depth. Why are you so keen on the “at least 24bit” color, when so much of the precision is lost in the color-correction? Do I understand, that color-correction is gamma correction, right?
I understand, that 24 bits is kind of more comfortable to handle, than 16 bits, but if you have small memory, it is luxury, and you can hardly see the difference with the naked eye.

I hope you don’t take my words as criticism. I admire your work and enthusiasm and yes, I am a little bit frustrated with reading a lot of code, that is way too sophisticated for me just to try to understand the intension of it.