LAP
Labor Automation Protocol[Bearbeiten | Quelltext bearbeiten]
Hier wollen wir uns das Protokoll auf dem CAN Bus überlegen, was uns zur Automatisierung des Labors dienen soll. Nachdem das alte Protokoll(nenen wir es mal V1.0) nichtmehr so richtig nach unseren Vorstellungen ist, wollen wir uns nun ein neues überlegen. Es darf total inkompatibel zum Alten sein, wir erstzen halt alle Firmwares mit neuen. Jeder darf hier mit Vorschlägen mitarbeiten, um unser neues Protokoll zu entwickeln. Dazu könnte auch das Diskussions-Feature des Wikis ganz sinnvoll sein.
Struktur des CAN-Identifiers[Bearbeiten | Quelltext bearbeiten]
Bei V1.0 hat sich das Feature der source- und destination Ports als ziemlich unnützlich herausgestellt. Beide wurde eigentlich immer auf den gleichen Wert gesetzt, und sozusagen als Dienstkennung gebraucht. Desswegen sollten wir bei V2.0 diese Bits sofort als Dienstkennung, bzw. Kanal-Kennung Deklarieren. Dabei könnte es Sinn machen, eine Trennung in Channel und Subchannel vorzunhemen. Jeder Channel kann dann 4 Subchannel haben, die man für jeden Dienst nach Belieben belegen kann. z.B. Subchannel 0-> Signaling, Subchannel 1-> Data. Dann kann man die vollen 8 Datenbytes eines jeden Paketes auch für Daten benutzen.
Eine Source-Addresse brauchen wir, um sicherzustellen, dass jede Nachricht auf dem Bus eindeutig ist(es darf bei CAN niemals von 2 Geräten aus mit dem gleichen Identifier gesendet werden). Ausserdem ist das für die Identifizierung der Nachrichten sinnvoll. 8 Bit sollte für die Addressen genug sein, weil an einem CAN-Bus elektrisch sowieso nur max. 127 nodes hängen dürfen.
Eine Destination-Addresse dürfte auch für die allermeissten Dienste Sinn machen. Die kann man jedoch optional halten - jeder Dienst hat schliesslich über seine Channel-Kennung sozusagen einen eigenen Address-space.
Hier mal die Struktur für den Identifier:
- CH = 9 bit(512) Channel
- SC = 2 bit(4) Subchannel
- SA = 8 bit(256) Source Address
- DA = 8 bit(256) Destination Address
2 bit sind übrig. RFU?
Die Trennung in 11 und 18 bits wird hier vorgenommen, weil vom CAN Protokoll her diese beiden Bereiche unterschieden werden. Ansonsten hat die Trennung keine weitere Bedeutung. Die Nachrichten werden über den gesammten 29-Bit-Identifier priorisiert. Das vorderste Bit hat die höchste priorität, eine 0 gewinnt gegen eine 1. Die Nachricht mit dem niedrigsten Identifier hat also die höchste Priorität.
| SID10 | SID9 | SID8 | SID7 | SID6 | SID5 | SID4 | SID3 | SID2 | SID1 | SID0 |
| CH8 | CH7 | CH6 | CH5 | CH4 | CH3 | CH2 | CH1 | CH0 | SC1 | SC0 |
| EID17 | EID16 | EID15 | EID14 | EID13 | EID12 | EID11 | EID10 | EID9 | EID8 | EID7 | EID6 | EID5 | EID4 | EID3 | EID2 | EID1 | EID0 |
| RFU | RFU | SA7 | SA6 | SA5 | SA4 | SA3 | SA2 | SA1 | SA0 | DA7 | DA6 | DA5 | DA4 | DA3 | DA2 | DA1 | DA0 |
Diese Zuordnung hat auch noch den Vorteil, dass sie wenigstens ein bisschen kompatibel mit LAP V1.0 ist. Die Addressen liegen an der gleichen Stelle, und die Channels ersetzen die Ports. Wenn wir erstmal bestimmte Channel bei der Vergabe aussparen, dann können V1.0 und V2.0 temporär gemeinsam auf einem Bus existieren. Wenn wir einen guten Grund dafür finden, können wir die Kompatibilität aber auch aufgeben.
Bit-Anordnung (LAP 1.0)[Bearbeiten | Quelltext bearbeiten]
| Die ersten 11 Bits | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Identifier-Bit | SID10 | SID9 | SID8 | SID7 | SID6 | SID5 | SID4 | SID3 | SID2 | SID1 | SID0 |
| LAP-Bit | SP5 | SP4 | SP3 | SP2 | SP1 | SP0 | DP5 | DP4 | 0 | DP3 | DP2 |
| Die hinteren 18 Bits | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| Identifier-Bit | EID17 | EID16 | EID15 | EID14 | EID13 | EID12 | EID11 | EID10 | EID9 |
| LAP-Bit | DP1 | DP0 | SA7 | SA6 | SA5 | SA4 | SA3 | SA2 | SA1 |
| Identifier-Bit | EID8 | EID7 | EID6 | EID5 | EID4 | EID3 | EID2 | EID1 | EID0 |
| LAP-Bit | SA0 | DA7 | DA6 | DA5 | DA4 | DA3 | DA2 | DA1 | DA0 |
Channels[Bearbeiten | Quelltext bearbeiten]
Jeder Dienst bekommt einen eigenen Channel. Da die Nachrichten alle über den Channel priorisiert werden, entscheidet der Cahnnel auch über die Priorität des Dienstes. Dabei sollten wir also bei der Vergabe der Channelnummern nachdenken. Auf jedem Channel darf ein anderes Unterprotokoll gesprochen werden. Wir können uns also bei der Entwicklung jedes Dienstes was neues einfallen lassen, und sind nicht zu sehr eingeschränkt.
Dienste[Bearbeiten | Quelltext bearbeiten]
Name[Bearbeiten | Quelltext bearbeiten]
Dieser Dienst kann Namen für die Verschiedenen Geräte und deren Funktionen liefern. So kann ein Controlpannel z.B. den Namen für Channel16:Device5.Funktion3 nachfragen, und erhällt "Rauchmelder Waschküche". Auch eine Nachfrage in Gegenrichtung, also Name zu Addresse sollte möglich sein. Dieser Dienst soll auf roulette laufen, und es ermöglichen, dass die Microcontroller für die eigentlichen Dienste sich nicht viele Strings speichern müssen, und man trotzdem den Komfort hat, Namen für die Geräte abfragen zu können.