Bonne pratique pour réunion de signaux en SPI

[scaypapa]

Bonjour, je cherche à réaliser une interface permettant de gérer plusieurs signaux arrivant depuis plusieurs modules à un microcontrôleur.
En gros j'ai plusieurs modules qui lisent des signaux de même type et les envoient à un dernier module chargé de les réunir et les traiter.
Je pensais utiliser les communications en SPI, mais je ne vois pas bien comment configurer mes liaisons.
Les signaux peuvent arriver à n'importe quel moment et doivent être traités en temps réel.

Si le module chargé de réunir les signaux est configuré en maître, il est responsable d'engager une communication avec les autres. Or les signaux étant envoyés depuis les autres modules quand ils ont été traités, ce n'est pas mon module maître qui sait quand un signal va être envoyé.
Première solution à laquelle j'ai pensée : configurer le module chargé de réunir les signaux en esclave. Mais alors, je ne dispose que de 2 modules SPI sur le µC et peut passer à 4 si 2 liaisons sont assurées en Usart. Mais ça ne me parait pas terrible.
Seconde solution : configurer le module principal en maître et dans la boucle principale, demander l'un après l'autre à chaque module s'il a un signal à transmettre. Ca me parait consommer beaucoup de ressources pour pas grand chose et enlève la possibilité de mise en veille d'un module qui n'aurait rien à transmettre pendant un certain temps.

Dernière solution, qui me parait la plus viable, mais qui consomme beaucoup plus de pins : configurer le module chargé de réunir les signaux en maître et ajouter une liaison supplémentaire pour chaque module permettant à chacun d'indiquer au module principal qu'il a une info à lui envoyer (voir shéma ci-dessous).
Chaque module enregistrerait dans un buffer circulaire les données à envoyer. Quand un signal prêt à être transmis, il enverrait un 1 (ou un 0) sur une pin d'interruption du maître (qui suivant la pin utilisée saura qui lui parle). Le maître pourrait alors engager une communication SPI avec ce même module en passant le SS correspondant à Low et en envoyant une première commande demandant à l'esclave de transmettre son signal. Un octet de fin de message signalerait au maître que la transmission est terminée. Le SS pourrait alors repasser à High. Le signal reçu serait lui aussi enregistré dans un buffer circulaire pour pouvoir traiter les signaux de tous les esclaves "en même temps" par la suite.


Est-ce que je suis sur la bonne voie ou est-ce qu'il y a une pratique qui permettrait de faire la même chose plus simplement ?
En l'occurrence, j'utilise 3 pins pour le SPI + 2 pins par esclave, ce qui me semble beaucoup. Mais je ne vois pas comment faire autrement.

Si vous avez des avis et conseils, si je suis complètement à côté de la plaque, je suis tout ouïe. Je suis toujours dans la découverte des µC, et il est possible (voire probable) que je n'aie pas du tout compris le principe des communications entre différents modules...

Merci et bonne journée.
-----

[invitee05a3fcc]

Les signaux peuvent arriver à n'importe quel moment et doivent être traités en temps réel.

Ca veut rien dire !
Ton maitre ne peut traiter qu'une liaison à la fois. Donc temps réel , ça veut dire que la succession des traitements fait que tu ne perds pas de données et que c'est "assez rapide" pour que ça semble instantané
Hors tu ne parles pas de combien d'octets tu dois gérer.

La solution bestiale, c'est ton schéma. Avec une petite amélioration, tu mets toutes tes interruptions ensembles et tu viens lire un code (2 bits) sur des entrées pour savoir qui veux causer parmi les quatre.

Par contre, le dialogue en SPI entre le maitre et les quatre esclaves, on pourrait le remplacer par une liaison asynchrone aux normes RS485 qui es un bus multi esclaves

[gcortex]

tu mets toutes tes interruptions ensembles et tu viens lire un code (2 bits) sur des entrées pour savoir qui veux causer parmi les quatre.

Et comment gères tu les collisions ?

