Slashdot Mirror
Guide To Designing Low Power Handhelds
randomErr writes "iAppliance had a nifty article about designing handhelds. As the state-of-the-art in low-power CPUs races forward, the CPU becomes one of the most critical components in the design of a handheld. New CPUs such as Intel's XScale, Alchemy Semiconductor's Au1000, and Transmeta's Crusoe provide the ability to scale clock frequency and voltage dynamically. As power consumption varies linearly with clock speed and as the square of core voltage, you'll want to have hardware hooks to be able to adjust both clock speed and voltage as necessary, based on device performance."
haldheld like those self-winding watches? Just move it around a little bit.....andit slowl charges it, now that would be awesome!!!
Great Linux Site
CPU? most of my drain is caused by the inverter...
I know that the ability to have rechargable batteries is out there, but I've always felt it was somewhat funny that while cordless and cellular phones typically run on batteries that you charge when they're not in use, the PDAs don't come with the same option by default. I wonder why this is, and if in the future that rechargable batteries will be the norm.
How does adjusting the clock speed affect timing issues in applications (games)? If it dynamically adjusts the timing, won't this create some bizarre effects?
Just to point out to anyone who doesn't know, AMD aquired Alchemy Semiconductor.
Unless these handheld companies can figure how to improve input into these tiny little computers, it doesn't matter how fast the CPU chip is because my big mitts won't get the data into fast enough for it to matter. To me, they are nothing more than a static data storage and regurgitation device, not an interactive system like my notebook or desktop.
Strange women lying in ponds distributing swords is no basis for a system of government.
CPU power is not the issue when it comes to portable computing. The real holy grail will be in acceptable display technology. Whether that be some sort of expanding/folding display technology or a lasar retinal display, something significantly better than our current technology is needed to really make a significant jump in usability and functionality.
Its gotten to the point where CPU power consumption is so good that the real concerns in designing a low power device reside in the peripherals.
I was designing a low-power DSP application, and the CPU consumed like 24 mW at 100 mHZ. But, when I added any peripherals to it the power consumption shot up an order of magnitude. The moral of the story is that people should stop worrying so much about CPU power consumption and take a good look at trying to bring up all the things that go with a CPU to the same level.
I have experience programming for embeded systems but something that I've wanted to be getting into is designing embeded systems. Ideally what I want is a small hand size device that supports all common hookups, serial, usb, firewire, ethernet, etc. For me this would be unbelievably useful especially if it was combined with a moderatly size hd. If I could get a 5 gig hd, (ipod toshiba hd) packaged with all the connectors I'd be able to test about anything I could need at this time.
I could be wrong, but don't we need a discussion about cooling somewhere? I thought one of the key points to the Transmeta Carusoe chips was the "lower power consumption and therefore lower temperatures and therefore less power needed for cooling so therefore longer battery life." While the whole "fan" issue is a moot point, dont they have to make serious considerations about heat dissipation in handheld devices? Why isn't it dealt with in the article....
When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. (Larry Wall)
If you want low power than asynchronous is the way to go. Amulet processors use much lower power than synchronous processors. They are asynchronous so they will slow down when the voltage drops or you go somewhere hot. When they are not working they don't use any power. There is no messing about with software controled clock control, you just stick it into a branch on spot and it freezes. This is great for things like pagers or handhelds where you dont even need to power the clock nets while you are not doing anything. A large processors clock power consumption can be as high as 80%.
You might have seen it already but this is me powering an Amulet2 off a mouse wheel. They are very robust.
Mouse powered Chips, Open source Processors and Lego
Palm systems are curently on top. They may only be B&W, but they get great battery life and do what most users need. Once you start entering the realm of music, that can be scaled over to an MP3 player instead of a Palm device.
However, once you start deciding to run higher end applications, give the machines net connects, etc. everything gets more complicated. Full color, integrated (or even unintegrated) 802.11b, sound and so on all drain batteries at an increased rate. My keyboard for my palmtop drains when it's plugged in, which is, obviously, why it's not plugged in all the time.
Battery life and functionality are both the keys. Is there a potential way to implement a self charging feature? Maybe harness the kinetic energy of movement to assist in charging the device? Most people with handhelds carry them everywhere. It wouldn't work well with high drain / low charge devices, like the Ipaq, Jornada, etc. which have charges of under 10 hours (at best) but maybe a system like this could achieve a few days or a week in a low drain device like a Palm m100.
I have no idea. Just a decidedly random thought that I had. Later.
There is a good reason for increasing the processor speed of PDAs. I agree that keyboard is completely worthless on these little things. I think companies need to start focusing more on voice recognition to do tasks.
The day i can get around half-well with voice commands on a PDA, and not have to worry about weilding a wand or typing on a keyboard that will give me carpel-tunnel.
My friend Rob has a PDA that can do somethings like say the time but there's not much more it can do yet.
- tristan
The matter is applicable on heat prevention on laptops: Those out that having a laptop with dynamically activated cpu-fan know the problem. Constantly running processes will activate the fan and increase the noise polution- it doesn't matter if the process is nice or not.
To gain a silent PC we would only need a daemon which constantly checks the CPU-temperature and slows down the system (starting or only from processes with lower priority) to prevent heat and noise.
Not to mention that this would even increase battery-power if only less important jobs are slowed down and thus fan activation is decreased to a minimum.
This really sounds like a neat feature, not complicated to implement- or is there already a project out there dealing with this?
A hack is just an idiom waiting for wider use.
I really like FastCPU for PalmOS. I run it on my Treo. Its great to be able to overclock slow apps from 33 MHz to 66 - it makes a helluva difference, and, it doesn't lock up all that often.
The other cool thing about it is that I can underclock things like notepad or "to-do list" so they use less battery power while running.
The speculation used in modern processors can be controled. For example the fetch unit fetching instructions after it fetched a conditional branch. These instructions are thrown away if the branch is mispredicted.
By controling the speculation you can decrease power without hitting your performance as much as lowering the clock rate would. One of the members of my group is working on this with positive results.
Mouse powered Chips, Open source Processors and Lego
Well, the easy answer is that you can always buy rechargeable AAA batteries if you want to go that route. This give you the best of both worlds (if you need long lasting batteries you can get alkalines, if you can recharge regularly you can save some money) and getting NiMH (as opposed to NiCd) means your batteries don't develop a memory if you recharge them from half-dead all the time. Get two sets, carry your charger in your luggage if you travel, or just buy regular batteries for the duration of any trip that takes you away from a power outlet.
Virg
This is the first time i've ever seen an analogy more complex than the original statement.
What is the relationship?
I mean, if voltage is doubled, you end up using 4x the power becaue:
P=EI
I=ER
-------
P=E^2R
R is constant.. so...
P is linearly related to E^2
Anyone lay it out for clock speed? I forget. It's not as simple...
Isn't this a basic truism for all computer design? After all, no amount of support circuit wizardry is going make an old 4004 run any modern OS at acceptable performance levels...
Which do you think is more cost-effective for a software company?
1) tell all their programmers to spend lots of time optimizing their code-- probably making it faster but harder to debug and maintain
OR
2) wait for AMD and Intel to cook up a new batch of microprocessors
If you guessed #1, you just lost. Guess what? Assembly langauge programming was faster, but it died out because (software) optimization stopped being a priority. Already C is starting to look archaic (except maybe for systems-level programming).
The reality is, software in the future will be buried under more and more layers of abstraction, just because it's easier that way. Easy to use, commercialized high level languages like Java are the future.
P.S. Please no flames about compilers vs. human assembly language programmers. Most of the binaries you run are probably compiled for a 386 anyway, if you use linux.
"Any connection between your reality and mine is purely coincidental." -Slashdot
A handheld is not supposed to replace a computer. It's supposed to provide useful functions like keeping to-do lists, schedules, phone directories, unit conversion programs, notes, etc. A good handheld design is a carefully engineered compromise between battery life, features, and speed. That's something that Palm and Handspring have pretty much understood. Only when Microsoft entered the market did people start demanding that handhelds come with 200mhz CPUs, ooh-gobs of RAM, and displays that ran the color spectrum from UV to IR.
A handheld is not an MP3 player. It's not a tiny laptop computer. It's not supposed to run X-Windows, FTP, or a web server. It's not supposed to be used for SETI at home, factoring huge primes, or playing first-person shooter games. I want month-long battery life, not a handheld with a heatsink and 10,000rpm fan. Don't screw up the market by demanding things that sway manufacturers to sell toys for geeks rather than tools for professionals.
I would like to make a point about clocking. Sleep mode involves turning off the clock (unlike Idle mode, where the clock continues to run). When the clock is turned back on it will take a certain amount of time - usually measured in milliseconds - for the clock to stabilize. This period of time will not matter if you are responding to the on/off switch, but means you can't service a high speed device out of Sleep mode.
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
The old rule of thumb was that power consumption in a digital CMOS chip was proportional to C*f*V^2, or total capacitance times frequency times voltage squared. Halve the size or clock speed, halve the power (and heat). Halve the voltage, cut the power by one fourth! Problem is that model becomes less realistic as you go down in geometries. As you get down to these ultra deep sub micron circuits (say .1 micron) leakage current becomes a big issue. This means that a section of the chip may draw an unacceptable amount of current even when the clock is turned off! Ugh. Makes me glad I got out of back end chip design.
So while you may just want all of the functions of a IIxe, there are people (and this is borne out by the fact that Compaq can still sell iPaqs) who want something more from their PDAs.
Think about what you say first.
Quid latine dictum sit, altum viditur.
Anything said in Latin, sounds profound.
I did a search and that looks like a really sweet machine. Being able to use CF for storing medical programs and stuff would be really helpful for me, as my IIIxe's 8 megs just isn't enough. Do you own one? Any comments?
Ergonomica Auctorita Illico!
Kyocera's best PDA, and strangely, the last machine for which Bill Gates ever wrote a BASIC interpreter/ operating system, was marketed in the early eighties by Radio Shack as the TRS-80 Model 100. I still use it; runs 22 hours off of AA batteries. It's lightweight, has a great keyboard, built in word processor and terminal software, and you can even today buy a ROM for it so you can do 8085 assembly programming when you are bored on the bus.
If only it had a bit more RAM. I snagged some off of an ethernet card; it exceeds the power draw expected a bit, but it works. If it had a bit more, it could probably run UZI, the Unix that ran on Z80s, with a little work.
How about Reconfigurable Computers? These are basically FPGAs featuring some ALUs and general gates, but instead of configuring these once at "burn-time" they are reconfigured dynamically on the fly, to transform the complete processor core for a specific task.The technique is somewhat young, but the ides is promising both in reducing die-size (or maximizing resource usage) bringing down power consumption.
How would this combine with asynchronous computing?
He's actually an excellent programmer. I think everyone agrees that algorithms are important. If you choose a e^x algorithm, you've just killed your scalability. Even the fastest available processor is going to have problems. But most optimizations take more time than they are worth. Writing the same code in Assembly vs Java would be slightly faster, but it would take much more programmer time. Choosing good algorithms usually saves programmer and processor cycles and isn't really relevant to FrostedChaos's points.
Ceci n'est pas un post
I interpreted the original poster's point to have been "hand-optimizing code is cost-effective, let's see more of it," and set about trying to refute that. If I had thought he had been referring to algorithmic improvements, I would have completely agreed with him.
My argument was that hand optimization is actually bad in most cases. There's lots of good reasons to keep programmers innocent of hardware and OS details. Portability amd maintainability come to mind. Another thing to remember is that hand optimization actually makes coding complex algorithms more difficult.
I don't think programmers should fear the coming of these new ideas. But they should realize that the days of sitting around, trying to squeeze a few bytes out of the inner loops, are over. In most cases, their time would be better spent on making the code more reliable, or finding better algorithms to do what they want.
And don't even get me started about code reuse...
"Any connection between your reality and mine is purely coincidental." -Slashdot