Ask Slashdot: Best Dedicated Low Power Embedded Dev System Choice?

An anonymous reader writes "I'm a Solaris user which is not well supported by the OSS toolchains. I'd like to have a dedicated Linux based dev system which has good support for ARM, MSP430 and other MCU lines and draws very little (5-10 watts max) power. The Beaglebone Black has been suggested. Is there a better choice? This would only be used for software development and testing for embedded systems."

Comments

UDOO

[danomatika]

Check out the UDOO: http://www.udoo.org/

A pretty capable machine at a decent price and low power draw. Yes more than a Raspberry PI, but multi cores and real USB controller is worth it (at least for my realtime audio needs).
 

Weird question, but...

[TWX]

...why the extremely low power draw requirement? Seems like for a dev box you'd want some horsepower, though you'd want to test on a box that's like your expected production machine...

Re: Weird question, but...

[Anonymous Coward]

I'd say 'esoteric' is an apt adjective for Solaris.

You're guilty of what you're accusing the grandparent for.

Re:Weird question, but...

[gl4ss]

*Probably to test how code performs under such low power conditions?*

not really. he's developing for mcu's. not for the system itself, so that has no point.

for it to be portable, it would need to have some other stuff.. like a monitor, keyboard and other stuff all which take power. now he might be doing it under solar power at his cottage or yacht or whatever.. but then kind of still would be needing the monitor and other peripheals.

basically the answer is just buy a friggin netbook. even if you need to have usb programmers for the stuff you're going to program due to not having gpio right on the system. my bro uses a raspi for mcu development but that's just mainly for flashing from the thing and using ssh to connect to it from a computer. so if he just wants to attach a big battery to the thing and leave it at where the mcu is doing some controlling or data acquisition and wants to update it live there.. then get a raspberry pi.

Re: Weird question, but...

[queazocotal]

I'd hesitate calling a quadcore intel system 'incredibly cheap' - but that aside.

In some cases, power can be rather more costly than that.
For example, I did some simulations using accurate local solar data here in Scotland, and if I want a system that works 24*7, with storage to back it up, it comes out to around $200/W initial capital, and maybe $20/W ongoing (battery replacement), or $.90/kWh equivalent.
Assuming a 10 year life, that doubles it to $1.8/kWh.
Or $15 per watt your device uses, per year, amortised over 10 years.

And this neglects structure - a 20W system will use 2500W or so solar panels, or 4m on a side.

Re:Weird question, but...

[dreamchaser]

naw - read TFS again; xie's devving for Solaris. Good luck getting Solaris running on a pi/bone/whatever.

Maybe you should read TFS again instead since the submitter clearly states that they want a dedicated *Linux* based dev platform. There's no mention of running Solaris on it.

Re: Weird question, but...

[laird]

It depends on your application space. If you're making a monitor to alert you when plants need to be watered, you're going to want to use a controller that can run on AA batteries for months, and costs a few dollars. That's not anything that Intel sells - that's more like an Arduino Atemel chip. So yes, compared to a high end CPU, a low end Intel CPU is cheap and low power, but compared to a $3 controller that can run on an AA battery for months, it's expensive and power hungry.

Re: Weird question, but...

[TemporalBeing]

The problem domain isn't "monitoring plants with only an AA battery for power" though. It's a host capable of running Linux and assorted toolchains for embedded software development. I know that there are systems for all kinds of applications and the power envelopes they prescribe. That's not the issue. The issue is that someone proclaimed that "electricity is expensive. Douche bag." And that's not true. Electricity is cheap. Cheaper than hardware which is incredibly cheap itself. And that holds true even for the very low end, where a tiny amount of energy is sold in an expensive package, but a finished system will still cost more than the batteries it takes to run it for a couple of years before it is replaced, yet the hardware is sold at prices which almost make the devices disposable. For perspective: How many smartphones does the average person buy per year? Still think a low to mid range quad core desktop system is expensive?

So I do development and I want to cut my costs down. I presently have a desktop at home with a 600W supply and a server with a 250W supply, as well as laptops with 60-90W supplies. As I use the desktop for other things (e.g playing DVDs, Netflix, etc.) I'm satisfied to leave it for now; laptops might get replaced by tablets or chromebooks.

But the server? I keep it on a UPS, and would love to be able to keep it up for a very long time. On the UPS it would only get between 10-30 minutes if power fails (APC 1500). I am very interested in switching it out for a few lower power devices. In fact, I'm targetting replacing it with 3 devices (a Rasberry Pi for authentication, a Udoo for disk storage, and a Routerboard for firewall support) with a total power envelope of 50W.

Do I still intend to do software development on the server? Yes.
Do I still intend to do DNS, DHCP, Samba, WebServers, etc on the server? Yes.

But you know what - unless I'm building something targetting a mainframe, some heavy video driven application (e.g games, autocad, etc) then I really don't need a very powerful system. Point being - a beagleboard, Udoo, or Rasberry Pi really is sufficient for most people doing software development....well, unless you're trying to use Eclipse or Visual Studios, but then you're just asking for trouble.

The display will draw more power than the CPU

[Animats]

Any display big enough for development will draw more power than the CPU. (Although I suppose you could kludge some non-backlit e-reader into being a dev system.)

Re:The display will draw more power than the CPU

[Alioth]

No need for a second display. Just ssh -X develsystem and have everything display on the Solaris machine.

Solaris not well supported by OSS toolchain

[Nutria]

It's my understanding that "install a bunch of gnu tools" is the first thing that many Solaris sysadmins do on a new system.

Anyway, why do you need a low-power ARM system? The description heading mentions "embedded", but your description mentions irrelevant stuff like Solaris, but not the important stuff like what sort of embedded work you'll be doing: industrial control, point-of-sale, sensor monitoring, etc, etc ad nauseum.

Re:Solaris not well supported by OSS toolchain

[Anonymous Coward]

Probably because about 99.99% of questions such as this one play out like this:

"I need a hammer. What is a good hammer?"

"Why do you need a hammer?"

"I need a hammer to chop down trees."

"No, you need an axe."

