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

[rwgast_lowlevellogicdesin]

Ive really been thinking about building an open source low price (hopefully under 200 dollar) bench multi tool, source measurement type thing. I want to build a a nice linear precision multi channel, current limiting, power supply along with with a precision constant current source and current sync in the same box. I then want to add a meter (maybe even with an RMS chip) capable of doing milliohms and microvolts. Basically these are tools I find myself needing all he time and have built different quick and dirty versions of them as stand alone tools in the past when needed to measure another project.

I figured it would be nice to stick it all in a nice 8x8x8 metal box with a 5 inch or greater screen. As a prototype I would probability use a Raspberry Pi or Beagle bone to drive the LCD and do fast number crunching to do source measurement analyzation functions. The thing is if I can pull this off with the precision I want at a decent price I think it would make a great tool for hobbyists and a much better value than a cheap $200 atten PSU. I would defiantly want to crowd source it and try to start up a business making them.

My issue is what to do about the RasPi in it? Obviously a raspberry pi is to expensive to go shoving in to a problem targeted to a low price point. I know there are manufactures out there like ST and Atmel doing ARM SOCs that can run linux. This seems like it would be awfully hard, you would have to roll your own linux distro and learn something like U-Boot. So is there a simple way one can put together there own small arm computer running linux that doesn't require a deep knowledge of the inter workings of the os and boot loader?

[baruch]

I don't know the market of cheap ARM CPUs to offer an advice there but I do have a question lead.

How much cheaper would any other fully boarded Linux system will you? I believe $35 for the Raspberry Pi 2 would give you plenty of processing power, ease of development and an ecosystem you can draw on that no other chip will do. The rest of your design doesn't seem like  very cheap thing anyway so it's not like the RPi will double the price of the final product.

[JVR]

Not to be that guy, but do you really believe it is a good idea to place a component in a design you want to sell (and therefore have to support from top to bottom) when you say things like:

This seems like it would be awfully hard, you would have to roll your own linux distro and learn something like U-Boot.

What happens when something in your application code ruins the lower laying OS? How will you support that?  This sort of approach is fine if you want to build one for yourself, but to use it as a basis of a product of not a good idea.

[Stonent]

Well there is the core version of the raspberry pi that fits into a laptop dimm slot connector. It's cheaper but you'd need to make a slot for it, or use the premade ones, but that would cost more than they would normally.

[donotdespisethesnake]

So is there a simple way one can put together there own small arm computer running linux that doesn't require a deep knowledge of the inter workings of the os and boot loader?

As you said simple and also cheap, short answer is no.

If a RPi is too expensive, I wonder about the cost model. Building your own Linux board in small Q would probably be a lot more expensive than an RPi. RPi have shipped millions of units, and rumour has it that it's a "loss leader" for Broadcom.

The cost of the RPi also effectively includes a whole bunch of bundled software, so isn't it worth $20 just for that? You'd have to sell a LOT of units before recouping development costs if you roll your own kernel.

There are plenty of other small Linux boards around, but really nothing comparable to RPi at $35.

If you want cheaper, then I think a Cortex M4 with a TFT might be doable, if you don't need network, disk, USB host, Python etc. Would be a fair amount of software development, unless e.g you use off the shelf graphics package.

[Ice-Tea]

Cortex M4 lacks the memory controller, which makes linux porting a *lot* less straightforward.

[miguelvp]

https://www.olimex.com/Products/OLinuXino/open-source-hardware

Might have what you need

Edit: of course there are others like:
http://www.seco.com/

with QSeven modules

And many more of course.

[Rasz]

You can go down to $12 per module (in moderate bulk) with MIPS platforms running openWRT

http://www.asiarf.com/Smallest-Tiny-Ralink-802-11n-Wireless-AP-Router-Module-Board-AWM002-product-view-375.html

[awallin]

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

This is an over-simplification for sure, but I hope you get my point. If you want to keep everything closed-source, and develop the whole thing by yourself to completion before release - then you are on your own and indeed it's quite rare to find this much talent/knowledge in one person - that's why open-hardware projects ideally should be be collaborations between people with different skills.

[Howardlong]

I did some work a couple of years ago on an OpenWRT MIPS based OEM board for a new product. Initially it seemed the obvious way to go, much of what was needed was already there, the board was cheap as chips, certainly cheaper than I could make it. The bad news came as I ended up diving deeper and deeper into the code and hardware, and after two or three weeks it became clear this was not going to be the way forward for the product.

There were bugs in the USB host code specific to MIPS for example, that I fixed, although getting the code accepted back into the builds was not straightforward, so I'd end up with a branch of code anyway for at least some time, something which makes future maintenance a PITA. In the end I documented the changes publicly so others finding similar problems could readily look up the fix.

The documentation and hardware support for the underlying chip itself was somewhat lacking too, making device driver implementation very difficult, for example I was attempting to use the hardware I2S functionality, and there was pretty much no documentation available for it, which is probably why it hadn't already been included in the OpenWRT build.

