Open Silicium N°
Numéro
8

Collecte et visualisation de consommation électrique

Temporalité
Septembre/Octobre/Novembre 2013
Image v3
Collecte et visualisation de consommation électrique
Article mis en avant

Résumé

On entend beaucoup parler d'économie d'énergie, du fait de considérations écologiques ou économiques, ou les deux. Toutefois, on entend beaucoup moins parler de la manière de mesurer et d'évaluer sa consommation énergétique ; il est pourtant entendu que pour faire des économies, il faut avant tout savoir mesurer et diagnostiquer sa consommation !

Dans ce numéro...


Ah ! Un exposant de 2 ! J'aime ! Et pas n'importe lequel en plus ! Le 8 n'est pas sans rappeler des choses d'un autre âge, non sans une pointe de nostalgie d'ailleurs.
Le précédent article concernant l'exploration de la liseuse Kobo Glo nous a permis de découvrir la plateforme jusqu'au noyau. Nous n'avions cependant pas touché au bootloader, chose que nous allons aborder maintenant. Ce sera également l'occasion de détailler la façon d'ajouter une board dans les sources de U-Boot de manière à ne rien casser du développement initial.
Après avoir exploré largement le système du Kobo Glo, reconstruit et modifié le comportement du noyau comme du bootloader, il est temps à présent de nous pencher sur l'élément qui fait la spécificité de ce type de périphérique : l'écran E-Ink et sa prise en charge depuis Linux. Nous allons voir que même en l'absence de sources nous permettant de baser nos expérimentations, il est parfaitement possible de développer un outil nous permettant d'afficher ce qui nous chante sur le périphérique.
Le système d'exploitation Android a su conquérir en quelques années le monde de la téléphonie mobile. Son architecture est proche d'un système GNU/Linux même s'il existe des différences notables. Si l'on se place du coté applicatif, sa simplicité d'utilisation a bien entendu tenté les industriels car le coût de développement d'une application graphique Android est souvent moins élevé que dans le cas de GNU/Linux avec Qt. Dans un avenir proche, Android pourrait donc être la référence des systèmes « Linux embarqué » avec IHM.Dans cet article nous avons donc évalué dans l'environnement Android les différentes fonctionnalités utilisées sous GNU/Linux dans un cadre industriel, en particulier l'approche temps réel en utilisant les patch PREEMPT-RT et Xenomai. La majorité des tests a été réalisé sur x86 (Atom) avec Android-x86.
Aujourd'hui prenons en main le module caméra associé au Raspberry Pi et voyons ce que nous pouvons en faire.
Le module que nous avons créé dans l'article précédent nous fourni une base pour le développement avec le micro-contrôleur LPC1224, mais son utilisation nécessite de disposer d'une interface de programmation externe, ce qui est parfois casse pied et nécessite plein de fils, câbles, alimentation, bref un beau bordel sur la table. Nous ajouterons aussi un élément spécifique aux modules pour le projet DomoTab, à savoir une eeprom qui servira à l'identification du module sur le système et pourra stocker des données utilisateur le reste du temps. Chaque élément pourra être mis sur une feuille séparée pour permettre le partage avec d'autres schémas.
Dans les deux articles précédents nous avons créé le schéma électronique d'un module de développement pour la plateforme DomoTab. Ce n'est cependant que la première étape pour obtenir un module fonctionnel. Nous allons désormais dérouler les étapes suivantes, jusqu'à obtention des documents de fabrication nécessaires à la réalisation du PCB (Printed Circuit Board, le circuit imprimé).
Lorsque l'on développe, il peut parfois être utile de récupérer le contexte mémoire qui a été à l'origine de la terminaison anormale d'un programme. Il est donc possible de demander la génération d'un core dump qui pourra être chargé dans un débugger comme gdb pour analyse.
Dans le précédent article, nous avons fait connaissance avec Verilog et avons conçu nos premiers modules après avoir choisi la plateforme FPGA la plus adaptée à nos besoins pédagogiques. Cependant, nous avons délibérément fait l'impasse sur une étape importante du design HDL : la simulation. Il est temps, maintenant, de corriger cet écart et de pousser davantage dans la découverte et la compréhension de Verilog et des FPGA.
L'embarqué c'est comme la cuisine, la peinture ou le bricolage… Pendant toute la phase de découverte durant laquelle vous vous « acclimatez » et découvrez le domaine, une chose revient régulièrement : il vous manque systématiquement un outil, un ingrédient ou un accessoire. Ce n'est qu'après quelques temps que vous disposez d'une collection vous permettant de faire face à la majorité des situations. Cet article se propose de vous faire gagner un peu de temps et de vous constituer une boîte à outils afin de limiter vos frustrations.
En tant qu'informaticien, bidouilleur, administrateur ou encore développeur, la communication et la maîtrise des technologies associées représentent une grande part de votre temps. Je ne parle, bien entendu, pas nécessairement de communication avec d'autres êtres vivants mais plutôt de celle entre et avec des systèmes informatisés, des PC généralement. Mais avez-vous déjà pensé communiquer avec des systèmes d'un tout autre genre, comme par exemple, ceux embarqués dans les aéronefs, utilisant des ondes électromagnétiques ? Rassurez-vous cela est bien moins coûteux et complexe qu'il n'y paraît.

Magazines précédents

Les derniers articles Premiums

Les derniers articles Premium

Du graphisme dans un terminal ? Oui, avec sixel

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

On le voit de plus en plus, les outils en ligne de commandes s'étoffent peu à peu d'éléments graphiques sous la forme d'émojis UTF8. Plus qu'une simple décoration, cette pointe de « graphisme » dans un monde de texte apporte réellement un plus en termes d'expérience utilisateur et véhicule, de façon condensée, des informations utiles. Pour autant, cette façon de sortir du cadre purement textuel d'un terminal n'est en rien une nouveauté. Pour preuve, fin des années 80 DEC introduisait le VT340 supportant des graphismes en couleurs, et cette compatibilité existe toujours...

Game & Watch : utilisons judicieusement la mémoire

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Au terme de l'article précédent [1] concernant la transformation de la console Nintendo Game & Watch en plateforme de développement, nous nous sommes heurtés à un problème : les 128 Ko de flash intégrés au microcontrôleur STM32 sont une ressource précieuse, car en quantité réduite. Mais heureusement pour nous, le STM32H7B0 dispose d'une mémoire vive de taille conséquente (~ 1,2 Mo) et se trouve être connecté à une flash externe QSPI offrant autant d'espace. Pour pouvoir développer des codes plus étoffés, nous devons apprendre à utiliser ces deux ressources.

Body