ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

TSV Safe Express: Timing issues.

Today Alexis delivered us the whole set of the train light circuit. Initially we tried to add another light card to our current testing configuration. We managed to get 2 light cards configured , so up to this point the central station has been able to control 2 light cards, the train and an ethernet connection  in total.

Currently we are working on stabilizing the  NMRAnet CAN bus protocol. We encountered problems  of what we think mainly concern,  a difference between the CAN bus bandwidth  and the processing bandwidth of the central station. For example, as we observed, during programming the events of a node,  within an environment of multiple CAN packets exhange, the central station missed acknowledgement frames sent by the node after  the configuration file. This prevented the central station from successfully programming a node. After inserting a delay between sending the data of the configuration file and the ACK we observed that the node got successfully programmed. This led us to assume a mismatch in processing and CAN bus bandwidth.

In order to face these kind of problems which have appeared, we will adjust the CAN bus bandwidth, use one buffer for event processing and another one for network-management purposes, and additionally install event filters on the fly accordingly for each node.

 

TSV Safe Express: DCC Signals and Ethernet

Our journey has continued from CAN to LAN passing through DCC in its way. During the last two days, we tried to write the dcc encoder for our card which will act as the central station. In brief, I will try to explain DCC for all those who are not already aware of it. DCC (Digital Command Control) is a standard which permits us to operate model railways by sending modulated pulse wave(amplified with the help of a booster) to the rail tracks. Thereby, we can control any locomotive or accessory (like Traffic lights) if they have the dcc decoder. DCC is standard provided by NMRA.
We have done the following encodings for bit 0 and 1 as per NMRA DCC Standard.
(i) bit ’0′ – 232 microseconds (half high and half low)
(ii) bit ’1′ – 116 microseconds (half cycle is low)
On the implementation part, to generate such type of signal on the STM32 GPIO port, we use PWM module(using Internal Timer of STM32) with 50% duty cycle. This was setup in Output Compare Mode. Through the help of oscilloscope, we verified that we got the expected results. We created a dcc packet simulator(coded as a task of FreeRTOS) and we tried sending Messages to the port as per DCC Communication Packet format.

On the Ethernet part, we have chosen LwIP Stack as the TCP/IP Stack. We have chosen LwIP primarily as it has features like DHCP, UDP, IPv6 which we may need as the project matures further. So, we integrated the LwIP stack with STM32F107(which has in-built MAC Controller) and DP83848P Phy Controller taking help of a similar example provided by ST on their website. We were able to make a telnet connection to our Central Station and correponding exchange messages through telnet.

On the stabilisation of NMRA CAN protocol, we added a watchdog module within all the nodes including the central station. This was required because if the software hangs in one of the nodes, it should have the ability to re-join the network. The timeout of the watchdog module has been kept to 3 seconds(Typically because we want our nodes to rejoin the network as soon as possible and at the same time give Central Station enough time to remove this node from the node table and event table). Also, the command to reset the nodes sent by the network manager at the start of his execution as a broadcast message to all the nodes will have a deeper impact. Instead of doing a cache reset at the nodes, we are now doing an actual software reset to the node. This is just to simulate an actual reset. All these changes done to stabilisation are open for discussions and all remarks/critics/ideas are heartily welcomed.

TSV Safe Express: à partir de carte TP à la carte réelle

Pendant le week-end, nous avons essayé de stabiliser le protocol de NMRAnet (CAN bus) avec trois cartes. Nous avons réussi avec 3 cartes mail il y avait beaucoup de problèmes quand on utilise plus que un carte pour le nœud. Les plus importants sont:-
Pour rappel, nous avons 3 cartes – Un carte central station, 2 qui sont nœuds.
1. Premier nœud se timed out lorsque le deuxième nœud entre dans le réseau –
Raison- Il y avait trop des paquets à partir de le nouvelle carte parce que Il se fait programmé. Alors, le « network manager » supprime le premier nœud s’il ne reçoit pas le paquet état ​​dans un délai prédéterminé.
Solution- Utilise le CAN Filter qui lui permet de recevoir que les paquets qui le concernent. ça va dire , une fois le filtre statique est installé, les nœuds ne recevraient pas de paquets qui sont envoyés par d’autres nœuds soit le gestionnaire du réseau (« Network Manager »)ou de l’outil de configuration(« Configuration Tool »).
Futur Développement possible – Actuellement, pour les évènements de carte feux(« Consumer ») il n’y a pas de filtres qui signifie que chaque noeud reçoit les événements qui sont générés par d’autres. Pour cela, nous avons besoin d’installer des filtres CAN dynamiquement en fonction du nombre d’événements qui lui sont donnés par le gestionnaire du réseau. Nous le ferons en fonction de comment ça se passe avec les 12 attendus plus de cartes.