In addition there is so much extra baggage when you use Linux in such a device it makes low power battery powered operation really difficult to implement.

One further point on using embedded Linux in any device is that you need to be mindful that you're frequently building stuff on a continually moving platform, especially if it's on a new device, which these days if it's not new, it's not cool anyway! That includes not just the distribution source code for your underlying device, but also the toolchains, so it often feels like trying to build a house on quicksand. While this is not unique to embedded Linux, the same is true, for example, with Qt, where something you compiled a year or so perfectly well will no longer compile as things become deprecated or "improved". I wonder just how many of,us have struggled to get a working toolchain to build an RPi kernel, particularly back in the early days?

In the end I went for a roll-your-own solution, and while it wasn't any cheaper in BOM cost, it did allow for a battery powered solution with reasonable battery life in a small form factor, and the development environment has thankfully remained fairly static.

I am certainly not discounting Linux for embedded systems, far from it, but it is going to be a compromise at the end of the day, Linux brings an awful lot of baggage with it, and while that can be a benefit in that you have nice high level languages available to you, it does make it difficult to implement low power devices. Using Linux to blink an LED seems rather perverse, however the line blurs when you start needing even quite simple GUIs for example.

[rollatorwieltje]

We use linux on several products, on ARM and PowerPC.

When you decide to use a linux distribution you really need a supplier that can support it. Up until now every Linux target we used had it's quirks, ranging from barely functional drivers to incorrect processor configuration causing lockups. If you are not intimately familiar with the SoC and Linux this is a pain to fix yourself.

[zapta]

Why do you need unix? The product description in your post matches a straight forward MCU solution.

[Howardlong]

We use linux on several products, on ARM and PowerPC.

When you decide to use a linux distribution you really need a supplier that can support it. Up until now every Linux target we used had it's quirks, ranging from barely functional drivers to incorrect processor configuration causing lockups. If you are not intimately familiar with the SoC and Linux this is a pain to fix yourself.

I certainly can't disagree with any of that. The innate complexity of Linux means that you pretty much have little choice but to segregate responsibilities, there's just too much for one person to do, to do both the hardware and the firmware, and the firmware guy really needs to know the distribution well.

[nctnico]

We use linux on several products, on ARM and PowerPC.

When you decide to use a linux distribution you really need a supplier that can support it. Up until now every Linux target we used had it's quirks, ranging from barely functional drivers to incorrect processor configuration causing lockups. If you are not intimately familiar with the SoC and Linux this is a pain to fix yourself.

I certainly can't disagree with any of that. The innate complexity of Linux means that you pretty much have little choice but to segregate responsibilities, there's just too much for one person to do, to do both the hardware and the firmware, and the firmware guy really needs to know the distribution well.

That depends on the knowledge of the person and the amount of time. I have done the hardware and software for several embedded Linux projects. Getting into embedded Linux does take a huge amount of time though. You need to know the kernel and bootloader inside out. Setting up the toolchain is another hurdle but nowadays you can install a generic Linux distro and compile on the target itself. OTOH that makes having a read-only root filesystem tricky.

[andyturk]

That depends on the knowledge of the person and the amount of time. I have done the hardware and software for several embedded Linux projects. Getting into embedded Linux does take a huge amount of time though. You need to know the kernel and bootloader inside out. Setting up the toolchain is another hurdle but nowadays you can install a generic Linux distro and compile on the target itself. OTOH that makes having a read-only root filesystem tricky.

Aside from development hurdles, what about power consumption? If your device is battery powered, how much more mW does Linux cost compared to an off-the-shelf RTOS or just bare metal? I think these kind of tradeoffs are being made more often in products that need features not present on Cortex-M processors (e.g., HD video decode), but still have to live within a tight power budget.

[Howardlong]

We use linux on several products, on ARM and PowerPC.

When you decide to use a linux distribution you really need a supplier that can support it. Up until now every Linux target we used had it's quirks, ranging from barely functional drivers to incorrect processor configuration causing lockups. If you are not intimately familiar with the SoC and Linux this is a pain to fix yourself.

I certainly can't disagree with any of that. The innate complexity of Linux means that you pretty much have little choice but to segregate responsibilities, there's just too much for one person to do, to do both the hardware and the firmware, and the firmware guy really needs to know the distribution well.

That depends on the knowledge of the person and the amount of time. I have done the hardware and software for several embedded Linux projects. Getting into embedded Linux does take a huge amount of time though. You need to know the kernel and bootloader inside out. Setting up the toolchain is another hurdle but nowadays you can install a generic Linux distro and compile on the target itself. OTOH that makes having a read-only root filesystem tricky.

For my scenarios, it just ended up easier doing it in my own sweet way. Although I've been dipping in and out of Linux for 20 years, back when you had little choice but to know how to recompile your kernel and tweak the device drivers to get going, I've never been immersed enough to be able to work my way around the OS like I do Windows, which I've been developing for for over 25 years, and of course DOS before that. I guess if you live and breathe it you may be able to make a production grade Linux device on your own. As a mere mortal I regret to say the curve is still beyond me other than for getting something trivial up and working, and I certainly wouldn't consider anything I ever did In embedded Linux to be ready for a marketable production system, but I am sure their are others with better magic powers than I have!

