2014-04-18 2 views
0

J'ai un module wifly RN-171 connecté à un microcontrôleur. J'utilise le protocole UDP pour communiquer avec le module. En outre, j'utilise la fonction de paire automatique UDP du microprogramme pour définir l'adresse IP de l'hôte. Dès que le module reçoit un paquet UDP, il définit l'adresse IP de l'hôte à l'adresse IP à partir de laquelle il a reçu les données. Maintenant, cet ip hôte ne peut pas être changé sans entrer dans le mode de commande.Configurer le module Wifly pour recevoir les paquets UDP

Je souhaite que le module se comporte de la manière suivante: Chaque fois qu'il reçoit un paquet UDP, il met à jour l'adresse IP de l'hôte vers l'adresse IP d'où provient ce signal.

En outre, je peux utiliser le protocole TCP mais il ne permet qu'une seule connexion à la fois. Un autre problème que j'ai rencontré en utilisant le protocole TCP était que si j'essaye d'initier une deuxième connexion TCP avec le module, non seulement il refuse la deuxième connexion mais bloque également la première connexion stable. Même si le second démarrage de la connexion ne bloque pas le module et qu'il est simplement refusé, je serai prêt à travailler avec TCP.

J'ai fait beaucoup de recherches sur le web concernant ce problème mais comme ces modules ne sont pas largement utilisés, ils ont un support très limité.

Répondre

0

J'ai beaucoup utilisé la RN-171 et j'ai de nombreux tickets résolus dans leur système de support.

Selon le WiFly Command Reference, Advanced Features and Applications User’s Guide, vous ne pouvez pas ouvrir plus d'un port TCP avec le module. (le nombre par défaut étant 2000)

Malheureusement, en ce qui concerne la fonctionnalité UDP, vous ne pouvez pas faire grand-chose. Si vous avez un nouvel hôte souhaitant communiquer via UDP, connectez-vous au module via TCP, passez en mode commande et réglez l'adresse en utilisant les commandes "$$$", "set ip host 0.0.0.0", "save", "exit". Sinon, au lieu de 0.0.0.0, vous pouvez entrer l'adresse IP du nouvel hôte: "$$$", "set ip host ###.###.###.###", "exit". Remplacer "###.###.###.###" avec l'adresse IP de l'appareil. De cette façon, vous ne vous tromperz pas de l'adresse IP de l'hôte si plus d'un périphérique communique via UDP en même temps. En outre, en n'utilisant pas "save", l'appairage automatique sera toujours sauvegardé dans la mémoire EEPROM. En outre, vous pouvez envoyer "ip flags 0x##" avant "exit", de cette façon vous pouvez également mettre le bit [6] à 0 (couplage automatique UDP désactivé) temporairement en utilisant la valeur hexadécimale qui a ce bit mis à zéro. L'un des problèmes que le support technique de Microchip a testés pendant l'été 2013 est que vous ne pouvez pas utiliser le RN-171 comme point d'accès pour d'autres RN-171, car ils ont une erreur de microprogramme qui en empêche l'exécution. firmware v4.41, publié en Janvier 2014, il n'y a pas encore de solution ni prévu.

Je ne recommande pas la dernière version du firmware v4.41, car elle ne semble pas fonctionner avec la plupart des routeurs; Cependant, le mode Soft AP fonctionne correctement. D'un autre côté, la version 4.00.1 est beaucoup plus compatible, mais vous devriez faire attention quand vous coupez l'alimentation car elle a un problème de brique potentiellement désastreux si vous coupez l'alimentation lorsque l'écriture flash est en cours - le module peut verrouiller sa mémoire pour toujours .

Je recommande d'enregistrer et d'ouvrir un Microchip ticket qui sera généralement répondu dans les deux jours ouvrables et ils sont assez favorables. Leur cycle de mise à jour du micrologiciel est cependant assez long, et il faut généralement un an ou deux pour une nouvelle mise à jour.

+0

Cependant, j'ai trouvé une meilleure façon de connecter plusieurs clients avec le module. Maintenant, j'utilise le protocole TCP mais dans une approche différente. Fondamentalement, je veux envoyer des données à partir d'un smartphone dans mon projet. Ainsi, lorsque l'application doit faire quelque chose avec le module, elle initie une connexion TCP, authentifie la connexion avec le mot de passe configuré dans le module, envoie et reçoit les données, puis ferme immédiatement la connexion. Comme l'entrée de l'utilisateur est prise avant la création de la connexion, tout ce processus prend environ 50-60ms. Ressentez-vous que c'est une solution stable pour gérer ce problème. – kayveesin

+0

C'est en effet une solution viable si vous n'avez pas à envoyer et recevoir des données de vos appareils en même temps. Si votre application peut gérer les retards de données dans le canal, il est parfaitement raisonnable que d'autres périphériques effectuent des tentatives de connexion (au cas où des collisions de demande de connexion se produisent) jusqu'à ce que tous les périphériques aient envoyé les données requises. Je n'ai pas encore eu de problèmes avec de nombreuses connexions consécutives non simultanées. – wolf9000

Questions connexes