Avantages du protocole Raw

• Prototypage très rapide du contrôle de votre système
• Simple à utiliser du côté de l’interface graphique ; Une simple affectation pousse une valeur hors du port
• Simple à manipuler de l’autre côté du fil dans votre code embarqué
• Léger, de sorte que l’interface graphique, par exemple, peut communiquer via l’UART avec un microcontrôleur 8 bits

Inconvénients du protocole Raw

• Pas de mise en paquet ; Vos communications peuvent être mal alignées ou désynchronisées
• Pas de vérification d’erreur ; La corruption des données en transit ne peut pas être détectée
• Pas de nouvelles tentatives automatiques ou de livraison garantie
• Type de données unique sorti, type de données unique entrant
• Pas de mise à jour du logiciel sur cette connexion ou d’accès à Protocole SHIPBridge fonctionnalités

Ces inconvénients sont importants. Bien que le protocole Raw puisse être utile dans les démos et les premières mises en service ainsi que dans des applications très simples, il est fortement recommandé au concepteur de considérer le Protocole Modbus pour des communications plus robustes. Mieux encore, le sophistiqué Protocole SHIPBridge devrait être pris en compte pour une connectivité de données flexible et puissante, ainsi que pour les mises à jour du micrologiciel sur le fil, etc.

FIFO de transfert de données typées

Le protocole Raw est implémenté sous la forme d’une paire de FIFO, l’un pour l’entrée, l’autre pour la sortie. La profondeur de ces FIFO dépend de l’exécution et de la plate-forme en fonction de la quantité de RAM disponible dans le système spécifique. Chaque FIFO a un type de données spécifique qu’il peut transporter.

Par exemple, vous pouvez envoyer des données Byte à votre appareil intégré. Dans ce cas, le FIFO de sortie aurait le type de données Byte.

Le type de données du FIFO d’entrée peut être différent de celui du FIFO de sortie. Par exemple, votre FIFO de sortie peut avoir le type de données Byte, mais votre FIFO d’entrée peut avoir le type de données String. Dans cette configuration, votre interface graphique pourrait envoyer des données Byte à l’autre MCU à l’autre extrémité de la connexion UART et que cette MCU renverrait des objets de données String – une séquence de caractères UTF-8 avec une terminaison nulle.

Le type de données doit être spécifique et immuable pendant le fonctionnement d’une interface graphique donnée, car il n’y a pas d’en-têtes de paquets ou d’autres éléments qui pourraient indiquer un changement message par message dans le type de données transmises. Le microcontrôleur embarqué ou tout ce qui se trouve à « l’autre bout du fil » doit être capable d’assumer un format spécifique pour les données entrantes et sortantes, tout comme l’interface graphique.

Construction d’un lien de protocole brut dans SHIPTide

Comme pour tous les protocoles en SHIP, un nœud de liaison dans la ressource lie un protocole à un canal de communication.

Dans SHIPTide, dans la zone Ressources sous liens, faites un clic droit et « ajouter un lien », puis configurez le lien pour instancier un nœud de lien avec protocole Raw lié au port de communication série asynchrone UART0 de la SIM.

Lorsque vous effectuez cette action, contrairement à d’autres protocoles, la structure sous le lien sera automatiquement remplie avec un ensemble fixe de nœuds :

• un ensemble de liens nommé « raw »
• un ensemble de linkvars pour la gestion des FIFO d’entrée et de sortie

La structure ressemble à ceci :

Les linkvars sont les suivantes :

iData et oData

Les linkvars iData et oData sont respectivement le FIFO d’entrée et le FIFO de sortie. Vous ne pouvez accéder qu’à la fin des FIFO : la lecture à partir d’iData récupère l’élément supérieur du FIFO d’entrée, et l’écriture dans oData pousse un nouvel élément à l’arrière du FIFO de sortie.

Notez que les accès à iData et oData sont assez uniques dans SHIP : la lecture à partir d’iData supprime un élément du FIFO et l’écriture dans oData ajoute un élément au FIFO. Soyez très attentif à ce comportement : lire deux fois à partir d’iData, par exemple, supprimera deux éléments du FIFO (en supposant qu’il y en ait deux disponibles).

Lorsque vous instanciez le lien pour la première fois, vous remarquerez (comme dans l’image ci-dessus) qu’il y a une erreur sur iData et oData. En effet, la propriété datatype n’a pas encore été définie pour les FIFO d’entrée et de sortie. Votre première tâche sera de définir ces types de données. Par exemple, si vous souhaitez disposer d’une entrée et d’une sortie d’octets, définissez le type de données iData et oData sur Octet.

iState, oState et les constantes d’état

Dans la structure, vous remarquerez également deux autres nœuds linkvar nommés iState et oState. Il s‘agit de linkvars spéciaux qui indiquent respectivement l’état des FIFO d’entrée et de sortie iData et oData.

Lorsqu’une activité se produit sur un FIFO, la linkvar d’état respective génère un événement qui peut être écouté par un écouteur et une action entreprise par un gestionnaire de script.

Les linkvars iState et oState  peuvent, à tout moment, avoir l’une des valeurs suivantes :