They don't even allow questions like this on stackexchange because they're so open ended and worthless that they serve no purpose and provide no value (other than to instigate arguments such as this or flameboy arguments such as Home Depot hammers versus Lowe's hammers). I can tell you've never dealt with customers and requirements management, because understanding why customers need something is extremely important: it may lead to a better product for the customer or new products for more/new customers. Lastly, you must be new to the internet if you go around assuming anyone knows shit (especially on Slashdot).

Re:Solaris not well supported by OSS toolchain

[Nutria]

Why do people always as WHY someone wants something?!

Excellent question, young Padawan.

People often ask for help, assuming an answer and thus embedding it in the question. The experienced helper asks probing questions to see what the asker really wants, and then asks that question. When you're older, you'll understand.

In this case specifically, embedded development typically requires specific "non-consumer" I/O requirements that little hobbyist systems just don't support. Thus, saying BeagleBoard or Udoo or RaspberryPi would steer him wrong.

OTOH, maybe he just doesn't know WTF "embedded" really means and is just tossing out the buzzword du jure, when a used laptop would serve his needs much better.

So, we ask probing questions.

Re:Solaris not well supported by OSS toolchain

[jones_supa]

I find it incredibly annoying when I have accurately researched some topic and know what I'm doing, but when I'm asking about some detail, some jackass starts walking me through that whole jarring "why do you want to do that" dance!

Re:Solaris not well supported by OSS toolchain

[Nutria]

but when I'm asking about some detail

Can you really not figure out that the solution to such a problem is to add more detail to your question, indicating what you've already researched?

Methinks more people should read "How To Ask Questions The Smart Way".
http://www.catb.org/esr/faqs/smart-questions.html#beprecise

Re:Solaris not well supported by OSS toolchain

[Aighearach]

Vampires don't figure, they just suck.

Re:Solaris not well supported by OSS toolchain

[jones_supa]

Can you really not figure out that the solution to such a problem is to add more detail to your question, indicating what you've already researched?

Let's say you want to develop a 3D game that has to work in all the absolutely most crusty computers that can be found. Then you want go with OpenGL 1.x and the fixed function pipeline. Just observe all the whining that appears. How you should use shaders, and how even shader-based OpenGL 2.x is not sufficient but for some academic reasons you want at least 3.x because it has the core profiles, so that even accidentally you won't be using any legacy functionality. Even despite the fact that games like Angry Birds and Minecraft actually still support OpenGL 1 for the best compatibility.

Re:Solaris not well supported by OSS toolchain

[Anonymous Coward]

For all we know this guy does development work inside his van and wants to drain the battery as slowly as possible.

Asking "why" is often a pretty good question, because you can't tell from the very first question that the person actually knows their needs, or indeed knows what they fuck they are doing at all. Development on embedded systems is slow, the processors are slow. Is the poster willing to put up with slow compile times compared to a laptop?

I saw online a person who was asking how to design a power supply with that supported a variable power correction factor (PFC) of about 0.7 to 1.
After some questions it turned out this person didn't really know what power factor correction was, he just saw an "acceptable PFC" range in some electrical standards document and made some assumptions about the requirements, not knowing that the standard meant your power supply had to have a PFC in this range (it wasn't asking for variable PFC), and not knowing why ideally you want a PFC near 1.
So if this guy got defensive for being asked why he wanted a variable PFC, he wouldn't have learned much.

I get coworkers asking all the time for roundabout ways to solve problems. So I often ask "what's this for?" Often the case is that I already built a tool to solve the problem, or I can build one in 5 minutes to save several hours of work.

They point of asking "why" isn't to embarrass, shame or trick the questioner, it's to find out the big picture of their end goal, and the discussion often leads to better solutions.

Re:Solaris not well supported by OSS toolchain

[thegarbz]

I find it incredibly annoying when someone THINKS they have researched some topic and knows what they are doing.

You may be perfectly right and capable and interested only in the detail that you're asking, but unfortunately you'd be in the minority. probing questions will confirm everyone is on the same page and while it may be annoying to you, it will be a godsend for many others.

Engineers in general are terrible at solving generic problems, which is ironic because we're thought of as the great problem solvers. Our issue is that it's in our blood to solve problems and quite often we'll have solved the problem without even understanding what that problem is. It reminds me of the great Dilbert comic where Wally interrupts his boss by saying "We'll build a database" and when it was pointed out that he doesn't know the problem yet he retorts "We always build a database."

Re:Solaris not well supported by OSS toolchain

[LWATCDR]

Simple native development can be a lot easier than cross development.
If you have the money for some really good embedded tools, cross development is not bad at all. But if not native development is a lot simpler.
I would still do most of my work on an X86 Linux box and then move the project over to the embedded for testing but that is just me.

Re:Solaris not well supported by OSS toolchain

[Andy Dodd]

Yeah. People are asking questions because HIS questions are, when taken together, nonsensical.

He's looking for a good host machine to do development for ARM, MSP430, and other MCU embedded targets.

When doing embedded development, there is usually a very clear distinction between "target" and "host" - it is rare in the embedded world for people to use a device as both host and target (since the target is usually pretty weak CPU-wise), but he's implying that he wants to use a device that is usually a target (Raspi, BBB) as a host... Which to anyone that has actually DONE this sort of development is nonsensical. There's some benefit to a BBB self-hosting, but it's silly to do AVR or MSP development on a BBB, unless what he's really looking for is a heterogenous target (e.g. the BBB is part of the target solution, and loads an AVR or MSP at runtime to do realtime tasks - but even this doesn't really make sense due to the BBB's PRUSS, other than the fact that the PRUSS is a bit more difficult to work with.)

If you want a low-power low-cost development environment for ARM Cortex-M, AVR, MSP430, etc. targets, your ideal host system is probably a Chromebook with crouton installed on the SD card.

So either he has VERY special unique requirements that he hasn't clearly communicated, or he's looking in an entirely wrong direction for solutions. Either way, his actually needs haven't been properly communicated.

Re:Solaris not well supported by OSS toolchain

[Nutria]

How you should use shaders...

"My hands are tied. Even though I want to use OpenGL 3.x, I can't. The specs say OpenGL 1. So, can you help me with OpenGL 1 or not?"

I was a programmer, and now I'm a DBA. When I ask for help, people understand that -- for example -- when I say "the machine runs SQL Server 2008R2" that there's zero chance of upgrading to v2012 or v2014 just to solve one itsy problem: there's too much effort involved in QAing a huge production environment.

Re:Solaris not well supported by OSS toolchain

[rasmusbr]

They want a low wattage test system for doing embedded dev. Period. Don't skirt around it, don't try to poke and make fun of anything he says in the comment, either you can't help him or you can. MOVE ON.

The person doesn't really provide a power budget. Low power compared to what?

Are we talking a device that's going to need to run off of battery power for hours or days? Are we talking about a device that's going to be silent (no cooling fan)? Are we talking about a device that can have a cooling fan as long as it delivers good performance per watt? Who knows, the question doesn't specify.

Re:Solaris not well supported by OSS toolchain

[jon3k]

Because there may be a better way to accomplish it. If your kid came to you and said dad can I get a rope, three pounds of butter and a mule? Would you give it to him or ask what he was trying to accomplish?

Re:Solaris not well supported by OSS toolchain

[Art Challenor]

Actually the question is really freaking stupid. If you're serious about embedded development you cross-compile on the fastest computer you can find and then deploy to the target board. If the question had been "what's a good embedded target" it would have made marginally more sense, except that parameters there are how much i/o volume/cost, performance, etc.

Re:Solaris not well supported by OSS toolchain

[geoskd]

The GPP is 100% right when he says "Just because you don't understand their needs doesn't mean you need to step in and try to change what you think they need. (Ever think they just MIGHT be smarter than you or know their needs better?)"

Which once again returns us to the basic questions being asked by the would be helpers: "What are you trying to accomplish?" Without that fundamental part of the picture, all but the most generic help is pointless.

