ModelleisenbahNInitialement je pensais séparer les fonctions nécessaires au TCO en deux. Une première carte de contrôle équipée d’un PIC 18F26K80 devait gérer l’acquisition des entrées provenant de l’utilisateur, voir à ce sujet « L’architecture électronique du cadre tactile », et envoyer via le bus CAN les coordonnées touchées. Une seconde carte équipée elle aussi d’un PIC 18F26K80 devait piloter des LED tricolores WS2812B et recevait les ordres d’affichage via le bus CAN également.
Outre les possibilités offerte par l’éclairage rouge/vert/bleu, le gros intérêt de ces LED est la simplicité de câblage. En effet, les LED de la série WS2812 sont chaînables et un seul fil suffit entre le micro-contrôleur et la première LED de la chaîne. Pour profiter de cette caractéristique il est préférable de faire une chaîne la plus longue possible. Par exemple, sur mon TCO, une architecture logique consisterait à former une chaîne de LED pour le dépôt (100 environ), une seconde pour la gare (75 environ) et une troisième pour le port et les boutons de commande globaux (100 environ).
Une chaîne est rafraichie entièrement par l’envoi d’une séquence de bits à une vitesse de 800kBits/s. cette séquence est très contrainte temporellement car il n’y a pas d’horloge séparée pour synchroniser l’émetteur et le récepteur lors de l’envoi des bits. De plus, le mode de fonctionnement fait qu’un rafraichissement d’une chaîne de LED n’est pas interruptible. Il n’est pas non plus possible de rafraichir une portion qui ne serait pas au début de la chaîne. Cette contrainte est extrêmement gênante car pendant le rafraichissement de la chaîne le micro-contrôleur ne peut pas exécuter d’autre tâche.
Notamment, les messages CAN entrant ne peuvent pas être traités pendant le rafraichissement. Par conséquent, si le temps de rafraichissement excède le temps de transmission d’un nombre de messages CAN plus grand que le nombre de tampons de réception matériels disponibles, un ou plusieurs messages seront perdus. D’une part, le bus CAN des accessoires travaille à 125kBits/s et le message CAN le plus court a une taille de 47 bits. D’autre part, le rafraichissement de 100 LED nécessite la transmission de 24 bits par LED, soit 2400 bits. Le temps nécessaire est donc de 3ms. Pendant ce temps, 8 messages CAN peuvent avoir été reçus.
Permettre de rafraichir les LED et de recevoir les messages CAN nécessiterait donc de saucissonner les chaînes de LED avec pour résultat de complexifier le logiciel mais surtout le câblage.
Il est donc préférable de dédier un micro-contrôleur au rafraichissement des LED et un second micro-contrôleur à l’interfaçage avec le bus CAN, les deux machines communicant via un bus série, le SPI par exemple. Le micro-contrôleur dédié au rafraichissement des LED serait un Arduino avec l’avantage de bénéficier de la bibliothèque Neopixel d’Adafruit. Il serait maître sur le SPI et ce serait donc lui qui initierait la communication afin de recevoir les commandes. De cette manière, l’acquisition de nouvelle commandes et le rafraichissement des LED seraient entrelacées sans concurrence. Le micro-contrôleur d’interfaçage avec le bus CAN serait un PIC 18F26K80. Il mettrait les commandes entrantes venant du bus CAN dans un tampon de taille suffisamment grande, par exemple une page entière de 256 octets, pour ne pas perdre de message alors que l’Arduino est en train de rafraîchir une chaîne de LED.
Cette tâche de passerelle entre le bus CAN et le bus SPI est légère et peut donc venir en plus de la gestion du balayage infrarouge du cadre tactile. Par conséquent, au lieu d’une architecture avec deux cartes, il s’agirait d’une architecture monocarte mais bi-processeurs.