Irritiert wegen Ethernet-Internet-TCP-UDP-HTTP-Network ??

Zur Zeit laufen in allen Medien und bei den Anwendern Diskussionen über "Embedded Ethernet". Und dabei fällt sofort der Begriff "TCP/IP". Viele Leute setzen diese Begriffe gleich, so das der Eindruck entsteht, dass alles das gleiche ist, TCP/IP ist Ethernet und auch Internet. Aber nur eines trifft grundsätzlich zu: Embedded Ethernet hat eine grosse Zukunft. Aber es gibt sehr viel Nebel und Unklarheiten dabei. Man beachte bei der ganzen Diskussion, dass man meistens von "Embedded Ethernet" spricht und nicht von "Embedded TCP/IP". Eine Implementation eines Ethernet Treibers irgendwelcher Art bezeichnet man i.A. als Netzwerk Stack oder "NetStack". Dies dient zur Klärung der hier benutzten Begriffe.

Unser Ziel war es zuerst auch ein komplettes TCP/IP mit allen Layern zu implementieren. Wir untersuchten diverse Implementationen mit PIC, HC11, HC16, 8051 und AVR die im WEB veröffentlicht wurden. Dabei stellte es sich sehr schnell heraus, dass ein Teil unbrauchbare Mickey Mouse Programme waren, und die anderen extrem gross waren (>30k).

Wir haben ein offensichtlich sehr gut designtes System aus dem WEB namens "L..." (mega103) getestet. Aber ein kurzes Bombardement mit Packeten brachte es zum Absturz. Sehr enttäuschend. Andere Implementationen machten einen argen "quick and dirty" Eindruck. Ein PIC mit einem kompletten TCP/IP HTTP Stack in 4kBytes ROM wird auch angeboten :-)

Also haben wir uns hingesetzt und gesagt : back to the roots, das ganze nocheinmal von vorne. Was wollen wir erreichen mit einem AVR und Ethernet? Einen WEB Browser erstellen? Einen WEB Server? E-mails verschicken? E-mails empfangen? Einen FTP Server oder Client erstellen? Eigentlich nicht! Eine Netzwerk Verbindung auf der Basis eines AVR ist mit einer V24/RS232 zu vergleichen. Das Ethernet ist "nur" ein weiterer Weg um mit anderen (der Aussenwelt) zu kommunizieren, nicht mehr aber auch nicht weniger. Wenn man einen WEB Server braucht, dann tut es zum Beispiel ein PC104 Board mit einem Linux. Das ist billig, schnell und klein.

Messages Senden und Empfangen, Steuer-Packete in einer extrem kurzen Zeit empfangen und reagieren auf eine sichere Art. Das ist das Ziel!

Das Ergebnis war: wir brauchen einen schnellen Packet Transfer von Board zu Board, vom PC zum Board und zurück.
Die Übertragung muss sehr sicher sein. Packet Verluste können nicht akzeptiert werden. Wir brauchen eine sehr kurze Reaktionszeit, die Packet Zeit muss unter 10msec sein, damit man Echtzeit Aufgaben erledigen kann.

Jedes TCP basierende Protokoll kann diese Anforderungen nicht erfüllen. Der einzig gangbare Weg ist das UDP/IP Protokoll. Eine Recherche im WEB hat dann ganz schnell gezeigt, dass alle industriellen Ethernet Implementationen (Motorola, Siemens, ProfiBUS etc) das UDP für Realtime Jobs benutzen.

Aber da gibt es ein grosses Problem mit UDP/IP. UDP ist ein sog. "unsicheres" Protokoll. Das bedeutet dass der Sender niemals weiss ob sein geschicktes Packet beim Empfänger angekommen ist. Wenn ein UDP Packet verloren geht bemerken das beide Teilnehmer nicht. Weiterhin, wenn das Packet angekommen ist, kann der Empfänger nicht feststellen, ob der Datenteil des Packets beschädigt wurde oder nicht. Falsche oder fehlende Daten können nicht festgestellt werden. Zwei grosse Nachteile, die das Standard UDP für Steuer-Anwendungen unbrauchbar macht.

