FastSPI_LED2 Teensy 3 and const array access

Status
Not open for further replies.

mortonkopf

Well-known member
Hi all,

I have ben using Teensy 2++ for running an LPD6803 Led array with the colour values to be displayed stored in PROGMEM. I have been using the FastSPI lib to drive these. My code for this was along the lines of:

in setup
FastSPI_LED.setChipset(CFastSPI_LED::SPI_LPD6803);

in loop
unsigned int array0[] PROGMEM = {0x7fff, 0x7fff, 0x7fff, 0x7fff, etc (these are 15bit colour leds)

Led[led_number1]= pgm_read_dword((uint32_t)(&(array)));
etc for the Led array locations, where i is the incremented value to find the array location.

It may not have been the most efficient, and was probably incorrect but, hey, it worked. (I think that I should have declared uint16_t).

I am moving over to the new FastSPI_LED2 lib and am using 24bit colour ws2811 leds, but am having issues with accessing the array values. I the Teensy 3 and leds up and running with non array values, producing patterns mathematically. However, I have the array of 0x123456 colour values, but can't seem to get the correct syntax for FastSPI_LED2 to access the correct location in flash. I have been reading the examples, but not found anything that makes sense to me for this issue.

I have declared the array as:
const unsigned int array[] = { 0x00FF00, 0xFFFF00, 0xFF00FF, etc

and am trying to access the value by using:
leds[led_number1]= CRGB{array};

Any idea whether this syntax is correct?
I'm thinking that as CRGB struct is in the for of {byte g, byte r, byte b}, I must have to do some for of bit shift:
leds[led_number1]= CRGB{(array)??16,((array)??8),(array)};

but this seems over complicated

many thanks for the help

mortonkopf.
 
Last edited:
Ummm, the teensy 2.0++ is based on the AVR processor, and int is only 16 bits.

So, things like this need to use long, int32_t, or uint32_t to make sure all of the bits can be specified:

Code:
const unsigned int array[] = { 0x00FF00, 0xFFFF00, 0xFF00FF, etc

// should be
const unsigned uint32_t array[] = { 0x00FF00, 0xFFFF00, 0xFF00FF, etc

// Also note, the above array should be a PROGMEM to save precious SRAM, but that can complicate things

// and assuming leds[les_number1] is declared as a 32-bit type, but red, green, blue are 8-bit types (byte)
leds[led_number1] = (red << 16) | (green << 8) | (blue);

// should be
leds[led_number1] = (((uint32_t)red) << 16) | (((uint32_t)green) << 8) | (blue);

Now, on the teensy 3.0, ints are 32-bit, and you don't have to worry, but it is useful to do so any way, in case code gets ported back to an AVR processor like the teensy 2.0++.
 
Ah yes, int is 16bit in arduino, and this this needs to be changed. Also, I believe that PROGMEM no longer needs to be used as in Teensy 3 'const' will place the array into flash rather than RAM (I have checked this with a very large array, and it does seem to be the case). Thank you for the pointers. I will look into it over the day or two and report back with a post of the the correct syntax.

thank you for your time and kind regards to all
mortonkopf
 
Last edited:
So, thanks for the pointers. I have the Teensy 3 reading colour values from an array held in flash using the FastSPI_LED2 lib. For others who may need it, I declared the array as const, and used a bit shift in getting the value out:

const unsigned int array[] = {0x00FFFF, 0x00ff00, 0x0000FF, 0xffFFff, 0x000000, ...etc

The array can stay as int, and does not need to be long. (probably a great sin to not explicitly declare as long...)

and then used (where i is the array location):

leds[led_number1]= CRGB{(array>>16), (array>>8), (array)};

hope that this is of use.
mortonkopf
 
Last edited:
So, thanks for the pointers. I have the Teensy 3 reading colour values from an array held in flash using the FastSPI_LED2 lib. For others who may need it, I declared the array as const, and used a bit shift in getting the value out:

const unsigned int array[] = {0x00FFFF, 0x00ff00, 0x0000FF, 0xffFFff, 0x000000, ...etc

The array can stay as int, and does not need to be long. (probably a great sin to not explicitly declare as long...)
For code like this, I still think it is better to be explicit in how many bits are used, i.e. uint32_t. That way it will automatically use unsigned long on the AVR processors, and either unsigned int or unsigned long on ARM processors.
 
Status
Not open for further replies.
Back
Top