What considerations should I have when selecting a microcontroller for fast read and throughput?

Question

For a project at work I am tasked with selecting a microcontroller to facilitate video transmission.

The microcontroller will read H.264 encoded 1080p30, 30 to 40-second, video files (~500 MB) from an external FAT32 storage (Currently a MicroSD UHS-1/Class 10) and send them to a communication component, with a WiFi module as most prominent candidate. It is impossible to use a wired connection in the context of this project. The data is sent over short range and during transmission the microcontroller is completely dedicated to transmission. It will have no other tasks running in parallel.

Timely transmission of video data is the most important quality attribute and we're aiming at a timeframe of around 1 minute or less.

I saw many questions about processing video that were about raw signals or output from camera modules, but did not find a case where there is just a microSD file system to read encoded video from and how this relates to needed capacity.

What should be my most important consideration when selecting a microcontroller to achieve an optimal data read speed from a storage device such as MicroSD, to route this data through the microcontroller and submit it to the communication component for transmission? Should I be looking at processing power, pins, RAM or other specifications?

Answer 1

You don't need a lot of RAM or pins to do this, but you need fast peripherals and system clock. You are looking at about 70Mbps throughput. If you take a basic approach of reading a chunk and writing a chunk, you would need to be able to read and write with at least twice that rate (since only one side is being done at a time).

If you get an MCU with DMA you should be able to link both together so you can copy directly. But I feel this may not be so simple when you get WiFi involved. You may need to deal with collisions, send failures, dropped connections, etc.

So your SD should probably be 4-bit or 8-bit SDIO, and the MCU you select should support that natively (i.e. preferably no bit-banging). And then the WiFi module should have a similar interface if possible. You can get modules with USB interfaces, but be sure it can handle the throughput you need. UART is obviously not an option.

I would start with selecting the WiFi module before the MCU, if you haven't already done that.

Answer 2

I'd argue what you're looking for is very likely not what most people would consider a microcontroller¹, but a proper applications processor, which runs a somewhat usable general purpose OS.

The ca. 70 MBit/s (=500MB/60s) throughput is, at any rate, not manageable by a CPU without heavy DMA usage. Notice that you can't likely put that much data rate through WiFi, so that's where your whole application breaks. You'll need at least Fast ethernet to do that. Since WiFi happens on a shared medium in an unlicensed band, it's not going to be reliably fully available for that rate, so I think you should rule that out. Even Fast Ethernet is a bit thin, so I'd go for Gigabit Ethernet straight from the start (this is 2017, after all, not 1997).

There's embedded processors that have GMII2 interfaces for Gigabit PHYs, but they're typically not MCU, but CPUs with external RAM.

There's absolutely no reason to design such a device yourself – go for one of the many, many single-board computers that have proper Gigabit Ethernet. I like the Odroids.

The point I make regarding "proper" OSes is that you want things that are typical of fully blown operating systems:

• a flexible file system stack (notice that FAT32 can't do files > 4GB, so it might be a bad choice to start restricting yourself to)
• A high-performance networking stack that supports network interfaces with DMA and interrupt coalescing (it's really no fun if your processor is stuck with handling hardware interrupts that you know will happen, anyway).
• easy multitasking (transmission of data should be independent of reading from storage)
• flexible buffering
• Very very loose definition of latency restraints – you don't need what anyone would consider real-time.

Thus, go for a cheap embedded Single-Board-Computer running a general purpose Linux, if you ask me.

---

¹ definitions vary, but it's generally agreed that a microcontroller differs from a microprocessor at least in integrating the RAM in the same package)

Answer 3

Don't bother trying to solve this using a microcontroller, you need a computer with an operating system to make this work. My suggestion is that you buy an Android phone or tablet capable of USB OTG and 802.11ac. The Nexus 5X is an ideal candidate. Then write an app that transfers your files via FTP and unmounts the SD-card.

There are other options (such as using a Raspberry Pi 3 with a network bridge capable of 802.11ac) but I doubt you could build anything smaller or more power efficient than a phone. Rolling your own solution from scratch with a "microcontroller" might (theoretically) be power-efficient but will cost you dearly in R&D.