Which Microcontroller to choose for Ethernet and HDMI application?

#25 Reply
Posted by GeorgeOfTheJungle on 03 Jan, 2018 00:21
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.

#26 Reply
Posted by Kjelt on 03 Jan, 2018 00:41
There night be another commercial requirement, if you use a raspbery pi your product can be copied/duplicated in a minute.

#27 Reply
Posted by mikeselectricstuff on 03 Jan, 2018 00:45
Quote from: Kjelt on 03 Jan, 2018 00:41
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.

#28 Reply
Posted by Kjelt on 03 Jan, 2018 00:50
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 ...........

#29 Reply
Posted by Aodhan145 on 03 Jan, 2018 00:52
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.

#30 Reply
Posted by GeorgeOfTheJungle on 03 Jan, 2018 01:28
There's plenty of power in four cores though, in an orange pi, and it's notably cheaper than the others.

#31 Reply
Posted by GeorgeOfTheJungle on 03 Jan, 2018 01:31
Quote from: cdev on 03 Jan, 2018 01:21
Why use HDMI to send text when- er.. ssh will do?

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

#32 Reply
Posted by samy03 on 03 Jan, 2018 15:26
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.

#33 Reply
Posted by Jeroen3 on 03 Jan, 2018 15:29
Beware, these chips aren't for sale for long periods. They're replaced quickly.

#34 Reply
Posted by mikeselectricstuff on 03 Jan, 2018 16:11
Quote from: samy03 on 03 Jan, 2018 15:26
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

#35 Reply
Posted by samy03 on 03 Jan, 2018 16:31
Quote from: mikeselectricstuff on 03 Jan, 2018 16:11
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.

#36 Reply
Posted by nctnico on 03 Jan, 2018 18:07
Quote from: samy03 on 03 Jan, 2018 16:31
Quote from: mikeselectricstuff on 03 Jan, 2018 16:11
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.

#37 Reply
Posted by mikeselectricstuff on 03 Jan, 2018 18:39
Quote from: nctnico on 03 Jan, 2018 18:07
Quote from: samy03 on 03 Jan, 2018 16:31
Quote from: mikeselectricstuff on 03 Jan, 2018 16:11
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.

#38 Reply
Posted by Dubbie on 03 Jan, 2018 19:52
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.

#39 Reply
Posted by GeorgeOfTheJungle on 03 Jan, 2018 21:32
Quote from: samy03 on 03 Jan, 2018 15:26
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.

#40 Reply
Posted by mikeselectricstuff on 03 Jan, 2018 21:48
Quote from: GeorgeOfTheJungle on 03 Jan, 2018 21:32
Quote from: samy03 on 03 Jan, 2018 15:26
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.

#41 Reply
Posted by GeorgeOfTheJungle on 03 Jan, 2018 22:37
Quote from: mikeselectricstuff on 03 Jan, 2018 21:48
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.

#42 Reply
Posted by mikeselectricstuff on 03 Jan, 2018 22:46
Quote from: GeorgeOfTheJungle on 03 Jan, 2018 22:37

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).

#43 Reply
Posted by nctnico on 03 Jan, 2018 23:05
Quote from: mikeselectricstuff on 03 Jan, 2018 18:39
Quote from: nctnico on 03 Jan, 2018 18:07
Quote from: samy03 on 03 Jan, 2018 16:31
Quote from: mikeselectricstuff on 03 Jan, 2018 16:11
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.

#44 Reply
Posted by GeorgeOfTheJungle on 03 Jan, 2018 23:25
Quote from: mikeselectricstuff on 03 Jan, 2018 22:46
Quote from: GeorgeOfTheJungle on 03 Jan, 2018 22:37

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.

#45 Reply
Posted by Richard Crowley on 03 Jan, 2018 23:52
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.

#46 Reply
Posted by Dubbie on 04 Jan, 2018 02:15
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

#47 Reply
Posted by samy03 on 04 Jan, 2018 15:27
Quote from: Dubbie on 04 Jan, 2018 02:15
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

#48 Reply
Posted by Dubbie on 05 Jan, 2018 11:20
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.

#49 Reply
Posted by SiliconWizard on 05 Jan, 2018 14:56
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.