I'm (trying to) build a device that can receive and play/stream videos wirelessly to an embedded system. I wanted to know what would be the best course to take? If the ARM Cortex-M3 is a viable option for this, do I need a separate video controller with it? or can I use an alternative solution in the ARM family. (Also I understand that I am targeting a wide range of chips by simply saying Cortex-M3, I would like to know (if anyone else knows) whether I could through such a wide net or does it have to certain models)
Thanks!
Wow, that's an impressive analysis, at least of the abstract capability of a wide range of Cortex-M3 chips.
Please allow me to offer a couple specific examples. These are based on Cortex-M4 (Freescale Kinestis K20) running at 96 MHz. Minimal use of the DSP extensions was made, so you could probably expect similar performance from Cortex-M3 at about 100 MHz, assuming similar buses and DMA capability.
First, here's a LED panel project I made several months ago, displaying 30 Hz video at low resolution (90x48 pixels) and streaming 44.1 kHz (mono) audio.
LED Video Panel at Maker Faire 2014: Concept and Development
The video and audio data leverage the Kinetis eDMA engine. The uncompressed data is read from a SD card, in SPI mode, using polling for the SPI peripheral. Testing showed approx 50% CPU usage, mostly for the SPI data transfer.
A 320x240 SPI-interface display was mentioned. This is another place I've done significant optimization work. Here's a blog article, with a sample video:
Display & SPI Optimization | DorkbotPDX
As you can see in that article, simplistic software design for these displays results in slow performance, even with a fast CPU.
Above, a theoretical 32.5 Hz refresh rate was mentioned, based on the assumption of 50 MHz SPI clock. Since publishing that article, I've talked with others attempting similar optimization. Testing has shown many of those displays do not work reliably with 42 MHz clock speed. Reliable specs are hard to find, but some datasheets spec a maximum SPI clock of only 10 MHz. I have personally done a LOT of testing with 24 MHz SPI clock, but always while running the display at 3.3V (well above its minimum 2.2 or 2.4V), with good results.
If your video is compressed with any DCT-based algorithm, odds are slim a Cortex-M3 will be capable of decoding the data in real time at any significant resolution. Even just moving the bytes from a SPI port to RAM can take a lot of CPU time if DMA is not leveraged efficiently.
Cortex-M7, when chips appear in the 350 to 400 MHz range, might open up more possibilities. Maybe? As you can see, I actually do quite a bit of work on optimizing open source middleware. If anyone from ARM actually reads this message, please let me know when an updated v7m architecture reference manual is published?
paulstoffregen - Great to hear about other Cortex-M options! -Thank you for chipping in (eh, that was lame, wasn't it?)
Yes, I made a lot of assumptions in my answer above; that's true. I've personally used the 50MHz clock with my SPI display, which is a low-cost display module from China (you probably know already). -I must say that your library is definitely impressive. Note: I just cloned the sources and viewed them lightly. I think you may be able to improve on the character-output by drawing the characters vertically instead of horizontally - I did this in my own code.
The reason I think this is the case, is that there are much more adjacent pixels vertically than horizontally (well in my font anyway). Saving are most of the time when you move the window without resizing it.
x-627 - I think I forgot to mention that there are 8-bit parallel and 16-bit parallel displays available as well. If pushing things to the limit, I believe it would be possible to get a data rate of 8 bits per clock cycle on a 16-bit parallel display or 4 bits per clock cycle on an 8-bit parallel display, however, the display would most likely not be able to handle a clock rate that high. I'm not currently able to test this theory, but this particular setup will most likely require the SCT found in the LPC43xx or LPC541xx.