I am new to coding on a raspberry pi (but not to using python). I have two different scripts which use the python library for the rgbmatrix5x5 connected to a pi zero w.
My two scripts are accessing different LEDs on the matrix, but it looks like the show() resets all LEDs before displaying a new signal. Is it possible for these two scripts to run at the same time and not reset the states already on the matrix?
I have the top three rows setup to make a simple binary clock, and I want the bottom two rows to display lights for a different signal. I tested changing the clear on exit function, but this only has an effect when the script is closed. Is there a different show function I can use which will not reset the state of all LEDs?
So when you write a “screen” to the board it overwrites what is already in the 5x5’s memory. The library isn’t set up to only change the pixels you’ve specified, because that would require it to keep track of what you’ve changed since last time and then only write those LEDs to the 5x5 board in multiple write transactions. In short, both of your programs are using different buffers to hold the LED data, so each one isn’t aware of what the other is doing, and they just overwrite each other when talking to the 5x5 board.
It might be easier to try merging the programs into one, and just having a single write function to handle data for both of them.
Thanks a lot for the reply. Does this also mean there is no way to extract the current state of the matrix memory before sending the set pixel request, or to send a message to only adjust a single part of the memory state? I though perhaps it would be possible because of the clear on exit functionality leaves the lights switched on (but indeed, no further updates are then made to the matrix).
I see that the i2c class has read and write functions. Would it be possible to use self.i2c.read_i2c_block_data in the matrix class to read the current state of the matrix, before updating the buffer and writing it back?
Does this also mean there is no way to extract the current state of the matrix memory before sending the set pixel request
As far as I understand it each instance of the 5x5 module will only track what it has sent to the 5x5; it won’t know which pixels have been changed in the other program’s instance.
or to send a message to only adjust a single part of the memory state?
This is technically possible but isn’t written into the library, which seems to push a full display of data at a time. You’d need to write that functionality in yourself.
Would it be possible to use self.i2c.read_i2c_block_data in the matrix class to read the current state of the matrix, before updating the buffer and writing it back?
Again, technically should be possible yes, but you’d need to write that functionality in yourself.
Thanks again for the feedback. I have been looking into extending the existing class, but I seem to be running into a problem. I have made a new class which inherits from the existing one, and I have added a new function which should read the data which was sent to the matrix (5x5matrixideas/MatrixUpdate.py at main · ianc89/5x5matrixideas · GitHub)
However, I seem to be getting back zeros. I implemented it into my clock function (also in the repository) and check the data being sent, and then use the read function to see if it returns this. However, it seems to return zeroes. I wondered if it was tied to the frame implementation, but as far as I can tell, the class only ever uses frame 0 by default. Would you have any input or suggestions?
Err, it has been a while since I played with this library, so I’m afraid I honestly don’t know. Rather than go via an instance of RGBMatrix5x5 it might be easier to write some Python to directly read the registers
Just to return to the topic. I did investigate writing my own driver but I had some difficulties in getting the code to interface correctly. However I investigated the adafruit drivers which are available for the same chip with different setups. I have ended up adapting their class and for now using different frames (for which the chip can store 8 independently) for different scripts, and then using another script to automate switching between them on a loop.
I have not yet tested whether I could write to different LED on the same frame with different code now, but it may be possible because this class now allows individual LEDs to be turned on or off, rather than writing a whole block of data at once.