OT? uC <-> EtherNet

Hi!

das später alles etwas ausbaubarer sein. Es kann also

hängen und dann natürlich auch unterschieden werden

Die Ethernetpakete sind ja mit Source und Dest. (MAC)Address definiert und jeder Netzwerkcontroller kann da glaub ich von alleine die richtigen Pakete für sich rausfiltern. Musst den Controller halt vorher mit der richtigen MAC Addresse konfigen...

Ähnliches/Alternativen?

Hab nur mit dem CS8900A bischen Erfahrung

TCP is ne gesicherte Verbindung. D.h. du musst erst ne Verbindung aufbauen, dann kannste Daten reinschieben und TCP kümmert sich darum, dass sie in der richtigen Reihenfolge und vollständig beim Empfänger ankommen. UDP is nur ne Kapselung für die IP Packete. D.h. wenn Du was per UDP verschickst kann es sein, dass es unterwegs verloren geht und dann nie beim Empänger ankommt. Auch müssen Packete die per UDP versendet werden nicht in der gleichen Reihenfolge ankommen wie sie losgeschickt wurden. Bei UDP wird keine Verbindung aufgebaut.

Da vor allem "Ethernet" und "Internet Protocols (IP)" Wobei die Frage ja ist, ob du IP brauchst. Sicher, ist _das_ Standartprotokoll und wenn du per Browser usw. auf deine Geräte zugreifen willst brauchste das. Aber um ganz simpel Daten zu den Geräten zu schicken kann man sicher auch irgendwie direkt Ethernetpackete versenden. Bzw. wenn überhaupt kein PC involviert sein soll und nur deine Geräte im Netzwerk sind ist IP sicherlich übertrieben.

Kenn ich nicht. Ich find die Cisco Doku schon ganz gut. Wenn man dann noch tiefere Infos haben will kann man ja bischen nach RFC googlen. Allgemeine Bücher über Netzwerktechnik sind wohl auch nicht das was du suchst. Da gehts vermutlich ehr darum wie man grosse Netzwerke betreibt, d.h. Routing, Sicherheit, usw... Aber du willst ja ehr Infos über Details eines Endgerätes.

Michael

Hallo,

Michael Dreschmann schrieb:

Also könnte man ganz grob so formulieren: IP ist UDP mit Fehlererkennung/Korrektur?

Werde ich mir auf jeden Fall anschauen.

Wie könnte man eigentlich die Fehlerquoten einer einfachen RS232 Verbindung ohne grossartiges "Protokoll" mit einer UDP Übertragung vergleichen?

Ich spinn jetzt mal ein bisschen rum:

Wenn ich bisher kritische Daten wie ein Firmwareupdate oder bin-Images für einen DSP in ein Flash per RS232 schaufle benutze ich zumindest immer ein Blockverfahren mir einfachen Checksummen. Grossartige (erkannte) Fehler oder Ausfälle hatte ich da bisher nie.

Prinzipiell könnte man das selbe Verfahren ja auch bei UDP anwenden? Verlorene Daten kann ich erkennen. Oben wurde die Reihenfolge der Pakete angesprochen. Wie bekomme ich mit ob meine Daten verwürfelt werden/wurden?

Wenn ich das ganze jetzt per IP mache kann ich ja eigentlich auf einen Teil der Fehlererkennung / Blockbildung verzichten? Es reicht ja dann nur so ne Art Startkommando vom Sender ("Jetzt geht's los") und eine Quittung von meinem Gerät ("Habe alles bekommen und verarbeitet"). Fehler auf der Übertragungsstrecke dürfte es ja dank IP nicht geben?

Alexander

Hallo Alexander!

nicht wirklich würde ich sagen.

Geräte implementieren dürfen. Da man das Rad ja nicht

Genau. Suchst du sowas in der Art:

?

Gruß Thorsten

--
Kunst kommt aber von 'können',
nicht von 'kennst du schon den neuesten trick?'
   Gunther in oecher.computer zum Thema "Gutes Webdesign"

Hallo!

• "Alexander Peter" schrieb:

Fehlererkennung/Korrektur?

Nein. Bei TCP/IP im Ethernet sehen die Schichten etwa so aus:

1. Ethernet (überträgt Frames)
2. IP (Pakete)
3. TCP (Windows) _oder_ UDP ("Datengramme"; schreckliches Wort)

