Système d'exploitation en temps réel AQUA RTOS pour MK AVR dans l'environnement BASCOM AVR

Lorsqu'il écrit pour du code MK plus compliqué que «clignoter une lumière», le développeur est confronté aux limitations inhérentes à la programmation linéaire dans le style de «supercycle plus interruptions». Le traitement des interruptions nécessite de la rapidité et de la concision, ce qui conduit à ajouter des indicateurs au code et à rendre le style de projet «super-cycle avec interruptions et indicateurs».

Si la complexité du système augmente, le nombre de drapeaux interdépendants augmente exponentiellement et le projet se transforme rapidement en un «code de pâtes» mal lisible et gérable.

L'utilisation de systèmes d'exploitation en temps réel permet de se débarrasser du "code des pâtes" et de rendre la flexibilité et la gérabilité à un projet MK complexe.
Plusieurs systèmes d'exploitation coopératifs en temps réel ont été développés et très appréciés des microcontrôleurs AVR. Cependant, ils sont tous écrits en C ou Assembleur et ne conviennent pas à ceux qui programment MK dans l'environnement BASCOM AVR, les privant d'un outil aussi utile pour écrire des applications sérieuses.

Pour corriger cette lacune, j'ai développé un RTOS simple pour l'environnement de programmation BASCOM AVR, que je porte à l'attention des lecteurs.



Pour beaucoup, le style de programmation MK familier est le soi-disant supercycle . Dans ce cas, le code se compose d'un ensemble de fonctions, procédures et descripteurs (constantes, variables), éventuellement ceux de bibliothèque, généralement appelés «code d'arrière-plan», ainsi qu'une grande boucle infinie enfermée dans une construction do-loop . Au démarrage, l'équipement du MK lui-même et des appareils externes est d'abord initialisé, les constantes et les valeurs initiales des variables sont définies, puis le contrôle est transféré à ce supercycle infini.
La simplicité du supercycle est évidente. La plupart des tâches effectuées par MK, parce que d'une manière ou d'une autre cyclique. Les inconvénients sont également évidents: si un appareil ou un signal nécessite une réaction immédiate, MK le fournira au plus tôt lorsque le cycle se retournera. Si la durée du signal est plus courte que la période de cycle, un tel signal sera ignoré.

Dans l'exemple ci-dessous, nous voulons vérifier si le bouton est enfoncé :

do ' -  if button = 1 then '     '  -  loop 

Évidemment, si "un certain code" fonctionne assez longtemps, MK peut ne pas remarquer une courte pression sur un bouton.

Heureusement, MK est équipé d'un système d'interruption qui peut résoudre ce problème: tous les signaux critiques peuvent être «suspendus» aux interruptions et un gestionnaire peut être écrit pour chacun. Le niveau suivant apparaît donc: un supercycle avec des interruptions .
L'exemple ci-dessous montre la structure du programme avec un supercycle et une interruption qui traite un clic de bouton:

 on button button_isr '    enable interrupts ' ***  *** do ' -  loop end '   button_isr: '  -    return 

Cependant, l'utilisation d'interruptions pose un nouveau problème: le code du gestionnaire d'interruptions doit être aussi rapide et court que possible; à l'intérieur des interruptions, la fonctionnalité MK est limitée. Étant donné que les AVR MK n'ont pas de système d'interruption hiérarchique, une autre interruption ne peut pas se produire à l'intérieur d'une interruption - ils sont actuellement désactivés sur le plan matériel. L'interruption doit donc être exécutée le plus rapidement possible, sinon les autres interruptions (et éventuellement les plus importantes) seront ignorées et non traitées.


Par conséquent, nous ne pouvons pas écrire quelque chose de compliqué dans le gestionnaire d'interruption, surtout si ce code doit avoir des retards - car jusqu'à ce que le retard fonctionne, le MK ne reviendra pas au programme principal (supercycle) et sera sourd aux autres interruptions.

Pour cette raison, dans le gestionnaire d'interruption, vous n'avez souvent qu'à signaler le fait de l'événement avec un indicateur - le vôtre pour chaque événement - puis à vérifier et à traiter les indicateurs à l'intérieur du supercycle. Bien sûr, cela rallonge le temps de réaction à l'événement, mais au moins nous ne manquons pas quelque chose d'important.

Ainsi, le prochain niveau de complexité se pose - un supercycle avec des interruptions et des drapeaux .

