How to cost effectively use a small linux system in a product?

[langwadt]

sorry, but YOUR post is nonsense.

there are LTS (long term support) platforms that you can buy for industrial use.  and those are HELLA expensive and also become old very fast.  they also tend not to be linux platforms.  who is going to support embedded linux for more than a few years on the same 'distro'?  it does not happen that way.

you get QNX or something like that for long-term embedded use.  or some other RTOS.  its almost never linux.

I still stand by my advice: de-couple the linux host from the rest of the system, loosely couple them and have the freedom to pick the next big linux board when it comes out.  integrating too much (to moving targets) is a rathole that wise designers should avoid completely.

besides, who wants to run linux on a platform that is 10 yrs old???  not me!  and there's little reason to have to, if you decouple the 'boxes' properly.

most embedded systems never gets upgraded, so why would long term support, and distro matter? you do it once and that's it
I have severals scope, logic analysers, signal generators etc. they all run some OS, un*x, windows, propriatary, doesn't really
matter they will  never be upgraded

[linux-works]

if it connects to the network at all, you BETTER have a good update story!

not talking about features, but security and bug fixes.

you think embedded code is perfect the day its shipped and deployed?

ha!

updates are important no matter what the system is.  more so if its a complex system like linux. 

[nctnico]

sorry, but YOUR post is nonsense.

there are LTS (long term support) platforms that you can buy for industrial use.  and those are HELLA expensive and also become old very fast.  they also tend not to be linux platforms.  who is going to support embedded linux for more than a few years on the same 'distro'?  it does not happen that way.

Actually it does happen that way. It's just stubborn programmers who always want the latest & greatest because they think it is better because what was written yesterday is obsolete and completely broken. With some care you can support a custom (buildroot) linux distribution for many years. There is no technical reason why that cannot be achieved.

I see no difference between MCU firmware which needs an update due to an obscure bug or a piece of software running on a Linux platform which needs an update for the same reason. Either way you need to retain the programming environment and associated hardware for as long as the products have to be serviced. Maybe that way of thinking is more natural to people supporting MCU firmware.

[oohal]

sorry, but YOUR post is nonsense.

there are LTS (long term support) platforms that you can buy for industrial use.  and those are HELLA expensive and also become old very fast.  they also tend not to be linux platforms.  who is going to support embedded linux for more than a few years on the same 'distro'?  it does not happen that way.

Actually it does happen that way. It's just stubborn programmers who always want the latest & greatest because they think it is better because what was written yesterday is obsolete and completely broken. With some care you can support a custom (buildroot) linux distribution for many years. There is no technical reason why that cannot be achieved.

I see no difference between MCU firmware which needs an update due to an obscure bug or a piece of software running on a Linux platform which needs an update for the same reason. Either way you need to retain the programming environment and associated hardware for as long as the products have to be serviced. Maybe that way of thinking is more natural to people supporting MCU firmware.

There's a bit of a difference in scale. Even complex bits of firmware will have a relatively small code base compared to the linux kernel, core userland and whatever other packages you want to use. Rolling your own distribution and freezing it at release is something you can do, but there's a lot of code that needs maintaining and community support in the form of back ported security patches is going to disappear entirely after a few years. You're right about there being no technical reasons it can't be done, but the additional maintenance burden is something to consider.

[nctnico]

It depends on what kind of software you are running and how things are (cleverly) configured. For a typical networked embedded  Linux device you can ignore 99.99% of the security patches because they won't affect the device at all.

[janoc]

linux embedded platforms change too fast (too many new ones come out and old ones get EOLd quickly) - so I would not recommend embedding linux IN a product.

Nonsense. Lots of ARM SoCs from TI and Freescale will be available for at least 10 years.

I think you are not talking about the same thing, guys.

Linux-works is talking about Linux boards (i.e. something like Raspberry Pi, Beaglebone, Gumstix ...) and those do, indeed, change quickly.

Nctnico, you are talking about SoCs - that is by far not the same thing. Someone who is capable of implementing a pre-made module like a Beaglebone into a product may not be capable of actually developing one with a bare SoC (or it may not make economic sense because of low volume).

