LAP

Aus LaborWiki
Wechseln zu: Navigation, Suche

Labor Automation Protocol[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]

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.

Die ersten 11 bits
SID10 SID9 SID8 SID7 SID6 SID5 SID4 SID3 SID2 SID1 SID0
CH8 CH7 CH6 CH5 CH4 CH3 CH2 CH1 CH0 SC1 SC0
Die hinteren 18 bits
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]

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]

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]

Name[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.