UDP hat eine einfache Prüfsumme für jedes Datengramm. Das Verfahren ist aber alles andere als zuverlässig. Für sensible Daten (Firmware- Update etc.) solltest Du selbst eine Prüfsumme mitschicken.

ohne grossartiges "Protokoll" mit einer UDP Übertragung

Dürfte in etwa vergleichbar sein. Unter normalen Umständen wird der Inhalt eines IP-Pakets nicht verfälscht. Solange es nur um LAN geht, werden gestörte Frames schon von der Netzwerkkarte aussortiert (Ethernet-Frames haben eine eigene Prüfsumme).

einen DSP in ein Flash per RS232 schaufle benutze ich

(erkannte) Fehler oder Ausfälle hatte ich da bisher nie.

Daten kann ich erkennen. Oben wurde die Reihenfolge

werden/wurden?

Einfach einen fortlaufenden Zähler verwenden. Sieh Dir mal das RFC zu TFTP an. Das ist ein sehr einfaches Dateitausch-Protokoll auf UDP-Basis. Zum Implementierten bedarf es nicht viel Pufferplatz.

der Fehlererkennung / Blockbildung verzichten? Es reicht

Quittung von meinem Gerät ("Habe alles bekommen und

geben?

Fehler sind unwahrscheinlich, können aber vorkommen. Einfach jedes Datengramm mit Prüfsumme versehen und quittieren, dann geht nichts verloren.

Gruß, Till.

--
e-mail: wollenberg (at) web (punkt) de

Hallo,

gibt es zu kaufen, aber frag mich jetzt nicht wo. Ein entsprechender Artikel steht glaube ich in der letzten c't. Der Preis lag so um die 100 EURO.

MfG Michael

--
Michael Schlegel
Faculty of Electrical Engineering and Information Technology
Chemnitz University of Technology, Germany
http://www.tu-chemnitz.de/~micsch

Thorsten Ostermann schrieb:

Ok, den hatte ich in meine Ursprungsposting nicht eingetragen ;-)

Michael Schlegel schrieb:

Und das ist leider noch zu teuer :-( Die XPorts liegen bei 1k schon um die 40 USD

Fehlererkennung/Korrektur?

Hier fehlen mindestens noch ARP und ICMP

Was meinst du mit "Windows"? Und üblicherweise sagt man "Datagramm" vs. "Stream". UDP ist eigentlich nur IP mit Portnummern für Sender bzw. Empfänger. TCP hingegen implementiert viel mehr:

- Quittierung empfangener Pakete

- erneute Anforderung verloren gegangener Pakete

- Sortierung von Paketen in die richtige Reihenfolge (dank Routing können IP-Pakete in beliebiger Reihenfolge ankommen)

- Flußkontrolle (ECN), Out-Of-Band-Notifikation etc. pp

Mitnichten. In einer Punkt-zu-Punkt Konfiguration, wo die Hardware schnell genug ist, kein Paket zu verpassen, ist UDP durchaus zuverlässig.

Nicht nur das. Da hier die Reihenfolge der Pakete wesentlich ist, sollte man gleich TCP verwenden. Eine Eigenimplementierung der erforderlichen (TCP-)Features ist zwar möglich, aber selten sinnvoll.

XL

--
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau

Hi!

Fehlererkennung/Korrektur?

Nein, aber UDP ist IP mit Fehlererkennung. Keine Korrektur. Das macht nur TCP (in dem es das Packet neu anfordert). Ausserdem wird bei UDP/TCP noch die Sache mit den Ports geregelt, damit mehrere Anwendungen komunizieren können. (Nur so nebenbei)

ohne grossartiges "Protokoll" mit einer UDP Übertragung

UDP in Verbindung mit Ethernet? Ist auf jedenfalls sicherer als ne einfache RS232 Verbindung weil sowohl Netzwerkkarte als auch UDP ne Checksumme überprüft.

Daten kann ich erkennen. Oben wurde die Reihenfolge

werden/wurden?

Wenn du das alles im LAN machst und das nicht hoffnungslos überfüllt ist, dann ist das nicht so kritisch. Das Problem von verlohrenen Packteten trifft ehr im Internet auf. Also wenn deine Anwendung nacher nach Australien kommunizieren soll...

Fehlererkennung / Blockbildung verzichten? Es reicht

Quittung von meinem Gerät ("Habe alles bekommen und

geben?

Naja, wenn das Kabel rausgezogen wird kann selbst TCP nichts mehr machen. :) Zumindest ein Fehlercommando könntest du also noch einbauen... :) Aber ich denke TCP ist für deine Sache vorskilled wenn's nur im LAN sein soll. Ist nich zu unterschätzender Aufwand das zu implementieren... (bin grade dabei)

