LED drivers, How to connect them to Normal SPI

[ali_asadzadeh]

Hi,
There are lot's of cheep and good 16 channel LED drivers out there, Like MBI parts like MBI5043,MBI5045,MBI5030 etc... or from ST  something like STP1612PW05 or similar ones. all of them seems to have a industry standard footprint and the protocol seems the same, I have bring them up by bit banging to them and they worked as expected, the weird thing is the LE signal which has this Number of CLK
rising edge when LE is asserted do different things!  I wonder how to connect them to a normal SPI and could get the 30MHz SPI clock, do we have a trick? in this way we can achieve the maximum speed, also I prefer to use STM32 for these ones, so do we have something there to help?

[langwadt]

Hi,
There are lot's of cheep and good 16 channel LED drivers out there, Like MBI parts like MBI5043,MBI5045,MBI5030 etc... or from ST  something like STP1612PW05 or similar ones. all of them seems to have a industry standard footprint and the protocol seems the same, I have bring them up by bit banging to them and they worked as expected, the weird thing is the LE signal which has this Number of CLK
rising edge when LE is asserted do different things!  I wonder how to connect them to a normal SPI and could get the 30MHz SPI clock, do we have a trick? in this way we can achieve the maximum speed, also I prefer to use STM32 for these ones, so do we have something there to help?

switch between hw spi and bit banging depending on what you need to do ?

[ali_asadzadeh]

I want to do it with HW SPI, right now I'm doing bit-bang! Because I want to use DMA on SPI and free the CPU.

[SiliconWizard]

You could take a look at this: TLC5947
http://www.ti.com/product/TLC5947

[Benta]

SPI has different modes, where clock phase and clock polarity differ. Make certain you use the correct mode.

[ali_asadzadeh]

SPI has different modes, where clock phase and clock polarity differ. Make certain you use the correct mode.

I know that, the problem is the LE signal! do we have any sample code with hardware SPI, any MCU or arduino?

[ali_asadzadeh]

You could take a look at this: TLC5947
http://www.ti.com/product/TLC5947

It's not compatible with these chips!

[ealex]

I took a quick look over the datasheet (https://olympianled.com/wp-content/uploads/2015/09/MBI5043.pdf)

It looks like the LE will do different things, depending on how many clock cycles it's set to 1.

I can think on several ways to do this:
- synchronize 2 SPI channels, if possible on your CPU with the same clock and mode, one of them handles SDI and the other handles LE - you will need 2x16 bit words for each byte
- use something like the external memory interface that's present on some STM32 chips, but you'll waste a lot of RAM if you don't connect several LED drivers in parallel
- get a small FPGA / CPLD (Lattice maybe) and make it into a protocol converter - SPI pass-trough, some extra input pins that will specify the requested command, and a counter in the FPGA that will set the LE high at the appropriate moment. If you need just 1 command, you can even set an external counter chip that will set the LE line high at the proper moment and will be cleared by the SPI's #CS line.

[SiliconWizard]

You could take a look at this: TLC5947
http://www.ti.com/product/TLC5947

It's not compatible with these chips!

What isn't? It seems relatively straightforward to feed it data with a simple SPI bus. Were you looking for ICs with the exact same commands and pin-out (or are the analog specs or features not fitting the requirements)? Adapting the software to this chip looks simpler than trying to twist an SPI bus to drive the other ones. So do we have to understand that you're not going to change anything hardware-wise?

Otherwise, one solution for the others (with this LE signal) would be for instance to use QSPI instead of SPI if your MCU supports it. QSPI is like SPI but can put out up to 4 bits (some MCUs even support 8 bits in extended SPI peripherals), you could use 2 bits of data to drive the data and LE signals.

Then again, if absolutely no hardware change is allowed, you may not necessarily be able to do this if the QSPI (or similar) peripheral can't be used with the pins that were selected on the MCU (really depends on the MCU and how the IO mux works if there is any...)

[TomS_]

I want to do it with HW SPI, right now I'm doing bit-bang! Because I want to use DMA on SPI and free the CPU.

What I would do is use DMA to transfer all of the data, which would be the most intensive part for bit banging, and with an interrupt on DMA transfer complete, bit bang a single clock pulse to latch the data in.

You could even go as far as using a timer interrupt if you dont want to sit in a busy loop for your bit banged clock pulse.

To me that seems like the least amount of effort for the CPU and the programmer.

[SiliconWizard]

Just as an added note if no hardware change is possible and if using SPI is not an option or wouldn't bring significant benefits due to this LE signal and how it must (if I got it well from the datasheets, but didn't look too deeply) apparently be toggled right in the middle of the serial communication: we haven't seen your code, but I think there are probably a number of ways to improve your bit-banging approach (including not making it blocking) so that its relative inefficiency wouldn't be a problem in your code.

