OT? uC <-> EtherNet

[Alexander Peter]

Hallo,

vielleicht etwas OT, aber hier gab's genügend Traffic, der mir bisher weiterhelfen konnte: habe heute die Google Kugel befragt, mir
diverse Webseiten angeschaut, Distris angerufen und bin trotzdem noch nicht ganz weiter gekommen:

Ich werde wohl demnächst ein EtherNet Interface für die uCs (AVRs) unsere Geräte implementieren dürfen. Da man das Rad ja nicht
immer neu erfinden muss habe ich folgende "Lösungen" entdeckt:

* EtherNut
* XPort
* EasyToWeb
* DIGI Connect

Prinzipiell reicht mir so ne Art RS232 &lt;-&gt; Ethernet Interface. Allerings soll das später alles etwas ausbaubarer sein. Es kann also
durchaus vorkommen, dass nicht nur ein Gerät sondern mehrere Geräte im Netz hängen und dann natürlich auch unterschieden werden
können müssen.

Hat da wer Erfahrungen mit den obigen Teilen? Kennt wer was Ähnliches/Alternativen?

Das ganze soll wie immer möglichst schnell, einfach und kostengünstig gehen, also z.B. Modul an die Serielle andocken fertig

Plan B wäre, die Platformen etwas aufzubohren (grösserer Controller) und den das dann "nebenher" mit einem fertigen Stack und einem
passenden Chip (CS8900A/RTL8019/W3100/?) zu ergänzen.

Bei meinen Recherchen habe ich dann auch festgestellt dass ich noch ein paar Wissensdefizte bezüglich Netzwerktechnik habe. Ich kann
zwar meinen PC im LAN konfigurieren, eine DFÜ Verbindung aufbauen einen JanaServer konfigurieren etc., aber die einzelnen
Mechanismen dahinter kenne ich nur als Schlagworte.

Worin unterscheiden sich grob eine Kommunikation per TCP/IP und UDP. Das scheint ja der Hauptunterschied zwischen EtherNut und
EasyToWeb zu sein?

Was für Literatur könnt ihr mir empfehlen?

Ich habe desöfteren folgende Bücher in Literaturangaben gefunden:

* TCP/IP Praxis, G. Lienemann
* Ethernet, Charles E. Spurgeon (engl.)
* Ethernet. Technologien und Protokolle für die Computervernetzung, J. Rech

Die Amazonbewertungen finde ich etwas schlapp. Kommentare von euch?

Gruss

Alexander

 

[Michael Dreschmann]

Hi!

Prinzipiell reicht mir so ne Art RS232 &lt;-&gt; Ethernet Interface. Allerings soll das später alles etwas ausbaubarer sein. Es kann also
durchaus vorkommen, dass nicht nur ein Gerät sondern mehrere Geräte im Netz hängen und dann natürlich auch unterschieden werden
können müssen.

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

Hat da wer Erfahrungen mit den obigen Teilen? Kennt wer was Ähnliches/Alternativen?

Hab nur mit dem CS8900A bischen Erfahrung

Worin unterscheiden sich grob eine Kommunikation per TCP/IP und UDP.

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.

Was für Literatur könnt ihr mir empfehlen?

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/
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.

Ich habe desöfteren folgende Bücher in Literaturangaben gefunden:

* TCP/IP Praxis, G. Lienemann
* Ethernet, Charles E. Spurgeon (engl.)
* Ethernet. Technologien und Protokolle für die Computervernetzung, J. Rech

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

 

[Alexander Peter]

Hallo,

Michael Dreschmann schrieb:

Worin unterscheiden sich grob eine Kommunikation per TCP/IP und UDP.

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.

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

Was für Literatur könnt ihr mir empfehlen?

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/
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.

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

 

[Thorsten Ostermann]

Hallo Alexander!

vielleicht etwas OT,

nicht wirklich würde ich sagen.

Ich werde wohl demnächst ein EtherNet Interface für die uCs (AVRs) unsere Geräte implementieren dürfen. Da man das Rad ja nicht
immer neu erfinden muss...

Genau. Suchst du sowas in der Art:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2727 ?

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

 

[Till Wollenberg]

Hallo!

* "Alexander Peter" &lt;apeter@musicandsales.com&gt; schrieb:

Michael Dreschmann schrieb:
Worin unterscheiden sich grob eine Kommunikation per TCP/IP und UDP.

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.

Also könnte man ganz grob so formulieren: IP ist UDP mit 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.

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

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).

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?

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.

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?

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

 

[Michael Schlegel]

Prinzipiell reicht mir so ne Art RS232 &lt;-&gt; Ethernet Interface.

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

 

[Alexander Peter]

Thorsten Ostermann schrieb:

Genau. Suchst du sowas in der Art:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2727 ?

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

 

[Alexander Peter]

Michael Schlegel schrieb:

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.

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

 

[Axel Schwenke]

"Till Wollenberg" &lt;till@deadspam.com&gt; wrote:

* "Alexander Peter" &lt;apeter@musicandsales.com&gt; schrieb:

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