Michael

=2E...

scheint ja der Hauptunterschied zwischen EtherNut und

RFC761/RFC768/RFC793 etc.

komplett, aber supertrocken

Deutlich lesbarer: TCP/IP Illustrated Volume I von W.R. Stevens

(nicht ganz billig)

Gru=DF, Toby

Hallo!

• "Axel Schwenke" schrieb:

Fehlererkennung/Korrektur?

ARP ja, ICMP ist für eine sparsame Implementierung nicht nötig (wir sprechen hier von kleinen 8-Bit µC).

Danke, aber ich bin über TCP einigermaßen im Bilde. Windows sind die (über dem IP-Paket) nächst höhere Struktur bei TCP. Der Fluß der Windows bildet dann den Stream.

"Das Verfahren" bezieht sich auf das verwendete Prüfsummenverfahren, nicht auf IP/UDP als Ganzes. Im abgeschotteten, "ruhigen" LAN ist Paketverlust in der Tat kaum zu erwarten. Im Internet kommt er allerdings häufiger vor, als man denkt.

Das ist das Standard-Argument. Wie oben bereits erwähnt, sprechen wir hier aber nicht von ausreichend dimensionierten 16-Bittern mit genug RAM, sondern von kleinen 8-Bittern in der Region von 2KB RAM. Ein für TCP notwendiger Stream-Puffer ist da schlicht nicht drin, vom Aufwand (Codegröße!) für alle anderen Protokoll-Intera mal ganz zu schweigen. Die Empfehlung für etwas TFTP-artiges kam daher nicht von ungefähr.

Gruß, Till.

--
e-mail: wollenberg (at) web (punkt) de

ICMP ist bei TCP/IP immer nötig. Z.B.für die MTU Discovery, sonst geschehen bei bestimmten Zugängen (DSL) merkwürdige Dinge.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

Ist das nicht so, als würde der Medizin-Professor einem angehendem Arzt raten, die menschliche DNA-Sequenz zu studieren? ;-))

SCNR, Thomas.

Alexander Peter wrote:

Grob vereinfacht und aus Anwendersicht - besser gesagt, genauer weiß ich es auch nicht ;-) TCP/IP ist das Protokoll, auf dem HTTP (also das Web) aufsetzt. Es enthält Fehlerschutzmechanismen und verschiedene bandbreiteschonende Timeout-Kriterien. Ist für Steuerungen oder "nur mal schnell Daten übertragen" eher ungeeignet, schon weil Verbindungen regelrecht "aufgebaut" werden müssen und gerne mal (wenn eine Verbindung versehentlich durch Reset gekappt wurde) mehrere Minuten vor sich hin idlen, bevor der Empfänger merkt, dass der Sender "weg" ist. Der Sender kann während dieser Zeit diese Verbindung nicht mehr wieder aufnehmen. UDP/IP ist ein Protokoll, welches sich recht gut mit RS232 vergleichen lässt: Es gibt keine Bestätigung auf versandte Daten, man weiß auch nicht so ohne weiteres, ob der Empfänger überhaupt "online" ist oder die Daten überhaupt ankommen. Also wie bei RS232, wo man ja auch nicht so ohne weiteres weis, ob denn das RS232-Kabel überhaupt eingestöpselt ist. Aber dafür hat UDP/IP eine sehr geringe Latenzzeit, versandte Daten kommen also nach wenigen Millisekunden schon beim Empfänger an. UDP/IP über Ethernet ist sogar CRC-geschützt, es kommen also keine falschen Zeichen an (im Zweifelsfall wird ein falsches Paket einfach verworfen). Für Steuerungen wird fast ausschließlich UDP/IP oder darauf aufbauende Protokolle verwendet. Das, was UDP angeblich als Nachteil gegenüber TCP/IP hat - Paket- reihenfolge kann beim Empfänger vertauscht ankommen, Pakete können verloren gehen - kommt innerhalb eines Netzwerksegments praktisch nicht vor - BTDT... Über das "echte Internet" sind solche Dinge aber wohl schon an der Tagesordnung.

