Ok, so still not believing there is any sort of chip problem,
I decided to dig a bit deeper into the s/w to see if there were any other s/w issues
since even though my displays seemed to no longer have initialization issues,
there were some funky pixel issues I had earlier seen during the initialization when I
had slowed things down that I never resolved.
So I REALLY slowed down everything and starting seeing the funky pixel changes again during
initialization after pressing RESET on the Arduino.
It all eventually seem to recover to work ok, but there shouldn't be any odd pixels.
It was REALLY odd, momentarily some pixels changed, some displays had pixels with different
intensities. Lots of funky stuff.
It was very repeatable. This was good!
So then I went back to pausing after each control() message and
noticed the funky pixel stuff had happened by the time the first
control message was done.
control(TEST, OFF);
(my pauses were after each control function call)
So now thinking there must be some sort of reset issue potentially
related to the led pin13 blinking (which is the clock line)
I hooked up the logic analyzer to see what the signals
going to the modules looked like to see what was going on.
First thing I noticed was WAY more messages being sent to the displays
than I expected.
(I'll get back to that later).
So after spending quit a bit time going down MANY rat holes,
I noticed that for the TEST/OFF command,
the commands being sent were the wrong ones!
I was seeing a string of DIGIT0, 0 commands (0x1, 0x0)
instead of TEST/OFF (0xf, 0x0)
Now we are getting somewhere!
Looking closer at the commands,
I had 7 displays but I noticed that there were 49 command being sent to set the test mode
on the 7 displays.
Seven bursts of 7 commands.
The command looked like:
six (d0/0) one (TEST/0)
five (d0/0) two (TEST/0)
four (d0/0) three (TEST/0)
....
seven (TEST/0)
It eventually turned out to be something really simple:
This code:
void MD_MAX72XX::spiClearBuffer(void)
// Clear out the spi data array
{
memset(_spiData, SPI_DATA_SIZE, OP_NOOP);
}
Here is the prototype for memset:
void *memset(void *s, int c, size_t n);
So the code should be:
void MD_MAX72XX::spiClearBuffer(void)
// Clear out the spi data array
{
memset(_spiData, OP_NOOP, SPI_DATA_SIZE);
}
The error caused the _spiData arrary to not be filled in with
the needed NOOPs.
So whatever was there was being used and since it is malloc'd
it can vary depending on the actual code.
After this fix, no more funky pixel stuff.
One thing that would be nice is if the code could be a little smarter and
send the commands to all the displays at the same time vs sending the
command to each display separately which requires sending NOOPs to all
the other displays.
This would reduce the number of commands sent from NxN to just N.
I'd be curious if others still see issues after all four s/w updates are incorporated.
- the decode register
- the SS init order change
- the _csPin init order change
- the memset() parameter order fix.
marco,
I am curious on one thing. The SPI code.
Any reason not to use the SPI library that comes with the IDE so that the code could work
on the non AVR platforms? Like chipkit or Teensy 3?
Anyway just wondering.
--- bill