Well, firstly, I'd say that getting power management to work on a mobile phone is an order or two of magnitude harder than a laptop. Not only do you have the usual suspects (applications, threads, backlights, screens blah blah) but you also have a radio circuit that needs to be on all the time, and needs to be able to quickly spin up and down if it's not being used in a wide variety of situations. It needs to regularly check the radio landscape, work out when to do handovers, check signal strengths and so forth, not to mention, you need to have a lot of logic in their to stop, for example, the radio stack doing massive high power frequency band sweeps when you go out of coverage. Tuning all of that, and getting it to work well with all the other stuff going on is a real development nightmare. Not to mention, each network, in each country is running different kit, doing different things so you need to run quite expensive test teams around the world tweaking things.
Other painful levels of abstraction... handling hardware acceleration for core codecs, for example, correctly handling the AMR11 (I think) codec for voice on a GSM phone. This will normally be a silicon codec on the radio ASIC, so you need to handle data pass through to the codec and handle how that interacts with the rest of the device, if you want to then do something like voice recording, other video with sound (H.264) you need to work out sensible ways of using the right acceleration at the right time.
Graphics... interfacing graphics to the screen drivers is a nightmare. Don't know why, but it seems to take thousands of man hours of hard graft to get working right and debug. If you then add another graphics abstraction layer on top of that it can be equally painful as you try and test and check to make sure things render correctly
Video/Audio multimedia... on dual core phones, you'll (as I've mentioned) have the audio codec running in hardware on the radio processor and video running in software or hardware on the application processor. Synchronisation of audio with video is a nightmare in those architectures. This is comon to a lot of the Marvel and TI family of processors for phones. Of course, a lot of this goes away if you stick a PC processor in and give it a Gig of memory, but that's not the direction most phone developers (with one exception) want to go in.
There's lots and lots more of those, but I'm not an engineer, I just have to tell people how much it's going to cost them for us to fix the problems when they encounter them.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2007-11-27 07:10 pm (UTC)Other painful levels of abstraction... handling hardware acceleration for core codecs, for example, correctly handling the AMR11 (I think) codec for voice on a GSM phone. This will normally be a silicon codec on the radio ASIC, so you need to handle data pass through to the codec and handle how that interacts with the rest of the device, if you want to then do something like voice recording, other video with sound (H.264) you need to work out sensible ways of using the right acceleration at the right time.
Graphics... interfacing graphics to the screen drivers is a nightmare. Don't know why, but it seems to take thousands of man hours of hard graft to get working right and debug. If you then add another graphics abstraction layer on top of that it can be equally painful as you try and test and check to make sure things render correctly
Video/Audio multimedia... on dual core phones, you'll (as I've mentioned) have the audio codec running in hardware on the radio processor and video running in software or hardware on the application processor. Synchronisation of audio with video is a nightmare in those architectures. This is comon to a lot of the Marvel and TI family of processors for phones. Of course, a lot of this goes away if you stick a PC processor in and give it a Gig of memory, but that's not the direction most phone developers (with one exception) want to go in.
There's lots and lots more of those, but I'm not an engineer, I just have to tell people how much it's going to cost them for us to fix the problems when they encounter them.