Le code suivant s'affiche:

 on button button_isr '    enable interrupts ' ***  *** do ' -  if button_flag = 1 then '     button_flag = 0 '     end if '  -  loop end ' ***    *** button_isr: button_flag = 1 return 

Un nombre considérable de programmes pour MK sont limités par cela. Cependant, ces programmes sont généralement encore plus ou moins simples. Si vous écrivez quelque chose de plus compliqué, alors le nombre de drapeaux commence à croître comme une boule de neige, et le code devient de plus en plus confus et illisible. De plus, dans l'exemple ci-dessus, le problème des retards n'a pas été résolu. Bien sûr, vous pouvez "suspendre" une interruption distincte sur la minuterie, et dans celle-ci ... également contrôler divers drapeaux. Mais cela rend le programme complètement moche, le nombre de drapeaux interdépendants augmente de façon exponentielle, et même le développeur lui-même peut difficilement trouver un tel "code de pâtes" assez rapidement. Essayer de trouver une erreur ou de modifier le code devient souvent égal dans les efforts pour développer un nouveau projet.

Comment résoudre le problème du "code de pâtes" et le rendre plus lisible et gérable? Le système d'exploitation (OS) vient à la rescousse. Dans ce document, la fonctionnalité que MK doit implémenter est divisée en tâches dont le fonctionnement est contrôlé par le système d'exploitation.

Types de systèmes d'exploitation pour MK

Les systèmes d'exploitation pour MK peuvent être divisés en deux grandes classes: OS avec éviction et OS coopératif. Dans l'un de ces systèmes d'exploitation, les tâches sont contrôlées par une procédure spéciale appelée répartiteur . Dans un OS avec éviction, le répartiteur bascule indépendamment à tout moment l'exécution d'une tâche à une autre, en allouant à chacun un certain nombre de cycles d'horloge (éventuellement différents, selon la priorité de la tâche). Cette approche dans son ensemble fonctionne très bien, vous permettant de ne pas regarder du tout le contenu des tâches: vous pouvez écrire au moins le code de la tâche

 1: goto 1 

- et le reste des tâches (y compris celle-ci) seront toujours exécutées. Cependant, les systèmes d'exploitation préemptifs nécessitent beaucoup de ressources (mémoire du processeur et cycles d'horloge), car chaque commutateur doit enregistrer complètement le contexte de la tâche à désactiver et charger le contexte de la reprise. Le contexte se réfère ici au contenu des registres de la machine et de la pile (BASCOM utilise deux piles - une matérielle pour les adresses de retour des sous-programmes et une logicielle pour transmettre les arguments). Non seulement une telle charge nécessite beaucoup de cycles de processeur, mais le contexte de chaque tâche doit également être stocké quelque part pendant un certain temps jusqu'à ce qu'il fonctionne. Dans les "gros" processeurs, initialement orientés vers le multitâche, ces fonctions sont souvent prises en charge dans le matériel, et elles ont beaucoup plus de ressources. Dans AVR MK, il n'y a pas de prise en charge matérielle pour le multitâche (tout doit être fait «manuellement»), et la mémoire disponible est petite. Par conséquent, les OS de déplacement, bien qu'ils existent, ne conviennent pas trop aux MK simples.

Une autre chose est le système d'exploitation coopératif . Ici, la tâche elle-même contrôle à quel moment transférer le contrôle au répartiteur, lui permettant de démarrer d'autres tâches. De plus, les tâches ici sont nécessaires pour ce faire - sinon l'exécution du code se bloquera. D'une part, il semble que cette approche réduit la fiabilité globale: si une tâche se bloque, elle n'appellera jamais le répartiteur et l'ensemble du système cessera de répondre. D'un autre côté, un code linéaire ou un supercycle n'est pas mieux à cet égard - car ils peuvent geler avec exactement le même risque.

Cependant, un OS coopératif a un avantage important. Étant donné qu'ici le programmeur définit le moment de la commutation lui-même, cela ne peut pas se produire soudainement, par exemple, pendant que la tâche travaille avec une ressource ou au milieu du calcul d'une expression arithmétique. Par conséquent, dans un système d'exploitation coopératif, dans la plupart des cas, vous pouvez vous passer du maintien du contexte. Cela économise considérablement le temps et la mémoire du processeur, et semble donc beaucoup plus adapté à la mise en œuvre sur MK AVR.

