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]

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

Re:Weird question, but...

[Anonymous Coward]

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

Re: Weird question, but...

[Anonymous Coward]

Because electricity is expensive. Douche bag.

Re: Weird question, but...

[Anonymous Coward]

Because electricity is expensive. Douche bag.

As if the operating power savings for something esoteric is really worth it compared to a simple laptop. He can probably even get a used laptop for free, which would more than compensate for any difference in power consumption costs.

Twat.

Re: Weird question, but...

[Anonymous Coward]

I think you need to reign in your vocabulary until you learn what the words mean. The word esoteric in that context makes no sense whatsoever.

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

[Anonymous Coward]

That would be "rein" in, as in the reins of a horse, Mr Vocabulary...

Idiot.

Re: Weird question, but...

[Anonymous Coward]

"I'd like to have a dedicated Linux based dev system which has good support for ARM". Nah, I'm also not seeing how "esoteric" makes sense here. Has Slashdot strayed so far from the path that we truly believe that Linux and/or ARM are esoteric?

Re: Weird question, but...

[Anonymous Coward]

No, it's not, not even if you pay 30 Eurocents per kWh. A typical quadcore Intel system can be built to have an idle draw under 20W. Power consumption under load is better (compared to the processing done) for Intel desktop processors than for low power embedded systems, and load power consumption does not dominate the average consumption for anything but heavily loaded servers. What does the idle load cost you per year, assuming you leave the system on around the clock? 0.3EUR*0.02kW*24h*365=52.56EUR. The power consumption costs less than the incredibly cheap hardware over a couple of years.

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

[Anonymous Coward]

On the incredibly cheap bit: Of course an Intel quad core from the low to mid range is incredibly cheap, absolutely and relatively. If you can't afford that kind of computer, what are you doing that requires a computer at all? There's no cheaper alternative if your time isn't free. You'll need to lower your requirements a lot to save very little on price. And relatively speaking, an Intel quad core desktop system can be cheaper than a fancy tablet that isn't even in the same league or in the league next to the one where you'd find a desktop system. Mobile comes at a hefty price premium.

On the power bit: Sure, if you have to make your own electricity, every Watt counts. Why you'd want a 24/7 developer system in addition to a Solaris desktop off-grid in rural Scotland though is beyond me. If you have internet access, why not electricity?

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

[Anonymous Coward]

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?

Re: Weird question, but...

[Anonymous Coward]

You forgot to add a random insult term to the end of your post. You'll find a nice selection of them on the urban dictionary.
  Dick cheese.

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.

Re: Weird question, but...

[Anonymous Coward]

As I wrote earlier, a modern Intel quad core system can be built to consume less than 20W idle measured on the mains side of the power supply (no mobile platform CPUs necessary)*, and the load power efficiency of Intel desktop CPUs is exceptional, so you really get your power's worth there. If you want to split the applications for security reasons or because you need them in physically different places, that's one thing. If you split them to save power, that's not efficient. You could probably run your server loads and Eclipse on something like a NUC or a Zotac nano and not consume more than 10W plus whatever your disks need. That would cost you less, both in terms of power and initial investment, than three ARM systems. I like, have and constantly use a couple of ARM boards. Power and cost are no longer good reasons for that though.

*) German magazine c't published a recipe for an 11W PC with 8GB RAM and an i5-4570 quad core CPU. (in German, article not freely available)

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

[Kelxin]

Why do people always as WHY someone wants something?! I see it over and over throughout the internet, they asked for something specific!

Can't help them?
THEN DON'T ASK WHY.

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

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.

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

[Anonymous Coward]

du jour

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

[Rockoon]

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?

It really isn't.

A ran into a fine example of why you are wrong just last week.

I was looking for a way for a .NET library developer to specify a type contract that included a non-default constructor with a specific prototype/signature. Now for some this may sound like an Interface, but others will argue that Interfaces should not specify implementation details and they (rightly or wrongly) include constructor prototypes as an implementation detail and argue that this is why interfaces should not (and do not) define constructor prototypes. The questions that appear throughout the internet (on msdn, stackoverflow, etc..) always involved the use of generics and so did the usage I had intended, so of course generic type constraints also came up. Quite specifically my need (and many others) is to develop a library which can construct generic types, however there is another related class of problems dealing with operator overloading that also spawns a similar set of questions based on the same framework limitation.

