µOSII/µC552 - ULB

Le développement d'applications temps réel est un exercice délicat faisant appel
au ..... Les processeurs de la famille 8051, et en particulier le 80C552 ne sont
pas conçus ...... d représentant un accès à la mémoire interne du microcontrôleur,
 ...

Part of the document


UNIVERSITE LIBRE DE BRUXELLES Année académique 2000-2001
Faculté des Sciences appliquées


















|Promoteur : |Travail de fin d'études |
|Professeur P. Mathys |Présenté par Olivier Dubois & |
| |Bram De Wachter |
| |En vue de l'obtention du Grade |
| |d'Ingénieur Civil Informaticien |











































Nous remercions Monsieur Mathys pour le
temps et l'attention qu'il nous a
consacré ainsi que pour les judicieux
conseils qu'il nous a donnés.
Nous associons également à ce
remerciement J. J. Labrosse pour avoir
développé un RTOS puissant et convivial
sans lequel ce TFE n'aurait pas eu le
résultat escompté.


Table des matières


Introduction aux OS temps réel 7
Concept d'un système temps réel 8
Le multitasking 8
Context Switch 10
Le noyau temps réel 10
Noyaux temps réel non-préemptifs 10
Noyaux temps réel préemptifs 11
Fonctions réentrantes 12
Caractéristiques de (COS-II 13
Exclusion mutuelle 13
Synchronisations de tâches 15
Communication inter tâches 16
Portage 18
Contraintes 19
La base utilisée 19
Les adaptations à faire 20
Les constantes spécifiques au processeur 20
L'évolution du stack 20
Déclaration des types de données 20
Les macros gérant le masque d'interruption 21
Sections critiques 21
Macro masquant les interruptions 21
La macro pour changer de tâche 21
Au c?ur d'un système d'exploitation multitâche 22
Multitasking vs SingleTasking 22
Les difficultés du µC552 23
Le code à changer dans µCOSII 25
Le « context switch » en détail 26
La taille du « stack » d'une tâche 26
Autres changements mineurs 27
Conclusions 27
Gestion des périphériques 28
Vue d'ensemble 29
Les interruptions 29
Le driver UART 30
Le «ringbuffer» 30
Input 30
Output 30
Le driver CAN 31
Message control blocks 31
Input 32
Output 32
Communications, interface 33
Utilisation standard 33
Utilisation multiplexée 34
Format de la trame 34
Interface utilisateur 35
Interactions des différentes composantes 35
Réception des messages multiplexés 35
Traitement interne 35
Dispatching 36
Perte 37
Conclusions 38
KDI 39
Introduction 40
Structure des fenêtres sous KDI 42
Implémentation du KSM pour (COS-II 44
Les fonctions de création et de gestion des fenêtres du KSM 45
La fonction de création de la fenêtre 46
La fonction de collecte des données 47
La fonction de traitement et d'affichage des informations 47
La fonction de mise à jour 48
La fenêtre TaskList (RADM_WIN_TASK_LIST) 50
Localisation des données dans (COS-II 51
Organisation du buffer de données 52
La fenêtre EventList (RADM_WIN_EVENT_LIST) 53
Localisation des données dans (COS-II 53
Organisation du buffer de données 55
Fonctions supplémentaires 55
Les fenêtres spécifiques à un event (RADM_WIN_EVENT) 56
Localisation des données dans (COS-II 56
Organisation du buffer de données 57
La fenêtre Memory (RADM_WIN_MEM) 58
Localisation des données dans (COS-II 59
Organisation du buffer de données 59
Fonctions supplémentaires 59
La fenêtre Expression (RADM_WIN_EXPR) 60
Localisation des données dans (COS-II 61
Organisation du buffer de données 61
Création et installation du KSM 61
Limitations du KSM 62
KDIPlus 64
Liens entre XView et KDIPlus 64
Lancement 64
Utilisation du MDIClient 64
Arrêt 64
Décodage des messages 65
La classe MessageHandler 65
La classe IO 66
La classe MessageAcceptor 66
Vue d'ensemble en UML 67
Vue d'ensemble des Threads 67
«Romage» 68
Introduction 69
Mémoire FLASH 69
Changements de la mémoire FLASH 70
La réduction de l'OS 71
La table des jumps 72
L'outil parseL51 73
Les variables du système d'exploitation 73
Gestion des interruptions 74
Filtrage des interruptions 74
Les macros d'interruptions 75
Caractéristiques de l'OS en ROM 75
Conclusions 76
Applications 77
Introduction 78
La Trace 78
Problème 78
Solution 78
Implémentation 79
Les probepoints 83
Introduction 83
Principe général de fonctionnement 84
Du côté (COS-II 85
La tâche ProbePointMessageTask() 85
La fonction ProbePointSet() 86
La fonction ProbePointCall() 87
La tâche ProbePointTaskOut() 88
Du côté PC 89
Un nouveau GUI 89
Configurations des options 90
Insertion d'un nouveau Probe Point 91
Gestion des adresses mémoire à surveiller 92
Gestion des variables à surveiller 93
Réception et traitement d'un message 94
Les fichiers d'historique 95
Intégration des probe points dans une application 97
Conclusion 98
Générateur de fréquence avec interruptions 100
But 100
La base 100
Partir du projet vide 100
Inspecter le code 100
Rajouter les morceaux 100
Insérer un ISR 101
Initialisation 101
Insérer une tâche 102
Compiler et profiter du spectacle 102
Les philosophes 103
Penser, avoir faim et manger 103
L'implémentation 103
Le «deadlock» 105
La famine 105
Le «livelock» 105
Précisions techniques 109
Romage 110
Introduction 110
Les changements FLASH 110
Les changements du MONITEUR 110
La réduction de l'OS 111
L'outil parseL51 111
JMPTable 112
GlobalVarAddr 112
Gestion des interruptions 112
Inclure d'autres composantes de µCOSII 112
Comment recompiler le noyau 113
1. Les options du projet 113
2. Les options des fichiers 114
3. Configuration 115
4. Compilation 115
5. Warnings 115
6. Programmation 116
7. Génération de le table des jumps 116
Le « context switch » en détail 117
Localisation du code 117
Initialisation du « stack » d'une tâche 117
Code lançant la tâche la plus prioritaire, OSStartHighRdy 119
Code faisant un contextswitch du niveau d'une tâche, OSCtxSw 120
Code faisant un contextswitch du niveau d'une interruption, OSIntCtxSw
121
Changements mineurs dans µCOSII 123
Gestion des périphériques 125
Localisation du code 125
Interruptions dans µCOSII/µC552 125
Fonctionnement du driver UARTExterne 125
Fonctionnement du driver CAN 126
Fonctionnement multiplexé 127
Spécification de la trame 127
Utilisation du système de messages 127
Décodage de messages 128
Vue d'ensemble des différentes composantes 129
Fonctions d'initialisation KDI 130






















µCOSII/µC552

Introduction aux OS temps réel





Concept d'un système temps réel


Les systèmes temps réel sont caractérisés par des contraintes de timing
sévères pouvant entraîner des conséquences graves si ces dernières ne sont
pas respectées.
Il existe deux catégories de système temps réel : les systèmes à
contraintes temporelles souples et les systèmes à contraintes temporelles
strictes.

Dans le premier cas, les tâches du système doivent être exécutées aussi
vite que possible, mais ne doivent pas obligatoirement se finir dans un
délai spécifique.
Par contre, en cas de contraintes temporelles strictes, les tâches ne
disposent que d'un laps de temps prédéfini (deadline) pour s'achever. En
pratique, la situation n'est jamais si « tranchée ». La majorité des
systèmes temps réel sont soumis à une combinaison de contraintes
temporelles souples et strictes.

Les systèmes temps réel ont un champ d'application très large couvrant des
domaines aussi variés que le contrôle de processus, l'automobile, la
communication ou l'aéronautique. Il s'agit donc la plupart du temps de
systèmes embarqués.





Le multitasking


Le développement d'applications temps réel est un exercice délicat faisant
appel au principe de la programmation multitâche.
Le concept du multitâche est de planifier et d'échanger le contrôle du
processeur entre plusieurs processus (tâches) afin de maximaliser son
utilisation. L'un des aspects les plus intéressants est de réduire la
complexité inhérente aux applications temps réel en permettant de les
fragmenter en problèmes de plus petites tailles.

Une tâche (ou thread) est simplement un programme qui s'exécute normalement
en pensant avoir le contrôle exclusif du processeur. En réalité, elles sont
conçues pour résoudre chacune une portion d'un problème plus important.
Chaque tâche possède une priorité, son propre jeu de registres et sa propre
pile en mémoire.

[pic]

Typiquement, une tâche n'est en réalité qu'une boucle infinie pouvant être
dans cinq états distincts :

- dormante : la tâche est présente en mémoire mais n'a pas été
activée. Elle n'essaye donc pas de prendre le contrôle du CPU.


- active : c'est la tâche qui détient actuellement le contrôle du
CPU.

- prête : la tâche disp