notes-ing2/bus/02_multiplexage.md
2024-02-29 10:38:14 +01:00

5.7 KiB
Raw Blame History

multiplexage

pourquoi ?

  • Pour rendre la quantité de connection linéaire par rapport au nombre de périphérique.
  • Rendre le système extensible.
  • Acheminer l'information le plus rapidement possible.

Principes

  • intégration : retrouper plusieurs fonctions dans un seul boitier plus intelligent

    • gestion moteur : injection, allumage, dépollution, refroidissement
  • spécialiser les boitiers

  • passer par un réseau

  • transmettre les données

  • structurer les trames

  • synchronisation

  • arbitrage

Modèle général

                             +-- Boitier intelligent --+
 +----------+ +----------+   | +---------------------+ |   +----------+ +-------------+
 | capteurs |-| étage d' |->-| | unité de traitement | |->-| étage de |-| actionneurs |
 +----------+ | entrée   |   | |  microprocesseur    | |   |  sortie  | +-------------+
              +----------+   | +---------------------+ |   +----------+
                             |            |            |
                             |    +--------------+     |
                             |    | interface de |     |
                             |    | multiplexage |     |
                             |    +--------------+     |
                             +------------|------------+
                                          |
                  ---------------------- bus -----------------------

Tramme

+----+---------+
| id | données |
+----+---------+

Architecture

Maître-esclave

+--------+ +---------+ +---------+ +---------+
| maitre | | esclave | | esclave | | esclave |
+--------+ +---------+ +---------+ +---------+
     |          |           |           |
-----+----------+-----------+-----------+-----

Multi-Maître

+----------+ +----------+ +----------+ +----------+ 
| services | | services | | services | | services | 
+----------+ +----------+ +----------+ +----------+ 
| maitre   | | maitre   | | maitre   | | maitre   |
+----------+ +----------+ +----------+ +----------+ 
     |            |            |             |
-----+------------+------------+-------------+-----

Protocole de communication

Note : Dans notre modèle, la seule opération sur le milieu (cable/bus) est l'interruption du signal actuel partagé. i.e. écrire 0 sur un signal qui est par défaut à 1.

Arbitrage

L'arbitrage CSMA se fait en organisant des temps pour que les composants puissent déclarer vouloir envoyer un message. Ils procèdent en écrivant leur ID sur le bus :

  • Les ID se retrouvent confondus par et logique sur les bits.
  • Un des composants détecte avoir envoyé l'ID le plus faible car l'ID résultant est le sien.
  • Ce composant a la priorité pour écrire le message suivant.
          .     .          .
Noeud x : #_____##########________
          .     .          .
Noeud y : #####___________________
          .     .          .
Noeud z : #_____#__________######_
          .     .          .
Bus :     _####__#########__#####_
----------------------------------
          ^\    ^\         ^\_ bus disponible, début message z, id de moindre priorité
            \     \___________ bus disponible, début de message x, id_x < id_z
             \________________ bus disponible, début de message y, id_y < id_x

Forme d'une trame

+-------+--------+-----------+-----+
| ZEROs | Header | Data      | UNs |
+-------+--------+-----------+-----+
  |       |        |           \_ mot entier de 1
  |       |        \_____________ donnée spécialisée du message
  |       \______________________ entête standard du message
  \______________________________ mot entier de 0

Note : Le format du Header et de la Data doit prendre en compte qu'il ne peut pas contenir un mot entier de 1 ou bien de 0.

Arbitrage des bits

Lors d'une mise en commun des bits de messages attendant d'être envoyé se fait par fusion des bits sur le bus :

Id message A : .....01001.......
Id message B : .....010001001000
Id message C : .....0100010011..
sur le bus   : 11111010001001000
--------------------------------
               ^^^^^\^^^^\    ^^\_ padding de ZEROs
                     \    \_______ ET logique des IDs
                      \___________ mot UNs du dernier message / maintient d'un état IDLE

Synchronisation

Le signial de synchronisation peut être porté par le signal de donnée dans le cas de certains codages.

  • ex : NRZ / Manchester

Topologies

Les topologies usuelles sont appliquables.

  • étoile
  • anneau
  • maillé
  • bus : idéal
    • moins couteux
    • extensible

Exemple : Trames CAN

       +---+----+---+---+---+---+------+--------+---+---+---+---+---+---
champ  |SOF| ID |RTR|IDE| r |DLC| DATA |checksum|DEL|ACK|DEL|EOF|ITM| /
       +---+----+---+---+---+---+------+--------+---+---+---+---+---+---
taile  | 1 | 11 | 1 | 1 | 1 | 4 | 0~64 |   15   | 1 | 1 | 1 | 7 | 3 | /
       +---+----+---+---+---+---+------+--------+---+---+---+---+---+---
nature |arbitration | control   | data | check      | aquit.| protocole
  • DLC : Description des données utiles.
  • checksum / CRC : Code de vérification d'un message.
  • ACK : Aquitement d'un message.

Synchronisation STUFF

Un bit est envoyé tout les N bits pour éviter des mots interdits (exemple : 11 × 0 / 11 × 1 ). Cette responsabilité est celle de l'émetteur et du récepteur.

STUFF-ing à 4 bits :

donnée actuelle :          0100.0000.0111
donnée écrite sur le bus : 01001000010001
donnée dé-stuffé :         0100.0000.0111
                               ^\___^\____ bits STUFF-é

Selon le protocol, il est également possible d'avoir des bits de 'stuffing' alternant.

Note : Le 'stuffing' peut servir de synchronisation d'horloge car il assure une alternance dans le signal.