To return to the current case in point, Say the person is trying to build a plant monitoring doo-hickey. The choice of platforms depends a great deal on a hundred little specifics. For example, if each device being designed will handle one plant only with just a few sensors, and it is going to run on a non-trivial power source (car battery, wall power, large-ish solar panel, then a Rpi is probably the best choice. If the device is going to monitor a row of plants with sensors, then a BeagleBone is probably a better choice for its expanded IO. If it has to monitor an entire greenhouse with dozens of rows, then perhaps a distributed collection of 1 wire sensors is in order in which case just about any platform will do. If, on the other had, the whole thing has to run on a pair of AA batteries, then you are going to have to roll your own solution, and some kind of FPGA board would be a better bet, since you're going to need to understand where every bit flip is going to keep the power consumption down.

The original questioner did not provide enough details to suggest that they even understand all of the options available, so it quickly becomes clear that further questions are needed to find out what they do and don't know.

Key questions that need to be answered:

What does "low power" mean? 5 watts, 0.5 watts, 50 watts?

What does embedded mean? Is he referring to embedded to mean that it is a headless device? Does he mean that it has to run from a limited power source? Does he mean that he needs a device with GPIOs?

In what ways will the device interact with the world? By Ethernet? by 1 wire? by dedicated GPIOs? Does the submitter even understand this question enough to answer it? I'm not so sure from the way the original question was phrased

How many of these device does he intend to build? Just the prototype? Low volume run (Less than 100 units)? Mass-Pro?

In conclusion, the question was not properly framed, most likely because the submitter did not understand the topic well enough to ask intelligent questions, and samzenpuss sure as hell doesn't understand the topic well enough to properly filter these kinds of questions.

Re:Solaris not well supported by OSS toolchain

[geoskd]

Which to anyone that has actually DONE this sort of development is nonsensical.

I happen to like doing my dev work directly on the BBB. I have a full scale machine that I use as a glorified display, and other servers that house subversion, and other needed resources.

Doing dev work directly on the BBB makes it far easier to deal with debugging problems in the field, because, by definition, I have my full debugging environment with me at all times. My dev environment is always exactly identical to the production environment, so I never have the "it works fine in the lab" scenario.

Sure it may take longer to compile, but I can take a virgin board, and have my dev environment up and running anywhere anytime. Give me any laptop with an SSH client, and I have a full dev environment. It is also much easier to debug embedded hardware problems when the development and production machines are the same.

Re:Solaris not well supported by OSS toolchain

[ezelkow1]

Its not really that much more complicated. I do cross dev at work, but at home I had a crossdev setup for a handheld gaming machine we were porting linux to up and running in under 30min. Its really not that hard to just specify a target on a different host. This is all gcc as well, you dont need money for good embedded tools

Re:Solaris not well supported by OSS toolchain

[jkflying]

Try developing for an MSP430 on the MSP430... hence the distinction between 'target' and 'host'. When you can develop on the target, great. But a lot of these MCUs don't have the IOPS/RAM to run a generic scripting language, never mind a compiler.

Re:Solaris not well supported by OSS toolchain

[david.given]

Because this never works.

What happens instead is that people latch on to some irrelevant detail in your context and the discussion gets instantly derailed in that direction, thus ensuring that your question never gets answered. It's particularly fatal to mention motive, because that's completely subjective. The only way to actually get useful answers to questions these days is to trim the context as ruthlessly as you possibly can.

One day someone needs to write a "How To Answer Questions The Smart Way".

Re:Solaris not well supported by OSS toolchain

[Nutria]

What happens instead is that people latch on to some irrelevant detail in your context

Maybe I just work in an area of IT where such Aspergers jerks are minimal.

Re:Solaris not well supported by OSS toolchain

[drinkypoo]

So either he has VERY special unique requirements that he hasn't clearly communicated,

Why is low power consumption a special, unique requirement? All of my computer equipment was chosen and/or assembled with low consumption in mind. My Desktop's TDP is under 350W and I can play games at 1920x1200, albeit not with everything turned on any more. I have a small fleet of netbooks for performing long-running tasks or for traveling, I sold an HP EliteBook and bought three of them. I even took an EEE 701 4GB running Jolicloud on a six-week vacation to Panama. My most power-hungry portable has two cores and the CPU has a TDP of 13W, and I'm undervolting.

Much of the goal was to be able to run on solar for long periods, which I do occasionally. Not so much lately, unfortunately, but I've mostly rebuilt my mobile solar rig. That reminds me, I should order some aluminum piano hinge.

Re:Solaris not well supported by OSS toolchain

[geoskd]

Try developing for an MSP430 on the MSP430...

Why would I bother when I can just use the BBB platform and run with it. Unless you're going to be selling millions of units, The time-to-market of the BBB platform trumps all.

Re:Solaris not well supported by OSS toolchain

[Rockoon]

Which once again returns us to the basic questions being asked by the would be helpers: "What are you trying to accomplish?"

Its stated quite specifically already so when you then go and ask that, you are of course doing exactly what I said you would do, proving my initial response that it really isn't helpful to describe in excruciating detail what is being tried.

The important specifics are already there: I need my generic class library to enforce a constructor contract on 3rd party code that calls my library.

Maybe you imagine that there isnt a need for it, but thats just proving the GPPP's point also.. that you think you know what other people need better than they do.

So you just proved us both right, showing that literally everyone else in the world would be better off if you didnt open your mouth when you dont know the answer but want to fish for a different question that you actually can answer (which is just self serving shit, harmful to the discussion as signal to noise goes righrt into the toilet .. your the noise.)

Re:Solaris not well supported by OSS toolchain

[Rockoon]

It's possible the person asking a question knows their stuff. It's possible. But we don't know that, which is why we ask probing questions.

..and by asking those questions you've trashed the original question.. so when the person asking does know their stuff the end result of your involvement is that you just fucked their thread over. At the very very best you've delayed any meaningful response by literally days because now everyone else is waiting for you to be answered.

Day 1, you ask: "Have you tried to [blah blah] your [woo hoo]?"

Day 2, you ask "Have you gotten all the latest [goo mo]?""

Finally day 4 or 5 comes around and you finally admit that you can't help (something you actually knew on day 1), but now the thread is pushed down, off everyones radar, and is filled with complete crap initiated by you. All because when you didn't know the answer, you decided that you must get involved anyways.

Do everyone in the world a favor and don't get involved when you don't know the answer. Don't pretend to be more than you are. The feel-good moment you get when you click "post" is a sham - you are harming the other person, not helping them.

Re:Solaris not well supported by OSS toolchain

[LWATCDR]

One word.
Debugger.
Compilers are actually easy to come by today. Debugging is where you run into issues.

Re:Solaris not well supported by OSS toolchain

[BitZtream]

I'd tell him to stop watching Kevin Smith movies and leave it at that.

Re:Solaris not well supported by OSS toolchain

[jkflying]

An MSP430 has idle currents measured in uA, and a chip costs in the region of $1.50, with no external components required. BBB isn't useful in applications that require running off of a watch battery for a year, and isn't cheap enough to consider adding as an additional component in consumer electronics.

Re:Solaris not well supported by OSS toolchain

[geoskd]

An MSP430 has idle currents measured in uA, and a chip costs in the region of $1.50, with no external components required. BBB isn't useful in applications that require running off of a watch battery for a year, and isn't cheap enough to consider adding as an additional component in consumer electronics.

and the MSP430 doesn't have enough horsepower for most things I want to do, and even if it did, the additional resources needed to design with it, and the additional time-to-market that these would introduce make it non-viable in todays world. As I said, time-to-market is everything. MS didn't get where they are because they made a superior product, they got there because they had a working product when the market opportunity arrived. Short TTM doesn't guarantee success, but TTM that is too long guarantees failure...

CPU cores and clock speed matter.

[Anonymous Coward]

Alright, I've been working on getting a build server setup on a BeagleBone Black that I had lying around. The ARM->x86_64 compiler I had to build so the executables could run elsewhere was a pain, so be careful about that. Also, the speed at which it compiles is "dog" slow. It reminds me of the stories I used to hear from old programmers about turning in their punch cards and waiting a day to get an answer back. It's not that bad, but it is slower. nohup quickly becomes your best friend. If it sounds like I'm harping on the compile speed it's because binutils--headers--gcc--glibc--binutils--gcc is a long build process and the Beagle bone black made it take even longer.

It's not all bad though. I find that the BeagleBone Black runs Linux quite nicely. Most common packages are there and working, and anything else can be compiled from scratch. It even acts a a nice PostgreSQL server. Also, it uses a processor that, if I recall correctly, will be supported by the general Linux kernel community. I believe the Raspberry PI has to use a special driver, so you are stuck with the raspberry flavors of Linux.

Now as far as a testing platform, as long as your program isn't graphically intense then it would be fine. But I think the Raspberry PI has a better graphics setup.
Don't forget to look at http://utilite-computer.com/web/home. They offer single, dual, and quad core ARM 9 systems that would probably be spiffier than the BeagleBone Black. Not as open of course, but that was not one of your requirements. The Utilite Pro running Ubunutu 12.04 consumes around 5 Watt in idle mode and around 8 Watt average when 3 cores are active.

A bit of a ramble, but I hope it helps.

Best <insert-x-here>

[weilawei]

Emacs! Oh wait, wrong flame war..

Intel NUC

[enter to exit]

The OP doesn't need Solaris (He currently has a Linux Dev box) or an ARM system. He needs a low powered machine that can compile to ARM (and other things).

I would look into an Intel NUC.

Re:Intel NUC

[Blaskowicz]

The one with quad core 22nm Atom (named Celeron N2820 or N2830) should be great and is cheap and low power. Dangerously cheap too!

Probably higher perf/watt than cell phone and tablet ARM.

Re:Intel NUC

[Anonymous Coward]

Zotac is currently bringing passively cooled quad core mini Intel boxes to market (the low end NUC has a fan but doesn't really need it under normal load). The Zotac ci320 nano looks particularly nice: Celeron n2930 (quad core, 1.8GHz) with a thermal design power of 7.5W and an even lower scenario design power. It offers a much better interface selection than the NUC: plenty of USB3 ports, display port, HDMI, eSATA, (shared SATA and mSATA inside). Costs about the same as the low end NUC.

The NUC allegedly has some issues with USB that are supposedly fixed by the 2830 CPU revision. This revision also brings QuickSync. The hardware video encoder wasn't available in previous revisions. But Intel decided not to change the SKU, so getting one that has the new CPU is a little difficult right now as they are selling the old stock first.

The Zotac is difficult to find. It's just coming to market.

Re:Intel NUC

[queazocotal]

For embedded intel - a better match may be the new minnowboard max.
http://www.minnowboard.org/mee... $99 - shipping real soon now, preorderable.

Re:Intel NUC

[Big_Breaker]

Celeron J1800 and J1900 boards are passively cooled, low power and cheap. Consider them as an alternative to a NUC

I bought this board:
http://www.supermicro.com/products/motherboard/celeron/X10/X10SBA.cfm

It's more expensive than the ASUS, Gigabyte, etc J1800 boards but mine does 12V dc-dc conversion on board and has many more SATA connections. That sames me a traditional PSU and SATA card/expander.

Re:Intel NUC

[Blaskowicz]

Oh right, it's the Celeron J1900 (sold on standalone ITX boards) that was quad core.

Buy a netbook

[drinkypoo]

You can get a netbook that will draw around 5-10W. If you get one with intel cpu and chipset you will have the advantage of massive compatibility, especially if you skip the original Atom chip. Once the dual cores came out it was pretty well abandoned by everyone.

That, or get one of these ~$100 android units which also runs Debian. But I don't really recommend that. The only one which seems very performant and yet inexpensive is the mk908 which is a bit of a turd reliability-wise and which doesn't yet have complete hardware support, e.g. http://www.cnx-software.com/20...

I stand by the netbook

Re:Buy a netbook

[Osgeld]

I got a dual core atom netbook for around 60 bucks, bumped it up to 2 gig of ram, and slapped a 32gig SSD in it, runs a couple days on a battery charge and in total have about 125$ into it thanks to ebay

its a good choice

Re:Buy a netbook

[Andy Dodd]

It seemed to me like netbooks stagnated pretty badly... These days, a Chromebook with crouton installed on an SD card makes for a GREAT Linux laptop.

Re:Buy a netbook

[drinkypoo]

It seemed to me like netbooks stagnated pretty badly...

So what? A dual-core atom is actually pretty snappy. I personally have a crufty single-core atom, that is quite pathetic and I wouldn't suggest it to anyone. What I actually use for a 'netbook' is a Gateway LT3103u with the L110 chucked for an L310. Since Gateway finally released windows 7 x64 drivers and a BIOS with AMD-V it blew the hacks wide open. I haven't done a custom DSDT yet (though I should) but I do have SATA running in AHCI mode, necessary for automatic TRIM support. That took a hacked BIOS, but they're not too hard to find any more.

I wouldn't actually suggest anyone buy one of these and mod it because the X1250/X1270 graphics are woeful, but if you have one lying around the upgrade is actually pretty easy. A dual Athlon 64 at 1.2 GHz is not too shabby, and you can get the CPU for ten bucks.

Re:Buy a netbook

[drinkypoo]

Nope, but a chromebook gives 2GB of ram.

Yes, and so do many netbooks. My Acer Aspire One D250 only came with 1GB, as did my EEE 701, but those are old. My LT31 came with 2GB. I upgraded the dimm to get lower-latency memory, mostly to speed up the integrated graphics. Most of the machines that will support 1GB will support 2GB and some of them will even take a 4GB SODIMM, but don't count on it.

Shuttle DS437!

[ravyne]

Finally, an Ask Slashdot I can answer with personal experience and some authority!

Do yourself a favor and order a Shuttle DS437, I bought one myself and cannot think of a better little box for playing with embedded systems. Here's why:

• Its small -- about the size of a 5.25" disk drive.
• Its low-power -- not as low as you'd like -- but less than 20watts under load for the system. Its passively cooled.
• It takes a 12v barrel-plug from a standard 65watt laptop power adapter (included) -- easy to replace anywhere in the world. Also good if the impetus for your low-power requirement is an exotic wish, like being able to run the system from battery or solar.
• Its relatively inexpensive -- about $200 from Amazon.com, and qualifies for Prime shipping. You'll need to add storage and RAM, but maybet have some DDR3 so-dimms and a spare 2.5" drive kicking around from an old laptop.
• Its got two DB9 Serial ports, right on the front. Handy!
• Its a modern system: 64bit, dual-core, Ivy Bridge, SSE 4.2, supports up to 16GB ram.
• Connectivity: VGA/HDMI, USB 3.0, USB 2.0, dual gigabit NICs, Wireless N WiFi
• Storage options: you've got one mSata slot and one 2.5" sata drive. I've got a 128GB SSD in the mSata slot, and a 500GB magnetic drive installed
• It took Ubuntu 14.04 without any significant fuss. Most things worked out of the box. I'm not a linux super expert, but got the rest working within an hour or so.

It's "only" 1.8Ghz, but we're talking Ivy Bridge here, not some wimpy Atom or ARM core. Plus, in my experience you really want x86 for your host machine. Not every compiler or tool you might want to use is going to be supported on, say, a lower-powered ARM system.

I considered a lot of exotic ARM boards as my development host, including BeagleBone, Jetson-K1, and a handful of others. I think the D437 leads by a wide margin, but for what its worth I considered the Jetson-K1 board a distant runner-up.

Re:Shuttle DS437!

[ravyne]

Also, forgot to add -- Beware the potentially-confusing Shuttle DS47 -- it's nearly identical in appearance and pricing, but has a dual-core 1.1 Ghz Atom-based CPU inside which is significantly slower than the ivy-bridge (3rd-gen i-series) processor in the DS437.

Re:Shuttle DS437!

[Anonymous Coward]

Looks like you didn't read the question. The inquirer isn't looking for an ARM system: The specification is for a low power system which runs Linux so that it will support the toolchains for ARM and other common embedded CPU architectures. The Shuttle DS437 runs Linux, as described by Ravyne. Idle power consumption certainly fits the desired envelope of 5-10W. It's a little more under load, but you get vastly more processing power in return for that, and the widest support of developer tools available. There are other options available in the Intel world too: The NUC DN2820FYKH from Intel and the new Zotac CI320 nano come to mind. They truly fit the 10W power envelope and are cheaper than the DS437, but have lower single core performance and lower maximum RAM capacity. They are still much, much more able systems than the small ARM boards which are mentioned in other comments.

you can do TI in oss

[Osgeld]

but I wont shed a tear for you when you have to jump though your 20th hoop

TBH the msp's are not NEARLY as bad as their arm based devices, where you will have more console windows up than lines of code

PcDuino

[bobm]

http://pcduino.com/
I have a raspberry Pi, Beagle Bone Black and PcDuino.

Raspberry PI: don't like the fact that you have to boot off the sd card.
BBB - no complaints, nice board and has an optional display that's pretty nice
PcDuino - my favorite, more memory and flash than the other 2 devices and the v3s is in a really nice case.

The Pi and BBB lack a decent case (from what i can find)

Re:PcDuino

[nwf]

I have a Pi and a PcDuino v2 and the PcDuino is definitely more capable and doesn't cost all that much more. The Arduino compatbility and WiFi are nice, as is having enough flash on board to boot without an SD card, although I generally use one since they are faster. I use their LinkSprite shield for prototyping things, since it breaks out the IO pins into a nice connector for easy use.

The Differentiators are SoC Peripherals...

[linearz69]

The ARM architecture has some fairly good Linux support and wide adoption.

One of my favorites out there today is the A10-OLinuXino-LIME This is a low cost 1GHz ARM board with a Mali-400 GPU, a SATA port, 100BT port, two USB ports for under $50. I'm a big fan of the SATA port... using a SSD for the system solves many reliability problems. It also has support for LIPO battery but I haven't tried it.

Perhaps the best value/performance is the Wandboard QUAD. Quad iM.6 with 2GB Ram, WiFi, SATA, and an OpenCL supported Vivante GC 2000 all for $129. For the price it can't be beat... though the power consumption may be a bit higher than other small embedded systems..

The most popular two boards out there seem to be Beagle Bone and Rasperry PI. I'm not big on either...

The Beagle Bone was good in its day, but it is kind of over the hill. The processor is underpowered compared to other ARMs out there today for the same price/power consumption. Its peripherals are limited to essentially one USB 2.0 port and a bunch of multifunction IO on a header - which may be useful if you are hobbying. The one USB2.0 limits storage options. Because of the poor reliability of MMC, I prefer to use SSD these days, which means I need a USB drive enclosure of some type and need to get a hub if I want other USB. With all this, I'm still stuck at 2.0 speeds on the SSD.

The other issue with the Beagle Bone is that the processor is kind of on a dead end in terms of development cycle. That is, TI is not actively developing new OMAPs, but they have been authoring most of the Linux drivers for these chips. TI will continue to produce the OMAPs that are on the Beagle Bone, but I wonder how much they will continue to support driver development for future Linux.

Raspberry PI is useful for what it was designed as, an educational tool. But as an embedded processor it is not that great, kinda overhyped. The boot option is very limited - boot loader must reside on an SD. Also, Raspberry PI hardware is not open source. The Broadcom processor most nifty feature is a closed sources GPU, and the hardware requires a mysterious bin blob to boot properly. It is a toy.

Re:The Differentiators are SoC Peripherals...

[linearz69]

TI+ARM is alive and well.

More like on life support since 2012: http://www.eetimes.com/documen...

The AM437x is nearly 18months late, and likely was far along in the pipeline when those layoffs happened. TI's OMAP roadmap has been slipping for the past two years, with many processors there will never get released.

Re:Jetson TK1

[Blaskowicz]

Its page implicitly but strongly says it's for people who register as a CUDA developer.

Re:Install Linux in a VM

[Blaskowicz]

What's more Virtualbox is made by the same vendor that makes Solaris and using it is a piece of cake..

Why ?

[dargaud]

Why do you want to _develop_ on an embedded system ?!? Use a Linux PC for development and then test your code on your embedded platforms. I use Ubuntu for the former, with either buildroot or a direct gcc eabi. If the development platform _must_ be low power, like you develop from an african field with a solar panel, get a netbook.

Re:Best

[Anonymous Coward]

That's vi, you insensitive clod!

Not quite sure if I'm following ...

[Ihlosi]

What exactly is the point of the dev system? You write/compile MCU software on it and then download the software to the MCU?

A simple, cheap small notebook computer should be able to do this.

Re:Cheap windows laptop

[goarilla]

But you see you are in the Windows CE embedded niche. Your vision is clouded.

Last post!

[jimmetry]

The correct answer starts with raspberry and smells like pie.

linux on ARM

[fonske]

Igor pecovnik maintains a Debian Wheezy branch for Cubietruck boards.

To answer the question

[petes_PoV]

Look at the Olimex range of boards.
I've been using these for a year or two and found them to fit the bill nicely.

There are single and dual core boards, with / without embedded flash memory (or micro-SD card slots) and they'll run Debian (or other) Linux They have a lot on on board peripherals and pinouts for their own range of LCD screens - though I use an HDMI monitor for simplicity. The power supply will accept anything from 6 - 16 Volts from a phone-charger type PSU and you can even plug in a LiPo for backup.

I'll stop there before someone accuses me of advertising (I'm not, and I have no connection to the company). But as a last point, they are also pretty cheap.

Baytrail-D boards?

[speculatrix]

http://ark.intel.com/m/product... The Intel Silvermont Atom boards are very electrically efficient and offer surprisingly good performance. You can buy a board for under US$100 and all you need to add is case, PSU, RAM and mass storage. Some boards have VGA, some DVI, with or without legacy serial and parallel, lots of choices. Manufacturers include gigabyte, msi, Asus, supermicro.

Olimex boards.

[Lumpy]

Far more OI, better all the way around.

https://www.olimex.com/Product...

A10-OLinuXino-LIME and BBB are both Cortex-A8

[Morgaine]

One of my favorites out there today is the A10-OLinuXino-LIME. ...

The Beagle Bone was good in its day, but it is kind of over the hill. The processor is underpowered compared to other ARMs

Just to be clear, the A10-OLinuXino-LIME, BeagleBone white and BeagleBone Black all contain a single Cortex-A8 core, and the TI AM3359 runs at the same 1GHz speed in the BBB as the Allwinner A10 does in the LIME.

The original BeagleBone (white) ran its AM3359 at 720MHz so its CPU performance is a bit less, but the BeagleBone Black (BBB) superceded it a year ago and at a much lower price. As a result, the reasonable current-day comparison is between A10-OLinuXino-LIME and BBB, and on CPU power their similar speed Cortex-A8 cores make them pretty much identical.

I have all of these boards and many other similar ones, and my assessment is that BBB is much more capable for embedded projects because of its additional dual realtime 200MHz PRU cores (which are quite unrivalled), while the A10-OLinuXino-LIME is more suitable as an extremely low end desktop-style "computer" because of its dual USB2 host sockets and rather more capable MALI-400 GPU.

This assessment doesn't change when the just-released A20-OLinuXino-LIME is brought into the comparison, except that the dual Cortex-A7 cores in the A20 make it a far better general purpose "computer" than its A10 sibling for a mere 3 euro more in price.

Re:A10-OLinuXino-LIME and BBB are both Cortex-A8

[linearz69]

One of my favorites out there today is the A10-OLinuXino-LIME. ...

The Beagle Bone was good in its day, but it is kind of over the hill. The processor is underpowered compared to other ARMs

Just to be clear, the A10-OLinuXino-LIME, BeagleBone white and BeagleBone Black all contain a single Cortex-A8 core, and the TI AM3359 runs at the same 1GHz speed in the BBB as the Allwinner A10 does in the LIME.

The original BeagleBone (white) ran its AM3359 at 720MHz so its CPU performance is a bit less, but the BeagleBone Black (BBB) superceded it a year ago and at a much lower price. As a result, the reasonable current-day comparison is between A10-OLinuXino-LIME and BBB, and on CPU power their similar speed Cortex-A8 cores make them pretty much identical.

These chips are hardly identical when you look at the peripherals. The Beagle Bone really is lacking in the SoC side of things and has been surpassed by a lot of other ARM chips.

For instance - the A10 LIME has a SATA port. What are the external options on a BBB? SD or the single USB port? And the 4G eMMC can have problems - there tends to be subtle difference in the parts between vendor and chip rev which make the system open to some of the reliability issues seen with SD.

I have all of these boards and many other similar ones, and my assessment is that BBB is much more capable for embedded projects because of its additional dual realtime 200MHz PRU cores (which are quite unrivalled),

Unrivalled? It can be rivaled with two PICs.

Not to say the PRU isn't nice, because it can be incredibly useful custom IO interface, but why would I need to do this? If I have some external device that requires that level of customization, then I'd be much better served to adapt it on the side of the device with a more ubiquitous interface (SPI, UART, PCIe), not create some custom interface on a processor.

while the A10-OLinuXino-LIME is more suitable as an extremely low end desktop-style "computer" because of its dual USB2 host sockets and rather more capable MALI-400 GPU.

Desktop-style?

I use the the A10-OLinuXino-LIME in low end Linux server apps - remote sensing and transmitting of data over ethernet. It seems to work quite well in this application. Don't use a monitor. I've leveraged the MALI-400 for codec conversion in a streaming app, which works fairly well. Cannot even begin to do that on a Beagle Bone.

Agree the A20 looks promising, but I haven't actually used it yet, so I can't comment.

RDP

[y5t3m]

Personally I'd have a netbook... In a Lab (Garage, whatever) I'd have the Oscilloscope/Logic Analyzers meters power supplies etc... connected to a Beefy desktop with plenty of RAM for running VM's so I don't stuff around with the build environment. When coding just remote (SSH/RDP/whatever) to the VM of choice. You don't mention price so stick solar panels, batteries and inverters on it till you're sub 5W.

Atmel SAMA5D3x

[jcdr]

This is a new chip with a ARM Cortex-A5 core, making it directly compatible with all distributions with an 'armhf' port like Debian, Ubuntu or Linaro.I like the fact that it is compatible with the Arduino Due connector. It's probably the easiest Linux based Arduino hardware compatible board.

http://www.at91.com/getting-st...
http://www.atmel.ch/tools/ATSA...
http://www.at91.com/linux4sam/...

That makes no sense.

[seebs]

Don't try to use super-low-power things for software development. Get something that will run things quickly and efficiently, and turn it off when you're not using it.

Re:That makes no sense.

[muridae]

This, 100 times this.

Even an old 100 watt laptop will compile your code many times faster than something like the Black or Ras Pi will. A gig of RAM and swap space, something that embedded systems don't normally have, will make a huge difference. Just throw a small SSD (or boot from USB stick) in an old 2-code i3 with a crap graphics card, and what your code compile faster than a 5 watt embedded device will even launch your IDE or get through the first source code file.

Re:That makes no sense.

[geoskd]

How much does it really matter when a small project will only take 15 seconds to compile on the BBB. So what that a cross-compiler can do it in 2 seconds. it'll still take close to 15 seconds total when you include the time to type the commands to download the executable. Even if it was only 7 seconds, it is still only a negligible gain.

now if you were compiling a kernel, or god-forbid something really big like open-office, or some such then I could understand, but for the vast majority of embedded work, it just doesn't matter. The embedded devices are fast enough.

Re:That makes no sense.

[muridae]

We don't know what the OP is attempting to compile. It might be just some code to run inside the Arduino bootloader, or it might be a whole muLinux and a local GCC for the target. Heck, the Debian distro for the BBB might not have a binary for the target muC, which means compiling GCC before compiling the code (worst case). There is also the possibility of OPs chips not being supported in GCC. For example, I just picked up some Cypress PSoC boards; the tools for them are only available right now on Windows. Not ideal, but writing some C so GCC could mangle the analog portions of the PSoC would be more uncomfortable imho.

Unknown target devices, unknown tools, leaves me suggesting something a little more capable than a embedded device. While a windows x86 device might not be ideal for all folks, it might be necessary for some target device's toolchain. I have a several year old quad-core i7 with a geforce 560 and spinning drives that runs on less than 100 watts; one could use an older second hand laptop like that, or a newer even lower power one with an SSD. It's not what the OP asked about, but the OP also didn't provide enough information to presume that they knew what their target embedded muC might always be. And for the general case of other readers who are reading this, I think a small laptop is still the best choice.

Sorry for all the mu, I can't seem to get the html for &#956; to work

AllWinner Mele set-top boxes

[FilmedInNoir]

http://archlinuxarm.org/platfo...
There's a good dozen or more configurations for the hardware.

There's guides on the internet to installing different versions of Linux on it. (Unless you want to do Android dev)
I bought the A1000 version and a laptop HD (plugs in the top).
Then I installed Debian (using an online guide) and MiniDLNA. I use it as a media server for my TV.

You got what you need

[slash0r]

You want 5-10 Watt max.

You have Beaglebone Black.
That works with 5V. 1A is recommended. That makes it a 5W device.

Most of similar embedded devices have same requirements. just look for functionnalities/ports you need and test/use it.

Technologic Systems

[Jon Abbott]

The embedded ARM boards from Technologic Systems are worth looking at also. I used a TS-7260 with a large enough SD card to install Debian with gcc and it worked great. It booted nearly instantly and consumed something like 100mA of current at 3.3V IIRC. It was quite a robust little box. There are newer and faster models than the TS-7260 at the link I provided above.

Technologic Systems

[Jon Abbott]

I just checked and they state that the TS-7260 draws half a watt minimum and 2W typical... I seem to recall it drawing even less than that though. Perhaps it was 200mA @ 3.3V which would fit within their spec.

A list of all boards in the market

[aprdm]

It's in portuguese but you can use google translator http://www.embarcados.com.br/a...

Re:Best

[Virtucon]

vim is where it's at.

toolchain

[electrosoccertux]

thats what a toolchain and cross compile is for. nobody compiles android on an android phone. HOW DID THEY COMPILE FIRST ANDROID PHONE? HOW IS BABBY FOREMED?

insensitive shuttle

[electrosoccertux]

I'm a cosmonaut, you insensitive clod!!

Re:Cheap windows laptop

[jrumney]

The vendor supplied tools may be Windows only, but chances are there is a gcc backend available for the target architecture these days. I wouldn't like to be using an ARM board for my cross compiling though, getting QEMU set up for any compilation steps that need to run on the target architecture is enough of a nightmare on Intel, let alone other architectures that noone has used that way before.

Re:Best

[danceswithtrees]

The Bears.

Use separate machines for development and testing.

[naris]

I am developing a system targeted to run on a wandboard (www.wandboard.org), which is a really good "embedded" system similar to the BeagleBoard, but uses a Freescale iMX6 A9 Arm processor and is available in single, dual & quad core CPUs with 512MB to 2 GB RAM.

However, even with the quad core 2GB ram version, builds take a really long time, so I use a regular PC that I built using a new Haswell CPU, 16GB ram and a 240GB SSD to do development and even unit testing. I can make several changes, build everything 6 or more times and do some more testing in the time it takes the wandboard to complete 1 build. I also perfrom cross compiles on the "PC" to target the wandboard and scp the resulting binaries over after the build completes.

Both the wandboard and the PC run ubuntu 14.04 and the system in question is being developed in C++ with Boost, rabbitmq and ODB to run on the wandboard and also "regular" x86-64 linux and windows. You should also look into using Yocto, which looks very interesting for cross platform development. However, I am currently just using eclipse on both the wandboard and the linux PC (and MS Visual Studio on the windows machine).

Wait: Cortex A15

[LordMyren]

Don't buy anything today. Wait until there are media boxes with quad Cortex A15/A17 chips and buy one of them. They'll be out any week now. Rockchip RK3288 is coming, should be affordable, and the company is spending a lot of effort making sure it's well supported in mainline.

Cortex A9 hails from 2007. It's ancient. The GPUs are at best old Mali-400's. The compute/watt is not-great.

If you want to go really low power- if battery life is your concern and you don't actually have serious CPU use (you mention MSP430, so it sounds like you don't have real CPU use needs) get a Cortex A7 or Cortex A5. There are dozens of dual core Allwinner A7 boards out there. A5 has slimmer pickings, but will get you pleasantly below the one watt range, and the boards come with more embedded targeted peripherals that might not be included on media devices.