It did not matter how accurately anyone had described their need to define a constructor signature contract. Every discussion devolved into the same lesson about why interfaces shouldn't specify constructors or any other static functions and methods.

Every single time it was suggested that the person asking the question include a non-static method in the interface which could then construct the type. When it is pointed out that that would require an instance of the type to begin with, it then occurs to these people you suggest coddling, "have you tried the factory pattern?"

Isnt that what they are trying to implement? sigh...

So then the discussions devolve into these people devising more and more complex contortions to defend their belief that interfaces should not ever under any circumstances leak any implementation detail so therefore the questioner is wrong about needing a constructor contract, as if one actually led to the other. Quite remarkably they suggest alternatives that leak far more implementation details the other direction.

They just cannot imagine the need and no amount of explaining will get them to acknowledge that there really is one, therefore its all about something unimportant like the philosophy of interfaces rather than an alternative method of enforcing a constructor contract in the setting of a generic type constraint.

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?)"

You sit here defending that behavior on the grounds that you also default to the position that you understand the questioners needs better than they do, and I know why.

You learned that you shouldnt pretend to have answers that you don't have... but you've not handled that knowledge correctly. The proper course of action is to acknowledge to yourself that you don't have the answer, rather than attempt to alter the question so that you do have the answer. When you try to alter the question, it stops being about you helping the questioner and starts being about you helping yourself look smarter.

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]

Only the competent ones.
As the question clearly indicates even the incompetent ones can and do post to Slashdot.

Answer #1: install the GNU tools and learn the difference between --host and --target
Answer #2: wipe the Solaris install and drop a sane linux distro on the box.
Answer #3: get a fscking *fast* amd/intel machine that can do a Yocto (or buildroot) embedded from scratch in a few hours. [I use an 8 core AMD w/SSD and 32gb RAM - make -j32 or higher is fine .. just watch the free RAM and the the CPUs burn :-)]
Answer #4: if you cannot learn the difference between --host and --target then *at least* get an embedded option with a SATA controller. Wandboard Quad or similar.

IMO: Avoid TI at all costs. Freescale is the most open and best supported of the A9 cores that I use. Odroid can get you a faster processor but not as open or general purpose as Freescale. TI is an unsupported mess. NVidia is very closed. The radxa looks promising but the chip (video encode/decode/egl) is not as capable as Freescale.

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

[Anonymous Coward]

I agree, the question didn't even include weight restrictions or the need for radiation hardened, there was also no mention of the number digitial i/o pins needed or even wind river

Re:Solaris not well supported by OSS toolchain

[Anonymous Coward]

You've got to admin, the requirements sound fishy. A low-power machine on which to develop? That's an odd requirement. Most developers want high power machines on which to develop so that they can run bulky IDE's, compile quickly, and do integrated debugging. A low power embedded platform makes perfect sense, but needing a low power platform on which to develop embedded applications is a quirky requirement at best.

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

[Anonymous Coward]

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. We're not asking to give us your source code, architecture diagrams or other documentation, we just want a clearer picture. The OP's question states: embedded systems, linux, ARM, and low power. There is a plethora of tools that meet those requirements, but OP also stated they wanted a development environment, which clashes with a lot of the aforementioned. Why can't you have a laptop or 200W desktop PC for development? Even if the embedded system can only draw 10W max, you can certainly develop software for it on a more powerful machine. I know that because I've developed for various embedded systems(and it's one of the things that sticks out as a red flag in OP's description).

But at the same time, OP is asking for a device that will do development and testing. What does he mean by that? Surely you can test parts of your code in your development environment, but ultimately testing will be done on the embedded target device.

