Connect bits streams at 13Mhz to GPIOs

[michcfr]

Posted on January 23, 2017 at 23:54

Hello,

I have a board which have 8 x bit streams. Each bit stream has its own associated bit clock. So I have: 8 x 2pins (one for the bit stream, one for its associated bit clock). Each bit clock is at 13mhz.

I would like to connect these streams to GPIOs pins of a single Cortex-M MCU for further processing. Which STM32F should I use?

Thx,Michel

[waclawek.jan]

Posted on January 24, 2017 at 00:47

Each bit clock is at 13mhz.

Unless you really meant millihertzs, which I doubt, you can't. There are only 6 SPIs even in the fattest 'F7s, and even if you could coax a SAI (of which 2 are in the fat F7s), I can't imagine any reasonable processing of an inflow of 13MBytes/s other than just plain shoveling it into a memory.

I'd recommend you to divide et impera.

JW

[Tesla DeLorean]

Posted on January 24, 2017 at 01:17

Consider using something more appropriate, like an FPGA

[Mon2]

Posted on January 24, 2017 at 04:53

Agree. FPGA (Lattice is nice; low cost for the devices; low cost for the kits). Also review the use of XMOS devices which is a middle ground between FPGA and microcontrollers using the C language to program your code. The $15 USD StartKit (Digikey) for XMOS devices is an excellent way to get started with this product line. Your 13 Mhz sampling is within the scope of the XMOS deterministic CPUs. You can always consider to stitch the XMOS / FPGA devices with a STM32 CPU and enjoy the best of both worlds.

[S.Ma]

Posted on January 24, 2017 at 05:38

Was wondering if cooking from DMA from a single GPIO port with 16 bit words dump could yield something. Or using DMA with FMC with oversampling. If all clocks are same frequency, it would be phase difference? Brute force with EXTI to build sw deserialiser? Once bit to byte, data rate would become reasonable.

[Andrei Chichak]

Posted on January 24, 2017 at 06:59

It may seem heretical, but I'd look at one of the motorola/freescale/nxp/broadcom chips, perhaps even the ones whereST is a second source. In the SPC56 range. They have a powerpc core, but the peripheral that you are looking for would be the eTPU.

The eTPU is a microcoded time processing unit that would be perfect for this application.

The confounding factor is going to be the phase difference in the clocks as pointed out by

Centauris.Alpha

. You will have to figure out the phase difference resolution and make that your base clock rate. But with an eTPU, you could do this as 8 half SPI ports, 8 two bit parallel ports with one bit just containing 0x55 and the other containing real data. Or you could write yourself some custom microcode.

https://community.st.com/0D50X00009Xkh83SAB

If the clock bits can be in phase and are turned off when there is nothing being transmitted, that would be a large simplification.

This would be very difficult, with an expensive processors, new compiler chains, and learning the eTPU. But very doable.

[Tesla DeLorean]

Posted on January 24, 2017 at 16:54

Doing it via software with blunt force just seems to be the wrong approach. Software engineers should stop trying to solve everything as a software problem.

At a minimum I think there needs to be some front end processing/consolidation of the streams/data. For high speed parallel data the DCMI might be worth a look, and you could likely modulate the clock somewhat as it is already asynchronous with respect to the processor/system clock.

[michcfr]

Posted on January 25, 2017 at 14:58

Thank you for your response.

So the suggested solution is to dispatch the 8 bistreams over many cortex-M connected through SPI? 

For example: 4 x Cortex-M0 or 2Xcortex-M4 ?

Thx

Michel

[michcfr]

Posted on January 25, 2017 at 15:01

Thank you for your response.

I would be in favour of a software solution rather than HDL if possible.

In another post you suggest DCMI, but this interface have only one clock signal and I have to manage 8 independant clocks. How can I handle 8 independant clock with a single DCMI?

Thx

Michel

[michcfr]

Posted on January 25, 2017 at 15:05

Thank you for your response.

The XMOS solution seems very interresting.

In another post

Chichak.Andrei

mentions an eTPU. How do the XMOS solution relates to eTPU in terms of power consumption, development/support and price?

It seems that eTPU is closely related to automotive and XMOS is a more general processor.

Thx

Michel