[Howardlong]

That depends on the knowledge of the person and the amount of time. I have done the hardware and software for several embedded Linux projects. Getting into embedded Linux does take a huge amount of time though. You need to know the kernel and bootloader inside out. Setting up the toolchain is another hurdle but nowadays you can install a generic Linux distro and compile on the target itself. OTOH that makes having a read-only root filesystem tricky.

Aside from development hurdles, what about power consumption? If your device is battery powered, how much more mW does Linux cost compared to an off-the-shelf RTOS or just bare metal? I think these kind of tradeoffs are being made more often in products that need features not present on Cortex-M processors (e.g., HD video decode), but still have to live within a tight power budget.

It is of course possible to reduce power consumption to reasonable levels (whatever reasonable may be!) as Android has proven for example. But I'd say you do really need to know what you're doing. Taking stuff out or halting things without understanding the implications of such a complex system is bound to result in tears.

[dannyf]

One way may be to look at the various TV sticks - gamestick for example. They usually run off Linux and are very inexpensive -> from a few dollars to maybe $20-ish.

[JonnyBoats]

You priced your Raspberry PI at $35 which will get you a model B. If you do not need wired Ethernet then you may be able to use a model A which costs $25.

[mazurov]

One way may be to look at the various TV sticks - gamestick for example. They usually run off Linux and are very inexpensive -> from a few dollars to maybe $20-ish.

The cheapest I've found so far are so-called '3G travel routers', a WiFi router with Ethernet and USB ports soldered on. They are built around Ralink RT5350 SoC ( it seems to me that Ralink published some ref.design and now everyone is copying it ). Nice little machine one can have for ~$10 retail shipped as a product, the bare board could be as little as $2.50 on Alibaba. Also, the design is well understood by openwrt crowd and have its own target in buildroot.

The devboard-ish variant of that is this -> http://wiki.openwrt.org/toh/hilink/hlk-rm04 , available from ~$15 from dx.com.

[ehughes]

So is there a simple way one can put together there own small arm computer running linux that doesn't require a deep knowledge of the inter workings of the os and boot loader?

Absolutely not.  If you plan to do any hardware interfacing, thinking that you can not consider how every part of system works is project suicide.     How can you expect to support a hardware product when you don't know how it works or aren't willing to learn?

Every product I have ever seen that simply "slaps on" a Linux layer without having people that really understand the architecture is absolute shit.

Also consider if you really want to product that takes 30 seconds to boot?   I find that annoying.   There is only one company who has gotten linux fast booting (under a second) to work is TimeSys (Pittsburgh, PA, USA).    If you really want to pursue a linux system,  get an expert involved.


From your specifications,  going to an applications processor running Linux is not a good fit if you are attempting any kind of volume.   If you are really worried about cost,   go with an MCU.   There is nothing about the specs at screams uses Linux (or ANY OS).    What feature/specification are your thinking you need Linux?

Even picking a high end MCU such as a Freescale K64 series or NXP LPC43xx series would give you more than enough horsepower for the job without the hassle of an OS.

[Howardlong]

So is there a simple way one can put together there own small arm computer running linux that doesn't require a deep knowledge of the inter workings of the os and boot loader?

Absolutely not.  If you plan to do any hardware interfacing, thinking that you can not consider how every part of system works is project suicide.     How can you expect to support a hardware product when you don't know how it works or aren't willing to learn?

Every product I have ever seen that simply "slaps on" a Linux layer without having people that really understand the architecture is absolute shit.

Also consider if you really want to product that takes 30 seconds to boot?   I find that annoying.   There is only one company who has gotten linux fast booting (under a second) to work is TimeSys (Pittsburgh, PA, USA).    If you really want to pursue a linux system,  get an expert involved.


From your specifications,  going to an applications processor running Linux is not a good fit if you are attempting any kind of volume.   If you are really worried about cost,   go with an MCU.   There is nothing about the specs at screams uses Linux (or ANY OS).    What feature/specification are your thinking you need Linux?

Even picking a high end MCU such as a Freescale K64 series or NXP LPC43xx series would give you more than enough horsepower for the job without the hassle of an OS.

Wise words, that pretty much reflect my experience and concerns.

[linux-works]

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.

better to just make your system interace TO an existing linux box.  let the user choose that box.  your job is to define the interface between them and keep it stable.

I do audio system stuff and I've wanted to have a linux box 'inside' my preamps, dacs, etc.  but it never made sense.  as soon as I think about using board X, X+1 comes out.  too much of a moving target and too much time invested to get things right for box X.

what I ended up doing was using arduino controllers inside (fast booting, simple, stable) and having them serially talk to some remote arduino, maybe over an xbee rf connection.

separate modules and leave them separate.  the stuff that changes a lot, make that its own box or module and then just treat that as a system all its own.  loosely couple with it.  that's what I recommend.

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

[linux-works]

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.

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