In essence, what OP is asking is: "What is an embedded device that allows me to write software, test it, and uses under 10W". Most notably, that's a question that Google can answer. You go out, you search for the beagleboards, the raspberry pis, and the arduinos of the world, and you pick one that fits your needs. But he's asking slashdot: what's the best? Well, best for what, exactly? A hammer is the best at hitting in nails. A saw is best for cutting down trees. What is the best tool for putting two pieces of metal together? I'm not a structural engineer, but I remember a case study on my university campus with at least 13 different ways of combining two pieces of metal. Rivet gun? Welding torch? By asking questions, we can figure out which method is best for what OP is actually doing.

You sit here defending that behavior on the grounds that you also default to the position that you understand the questioners needs better than they do, and I know why.

That's literally the exact opposite of what our position really is. We don't know what OP wants, in fact we have a complete lack of understanding of what OP wants due to a lack of detail. We hear red flags in these kinds of questions, so we ask about them to see what the OP really wants. Sometimes the OP is on the right track, but usually not.

For your interface example, I'm on the side of the "other" people. There's no reason to be constructing objects in an interface, that is not what they're designed for. What you're suggesting breaks the language just as much as interpreting strings as integers. "2" + "4" should not equal "6", even if you found a use case for it; there are other ways of solving that kind of problem(like syntax trees). For those of us who have used .Net for years, what you're suggesting is a bad code smell, and it sounds like what you want is actually inheritance. If I had to guess, a pure virtual init(string[] params) or the like would be the route to go, but I wouldn't even go as far as to make a super class with an init(string[] params), because that feels like a superfluous use of inheritance if not entirely wasteful. I would simply make it a requirement that the classes in folder X implement that function. There are static analysis tools that could help you do that, which would be a form of "contract" even if it's not explicitly in the code. But without asking questions, I couldn't even begin to advise you one way or another.

Also, the problem is not "leaking implementation details". It's perfectly fine for class MyFoo to leak implementation details of class MyFoo. In fact, unless MyFoo is entirely private and offers no API whatsoever, it will necessarily leak details about its implementation. It makes far less sense for IFooBar to leak details about MyFoo, because that implies IFooBar is tightly coupled with MyFoo, and if that's the case

Re:Solaris not well supported by OSS toolchain

[Anonymous Coward]

OTOH, maybe he just doesn't know WTF "embedded" really means and is just tossing out the buzzword du jure

pot, meet kettle.

"de jure" vs. "du jour"

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

[Anonymous Coward]

It's normal to have follow up questions, especially when a question is poorly-written. The question as written literally sounds like he wants his dev system to be low-power, where the guy does his work while sitting in front a computer as underpowered as the embedded systems that he's deploying for customers -- his beagleboard would literally be running vim and gcc. Don't you think that seems a little strange? Most people probably suspect he might really be asking for a way to develop for low-power systems. i.e. maybe he just needs a handy way to cross-compile to ARM object code on his hundred-watt hex-core i7 at his office which is on the big public power grid, and he's going to be reselling beagleboards, preloaded with his software, that run off solar panels or batteries. That's more believable and it's also something a lot people wouldn't know how to get started on, because cross-compiling is outside many people's usual way of doing things.

And yes, the question is poorly written. WTF is the bit about Solaris about? It's seemingly totally irrelevant, yet he mentioned it. Is it a clue or a red herring? Might it be that he wants his dev system to actually be running Solaris, but outputting binaries for ARM Linux or something? No, probably not, but maybe.

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

You misdiagnosed the motivation. People communicating poorly is something that happens many times more often than "smarter" people correcting "dumber" people. Asking "why" is a way of teasing more info out of the guy or helping him realize that he needs to try again with the presenting his problem.

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

[Anonymous Coward]

For what are you asking a jackass advice?
You get the answer you deserve if you're not willing to help that jackass help you.
It especially servers you right if the answer is brilliant based on the information you deigned to supply, but is way off base because some bits of info you were too busy/offended/arrogant to clarify were actually important for the answer.

Re:Solaris not well supported by OSS toolchain

[Anonymous Coward]

In some cases, though, there's some benefit in letting people make mistakes since they learn better by doing rather than by being told. Give him the model number of a good hammer. When he realizes he can't chop down trees, hopefully he'll learn to ask a more appropriate question.