Yocto

[linearz69]

If you are looking for a Linux based Dev System with support for many ARM processors, I would look at Yocto: https://www.yoctoproject.org/

This runs on 32 and 64 bit systems, has emulators for several processors, and generally appears to have support from many embedded ARM platform vendors.

Yocto leverages Open Embedded and so essentially builds a distribution, much like Gentoo. You will be rolling your own system from scratch. One of the beauties of Yocto is that you can maintain a similar source control configuration for multiple platforms, making it very easy to port across platforms.

Re:Wandboard

[linearz69]

Using the quad as a single board computer in an embedded app. It is amazing.

The only downside is the price. The power is nearly 10W, and has no flash on board, so an SSD will put it over 10W.

Re:BBB

[geoskd]

Because of the poor reliability of MMC, I prefer to use SSD these days

MMC reliability is fine. I thought I was going to have problems using the MMC on the BBB as well, so I set about beating several of them severely. I setup accelerated read-write-read testing, and started pounding on the BBB internal MMC. with 3 boards at over 5M writes to a single 512Byte block each, none of the devices failed. I read some literature which suggests that the MMC rotates sector usage to even out wear, which, if true, means that you would have to do the equivalent of recording 100,000 hours of HD video before you will burn out the MMC.

The other issue with the Beagle Bone is that the processor is kind of on a dead end in terms of development cycle. That is, TI is not actively developing new OMAPs, but they have been authoring most of the Linux drivers for these chips. TI will continue to produce the OMAPs that are on the Beagle Bone, but I wonder how much they will continue to support driver development for future Linux.