[invitee05a3fcc]

Et comment gères tu les collisions ?

http://pdf.datasheetcatalog.com/data.../333876_DS.pdf
Il y a aussi une solution logiciel

[A voir en vidéo sur Futura]

[scaypapa]

D'abord merci beaucoup pour ta réponse.

Ca veut rien dire !
Ton maitre ne peut traiter qu'une liaison à la fois. Donc temps réel , ça veut dire que la succession des traitements fait que tu ne perds pas de données et que c'est "assez rapide" pour que ça semble instantané
Hors tu ne parles pas de combien d'octets tu dois gérer.

Oui, c'est pour ça que dans l'idée, la première interruption permettrait de positionner des drapeaux disant quel(s) esclave(s) veut(veulent) causer.
Chaque message contiendra de 4 à 6 octets : depuis le maître : envoi de la commande - réception du type de message - réception d'un 1 à 3 octets de données suivant le type de message - réception de l'octet de fin de transmission.

Je pensais utiliser les interruptions sur SSPIF pour déterminer si un octet est arrivé et l'enregistrer dans un buffer circulaire (1 buffer par module), ce qui me permettrait de continuer l'exécution de la boucle principale le temps qu'une réception est en cours.
Dans la boucle principale, si un ou plusieurs esclaves veulent causer, je testerai le drapeau SSPSTAT.BF pour savoir si le bus SPI est libre et entamer une communication SPI l'une après l'autre avec chaque esclave concerné (envoi de la commande). La réception de l'octet de fin de transmission permettra de replacer le flag de l'esclave concerné à 0.
Je remplis donc les buffers de chaque esclave octet par octet.