My assumption here is that 1/ LED driving itself is not that time-critical if it's just for viewing purposes - to be confirmed -  and 2/ the way you currently bit-bang to the LED driver is likely blocking, and thus makes it impossible to execute anything else on the MCU until it's completely done. If 1/ is true, you could just implement the bit-banging in some timer interrupt for instance, "sending" just one bit at a time at whatever rate is convenient and still meets your requirements, but obviously as slow as possible. Time spent in this interrupt would be minimal. MCU could execute anything else while the communication is under progress, which, unless again updating the status of the LEDs should be very fast (useless if it's only a visual indicator), is probably your main concern here.

[ali_asadzadeh]

Thanks for the feedback, The LED driver part is not allowed to change, but everything else is possible, also It should be on a low end MCU, because of the price

This is the STM32 bit-bang code,

#define RGB_LE_init                  //GPIO_SetDir(0,11,GPIO_DIR_OUTPUT) //RGB_LE
#define RGB_LE_0                     HAL_GPIO_WritePin(GPIOF,GPIO_PIN_0,GPIO_PIN_RESET)//LE0
#define RGB_LE_1                     HAL_GPIO_WritePin(GPIOF,GPIO_PIN_0,GPIO_PIN_SET)//LE1

#define RGB_SDO_init               

#define RGB_SDI_init               
#define RGB_SDI_0                     HAL_GPIO_WritePin(GPIOA,GPIO_PIN_7,GPIO_PIN_RESET)//SDI    0                        
#define RGB_SDI_1                     HAL_GPIO_WritePin(GPIOA,GPIO_PIN_7,GPIO_PIN_SET)//SDI    1                        

#define RGB_CLK_init               
#define RGB_CLK_0                     HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_RESET)//SCK    0               
#define RGB_CLK_1                     HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_SET)//SCK    1   

void init_STP1612PW05(void)
{
   

   //set outputs
   RGB_LE_init;
   
   RGB_SDO_init;
   RGB_SDI_init;
   RGB_CLK_init;
   
   RGB_LE_1;
   
}


void STP1612PW05_write(void)
{
   int i=0;
   uint16_t RGB_Data_temp[16];
   for(i=0;i<16;i++)
      RGB_Data_temp=RGB_Data;
   
   //Load first 15 data
   for(int j=0;j<15;j++)
   {
      for(i=0;i<16;i++)
      {
         RGB_LE_0;   
         
         if(i==15)
            RGB_LE_1;

         RGB_CLK_0;
         if(RGB_Data_temp[j] & 0x8000)
            RGB_SDI_1;
         else
            RGB_SDI_0;
         
         
         
         RGB_CLK_1;
         RGB_Data_temp[j] <<= 1;
      }
   }
   //osDelay(1);
   //Global latch all data
   for(i=0;i<16;i++)
   {
      
      RGB_LE_0;   
      
      if(i==15 || i==14)
         RGB_LE_1;

      
      RGB_CLK_0;
      if(RGB_Data_temp[15] & 0x8000)
         RGB_SDI_1;
      else
         RGB_SDI_0;
      
      
      
      RGB_CLK_1;

      RGB_Data_temp[15] <<= 1;
   }
}

If it can be done efficiently with DMA and GPIO only, it would be nice! since GPIO and DMA is almost free on any cortex M part.

[NorthGuy]

- synchronize 2 SPI channels, if possible on your CPU with the same clock and mode, one of them handles SDI and the other handles LE - you will need 2x16 bit words for each byte

Make one SPI master, forward the clock from it to the other SPI.

Make the second SPI slave, and use its MISO to output LE as needed.

This will be perfectly synchronized and DMA-able.

[SiliconWizard]

Thanks for the feedback, The LED driver part is not allowed to change, but everything else is possible, also It should be on a low end MCU, because of the price

This is the STM32 bit-bang code,

Confirms that it's blocking.
As I said above, making it non-blocking is largely possible even with no DMA, and not very difficult.

Now you have several different options. Up to you to select the one that can be implemented on your MCU and that you feel comfortable with.

[ali_asadzadeh]

Confirms that it's blocking.
As I said above, making it non-blocking is largely possible even with no DMA, and not very difficult.

Thanks, But how?

Make one SPI master, forward the clock from it to the other SPI.

Make the second SPI slave, and use its MISO to output LE as needed.

This will be perfectly synchronized and DMA-able.

That sound a good option,but pricey in terms of SPI usage.