This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR2000: UART-to-CCSI Bridge for Matrix LED Driver

Part Number: MSP430FR2000
Other Parts Discussed in Thread: LP5890, MSP430F5529, TLC6983, TLC6983EVM, MSP430FR2110

Hi Team,

Can the MSP430FR2000 (or another MSP in this family) be able to support a UART-to-CCSI bridge implementation? The CCSI details can be found on section 8.5, p.25 of the LP5890 datasheet. I am thinking it would be similar to the existing UART-to-SPI demo project. Would it leverage the HW SPI interface and be able to meet the CCSI timing requirements?

Thanks,

Antonio

  • Hello Antonio,

    CCSI looks very similar to SPI, with the key difference being that the SCLK has to be on constantly. This is counter to most implementations of SPI, where the clock output is only being driven when sending data from the controller. This constant clock is a requirement for LP5890 as I gather from my quick glance at the data sheet, as it is used as the main clock for that part as well. So if you stop clocking the LP5890, it stops controlling the LEDs. 

    You might be able to rig up something where you constantly put out all 0xFFs via SPI to have a constant clock, but you would not be able to do that with an MSP430FR2000. You would need something with more memory to either utilize DMA, or have an extensive ISR routine that allows you to keep feeding the SPI module.

    The last issue is speed. You might be able to get away with 2.5-3MHz input to LP5890, but tis probably not ideal/ best performance of the device. The MSP430FR2000 goes up to 16MHz, so you may have enough time to keep filling the SPI buffer if operating SPI @ 2.5MHz, but you would have much time for anything else, so UART translation maybe a tough ask. you would have to have a very streamlined ISR routine to getting UART -> SPI, and figuring out when to interrupt your shoveling of 0xFFs. You would most likely want to buffer a whole command string then send. So you won't have enough memory on MSP430FR2000 to do this. 

    With these points in mind, I don't think MSp430FR2000 is a good fit here. Something that can run at at least 24MHz might be possible, but would still be a challenge I think. 

  • Hi Jace,

    Thanks for the detailed response. The MSP430F5529 is used on the TLC6983EVM to drive the TLC6983 which uses a similar interface. However, I am looking for a lower cost option since most features of this MSP will not be needed.

    Based on MSP430F5529 specs, I would think the lowest cost option might be the MSP430F5234 since it has the same memory and runs at 25MHz. Do you see any issues implementing the bridge with this IC? Are there any lower cost options to consider?

    Thanks,
    Antonio

  • That EVM does seem applicable. Any MSP430F5xxx device would work here then depending on your memory requirements. You maybe able to get away with a 24MHz FRAM device as well depending on how the solution was done. I don't see any information on the SW that goes with the EVM though to make a judgement call at this time. 

  • Antonio,

    with your drop of the TLC6983EVM code, I was able to decipher what they are doing. Instead of constantly filling the SPI buffers, they are outputting a timer at the correct frequency to be utilized as the SPICLK. They then have the SPI peripheral setup to use the same base clock  and dividers so everything lines up, and just utilize the data lines form the SPI Interface. 

    So I would say this is doable in most devices. I don't think the application is doable on an MSP430FR2000 though due to memory requirements, as you are going to want some buffers for the data transfer from UART  -> CSSI, and you need some extra code in there to settle the clock correctly for these devices. They maybe able to squeeze in everything to below 2k so the MSP430FR2110 might be the best option. They could of course develop/prototype on the MSP4320FR2311 Launchpad to see what there memory comes out to be and squeeze tot eh lowest memory variant they can. 

**Attention** This is a public forum