Associate II

Question

Connect bits streams at 13Mhz to GPIOs

Forum|Forum|9 years ago
January 23, 2017
17 replies
3408 views

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

This topic has been closed for replies.

waclawek.jan

Super User

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

michcfrAuthor

Associate II

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

waclawek.jan

Super User

Posted on January 25, 2017 at 15:35

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 ?

It's one of the options, not a recommendation. Others mentioned other options, e.g. using an FPGA either to pre-process (deserialize or merge the streams and then input e.g. through DCMI - the question of processability of 13MBytes/s still remains) or do all the required processing in an FPGA entirely without an mcu.

The choice depends on the nature of those bitstrams and the required processing of the received data.

Tell us more and we'll can go deeper in the suggestions.

JW

Tesla DeLorean

Guru

Posted on January 24, 2017 at 01:17

Consider using something more appropriate, like an FPGA

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

michcfrAuthor

Associate II

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

Mon2

Senior III

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.

michcfrAuthor

Associate II

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

Andrei Chichak

Lead

Posted on January 26, 2017 at 02:53

The eTPU is more than an automotive processor, it also does motion control quite nicely. It came out of the automotive market, but the TPU coprocessor doesn't care.

I used it to get an extra 8 UARTs without any external chips. On another project I programmed it for a half UART (transmitter to a display), SPI, a bunch of digital I/O and some PWM. Another time it was PWM to multiple servos, plus SPI, and some DIO. Each channel is individually programmable.

The best part was when EE got TX and RX on the UARTs backwards, fine, I'll just twiddle these parameters and now the hardware is correct.

The TPU is a co-processor that is used for I/O stuff that needs timing. It is attached to a pretty big processor too. A recent powerpc chip is the general purpose processor, the TPU just takes care of the weird I/O that the chip manufacturers can't worry about because the market is too small.

S.Ma

Principal

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.

Tesla DeLorean

Guru

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.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

Andrei Chichak

Lead

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.

AVI-crak

Senior

Posted on January 25, 2017 at 16:21

13mgts - it's the sound?

I think you want to 8 channels of audio. But why such a strange way?

Use ready-made audio codecs, for example in excess of cheap CMI8738. A little bit of magic, and the chip can be easily connected via the FMC / SRAM / MODE1 interface.

Features CMI8738 chip audio processing - much higher than any stm32f.

michcfrAuthor

Associate II

Posted on January 26, 2017 at 14:06

Hello

The bitstreams come from different radio transceivers (at 8 differents frequencies).

So I would need to decode these streams simultaneously.

I hope it helps. Thx

Regards

Michel

Tesla DeLorean

Guru

Posted on January 26, 2017 at 14:50

Put a deserializer on the front end to get each bit stream into bytes, and then use the DCMI to clock in the 'words' which include the byte and a channel number.

Or rethink what you are doing, because it is going to be very hard to do any processing with multiple streams at these rates in software on these parts.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

michcfrAuthor

Associate II

Posted on January 27, 2017 at 14:15

Thank you for your reply.

Any suggestion of deserializer models?

Sign up

Login with SSO

Login to the community

Login with SSO