Changement de tâche dans BASCOM AVR

Afin d'implémenter la commutation de tâches dans l'environnement BASCOM AVR, le code de tâche, dont chacune est implémentée comme une procédure normale, doit en quelque sorte appeler le répartiteur - également implémenté comme une procédure normale.
Imaginez que nous ayons deux tâches, chacune à un endroit quelconque de son code étant appelée par le répartiteur.

 sub task1() do '  1 '  loop end sub ' ---------------------------------- sub task2() do '  2 '  loop end sub 

Supposons que la tâche 1 a été exécutée. Voyons ce qui se passe sur la pile lorsqu'elle exécute un «appel de répartiteur»:

adresse de retour au code principal (2 octets)
haut de la pile -> adresse de retour à la tâche 1 qui a appelé le répartiteur (2 octets)

Le haut de la pile pointera vers l'adresse de l'instruction de la tâche 1, qui suit l'appel du répartiteur (l'instruction de boucle dans notre exemple).

L'objectif du répartiteur dans le cas le plus simple est de transférer le contrôle à la tâche 2. La question est de savoir comment procéder? (supposons que le répartiteur connaisse déjà l'adresse de la tâche 2).

Pour ce faire, le répartiteur doit extraire l'adresse de retour à la tâche 1 de la pile (et un endroit à retenir), puis mettre l'adresse de la tâche 2 à cet endroit de la pile, puis donner la commande de retour. Le processeur extraira l'adresse qui y est placée de la pile et, au lieu de revenir à la tâche 1, procédera à l'exécution de la tâche 2.

À son tour, lorsque la tâche 2 appelle le répartiteur, nous retirons également la pile et enregistrons l'adresse où il sera possible de revenir à la tâche 2 et de charger l'adresse de la tâche 1 précédemment enregistrée dans la pile. Donnez la commande de retour et nous serons au point de continuation de la tâche 1 .

En conséquence, nous obtenons un tel gâchis:

Tâche 1 -> Dispatcher -> Tâche 2 -> Dispatcher -> Tâche 1 ....

