Which Microcontroller to choose for Ethernet and HDMI application?

[samy03]

Hi All,

I am looking for a micro-controller which can receive data from Ethernet through UDP (Multicast) and transmit the data to HDMI output with a HDMI transmitter IC.
As of now after some research I am leaning towards STM32F429ZI, as it has Ethernet capability and built-in LCD controller. On the Ethernet side STM32 does have lwIP library which can come in handy for receiving UDP. On the HDMI side I will use LCD controller pins of STM32, I will take the 24 bit RGB signal and will use an IC like SIl9022 as HDMI Transmitter to get HDMI output.
Is this something that will work or do I need to choose another micro-controller? I would really appreciate your suggestions.

Thank you

[llkiwi2006]

What kind of resolution and refresh rate do you want to be operating at? Micro-controllers are not the best at pushing high data rates.

If you budget and size allows, you could whack a raspberry pi in there (or even a pi zero with a external ethernet adapter).

[Yansi]

Your question is not well defined.  It can work but it also can't. It all depend on what you will be doing there.

The first question that comes in mind: What resolution do you expect at the HDMI and what framerate?  The 429ZI limits you to use only of 16bit SDRAM. That quite limits the available resolution and what can be done with the graphics.

[nctnico]

If the data comes in through the network in a raw format then the framerate is going to be limited anyway because you can't pump that much data over a network. I'm also wondering how you'd handle missing UDP frames.

[Kjelt]

My first question would be: what is the production number of units?
If it is below 1000 use a beaglebone or use the open HW schematics and BOM to design youw own version. It will save you bigtime on NRE costs.

[asmi]

The answer is likely "none". MCUs are not really designed for high bandwidth applications, you will need full-featured MPU or - even better - FPGA.

[cdev]

"Raspberry pi" + VLC ?

There will likely be a few hundred microseconds delay

I agree that the RPI Ethernet is likely to be problematic. Try getting a USB3 capable gigabit LAN adapter this will more than triple the RPI's lan speed but still be rate limited by the internal USB which maxes out at a total of around 480 MBPS for everything added up together.  On a machine with USB3 the same adapter will do full gigabit lan. On an RPI3 you should still get >200 MBPS in USB2 backwards compatibility mode.

[samy03]

From Ethernet I will just receive a text in my Multicast message, the text will then be displayed over HDMI in form of an image. So I am not sure how much bandwidth will be required for this. What do you guys think? I would like to have a good resolution display at least 720 or 1080p.

[mikeselectricstuff]

FPGA plus Wiznet W5500 to handle the Ethernet
or a rasPi/beaglebone/whatever which has pretty much all the hardware ready to go. Unless you're making thousands, that's going to be a lot cheaper

[Yansi]

Well, with a 32bit SDRAM on the STM32F429 it is possible to have 1024x768 output with still decent graphics, 1280x720 therefore it might be possible, but you are right at or slightly above the edge of what is sensible to do here.

For such application, if you insist upon doing a custom design with MCU, I would highly recommend switching for a beefier one, like STM32H7, that would cope with the HD resolution quite well.

[andersm]

From Ethernet I will just receive a text in my Multicast message, the text will then be displayed over HDMI in form of an image. So I am not sure how much bandwidth will be required for this.

Only as much as you have text to send, which I imagine is not very much? A Raspberry Pi sounds almost ideal for the job.

[ebclr]

Amlogic S912, Cortex A53

[Richard Crowley]

Yes, if you are simply receiving a "message" (a few hundred bytes?) and displaying an "image" (still?, animated? video of some framerate?) then a RaspberryPi (or one of the many similar commercial products) would seem ideally suited for both development and deployment.  Even a RasPi Zero would work well depending on the complexity (size) of the displayed images.

As has already been mentioned, the definition of several of your criteria, as well as the nature, economics, deployment details, etc. would influence this kind of decision.

