Difference between revisions of "Projets:Perso:2015:LedTube:Protocole"
(→Protocole série / UDP) |
(→Protocole série / UDP) |
||
Line 25: | Line 25: | ||
* un vecteur vitesse de translation horizontale (nombre flottant dans [-1,1]). En tours par seconde. | * un vecteur vitesse de translation horizontale (nombre flottant dans [-1,1]). En tours par seconde. | ||
* une demande de changement de mode de génération d'image. | * une demande de changement de mode de génération d'image. | ||
− | * une commande d'intensité lumineuse | + | * une commande d'intensité lumineuse |
Il n'est pas nécessaire de limiter le nombre de commande par trame UDP à 1. Le parser gère les données reçues comme un stream continu. | Il n'est pas nécessaire de limiter le nombre de commande par trame UDP à 1. Le parser gère les données reçues comme un stream continu. |
Revision as of 17:38, 18 April 2019
Protocole série / UDP
- SSID WIFI : LEDTUBE
- WIFI protection : OPEN
- DHCP activé
- DHCP Range : 192.168.1.1 - 192.168.1.???
- Adresse IP du module WIFI sur le réseau WIFI : 192.168.1.0
- Masque sous réseau 255.255.255.0
- Numéro de port UDP : 5125 (decimal)
Une interface UDP/IP est offerte pour y injecter des images et envoyer des commandes.
Le système n'envoie jamais rien vers le device connecté.
La limitation de débit est liée à la liaison série entre le MCU et le module WIFI. Elle est à 115200 bauds. Soit un débit utile proche de 92kbits/s.
Le système ne peut recevoir que les choses suivantes
- une commande ON/OFF sortie de veille, mise en veille
- des images en RAW en trois trame UDP pour les images fixes
- une commande d'initialisation de la translation (nombre flottant dans [-1,1]).
- un vecteur vitesse de translation horizontale (nombre flottant dans [-1,1]). En tours par seconde.
- une demande de changement de mode de génération d'image.
- une commande d'intensité lumineuse
Il n'est pas nécessaire de limiter le nombre de commande par trame UDP à 1. Le parser gère les données reçues comme un stream continu.
Les commandes ne sont jamais acknoledgées. Le système n'envoie jamais rien en réponse, quoi qu'il arrive. Aucun message spontané non plus.
Il est à noter que le passage en TCP ne demanderait que très peu de changement dans la mesure où en réalité, le parser gère un stream.
Pas de notion de sprites. Pas de notions de couches superposées transparentes. On va pas refaire le chipset de l'amiga.
Les commandes sont aussi exprimées ci-dessous en syntaxe sprintf.
Par exemple, la commande POS qui a un paramètre variable en nombre flottant à nombre de décimales fixe est documentée en utilisant le formatage de la commande en langage C sprintf.
float pos;
sprintf(s,"LEDTUBE:POS:%+01.4f$$",pos);
Les Commandes
Commande On/Off
- "LEDTUBE:OFF:$$" (exemple)
Commande init translation, exprimée en unité de tour. Paramètre = Nombre flottant à virgule fixe dans [-1,1]
- "LEDTUBE:POS:???????$$" (masque parser de commande)
- "LEDTUBE:POS:%+01.4f$$" (syntaxe sprintf pour le formatage en C)
- "LEDTUBE:POS:+0.2445$$" (exemple)
- "LEDTUBE:POS:-0.1200$$" (exemple)
Commande vecteur vitesse de translation horizontale, exprimé en tours par seconde. Paramètre = Nombre flottant à virgule fixe dans [-1,1]
- "LEDTUBE:SPD:???????$$" (masque parser de commande)
- "LEDTUBE:SPD:%+01.4f$$" (syntaxe sprintf pour le formatage en C)
- "LEDTUBE:SPD:-0.1112$$" (exemple)
Commande Image Raw
- "LEDTUBE:RAW:" (masque parser de commande)
- "LEDTUBE:RAW:[RGB](1200x)" (pseudo syntaxe)
- "LEDTUBE:RAW:RGBRGBRGBRGB..." (exemple.Nota : il n'y a pas de $$ à la fin)
- En raison des limitations du module WIFI, les images peuvent être envoyées en un minimum de 3 trames UDP de taille 1212,1200,1200. Ou bien 4 trames UDP de taille 12,1200,1200,1200
- Respecter un délai entre chaque envoi de trame d'au moins 94ms.
- La durée totale d'envoi ne doit pas dépasser 5 secondes (time out).
- Le code source fourni dans le package complet : sendrawbyudp.cpp , ltraw.exe permet de faire ça sur PC.
Les images sont en 60x20 pixels. Le premier pixel envoyé est en haut à gauche de l'image. Images Envoyées en lignes. Ordre RGBRGBRGB...
L'image n'est pas sauvée en flash.
Commande Image Raw (avec CRC32) destinée à être sauvée en Flash
- "LEDTUBE:RWC:" (masque parser de commande)
- "LEDTUBE:RWC:[[RGB](400x)CRC32](3x)" (pseudo syntaxe)
- "LEDTUBE:RWC:RGBRGBRGBRGB..." (exemple.Nota : il n'y a pas de $$ à la fin)
- En raison des limitations du module WIFI, les images peuvent être envoyées en un minimum de 3 trames UDP de taille 1216,1204,1204. Ou bien 4 trames UDP de taille 12,1204,1204,1204
- Respecter un délai entre chaque envoi de trame d'au moins 94ms.
- La durée totale d'envoi ne doit pas dépasser 5 secondes (time out).
Les images sont en 60x20 pixels. Le premier pixel envoyé est en haut à gauche de l'image. Images Envoyées en lignes. Ordre RGBRGBRGB...
Si l'image est déjà en flash, elle est juste affichée. Si l'image est nouvelle, elle s'ajoute ou remplace la plus ancienne image.
La version 446RE gère 32 images.
Changement de mode. Paramètre entier en hexadecimal dans [0000..]
- "LEDTUBE:MOD:????$$" (masque parser de commande)
- "LEDTUBE:MOD:%04X$$" (syntaxe sprintf pour le formatage en C)
- "LEDTUBE:MOD:000A$$" (exemple)
Changement de l'intensité lumineuse (dans tous les modes). Paramètre entier hexadecimal dans [0000..00FF]
- "LEDTUBE:INT:????$$" (masque parser de commande)
- "LEDTUBE:INT:%04X$$" (syntaxe sprintf pour le formatage en C)
- "LEDTUBE:INT:008A$$" (exemple)
Les Modes (MOD)
Modes (decimal)
- 0 : Mode statique. Le système passe dans ce mode à chaque réception d'une image RAW.
- 1..5 : plasma dynamique de couleurs variées
- 6 : 3 logos Electrolab Verts
- 7 : uniformément noir
- 8 : uniformément blanc
- 9 : uniformément jaune
- 10 : 3 logos Electrolab Verts
- 11 : jeu de la vie
- 12..20 : plasma dynamique de couleurs variées
- 21 : effets noël (code pololu https://github.com/pololu/pololu-led-strip-arduino/tree/master/examples/LedStripXmas)
- 22..53 : 32 images en flash
- etc...