Embedded devices are install and forget machines. It doesn't matter much who supports them or doesn't once they are in the field. As far as unit availability, Special Computing is ramping up production and already surpassed all the other BBB manufacturers combined. Last I heard, they were over 120k per month production, the vast majority of which is going into mass-production doo-hickeys from various manufacturers. Our own embedded system uses 1 or more of them in every unit we sell.

The biggest advantage to the BBB (and to a lesser degree the Rpi) is time-to-market. An embedded system used to take 3 to 4 years to develop from conception mass-pro. With the BBB, we were able to do an entire embedded system, From absolute zero to mass-pro in 18 months. The case took longer to design than the embedded hardware!

Re:With Ubuntu. BBB

[geoskd]

The new BBB version is popular and hard to find but the extra flash is nice.

https://specialcomp.com/beaglebone/index.htm

How many do you want? These are not from Beagleboard, and are not Beagleboard certified, but they can be had in almost unlimited quantities and work as advertised. They are manufactured to the open specs. They are being manufactured by a third party in China in vast quantities for commercial use. They cost more than the official versions mostly because you can actually get your hands on them from these guys in nearly limitless quantities (up to 100+ they have in stock to ship right now, more than that might take a day or two, and order for a couple thousand might actually take them a week, but i doubt it) Rumor has it they are moving more than 100k units/month