I have a somewhat similar question, about identifying a commercial single-board controller with Ethernet and HDMI that is capable of implementing the NDI protocol (https://www.newtek.com/ndi/sdk/)  But that is actually streaming live, HD video.

[samy03]

I have tried beaglebone but I also had a HDMI switch using (TS3DV642) connected at the output, and due to some back EMF it kept shutting off my beaglebone and all the power leds on beagle would shut off until I disconnect my HDMI switch and then power it back on.

[samy03]

And beaglebone and raspberry pi does not have all the hardware I need. I also need to drive an LED Matrix, add POE, and HDMI switch. I would end up with a custom design anyways.

[mikeselectricstuff]

And beaglebone and raspberry pi does not have all the hardware I need. I also need to drive an LED Matrix, add POE, and HDMI switch. I would end up with a custom design anyways.

RasPi Compute module perhaps ?

[nctnico]

And beaglebone and raspberry pi does not have all the hardware I need. I also need to drive an LED Matrix, add POE, and HDMI switch. I would end up with a custom design anyways.

True but in case of the Beaglebone you can use the schematics to start your own circuit board (probably with chips in more friendly packages). Using seperate boards is asking for problems but it is a good way to put a demonstrator together.

[mikeselectricstuff]

Might be worth looking at the PIC32MZ DA - supports 24 bit up to 1280x1024 with onboard 32Mbyte DDR2, and up to 2M flash, plenty for high-res font storage.

http://www.microchip.com/design-centers/32-bit/architecture/pic32mz-da-family

[andersm]

And beaglebone and raspberry pi does not have all the hardware I need. I also need to drive an LED Matrix, add POE, and HDMI switch. I would end up with a custom design anyways.

You'll save everyone time and get better suggestions if you list all your requirements instead of dripfeeding them.

[samy03]

Okay so I'll be receiving text from Ethernet through UDP, which will be displayed on HDMI output in form of an image, and the HDMI Switch will also be connected at the HDMI output.
I will also receive a sound file through Ethernet which will be output on an Audio Jack connector for speakers.
I also have to drive an LED Matrix and display the data received from Ethernet. Plus the unit should also have POE. That's all!

[SiliconWizard]

The Raspberry Pi (and many similar boards) actually has GPIO's, SPI and I2C that you can control. Not really real-time, but for driving an LED matrix (which I suppose is some kind of display), it may prove more than adequate. Surely it's the fastest way of implementing what you described. The downside is, you may not like having to depend on (and bear the boot times of) a Linux OS. The upside, you'll get access to loads of libraries to implement nice GUIs with HDMI output, you'll get all the required drivers including Ethernet, and a lot of memory (RAM and Flash).

If you really need real-time control and/or more IO's, you could also develop a small MCU-based board that would handle the low-level stuff and communicate with the Pi (or some other SBC) through SPI or USB. Then all the higher-level stuff could be done on SBC's or even PC's, making it versatile.

As you have already been told, you won't find any MCU with an HDMI output. You'll find that on bigger CPU's along with a lot of RAM and an integrated graphics controller. Directly using those on a low-cost, low-volume project is just not doable in my opinion, hence the approach of getting a ready-made module.

You can find a whole range of MCU's with Ethernet controllers though, so there is another option yet, finding an external video module with HDMI output. I remember one from 4D Systems but with VGA output only: http://www.4dsystems.com.au/product/uVGA_III/ . It's not cheap though, and has limited resolution. Not sure if you can find any with HDMI output. Even if you do, it will probably not be cost-effective at all compared to a solution like a Pi Zero + a custom small MCU board.

[mikeselectricstuff]

Okay so I'll be receiving text from Ethernet through UDP, which will be displayed on HDMI output in form of an image, and the HDMI Switch will also be connected at the HDMI output.
I will also receive a sound file through Ethernet which will be output on an Audio Jack connector for speakers.
I also have to drive an LED Matrix and display the data received from Ethernet. Plus the unit should also have POE. That's all!

Build quantity ?

[samy03]

Probably around 200-300 per year.

[GeorgeOfTheJungle]

Okay so I'll be receiving text from Ethernet through UDP, which will be displayed on HDMI output in form of an image, and the HDMI Switch will also be connected at the HDMI output.
I will also receive a sound file through Ethernet which will be output on an Audio Jack connector for speakers.
I also have to drive an LED Matrix and display the data received from Ethernet. Plus the unit should also have POE. That's all!

An Orange Pi PC ($15 http://www.orangepi.org/orangepipc/ ) + Armbian (free) + node.js (free) can do all that very very well, piece of cake, and it's a one day job or two no more. But you don't mention if boot times of 10..15s are ok for your application.

[Yansi]

I can guarantee you it will not be a two day job.

[GeorgeOfTheJungle]

Ok, maybe three :-)

Driving the led matrix takes most of the time, all the other things can be done in high level languages with off the shelf linux command line utilities.

[Kjelt]

There night be another commercial requirement, if you use a raspbery pi your product can be copied/duplicated in a minute.

[mikeselectricstuff]

There night be another commercial requirement, if you use a raspbery pi your product can be copied/duplicated in a minute.

But someone could duplicate the functionality with a Raspi anyway.
You could always throw a USB dongle onto it, or encrypt/serialise the software using the Pi's unique serial no.

[Kjelt]

True, just saying there might be some more effort required if you use the standard emb. Linux boards.
I also wonder because there are tens of internet audio streaming devices already on the market that there are some possible patent infringemenrs involved, for your own project not a problem but a commercial project selling hundreds a year ...........

[Aodhan145]

A beaglebone is probably the simplest idea, ethernet can receive the display data and can be displayed over hdmi. The internal PRU core can be used to control the led matrix.

[GeorgeOfTheJungle]

There's plenty of power in four cores though, in an orange pi, and it's notably cheaper than the others.

[GeorgeOfTheJungle]

Why use HDMI to send text when- er.. ssh will do?

To display text "in form of an image" I think it is.

[samy03]

The reason I can't go with Raspberry pi or Orange pi is that I have to depend on seller to supply me the boards rather than me getting my custom boards built whenever I want. I can't even get the microprocessors in those units from digikey or mouser.
I think Beaglebone black is a better option where I can use it for prototyping and later I can design a custom board because of the availability of chip.

[Jeroen3]

Beware, these chips aren't for sale for long periods. They're replaced quickly.

[mikeselectricstuff]

The reason I can't go with Raspberry pi or Orange pi is that I have to depend on seller to supply me the boards rather than me getting my custom boards built whenever I want. I can't even get the microprocessors in those units from digikey or mouser.
I think Beaglebone black is a better option where I can use it for prototyping and later I can design a custom board because of the availability of chip.

That's what the RasPi compute module is for. They say it will be in production until at least 2023

[samy03]

That's what the RasPi compute module is for. They say it will be in production until at least 2023

Again with RasPi compute I have to depend on the seller. I can not just make my own version of RasPi compute. The company I am working for will probably need this product for more than 5 years.

[nctnico]

That's what the RasPi compute module is for. They say it will be in production until at least 2023

Again with RasPi compute I have to depend on the seller. I can not just make my own version of RasPi compute. The company I am working for will probably need this product for more than 5 years.

I agree. Don't use modules. I'm using a module in a product for a customer because they insisted on doing so but meanwhile the module got like 40% more expensive and the manufacturer already tried to make it obsolete. A full custom design would have been cheaper for the customer.

[mikeselectricstuff]

That's what the RasPi compute module is for. They say it will be in production until at least 2023

Again with RasPi compute I have to depend on the seller. I can not just make my own version of RasPi compute. The company I am working for will probably need this product for more than 5 years.

I agree. Don't use modules. I'm using a module in a product for a customer because they insisted on doing so but meanwhile the module got like 40% more expensive and the manufacturer already tried to make it obsolete. A full custom design would have been cheaper for the customer.

All depends on the volumes. Do you really want to get into DDR3 routing etc.?
A compute module would easily go on a 4L PCB with a good chance of working first time for a day or two's PCB layout work.
If the volumes increase, redesign then. 

Anything you design in today could easily go obsolete in 5 years.

[Dubbie]

I did a very similar project using a raspi compute module for hdmi and Ethernet and everything else ran on a normal stm32F4 because it was easier for me to get real-time constraints working on that rather than the pi.

[GeorgeOfTheJungle]

The reason I can't go with Raspberry pi or Orange pi is that I have to depend on seller to supply me the boards rather than me getting my custom boards built whenever I want. I can't even get the microprocessors in those units from digikey or mouser.
I think Beaglebone black is a better option where I can use it for prototyping and later I can design a custom board because of the availability of chip.

For the price of a beaglebone you get 4 Orange Pis IIANM. And the OPi price can only go down, because sooner or later a new model will appear that's as good but even cheaper. Consider the OPi a component, your job is the software, it's quite easy to port the software from an OPi to a RasPi or a beaglebone or whatever, so you're not vendor-locked, no, not at all.

[mikeselectricstuff]

The reason I can't go with Raspberry pi or Orange pi is that I have to depend on seller to supply me the boards rather than me getting my custom boards built whenever I want. I can't even get the microprocessors in those units from digikey or mouser.
I think Beaglebone black is a better option where I can use it for prototyping and later I can design a custom board because of the availability of chip.

For the price of a beaglebone you get 4 Orange Pis IIANM. And the OPi price can only go down, because sooner or later a new model will appear that's as good but even cheaper. Consider the OPi a component, your job is the software, it's quite easy to port the software from an OPi to a RasPi or a beaglebone or whatever, so you're not vendor-locked, no, not at all.

That is rarely a viable option for a product in series production - any change will need re-validation, maybe different cabling, mounting holes etc.  And of course software changes. Then you have to deal with different variants in the field, different software updated for different versions, issues for field service replacement etc. The initial cost of the module can be negligible compared to the long-term cost of a bad decision.
Beagleboard and Raspi are established enough to have reasonable chance of being there long-term in sufficiently similar form. anything pitched as a bargain-basement product will inevitably have questionable  longevity as the manufacturer cares more about price than continuity of supply or compatibility.

[GeorgeOfTheJungle]

That is rarely a viable option for a product in series production - any change will need re-validation, maybe different cabling, mounting holes etc.  And of course software changes. Then you have to deal with different variants in the field, different software updated for different versions, issues for field service replacement etc. The initial cost of the module can be negligible compared to the long-term cost of a bad decision.
Beagleboard and Raspi are established enough to have reasonable chance of being there long-term in sufficiently similar form. anything pitched as a bargain-basement product will inevitably have questionable  longevity as the manufacturer cares more about price than continuity of supply or compatibility.

I got my first OPi PC in 2015, it's well built, stable, rock solid and still available in 2018, I got my first RasPi in 2012 and it's no longer available and I've had to go thru 5 new versions or so, most of which are no longer available. The newer rpi 3s are not fully compatible with previous ones, and the wifi and BT does not work well/reliably. The power supply circiut has always been a disaster (fixed in rpi3). Ethernet and USB I/O througput is another disaster. Etc, etc. The RasPi was first but is easily the worse af all these sbcs imho.

Read udp from ethernet, create an image with text, display thru hdmi, play some audio, all these things can be done with off-the-shelf Linux software very easlily and be portable, only the led matrix is somewhat more tricky and non standard but even that can be portable if reduced to an app to send/receive via i2c or serial or spi.

If "orange pi inc" ever goes to hell it won't matter, just compile/setup everything on/for an olimex, odroid, bananapi, nanopi, tinkerboard, pcduino, whatever (see https://www.armbian.com/download/ ) and you're done.

At least that's what I honestly believe.

[mikeselectricstuff]

If "orange pi inc" ever goes to hell it won't matter, just compile/setup everything on/for an olimex, odroid, bananapi, nanopi, tinkerboard, pcduino, whatever (see https://www.armbian.com/download/ ) and you're done.

That's easy enough to say, but for a production thing even the slightest change can be a major headache for all sorts of reasons. 
"Just compile/setup" can turn into a huge engineering headache and cost a lot of time & money. More so if the people who implemented it aren't still around. Not to mention any re-approvals issues (EMC at least).

[nctnico]

That's what the RasPi compute module is for. They say it will be in production until at least 2023

Again with RasPi compute I have to depend on the seller. I can not just make my own version of RasPi compute. The company I am working for will probably need this product for more than 5 years.

I agree. Don't use modules. I'm using a module in a product for a customer because they insisted on doing so but meanwhile the module got like 40% more expensive and the manufacturer already tried to make it obsolete. A full custom design would have been cheaper for the customer.

All depends on the volumes. Do you really want to get into DDR3 routing etc.?
A compute module would easily go on a 4L PCB with a good chance of working first time for a day or two's PCB layout work.
If the volumes increase, redesign then. 

Anything you design in today could easily go obsolete in 5 years.

That chance is higher when using a module then a SoC with a guaranteed availability of 10 to 15 years. For a volume between 100 to 200 pieces it already makes sense to go full custom. Remember you don't have to re-invent the wheel because you can use existing boards as a reference design besides the extensive high-speed routing guidelines which typically come with a SoC. I'm not saying it is copy and paste but it is pretty darn close: read the manual, follow the recipe and use common sense (been there & done that for other projects).

Another problem with modules is that you will probably be dealing with high speed interconnects for PCIexpress, LVDS, USB, ethernet, Sata, MIPI, etc for which the usual module connectors (intended for memory) are not very suitable to begin with.

[GeorgeOfTheJungle]

If "orange pi inc" ever goes to hell it won't matter, just compile/setup everything on/for an olimex, odroid, bananapi, nanopi, tinkerboard, pcduino, whatever (see https://www.armbian.com/download/ ) and you're done.

That's easy enough to say, but for a production thing even the slightest change can be a major headache for all sorts of reasons. 
"Just compile/setup" can turn into a huge engineering headache and cost a lot of time & money. More so if the people who implemented it aren't still around. Not to mention any re-approvals issues (EMC at least).

Sure, shit happens, but, come on, what he wants isn't rocket science, most of it can be done this way in ~ no time, and that counts too, no?

For example, to get udp it's only a few lines of javascript for node.js (done in minutes, literally). To put the image on the screen thru hdmi perhaps a .sh with some parameters will do. Ditto to play a .snd. Etc. All very easy and portable, piece of cake... can be done this way because $15 buys you a Linux with GBs of RAM and 4 cores at 1.x GHz that can do these things in ms and because most needs have already been thought and done by somebody else and are ready to be apt-get install-ed for you to use without having to develop them again. Except the led matrix driver.

[Richard Crowley]

It seems to me that the only things here that seem at all "custom" are

• The "LED matrix" driver (undefined?)
• The HDMI switch

All the other requirements can be done with generic, commodity components:

• receive data from Ethernet through UDP (Multicast)
• create image and send to HDMI output
• receive a sound file through Ethernet
• output sound file on an Audio Jack connector for speakers
• control LED matrix driver
• control HDMI switch
• POE

If you are really worried about long-term viability, designing a custom board with everything is no more of a "sure thing" than using a commodity micro-controller board (RasPi, et.al.)  Consider that any critical component (the microcontroller, the HDMI switch, etc.) could go extinct in the middle of your product life-cycle and you would have to re-design your custom board around a replacement.

OTOH, developing the "LED Matrix" driver and HDMI switch as basic, board-level I2C peripherals would mean that you could use ANY available microcontroller board and simply maintain the application as essentially a software solution.

[Dubbie]

let me know if you find an HDMI switch IC that a hobbiest can buy.

I tried for a while and got nowhere. Ended up just using a generic aliexpress board and patching into the i2C lines to control it

[samy03]

let me know if you find an HDMI switch IC that a hobbiest can buy.

I tried for a while and got nowhere. Ended up just using a generic aliexpress board and patching into the i2C lines to control it

I am using TS3DV642, and its costs $1.64

[Dubbie]

Thanks for taking the time to post that Samy. Unfortunately not quite what I am after. I need 4>1 with audio de-embed. Because of the audio requirement, that opens HDCP and HDMI licensing cans galore.

[SiliconWizard]

Hi again,

I think we all kind of overlooked the solution you were initially suggesting. I didn't know the SiI9022.
More info there: http://www.latticesemi.com/en/Products/ASSPs/MobileHDMITransmitters.aspx
Looks like we need to contact sales to get ahold of the datasheet? So it's hard to give very informed feedback on this solution.

Just a couple things that might be a problem:

• The STM32F429's LCD controller supports up to XGA resolution. The SiI9022 is advertised for full hd (1080p) resolution. I have no idea if it supports other resolutions and/or can do scaling, but I suspect it may not. I that case, it won't work. You may have more info on that though, if you have the datasheet, let us know.
• I've never used the STM32F4 series LCD controllers. I don't know exactly what can be done with them. XGA resolution (1024x768) in 24-bit RGB would require a 2.25 MBytes framebuffer, and surely the STM32F4 uCs don't have that kind of embedded RAM to begin with, so I wonder if the LCD controller is not supposed to be used with LCD panels with integrated controllers/framebuffers. And I would guess the SiI9022 would need a "scanline", 24-bit output. Not sure this is what the STM32F4 provides. You really have to check.

Again, I don't have enough info on SiI9022 and have not dug enough into the STM32F4 series LCD controllers, so this could very well work, but those are at least points to consider before diving into this.

On top of that, since you are cautious about long-term availability, I'm not sure how long the SiI9022 is supposed to be supported by Lattice.

One option if you still want this kind of architecture with less dependency on supply and more flexibility on specs would be to use an FPGA for the HDMI part, and either write your own controller or use existing IPs.

[samy03]

Hi again,

I think we all kind of overlooked the solution you were initially suggesting. I didn't know the SiI9022.
More info there: http://www.latticesemi.com/en/Products/ASSPs/MobileHDMITransmitters.aspx
Looks like we need to contact sales to get ahold of the datasheet? So it's hard to give very informed feedback on this solution.

Just a couple things that might be a problem:

• The STM32F429's LCD controller supports up to XGA resolution. The SiI9022 is advertised for full hd (1080p) resolution. I have no idea if it supports other resolutions and/or can do scaling, but I suspect it may not. I that case, it won't work. You may have more info on that though, if you have the datasheet, let us know.
• I've never used the STM32F4 series LCD controllers. I don't know exactly what can be done with them. XGA resolution (1024x768) in 24-bit RGB would require a 2.25 MBytes framebuffer, and surely the STM32F4 uCs don't have that kind of embedded RAM to begin with, so I wonder if the LCD controller is not supposed to be used with LCD panels with integrated controllers/framebuffers. And I would guess the SiI9022 would need a "scanline", 24-bit output. Not sure this is what the STM32F4 provides. You really have to check.

Again, I don't have enough info on SiI9022 and have not dug enough into the STM32F4 series LCD controllers, so this could very well work, but those are at least points to consider before diving into this.

On top of that, since you are cautious about long-term availability, I'm not sure how long the SiI9022 is supposed to be supported by Lattice.

One option if you still want this kind of architecture with less dependency on supply and more flexibility on specs would be to use an FPGA for the HDMI part, and either write your own controller or use existing IPs.

If not Sil9022, then I will use TDA19988BHN, as this model of TDA19988 does not have HDCP and will not require any licensing.

[cdev]

This is an interesting data point!

https://blog.danman.eu/new-version-of-lenkeng-hdmi-over-ip-extender-lkv373a/

also:

https://www.youtube.com/watch?time_continue=1600&v=SAvGylthpkU

[NiHaoMike]

There exist advanced HDMI switches that support text overlay and even picture in picture. Not sure where to find one that has a public datasheet.

[mikeselectricstuff]

I've never used the STM32F4 series LCD controllers. I don't know exactly what can be done with them. XGA resolution (1024x768) in 24-bit RGB would require a 2.25 MBytes framebuffer, and surely the STM32F4 uCs don't have that kind of embedded RAM to begin with.

Again, look at the PIC32MZ DA - it has 32MBytes onboard specifically for this sort of application.

One option if you still want this kind of architecture with less dependency on supply and more flexibility on specs would be to use an FPGA for the HDMI part, and either write your own controller or use existing IPs.

Yes - Spartan6 will do HDMI natively. You could use the Wiznet W5500 to simplify the networking side of things.
You'd still have to add RAM for a framebuffer, though if it was purely text you may be able to renderfont data on the fly to avoid the need for a full pixel buffer

[samy03]

I think I am gonna go with AM335x series and use Beaglebone Black as a development board for Embedded Linux. I know Embedded Linux is going to be a challenge for a person like me who has always worked on 8/16 bit micro-controllers, but I am willing to tackle it and step up my game!

I am also looking for Embedded Linux training classes/workshops, so any suggestions would be greatly appreciated!

[rsjsouza]

There are a few training resources online for this with varying degrees of quality.

One resource (Udemy) that some folks around here tend to consider highly is below:
https://www.udemy.com/embedded-linux-step-by-step-using-beaglebone/

(I am not affiliated to the company above)

Another resource from one of the "owners" of the BeagleBone is below, but it is a bit more applications oriented instead of a step-by-step method:
https://www.element14.com/community/docs/DOC-78585/l/beaglebone-black-webinar-series

[Kjelt]

Buy some books, there is one for the Beagle from Derek Molloy and this one should also be pretty good:
https://www.amazon.com/Mastering-Embedded-Linux-Programming-potential/dp/1787283283/

[samy03]

Thanks guys! I will check em out