I've seen the opposite issue play out: Someone is on step 18 of 20, can see the end point but realizes he needs an additional tool to finish step 18. Said person seeks help from an expert, who immediately asks "why" or "what are you trying to do", and want to start over at step 1 and rehash everything, wasting time, only to eventually end up taking the same path to step 18. Once that gets resolved, all of those people then proceed to step 19 where they need to ask for something from yet another expert, who of course wants to immediately start over at step 1 and rehash everything.

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

With Ubuntu. BBB

[Anonymous Coward]

Now that Ubuntu can be had with ease on the Beaglebone Black it is a good bet. Mine sits at the end of a ssh connection and I use the USB port for a storage device connection. The new BBB version is popular and hard to find but the extra flash is nice. Raspberry Pi has the richest software universe and by swapping out one SD card for another you can switch projects... (The BBB is almost as easy). BOTH are bargains and recommended. Have fun...

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

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

[Anonymous Coward]

^ This. I just bought one of these and it's an incredible machine for its size and price. TONS of I/O options (not sure if that matters to you) and a small, fanless, X86-compatible board. I've read you have to jump through some hoops to get Linux installed properly on it (due to the BIOS) but once you get past it, it's a great little machine.

Re:Intel NUC

[Anonymous Coward]

NUC overheats, doesn't come with RAM nor SSD, and is more expensive than a regular low-end laptop.

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

[Anonymous Coward]

The Celeron N2830 is a dual core processor by the way. The quad core is called Celeron N2930.

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

[Anonymous Coward]

He's not looking for an embedded system. He's looking for a system to do software development on. He wants to run the toolchains for ARM and other embedded CPUs which are unavailable on Solaris. Apparently he doesn't want a full desktop because he already has one (the Solaris system) and wants to keep it.

Re:Intel NUC

[Anonymous Coward]

>The Beaglebone Black has been suggested. Is there a better choice?
Maybe he is looking for an embedded system.

Re:Intel NUC

[Anonymous Coward]

If he is, then he should say so. There is no system which is built on "ARM, MSP430 and other MCU lines" at the same time. Those are his specified target platforms. Nothing in his question requires an embedded system. He mentions one which would satisfy the requirements, but that doesn't mean that other options also have to be of the embedded kind. I guess people just aren't aware that "less than 10W" doesn't exclude full-fledged Intel desktop systems anymore.

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.

Cheap windows laptop

[Anonymous Coward]

The tools are slowly moving over; but embedded development is still really a Windows world.
All the 3rd party tools work on Windows. Only some on OSX, Linux.

In our embedded consulting company, it's all Windows to cope with the 20 or so different processors at any one time.

Re:Cheap windows laptop

[Anonymous Coward]

wut

Re:Cheap windows laptop

[goarilla]

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

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.

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

[Anonymous Coward]

...got a c2d 2010 13" macbook pro for c.$250, upgraded it to 16GB RAM(have to watch models as IIRC only one of the 2010s could handle 16GB)... P8600, so no speed demon but it'd get the job done...

Re:Buy a netbook

[Anonymous Coward]

Nope, but a chromebook gives 2GB of ram.

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.

Re:Shuttle DS437!

[Anonymous Coward]

That's a great setup! There's also this motherboard by ASRock that has a laptop power input. It uses the new quad-core Athlon (25 watts)...

http://www.newegg.com/Product/Product.aspx?Item=N82E16813157491

http://www.newegg.com/Product/Product.aspx?Item=N82E16819113364

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

Here is a pretty complete list

[Anonymous Coward]

This is the most complete list of embedded linux systems I have seen:

http://linuxgizmos.com/rate-your-favorite-open-single-board-computers/

odroid u3

[Anonymous Coward]

http://www.hardkernel.com/main/main.php

Re:odroid u3

[Anonymous Coward]

Look around and there's a Debian release for it too.
I've been running one for a while and love it. Quad core 1.7GHz, 2GB RAM.

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.

Re:Best

[Anonymous Coward]

Emacs! Oh wait, wrong flame war..

fgadfzsdfvdfvzdvd

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

[Anonymous Coward]

