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

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.

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  

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.

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é.

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.