Reacting to the OPs issues, there is nothing wrong with embedding Linux in a product - it is pretty much the same as embedding any other OS, be it VxWorks or Windows CE, there is quite a bit of support and documentation for it too. It is the same as with everything else - either you have the money to pay for the work to be done (hire an engineer, subcontract it, etc) or you must have the time to learn to do it yourself. Not willing to learn and wanting to have things cheap/for free is pretty much a killer combo for any project

If you need the high-level capabilities provided by the OS, by all means, go for it. However, then you better design your own board around some SoC too, depending on an external vendor for the CPU modules is probably not a good strategy long term. On the other hand, if your design can be handled by an MCU, then using Linux is likely not going to bring you many benefits, only extra complexity you don't really need as you aren't using the capabilities of the high level OS anyway (multithreading/processing, UI, networking, USB support, SATA support, etc.)

[janoc]

<rant mode, sorry..>

"all bugs are shallow, given enough eyeballs"

If you know how to design the analog parts of the system, and interface that to the computer, and you are willing to sell cheaply or give away prototypes to software developers - then I'm guessing the software issues will solve themselves.

IMO any new open-hardware effort should place as much as possible/reasonable of the design in software (c/python code on the linux machine, or perhaps HDL on an FPGA, or C code on a microcontroller) - so that developing the product becomes a software problem. You then solve that by placing it in the hands of enough talented and motivated developers.

Sorry, that's just nonsense. Unfortunately, way too common misconception about how open source works 

Company designs a gizmo, doesn't want to pay for software development, so they ship the gizmo with basic, unusable software and then cook up a half-baked SDK and throw it out "to the wolves", hoping that the software just "gets written" by someone for them. And then they are surprised that it is an utter failure.

Sorry, it doesn't work like that. First and foremost, most people buy the gizmo because they, surprise, want to use it, not to first make it work, especially if there are other products that actually do work without having to do crazy stuff first. Not many people buy cars without engines either.

Open source requires two things - interest in your product and established community. Establishing and nurturing a community is much more work than just publishing a crappy SDK and then hoping that the users sort it out for themselves. It actually needs that the company actively works with their users/customers, isn't hostile to outside development in the name of IP protection and that it has some reasonable foundation to build on. Only then things may actually happen that will be beneficial to the company as well, beyond the sale of the gizmos.

[nctnico]

linux embedded platforms change too fast (too many new ones come out and old ones get EOLd quickly) - so I would not recommend embedding linux IN a product.

Nonsense. Lots of ARM SoCs from TI and Freescale will be available for at least 10 years.

I think you are not talking about the same thing, guys.

Linux-works is talking about Linux boards (i.e. something like Raspberry Pi, Beaglebone, Gumstix ...) and those do, indeed, change quickly.

There are plenty of vendors which have long term (10 years) availability for SoC based modules. Raspberry Pi isn't one of them ofcourse but the cost of a module with long term availability isn't going to break the bank.

[janoc]

There are plenty of vendors which have long term (10 years) availability for SoC based modules. Raspberry Pi isn't one of them ofcourse but the cost of a module with long term availability isn't going to break the bank.

Any examples? No, I mean it - I am seriously interested in that. Most vendors I have seen change their portfolio quite often and you would be hard-pressed to find a replacement board for a 5 year old product, unless it is something that was sold in huge volumes.

[nctnico]

DirectInsight for example.

[donotdespisethesnake]

A pretty good range of realistic opinions here. I think there is a valid debate over the most effective way of deploying an embedded Linux, but the general consensus seems to be that an off the shelf Linux board like RPi is doable, any custom solution is likely to involve significant skills and effort, and not necessarily significantly cheaper.

I think I would favour KISS approach, use as much off the shelf stuff at least until it is shown there is demand for what could be a quite specialist product.

I'd like to hear back from the OP to know what they think of the options presented.

[janoc]

DirectInsight for example.

Thanks, that looks exactly like what I was looking for.