Question:
Aide à l'identification des appareils dans une chaîne
Chris Gammell
2010-10-14 07:46:03 UTC
view on stackexchange narkive permalink

Je travaille donc sur un nouveau projet dans lequel j'essaie d'identifier des périphériques sur un "réseau" à protocole fermé. J'essaie de déterminer le nombre d'appareils disponibles et les identifiants uniques de chaque appareil. J'aurai probablement un eprom ou quelque chose de similaire pour stocker l'identifiant unique. La question que j'aurais pour le forum serait: une guirlande est-elle le meilleur moyen d'identifier les appareils? (comme indiqué ci-dessous)

alt text

Je pensais que je pourrais également essayer d'acheminer des lignes de contrôle individuelles vers les appareils, mais je ne saurai pas nécessairement combien il y a au total d'appareils Là. Je pourra relier l’équipement final à une ligne de retour (physiquement à l’aide d’un cavalier et identifié ici par le point bleu).

Encore une fois, ma question est la suivante: y a-t-il une meilleure façon de faire cela?

Merci!

Il peut être utile d'en savoir plus sur les périphériques 1 2 et 3. S'ils ont déjà un protocole défini, vous devrez les connecter exactement comme le périphérique le souhaite.
Salut chris. De combien d'appareils parle-t-on? Je sais que vous dites que vous ne connaîtrez pas le total, mais parlons-nous de 10, 1000 ou plus? De plus, dans quel genre d'environnement serez-vous - des utilisateurs éclairés, ou pas tellement? Quelle est l'importance de la robustesse?
quel est le PHY? I2C? SPI? autre chose?
Le phy n'a pas encore été déterminé, c'est encore au début du processus. Il va au maximum à 4 à la fois en ce moment, je pense, mais pourrait être plus à l'avenir. L'autre chose est qu'il est possible que les 4 appareils soient différents à chaque fois. Ce seront essentiellement des appareils échangeables.
Six réponses:
#1
+4
Toby Jaffey
2010-10-14 13:31:40 UTC
view on stackexchange narkive permalink

Il serait utile de savoir quelle couche phy vous utilisez. Mais voici quelques informations générales:

Si vous utilisez I2C, votre bus devrait ressembler à quelque chose comme ceci:

(extrait de societyofrobots.com)

Lors de l'exécution, vous pouvez détecter les adresses I2C en scannant le bus en envoyant une condition START à chaque adresse et en recherchant un ACK.

Si vous utilisez SPI , vous aurez besoin d'une ligne de sélection de puce par appareil. Si vous manquez de broches, vous pouvez utiliser une sorte de multiplexeur. Vous pourrez peut-être scanner le bus en affirmant tour à tour chaque ligne de sélection de puce et en essayant de communiquer.

http://kkamagui.springnote.com/pages/422905/attachments/177111