Re:Save yourself some pain ...

[geoskd]

If you are building a project which requires some special hardware then you don't have to waste time porting a driver from x86 to ARM, MIPS, Sparc, etc.

In my experience, most embedded machines these days are ARM, and finding x86 ports is more of a challenge. Between the explosion of ARM based cell phones, and the Rpi/BBB, x86 is becoming less and less relevant (and with it MS/Intel)

Active android development is almost all ARM, and x86 is ported as an afterthought.

Re:BBB

[linearz69]

MMC reliability is fine.

It is absolutely not fine. Some MMC devices that are better than others. The system plays a huge factor, the software configuration matched with the MMC can make a difference. Component skew and differences in implementation between chips and chip revs are huge factors. If you really think that MMC is reliable, then I have some swampland.... MMC for embedded is a bit of a mess.

Embedded devices are install and forget machines. It doesn't matter much who supports them or doesn't once they are in the field.

My customers would differ that support doesn't matter. For what I build, I have to design with a 5 years horizon. That includes new marketing requirements and field support among other things...

But that is rather tangential to my point... Because the HW development has stopped, is very possible that TI won't be writing drivers for OMAP devices much longer. Which means, as the Linux kernel progress, drive development may not. Looking 5 years down the line, this could get tricky, particularly considering TI's management of its own code base.