The beagle bone and the bb black are more about embedded and gpio, if you want to hook up 5 stepper motors and a bunch of sensors you will be pushed to do it with SoCs that are optimised as little pcs, and dont breakout gpio. Its why an arduino still beats a raspberry pi for many applications, a mega2560 gets you 54 programable i/o lines, some pwm, some analog in/out, some pure digital i/o . The due does the same as a mega2560 but with an arm processor. You wont find an hdmi or ethernet port on these boards but thats not what they are for.

Re:The Differentiators are SoC Peripherals...

[Anonymous Coward]

Portions of this are incorrect...TI just released a new broad market "OMAP" device not 2 weeks ago and others are on the roadmap.

Google AM437x for more details...A9, 1GHz, xHCI, etc.

TI+ARM is alive and well.

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.

For anyone looking for x86 options

[Anonymous Coward]

The PC Engines APU board is pretty damn spiffy.

http://www.pcengines.ch/apu.htm

6"x6" board, AMD G series T40E APU 1 GHz dual core processor, 2 or 4 GB of RAM, GPIO, 2 miniPCI expres slots, SD slot, three gigabit ethernet ports, plus other features, and uses 6-12 watts of power. Depending on what board and accessories are selected It's in the $150-$250 price range.

Jetson TK1

[Anonymous Coward]

Can't beat 4+1 nice cores, 192 cuda cores, usb3, gig-e, real sata, on and on...

Re:Jetson TK1

[Blaskowicz]

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

Re: Jetson TK1

[Anonymous Coward]

To get the cuda development suite, for sure. Possibly to get other nvidia binaries. But it's free to register, it's just an account in their portal system.

The TK1 base model can be bought by anyone, although advertised as an automotive development board. The pro model with expansion boards however, was industry only last time I checked

Install Linux in a VM

[Anonymous Coward]

Install Linux in a Virtual Machine on your Solaris box. Any reasonably modern hardware (ie., Core 2 Duo or newer) should have hardware support for virtualization. Pass through the USB device of your microcontroller to the VM to program it.

Hardware cost: $0

Effective power use: minimal

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

Save yourself some pain ...

[Anonymous Coward]

And use an atom box which meets your power envelope. Having worked on different embedded systems, I have to be honest that unless you need really low power performance best to stay with x86. x86's best selling point ... it is very well supported across the board. 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.

It is funny how quickly you realize you are doing make work stuff when you constraint yourself in terms of budget and time. This doesn't mean that you still don't have some opportunities for learning or development, it just means you get the platform issues out of the way very quickly and focus on the value add.

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:Save yourself some pain ...

[Anonymous Coward]

ARM is slow and power inefficient under load.

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.

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:Why ?

[Anonymous Coward]

Lol, seriously. I was doing native development of OpenCV code on a Raspberry Pi in QT4. You can probably imagine my compile times. It was like I went back in time and got to experience "the good old days" I always heard the age discrimination victims wax nostalgic about in my CS classes.

You can make a normal desktop that is low power

[Anonymous Coward]

The J1800i board has a 10 watt TDP processor, see http://www.asus.com/Motherboards/J1800IC/

Considering the hatred Republicans have...

[Anonymous Coward]

for anything that isn't Intel x86, none of these systems are going to be allowed to be successful. Just buy one of the power hungry Intel low-performance per Watt CPUs and be happy.

Re:Best

[Anonymous Coward]

That's vi, you insensitive clod!

Teaching a man to fish

[Anonymous Coward]

It's meta-helping. You find out why they want to do (possibly stupid) thing X and then you help them do related (presumably clever) thing X' instead.

Or are you saying it's never appropriate to suggest to someone that they do something different simply because it's better? People with their head in the sand have to be helped to breath sand rather than told how to pull their head out?

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.

cubie board

[Anonymous Coward]

I was in the same position. I have a Mac laptop an ubuntu laptop and a Windows laptop. All for different purposes. I bought a cubie board for dedicated arm development and love it. It's perfect.

Zone

[Anonymous Coward]

Run Debian in a Zone. You can cross-compile what you need.

rasberry pi?

[Anonymous Coward]

It depends if the box is just for compiling or also for testing.

If it's just for compiling then you can get some supercheap desktop pcs these days.