Je pense que je m'orienterais vers la solution SPI en raison de la nature des appareils sur lesquels je travaille. Je serai capable de câbler jusqu'à un certain point, mais ce sera inconnu après ce point (les appareils changeront de temps en temps)
Une autre chose à laquelle j'ai pensé. Puisque j'essaie de rendre les appareils interchangeables, j'espérais aussi qu'ils seraient le même tableau (la disposition avec seulement l'ID unique programmé étant différent). C'est un autre problème car les lignes CS ne fonctionneraient pas nécessairement uniquement sur l'un des appareils. Je suis vraiment inquiet de me mettre en place pour un "réseau auto-organisé" qui est waaaay plus compliqué que je ne le souhaite.
Si vous avez un MCU dans chaque appareil, vous pourrez peut-être vous passer des sélections de puce. Tous les appareils surveillent les lignes de données + d'horloge et ne répondent que lorsqu'ils sont adressés (par exemple, premier octet reçu). Chaque appareil devrait avoir une adresse unique. Si vous essayez de réduire les fils (au détriment de la vitesse), jetez un œil au bus microlan à 1 fil de Maxim.
#2
+3
AdamShiemke
2010-10-14 19:47:00 UTC
view on stackexchange narkive permalink

Vous voudrez peut-être regarder LIN ( http://en.wikipedia.org/wiki/Local_Interconnect_Network) qui peut utiliser quelque chose appelé SNPD pour détecter et attribuer des adresses aux nœuds au moment de l'exécution. Il existe trois méthodes présentées dans l'article de Wikipédia, et toutes fonctionneraient, mais certaines sont apparemment brevetées, alors soyez prudent.

Le protocole LIN lui-même est un protocole basé sur SCI assez simple avec quelques fonctionnalités de fiabilité supplémentaires, mais les techniques SNPD pourraient être appliquées à tout transfert de données série.

#3
+2
Robert
2010-10-14 17:58:36 UTC
view on stackexchange narkive permalink

Envoyer une commande au premier appareil pour envoyer son adresse, suivi d'un compteur (zéro pour démarrer) Chaque appareil lira la commande et sortira la commande.

Ensuite, lira le compteur, incrémente et envoyez le compteur.

Ensuite, lisez toutes les adresses précédentes et envoyez-les.

Ensuite, envoyez son adresse.

À mesure que chaque appareil reçoit la commande, il ajoute son adresse à la réponse.

Si les appareils sont numérotés 1, 2, 3, la réponse résultante sera:

  DISCOVER CMDCOUNT = 3ADDRESS 1ADDRESS 2ADDRESS 3  
#4
+2
Tim Williscroft
2010-10-15 02:48:21 UTC
view on stackexchange narkive permalink

Si vous n'avez pas à parler trop vite, regardez Dallas One-Wire pour votre bus.

1 fil (et une mise à la terre implicite)

adressable, 250 off par bus, routables, et les périphériques d'interface sont très bon marché.

Vraiment utile en tant que bus de gestion de système car il est si extensible. et la découverte de périphériques, puis quelque chose d'autre (comme) jindi pour les communications.

Je recommande de tout cœur quelque chose avec un méta-protocole afin que vous puissiez changer les choses plus tard.

#5
+2
Mark
2010-10-15 06:19:50 UTC
view on stackexchange narkive permalink

Vous ne pouvez vraiment pas faire de choix ici sans déterminer la couche PHY, mais quelques idées:

Si le système est vraiment connecté en guirlande comme dessiné, mettez chaque appareil dans l'ordre. Programme d'usine à "l'adresse de diffusion" si le PHY en a une (comme I2C). Ensuite, demandez à chaque appareil de choisir une adresse et d'envoyer cette adresse au périphérique suivant au fur et à mesure qu'il se déplace le long de la chaîne.

Si vous utilisez des UID 8 bits, vous obtenez des points bonus, du moins de ma part, si vous épelez quelque chose de comique en ASCII avec les adresses:

Maître: "Hé appareil 1, choisissez une adresse «Appareil 1:« M », hé appareil 2 choisissez une adresse Appareil 2:« y »Appareil 3:« B »Appareil 4:« o »Appareil 5:« s »Appareil 6:« s »Appareil 7: Appareil« S » 8: "u" Device 9: "c" Device 10: "k" Device 11: "s"

Alternativement, si votre conception a un nombre fixe de périphériques: j'ai eu une conception qui utilisait un fond de panier qui a permis de brancher jusqu'à 4 cartes. Ce que j'ai fini par faire quoi placer un expanseur GPIO basé sur I2C sur le fond de panier (en fait, c'était un IC de contrôle de ventilateur dont j'avais besoin de toute façon, j'en ai choisi un avec une interface I2C et quelques GPIO dessus ).

J'ai acheminé un GPIO à travers chaque connecteur de bord de carte vers la broche de réinitialisation du DSP sur chaque carte enfichable. Tous les DSP ont été programmés en usine sur 1 adresse. Le contrôleur système a sorti les emplacements de la réinitialisation 1 à la fois, une commande I2C a été envoyée, si quelque chose ACKé, il a été supposé que l'emplacement était rempli et une commande a été envoyée pour qu'il change son adresse I2C en un UID pour cet emplacement. Cela a été fait pour chaque slot avec un délai de réponse raisonnable.

S'il s'agit d'un bus partagé capable de lancer des transferts esclaves, c'est-à-dire multi-maître. Il suffit que le périphérique esclave confirme le contrôle du bus et demande au maître une adresse, le maître lui donne simplement la prochaine adresse en ligne, pensez DHCP. Mêmes points bonus que ci-dessus.

Si le PHY est un seul maître et que vous avez un nombre complètement inconnu de périphériques ... connectez-vous en guirlande à un GPIO et utilisez-le pour contrôler s'ils répondent à une adresse programmée en usine? Ensuite, lorsque l'esclave obtient son adresse, il désaffirme le périphérique suivant en ligne? De cette façon, vous n'avez besoin que de 2 broches GPIO par appareil et 1 pour le maître et vous pouvez monter les appareils un à la fois. Doit fonctionner je pense.

Quoi qu'il en soit, honnêtement, toutes les spéculations jusqu'à ce que vous choisissiez un PHY et que vous puissiez nous en dire plus sur la façon dont le système global est connecté.

#6
+2
davidcary
2011-02-22 09:19:34 UTC
view on stackexchange narkive permalink

Les moyens pour le processeur principal de découvrir combien de périphériques y sont connectés - et l'ID de chacun - incluent:

  • les systèmes en guirlande ne nécessitent pas d'adresse unique "- chaque périphérique est implicitement adressé par sa distance (nombre de sauts) de la CPU principale. Une fois que vous avez compris qu'il y a 7 périphériques, vous pouvez les adresser chacun à l'emplacement 1, 2, 3, 4, 5, 6 et 7.
    • Systèmes avec une ligne d'horloge globale, comme la marguerite- SPI chaîné: le processeur principal se décale selon un modèle unique suivi de nombreux bits "0", et compte le nombre d'horloges qu'il faut avant que ce modèle ne retourne au processeur principal: s'il a synchronisé N bits d'horloge et que chaque périphérique a un registre de bits, alors il doit y avoir N / 16 périphériques sur la chaîne.
    • Systèmes sans ligne d'horloge globale, uniquement des bus locaux, tels que les réseaux token-ring: chaque message du CPU principal à un périphérique comprend une adresse de destination. Lorsqu'un appareil reçoit un message adressé à "1", il opère sur ce message. Sinon, il transmet le message au périphérique suivant sans le modifier - sauf qu'il décrémente l'adresse. Lorsque la CPU principale envoie un message avec une adresse de destination incroyablement grande, aucun des périphériques ne le revendique, et la CPU principale peut dire combien de périphériques sont sur le bus par combien de fois cette adresse a été décrémentée tout autour de la boucle (le nombre de sauts).
  • les systèmes de sélection de périphérique ne nécessitent pas une "adresse" unique - chaque périphérique est implicitement adressé par lequel des périphériques sélectionne les lignes dans CPU l'activer. Pour chaque ligne de sélection de périphérique, activez la ligne de sélection de périphérique et envoyez un simple "qui êtes-vous?" message, et voyez s'il y a un périphérique à la fin de cette ligne pour donner une réponse.
  • systèmes de bus qui n'ont que des signaux "globaux" ("communs") où chaque périphérique a un unique câblé adresse.
    • Certains systèmes, tels que CANbus et certains protocoles RFID, permettent au processeur principal de détecter qu'une centaine d'appareils y sont connectés et l'ID unique de chacun, après seulement quelques centaines de commandes, même s'il y en a des millions des adresses possibles - protocoles de singularisation. Cela permet à chaque périphérique d'avoir une adresse unique, même lorsque des millions d'entre eux ont été fabriqués, et permet toujours au processeur principal de découvrir rapidement les quelques périphériques qui lui parlent réellement.
    • Certains protocoles, comme I2C, ne supporte pas un protocole de singulation rapide, mais autorise le scan: le CPU principal peut envoyer un "Bonjour, tu m'entends?" à toutes les adresses possibles. (Cela peut prendre beaucoup de temps s'il y a des millions d'adresses possibles.)
  • systèmes de bus où chaque appareil se voit (éventuellement) attribuer une adresse, qui peut être différente chacun l'heure à laquelle vous l'allumez: comme DHCP. C'est probablement une complexité inutile pour votre application.

Beaucoup de gens affirment que "Si vous utilisez SPI, vous aurez besoin d'une ligne de sélection de puce par appareil." Si c'est vrai, alors quel est le bon nom pour cet autre protocole qui ne nécessite pas une ligne de sélection de puce par périphérique, seulement 4 broches fixes sur le processeur principal même avec des dizaines de périphériques - c'est-à-dire le protocole utilisé par appareils que Wikipédia appelle "SPI en guirlande"?

Plutôt que de réinventer une autre roue carrée, vous pouvez consulter la liste des systèmes embarqués courants, vous évitez ainsi la plupart des pièges qui piquent souvent les personnes qui conçoivent des protocoles à partir de zéro.

Le terme «SPI» en est venu à englober à peu près n'importe quelle interface série cadencée où un seul appareil maître a le contrôle exclusif de l'horloge, et où l'état d'une ligne de données n'est pas pertinent sauf sur un front d'horloge particulier (pour certains appareils, le front pertinent est en hausse; pour les autres, en baisse). La plupart des dispositifs appelés SPI nécessitent des sélections de puces individuelles, mais il existe de nombreux dispositifs qui peuvent être adaptés pour communiquer avec un bus SPI (par exemple, des puces 74HC595 ou 74HC165) qui peuvent être connectés en série. Je considérerais une chaîne de six 74HC595 avec un signal de verrouillage commun comme un seul périphérique SPI-ish.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...