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
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.
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.
Some PDAs have already started moving towards this end. The Visor Edge and some of the other Handspring Visor products have rechargeable batteries built in. My Edge charges in the same cradle as it syncs in, making it quite convenient.
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.
Common misconseption. The processor speed can change while you play the game and all that will change is your frame rate and not your play speed.
Thats why asynchronous processors are possible.
Mouse powered Chips, Open source Processors and Lego
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?
There are some good reasons why devices still use alkaline batteries instead of rechargable:
:)
- It's cheaper. Making the user buy AAA cells is cheaper than an expensive built-in rechargable. Be angry if you want, but the same shoppers that gripe are the ones that will pick the AAA model because it's $10 cheaper.
- Charger required. more $$$, bigger packaging, more travelling weight, country-specific voltage, UL Listing, the works.
- Alkalines last longer (per charge) than rechargables. On a device may go weeks without seeing a charger, this counts.
- Rechargable cells die. What do you do with a PalmV that no longer charges well? LiIon cells only last a year or two before they start to degrade quickly.
I'm not saying that these are valid reasons to require disposable batteries, but these are factors that manufacturers look at in deciding which way to go.
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.
I see a problem with voice recognition. It is not the technology itself, but more of where you can use this method. Imagine yourself in a classroom, where all of the students are talking to their PDA, to take class note.
I think a quiet (less dirturbance to the environment) input method is required. Voice is just not the one.
what inverter?
Unless you are using an external AC/DC inverter, there usually isn't one in an embedded application. Anything with an LCD the size of a PDA uses a frontlight display. Laptops use inverters to power the CCFL because their screens are simply to large for an effective frontlight to work.
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
You are assuming that all timing in a system is dependent on the CPU's clock. This usually isn't the case. Most real-time dependant applications rely on another clock to 'keep time' for them. This enables games, for example, to run at any given CPU speeds and have similiar performance. Of course actual game speed would depend on if instructions are executed fast enough. (If your RTC is ticking away at 1ms and it takes a slower processor 3ms to finish its last instruction set, then you are going to see significant slowdowns.)
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
er then do you mean regulators?
I think the term DC-DC inverter is misleading. Anything that does DC-DC conversion is a regulator. Linear regulators consume power like there is no tomorrow. They also produce a sizable amount of heat (imagine that.)
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...
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.
Indeed, there are some people who will gladly shell out several hundred dollars in order to avoid buying a cheap daytimer.
I can't download reference books to a daytimer. I can't download unit conversion software to it. I can't beam the addresses and phone numbers from my daytimer to my friend's. A daytimer won't function as an alarm or a stopwatch. The comparison is ill-conceived at best.
My main problem with Palm is that they subscribe to this philosophy -- that they know what their users want better than their users do.
They do. Users invariably yell for each feature that enters their heads, seldom considering the consequences (weight, battery usage, longevity, user interface, overall complexity, etc.). Palm has engineers do their engineering and they have a unified vision of how things should work.
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.
I did think about what I said. I don't want a useful, efficient, cost-effective, professional tool turned into an expensive, battery-hungry, bloated, behemoth because some vocal group clamored for features that are neither needed nor wanted by most users.
Ergonomica Auctorita Illico!
Rotary processors by Simon Moore is the sort of thing. My flatmate is looking at it now but more for performance reasons than power.
Mouse powered Chips, Open source Processors and Lego
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