If you also want a development board to do some testing then linux gizmos is a good source of information
http://linuxgizmos.com/top-10-hacker-sbcs-survey-results/
http://linuxgizmos.com/rate-your-favorite-open-single-board-computers/

Of course, there is always the Rasberry pi.

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

Weird question, but...

[Anonymous Coward]

I think the question is qeird because ARM and MSP430 are two completely different architectures. I'm not sure if the submitter is asking for a host system, in which case any laptop that can run Linux will do fine, or an actual target device, in which case there is none for both MSP430 and some ARM flavor. You can get one dev board for each.

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.

for data aquisition get Arduino

[Anonymous Coward]

For microserver try:
Arduino Yun of you need wifi and limited resources.

Beaglebone Black for more horsepower or Beaglebone of tou prefer to boot/reimage from sdcard .

RPi's CPU is very slow.

And for generic development get a microinstance in the cloud. Power consumption zero.

Recommendation for Big-Endian dev board?

[Anonymous Coward]

Similar to OP's question, what would be a good linux-based board for a Big-Endian CPU ?

Seems like all the ARM boards are little-endian (though ARM itself is bi-endian, the boards are configured as little-endian).
Preferably 64-bit, bit 32-bit will do in a pinch.

Many people recommend simply getting an old G4/G5 macs, but I'm looking for a product that's not 10 years old...

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

[Anonymous Coward]

Are you a vi user ?

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:Best

[Anonymous Coward]

pico!!!

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.

Wandboard

[Anonymous Coward]

Take a look at the wandboard quad core http://wandboard.org it's a dinky ARM board with lots of IO and includes SATA support, wired and wireless ethernet along with a couple of SD card slots.

I'm running my server at home off one and it works beautifully on ArchLinux|ARM, I highly reccommend it!

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.

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: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!

Probably a Raspberry Pi

[Anonymous Coward]

A pi runs around 500ma, so that's 2.5 watts. The good thing about it is that you can develop - code/test - on a regular Linux desktop and then just recompile on the pi. I have several pis running on a solar panel + batteries. If you need A/D or PCM or something - just add a Atmega 328 (arduino). For simple inexpensive, low power, internet connected devices you can't beat this. A quad core is almost certainly going to take more power but there are a lot of pi compatibles with faster CPUS, more RAM and more power + more $.
.

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.

Just get one of these. It's not arm though. But...

[Anonymous Coward]

Otherwise it's perfect.

http://www.pcengines.ch/apu.htm

Re:Best

[Anonymous Coward]

You're all wrong. Real power users use ed!

Use Case not defined

[Anonymous Coward]

Guys, (and gals, trans, whatever)
Having such a low power draw could be a result of the imagined use case: will this device be used on a boat, third world country, powered by windmill or solar panel and batteries? The given OS requirement could simply be an extension of an existing project. I know how annoying it is to move decades of programs between windows and Linux, and that is just my civilian stuff.

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

check linux support!

[Anonymous Coward]

* raspberry pi because of the community
* if that's too low spec'ed then the hummingboard has a similar form-factor and packs a bit more punch (http://www.solid-run.com/products/hummingboard/)
* odroid u3 + io shield gives you even more computing power (quad core A9 + 2gb ram) with arduino compatible pins + its own GPIOs http://www.hardkernel.com/main/products/prdt_info.php?g_code=G138760240354
* if you want even more power, odroid xu3 gives you 8 cores running at the same time + 6 core GPU with openCL and has a decent array of connections (30 pins) + it has integrated power monitoring for the CPU, GPU and memory - though it's a bit more expensive http://www.hardkernel.com/main/products/prdt_info.php?g_code=G140448267127
* there is also the nvidia jetson tk1 - also A15 and more expensive - but it does run "desktop" openGL https://developer.nvidia.com/jetson-tk1

there are a lot more boards, but I think the above have some of the best linux support - most of the others have it all working just in Android...

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.

Anything anyone tells you will be wrong in 6 month

[Anonymous Coward]

The pace of new processors and the rapid change of "lowest power" changes so often it's meaningless to ask this - it WILL change every 6-12 months.

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.