Benutzer-Werkzeuge

Webseiten-Werkzeuge


lasertag:module:modulebus

Modulbus

Der Modulbus setzt auf die I2C Schnittstelle auf.

Adressen

Jedes Modul bekommt eine feste Adresse.

NameAdresse
Broadcast0
Mainboard10
UI-Modul14

Vorgehen

Der Master fragt Reihum nach Änderungen auf allen Slaves, sind Daten vorhanden, werden diese anschließend abgefragt. Die abgefragten Daten werde direkt wieder gebroadcastet.

  1. Liste aller Adressen
  2. Jeden Adresse nach neuen Daten fragen
  3. Antwort mit Anzahl Bytes neuer Daten
  4. bei > 0
    1. Daten abfragen

Neue Idee:

  1. Liste aller Adressen
  2. begin Tansmission
  3. liest erste zwei Bytes
  4. erkennt dann länge
  5. liest dann folgende Daten
  6. dann wieder zwei Byte, bis NO_DATA Paket
TWAR = (MY_ADDRESS << 1) | 1;  // enable broadcasts to be received

Pakete

2Byte Datentyp, X-Byte Daten

  • NO_DATA - 1
  • BUTTON_PRESSED - 2

Hardware

Mini Module Connectors von Würth oder MicroMaTch von TE. 2×2 mit GND, VCC, SDA, SCL

ALT

Physikalisch

Es wird ein 2×3 Wannenstecker vorgesehen, der folgende Belegung besitzt:

Eine sternförmige Verschaltung ist unzulässig, lediglich Daisy-Chaining ist erlaubt. Dazu muss jedes Modul einen Eingangskonnektor sowie einen Ausgangskonnektor besitzten. Diese müssen immer mit „IN“ bzw. „OUT“ gekennzeichnet werden (Bestückungsdruck oder Aufkleber).

Elektrisch

Es sind alle Signale auf 3,3V Pegel. SDA und SCL sind entsprechned I2C definiert. SS (slave select) ist low-active und aktiviert das angeschlossene Modul. Die Signale GND, +3V3, +5V, SDA, SCL der Eingangs- bzw. Ausgangsseite sind unbedingt miteinander zu verbinden. Das Signal SS der Ausgangsseite muss vom aktuellen Controller aus geschaltet werden können, und darf nicht einfach durchgereicht werden.

Protokoll

Phase 1: Adress Alokation

Zu Beginn (nach Reset bzw. PowerOn) haben alle Module keine Adresse. Dies bedeuted, dass alle Module lediglich auf einen Broadcast hören - allerdings nur dann wenn auch SS active ist.

Der Modulebuscontroller schaltet nun den SS des ersten Modules in der Kette auf low-active und versendet ein Ping-Orphan-Paket auf die Broadcast-Adresse. Sollte die Antwort positiv sein, sendet der Controller anschließend ein Set-Adress-Paket mit einer noch unbenutzen Adresse an den Broadcast.

Sobald nun ein Modul eine Addresse erhalten hat wird das SS des Eingangssteckers auf den Ausgangstecker durchgereicht, womit das nachfolgende Modul erreichbar wird. Somit kann der BusController das oben beschriebene Verfahren erneut durchlaufen. Er bricht ab, sobald das Ping-Orphan-Paket eine negative Antwort liefert.

Phase 2: Discovery

Zu diesem Zeitpunkt haben alle Module eine gültige Adresse, und der Buscontroller eine Liste aller besetzen Adressen. Er fragt nun mittels Get-Module-Info-Paket alle relevanten Informationen der Module nacheinander ab und speichert diese bei sich zur weiteren Verwendung.

Phase 3: Usage

Ab diesem Zeitpunkt ist der Bus vollständig initialisiert und funktionsbereit.

Paketaufbau

Jedes Paket besteht aus dem dem Pakettyp und einer beliebigen Anzahl an Nutzdaten.

Es existieren folgende Pakete:

Paketname Pakettyp Nutzdaten Bemerkung
Ping 0x01 Keine - Rückmeldung über ACK
Ping-Orphan 0x02 Keine - Rückmeldung über ACK Es antworten nur Module ohne Adresse
Set-Adress 0x03 1 Byte: Zu setztende Adresse
Get-Module-Info 0x04 beliebig *Siehe unten
Get-Sensor 0x05 beliebig *Siehe unten
Set-Actuator 0x06 beliebig *Siehe unten

Zu den Nutzdaten des Get-Module-Info:

Byte 1
Modultyp

Es existieren folgende Modultypen:

IR-Sender 0x01
IR-Empfänger 0x02

Die Nutzdaten für die Get-Sensor bzw. Set-Actuator-Pakte müssen im Folgenden Modultypenabhängig noch definiert werden.

lasertag/module/modulebus.txt · Zuletzt geändert: 2017/08/12 16:22 von dirk