Pas mal! Et ça marche. Mais, bien sûr, cela ne suffit pas pour un système d'exploitation pratiquement utilisable. Après tout, toutes les tâches ne doivent pas toujours fonctionner - par exemple, elles peuvent s'attendre à quelque chose (l'expiration du délai, l'apparition d'un signal, etc.). Ainsi, les tâches doivent avoir un statut (TRAVAUX, PRÊT, ATTENDU, etc.). De plus, il serait bien que les tâches soient prioritaires . Ensuite, si plusieurs tâches sont prêtes à être exécutées, le répartiteur poursuivra la tâche qui a la priorité la plus élevée.

AQUA RTOS

Pour mettre en œuvre l'idée décrite, la coopérative OS AQUA RTOS a été développée, qui fournit les services nécessaires aux tâches et permet la mise en œuvre du multitâche coopératif dans l'environnement BASCOM AVR.

États des tâches AQUA RTOS

Les statuts suivants sont définis pour les tâches dans AQUA RTOS:

 OSTS_UNDEFINE OSTS_READY OSTS_RUN OSTS_DELAY OSTS_STOP OSTS_WAIT OSTS_PAUSE OSTS_RESTART 

Si la tâche n'a pas encore été initialisée, elle se voit attribuer le statut OSTS_UNDEFINE .
Après l'initialisation, la tâche a le statut OSTS_STOP .
Si la tâche est prête à être exécutée , elle se voit attribuer le statut OSTS_READY .
La tâche en cours d'exécution a le statut OSTS_RUN .
De là, elle peut aller aux statuts OSTS_STOP, OSTS_READY, OSTS_DELAY, OSTS_WAIT, OSTS_PAUSE .
Le statut OSTS_DELAY a une tâche remplissant un délai .
Le statut OSTS_WAIT est affecté aux tâches qui attendent un sémaphore, un événement ou un message (plus d'informations à leur sujet ci-dessous).

Quelle est la différence entre les statuts OSTS_STOP et OSTS_PAUSED ?
Si, pour une raison quelconque, la tâche reçoit le statut OSTS_STOP , la reprise ultérieure de la tâche (à la réception du statut OSTS_READY ) sera effectuée à partir de son point d'entrée, c'est-à-dire dès le début. À partir du statut OSTS_PAUSE, la tâche continuera de fonctionner à l'endroit où elle a été suspendue.

Gestion de l'état des tâches

Le système d'exploitation lui-même peut gérer automatiquement les tâches, ainsi que l'utilisateur, en appelant les services du système d'exploitation. Il existe plusieurs services de gestion des tâches (les noms de tous les services OS commencent par le préfixe OS_ ):

 OS_InitTask(task_label, task_prio) OS_Stop() OS_StopTask(task_label) OS_Pause() OS_PauseTask(task_label) OS_Resume() OS_ResumeTask(task_label) OS_Restart() 

Chacun d'eux a deux options: OS_service et OS_serviceTask (à l'exception du service OS_InitTask , qui n'a qu'une seule option; le service OS_Init initialise le système d'exploitation lui-même).

Quelle est la différence entre OS_service et OS_serviceTask ? La première méthode agit sur la tâche elle-même qui l'a provoquée; la seconde vous permet de définir comme argument un pointeur vers une autre tâche et donc d'en gérer une autre à partir d'une tâche.

Priorité et file d'attente des tâches

Comme mentionné ci-dessus, dans un système réel, certaines tâches peuvent être plus importantes, tandis que d'autres peuvent être secondaires. Par conséquent, une fonctionnalité utile du système d'exploitation est la possibilité d'attribuer une priorité aux tâches. Dans ce cas, s'il y a plusieurs tâches prédéfinies en même temps, le système d'exploitation sélectionnera d'abord la tâche avec la priorité la plus élevée. Si toutes les tâches prédéfinies ont une priorité égale, le système d'exploitation les mettra à exécution dans un cercle, dans un ordre appelé "carrousel" ou round-robin.

Dans AQUA RTOS, la priorité est affectée à une tâche lorsqu'elle est initialisée via un appel au service OS_InitTask , qui reçoit l' adresse de la tâche comme premier argument et un nombre compris entre 1 et 15 comme deuxième argument. Un nombre inférieur signifie une priorité plus élevée . Pendant le fonctionnement de l'OS, aucune modification de la priorité affectée à la tâche n'est fournie.

Retards

Dans chaque tâche, le retard est traité indépendamment des autres tâches.
Ainsi, pendant que le système d'exploitation calcule le retard d'une tâche, d'autres peuvent être exécutées.
Pour l'organisation des retards fournis les services OS_Delay | OS_DelayTask . L'argument est le nombre de millisecondes pendant lequel la tâche est retardée . La dimension de l'argument étant dword , le délai maximum est de 4294967295 ms, soit environ 120 heures, ce qui semble suffisant pour la plupart des applications. Après avoir appelé le service de retard, le répartiteur est automatiquement appelé, ce qui transfère le contrôle à d'autres tâches pendant la durée du retard.

Sémaphores

Les sémaphores dans AQUA RTOS sont quelque chose comme des indicateurs et des variables disponibles pour les tâches. Ils sont de deux types - binaires et dénombrables. Les premiers n'ont que deux états: libre et fermé. Le second est un compteur d'octets (le service de comptage des sémaphores dans la version actuelle d'AQUA RTOS n'est pas implémenté (je suis un paresseux), donc tout ce qui est dit ci-dessous ne s'applique qu'aux sémaphores binaires).

La différence entre un sémaphore et un simple indicateur est que la tâche peut être effectuée pour attendre la libération du sémaphore spécifié. À certains égards, l'utilisation de sémaphores ressemble vraiment à un chemin de fer: en atteignant le sémaphore, la composition (tâche) vérifiera le sémaphore, et s'il n'est pas ouvert, il attendra que le signal d'activation apparaisse pour aller plus loin. À ce moment, d'autres trains (tâches) peuvent continuer à se déplacer (rouler).

Dans ce cas, tout le travail noir est affecté au répartiteur. Dès qu'il est demandé à la tâche d'attendre le sémaphore, le contrôle est automatiquement transféré au répartiteur et il peut démarrer d'autres tâches - jusqu'à ce que le sémaphore spécifié soit libéré. Dès que l'état du sémaphore devient libre , le répartiteur affecte à toutes les tâches qui attendaient ce sémaphore l'état prêt ( OSTS_READY ), et elles seront exécutées dans l'ordre de priorité et de priorité.
Au total, AQUA RTOS fournit 16 sémaphores binaires (ce nombre peut, en principe, être augmenté en modifiant la dimension de la variable dans l'unité de contrôle des tâches, car à l'intérieur, ils sont implémentés sous forme de drapeaux binaires).
Les sémaphores binaires fonctionnent via les services suivants:

 hBSem OS_CreateBSemaphore() OS_WaitBSemaphore(hBSem) OS_WaitBSemaphoreTask(task_label, hBSem) OS_BusyBSemaphore(hBSem) OS_FreeBSemaphore(hBSem) 

Avant d'utiliser un sémaphore doit être créé . Cela se fait en appelant le service OS_CreateBSemaphore , qui renvoie l'identificateur d'octet unique (handle) du sémaphore hBSem créé, ou via le gestionnaire défini par l'utilisateur génère une erreur OSERR_BSEM_MAX_REACHED , indiquant que le nombre maximal possible de sémaphores binaires a été atteint.

Vous pouvez travailler avec l'identifiant reçu en le passant comme argument à d'autres services de sémaphore.

Service OS_WaitBSemaphore | OS_WaitBSemaphoreTask met la tâche (actuelle | spécifiée) dans un état pour attendre la libération du sémaphore hBSem si ce sémaphore est occupé, puis transfère le contrôle au répartiteur afin qu'il puisse démarrer d'autres tâches. Si le sémaphore est libre, le transfert de contrôle ne se produit pas et la tâche se poursuit simplement.

Les services OS_BusyBSemaphore et OS_FreeBSemaphore définissent le sémaphore hBSem sur occupé ou libre, respectivement.

La destruction des sémaphores afin de simplifier le système d'exploitation et de réduire la quantité de code n'est pas fournie. Ainsi, tous les sémaphores créés sont statiques.

Les événements

En plus des sémaphores, les tâches peuvent être pilotées par des événements. Une tâche peut être chargée d' attendre un certain événement , et une autre tâche (ainsi que le code d'arrière-plan) peut signaler cet événement. Dans le même temps, toutes les tâches qui attendaient cet événement recevront le statut prêt pour l'exécution ( OSTS_READY ) et seront définies par le répartiteur pour exécution dans l'ordre de priorité et de priorité.

À quels événements la tâche peut-elle répondre? Eh bien, par exemple:

• interruption;
• occurrence d'une erreur;
• libération de la ressource (il est parfois plus pratique d'utiliser un sémaphore pour cela);
• changer l'état de la ligne d'E / S ou appuyer sur une touche du clavier;
• recevoir ou envoyer un caractère via RS-232;
• transfert d'informations d'une partie de l'application à une autre (voir aussi messages).

Le système d'événements est implémenté via les services suivants:

 hEvent OS_CreateEvent() OS_WaitEvent(hEvent) OS_WaitEventTask(task_label, hEvent) OS_WaitEventTO(hEvent, dwTimeout) OS_SignalEvent(hEvent) 

Avant d'utiliser un événement, vous devez le créer . Cela se fait en appelant la fonction OS_CreateEvent , qui renvoie un identifiant d'octet unique (handle) pour l'événement hEvent , ou renvoie une erreur OSERR_EVENT_MAX_REACHED via le gestionnaire défini par l'utilisateur, indiquant que la limite du nombre d'événements pouvant être générés dans le système d'exploitation a été atteinte (255 événements différents maximum).

Pour faire attendre une tâche à un événement hEvent , appelez OS_WaitEvent dans son code, en passant le descripteur d' événement comme argument. Après avoir appelé ce service, le contrôle sera automatiquement transféré au répartiteur.

Contrairement au service de sémaphore, le service d'événements fournit une option pour attendre un événement avec un délai d'expiration . Pour ce faire, utilisez le service OS_WaitEventTO . Le deuxième argument ici, vous pouvez spécifier le nombre de millisecondes pendant lequel la tâche peut attendre l'événement. Si le délai spécifié a expiré, la tâche recevra le statut prêt à être exécuté comme si l'événement s'était produit et sera définie par le répartiteur pour poursuivre l'exécution dans l'ordre de priorité et de priorité. La tâche peut découvrir qu'il ne s'agissait pas d'un événement, mais d'un délai d'expiration, que la tâche pouvait vérifier en vérifiant l' indicateur global OS_TIMEOUT .

OS_SignalEvent , . , , , .

Des messages

, : , – .
:

 hTopic OS_CreateMessage() OS_WaitMessage(hTopic) OS_WaitMessageTask(task_label, hTopic) OS_WaitMessageTO(hTopic, dwTimeout) OS_SendMessage(hTopic, wMessage) word_ptr OS_GetMessage(hTopic) word_ptr OS_PeekMessage(hTopic) string OS_GetMessageString(hTopic) string OS_PeekMessageString(hTopic) 

, . OS_CreateMessage , hTopic , OSERR_TOPIC_MAX_REACHED , , , .

hTopic , OS_WaitMessage , . . , hTopic .

OS_WaitMessageTO OS_WaitEventTO .

OS_SendMessage . , , – word . , , , , .

, BASCOM varptr , , :

 strMessage = "Hello, world!" OS_SendMessage hTopic, varptr (strMessage) 

OS_WaitMessage , , , , — . . word , , , . OS_GetMessage , OS_PeekMessage .

, , OS_GetMessageString OS_PeekMessageString , , , .

AQUA RTOS TIMER0 . , ( ) . , .. . 1 .

AQUA RTOS

, . OS_SIM = TRUE | FALSE , .

, OS_MAX_TASK , . , ( ), . , . , .

AQUA RTOS . OS_Init . . , – . , , – .

( ) – , . , - .

, AQUA RTOS :

 OS_Init my_err_trap '... '... '... sub my_err_trap(err_code as byte) print err_code end sub 

, :

 OS_InitTask task_1, 1 OS_InitTask task_2 , 1 '... OS_InitTask task_N , 1 

, , Arduino Nano V3. - (, test), bas-:

 '    config submode = old $include "..\aquaRTOS_1.05.bas" $regfile = "m328pdef.dat" $crystal = 16000000 $hwstack = 48 $swstack = 48 $framesize = 64 '   declare sub my_err_trap (byval err_code as byte) declare sub task_1() declare sub task_2() '       led_1 alias portd.4 led_2 alias portd.5 config portd.4 = output config portd.5 = output ' ***    *** '   OS_Init my_err_trap '   OS_InitTask task_1, 1 OS_InitTask task_2 , 1 '      «» (OSTS_STOP) '    ,     ' «  » (OSTS_READY)   OS_ResumeTask OS_ResumeTask task_1 OS_ResumeTask task_2 '      OS_Sheduler end ' ***  *** sub task_1 () do toogle led_1 '   1 OS_delay 1000 '   1000  loop end sub sub task_2 () do toogle led_2 '   2 OS_delay 333 '   333  loop end sub ' **************************************************** '   sub my_err_trap(err_code as byte) print "OS Error: "; err_code end sub 

D4 D5 Arduino ( , - ). 100...500 GND . . 2 0,66 .

. , ( , aliases), – , – .

«», « » (, – - , , ; ). OS_ResumeTask .

, . ? , ! . , , , end .

. , do – loop . – , , – , . OS_Delay . , .

OS_SIM = TRUE , , , .

, , , « », . , « », .

, (, task_1 ), ( end ) task_1 , , return , – , task_1 ( do task_1 ).

task_1 , , OS_delay , , , .

, , task_1 ( , OS_delay , .. loop ), , « », , task_2 . task_2 ( do task_2 ) return , – , task_2 .

task_2 , , OS_delay , , , .

, , task_1 ( , OS_delay , .. loop ), , « », , task_2 . , task_1 , , . ( loop task_1 ), .

task_1 loop , « 1 – – 2 – » .

.

 '    config submode = old $include "..\aquaRTOS_1.05.bas" $regfile = "m328pdef.dat" $crystal = 16000000 $hwstack = 48 $swstack = 48 $framesize = 64 '   declare sub my_err_trap (byval err_code as byte) declare sub task_1() declare sub task_2() const OS_SIM = TURE '       '   dim hTopic as byte '     dim task_1_cnt as byte '    1 dim strMessage as string * 16 '  ' ***    *** OS_CreateMessage hTopic OS_Init my_err_trap OS_InitTask task_1 , 1 OS_InitTask task_2 , 1 OS_ResumeTask task_1 OS_ResumeTask task_2 OS_Sheduler end ' ***  *** sub task_1() do print "task 1" OS_Sheduler incr task_1_cnt '    1 if task_1_cnt > 3 then print "task 1 is sending message to task 2" strMessage = "Hello, task 2!" '    2 OS_SendMessage hTopic , varptr(strMessage) task_1_cnt = 0 end if loop end sub sub task_2() do print "task 2 is waiting messages..." '      1 OS_WaitMessage hTopic print "message recieved: " ; OS_GetMessageString (hTopic) loop end sub ' **************************************************** '   sub my_err_trap(err_code as byte) print "OS Error: "; err_code end sub 

:

task 1
task 2 is waiting messages…
task 1
task 1
task 1
task 1 is sending message to task 2
task 1
message recieved: Hello, task 2!
task 2 is waiting messages…
task 1
task 1
...

, . 1 task 1 , , . 2 task 2 is waiting messages... , hTopic , , 1. task 1 . , , 2 , 1 incr , .
task_1_cnt 1 , , – loop task 1 . , , 2 , . .

:

 '    config submode = old $include "..\aquaRTOS_1.05.bas" $regfile = "m328pdef.dat" $crystal = 16000000 $hwstack = 48 $swstack = 48 $framesize = 64 '   declare sub my_err_trap (byval err_code as byte) declare sub task_scankeys() declare sub task_led_1() declare sub task_led_2() '        led_1 alias portd.4 led_2 alias portd.5 config portd.4 = output config portd.5 = output button_1 alias pind.6 button_2 alias pind.7 config portd.6 = input config portd.7 = input '   dim eventButton_1 as byte dim eventButton_2 as byte ' ***    *** eventButton_1 = OS_CreateEvent '       eventButton_2 = OS_CreateEvent OS_Init my_err_trap OS_InitTask task_scankeys , 1 OS_InitTask task_led_1 , 1 OS_InitTask task_led_2 , 1 OS_ResumeTask task_scankeys OS_ResumeTask task_led_1 OS_ResumeTask task_led_2 OS_Sheduler end ' ***  *** sub task_scankeys() do debounce button_1 , 0 , btn_1_click , sub debounce button_2 , 0 , btn_2_click , sub OS_Sheduler loop btn_1_click: OS_SignalEvent eventButton_1 return btn_2_click: OS_SignalEvent eventButton_2 return end sub sub task_led_1() do OS_WaitEvent eventButton_1 toggle led_1 loop end sub sub task_led_2() do OS_WaitEvent eventButton_2 toggle led_2 loop end sub ' **************************************************** '   sub my_err_trap(err_code as byte) print "OS Error: "; err_code end sub 

AQUA RTOS

, . ; , , . , : , 95…97°; (, GSM-), .

« + + » , . , .
:

• – ControlHeater()
• – ShowGoods()
• / – AcceptMoney()
• – ScanKeys()
• – MakeChange()
• – ReleaseCoffee()
• – Alarm()

.
ControlHeater() , . , , . . 5.
ShowGoods() . , - . 8, .
ScanKeys() , . 3, 40 .
AcceptMoney() . , ScanKeys(), 20 .
MakeChange () . ReleaseCoffee() 10.
ReleaseCoffee() , . 2.
– , Alarm() – 1, , .

, . , EEPROM , .

 '    declare sub ControlHeater() declare sub ShowGoods() declare sub AcceptMoney() declare sub ScanKeys() declare sub MakeChange () declare sub ReleaseCoffee() declare sub Alarm() 

RTOS : ( , ) – .

, ReleaseCoffee() :

 sub ReleaseCoffee() do OS_WaitMessage bCoffeeSelection wItem = OS_GetMessage(bCoffeeSelection) Release wItem loop end sub 

ReleaseCoffee bCoffeeSelection , ( , ). , ReleaseCoffee() , , ( ) wItem OS_GetMessage . ReleaseCoffee() , :

 dim bCoffeeSelection as byte bCoffeeSelection = OS_CreateMessage() 

, ShowGoods() . ReleaseCoffee() , . :

 dim bGoodsReliased as byte bGoodsReliased = OS_CreateEvent() 

ReleaseCoffee() Release wItem bGoodsReliased :

 OS_SignalEvent bGoodsReliased 

, , , , . OS_Init :

 OS_Init Mailfuncion 

– , :

 sub Mailfuncion (bCoffeeErr) print "Mailfunction! Error #: "; bCoffeeErr if isErrCritical (bCoffeeErr) = 1 then CallService(bCoffeeErr) end if end sub 

( - : , GSM- ..), , , .

, , .. , . , OS_InitTask :

 OS_InitTask ControlHeater , 5 OS_InitTask ShowGoods , 8 OS_InitTask AcceptMoney , 3 OS_InitTask ScanKeys , 3 OS_InitTask MakeChange, 10 OS_InitTask ReleaseCoffee , 2 OS_InitTask Alarm , 1 

, , , , . . , OS_ResumeTask « »:

 OS_ResumeTask ControlHeater OS_ResumeTask ShowGoods OS_ResumeTask AcceptMoney OS_ResumeTask ScanKeys OS_ResumeTask MakeChange OS_ResumeTask ReleaseCoffee OS_ResumeTask Alarm 

, ; «» . OS_ResumeTask ( ), . , , , .

, . :

 OS_Sheduler 

end – .

:

 '    config submode = old $include "..\aquaRTOS_1.05.bas" $include "coffee_hardware.bas" '      '       Coffee_ $regfile = "m328pdef.dat" ' Arduino Nano v3 $crystal = 16000000 $hwstack = 48 $swstack = 48 $framesize = 64 Coffee_InitHardware '    '   declare sub Mailfuncion (byval bCoffeeErr as byte) '   declare sub ControlHeater () '   declare sub ShowGoods () '    declare sub AcceptMoney () '   declare sub ScanKeys () '   declare sub MakeChange () '      declare sub ReleaseCoffee () '   declare sub Alarm () '    '     Coffee_InitHardware () '   dim wMoney as long '    dim wGoods as long '   ' ***    *** '   OS_Init Mailfuncion '       dim bCoffeeSelection as byte bCoffeeSelection = OS_CreateMessage() '     dim bGoodsReliased as byte bGoodsReliased = OS_CreateEvent() '   OS_InitTask ControlHeater , 5 OS_InitTask ShowGoods , 8 OS_InitTask AcceptMoney , 3 OS_InitTask ScanKeys , 3 OS_InitTask MakeChange, 10 OS_InitTask ReleaseCoffee , 2 OS_InitTask Alarm , 1 '     OS_ResumeTask ControlHeater OS_ResumeTask ShowGoods OS_ResumeTask AcceptMoney OS_ResumeTask ScanKeys OS_ResumeTask MakeChange OS_ResumeTask ReleaseCoffee OS_ResumeTask Alarm '   OS_Sheduler end ' ***   *** ' ----------------------------------- sub ControlHeater() do select case GetWaterTemp() case is > 97 Coffee_HeaterOff '   case is < 95 Coffee_HeaterOn '   case is < 5 CallServce (WARNING_WATER_FROZEN) '   end select OS_Delay 60000 '  1  loop end sub ' ----------------------------------- sub ShowGoods() do LEDS = Coffee_GetDrinkSupplies() '    D, '         '   LEDS OS_WaitEvent bGoodsReliased '   " " loop end sub ' ----------------------------------- sub AcceptMoney() do wMoney = wMoney + ReadMoneyAcceptor() OS_Delay 20 loop end sub ' ----------------------------------- sub ScanKeys() do wGoods = ButtonPressed() if wMoney >= GostOf(wGoods) then OS_SendMessage bCoffeeSelection, wGoods '     bCoffeeSelection,  '     end if OS_Delay 40 loop end sub ' ----------------------------------- sub MakeChange() do OS_WaitEvent bGoodsReliased '   " " Refund wMoney loop end sub ' ----------------------------------- sub ReleaseCoffee() do OS_WaitMessage bCoffeeSelection '  bCoffeeSelection wItem = OS_GetMessage(bCoffeeSelection) '   Release wItem '    wMoney = wMoney – CostOf (wItem) '     OS_SignalEvent bGoodsReliased '     '  ,       : ' MakeChange  ShowGoods '  ,  ,     loop end sub ' ----------------------------------- sub Alarm() do OS_Delay 1000 if Hijack() = 1 then CallPolice() end if loop end sub ' ----------------------------------- ' ***    *** sub Mailfuncion (bCoffeeErr) print "Mailfunction! Error #: "; bCoffeeErr if isErrCritical (bCoffeeErr) = 1 then CallService() end if end sub 

, , . OS_SendMessage() , /. . , , , , .

AQUA RTOS

1.05

Q: AQUA?
A: , , « », , . , , , , « » WiFi-. , , , EEPROM , , - . . – « », , . , . AQUA.

Q: ?
A: . , , , , , . , . , , , , , , -, . , . , - ( ? – ) . .