Je regarderai ensuite chaque buffer l'un après l'autre (dans la boucle principale). Si un message complet est arrivé sur l'un d'eux, je le traite, afin ne pas mélanger les données (si un message contient 3 octets par exemple, je dois lire ces 3 octets à la suite et ne pas regarder ce qu'a envoyé un autre esclave au milieu du message).
Les données reçues de chaque modules sont donc bien lues l'une après l'autre. Mais j'ai l'espoir que ce temps soit suffisamment court pour donner l'impression que tous les signaux sont lus en même temps.

J'espère surtout que le temps entre l'envoi de l'interruption par l'esclave et le traitement complet par le maître ne se sentira pas trop. Pour le moment, je travaille à 16MHz, si c'est trop long, je pourrai mettre un quartz plus rapide... Mais le mieux est encore de trouver la solution pour un traitement plus "instantané".

La solution bestiale, c'est ton schéma. Avec une petite amélioration, tu mets toutes tes interruptions ensembles et tu viens lire un code (2 bits) sur des entrées pour savoir qui veux causer parmi les quatre.

Tu veux dire quelque chose comme ça ?

Par contre, le dialogue en SPI entre le maitre et les quatre esclaves, on pourrait le remplacer par une liaison asynchrone aux normes RS485 qui es un bus multi esclaves

Merci, je vais étudier ça aussi alors... J'étais parti sur le SPI car très très débutant et il m'a semblé comprendre que c'était à la fois la plus simple à mettre en œuvre et l'une des plus rapides.

[vincent66]

Bonjour tousse !

Et relier ensemble les sorties de tous les esclaves c'est pas génial, il faudrait utiliser un multiplexeur...

[invitee05a3fcc]

Et relier ensemble les sorties de tous les esclaves c'est pas génial, il faudrait utiliser un multiplexeur...

Un esclave, non validé par son Chip Select, est en trois état

[scaypapa]

http://pdf.datasheetcatalog.com/data.../333876_DS.pdf
Il y a aussi une solution logiciel

Intéressant merci

[invitee05a3fcc]

En alternance avec la solution RS485, tu as aussi la solution de la liaison I²C entre le maitre et les esclaves (plus rapide) si la liaison est carte à carte . Par contre, il faut que le µC des esclaves soit capable de gérer un I²C esclave (je crois que ce n'est pas le cas de tous les µC avec un port I²C)

[scaypapa]

En alternance avec la solution RS485, tu as aussi la solution de la liaison I²C entre le maitre et les esclaves (plus rapide) si la liaison est carte à carte.

Ah bon ? J'ai pu trouver ce message de Risc. Je sais que c'est ancien, mais sur le principe, ça me parait logique qu'on puisse aller plus vite avec 2 fils qu'avec un seul pour la transmission de données...

En tout cas, d'après ce qu'il dit, ça a l'air en effet plus adapté à ce que je veux faire. Il faut que je vois si la vitesse de transmission est assez rapide en pratique... Encore que la consommation est importante dans mon cas.

[invitee05a3fcc]

Faut bien lire ce que j’écris !
Je parle de I²C versus RS485 .......

PS : Si tu répondais aux interrogations ? Combien d'octets par seconde ?

[jiherve]

Bonjour,
Hormis les bus plus complexes CAN/FLEXRAY/ETHERNET seul l'I²C permet en théorie le multi-maitre et la gestion des collisions, en SPI/RS485 il faudra en passer par les interruptions.

JR

[scaypapa]

D'accord merci pour ces précisions.
@ Daudet : Je me demandais en fait si tu voulais dire que l'I2C serait plus rapide que le SPI dans mon utilisation, car plus adapté à une configuration 1 esclave, plusieurs maîtres. Mais apparemment non.

Les signaux sont du MIDI, c'est pour ça que les temps de traitement ne doivent pas décaler visiblement le résultat. Ca fonctionne généralement à 31250bps et les messages qui m'intéressent contiennent entre 2 et 4 octets.
Mais mes différents modules peuvent tourner beaucoup plus vite (jusqu'à 64MHz) je crois. Pour l'instant, je fonctionne à 16MHz.

[invitee05a3fcc]

Je me demandais en fait si tu voulais dire que l'I2C serait plus rapide que le SPI dans mon utilisation, car plus adapté à une configuration 1 esclave, plusieurs maîtres. Mais apparemment non.

Correction : Un maitre et quatre esclaves
C'est l'esclave qui demande au maitre de s'occuper de lui .

les messages qui m'intéressent contiennent entre 2 et 4 octets.

Donc tu en as rien à faire de la vitesse

Mais mes différents modules peuvent tourner beaucoup plus vite (jusqu'à 64MHz) je crois. Pour l'instant, je fonctionne à 16MHz.

Du n'importe quoi !
Ca, c'est la fréquence de l'horloge du CPU.... rien à voir avec les vitesses de transfert

[jiherve]

Re
non en I²C c'est l'initiateur de la transaction (condition START) qui devient le maitre du bus jusqu'au prochain STOP donc ici il y aurait, en I²C, 5 maitres/esclaves possibles. La gestion des collisions n'est pas tout à fait triviale.
JR

[scaypapa]

Correction : Un maitre et quatre esclaves
C'est l'esclave qui demande au maitre de s'occuper de lui.

Oui, c'est ce que je fais pour contourner le fait que le SPI fonctionne en 1 maitre, plusieurs esclaves et que ma situation est plutôt inverse.
C'est les esclaves qui "commandent" au maître de leur demander ce qu'ils ont reçu. Une communication inverse (4 maîtres, 1 esclave) permettrait à chaque module d'envoyer directement ses données. Elles serait gérées au fur et à mesure de leur arrivée par le maître, à condition d'éviter les collisions.
Ou alors je n'ai rien compris du tout.

Donc tu en as rien à faire de la vitesse

ça c'est cool

Ca, c'est la fréquence de l'horloge du CPU.... rien à voir avec les vitesses de transfert

Oui, ça donne une idée du nombre de signaux que pourra gérer le µC. L'horloge du SPI lui-même peut tourner jusqu'à Fosc/4 soit 16MHz, mais les données d'origine traitées par les différents modules sont plutôt de l'ordre de 31,25kbps (125kHz?). En fait, y'a plein de fréquences différentes...

[invitee05a3fcc]

Y a un truc que je ne pige pas . Le bus MIDI, c'est du genre RS485 . Alors pourquoi cette usine à gaz ?

[scaypapa]

Hihi. Cette "usine à gaz", c'est un Merger MIDI. Il y aura probablement un bus MIDI normal qui est du RS485 mais je veux surtout y réunir des modules que je rajoute et "merger" les signaux MIDI proprement vers une seule sortie.
Les différents modules codent du MIDI depuis différentes sources (clavier, carte SD etc) et envoient le résultat au Merger.

[invitee05a3fcc]

Les différents modules codent du MIDI depuis différentes sources (clavier, carte SD etc)

Ben tu fais un interface compatible MIDI pour clavier, carte SD etc
Où est le problème ?

[scaypapa]

Le problème, c'est que je veux réunir tous les signaux reçus sur une sortie unique sans que deux messages MIDI (3-4 octets) ne se mélangent et sans rater un message qui serait bloqué par la réception d'un autre.

En fait, je ne vois pas du tout comment réunir plusieurs signaux qui arrivent en même temps en RS485 à part en utilisant plusieurs bus, mais mon µC qui reçoit tous les signaux ne dispose que de 2 ports Usart.
C'est pour ça que je me dirigeais plutôt vers des communications SPI qui me permettent de réunir tous mes modules sur un seul port SPI du Merger, mais avec un ChipSelect différent et de gérer le tout de manière logicielle.
J'étais parti sur le SPI pour le moment, parce que c'est ce que j'ai le mieux compris pour l'instant

[invitee05a3fcc]

En fait, je ne vois pas du tout comment réunir plusieurs signaux qui arrivent en même temps en RS485

Faut que tu arrêtes de faire une fixation sur le temps réel ...
En informatique , le temps réel, c'est d'être assez rapide pour traiter successivement des données en donnant l'impression à l'utilisateur que c'est simultané .
Y a aucun problème , en RS485, pour acquérir 10 octets sur chaque esclaves et que tu ne vois que du feu !

C'est pour ça que je me dirigeais plutôt vers des communications SPI qui me permettent de réunir tous mes modules sur un seul port SPI du Merger, mais avec un ChipSelect différent

Donc, là aussi, c'est une acquisition successive dans le temps ! comme pour du RS485, de l'I²C .........

[scaypapa]

Mais je suis d'accord. Je veux juste dire qu'avec la solution que j'ai imaginée, je vois comment faire pour placer les messages dans des buffers de réception différents le temps de trouver le temps de les traiter.
L'interruption envoyée par un module permet de savoir qu'une information doit être traitée puis de la traiter au moment opportun.
C'est certainement possible d'utiliser le même principe en RS485, mais je ne vois pas exactement comment : si 2 modules décident d'envoyer des données en même temps et que je n'utilise qu'un seul bus, il va bien falloir justement décaler leur traitement pour obtenir une acquisition successive. Donc prévenir l'un des modules que la réception est retardée... Enfin je ne vois pas comment faire quoi.

[invitee05a3fcc]

L'interruption envoyée par un module permet de savoir qu'une information doit être traitée puis de la traiter au moment opportun.

OK et quelque soit le protocole SPI, I²C ou Uart

si 2 modules décident d'envoyer des données en même temps

Ce n'est pas l'esclave qui décide ! Mais le maitre .
Le maitre, sachant que la carte 2 à des données en stock, demande à la la carte 2 de dialoguer (et les cartes 1 , 3 et 4, elles patientent)

[scaypapa]

D'accord, comme tu disais tout à l'heure quoi : ce n'est pas une bonne idée de chercher à fonctionner avec un esclave et plusieurs maitres qui envoient ce qu'ils ont à envoyer. Il faut obligatoirement un maître et plusieurs esclaves pour les autoriser à envoyer leur infos ou leur demander de patienter.