hi every one, unfortunately current version of FastLED not support ESP HW SPI,

hi every one, unfortunately current version of FastLED not support ESP HW SPI, hence I’m trying to combine CRGB object with Arduino SPI command.
according to APA102 data sheet , following code must be performed for each show

#define end_write ((NUM_LED*3/ 4) + 15) / 16;

LED_BUFFER = (uint8_t )malloc(LED_NUM3+4+end_write);
memset(LED_BUFFER, 0, LED_NUM3+4+end_write);
memset(&LED_BUFFER[4+LED_NUM
3],0xff, end_write);

when LED_BUFFER filled by correct RGB data
ESP.flashRead(_m_pointer,(uint32_t ) &LED_BUFFER[4],LED_NUM3);
then simply run SPI.transfer(LED_BUFFER,LED_NUM*3+4+end_write);

however when I run sketch , most of LED color are white and effect is kindda nonsense , I really appreciated to have any comments

So there’s a bunch that is wrong in here. APA102 data is 4 bytes per led, not 3 - which is what you’re allocating and copying. There’s a control byte (which can just be 0xFF for the most part, unless you want to mess with the global brightness setting) - and SPI transfer isn’t going to know to do that.

Danial is this what it should be ?
void wireLED(byte Brightness)
{
for (int i = 0; i < 4; i++)SPI.transfer(0);
for (int i = 0; i < LED_NUM*3; )
{
SPI.transfer(0xE0 | Brightness);
SPI.transfer(LED_BUFFER[i++]);
SPI.transfer(LED_BUFFER[i++]);
SPI.transfer(LED_BUFFER[i++]);
}
for (int i = 0; i < (1 + LED_NUM / 32) * 4; i++) SPI.transfer(0xFF);
}

Roughly, yes

thanks Daniel , but 2 more things , I saw couple of lib use different end LED byte writing (SPI.transfer(0xFF):wink: such as following , as the number of writing is pretty different would you advise which formula is the best match
( 1 + LED_NUM / 32) * 4 ;
(LED_NUM*3 / 4) + 15) / 16;
((LED_NUM+1)/16)*4 ;

also as the FastLED used CRGB struct object for store LED data , I thought I should use processing to convert image pixels to 3 bytes RGB data , but as you stated I should consider the brightness writing as well , so there is two way to fulfill this task , first expand my buffer to 4 bytes size and filled the 4th place with brightness data after reading the image data , or use processing to convert image pixels to 4 bytes WRGB data, what is your suggestion ? thanks again

@Hamid_s_k For the second question, you don’t need to consider the brightness value unless you want to dim the pixels separately from the color data. For your purposes you should just leave the brightness at full, so use 0xFF or 255. If you do decide to change it, that byte must be in the range 224 to 255, with 224 being zero brightness (value is 224 + brightness from 0 to 31).
Unless you’re wanting an actual brightness control or dimming effect or you’re working with higher colour bit depths, there’s not really any use for the brightness value.

thanks @1icri_Old_Account , I’m gonna change my processing sketch to add 0xFF value to the generated data