Not to say that BB is not a fine development platform. It is just not something I would pick up for a new design. This is coming from someone who has 3 Beagle Bones sitting his desk.

As far as unit availability, Special Computing is ramping up production and already surpassed all the other BBB manufacturers combined. Last I heard, they were over 120k per month production, the vast majority of which is going into mass-production doo-hickeys from various manufacturers.

Interesting. I can't say that I know of any products that are shipping Beagle Bones. Most that use the 335x will use embedded modules (usuall DIMMs) with NAND, from manufactures that assure reliability, usually at a much lower price point. The Beagle Bone itself is a reference design, and I've seen a few cases where the circuit is just put down on a larger board with other stuff.

I'm sure that TI will be making 335x until people stop buying them. TI generally doesn't EOL parts like that. But putting whole BBBs in products seems a bit risky for a lot of other reasons.

Re:Save yourself some pain ...

[geoskd]

Citation please.

The vast majority of cell phone makers use ARM based processors, and with Smartphones, battery life is a gigantic deal breaker. This would suggest to me that large numbers of design engineers concluded that ARM was at the very least "good enough" in power efficiency to allow its use.

This leads me to conclude that either ARM is better in this department, or that the difference is trivial enough that other trade offs make it worth it.

Re:BBB

[geoskd]

I'm sure that TI will be making 335x until people stop buying them. TI generally doesn't EOL parts like that. But putting whole BBBs in products seems a bit risky for a lot of other reasons.

As opposed to undertaking to spin your own processor board? The BBB is a complete functional platform that is cost competitive for all but the largest quantities, and shows all the signs of being at the beginning of its life-cycle. Its undergone 2 minor revisions in 12 months, and there are several active design communities. The list of peripherals is growing by leaps and bounds. Lastly, by Beagleboard.orgs own accounting, the demand far exceeds the supply, and people are clearly using them as more than just a prototyping platform.

