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?

  • \$\begingroup\$ Why a microcontroller? Do you have power or size constraints? \$\endgroup\$ – user1890202 Mar 9 '17 at 18:49
  • \$\begingroup\$ Yes! Both actually! \$\endgroup\$ – Zimano Mar 10 '17 at 8:15
  • \$\begingroup\$ Ping! You've got three answers now, all of which are interesting. You should probably accept one to mark this question as answered. \$\endgroup\$ – Marcus Müller Mar 20 '17 at 19:44

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.

| improve this answer | |
  • \$\begingroup\$ Not agreeing with your math. 500MB/30s = 4000 Mb/30s ~= 133 Mb/s >> 70 Mb/s. So, doesn't even fit through WiFi (the "150 Mb/s" and "300 Mb/s" Draft-N are, generally, a lie) \$\endgroup\$ – Marcus Müller Mar 9 '17 at 14:07
  • \$\begingroup\$ @MarcusMüller where did you get 30s? OP wrote 1min. \$\endgroup\$ – AngeloQ Mar 9 '17 at 14:09
  • \$\begingroup\$ huh?! OP's question: 30 to 40-second, video files (~500 MB) Ah right, that's for the video duration, not the transmission duration. Well, but even so, 70Mb/s is not what you can rely on in WiFi. It's the exception, not the norm, because you use a shared medium in an unlicensed band. \$\endgroup\$ – Marcus Müller Mar 9 '17 at 14:10
  • \$\begingroup\$ We're aiming at under a minute. So a minute is still acceptable. The video material is 30 to 40 seconds, and its size is about 500 megabytes. Still reading everything :) Thanks for your answer! \$\endgroup\$ – Zimano Mar 9 '17 at 14:12
  • 1
    \$\begingroup\$ @MarcusMüller I agree that there will certainly be some RAM requirement. How much depends a lot on how the firmware is implemented. My thinking was that a MCU or CPU capable of the throughput would inherently have sufficient RAM, and that it is not the critical factor in my opinion. The clock and data processing speeds are the more relevant metrics here. \$\endgroup\$ – AngeloQ Mar 9 '17 at 15:01

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)

| improve this answer | |
  • \$\begingroup\$ The OP wrote 1min, not 30s. I agree it's high for WiFi but not impossible. A reason to design such a device oneself is if the minimal cost is desired and the production volume warrants it. \$\endgroup\$ – AngeloQ Mar 9 '17 at 14:13
  • \$\begingroup\$ Corrected the "impossible with Wifi",too. \$\endgroup\$ – Marcus Müller Mar 9 '17 at 14:15

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.