3 ms·
Okay, so let's just get on with starting at an incredibly basic level then! Consider the Ericsson MC218 / Psion Series 5 (https://www.google.com/search?q=psion
by exikyut 8y ago
Okay, so let's just get on with starting at an incredibly basic level then!
Consider the Ericsson MC218 / Psion Series 5 (https://www.google.com/search?q=psion+series+5 https://www.google.com/search?q=psion+series+5). The software (EPOC, forerunner to Symbian) could drag windows (whole windows) around the little screen faster than the LCD crystals could keep up/redraw.
I had a look inside the unit (find the photos at https://www.applefritter.com/content/pocketable-ultra-low-powered-device-linux-andor-wi-fi https://www.applefritter.com/content/pocketable-ultra-low-po...) and found only a 36MHz ARM7TDMI inside. Presumably the CPU was doing the window redrawing all in software.
It's really reassuring to me that such a slow CPU gave the LCD a run fo its money, because let's face it, doing $tons_of_pixel_manipulations on a CPU always chews power, so if you want battery life you're going to need something that works well at the low-power end of the spectrum. (The Series 5's monochrome LCD was 640x240.)
So, well-designed software would meet the power consumption-versus-feature challenge halfway. Such software doesn't exist yet though, and it appears this status quo isn't going to change anytime soon; the (financial) investment required just doesn't seem to be materializing.
I'd say the main problem is market effects, and consumer interest. "Yeah 70% of CPU time goes to drawing the screen" is NOT particularly attractive.
- lkcl 8y agousually in these cases where the CPU is so slow, it simply doesn't have the bus bandwidth even to feed an LCD. so the LCD is an SPI device or 8080 MCU compatible memory-mapped peripheral, that has its own internal SRAM as a framebuffer. a good example is the HX8357D (now obsolete sadly) https://github.com/torvalds/linux/blob/master/drivers/video/backlight/hx8357.c https://github.com/torvalds/linux/blob/master/drivers/video/... technically speaking it's perfectly possible to use an 8mhz 8-bit arduino-style processor to make a phone, if all you want is calls and SMS! the processor inside the actual GSM/3G modem is far, far more powerful than that. i added up the number of actual processors in a smartphone once: it was insane. DSP in the Audio IC. ARM core in the GPS. ARM core in the 3G Modem. ARM core in the main processor. 8051 core in the capacitive touchpanel controller. the list just goes on and on!
- exikyut 8y ago[Oops, just noticed your reply] FWIW, I did see a weird black blob type thing on the LCD ribbon cable, but I don't think I got any photos of that. That is very probably the LCD controller you speak of. I wouldn't be entirely surprised if the main CPU (and specifically EPOC) had a framebuffer of what was on the screen. (I'd be surprised if it didn't have any such (double-)buffering.) Yeah, baseband processors have a fair bit of oomph to them. I've long been curious what sorts of specs they have. In the iPhone, there's also the ARM core in things like NVMe storage as well. (http://ramtin-amin.fr/#nvmepcie http://ramtin-amin.fr/#nvmepcie)