Aus RN-Wissen.de
Wechseln zu: Navigation, Suche
Balkonkraftwerk Speicher und Wechselrichter Tests und Tutorials

 
(10 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
−
Wenn einmal die Terminalemulation nicht mehr als Partner für den Microcontroller genügt, um Sensorwerte anzuzeigen oder Aktionen auszulösen, tauchen meist bei der Entwicklung der Software (in jedweder Sprache) einige Fragen zu der Kommunikation auf.  
+
In dieser Version werden die Festlegungen getroffen, die für ein kleines Controller/PC Netzwerk erforderlich sind. Beispielprogramme, Templates und Libraries für PC und µC sind teilweise fertig, teilweise in Entstehung, [[Network_Controller/PC#Weblinks/Download|und können dann mit Download geholt werden.]]
  
−
=Ein Netzwerk=
+
*Für µC-Programme liegt der Schwerpunkt vorerst auf Bascom, C-Libraries der Kern-Funktionen sind aber vorgesehen.
−
Für weitere Überlegungen über den Nachrichtenaustausch ist es günstig, ein einfaches Modell als Ausgangspunkt zu nehmen
+
*PC-seitig soll der RN-Server erstmal den Abschluß bilden, die eigentlichen Anwendungen muß ich mangels VB-Erfahrung den Spezialisten überlassen, soweit sie mitspielen wollen. Ich selbst kann nur know-how für MS Visual C++ liefern. 
  
−
[[Bild:Network1.png]]
+
=Das Netzwerk=
 +
<center>[[Bild:Rncomsmall.png]]</center>
 +
==Teilnehmer==
 +
*Ein RNBFRA 1.2 Board, mit
 +
**Powerport
 +
**Outputport
 +
**Expansionport (Input)
 +
**AT90S2313 als Coprozesser, mit dem Servoprogramm "RNSXNET". Das ist eine Abwandlung des RNS-Servers für Netzwerke
 +
*Ein Zusatzboard (Eigenbau) mit einem Atmega16
 +
*Ein PC, der mit COM1 (RS232) mit dem RNBFRA Board verbunden ist
 +
**das PC-Programm "RN_SERVER.EXE, das das Routing übernimmt
 +
**mehrere PC-Anwendungen
  
−
*Auf dem Controller (links) sollen drei Ports verwendet werden, zwei als Output, eins als Input, wobei die Pin-Änderungen entweder durch Polling oder durch Interrupt erkannt werden könnten.
 
−
*Auf dem PC (rechts) soll eine Applikation laufen, die einerseits die Pins der Output-Ports setzen (vielleicht durch Check-boxen) und andererseits den Status des Inputports darstellen kann.
 
  
−
'''Anmerkung:''' mit Hardware kann man nicht reden. Kommunikation ist etwas, was sich grundsätzlich nur zwischen Programmen (-teilen) abspielt. Hardwarefunktionen müssen durch Software-Funktionen repräsentiert werden. D.h. vor jedem PortPin sitzt ein Stück Software, das auf Verlangen dann dieses Pin manipuliert.  
+
=Messages (Nachrichten)=
 +
<center>[[Bild:Rncomformat.png]]</center>
  
−
=Aufgabenstellung=
+
Je nach physikalischem Transportmittel wird die Message verschieden eingepackt.
−
Es geht also darum, wie kann die PC-Applikation eine bestimmte Aktion beim Controller auslösen (diesen oder jenen Pin setzen), beziehungsweise wie kann der Controller dem Modul des PC-Programmes, das zuständig ist, mitteilen, daß sich etwas bei den Pins geändert hat.  
+
Anm. IP: Das Längenwort (16-Bit) beinhaltet die Länge der Daten exklusive Längenwort. D.h, um z.B. vier Byte zu übertragen,  werden insgesamt 6 Byte weggeschickt.  
−
Da alle Nachrichten offensichtlich über den gleichen Draht gehen müssen, wird also eine "Dispatch" Funktion auf beiden Rechnern notwendig sein, die anhand einer Art Adresse in dieser Nachricht immer die angesprochenen Programmteile benachrichtigen kann. Also wurden als Adressen einerseits "Pout/1", "Pout/2" und "Pinp/1" vergeben, auf dem PC einfach "MODA/1",  "MODA/2" und "MODB/1". Und wir nehmen auch einmal an, daß jeder davon weiß, wie sein richtiger Partner auf der anderen Seite heißt.  
+
  
−
=Nachrichten von Programmen an Programme (Messages)=
+
Der Vergleich mit einer Briefsendung ist zulässig, da wie dort gibt es
 +
*Zieladresse (Target)
 +
*Absender    (Source)
 +
*Daten
  
−
[[Bild:Network2.png]]
+
Uns interessiert zuerst einmal nur, wie eine solche Nachricht vom Sender zum Empfänger und ggf. wieder zurückkommt, daher können uns die Daten selbst erst einmal völlig egal sein.  
  
−
Zweckmäßig ist auf jeden Fall eine Aufgabenteilung:
+
'''Details zu Messages:'''
−
*COMM beschränkt sich darauf, Daten variabler Länge sicher über die Leitung zu senden und zu empfangen. Eventuell auch den Medium-Zugriff zu handhaben (wenn es nicht RS232, sondern eine Bus-Verbindung ist).
+
*[[Network Controller/PC Spezifikationen]]
−
*DISPATCH übernimmt die Schnittstelle zu den Module und baut Sende-Pakete mit Ziel- und Absender auf, die es dem Comm-Modul übergibt. Andererseits nimmt es von diesem Empfangspakete entgegen und liefert sie bei den Modulen ab. 
+
−
*Module (Applications) Für sie erfolgt der Zugang aufs Netz transparent, d.h. nicht sichtbar. Sie scheinen über die Dispatch-Schnittstellen "direkt" mit ihren Partnern auf der gleichen oder anderen Maschine zu kommunizieren. 
+
−
 
+
−
Eine besondere Nähe zur OSI-Nomenklatur wurde hier nicht gesucht. Es scheint nicht zweckmäßig, z.B. auf einem Tiny-Controller alle Schichten explizit auszuführen.
+
−
 
+
−
==COMM==
+
−
*Start
+
−
Jede Message braucht einen für alle Teilnehmer erkennbaren und eindeutigen Beginn. Bei I2C ist es die "Start-Bedingung" (fallende Flanke auf SDA, wenn SCL auf High ist) bei SPI gilt die SS-Leitung, bei RS232 Protokollen oft der 9-Bit-Mode benutzt, wobei das 9.Bit als Kennzeichen gilt.
+
−
 
+
−
Der Start ist eigentlich das Wichtigste. Die Empfangsfunktion muß dadurch in der Lage sein, die weiteren Bytes einwandfrei zu lesen. Hier müßten auch Kennzeichen enthalten sein, wenn es mehrere verschiedene Paket-Typen gibt (eventuell auch die Version, das ist gut für eine spätere Weiterentwicklung)
+
−
 
+
−
Der Message-Start unterbricht auch immer eine eventuell laufende Bearbeitung und setzt das Empfangsmodul zurück.
+
−
*Nutzdaten: Das ist das schraffierte Bereich, dessen Inhalt für den Transport keine Rolle spielt.
+
−
*End: Das Ende muß nun wieder für die Transportfunktionen erkennbar sein.
+
−
Es kann auch im Start eine Längenangabe enthalten sein, dadurch ist dann ein explizites Ende-Kennzeichen nicht nötig, die Empfangsroutine muß dann halt mitzählen. Beim I2C-Bus hingegen ist es zum Beispiel so, daß sowohl die Empfangseinrichtung (durch Unterlassung des ACK) als auch der Senders durch eine Stop- oder eine neue Start-Bedingung die Übertragung jederzeit beenden können.
+
−
*Cks (optional): An die Nachricht kann auch eine Kontrollsumme angefügt werden.
+
−
 
+
−
===Transparente (binäre) Messages über UART===
+
−
Der Forderung nach transparenten Daten und dem damit verbundene Verlust der üblichen Steuerzeichen kann man auf verschiedene Weise Rechnung tragen
+
−
*9-Bit Datenformat. Dieses 9.Bit zeigt an, daß die 8 anderen Bits ein Kontrollzeichen darstellen. Bei 0 sind es normale Daten.
+
−
*8-Bit Format, aber Umkodierung. z.B. BASE64, ein gängiges Verfahren für die Übertragen von Binärdaten im Internet und Mail
+
−
*Verwendung der RS232 Steuerleitungen.
+
−
*[[Bascom_UART_Input#Byte-Stuffing|Byte Stuffing]]
+
  
−
Alles davon hat Vor- und Nachteile. Wenn man die Daten umkodiert, hat man den Vorteil, wieder die ASCII-Steuerzeichen verwenden zu können. Der Nachteil: es sind mehr Bytes je Message zu übertragen. Ähnliches gilt für die 9-Bit Variante und auch das Byte-Stuffing. Die RS232 Steuerleitungen brauchen wiederum eine Hardware-Erweiterung.
+
==Adressen==
 +
Für die PC-Anwendungen ist der Aufbau des Controller-Netzwerkes transparent, d.h. die Adressierung erfolgt (normalerweise) mit 16-Bit ID-Codes
  
−
==DISPATCH==
+
==Pfade==
−
*Destination: Das ist die Ziel-Angabe. Nun würde eine Nachricht auch richtig ankommen. Es ist gut, gleich nach dem Start diese Angabe zu machen. Denn dann kann jeder Netzwerkteilnehmer sofort erkennen, ob er angesprochen wird und anderenfalls alles, was da kommt, bis zum nächsten Start ignorieren. Das ist am wenigsten belastend, und wird bei den meisten Netzwerken so gemacht.   
+
Was ist denn in einer einzelnen Pfadangabe darzustellen ?
−
Um aber z.B. eine Bestätigung zurückzusenden, wird wohl auch eine Angabe zur
+
*Typ und Wert
−
*Source erforderlich. Das ist die äquivalente Absender-Adresse als Backlink.
+
**I2C  u. Adresse (7-Bit)
−
Das Wichtigste an einer Adresse ist wohl die Eindeutigkeit. So gesehen ist jede Nummer recht, wenn sie den Teilnehmern bekannt ist. Aber für größere Systeme kann eine Strukturierung günstig sein.
+
**UART  u. ev. eine Nummer 1, 2,..  
−
*Node  bezeichnet einen bestimmten Rechner, also einen PC oder eine Microcontroller  (da gibt es aber unterschiedliche Terminologien).
+
**RS232 das ist eigentlich das Gleiche wie UART oder COM
−
*Class bezeichnet eine Modul- oder GeräteKlasse
+
**IP    u. Socket da müßte man schon mit einem 16-Bit Wort rechnen
−
*Ident ist dann eine spezifische Ausprägung.  
+
**Funktions-ID. Auch da haben wir bisher 16 Bit festgelegt.  
  
−
Beim Absender kann es auch notwendig sein, irgendwelche "Tags" einzufügen, damit bei einer Rückantwort der Absender eine Zuordnung treffen kann. Nicht immer ist ja das Sende-Empfangsverhältnis 1:1.
+
Wenn man da noch die Möglichkeit einer vollständigen IP-Adresse dazunimmt, würden wir auch noch entweder Text ("www.nirwana.com") oder eine IP-Addresse (32-Bit) + Port (16-Bit) unterbringen.  
  
−
*Data: auch auf dieser Ebene sind das reine Nutzdaten.
+
Was heißt denn eigentlich "Typ" ? Nun, im Grunde muß daraus nur eine bestimmte Programm-funktion abgeleitet werden, die dann auch ihren "Wert" bekommen kann. Wie kann man eine sowas identifizieren ?
 +
*Einfach ein Index (die soundsovielte Funktion)
 +
*Eine Direktadresse (wohl nur theoretisch)
 +
*Eine ID (mit Tabelle)
  
 +
Damit wir nicht irgendeinen kleinen Controller als Zwischenstation durch zu lange Messages oder Tabellen überfordern, ist es wohl ratsam, ein wenig Bits zu quetschen (Huffman läßt grüßen).
  
−
===Aufgaben===
+
*I2C Adressen haben im LSB-Bit immer NULL (das ist ja das R/W Bit), also sagen wir einfach, ein Pfad-Byte, dessen LSB = 0 ist, ist grundsätzlich Typ=I2C und gleichzeitig die Adresse.  
−
*Initialize: Was der Dispatcher zur Arbeit braucht, sind einige Tabellen. Er muß die empfangenen Modul-Adressen umsetzen können auf eine CALL-Entry-Adresse und einen Verweis auf die privaten Daten dieses Modules.  
+
*Ist das LSB = 1, kommts jetzt auf das nächste Bit an.
−
**Bei einem PC kann die Initiative auch von den einzelnen Modulen ausgehen, die durch einen "RegisterCallback" Aufruf an den Dispatcher ihre Adresse und den DatenVektor hinterlegen. Bevor sie das nicht getan haben, sind sie eben nicht da.  
+
*ist das NULL, gelten die restlichen 6 Bit als Funktionsindex, also eine Zahl 0-63. Das wird bei kleinen µC meistens auch schon reichen. Wenn wir noch festlegen, daß Index 0-3 immer eine UART (RS232 od. COM) bezeichnet, kommen wir auch da mit einem Byte aus. Das ist ja schon mal fein.   
−
**Auf den MC werden diese Tabellen und Verweise wohl schon im Source-Programm festgelegt werden, da hier zur Laufzeit wohl nicht mit einer Dynamik gerechnet werden muß
+
*es geht weiter wie dargestellt.  
−
*Send: Auch der Dispatcher braucht zum Senden die User-Daten, als Liste oder gesamt, das kann verschieden gemacht werden. Dazu natürlich die Zielangabe und etwas, mit dem eine Rückantwort mittels der ob. genannten Tabelle zugeordent werden kann. Wir haben ausgeführt, daß für Rückantworten einfach Ziel und Absender vertauscht werden. Die Rückadresse braucht also nur beim Absendersystem wirklich eine Bedeutung zu haben. Wenn das Comm-Modul on-the-fly arbeitet, muß das natürlich in der Schnittstelle berücksichtigt werden.   
+
*"reserved" ist im Moment noch offen, da könnten wir z.B. sagen, daß die verbliebenen 4 Bit im ersten Byte eine Längenangabe sind, wieviele Type- und Wert-Bytes noch folgen.  
−
*Receive: Synchron oder asynchron. Bei einem Aufruf durch das Comm-Module, daß Daten hier sind, werden jedenfalls mittels der Zieladresse in der Mapping-Table Call- und Daten-Vektor gesucht. Zusammen mit einem Verweis (Adresse, Länge) auf die Userdaten in der Message kann nun das Modul gerufen werden.
+
  
−
==Applikations-Schnittstelle==
+
<center>[[Bild:path.PNG]]</center>
−
Wenn von der Applikations eine Sendung veranlaßt werden soll, ist offensichtlich erforderlich
+
−
*Eine vollständige Zielangabe.  
+
−
*Die Absenderangabe, eventuell mit einen "Tag" um auch diese spezielle Message eindeutig zu machen.
+
−
Die "Node"-Angabe kann wohl entfallen, denn das Kommunikationsmodul wird wohl wissen, auf welchem Rechner es sich befindet.
+
−
*Fields/Daten: Das sind die eigentlichen "Nutz"-Daten, deren Inhalt, Aufbau und Bedeutung nur dem eigentlichen Sender und Empfänger bekannt sein müssen. Ob diese Daten gleich gesamt übergeben werden oder in einer Feld-Liste, kann beliebig gestaltet werden. 
+
  
−
Wenn es wundert, daß der Begriff "CMD" hier nirgends auftaucht: Es hat für den Transport von Messages eigentlich keine Bedeutung, denn eine Nachricht kann man so oder so immer nur weiterleiten. Dadurch ist es sinnvoll und flexibler, eine CMD-Feld innerhalb der User-Fields anzusiedeln.
 
  
−
==Spezielle Applikationen==
 
−
Wie schon oben erwähnt, kann es sinnvoll sein, einige spezielle Module anzuwenden, die der Betrieb sicherer und vielleicht auch einfacher machen.
 
−
*PING/Heartbeat
 
−
Eine Art Anwesenheitskontrolle. Kann auch leicht mit der allgemeinen "Timeout" Funktionalität verbunden werden. Auch ein Timestamp könnte damit verteilt werden.
 
−
*Enumerator/Enlisten
 
−
Beim Startup (oder auf Anforderung) sendet jedes System eine Liste mit den aktiven Module, eventuell mit einer "Kurz-Adresse", der dem Dispatcher die Tabellenarbeit erleichtert. DIe Gültigkeit dieser "short-cuts" muß natürlich gewährleistet sein (Änderung durch Umprogrammieren eines Controllers). Das kann geschehen, indem jedes System eine "Session"-Nummer (im EEPROM) führt. Die wird bei jedem Start oder Änderung inkrementiert. Hat ein anders System sich die letzte Nummer gemerkt, kann es durch die Unstimmigkeit die Änderung erkennen und eine aktuelle Liste anfordern.
 
  
−
==Gateways==
+
=Weblinks/Download=
−
Ein Gateway ist ein Übergang zwischen Netzwerken, die völlig unterschiedlich funktionieren und auch andere (Netzwerk-)Begriffe haben.  
+
http://www.oldformation.at/electronic/download/down.htm
−
Im Zusammenhang mit einer Vernetzung zwischen Controller und PC kann es sinnvoll sein,
+
−
*auf einem oder mehreren PC einen eigenständigen Prozess zu implementieren, der das Controller-Netz als Server abbildet.  
+
−
*die verfügbaren Controller und die Geräte darauf werden durch IP-Sockets und Ports abgebildet.
+
−
*Die eigentlichen PC-Applikationen zur Kontrolle oder Darstellung können ein oder mehrere Programme sein, die den Traffic als IP-Sessions über eines oder mehrere Ports abwickeln.
+
−
*Der Vorteil wäre die Plattform- und Sprachunabhängigkeit, denn Kommunikation über Sockets werden überall unterstützt.
+
  
−
==Autor==
+
=Autor=
 
*  [[Benutzer:PicNick|PicNick]]
 
*  [[Benutzer:PicNick|PicNick]]
  
−
==Siehe auch==
+
=Siehe auch=
−
*[[Network Controller/PC Schichten]]
+
*[[Network Controller/PC Routing]]
−
*[[Network Controller/PC Vermittlung]]
+
 
*[[Network Controller/PC Spezifikationen]]
 
*[[Network Controller/PC Spezifikationen]]
−
*[[RNcom Schicht 0]]
+
*[[Network Controller/PC Praxis]]
 
*[[Kommunikation/Protokolle]]
 
*[[Kommunikation/Protokolle]]
−
*[[Betriebssystem für Bascom]]
 
  
 +
[[Kategorie:Kommunikation]]
 
[[Kategorie:Software]]
 
[[Kategorie:Software]]
 
[[Kategorie:Projekte]]
 
[[Kategorie:Projekte]]

Aktuelle Version vom 10. Oktober 2006, 13:13 Uhr

In dieser Version werden die Festlegungen getroffen, die für ein kleines Controller/PC Netzwerk erforderlich sind. Beispielprogramme, Templates und Libraries für PC und µC sind teilweise fertig, teilweise in Entstehung, und können dann mit Download geholt werden.

  • Für µC-Programme liegt der Schwerpunkt vorerst auf Bascom, C-Libraries der Kern-Funktionen sind aber vorgesehen.
  • PC-seitig soll der RN-Server erstmal den Abschluß bilden, die eigentlichen Anwendungen muß ich mangels VB-Erfahrung den Spezialisten überlassen, soweit sie mitspielen wollen. Ich selbst kann nur know-how für MS Visual C++ liefern.

Das Netzwerk

Rncomsmall.png

Teilnehmer

  • Ein RNBFRA 1.2 Board, mit
    • Powerport
    • Outputport
    • Expansionport (Input)
    • AT90S2313 als Coprozesser, mit dem Servoprogramm "RNSXNET". Das ist eine Abwandlung des RNS-Servers für Netzwerke
  • Ein Zusatzboard (Eigenbau) mit einem Atmega16
  • Ein PC, der mit COM1 (RS232) mit dem RNBFRA Board verbunden ist
    • das PC-Programm "RN_SERVER.EXE, das das Routing übernimmt
    • mehrere PC-Anwendungen


Messages (Nachrichten)

Rncomformat.png

Je nach physikalischem Transportmittel wird die Message verschieden eingepackt. Anm. IP: Das Längenwort (16-Bit) beinhaltet die Länge der Daten exklusive Längenwort. D.h, um z.B. vier Byte zu übertragen, werden insgesamt 6 Byte weggeschickt.

Der Vergleich mit einer Briefsendung ist zulässig, da wie dort gibt es

  • Zieladresse (Target)
  • Absender (Source)
  • Daten

Uns interessiert zuerst einmal nur, wie eine solche Nachricht vom Sender zum Empfänger und ggf. wieder zurückkommt, daher können uns die Daten selbst erst einmal völlig egal sein.

Details zu Messages:

Adressen

Für die PC-Anwendungen ist der Aufbau des Controller-Netzwerkes transparent, d.h. die Adressierung erfolgt (normalerweise) mit 16-Bit ID-Codes

Pfade

Was ist denn in einer einzelnen Pfadangabe darzustellen ?

  • Typ und Wert
    • I2C u. Adresse (7-Bit)
    • UART u. ev. eine Nummer 1, 2,..
    • RS232 das ist eigentlich das Gleiche wie UART oder COM
    • IP u. Socket da müßte man schon mit einem 16-Bit Wort rechnen
    • Funktions-ID. Auch da haben wir bisher 16 Bit festgelegt.

Wenn man da noch die Möglichkeit einer vollständigen IP-Adresse dazunimmt, würden wir auch noch entweder Text ("www.nirwana.com") oder eine IP-Addresse (32-Bit) + Port (16-Bit) unterbringen.

Was heißt denn eigentlich "Typ" ? Nun, im Grunde muß daraus nur eine bestimmte Programm-funktion abgeleitet werden, die dann auch ihren "Wert" bekommen kann. Wie kann man eine sowas identifizieren ?

  • Einfach ein Index (die soundsovielte Funktion)
  • Eine Direktadresse (wohl nur theoretisch)
  • Eine ID (mit Tabelle)

Damit wir nicht irgendeinen kleinen Controller als Zwischenstation durch zu lange Messages oder Tabellen überfordern, ist es wohl ratsam, ein wenig Bits zu quetschen (Huffman läßt grüßen).

  • I2C Adressen haben im LSB-Bit immer NULL (das ist ja das R/W Bit), also sagen wir einfach, ein Pfad-Byte, dessen LSB = 0 ist, ist grundsätzlich Typ=I2C und gleichzeitig die Adresse.
  • Ist das LSB = 1, kommts jetzt auf das nächste Bit an.
  • ist das NULL, gelten die restlichen 6 Bit als Funktionsindex, also eine Zahl 0-63. Das wird bei kleinen µC meistens auch schon reichen. Wenn wir noch festlegen, daß Index 0-3 immer eine UART (RS232 od. COM) bezeichnet, kommen wir auch da mit einem Byte aus. Das ist ja schon mal fein.
  • es geht weiter wie dargestellt.
  • "reserved" ist im Moment noch offen, da könnten wir z.B. sagen, daß die verbliebenen 4 Bit im ersten Byte eine Längenangabe sind, wieviele Type- und Wert-Bytes noch folgen.
Path.PNG


Weblinks/Download

http://www.oldformation.at/electronic/download/down.htm

Autor

Siehe auch

Von „https://rn-wissen.de/wiki/index.php?title=Network_Controller/PC&oldid=9222“

LiFePO4 Speicher Test