High Frequency Input Processing

[AndersonKKK]

Hi,

The input to the MCU is basically 1-bit (0/1 values), but it would be better if it could process multiple bits.
The input is at 150MHz, and 10,000 data items are received at once. The MCU must store them in uint8_t data[10000]. When a 1-bit value is received, data[10000] contains 0/1 values. For the next data item, the 0/1 values ​​must be accumulated and added for calculation.
This is what I’ve come up with:
1) GPIO: 150MHz input is not possible.
2) ICP + DMA: It seems possible, but it doesn't seem to work. ICP cannot  reliably capture 150MHz, and DMA doesn't seem to be able to store data in SRAM.
3) DCMI or DCMIPP: 8-16bit data can be processed, and accumulation is possible using DMA. However, the maximum speed is 80MHz or 120MHz.

Is there a model among the stm32 models that can do this on its own mcu?

[TDK]

What does the signal coming in look like? If it's just data, no clock, I don't think any STM32 can do this, at least not if you need the reads to be synchronized to something. If an occasional bit slip or skip is allowed:

At 150 MHz you would need to sample using something like SPI, not through the GPIO registers.

On the STM32H723, SPI max is 125 MHz, OCTOSPI is max 140 MHz, so no luck there.

On the STM32N6x5, max XSPI clock is 185 MHz, so that's a possibility. Max SPI click is only 115 MHz.

It's possible a memory interface could also work.

> MCU must store them in uint8_t data[10000]

As a 0 or 1 per sample? Not possible. But you can post-process the data.

[AndersonKKK]

thanks TDK.

Since the PCB hasn't been designed yet, anything is possible, but the clock can be pulled from the MCO pin of the MCU or can be supplied externally.

After 10,000 data (0/1) are received, the next data item is actually received consecutively.

Using XSPI + DMA, is it possible to split the DMA address into two area, so that one side receives the data while the other side accumulates the data?

[AScha.3]

Hi,

sampling an input at 150MHz ...? I think, impossible on any cpu without dedicated hardware , lets say: a SPI input, that can run at 150MHz .

No STM , afaik.

But what comes to my mind : the RP2350 , dual M33 cores at 150MHz ;

AND the programmable PIO state machines, can sustain 360 Mb/s during the active scanline period .

With one of the PIO it should be no problem to make a 150Mbit SPI .

[TDK]

DMA has the half-complete and full-complete interrupt that lets you do this. Or you can use double-buffer mode to store into separate regions.

[AndersonKKK]

I have one more question.

It seems physically possible to receive data using DMA over xSPI.

But the question is, is it possible to receive data over xSPI in a free-running manner?

[Ozone]

> No STM , afaik.

I would say, not with a general-pupose MCU like the Cortex M is one.

I think this use case asks for specialized hardware. Either a DSP, or an application processor (like a Cortex A) with peripheral hardware suited for the purpose.

[TDK]

Isn't DMA free-running?

You can't read and process 150 MHz data continuously. Not enough CPU for that.

[Ozone]

> You can't read and process 150 MHz data continuously. Not enough CPU for that.

I would second that, converting it into a SPI stream does not change the problem. xSPI might get it into the core, but you still cannot process it in a useful manner for any output stream fast enough.

I suppose one could de-serialize the data with external hardware to 8-bit or 16-bit, and read it in by the core in parallel manner, as byte / word.
The roughly 2MByte/s might be manageable by a H7 or less - but requires specialized hardware.

[AndersonKKK]

One solution I've been thinking about is that the STM32N6X series support xSPI's DTR (Double Transfer Rate) mode up to 140-200MHz in spec-sheets.

If MCU set the xSPI clock to 75MHz, it should be able to internally receive data at double that rate, 150MHz.

Using DMA and double-buffer mode, with the DMA receiving data on one end and the CPU processing it on the other, it should be able to physically receive 150MHz data.

However, the problem is that, unlike SPI, xSPI can only operate as a master, not a slave, on the STM32 side. Therefore, only after an STM32 (master) communicates with another slave via the xSPI line to exchange protocols (e.g., a read operation), the STM32 can then read the data at the appropriate clock rate.

However, the slave can only send data and not communicate the protocol.