Hello, I’m getting an error when trying to compile a simple test program with the RGBMATRIX library on my local Particle Dev IDE install (Mac OSX 10.10.5).
App had all been compiling and working fine in this local environment. Then “something changed” and now I get this error when trying to compile, complaining that “gamma” is being defined elsewhere:
As for what may have changed, I know that Atom was upgraded recently (it is now version 1.8.0). I’m almost 100% sure that the simple app code I have has not changed (famous last words, I know).
Any clues / ideas about this problem, and what I can do to resolve it would be greatly appreciated!
@ninja118, I just realized that I haven’t update that library to Libraries V2.0!!!
I will do that tonight and test. From the error, it seems that the gamma array name is conflicting with a predefined C++ function.
Ah hah! Compiles without error when I set the targeted firmware version to 0.6.0 (had been set to 0.6.1) Thanks @Vadym!
As a newbie, I’m not totally sure of what the difference between 0.6.0 and 0.6.1 is, nor what the downside is to being set back at 0.6.0. So, @peekay123, I’m hoping you’ll still be able to take a look at and resolve the conflict so that the library can work with the latest-greatest. Thanks!
It would be great if the R1, G1, B1, R2, G2, B2 pins could be specified as part of the constructor for the Photon implementation. A specific conflict I have at the moment is trying to use I2C concurrently with the library. I2C, of course, uses D0 & D1 (which are currently fixed as R1/G1 by the library). Changing these in the library to, for example, D7 and DAC, allows me to use I2C at the same time. But would be nice if I didn’t have to hack the library!
Since the RGBMATRIX library chews up so many GPIO pins, I’ve found myself short of pins for other critical functions (even after some heavy multiplexing). As a result, I’ve experimented with eliminating the use of the OE pin from the RGBMATRIX library to reclaim one pin. Simply tying that low (always enabled) on the display seems to work. I’m not able to observe problems/glitches on the display with some limited testing. The library code uses OE to “Disable LED output during row/plane switchover” – so I was fearing I might see some sort of garbage. But didn’t. I’m not actually sure what “row/plane switchover” is, but are there cases where I might see problems? If not (at least on the Photon), it would be awesome if yet another option could be to omit the use of the OE pin (just assume that it has been wired always enabled).
Anyway, just a couple of ideas to ponder while you’re in the code…
@ninja118, great points! On the pin specifications, I’ll need to think about that as adding variables vs defines for those will impact the performance of the ISR (though marginally I suspect). As for tying OE to GND, that will work for one panel I suspect but may impact a multi-panel configuration. Definitely worth testing!
I’ll look at doing this for the next release of the library, though I have no timeline for that yet.
OK, thanks for considering these, @peekay123! For what it’s worth, the configuration I’ve tested is 32x128 (two 32x64 panels chained). Tying OE low hasn’t seemed to cause visible problems, but maybe I haven’t looked hard enough.
Hmm… not sure if it qualifies as hard, but I have been doing things like scrolling some full-screen bitmaps. I don’t have much to compare it to, but it seems to work well to me.
What happened was - RGB library was using a variable named gamma, and it was a free name for a variable in firmware versions previous to 0.6.1. But in new update, the Particle team has claimed the variable name gamma, and you couldn’t use it elsewhere. Similar to how you cant create a variable named Particle .
In future, if you run into an error like this, and support team doesnt respond with the speed of light like Mr. @peekay123 does - you have two (easy~~) options:
Roll back to previous version of firmware; or (lets say you MUST use newest firmware)
Download library, manually change the problematic name (in all files used by the library, of course) and manually use your “new” library.
Hi @peekay123, I’ve been trying to get the RGBMatrixPanel2 library to compile in the Desktop IDE, but am having difficulties. I get this error:
Steps to reproduce were to create a new, empty project in the Desktop IDE, then select the RGBMatrixPanel2 library to be “used” (i.e., added to the project’s project.properties file, then try compiling.
Also, if I try copying the library local (rather than just “using” it), the error I get upon compile is:
Same errors reported whether targeting firmware 0.6.0 or 0.6.1
Am I doing something wrong, or are there still a few issues to resolve with the Lib 2.0 version of the library?
@ninja118, I hate to say it but I only tested with CLI and web IDE cause I have nothing but problems with the desktop IDE. I’ll need to try and install it again on a VM and then I can debug. However, if it works on the web IDE and CLI, it should work on the desktop IDE.
@ninja118, now I understand. This is a problem due to the latest default Arduino compatibility being done by the pre-processor. A solution hasn’t been quite identified yet. I’ll take another look at the library to see if I can fix it myself.
wondering if you’ve had a chance to come up with a work-around for the ‘gamma’ variable name conflict with the 6.1 firmware?
I’ve recently discovered that while the RGBMATRIX lib has been working great for me with several sets of panels (pairs of 32x64 in a 32x128 chained configuration), a bunch of newer panel pairs (which physically look identical to the old pairs) do not work when I swap them in to the Photon running the RGBMATRIX lib. However, these same panels work fine when connected to a Teensy 3.2 with a SmartMatrix shield. Both my Photon config and the Teensy/Shield config are using SN74AHCT245 level shifters. So why would several sets of “old” panels work, but several sets of “new” panels won’t? Very repeatable across several Photon systems (i.e., old panels work, new ones don’t; but all those new ones (and old ones) work on the Teensy)…??? I asked Adafruit support if they thought it perhaps might be a timing issue (perhaps the Photon refreshing too fast for the newer boards or not having enough delays at certain points??) Any way for me to try slowing down the refresh or parts of the communication? (happy to try tweaking the code if you point the way)
A bit of a crisis here, so any thoughts you might have, particularly on #2, would be great!!