Da gibt es noch das "IIM7000A" (Vorgängerversion IIM7000) Mini Network Module, z.B. bei

für 28,00 Fragezeichen. Darauf ist der Chip W3100A, der einen "Hardware-IP-Stack" realisiert und über vergleichsweise einfache Befehle die wichtigsten Protokolle beherrscht (UDP, TCP, ARP, PING u.a.). Es gibt für dieses Modul wohl schon einige Sourcen für den ATmega, allerdings für den BASCOM Compiler. Da die API des W3100A im Datenblatt dieses Chips dokumentiert ist, sollte es eigentlich kein so großes Problem sein, beispielsweise eine UDP-Verbindung damit selbst zu programmieren.

Wenn Du also "nur schnell" ein paar Daten "wie über RS232" übertragen möchtest, macht es Sinn, UDP/IP zu verwenden und einfach einen festen Port dafür zu benutzen. Das dürfte auch mit dem vorher genannen Modul IIM7000 noch halbwegs einfach selbst zu programmieren sein. Jan-Hinnerk Reichert hat zu diesem Modul schon einige Erfahrungen in comp.arch.embedded veröffentlicht (siehe

) und wohl auch eine Website zu diesem Thema in Planung.

Thomas.

ICMP-Unreachable ist mindestens nett, wenn man UDP/TCP sprechen will.

Und? Bei UDP/IP/Ethernet ist das dann die dritte Prüfsumme. IMHO könnte man die auch ganz weglassen.

...

Das Standard-Argument ist: verwende vorhandenen Code. Wenn eine TFTP- Implementierung dazugehört, kann das auch die sein.

Du kennst ?

XL

--
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau

Hallo!

Die zweite. IP püft nur den IP-Header, nicht die Nutzdaten. Und ob auf jedem Medium ein CRC Check gemacht wird wie bei Ethernet ist auch die Frage. Von daher is die Checksum von TCP/UDP doch schon ganz sinnvoll.

Michael

Hallo!

• "Axel Schwenke" schrieb:

Wie Michael schon schrieb betrifft einzig die UDP-Prüfsumme die eigentlichen Daten. Die Ethernet-Frame-Prüfsumme ist hinfällig, sobald das IP-Paket geroutet wird.

Jup, kannte ich schon. Das ist zwar ein sehr nettes Projekt, aber nicht wirklich praxistauglich. Zum Beispiel wird ein eintreffender HTTP-Request anscheinend überhaupt nicht ausgewertet, sondern die zu sendende Datei anhand der Portnummer bestimmt. Der ICMP-Teil belegt laut Website 11 Instruktionen und beantwortet gerade mal ICMP-Echo-Requests mit einer bestimmten Länge. Leider liegt der Source nicht offen, so daß man sich die genaue Implementierung nicht ansehen kann.

Gruß, Till.

--
e-mail: wollenberg (at) web (punkt) de

Wenn es der ist, denn ich mir schonmal angeschaut habe, dann kann der praktisch nichts. Er ist über Slip (nicht ppp, auch kein Ethernet) angebunden, wertet aber nichtmal die IP-Adresse aus (er nimmt an, alles sei für ihn). Er wertet auch nicht die URL aus, sondern nur die Port-Adresse (eine Seite pro Port).

Wenn man einen billigen Router hat, der auch SLIP spricht ist das vielleicht ganz ok, aber ich kenne da keinen. Auch derjenige, der den kleinen Webserver gebaut hat, benutzt dazu einen PC bzw. eine DEC Alpha - und das ist der Punkt, den ich dann nicht mehr nachvollziehen kann. Es ist doch viel sinnvoller, an der Stelle nur die Meßwerterfassung mit dem Microcontroller zu machen und den Webserver dazu auf einem PC laufen zu lassen.

Markus

Ich sehe schon, da gibt's wohl zum ein oder anderen Thema noch Diskussionsbedarf, was einen tiefer in die Materie zwingt ;-) Einstweilen danke ich mal für die Antworten und Links. Ein paar haben mir direkt und sehr weitergeholfen, für die anderen brauche ich wohl noch etwas.

Alexander