Différences

Ci-dessous, les différences entre deux révisions de la page.

--- rotary_encoder_controller [2022/06/12 09:53] – serge
+++ rotary_encoder_controller [2022/06/30 14:07] – serge
@@ Ligne 18: / Ligne 18: @@
 ## Dépôt
 [Url github du dépôt](https://github.com/mxbossard/furuta)
+Le projet est compatible avec les 2 IDE :
+- Arduino IDE
+- PlatformIO
 ## Features
-TODO
+- Contrôle actuellement 2 capteurs
+- Enregistre les périodes entre chaque événement en µs.
+- Conserve une liste des périodes dont la taille est paramétrable.
+- Communique les positions et vitesse via SPI avec un master.
+- Vérification de l'intégrité des messages SPI avec CRC16.
-## Documentation SPI
-TODO
-## Qu'est-ce qui fonctionne
+## Tests
-TODO
+Construction d'un simulateur pour faire des tests :
+- 1 Version tout intégré contrôleur + simulateur sur le même ESP32.
+- 1 Version installé sur 2 ESP32 pour réaliser les tests de communication SPI et décorréler le code du simulateur et les interruptions du contrôleur.
-## Qu'est-ce qui reste à faire
+Limitations:
-- Prendre en compte les "événements simple" des capteurs (et réduire leur résolution d'un facteur 4) pour augmenter la fiabilité du contrôleur.
+- la génération des signaux de simulation sont interrompu lorsque l'on réalise les assertions : le test n'est pas complètement dynamique.
-- Paramétrer le mode de capture d’événement (simple ou quadratique)
-- Vérifier si la capture des évenements n'est pas buggé
-- Simplifier si possible la commande de timing du controller, en utilisant la pin d'activation (SS) du SPI si possible.
-- Rendre le projet compatible avec arduino ide: il suffit de rajouter le lien vers le gihub de sergelabo furuta_pi
+## Documentation de la communication SPI
+### Version initiale
+La version initiale de la communication nécessite 2 dialogues SPI pour récupérer les informations du contrôleur :
+- Le master envoie une commande "Timing" pour que le contrôleur prenne  une "photo instantanée" des capteurs et construise la payload à envoyer.
+- Le master attend un minimum de 100 µs pour que le contrôleur puisse construire la payload.
+- Le master envoie une commande "Read" pour recevoir les données des capteurs.
+#### Commande
+La commande timing comporte 4 Octets :
+- 2 Octets CRC16 (CRC16 xmodem calculé sur les 2 octets suivants)
+- 1 Octet "Marker" (valeur = 0 - 255)
+- 1 Octet "Commande" (valeur = 5 pour "Timing" ; 42 pour "Read")
+Ces 4 octets sont répétés 11 fois afin d'augmenter la probabilité que le contrôleur reçoive un message non corrompu.
+Le marker reçu par le contrôleur sera retourné par le contrôleur dans la payload. De sorte que le master peut vérifier que la payload reçu correspond à sa dernière commande de timing.
+#### Payload
+La payload comporte 50 Octets :
+- 2 Octets CRC16 (CRC16 xmodem calculé sur les 2 octets suivants)
+- 1 Octet "Marker" (valeur = 0 - 255)
+- 1 Octet "Header" (non utilisé pour le moment)
+- 2 Octets position capteur 1 (entier non signé sur 16 bits)
+- 2 Octets position capteur 2 (entier non signé sur 16 bits)
+- 2 Octets periode0 capteur 1 (entier non signé sur 16 bits)
+- 2 Octets periode2 capteur 1 (entier non signé sur 16 bits)
+- ...
+- 2 Octets periode9 capteur 1 (entier non signé sur 16 bits)
+- 2 Octets periode0 capteur 2 (entier non signé sur 16 bits)
+- 2 Octets periode2 capteur 2 (entier non signé sur 16 bits)
+- ...
+- 2 Octets periode9 capteur 2 (entier non signé sur 16 bits)
+- 2 Octets temps de construction de la payload (en 10zaine de µs)
+Pour 2 capteurs avec 10 périodes par capteur, la payload mesure 4 + 2 x (2 + 2 x 10) + 2 = 50 Octets.
+Le hash CRC16 est calculé sur les Octets 2 à 47. (Les octets 0-1 sont le CRC16 lui meme, les 2 derniers octets 48-49 ne sont pas utilisés).
+### Version "API"
+Quelques modification sont introduites pour la version API puisque le nombre de Capteurs et de Périodes est paramétrable.
+Seule la payload est modifiée.
+#### Payload
+La payload comporte un nombre d'octets variable, fonction du nombre de capteur et du nombre de périodes stoquées par capteur :
+- 2 Octets CRC16 (CRC16 xmodem calculé sur les 2 octets suivants)
+- 1 Octet "Marker" (valeur = 0 - 255)
+- 1 Octet "Header" (non utilisé pour le moment)
+- 2 Octets position capteur 1 (entier non signé sur 16 bits)
+- 2 Octets periode1 capteur 1 (entier non signé sur 16 bits)
+- 2 Octets periode2 capteur 1 (entier non signé sur 16 bits)
+- ...
+- 2 Octets periodeN capteur 1 (entier non signé sur 16 bits)
+- 2 Octets position capteur 2 (entier non signé sur 16 bits)
+- 2 Octets periode1 capteur 2 (entier non signé sur 16 bits)
+- 2 Octets periode2 capteur 2 (entier non signé sur 16 bits)
+- ...
+- 2 Octets periodeN capteur 2 (entier non signé sur 16 bits)
+- 2 Octets temps de construction de la payload (en 10zaine de µs)
+Pour 2 capteurs avec 10 périodes par capteur, la payload mesure 4 + 2 x (2 + 2 x 10) + 2 = 50 Octets.
+Le hash CRC16 est calculé sur tous les Octets exceptés les 2 premiers et les 2 derniers. (Les 2 premiers octets sont le CRC16 lui même, Les 2 derniers octets ne sont pas utilisés, car ils contiennent le temps de construction de la payload, calcul du CRC16 compris).
+## Qu'est-ce qui fonctionne
+- Le comptage des événements
+- Le calcul de la position
+- Le paramétrage du nombre de points
+- L'activation/désactivation du mode quadrature
+- Le calcul des périodes
+- Le stockage des périodes
+- La communication SPI
+- Le calcul des hash CRC16 en utilisant la variante xmodem
+- API pour utiliser la lib (begin, ...)
+## Qu'est-ce qui reste à faire
+- Tester le mode quadrature désactivé
+- Améliorer la performance des interruptions en rendant static le mode utilisé (quadrature ou non).
+- Simplifier si possible la commande SPI de timing du controller, en utilisant la pin d'activation (SS) du SPI si possible.
 </markdown>
 {{tag>communication petit_pendule_furuta
 }}