• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

super-fast mobile chips that sleep a lot

D

dpopiz

Diamond Member
One of my biggest pet peves is mobile gadgets (cell phones, pdas, etc) that have unresponsive UIs.

Unresponsive or "unsnappy" to me is not the same thing as slow. My nokia cell phone can encode mpeg4 video in relatime, so it has a decent processor, yet it still takes it almost half a second to switch menu item selected when I press DOWN.

That's the sort of thing that aggrevates me. Slow-to-respond user interfaces always end up making a device *less useful* because it gets in the way of making the device an extension of your consciousness.
--------

so, here's what I often wonder, and I hope one of you EE majors can give me an answer:
Why can't you just put a chip in my cell phone that's SUPERFAST to give *instant* response *when I'm doing something*, but goes to sleep after a few miliseconds of inactivity to conserve battery power?

Of course it would also have to wake up instantly upon I/O activity, but hasn't this been done before, like with Transmeta? I seem to remember reading somewhere that the old Crusoe had the ability to go in and out of deep sleep mode between every keystroke when you're typing something.
 
That technology has been around for ages.
Almost alls microprocessors/DSPs have a "sleep" mode and AFAIK it is always used in battery driven equipment.
I would say the problem with the GUI on your Nokia has noting to do with this, it is probably just bad programming and/or an attempt to reduce battery consumption even when you are using the phone.


 
Originally posted by: f95toli
That technology has been around for ages.
Almost alls microprocessors/DSPs have a "sleep" mode and AFAIK it is always used in battery driven equipment.
I would say the problem with the GUI on your Nokia has noting to do with this, it is probably just bad programming and/or an attempt to reduce battery consumption even when you are using the phone.
Click to expand...

ok, but there are LOTS of pocket devices like this -- I would say virtually ALL of them. The only one that comes close to a responsive interface is Blackberry-- Moving around its menus is almost instantaneous--the only time I have to wait is when I open a new app.

But that brings up another point I was trying to touch on: Why can't *everything* be instant on these devices, like they would be on a PC. In other words, why can't they use a CPU that is is as fast as say a 1GHz pentium, but that still conserves battery power by going to sleep frequently?

Is there some other concern with mobile devices that I'm not thinking of, that is besides battery life?
 
The devices I have are all ok. Both my IPAQ 2210 and my cell phone (Ericsson Z1010, a 3G phone which is pretty old) have good interfaces.
Older devices were ususally limited by their screens, changing the screen to fast would have resulted in "ghosting".

The problem with sleep mode is that is takes some time to turn the chip on and off (probably a few ms) so you can not let the device go to sleep while the user is working with it, a 1 GHz pentium uses a LOT of power and would drain the battery in no time.

That said, my Z1010 is MUCH faster than my old cell phone AND has a better battery life (despite the fact that the Z1010 has a good color screen, plays mp3&video and has some basic PDA functionality) so it is possible to make reasonably fast battery driven devices.
 
yeah I see, so now my question is why does it take a few ms to turn a chip on and off? would it be possible to eliminate this delay? (e.g. "freeze everything", then "unfreeze")
 
maybe the mcu needs to save the state of everything - peripherals/ram/registers and dump it somewhere, then needs time to load everything up where it was. also - assuming the chip clocks down or shuts completely off, doesnt it take time for the clock to stabilize whether it be a xtal or RC osc.?
 
most people can't handle an instantaneous response from a gadget. The menu updates takes 1/2 second, so do scrolling. can you imaging if scrolling is instantaneous? you actually can't use the thing because you can nver get to the point you want.
 
Originally posted by: PottedMeat
maybe the mcu needs to save the state of everything - peripherals/ram/registers and dump it somewhere, then needs time to load everything up where it was. also - assuming the chip clocks down or shuts completely off, doesnt it take time for the clock to stabilize whether it be a xtal or RC osc.?
Click to expand...

Couldn't you keep current always flowing through the RAM and the registers in the CPU and then shut down the rest of the CPU? And as unexpected inputs coming in, just buffer those and make it so the buffer is large enough to store however much data the input could possibly dump in it while we're waiting for the CPU to boot up.
 
There should be the "zero clock" idea - when the processor is still running but at a clock speed of 0 MHz - the moment when the next clock cycle arrives, the processor can be back at full speed.
However, this is not such a good idea - as for longer amounts of time, the energy used by a working 0MHz processor is greater than the energy used for the processor to save its state, shut down almost completely and then retrieve its state
 
If it was just a "few" milliseconds I wouldn't have a problem, but it's really like 500 ms, i.e. 1/2 second. And why does my cell phone take so long to hang up. As far as I can tell, it should instantly turn off and discontinue power usage.

Maybe it's bad programming. My Palm m505 (now 4 years old) is as snappy as any new gadget I have but runs a proprietary OS dedicated to the Palm CPU chip. I think many people have turned to JAVA GUI interfaces - but they suck - even on a 2GHz Pentium. That could be the source of a lot of woess. What ever happened to machine language programming?
 
Originally posted by: onix
If it was just "few" milliseconds I wouldn't have a problem, but it's really like 500 ms, i.e. 1/2 second. And why does my cell phone take so long to hang up. As far as I can tell, it should instantly turn off and discontinue power usage.

Maybe it's bad programming. My Palm m505 (now 4 years old) is as snappy as any new gadget I have and run a proprietary OS dedicated to the Palm CPU chip. I think many people have turned to JAVA GUI interfaces, but they suck, even on a 2GHz Pentium .That could be the source of a lot of problems. What ever happened to machine language programming?
Click to expand...

I think (supposedly) java itself is almost fast as native C++, but the Swing library used for GUIs is hellza slow. I don't think Swing is used in most mobile devices -- they would probably write their own GUI libs.

Anyway, I'm glad you understand my confusion regarding the delays that are common in pocket devices, onix.
 
Java code can have its speed somewhat close to that of C++ code. However, some optimisations based on runtime statistics can make the java bytecode just as fast (and sometime a bit faster) than native C++ code. I wouldn't have believe it either.
However, this speed come at the expense of a bigger memory footprint and a longer load time (based also on the memory footprint). And using actual run-time statistics to improve the run speed of java code would severely tax a lowly processor like the one in a phone.
I would say they have also dedicated GUI libraries, that knows nothing else but the phone they run on. Not like the pc-like libraries that would support tons of different configurations, they might be incompatible between two models that differ only a bit.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top