GPIO vs SPI for LED1642GW

[JFern.5]

Well, as you can see in the datasheet and the application note for LED1642GW, It doesn't use pure SPI, since it doesn't use CS but it requires the Latch Enable (LE) signal.

I'd actually like to write an application to manage multiple LED drivers but the important point is that I'd like to do it for an embedded system based on iMX6, instead just a microcontroller. This apparently could be an issue because SPI spec has not any signal intended to play the role which LE requires. That's why I've been considering to develop from scratch the protocol using GPIO. 

What do you think?  

[Mazen Aljeddani]

I don't think that developing the complete SPI protocol using GPIO only for ​one custome signal while the SPI hardware is available.

If I understand your question correctly. ​You

only need a logic not gate to invert the CS signal to be used as Latch Enable, or a a transistor or any logic negation method.

Regards,

Mazen​

[KnarfB]

You may look at X-CUBE-LED1642 sample code for the X-NUCLEO-LED16A1 board.

[JFern.5]

Well, In fact I can invert the CS signal modifying the device tree to make it high-active, however LE requires also to be controlled in a middle of a byte. Am I right?

[JFern.5]

Have you read the Application Note for the LED1642GW driver? https://www.st.com/resource/en/application_note/dm00097096-the-led1642gw-and-aled1642gw-startup-guide-stmicroelectronics.pdf

You can see in the figure 3 that you need to set LE on high for several CLK rising edges to use different commands, I think It's not possible to control CS in that way when you are using SPI protocol.

[JFern.5]

I don't get the point of using an expansion board like X-NUCLEO-LED16A1 :\

[KnarfB]

You don't have to use the expansion board, but may check the sample code and adapt to your needs.

[JFern.5]

That sample code is apparently for a STM32 MCU, so I think I won't be able to use it in a whole embedded system.