Which Power Processor Board?

The biggest problem regards adding more processing power is the amperage used by the board. Some of these power-user boards are also very power hungry - 1 to 2 Amps or more. Might be ok if your bot is large enough to lug around a good-sized SLA battery, etc. A large enough bot can lug a notebook PC.

To me, the major factor involved in the "next level" of tasking above the basics is mainly in how much RAM you have, not so much how many MIPS. For monster jobs, like vision processing, then MIPS will become the major issue.

But, for in between stuff, something like the Rabbit might do ok. You can get 512KB of RAM and current draw is only 50 mA or so. But you won't have the MIPS as with some other cpus.

- dan michaels

=====================

I wrote a book about more or less this topic. I selected the Advantech PCM-5280 3.5" biscuit PC, running Linux (off a CompactFlash card) for this task.

However in my application, the PC was really just the tip of the iceberg in terms of power consumption. Also it was strictly for a prototype.

Later I wrote a series of articles for IBM's developerWorks, wherein I essentially ported all my work on the x86 board onto a PowerPC board. You can read those articles: (it's the "Migrating Embedded Linux Applications..." series). Please note that #9 was posted but I didn't add the URL yet; just take the URL for #8 and change the 8 to a 9 :)

If I had to do the same thing all over again right now, and I had a power budget, I would choose an ARM-based SBC. Olimex makes a large range and you are likely to find something of use there.

Pretty much the main reason I chose to use a PC was to get easy USB host support. Lots of stuff - webcams, human interface devices, and so on - is USB. A board like will do a lot for you.

Board has a lot of very nice features, but doesn't mention operating voltage, current draw, or how many I/O lines are available. Also, has a "p*rn" switch. That doesn't look good :).

The I/O question can be answered by the schematic, which is available there. The board runs off 5VDC, as you can see from the photo.

Current drain depends on what features you're using (for example, 10bT Ethernet will pull more current than 100bT) but you can be certain it is much less than an x86!

A p*rn switch has been, or should have been, a design requirement of every single appliance I have ever built.

There's a BUT switch, too. Lewin's just has to improve his spelling!

-- Gordon

Hey, I didn't design that board; I'm nothing to do with Olimex (except as a customer).

Oh, okay. We'll forgive you this one time!

-- Gordon

Thanks for the info!

Looks like they've got some good stuff. How well does Linux run on it? Drivers and such easy to get hold of/setup?

Gord> >

Hello,

Look at gumsitx.com. They have small boards that run on Xscale at

400Mhz, 64MB of RAM and 16MB of flash. Presinstalled with 2.6 Linux.

-Pandit

snipped-for-privacy@yahoo.co.uk wrote:

Here is one product I came across yesterday as I was browsing the Internet. It runs Linux, costs $330.

=3D=3D=3D=3D=3D=3D=3D=3D A quick overview of Qwerk's hardware features: =B7 200 MHz ARM9 RISC processor with MMU and hardware floating point unit =B7 32 Mbytes SDRAM, 8 Mbytes flash memory =B7 4 closed-loop 2.0 Amp motor controllers (supports quadrature encoder and back-EMF "sensorless" position feedback as well as current sensing) =B7 16 RC-servo controllers =B7 16 programmable digital I/Os =B7 8 12-bit analog inputs =B7 2 RS-232 ports =B7 I2C ports =B7 2 USB 2.0 host ports for connecting standard USB PC peripherals =B7 10/100BT Ethernet port =B7 Built-in audio amplifier with MP3, PCM and WAV audio support =B7 4 Amp switching power supply, 90% efficient, 7 to 30 Volt input range =B7 Rugged aluminum enclosure =B7 5.1" x 5.8" x 1.3", 12.8 ounces

Qwerk uses about 2 watts on average. Since it uses an efficient DC/DC converter, it will use the same amount of power regardless of the battery voltage. For example, if you are using a 10V battery, it will draw about 200mA. If you are using a 20V battery, it will draw about

100mA. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Joe Dunfee

Yes. Do you know what the current draw is on the gumstix? The website makes it almost impossible to find this info, or else I didn't try hard enough. When you click on "product specification", and it really doesn't tell you very much that's useful, you lose interest quickly regards browsing the site.

Yes, BUT .... what is the current draw? Can I stick this thing on my smallish bot, or do I need a bot with a huge battery for more than 3 minutes operation?

Usually labeled as POR switch in the US, rather than the other way, for obvious reasons.

Nice board, but much too big and heavy for a small bot, even if efficient on current draw.

When we're shopping for a controller, we first have to distinquish the size of the bot, and the battery load it can carry, as the primary limiting factors regards controller selection. Power and speed are nice, but different bots [small vs large vs walker] all have their size and energy limitations as the first criterion. There's a real problem in trying to stuff a huge amount of processing power onto a small bot or walker, so my point has been that suggestions for controller have to be qualified in this fashion.

I agree the web navigation is not quite friendly. This page tells what the current draws are:

It appears to mentions less than 250ma without out BT at 400Mz. It also mentions 50ms in sleep mode with comments saying that while it waits for input (not even in sleep mode)?

Regards,

-Pandit

dan michaels wrote:

Yeah - current consumption depends on the exact set of boards you have, what's connected to those boards, and what program (or set of programs) is running.

All of the boards except the robostix can run at 3.3v + about 150mV headroom for the regulators. So you're looking at about 1/2 to 2/3 watt for a minimal configuration, upto a couple or so of watts, if you have a WiFi Compact Flash card plugged in. Some of the Wi Fi cards draw several hundred mA.

The included kernel idles the CPU when nothing is happening. This stops the CPU clock until an interrupt occurs (this happens with most ARM processors running linux).

So well behaved programs which block waiting for input use less power than programs which busy wait.