@danield , since the above repos were mainly focused on @Dave 's 16x32 panels they do contain some half baked things in connection with 32x32, but I've tweaked them a bit, so that they definetly do support 32x32 panels.
See video there:
You can download it from
Have a look in the .h file for the propper pinout.
Happy to help.
That was quick!!!
I have built this: LED Message Board, but have removed the Arduweeny and wish to replace it with the Spark Core. Would the code in this thread work to print to these displays? (Sure 0832 8x32 monochrome LED matrix[x3])
@Catfang, the matrix display you are using is not compatible with the library. There are HT1632C Arduino libraries that could be ported for the Core. (eg. this one). Let us know if you need help with the porting. 
Looks like Iām going to need help. Iāll start a new thread though since it looks like itās only marginally related to this one.
Hi Paul (@peekay123), I finally got myself a pocket DSO, just to have it with me whenever I want to do some testing 
And so I did some timing tests for the three modes of our ācolaborate libā.
And these are the results
Normal Mode
)FASTER Mode
FASTEST Mode
FASTEST Mode with unrolled pixel loop
Iāve done some asm testing, but havenāt come up with any running code yet.
@ScruffR, excellent JOB!! Now I have to rewire my board to match your wiring. Also, the ISR timing table will need adjusting to the new timing. Keep me posted on the ASM
Thanks, I will
The only sad thing in this, that my port write solution will not work on the Photon, since there are no six consecutive bits/pins to use for this anymore.
@ScruffR, yup thatās a bummer but a necessary evil I guess
Hey all - Iām trying to finish up some cool matrix demos but I could use some help on my code. Thanks to prior work done by @peekay123 and @Dave I was able to set up some code that works really nicely.
Things are working great and now Iād like to take some next steps. First up - Iād like to slow down the speed at which my text scrolls. Does anyone have any tips on what I can do/add/change to make that happen?
My code is below. And a heads-up I have definite reasons for wanting to keep spark.function() in there for integration purposes wink
This might sound dumb, but why not just put some modest delay() at the end of your loop, or wrap your
--textX
Fixed!long lastTime = 0;
int softDelay = 30; // e.g
...
void loop()
{
...
if (millis() - lastTime > softDelay)
{
if((--textX) < textMin) textX = matrix.width();
lastTime = millis();
}
...
}
Thanks @ScruffR!
Just to confirm, I should edit the 30 in the code you provided in order to change the scrolling speed? I am still learning on the coding side (mainly do biz and marketing) 
Exactly.
Maybe you do some experimenting with the desired value via your Spark.function.
If you send in a number literal, just set softDelay = command.toInt();
Cool - thanks @ScruffR!!
Hi ScruffR,
Iām not sure if this should be in this thread or in a new one. Please feel free to move it if you feel it is the right thing to do.
I have 2 16 x 32 RGB LED matrix panels and I wondered what I would have to do to the code to chain in the second panel? I can see I would have to change the code somehow to tell the core that the panels are one over another (32x32) or end on end (16 x 64)?
Is that an easy thing to do or should I just stick to a 16 x 32
Thanks,
Hi @Julian, this thread is perfect for this question.
Iām not quite sure which version of the library youāre using, but in the one Iāve used (see https://github.com/ScruffR/RGB_Matrix_Panel_FAST) you just need to #define numPanles 2 in RGBmatrixPanel.h to have two panels side by side (16x64).
In my demo I used two 32x32 panels as (64x32), so numPanels is already defined 2 on my repo.
I must admit, I have not thought of stacking the panles top to bottom, but this would definetly require some library tweaking.
As I recall @Dave had his 16x32 panels stacked that way but bottom to bottom having the lower one flipped upside down. No idea why, but there must have been a good reason for it
An alternative approach would be to treat the two 16x32 as one 32x32 by cleverly using the D address bit to switch between the top and the bottom panel - I havenāt thought that through, but maybe @Dave or @peekay123 can jump to my rescue here
On the other hand you can just be lazy and hack your way around this and use the side by side capability of the lib as is and only remember that your program needs to draw the bottom half not at Y coordingates 16ā¦31 but still 0ā¦15 and just add 32 to the X coordinat. Hacky but a limited workaround, if you need to get on with you project.
@ScruffR, the difference between the 16x32 and the 32x32 panels is the use of the extra āDā row select line on the larger panel. This is a hardware select line and canāt be connected between two 16x32 panels to give a 32x32 panel. The library would have to be modified to treat two daisy chained 16x32 panels as stacked panels as yo u suggested though I have not thought through all the changes necessary. To be honest, the cost of a 32x32 panel dosenāt justify all the work in my own mind 
@ScruffR, @peekay123, Thank you for your responses. I will have a go at a 16 x 64 this evening!
I appreciate your comments on the cost v effort on the 32 x 32 and you are quite right. In my case I have 2 x (16 x 32) and just wondered if, with a simple change, the code could be adapted. No problem, a 16 x 64 would be a fine alternative.
Thanks again
@peekay123, I agree, I wouldnāt take the hassle either.
But since some of the older 32x32 panels came as two 16x32s on one carrier but with two ribbon connectors and still ABCD addressing, Iād guess they just had some kind of latching logic switching ABC to either of the panels depending on the state of D.
But since @Julian, seems to be happy with the 16x64, this is only academic anyway
On the other hand, if when Iāll find time, Iād like to find a software solution for this after all 
