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.

6 - SPI to 32bit parrallele port

Other Parts Discussed in Thread: PMP

Hi,

I have to convert 6-SPI clocked at 20Mhz. Each SPI are 32 bits. I need to have all those being converted to a single parallel port of 32bit (16 bit is still acceptable). So basically I have 6-SPI @ 20Mhz In and need to output 32 bits @ ~4Mhz or 16bits @ ~8Mhz. So the need is mostly in # of DMA, SPI, parrallel IO and clock speed.

I looked in microchip portfolio and they do have a few that seems to fit. But I would rather stick with TI if possible. But I don't seem to find what I want. The things becomes especially vagues for the parralel port part.

Ben

  • Ben,

    Please correct me if I am not understanding your requirements. You are trying to connect 6 independent SPI ports and convert the incoming bit streams to a single 32-bit (or 16-bit) parallel port? Assuming that my understanding is correct I have 3 proposed solutions in order of which I thought of them :)

    You MIGHT be able to get away with using a Concerto Microcontroller. This will not be a pretty solution, but it may work depending on the speeds and latency you need. There are 4 SSI modules on the Master subsystem. There is a native SPI module and a McBSP on the Control subsystem. This totals 6 SPI ports. There is no DMA on the native SPI on the C28x side, but the McBSP does have DMA. If you go this route, it looks like you would have to write 3 different routines (one for each type of SPI) and then somehow interleave all of this to be put to the GPIO in a parallel fashion. Like I said, it is possible, but might not be worth the effort.

    Are the 6x SPI's independent devices? Is there no way to consolidate into less channels? The TM4C129x line of Microcontrollers has 4x QSSI ports. The data stream must be interleaved, so you would need to have already consolidated the SPI data.

    Are these SPI devices slaves? If so, with one SPI, you could write some sort of round-robin scheme to clock out the data from each of the 6x SPI devices using individually controlled Chip Select signals (GPIOs). Or by Using the the F2837x device, you have 3 SPI ports with DMA. If you use each SPI port for 2 of the external devices, you can reduce the data collection by 1/2. Some additional processing would be required on the MCU to organize the data such that you can then output the data to the GPIOs emulating a parallel port.

    I hope this gets you thinking a little outside the box!

    -Mark
  • Ben,

    Were you ever able to get this working? If so, please post how so that others with similar questions might learn from it.

    Thanks,
    Mark
  • CPLD or FPGA would be much better solution

  • Thanks Mark,

    I wasn't too sure if i should share because it wasn't in TI's portfolio. The solution I'm going for is the PIC32MZ2048EFH144. The chip has 6 SPI and a 16 bit parrallele port (it's not 32, but it will do) with 4 Byte buffer. It's a 252 Mhz MCU with 15 DMA channels. The maximum speed of the PMP is really vague. I didn't see any specific number but at least 7.125Mhz is achievable. The PMP will be interacting with the cypress FX3 (GPIF inertface). The interface is highly flexible, so I might be able to get closer to the 15Mhz by tweaking a few things in the interface. 15 DMA should be enough to do deal with the complete data transfer operations without much of the CPU involvement.

    7.125 Mhz would be insufficient for sure. But from what I read, most latency issues with the PMP should be bypassable with the GPIF. Ultimately the GPIF is a 32-bit 100Mhz parrallel bus, which really, no mcu can match.

    I haven't seen any CPLD with enough resource to allow a bidirectional bridge between 6-SPI and a parrallele port. The buffering of 192 bit becomes an issue quickly. A FPGA would probably fit better for the whole thing, in reality, that is what the GPIF is meant to interact with. In addition to matching the speed bus speed, an external RAM memory buffer could be added to cover for the USB 3.0 communication latencies. That being said, the FPGA also involve more cost, footprint, development time and less support.

    In summary the choice is between the PIC32 (low cost, limited scope, low grade solution) and a FPGA (high cost, high flexibility, high performance solution). Because of the limited resource I'm going for the PIC32.

  • Benjamin,

    I am sorry to hear that C2000, or TI in general, was not able to suit your needs. I will pass this information on to our architecture team as feedback. If you don't mind me asking, what type of application is this intended for?

    Thanks,
    Mark
  • The application is for a streaming for multiple ADC through USB 3.0. More spécifically it's for 24bit 625kHz. This specific hardware was for interfacing between the ADC and the USB chip.