It all goes back to time to market. These things allow even relatively inexperienced users to build off a powerful platform and create good-enough-to-market products that can be ready to ship in a fraction of the time. Dev houses using the BBB and RPi as base systems are going to eat everyones lunch. It is the comoditization of embedded hardware design. It was bound to happen sooner or later. the RPi started it, but the BBB brought enough IO channels to really get the ball rolling..

Board with a Display System or without?

[billstewart]

One of the cool things about the Beaglebone Black and the Raspberry Pi is that they've got GPUs powerful enough to drive an HDMI display, and give you 1080p graphics if you make sure there's enough electric power and not too much interference (my RPi was a bit wonky on the last display I tried), so you can drive a decent monitor for programming or use it as a TV video player.

But if you don't need that, because you're doing X windows or just doing a bunch of ssh terminal sessions, you've got more potential choices, possibly lower power, possibly more memory. It depends a lot on what the target platform for your development is going to be, and on how much effort you plan to spend getting things set up, compared to just taking the BBB or RPi and calling it a day.

Don't count on good OSS support

[aNonnyMouseCowered]

"Rockchip RK3288 is coming, should be affordable, and the company is spending a lot of effort making sure it's well supported in mainline."

Citation needed. Mind supporting your statement with a link? AFAIK RK has one of the poorest FOSS support among Chinese SOC makers (compared to Allwinner and Amlogic). The RK source code floating in the net tend to be "leaks" or in any case releases that aren't official supported by the company. Also for a long time there was no official way to flash firmware onto the embedded flash storage of an Android device unless you use RK's Windows only firmware tool. (This changed recently with the appearance of a binary only Linux upgrade tool.) Opensource RK flash tools are quite limited in that they are unable to partition the flash storage or to change the bootloader, needed when upgrading between incompatible Android versions or loading desktop Linux.

It's a tool vendor, not a target, issue.

[Ungrounded Lightning]

But you see you are in the Windows CE embedded niche. Your vision is clouded.

I'm not in a "windows CE embedded" niche and the grandparent poster is right.

It's not an issue with the target. It's an issue with the platform(s) supported by the development tool vendors and the chip manufacturers.

For instance: With Bluetooth 4.0 / Bluetooth Low Energy (BLE), two of the premier system-on-a-chip product families are from Texas Instruments and Nordic Semiconductors.

TI developed their software in IAR's proprietary development environment and only supports that. Their bluetooth stack is only distributed in object form - for IAR's tools - with a "no reverse engineering" and "no linking to open source (which might force disclosure)". IAR, in turn, doesn't support anything but Windows. (You can't even use Wine: The IAR license manager needs real Windows to install, and the CC Debugger dongle, for burning the chip and necessary for hooking the debugger to the hardware debugging module, keeps important parts of its functionality in a closed-source windows driver.) IAR is about $3,000/seat after the one-month free evaluation (though they also allow a perpetual evaluation that is size-crippled, and too small to run the stack.)

The TI system-on-a-chip comes with some very good and very cheap hardware development platforms. (The CC Debugger dongle, the USB/BLE-radio stick, and the Sensor Tag (a battery-powered BLE device with buttons, magnetometer, gyro, barometer, humidity sensor, ambient temp sensor, and IR remote temp sensor), go for $49 for each of the three kits.) Their source code is free-as-in-beer, even when built into a commercial product, and gives you the whole infrastructure on which to build your app. But if you want to program these chips you either do it on Windows with the pricey IAR tools or build your own toolset and program the "bare metal", discarding ALL TI's code and writing a radio stack and OS from scratch.

Nordic is similar: Their license lets you reverse-engineer and modify their code (at your own risk). But their development platforms are built by Segger and the Windows-only development kit comes with TWO licenses. The Segger license (under German law), for the burner dongle and other debug infrastruture, not only has a no-reverse-engineering clause but also an anti-compete: Use their tools (even for comparison while developing your own) and you've signed away your right to EVER develop either anything similar or any product that competes with any of theirs.

So until the chip makers wise up (or are out-competed by ones who have), or some open-source people build something from scratch, with no help from them, to support their products, you're either stuck on Windows or stuck violating contracts and coming afoul of the law.

Re:It's a tool vendor, not a target, issue.

[goarilla]

What about consumer electronics (washing machines, microwaves, smartphones, routers, AP's) or critical industrial systems
where I would image RTOS to be necessary (VxWorks, QNX) ? I can't imagine Windows CE dominating in those spaces.

Re:BBB

[linearz69]

Dev houses using the BBB and RPi as base systems are going to eat everyones lunch. It is the comoditization of embedded hardware design. It was bound to happen sooner or later. the RPi started it, but the BBB brought enough IO channels to really get the ball rolling..

The comoditization of embedded hardware designed happened over a decade ago. Have you heard of Kontron? PC104? Com Express? You seem to have missed the 2000's.... this is nothing new. These days it is amazing what is put on a DIMM module - far more than the Beagle Bone and Pi toys provide and at far lower unit prices.

I heard the phrase "People using tool / platform / programming language / development process / telescopic fork are going to eat everyone's lunch." at least three times a year for the past 15 years. It is good evangelist speak, but rarely does it translate to reality... When it does, usually some other high barrier of entry is involved - a large amount of capital, good connections, or some wicked smart technical genius. Nobody eats anybody's lunch when it is so easy that any inexperienced person can do it.

And those who put hobbiest toys booting off MMC devices into products for sale, because they can't figure out how to port to a DIMM module or spin a board with a reference design, will be lucky to score on a dumpster dive.

Re:BBB

[geoskd]

The comoditization of embedded hardware designed happened over a decade ago. Have you heard of Kontron? PC104? Com Express? You seem to have missed the 2000's.... this is nothing new. These days it is amazing what is put on a DIMM module - far more than the Beagle Bone and Pi toys provide and at far lower unit prices.

The commoditization of these designs depended on several factors happening all at once.

First, processor power had to pass a threshold. Having a processor that is fast enough to handle an embedded system running a custom operating system (or more likely just a simple set of interrupt handlers and startup code) is a lot slower than the processor needed to run a full fledged kernel like modern Linux. The custom Software saves huge amounts of unit-cost, at the cost of time-to-market.

The second item that was needed was price point. Even $45 per unit is still high for the BBB black, but the RPi at $35 is pretty close. Even the BBB is close enough to work with.

Third, mainstream OS support. This is critical, because it turned a legion of higher-level programmers into embedded programmers. This, again, helps to reduce TTM

Last, the availability and maturity of simple to wire peripherals, and the availability of software libraries for using these peripherals. This is probably the most key part because you now have the ability to buy a modular set of components, and wire them all together with very little, if any, electronics knowledge and get a working system. Again, it all drives TTM, and in todays world TTM is everything. Just ask Microsoft how their tablet and phone business' are doing to find out how important TTM really is.

It has nothing to do with the target.

[Ungrounded Lightning]

What about consumer electronics (washing machines, microwaves, smartphones, routers, AP's) or critical industrial systems
where I would image RTOS to be necessary (VxWorks, QNX) ? I can't imagine Windows CE dominating in those spaces.

You seem to be missing something here.

We're not talking about the target. We're talking anout the platform on which the program for the target is built.

This is where the editors, version control system, compilers, linkers, profilers, prom burners, in-circuit emulators, etc. are running. The operating system here has no more to do with the operating system on the target (other than supporting the tools that build it) than the operating system on the mainframe where Gates and Allen developed Altair BASIC had to do with the BASIC language or the guts of their interpreter.