2. Redémarre de le nœud ne marche pas –
Raison – Si le redémarrage est très rapide, le nœud n’a pas reprogrammé par l’outil de configuration. C’est parce que le gestionnaire de réseau n’a pas assez de temps pour lui de supprimer de sa table nœud.
Solution – Après le redémarrage, le nœud inactif pendant 3 secondes qui donne la gare centrale de suffisamment de temps pour lui supprimer.
Futur Développement possible – Au lieu de dormir aveugle de 3 secondes, l’introduction de l’Etat en fonction le contrôle opérationnel au niveau du « Network Manager ».

3. Redémarre de le station central –
Raison – Depuis le nœud est déjà programmée, ainsi qu’il ne devient pas programmé encore par l’outil de configuration.
Solution – Au démarrer de la gare centrale, il envoie une commande broadcaste à tous les nœuds de se réinitialiser.
ça marche mais avec deux carte, ça ne marche plus. Juste une carte, qui devient programmé. Nous sommes en train de trouver la raison.

Pour le Carte Feux (pas de TP) – Nous avons réussi avec CAN et nous pouvons contrôle cette carte à partir de station central. Maintenant, Theodoros, il est en train de travailler sur le SPI. Siwar continue de travailler à CAN bootloader. Vaibhav travaille sur le code existant.

TSV Safe Express: Le débogage avec bus CAN

Hier, nous avons eu problèmes avec multiple nœuds. Alors, aujourdhui, nous essayions de stabiliser le protocol NMRA pour le bus CAN. Un problème intéressant a été les paquets du bus CAN ne sont pas dans le bon ordre. Qu’est-ce qui se passait?
Notre théorie est la suivante. Nous avons « transmit mailbox » dans le contrôleur CAN avec la capacité de 3. La fonction de transmission de la bibliothèque CAN tente de trouver « transmit mailbox  » vide et envoyer le paquet. Supposons qu’il écrit le premier paquet en deuxième mailbox , puis premier mailbox (car il a trouvé les mailboxes vide dans cet ordre). Mais la transmission de messages CAN commence de 0 mailbox. Ainsi, les paquets ne sont pas envoyés dans l’ordre correct.

Une solution possible peut être de s’assurer d’utiliser une seule mailbox pour envoyer des messages CAN. Cela peut être réaliser en commençant par transmettre CAN gestionnaire d’interruption qui se synchronise avec le CAN transmettre fonction à l’aide de sémaphores. Mais, avec ça nous ne pouvons pas prendre l’avantage de trois mailbox. D’autres solutions sont les bienvenus.

Avec, le bootloader, nous avons réussi en faire le lecture et écriture sur le flash. Maintenant, nous sommes en train de faire le l’autre choses de bootloader comme le usart.

Nous avons reçu noter carte feux. Demain, nous allons faire le SPI pour cette carte.

TSV Safe Express: NMRAnet CAN bus.

Après les tests que nous avons fait sur le mode loopback du bus CAN, aujourd’hui nous avons relie nos cartes de TP afin de teste les modules que nous avons développé jusque a maintenant. Nous avons commence avec deux cartes. Nous avons utilise une carte comme un « central station » et l’autre comme une « carte feux ».

En développant le code nous avons essayé de suivre aussi strictement que possible  la norme CAN bus de NMRAnet, concernant le format des messages CAN, la gestion du réseau et les mécanismes de configuration des évènements producer/consumer. Nous avons utilise le mode « extended identifier » des 29 bits du bus CAN, et nous l’avons forme respectant la norme NMRA. La gestion du réseaux est responsable pour l’assénement des adresses des nœuds et pour détecter l’état du circuit. Les adresses qui sont assignes par le « network manager »  sont utilisées soit pour identifier l’état d’un nœud avec une adresse x, soit par le « configuration tool » pour configure le table d’événements du node avec une adresse x. Ca veut dire que a la suite, si le station central veux allume un feu, il n’envoie pas un message du type <adresse x><événement>  mais il envoi seulement l’événement.

Pendant la journée nous avons vérifie le fonctionnement du système en utilisant un station central et une carte feux. Nous avons réussi de allume les leds de la carte feux. A la suite nous avons essaye d’ajouter une carte feux en plus, mais les résultats n’étaient pas satisfaisants.. Au même temps nous avons réussi a configure les filtres CAN et nous avons commencé a écrive du code pour le bootloader CAN.

TSV Safe Express: travail du Lundi

