Faken,
The UBW32 is a very good way to go, from what I can tell of your requirements. It will support exactly what you need, as long as you're OK with 3.3V I/O (some are 5V tolerant, but not all.) It is inexpensive ($40) and is very easy to talk to using any language that can support serial ports (which is pretty much all of them - Basic, C, C#, Processing, etc.)
You can use any of the 76 I/O pins as inputs or outputs. The stock firmware as shipped will allow you to do what you want to do, no programming required on the embedded side. Getting that data up to the PC over USB (at only 10Hz) will be no problem. Getting outputs to go at 1KHz will probably work just fine as well.
If you have any questions, please let me know. I'm happy to help you out.
*Brian Schmalz
UBW32 creator
Am I correct that the faster processor draws more power (and thus
dissipates more heat) under a computational load?
Not necessarily. There are two major components of power dissipation - static power (the power you burn when the chip is on) and dynamic/switching power (the power burned when the clock is running). While running the same chip at a higher frequency will result in more power dissipation, a chip may have a static power dissipation that is too high when combined with the faster clock rate to meet the bin requirements for the faster rating.
If so, is the power under computational load approximately
proportional to the rated/clocked frequency? In other words, inasmuch
as the one processor is clocked 8 percent faster than the other, does
it run about 8 percent hotter under load? Another way to ask the same
question is to ask: does each processor process about the same
quantity of data per unit of energy? or, if battery powered, can each
accomplish about as much before its battery dies?
For a given chip running identical calculations, the dynamic portion of the power consumption will be proportional to the clock frequency. The total power dissipation of the processor will increase a bit less than 8% for an 8% increase in clock frequency due to the static power dissipation.
When not under load, do the two processors idle equally cool, or are
there practical or theoretical factors that make the one idle cooler
than the other?
If you had two identical chips idling, the one with the lower clock frequency would dissipate less power. When the chips are idling, the static power becomes a much larger portion of the active power dissipation, so any differences there would be more noticeable.
Even if the processor's price were not determinate, might one prefer
the slower processor merely for the sake of cooler operation and
extended battery life?
Possibly, but again, you have a lot less of a guarantee that this would be the case. If you bought chips with different rated TDPs, then you could safely make this argument. Otherwise, you're at the mercy of the binning algorithm and the consistency of the manufacturer's process. Also, note that we're talking about power dissipation, not energy consumption. A faster processor may be able to complete a computationally heavy task faster, and switch to a low power idle mode sooner than a slower processor.
Would the answers differ for embedded processors?
Yes. The static power dissipation is most significant on the bleeding edge processes that Intel, TSMC, IBM, and Global Foundries use. Embedded processors are often optimized for low static power dissipation and use larger processes where static power dissipation is a much smaller portion of power dissipation. The variation at those larger process nodes is much less, so microcontrollers are much less susceptible to variation in power and frequency performance.
Best Answer
There are other factors that contribute to the speed.
Memory: Actual performance is often limited by memory latency. Intel CPUs have large caches to make up for this. Microcontrollers usually don't. Flash memory is much slower than DRAM.
Power consumption: This is often a big deal in embedded applications. Actual 200 MHz Intel CPUs consumed more than 10 watts (often much more), and needed a big heat-sink and a fan. That takes space and money, and it's not even counting the external logic and memory that went with it. A 20 MHz AVR takes about 0.2 watts, which includes everything you need. This is also related to the process -- faster transistors tend to be leakier.
Operating conditions: As Dmitry points out in the comments, many microcontrollers can operate over a wide voltage and temperature range. That ATMega I mentioned above works from -40C to 85C, and can be stored at anything from -65C to 150C. (Other MCUs work up to 125C or even 155C.) The VCC voltage can be anything from 2.7V to 5.5V (5V +/- 10% for peak performance). This Core i7 datasheet is hard to read since they trim the allowed VCC during manufacturing, but the voltage and temperature tolerances are certainly narrower -- ~3% voltage tolerance and 105C max junction temperature. (5C minimum, but when you're pulling >100 amps, minimum temperatures aren't really a problem.)
Gate count: Simpler isn't always faster. If it were, Intel wouldn't need any CPU architects! It's not just pipelining; you also need things like a high-performance FPU. That jacks up the price. A lot of low-end MCUs have integer-only CPUs for that reason.
Die area budget: Microcontrollers have to fit a lot of functionality into one die, which often includes all of the memory used for the application. (SRAM and reliable NOR flash are quite large.) PC CPUs talk to off-chip memory and peripherals.
Process: Those 5V AVRs are made on an ancient low-cost process. Remember, they were designed from the ground up to be cheap. Intel sells consumer products at high margins using the best technology money can buy. Intel's also selling pure CMOS. MCU processes need to produce on-chip flash memory, which is more difficult.
Many of the above factors are related.
You can buy 200 MHz microcontrollers today (here's an example). Of course, they cost ten times as much as those 20 MHz ATMegas...
The short version is that speed is more complicated than simplicity, and cheap products are optimized for cheapness, not speed.