Bonjour,
Si vous le voulez bien, on pourra parler ici de la consommation de nos chers appareils électroniques mobiles.
Les chiffres et les graphiques suivants sont tirés d'un stage chez un fabricant de SoC. Les chiffres datent d'il y a quelques années, mais devant le manque d'informations de ce genre car souvent confidentielles, ils restent toujours intéressants.
Je vais principalement parler de la plateforme basée sur un ARM 926 @ 266MHz, L1 32kB pour I et D, L2: 128kB, en 90nm. Il est aidé par des accélérateurs dédiés pour la partie multimédia. La ram (512Mb DDR) et la nand (1-2Gb) sont placées en PoP (Package over Package) sur le chip. Evidemment, on peut y connecter tout un tas de périphériques, comme des capteurs d'images, des écrans, des accéléromètres, une puces gps, du bluetooth/FM, une sortie TV... N'oublions pas non plus toute la partie Modem, ce sont des téléphones après tout. Il y a donc le baseband (intégration future dans le SoC principal), la puissance et la RF, et la gestion de l'énergie. Je n'ai pas travaillé là dessus, mais plutôt côté multimédia.
Le tout sera alimenté par un chip de power management s'occupant de la conversion de l'énergie fournie par la batterie. Les rendements de régulateurs à découpage sont optimisé seulement pour certains courants. Dans des cas particuliers, leurs pertes peuvent être importantes. C'est ce qui nous intéresse ici.
Voici donc combien consomme tout ce matériel, au bout de moult optimisations software. Les chiffres sont sans conso des clocks, je ne me souviens plus exactement pourquoi.
Au repos un téléphone doit quand même surveiller le réseau. A cette époque, les téléphones passaient la majorité de leurs temps dans cet état. Chaque mW est important. On finit par obtenir 9.2mW, dont 30% sont des pertes.
Un petit peu de musique ? Ecoutez moi ce mp3 à 48kHz/128kbs d'une carte SD. On enlève le rétroéclairage parce que ca bouffe. Le SoC, on lui fait remplir un buffer de musique @ 266MHz pendant 30% du temps. Puis on le laisse se reposer à 19.2MHz, les données étant envoyées du buffer sur le codec audio. On atteint 62mA de courant tiré sur la batterie, économisant 30% par rapport à un mode normal. (les demandes de Nokia pour 2010 était 10mA). Il y a 20% de pertes, et le codec audio + l'ampli participe à 25% de la conso totale.
Il se fait tard, alors un petit flim sur le cyclimse en MPEG4+AAC en résolution VGA. Bon là on est obligé d'allumer l'écran et de faire tout tourner à fond. On a finalement besoin de 172mA, soit 621mW, dont 10% de pertes de conversion.
Pour anecdote, voici les gains obtenus sur une même plateforme par optimisation software :
Code:
10/07 05/08 06/08 07/08
Idle: 18mW 12mW 9.2mW Target:4mW
MP3: 345mW 322mW 310mW 225mW (LP Mode)
Video: 935mW 697mW 697mW 621mW
Je pense m'arrêter là pour aujourd'hui. Si vous êtes intéressés par plus de détails, n'hésitez pas !
De même, si vous avez des questions, j'essaierai d'y répondre dans la mesure de mes capacités.
PS: Pour Newbie06, la proportion backlight/LCD control en chiffres mesurés pour cet écran (QVGA je crois), c'est 23.6mA/3.3mA. Donc oui, un écran c'est principalement du rétroéclairage et des pertes de conversion (30%).