Répondre à la discussion
Affichage des résultats 1 à 24 sur 24

Bonne pratique pour réunion de signaux en SPI



  1. #1
    scaypapa

    Bonne pratique pour réunion de signaux en SPI


    ------

    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.
    Nom : CommunicationSPI.jpg
Affichages : 38
Taille : 73,6 Ko

    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.

    -----

  2. Publicité
  3. #2
    DAUDET78

    Re : Bonne pratique pour réunion de signaux en SPI

    Citation Envoyé par scaypapa Voir le message
    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
    J'aime pas le Grec

  4. #3
    gcortex

    Re : Bonne pratique pour réunion de signaux en SPI

    Citation Envoyé par DAUDET78 Voir le message
    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 ?

  5. #4
    DAUDET78

    Re : Bonne pratique pour réunion de signaux en SPI

    Citation Envoyé par gcortex Voir le message
    Et comment gères tu les collisions ?
    http://pdf.datasheetcatalog.com/data.../333876_DS.pdf
    Il y a aussi une solution logiciel
    Dernière modification par DAUDET78 ; 15/12/2016 à 11h22.
    J'aime pas le Grec

  6. A voir en vidéo sur Futura
  7. #5
    scaypapa

    Re : Bonne pratique pour réunion de signaux en SPI

    D'abord merci beaucoup pour ta réponse.

    Citation Envoyé par DAUDET78 Voir le message
    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 ?
    Nom : CommunicationSPI.jpg
Affichages : 28
Taille : 38,6 Ko

    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.

  8. #6
    vincent66

    Re : Bonne pratique pour réunion de signaux en SPI

    Bonjour tousse !

    Et relier ensemble les sorties de tous les esclaves c'est pas génial, il faudrait utiliser un multiplexeur...
    Leonardo était ingénieur "sans papier", et moi diplômé juste...technicien...

  9. Publicité
  10. #7
    DAUDET78

    Re : Bonne pratique pour réunion de signaux en SPI

    Citation Envoyé par vincent66 Voir le message
    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
    J'aime pas le Grec

  11. #8
    scaypapa

    Re : Bonne pratique pour réunion de signaux en SPI

    Citation Envoyé par DAUDET78 Voir le message
    Intéressant merci

  12. #9
    DAUDET78

    Re : Bonne pratique pour réunion de signaux en SPI

    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)
    J'aime pas le Grec

  13. #10
    scaypapa

    Re : Bonne pratique pour réunion de signaux en SPI

    Citation Envoyé par DAUDET78 Voir le message
    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.
    Dernière modification par scaypapa ; 15/12/2016 à 13h14.

  14. #11
    DAUDET78

    Re : Bonne pratique pour réunion de signaux en SPI

    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 ?
    Dernière modification par DAUDET78 ; 15/12/2016 à 13h14.
    J'aime pas le Grec

  15. #12
    jiherve

    Re : Bonne pratique pour réunion de signaux en SPI

    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
    l'électronique c'est pas du vaudou!

  16. Publicité
  17. #13
    scaypapa

    Re : Bonne pratique pour réunion de signaux en SPI

    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.
    Dernière modification par scaypapa ; 15/12/2016 à 13h36.

  18. #14
    DAUDET78

    Re : Bonne pratique pour réunion de signaux en SPI

    Citation Envoyé par scaypapa Voir le message
    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
    J'aime pas le Grec

  19. #15
    jiherve

    Re : Bonne pratique pour réunion de signaux en SPI

    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
    l'électronique c'est pas du vaudou!

  20. #16
    scaypapa

    Re : Bonne pratique pour réunion de signaux en SPI

    Citation Envoyé par DAUDET78 Voir le message
    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...
    Dernière modification par scaypapa ; 15/12/2016 à 14h02.

  21. #17
    DAUDET78

    Re : Bonne pratique pour réunion de signaux en SPI

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

  22. #18
    scaypapa

    Re : Bonne pratique pour réunion de signaux en SPI

    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.

  23. Publicité
  24. #19
    DAUDET78

    Re : Bonne pratique pour réunion de signaux en SPI

    Citation Envoyé par scaypapa Voir le message
    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 ?
    J'aime pas le Grec

  25. #20
    scaypapa

    Re : Bonne pratique pour réunion de signaux en SPI

    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
    Dernière modification par scaypapa ; 15/12/2016 à 17h40.

  26. #21
    DAUDET78

    Re : Bonne pratique pour réunion de signaux en SPI

    Citation Envoyé par scaypapa Voir le message
    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 .........
    J'aime pas le Grec

  27. #22
    scaypapa

    Re : Bonne pratique pour réunion de signaux en SPI

    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.

  28. #23
    DAUDET78

    Re : Bonne pratique pour réunion de signaux en SPI

    Citation Envoyé par scaypapa Voir le message
    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)
    J'aime pas le Grec

  29. #24
    scaypapa

    Re : Bonne pratique pour réunion de signaux en SPI

    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.

  30. Publicité

Discussions similaires

  1. CAN pour signaux physiologiques ?
    Par hictou dans le forum Électronique
    Réponses: 1
    Dernier message: 11/03/2015, 16h19
  2. Recréer des signaux aléatoires à partir de vrais signaux
    Par rlefrant dans le forum Mathématiques du supérieur
    Réponses: 4
    Dernier message: 25/10/2012, 16h19
  3. Réponses: 3
    Dernier message: 13/03/2009, 11h16
  4. Question pratique pour une T.C.C
    Par Résilient dans le forum Psychologies (archives)
    Réponses: 6
    Dernier message: 05/10/2007, 23h52
Découvrez nos comparatifs produits sur l'informatique et les technologies.