Nein. Bei TCP/IP im Ethernet sehen die Schichten etwa so aus:
1. Ethernet (überträgt Frames)
2. IP (Pakete)

Hier fehlen mindestens noch ARP und ICMP

3. TCP (Windows) _oder_ UDP ("Datengramme"; schreckliches Wort)

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

UDP hat eine einfache Prüfsumme für jedes Datengramm. Das Verfahren
ist aber alles andere als zuverlässig.

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

Für sensible Daten (Firmware-
Update etc.) solltest Du selbst eine Prüfsumme mitschicken.

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

 

[Michael Dreschmann]

Hi!

Also könnte man ganz grob so formulieren: IP ist UDP mit 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)

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

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

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

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?

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

 

[Tobias Schlottke]

On Wed, 28 Apr 2004, Alexander Peter wrote:

....

Worin unterscheiden sich grob eine Kommunikation per TCP/IP und UDP. Das scheint ja der Hauptunterschied zwischen EtherNut und
EasyToWeb zu sein?

Was für Literatur könnt ihr mir empfehlen?

RFC761/RFC768/RFC793 etc. (www.ietf.org)
komplett, aber supertrocken

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

(nicht ganz billig)


Gruß,
Toby

 

[Till Wollenberg]

Hallo!

* "Axel Schwenke" &lt;schwenke@jobpilot.de&gt; schrieb:

"Till Wollenberg" &lt;till@deadspam.com&gt; wrote:
* "Alexander Peter" &lt;apeter@musicandsales.com&gt; schrieb:

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

Nein. Bei TCP/IP im Ethernet sehen die Schichten etwa so aus:
1. Ethernet (überträgt Frames)
2. IP (Pakete)

Hier fehlen mindestens noch ARP und ICMP

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

3. TCP (Windows) _oder_ UDP ("Datengramme"; schreckliches Wort)

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

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.

UDP hat eine einfache Prüfsumme für jedes Datengramm. Das Verfahren
ist aber alles andere als zuverlässig.

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

"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.

Für sensible Daten (Firmware-
Update etc.) solltest Du selbst eine Prüfsumme mitschicken.

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.

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

 

[Oliver Bartels]

On Thu, 29 Apr 2004 17:12:41 +0200, "Till Wollenberg"
&lt;till@deadspam.com&gt; wrote:

ARP ja, ICMP ist für eine sparsame Implementierung nicht
nötig (wir sprechen hier von kleinen 8-Bit ľC).
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

 

[Thomas Rehm]

Tobias Schlottke wrote:

Was für Literatur könnt ihr mir empfehlen?

RFC761/RFC768/RFC793 etc. (www.ietf.org)
komplett, aber supertrocken

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

SCNR,
Thomas.

 

[Thomas Rehm]

Alexander Peter wrote:

Worin unterscheiden sich grob eine Kommunikation per TCP/IP und UDP.

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.

Prinzipiell reicht mir so ne Art RS232 &lt;-&gt; Ethernet Interface

Da gibt es noch das "IIM7000A" (Vorgängerversion IIM7000) Mini Network
Module, z.B. bei www.elektronikladen.de/easytcpip.html 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
http://groups.google.de/groups?selm=b2hh50%241c3jti%241%40news.hansenet.net
) und wohl auch eine Website zu diesem Thema in Planung.

Thomas.

 

[Axel Schwenke]

"Till Wollenberg" &lt;till@deadspam.com&gt; wrote:

* "Axel Schwenke" &lt;schwenke@jobpilot.de&gt; schrieb:
"Till Wollenberg" &lt;till@deadspam.com&gt; wrote:
1. Ethernet (überträgt Frames)
2. IP (Pakete)

Hier fehlen mindestens noch ARP und ICMP

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

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

UDP hat eine einfache Prüfsumme für jedes Datengramm. Das Verfahren
ist aber alles andere als zuverlässig.

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

"Das Verfahren" bezieht sich auf das verwendete Prüfsummenverfahren,

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

Für sensible Daten (Firmware-
Update etc.) solltest Du selbst eine Prüfsumme mitschicken.

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.

Das ist das Standard-Argument.
....
Die Empfehlung für etwas TFTP-artiges kam daher nicht
von ungefähr.

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

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.

Du kennst &lt;http://www-ccs.cs.umass.edu/~shri/iPic.html&gt; ?


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

 

[Michael Dreschmann]

Hallo!

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

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

 

[Till Wollenberg]

Hallo!

* "Axel Schwenke" &lt;schwenke@jobpilot.de&gt; schrieb:

"Till Wollenberg" &lt;till@deadspam.com&gt; wrote:

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

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.

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.

Du kennst &lt;http://www-ccs.cs.umass.edu/~shri/iPic.html&gt; ?

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

 

[Markus Kaufmann]

Axel Schwenke wrote:

Du kennst &lt;http://www-ccs.cs.umass.edu/~shri/iPic.html&gt; ?

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

 

[Alexander Peter]

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