STM32H730AB - Assembling Data from Single Bit Inputs

[SPaul.3]

I would like to use the STM32H730AB as the central controller for a wireless sensing device. For this device, the MCU will drive an external 8-bit ADC at 40 MSPS. This ADC generates an output signal across 8 output pins, 1 for each bit of the digital signal. For wireless communication, I plan out sending each data point to an external wireless module via the SDMMC2 module. For each point of data, I would like to write the time of conversion (based on the ADC clock signal from MCO2) and the "reassembled" conversion data from the ADC. So my overall question at this point is twofold:

1. What would be the best method to input 8 1-bit channels and subsequently assemble the 8 individual bits into a single 8-bit word?
2. Is it possible to write a file internally for each data point? This file would only need to contain the time of conversion and the 8-bit conversion data. This file would be sent to the SDMMC2 for transmission via the external wireless module.

[Tesla DeLorean]

40 MHz ? ADC or DAC ?

Strikes me as a mixing task far better done with a small CPLD/FPGA

[TDK]

40 MSPS at 8bit is above the capabilities of the STM32H7.

You can use DMA to transfer GPIO states to memory, but this will top at somewhere near 10 MSPS, and even then you'll be running into bus contention issues if you're doing anything else nontrivial within the program, such as talking to an SD card.

[Tesla DeLorean]

Perhaps there are some off-the-shelf FIFO Memory and SERDES devices.

[SPaul.3]

Thank you for your recommendations! Do you happen to know what kind of device I might be able to use in order to send data to the SDIO interface on my wireless module?

[SPaul.3]

I figured that I would need a very high MIPS count, but I didn't have a great idea of how high it needed to be. I'm thinking something like the more specialized components that @Community member​ mentioned above will be better suited to my application. My overall PCB footprint needs to remain small, and mpus and mcus seem to get much larger and more complex with higher processing rates.

[Tesla DeLorean]

I'm still not clear of the TO/FROM of what you're trying to do, are you trying RECORD data to SDCARD, PLAY it back, or BOTH. Perhaps draw a system diagram.

Is this a continuous process? Or bursts of 40 MSPS

Sounds to me like you need to hire someone with RF BASEBAND design experience, I don't think this is something you can cobble together with an STM32 and deal with the bandwidth, and be small, cheap, low power, etc. Most times people decimate the data so there's less of it rather than to wrestle the fire hose directly.

You need to figure out the flow, how you're going to pipeline the data, and get efficiently on/off a storage medium. Writing to eMMC / SDMMC tends to be slow unless you get into highly specialize products or streaming modes.

Sounds to me like you'd probably need to do it all in an FPGA with enough memory, horsepower, and CPU to do caretaking working, and get the data paths implemented in HW. Major players would do this as an SoC/ASIC

#AdverbSoup

[SPaul.3]

Thank you for this additional guidance. Hiring a designer unfortunately isn't in the picture, as I'm a PhD student working on this concept for my research. Also, I'm working in material science/engineering and most of my electrical experience so far is limited to our DC strain gauge circuits. For most of our work, we let Tektronix devices handle our signal conditioning, which requires a time domain resolution in the 100 ns range. If I can sort out triggering, I can run it in a short burst of 40 MSPS, but the "easier" option would be to just run continuously.

The SDIO portion of the system is the fastest option for data input and control in the wireless module I'm looking at (NXP 88W8987). I had thought it would be convenient to package the data before transmitting, but perhaps that step just slows the process down. The other option then would be to use the processor on the receiver end to receive the raw signal and package it as it comes in. So I guess writing isn't exactly necessary within the sensor device, as long as it can be transmitted out to be written by the processor on the receiver end. I've included a basic diagram below of what I'm trying to accomplish on the sensor/transmitter end. The unknown at this point is the stages between the ADC and the wireless module.