Comment les interfaces utilisateur intégrées sont-elles contrôlées

Question

Comment codent-elles la logique d'une interface utilisateur exécutée sur du matériel incorporé? Fours à micro-ondes, téléviseurs à écran plat, lecteurs de DVD portables et même une montre numérique ces jours-ci ont des interfaces utilisateur complexes. Existe-t-il des outils/frameworks disponibles pour supprimer tout le sale boulot ou est-ce que les développeurs utilisent des constructions IF ELSE.

Je ne demande pas d'outils d'interface utilisateur dans le sens de QT ou WxWidgets. Je suis plus intéressé à savoir s'il existe des cadres pour gérer la logique derrière les contrôles.

if (mTemperature > maxTemperature) 
    temperatureDialControl.Enabled = false; 

Answer 1

J'ai utilisé la famille de frameworks Quantum Platform de Quantum Leaps pour plusieurs produits embarqués avec interfaces utilisateur (et ceux sans interface utilisateur). Le QP est un cadre pour la programmation événementielle (qui est essentiellement tous les systèmes embarqués). Les interfaces utilisateur en particulier correspondent bien, car la plupart des interfaces utilisateur sont constituées de «widgets» personnalisables, et les widgets reçoivent généralement des événements (timeout, pression de bouton, mouvement, etc.) provenant d'un répartiteur d'événements. Cette "inversion de contrôle" est très typique avec les interfaces utilisateur. La plupart des interfaces utilisateur (intégrées) que j'ai rencontrées au cours de ma carrière sont soit des machines à états pilotées par des événements, soit elles auraient dû être implémentées de cette manière.

Vous avez demandé spécifiquement comment gérer les commandes logiques &. Ce qui est bien dans la QP, c'est que le modèle de calcul d'objets actifs qu'elle englobe se prête à une implémentation simple et naturelle de machines à états (plates ou hiérarchiques). Ainsi, dans votre exemple ci-dessus, vous recevrez probablement un événement "température mise à jour" avec une nouvelle température, et votre gestionnaire d'état exécutera la logique & décider quelle action est nécessaire. Avec un framework, vous créez la logique derrière les contrôles, mais l'infrastructure gère presque tout le reste.

La plate-forme Quantum est assez sophistiquée. Il est également très facile de voir la connexion (traçabilité) entre le design (statechart) et l'implémentation/code. Mieux encore, le framework implémente toute l'infrastructure (mise en file d'attente & dispatching, transitions d'état, garbage collection, pools de mémoire, etc.), tout ce que vous avez à faire est de vous concentrer sur votre application.

J'ai utilisé le Qt de Nokia sur des plates-formes non embarquées, mais votre question semble indiquer que vous êtes déjà au courant. Je pense qu'il y a une version plus "embarquable" de Qt mais je ne l'ai jamais utilisée.

Answer 2

sont des outils/cadres là pour enlever tout le sale boulot ..? Oui il y en a. Ils sont appelés OS 'embarqués et RTOS. En règle générale, ils aident à gérer les interruptions générées par les minuteurs, les boutons et d'autres contrôles, ils contiennent des niveaux d'abstraction matérielle, ils incluent diverses piles de protocoles de communication, etc. Donc, fondamentalement, ils font tout le sale boulot. Tout ce dont vous avez besoin est de traiter ce qu'ils fournissent en utilisant IF/ELSE ou SWITCH ou ce que vous voulez. Au moins qui sait mieux que temperatureDialControl.Enabled doit être faux si mTemperature dépasse maxTemperature?

Answer 3

Avec intégré vous avez la liberté de faire ce que vous voulez, vous n'êtes pas confiné par les limites d'un système d'exploitation ou pire une API. Les systèmes embarqués peuvent être pilotés par des événements, en particulier si l'alimentation est un problème (alimenté par batterie) parce que vous voulez essentiellement passer à faible puissance et ne vous réveiller que pour les événements. Mais vous pouvez également utiliser aucune interruption et aucun événement dans le sens d'interruptions, vous pouvez interroger tout le temps tant que votre temps de réponse est garanti pour répondre à toutes les exigences.

En ce qui concerne les interfaces utilisateur micro-ondes, qui sont triviales comparées à celles d'un clavier d'ordinateur par exemple, peuvent être compliquées ou simples selon le système. Pour le coût chacun de ces boutons peut être alimenté dans un microcontrôleur et le microcontrôleur doit interroger ou obtenir une interruption pour chacun et faire le rebond, etc. Ou comme votre clavier ou souris d'ordinateur par exemple il peut y avoir du matériel et de la logique qui fait tout ça travail et le microcontrôleur est envoyé un seul octet ou paquet indiquant un événement, sur un bus spécial ou standard comme série ou spi ou autre. Maintenant que la logique qui effectue cette tâche peut elle-même être un autre microcontrôleur dont le seul travail est de rebondir et de détecter les appuis sur les boutons, puis de déclencher l'octet série lorsqu'il voit un changement d'état. L'interrogation est probablement plus facile, mais je peux imaginer des façons de rebondir en utilisant des interruptions. Embedded est seulement spécial dans le sens où vous n'êtes pas confiné par les limites du système d'exploitation et les API, à l'exception de ceux que vous vous imposez (ou qui sont imposés par le client). Les interfaces utilisateur sont normalement beaucoup plus simples qu'une interface utilisateur de programmes de bureau.