I'd never heard of namespaces. That looks like the sort of thing I was looking for, but I gotta say, C++ seems pretty ridiculous to me. You've got structs, classes, and now namespaces, and they all seem to (mostly) duplicate the functionality of one another.

Well, to reduce clutter like you said. Though I had also planned to make some of the variables private and only accessible to the functions in the class. Which it seems I can't do with name spaces. But I guess that doesn't really matter, I mean I'm not making a huge application here and I'm not worried about accessing something I shouldn't somewhere I shouldn't. I was just going to do that because it's good practice.

So I guess I'll use a namespace instead and forget the whole private data thing.

So with namespaces I don't have to redeclare those variables in the namespace outside of it eh? Or use static?

static int MODULES; // Number of LED modules connected. Defined in config.txt.

static byte * data; // LED data is stored as a string of 12 bit LED values. There are 3 bytes for every two LEDs. We store it this way because the data does not need to be altered when we are shifting it out to the TLC5947s. Modifying the data with bit shifts would be very expensive and there is a lot of data to move. static byte * scale; // Scaling factor for LED brightness. Used when say, you want to be able to adjust the brightness of the powercell without changing all the code that assumes the max desired brightness is 1.0. Value stored here is scaling_factor*255, where scaling factor is 0..1.

Okay, by uncommenting that timing code I put in there when I was trying to optimize my SPI function for outputting the LED data, I have verified that the function is indeed being called, but it is going through the LED loop so fast that the thisLED pointer must surely be being set wrong:

// 340 microseconds // The trick which makes the above so fast is that we decrement the pointer and do the conditional jump while we are waiting for the previous byte transfer to complete.

// Move data from shift register into latch register:

LATPORT &= ~(1 << LATPIN); // Set LATCH pin low. It is important to do this first, just before transitioning high! I don't know why, but the LED modules won't work right otherwise! LATPORT |= (1 << LATPIN); // Set LATCH pin high. Transitioning from low to high moves all data from the shift register into the latch registers.

ENAPORT |= (1 << ENAPIN); // Set BLANK pin high. Turn all outputs off, and reset grayscale timer. Blanking reduces flicker, but it does not seem to matter if it is before, after, or in the middle of latching. ENAPORT &= ~(1 << ENAPIN); // Set BLANK pin low. Turn all outputs on.

sei(); // Reenable interrupts.

time = micros() - time; Serial1.println(time,DEC);

nextLEDFrameTime = time + LEDFrameTime; // Set the time of the next update.

int modules; // Number of LED modules connected. Defined in config.txt.

byte * data; // LED data is stored as a string of 12 bit LED values. There are 3 bytes for every two LEDs. We store it this way because the data does not need to be altered when we are shifting it out to the TLC5947s. Modifying the data with bit shifts would be very expensive and there is a lot of data to move. byte * scale; // Scaling factor for LED brightness. Used when say, you want to be able to adjust the brightness of the powercell without changing all the code that assumes the max desired brightness is 1.0. Value stored here is scaling_factor*255, where scaling factor is 0..1.

That was the predicted time (216 uS) for the fastest SPI loop. So not only does it work, it works nice and fast without mucking around with the SPI registers. Throw in one NOP if necessary if the LEDs require it.

(edit) Changed loop to post-test.

Please post technical questions on the forum, not by personal message. Thanks!

I just discovered that it was the NOP's which were the problem. Somehow switching to the use of a namespace has changed the timing so 10 NOP's is no longer sufficient. I threw 20 in there just to see if that was the issue (WAIT; WAIT;) , and sure enough the LEDs light up once more.

As for your suggestion Nick, I'm afraid there's one problem with your benchmark. The benchmarks I was doing before were for 6 LED modules, not 2. So that SPI function you're calling there is in fact 3x as slow as the theoretical max speed.

I guess I'll have to add or remove some NOPs and see what happens. I probably only need to add one. I had noticed with my earlier testing that removing just one would result in no LEDs lighting, and I could not figure out why that would be, when removing 2 resulted in garbage.

All the code wouldn't fit into one post and it uses a modified wavehc and sd card reader lib and 1284 pin definitions and serial output on uart1 with a special bootloader... I don't think you'd want to go to all the trouble to compile it. :-) Anyway I'm gonna post something in the optimization thread for this spi stuff, I just came across something interesting.