Eine genauere Betrachtung der industriellen (control) UDP Implementationen zeigte, dass alle ein zusätzliches Handshake und Checksum Verfahren benutzen. Das ist die Lösung!. Extreme Geschwindigkeit durch UDP/IP mit zusätzlichem Handshake und Daten Checksumme. Sicher, das setzt den Datendurchsatz wieder etwas herab. Trotzdem ist dieses Verfahren sehr viel schneller als das reine TCP/IP Protokoll, und es ist sicher!!

Nach diesen Untersuchungen mit diesen Ergebnissen haben wir entschieden ein extended UDP/IP zu implementieren. Wir nennen dieses Verfahren xUDP. Es ist absolut sicher und sehr schnell. Board zu Board Verbindungen sind sehr einfach. PC zu Board Verbindungen können mit dem E-LAB xUDP Mapper Programm aufgebaut werden.

E-LAB xUDP Mapper
Was ist ein Mapper??
Da es unser Ziel war, ein sicheres high speed Ethernet Protokoll zu implementieren, das kleiner 8kB Code Grösse hat, gibt es hier keinen direkten TCP/IP (FTP, HTTP, TFTP, TelNet, e-mail etc) Support in unserem NetStack. Das ist aber normalerweise keine Einschränkung. High speed Transfers können mit xUDP ausgeführt werden. Wenn z.B. eine FTP Verbindung notwendig wird, so wird ein sogenannter "GateWay" eingesetzt. Der PC-gest"tzte E-LAB xUDP Mapper ist so ein Werkzeug. Es kann auf jedem PC mit LAN Anschluss installiert werden. Es läuft unsichtbar im Hintergrund.

Wenn ein xUDP Stack in diesem LAN/Netzwerk eine FTP Verbindung anfordert, wird der xUDP Mapper aktiv und mappt die xUDP Packete in FTP Packete und umgekehrt. Diese Packete werden nun weitergeleitet zu einem entspr. FTP Server oder von diesem abgeholt. Das ist transparent für alle Teilnehmer. Zukünftige Versionen werden auch weitere Protokoll Typen unterstützen, einschliesslich e-mails.

Dieses PC Programm hat 4 Aufgaben.

1. Konfiguration jedes Boards mit dem xUDP Kernel. IP-address, MAC-address, Boardname etc.
   Das muss durch eine V24/RS232 Verbindung zwischen PC und Board erfolgen.
2. Boards testen mit einem Scanner und einem Pinger.
3. Übersetzen bzw. Mappen des xUDP ProtoKolls in andere Protokoll Typen. Dadurch kann das Board mittels FTP
   kontaktiert werden und das Board kann Daten bzw. Dateien zu einem FTP-Server uploaden in dem lokalen
   Netwerk oder worldwide net (WEB).
4. Eine Chat ähnliche Verbindung in semi realtime mit irgend einem PC etc. aufnehmen (LAN oder WEB).

Ähnliche Tools und Programme werden im Internet für mehrere $1000 angeboten :-)

Mit der Hilfe eines PCs im lokalen Netzwerk kann der xUDP Stack die meisten der bekannten TCP/IP ProtoKolle benutzen, ohne das on-chip FLASH oder RAM zu fluten oder den AVR komplett mit schwierigen und aufwendigen Protokollen auszulasten.

Tests mit unserem EtherBoard mit einem 6.4MHZ AVR mega System ist der Ping response time für 65 Bytes bei ca. 3msec, ein Standard Ping dauert ca. 4msec und ein 1.5kByte Ping dauert ca. 10msec. Neue AVRs (mega104) werden diese Zeiten evtl. noch einmal halbieren.

Da ein xUDP Packet einem Ping ziemlich ähnlich ist, wird hier die Zeit immer unter 10msec bleiben, wenn die Packet Grösse sich im Bereich von einigen hundert Bytes bewegt. Das kann man schon unter "Echtzeit" verbuchen.

Die xUDP Kernel Grösse ist ca. 6kBytes, RAM ist ca. 400bytes plus 2 Buffers (Rx/Tx). Deshalb kann unser xUDP System leicht in einen mega161, mega163, mega32 etc. implementiert werden.

Der xUDP Stack/Treiber ist ein Teil der AVRco Pascal Profi Version. Zur Zeit wird nur der RTL8019 Ethernet Chip intern unterstützt. Eine spätere Version unterstützt auch dann einen "generic driver" wobei der Programmierer seinen eigenen Netzwerk Treiber/Chip implementieren kann.