Aujourd’hui, nous avons avancé sur deux axes: l’implémentation du standard NMRA et celle du Bootloader CAN.

Concernant le NMRA, Théodor et Vaibahv ont fini l’implémentation du Network Manager ( Le code actuel se trouve dans leurs branches.)

Ils ont avancé ensuite dans la programmation du « Configuration Tool« .

Demain, ils vont finir la partie configuration pour entammer ensuite l’implémentation du protocole consumer/producer.

De ma part, je me suis fixée les idées sur l’implémentation du Bootloader. J’ai divisé mon travail en trois parties:

sendToUART    =>    UART_To_CAN   =>   CAN_To_MemoryAccess

La première partie est facile, il suffit d’initialiser l’UART et d’activer le Bootloader intégré .

Pour la deuxième partie, il faudra groupper les bytes provenant de UART pour envoyer des messages CAN correspondants avec un header de 29 bits et une partie data de 8bytes au maximum.

Pour la troisième partie, j’ai commencé à implémenter du code pour accéder à la mémoire Flash comme décrit dans les diagrammes du manuel, puis j’ai trouvé des fonctions toutes prêtes dans la bibliothèque. J’ai écrit du code qui reçoit une commande d’écriture après activation du Bootloader CAN, prend l’adresse sur 4 bytes et vérifie si elle est valide et commence à flasher les packets reçus.

Je finis bientôt l’implémentation de la partie qui flashe le code à partir de messages CAN. Il reste par exemple d’assurer l’alignement des adresses et d’envoyer des messages d’ ACK pour signaler le bon flashage du code.

 

Le schéma suivant représente les relations entre nos 3 types de cartes à travers le bus CAN et les différentes parties faites ou à faire:

 

TSV Safe Express: le bus CAN continué

Aujourdhui, Nous avons essayé de comprendre le norme du NMRA pour le bus CAN. ça va dire quel sort de packet nous avons besoin. Nous utilisons le CAN 2.0 B « Extended Frame Format » comme mentionné dans le standard du NMRA. Nous avons écris le code qui permet de faire le conversion entre le packet du NMRA et CAN packet(CAN standard packet). Aprés cela, nous avons fait le test du conversion.

Nous avons essayé de faire « filters » dans CAN mais nous navons pas réussi.

Nous avons eu quelque problèmes avec comprendre le norme du NMRA qui contrôle les feux. Nous devons être capable contrôler les LED à partir de messages du bus CAN sûr le carte de TP. Exactement, nous n’avons pas compris « Producer/Consumer Events » dans le norme. Nous avons posté sur les forums comme modelrailforum, rocrailforum. Aussi, nous avons envoyé un email à le NMRA (« Development Team »)
Mais aucune réponse jusqu’à maintenant.

TSV Safe Express: CAN bus.

Aujourd’hui hui nous avons travaillé sur la communication de nos cartes de TP avec le Bus CAN. Alexis a modifier les cartes TP et nous a débloque. Donc les premiers messages sont envoyés. Apres ca nous avons fait une répartition sur les taches qui concernent le bus CAN. Siwar est en train de implémenter le Bootloader CAN , afin de programmer les cartes avec un manière simple et efficace, et Vaibhav et Theodoros sont en train de implementer le standard CAN de NMRA sur les cartes de TP.

TSV Safe Express prend son chemin

Ces deux jours, nous nous sommes renseignés sur les éléments existants de notre projet.
Nous avons à notre disposition:

  • le circuit du train avec 60 capteurs de position
  • un train qui possède déjà un décodeur DCC
  • un booster pour l’amplification de la commande qui sera passée sur les rail
  • des aiguillages qui sont commandés à travers une carte avec un protocole non universel

Sinon, chacun d’entre nous à fait une petite recherche sur le web:

  • Theodoros nous a informé sur le principe de fonctionnement du protocole DCC, ainsi que sur le circuit de rectification pour l’alimentation du décodeur DCC.
  • Vaibhav nous a informé sur openDcc pour avoir une idée sur l’implémentation du protocole DCC. Il s’informe encore sur la façon d’utiliser Rocrail.
  • Siwar a commencé à s’informer sur le protocole du bus CAN et la façon de l’implémenter sur un microprocesseur. Elle s’est chargée aussi de voire les limites du projet et répartir les Pssc.

Nous pourrons tester nos petites cartes à l’aide d’un appareil qui envoie des commandes DCC, ainsi qu’en utilisant le carte du TP avec le controleur CAN.Nous avons fixé à la fin un emploi de temps interne afin de tenir les délais des Pssc le maximum possible.
Ce Week end, on va commencer à déterminer les composants de chaque carte (centrale,capteur position, feux..)