Quote:
Originally Posted by Lucas Malor
|
Hi Lucas.
Yes, at least to manually set it with the frequency switching API I already referenced ; but there is supposed to be a separate way to do it with DVFS enabled. I don't care if it's automatic or not, but there is supposed to be some kind of table that can be set up describing the frequencies and voltages which the Kobo is allowed to run at. I found the references in freescale's documentation, but they didn't show an example of how it is done. Thanks for the link, I'll look it over.
I agree, The battery lasts a long time -- but that's with the e-reader, nickel, software running because the battery life is much longer when doing e-book reading -- than when running some of the linux apps. I have been using. They seem to kill the battery in under two days, best case. ( Part of the problem, though, might be that I didn't unload the USB device drivers and shut down the peripherals; so it might not be the clock which is the problem. ).
A big part of my motivation is simple curiosity -- but I'm also wanting to be able to extend the battery life to the maximum while running my own applications on the Kobo. For example, I might take a kobo on a trip in the outback where there's no electricity, and carrying things over long distances means I want to travel light; so I might not be able to charge it for 10 or 11 days at a time, but still want to use it for doing text editing, journaling, and programming for several hours a day (using it as a linux command line/terminal device, not as an e-reader).
According to freescale's glossies ... DVFS is supposed to be able to give a far better power savings than the CPUFREQ system allows. I know that when the core voltage of a cpu is lowered, the power drop is not just linear with frequency decrease; but is much better than that -- and DVFS can lower the core voltage substantially; so in theory, the Kobo's not utilizing the real power savings mode that Freescale built into it, and the Kobo's performance might be capable of being made much better. ( Maybe not, too... depending on how much power the touch-screen draws. It could all be a moot point. )
Some arm processors can apparently operate as low as a few 10's of kHz -- which should allow it to operate well over a month on a single battery charge even if operating continuously and never sleeping, especially if if Linux is recompiled to run tick-less and the processor can completely halt between keystrokes, or screen touches and only draw battery when touched or updating the screen.
A processor running 166MHz is way overkill for the kinds of tasks I'm doing. But that's what the Kobo is doing.
I used to do text editing on a 12MHz 80286 processor, quite happily. So, I know that if the kobo could run 10x slower, it would be plenty fast at 1/10th (with memory that's probably more like 1/3 the power... but in theory it could be 1/10th) the power draw and the battery life would extend accordingly -- eg: if it wasn't running a computation intensive GUI, but just a simple terminal based word processor. ( Even in the QT compile script I got from GitHub, it's interesting to note that KOBO's programmers chose to turn off the neon graphics coprocessor. I imagine that a slow e-paper display which cant update except once in a quarter second or so, doesn't really need a hardware accelerated GPU -- and maybe it was better to simply not use it and waste extra power ? )
As a final note: I just checked the data sheet, and I know the Freescale processor has a built in 24MHz clock, and that's still 6x slower than it's running now, and should extend the battery life significantly if it could be enabled.
So, just call it extreme curiosity. What are the limits of the kobo reader....