• AJOUTÉ – un élément a été ajouté à ce FIFO
• SUPPRIMÉ – un élément a été retiré de ce FIFO
• FULL – FIFO est devenu complet après un ADDED
• VIDE – FIFO est devenu vide après un
• OVERRUN — FIFO a dépassé (était plein) après une tentative d’ajout
• UNDERRUN – FIFO était vide et une tentative de suppression a été tentée (s’applique uniquement à iData)

Envoi de données

Lorsque les données sont placées sur le FIFO de sortie, via un code tel que myLink.raw.oData = 0x00;

la variable oState deviendra la valeur ADDED. Si le FIFO est devenu plein à la suite de cette action, il passera alors à FULL. Si le FIFO était plein lors de la tentative d’ajout de l’octet au FIFO, la variable oState ne passera pas par l’état ADDED, mais passera directement à l’état OVERRUN.

Le système de transmission à l’intérieur de SHIPEngine commencera automatiquement à envoyer les données hors du canal de communication. Il supprime des éléments de l’en-tête du FIFO oData et les met en file d’attente hors du port. Lorsqu’il effectue la suppression, l’  événement d’état REMOVED sur oState est généré et un état EMPTY ultérieur  est généré si le FIFO est devenu vide à la suite de cette suppression. Un événement UNDERRUN ne sera jamais généré sur oState.

La variable oState a la propriété très inhabituelle dans SHIP de générer des événements lorsqu’ils sont mis à jour, même s’ils sont inchangés. En d’autres termes, contrairement à presque toutes les autres propriétés et valeurs de SHIP, lorsque l’oState a une activité REMOVED répétée  (par exemple), un événement sera généré pour les deux même si la valeur de oState n’a pas changé.

Par conséquent, à l’aide de nœuds d’écoute et de scripts, vous pouvez compter les événements ADDED et les  événements REMOVED et savoir à tout moment combien d’éléments se trouvaient dans la FIFO oData de sortie.

Pour les données de sortie à très basse fréquence, vous pouvez simplement envoyer des octets (données) en utilisant des affectations simples comme vous le souhaitez, par exemple myLink.raw.oData = 0x01; dans n’importe quel contexte, par exemple lorsqu’un bouton à l’écran est enfoncé. Dans ces cas, la probabilité d’un FIFO plein/dépassement est minime avec un débit en bauds raisonnable.

Toutefois, si la fréquence des mises à jour des données de sortie est supérieure à celle du débit en bauds, de sorte qu’il existe un risque de dépassement du FIFO de sortie (par exemple, en attribuant rapidement oData successivement jusqu’au point où le FIFO de sortie est surchargé et génère l’événement OVERRRUN), vous devez effectuer ces affectations de manière plus structurée. Il existe de nombreux facteurs dépendant de l’application graphique dans la façon dont vous procédez. Par exemple, il peut s’agir d’une condition que vous souhaitez indiquer à l’utilisateur d’attendre pendant que le FIFO se vide et que tous les messages sont envoyés, ou que vous pouvez ignorer cette condition et que la demande de sortie peut être quelque chose que vous pouvez réessayer ultérieurement.

Une façon de surveiller et de gérer cette condition est, par exemple :

1. Créer une variable de stockage  (par exemple, appelée oDataReady) en tant que booléenne avec la valeur initiale true.
2. Assurez-vous que la variable/l’écouteur se trouve au début de l’arborescence de disposition afin qu’il soit toujours traité tôt lorsque oState change
3. Crée un écouteur sous cette variable qui, lorsque oState est FULL,  définit ce booléen a false et lorsque oState est REMOVED, il lui vaut  true.
4. Lorsque vous souhaitez envoyer une valeur, vérifiez que cette variable est vraie. Si ce n’est pas le cas, le FIFO est plein et vous ne pouvez pas en envoyer un à ce moment-là sans risquer un DÉPASSEMENT

Réception de données

Si votre interface graphique doit attendre et traiter des objets entrants, créez un écouteur sur votre linkvar iState et définissez une condition recherchant spécifiquement l’état « ADDED » :

Cet écouteur se réveille chaque fois qu’un nouvel état se produit sur la fenêtre de liaison iState. Dans ce cas, la propriété condition teste cet événement pour s’assurer qu’il s’agit de l’  événement ADDED. Si c’est le cas, tout script joint sera exécuté.

Par exemple, si cet écouteur se trouve à l’intérieur d’un nœud de texte et que vous souhaitez que le texte change automatiquement pour refléter l’octet entrant, vous pouvez faire en sorte que la structure ressemble à ceci :

Notez bien que cette action de « récupération » à partir d’iData dans l’affectation de texte supprime l’élément du FIFO. Si vous avez besoin de plusieurs emplacements dans votre interface graphique pour accéder à ce nouvel élément de données, vous devez créer une variable d’attente dans votre interface graphique pour cette valeur entrante et attribuer iData à cette variable d’attente, et tous les « consommateurs » de ces données doivent accéder à cette variable d’attente. Ce mécanisme garantit une seule récupération par article entrant.

La variable iState a la propriété très inhabituelle dans SHIP de générer des événements lorsqu’ils sont mis à jour, même s’ils sont inchangés. En d’autres termes, contrairement à presque toutes les autres propriétés et valeurs de SHIP, lorsque l’iState a une activité REMOVED répétée  (par exemple), un événement sera généré pour les deux même si la valeur de l’iState n’a pas changé.