mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ENC28J60 Protokolle


Autor: Jay Jay (webchen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Leute!

Da mir das letzte Mal so schnell geholfen wurde, versuch ich es nochmal.

Ich arbeite im Moment an einem Uni-Projekt. Wir müssen ein Signal mit 
100kHz (so jedenfalls die vorgabe) abtasten, mit einem ADC (16 Bit).

Diese Daten müssen wir anschließend über eine Ethernet-Schnittstelle an 
einen Rechner schicken.

So sieht die grobe Struktur aus.
Wir haben einen Atmega64 und den Ethernet-Controller ENC28J60 
ausgewählt.

Das Problem das ich jetzt habe ist die Zeit. Da wir ja nur 8 Mhz als Clk 
auf der SPI haben, haben wir eine Geschwindigkeit für die Bytes 
vorgegeben.

Ich hatte vor die Pakete per UDP ins Netzwerk zu senden.

Jetzt mein Problem: Dadurch dass ich ja nur eine gewissen Zeit für die 
Übertragung an den Ethernet-Controller zur verfügung habe, muss ich Zeit 
einsparen. Meine Idee war, den Header schon bei der Initialisierung zu 
erstellen, da sich dort nix ändern wird über die Laufzeit. Während der 
Messung wollte ich dann nur noch die Bytes (2 ADCs * 2Bytes) an den ENC 
übertragen. So geht das ruck zuck.

Da ich ja kein Multithreading habe, geht ja alles nicht parallel.
Die Frage dieich jetzt habe: Das IP-Protokoll besitzt ja eine Checksum.
Wenn ich den Header vorher an den ENC schicke müsste ich die ja schon 
erstellen.

Kann ich das so einfach machen? Ohne dass ich weiß welche Daten ich 
haben werde ? Die länge des Datenpakets wäre fest, da ändert sich nichs.

Autor: Frank aus Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jay Jay,

ich weiss nicht ob ich dein problem richtig verstanden habe, aber wenn 
du am IP teil deines Datenpaket nichts änderst, dann kannst du den IP 
Header schon komplett vorbereiten und da du die länge Deines UDP paketes 
ja auch schon weisst, auch die IP-Header-CRC berechnen. Die UDP-CRC 
kannst du auch auf 0x0000 setzen, das ist zulässig und wird auch oft so 
gemacht siehe hier:

http://de.wikipedia.org/wiki/User_Datagram_Protoco...

Gruß aus Köln

Frank

Autor: Webchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah genau das wollte ich wissen.

Die UDP-Checksum kann ich also in dem Sinne außer Acht lassen.
Das erspart mir einiges an Arbeit.

Hab mir gestern auch nochmal die Protokolle richtig angeschaut.

Danke für die Antwort!

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde dir auch empfehlen gleich mehrere Datenpakete zusammenzufassen 
(falls zulässig). Nur weil du ganz schnell sendest, heißt es nicht das 
es so auch ankommt...
Ein Router/Switch/Netzwerkkarte gnadenlos weg was zu schnell kommt...

Autor: Webchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Letztendlich soll nur ein Router/Switch (Egal welche art von Verteiler) 
dazwischen hängen. Ist das dann auch ein Problem?

Also sollte ich lieber ein Datenpaket mit 30 Messwerten verschicken, als 
30 Datenpakete. Habe ich das richtig verstanden?

Autor: Frank aus Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja, das hängt ein bisschen von deiner Anwendung ab, wenn ich das 
richtig verstanden habe musst du nur 4 Bytes pro Messung verschicken.
Wenn ich mich jetzt nicht verrechnet habe hat aber jedes Paket 42 Bytes 
Header, das klingt für mich nicht wirklich effizient. Würdest Du jetz 
250 Messwerte auf einmal verschicken dann hättest du immer noch 42 Byte 
Header aber 1000 Bytes Nutzdaten. Ob das aber bei Deiner Anwendung aber 
Ok ist, kann ich nicht wissen, ich weiss nicht ob es bei Deinem Projekt 
zulässig ist, erst mal 250 Messungen zu sammeln.
Auf der anderen Seite kann ich mir aber auch nicht vorstellen das ein 
10MBit ENC in der lage ist einen halbwegs aktuellen Router/Switch so zu 
überfahren das der deine Pakete "wegwirft".

Gruß aus Köln

Frank

Autor: Webchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Effizienz wollte ich dadurch erreichen das ich den Header schon im 
Transmission Buffer ablege, bevor die ganze Messung gedurchgeführt wird.

Ob ich das Paket aus mehreren Werten zusammenfassen kann muss ich 
erstmal nachfragen. Kommt ja auch darauf an, wie "realtime-mäßig" die 
Daten gesendet werden müssen.

Ich denke man muss das einfach mal ausprobieren. Je nachdem wie schnell 
die Datenübertragung und die Abbarbeitung aller Algorithmen ist, muss 
ich mal gucken was ich für eine Abtastrate maximal schaffe.

Nach meiner Berechnung komme ich auf 50kHz. Bei 100 kHz vorgabe wärs 
natürlich umso besser ;)

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank aus Köln schrieb:
> Auf der anderen Seite kann ich mir aber auch nicht vorstellen das ein
> 10MBit ENC in der lage ist einen halbwegs aktuellen Router/Switch so zu
> überfahren das der deine Pakete "wegwirft".
Naja wie gesagt, da ist ja immer overhead dabei und die Gegenstelle muß 
die Daten ja auch annehmen.
Bei TCP gibt es ja extra ein Verfahren das sowas verhindern soll, da man 
eben i.A. keine Aussagen über Puffergrößen oder Leitungsqualität machen 
kann. Es kommt halt echt darauf an ob Daten halt verloren gehen dürfen, 
weil wenn man 100 Werte sammelt und das Paket geht dann verloren sind 
natürlich auch 100 Werte weg ;)

Autor: uz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn die fcs nicht stimmt sollte ein switch den frame schon in die tonne 
treten ;-)

Autor: Gebhard Raich (geb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wir haben einen Atmega64 und den Ethernet-Controller ENC28J60
>ausgewählt.

Schlechte Wahl,bei dieser Applikation wird, wenn überhaupt ,dem MC nur 
wenig Luft bleiben. Ein W5300 oder W5100 (Wiznet)würde einem die ganze 
Stack-Geschichte abnehmen und man könnte mit TCP fahren und die 
Datensicherheit wäre kein Thema.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gebhard Raich schrieb:

> Schlechte Wahl,bei dieser Applikation wird, wenn überhaupt ,dem MC nur
> wenig Luft bleiben. Ein W5300 oder W5100 (Wiznet)würde einem die ganze
> Stack-Geschichte abnehmen und man könnte mit TCP fahren und die
> Datensicherheit wäre kein Thema.

Aufgrund des etwas ineffizienten SPI-Verfahrens ist ein Wiznet bei UDP 
langsamer als ein ENC. Schneller erst wenn parallel, und dann besser ein 
neuerere Wiznet als der uralte 5100.

Aber 100KHz Abtastung mit 16 Bits, also summarum etwa 2MB/s, das 
überfordert sowohl AVR, den ENC28J60 wie auch seriell angebundene 
Wiznets und schreit nach einem 32-Bit Controller mit integriertem 
Fast-Ethernet Controller.

Autor: Frank aus Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kommt halt auf die Anwendung an, ob ich halbwegs "Echtzeit" brauche, 
dann muss ich für 250 Messungen 250 Pakete = 11500 Bytes über die 
Leitung schicken, oder ich darf sammeln und muss dann nur 1 Paket = 1042 
Bytes senden. Wenn ich richtig verstanden habe gibt es ein analoges 
Signal mit bis zu 100Khz was irgendwie  digital über die Leitung muss. 
Wir wissen allerdings nicht ob Daten verlorengehen dürfen, noch ob das 
ganze in "Echtzeit" geschehen soll, oder ob verlorene Daten evtl. sogar 
Interpoliert werden dürfen.
TCP hat im übrigen noch mehr Overhead, mal ganz davon abgesehen das wenn 
ein Paket flöten geht, muss ich es auch wieder neu anforden. ("Echtzeit" 
ade)

@uz
what on Earth is "fcs"

Gruß aus Köln

Frank

Autor: Gebhard Raich (geb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@prx

Ja stimmt, SPI ist nicht wirklich toll. Ich verwende den W5300 mit einem 
STRX710 ARM am 16Bit Bus und die schaufeln gemessene 4MByte/s im 
TCP-Mode in den PC,wobei der STRX noch viel Luft hat.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank aus Köln schrieb:

> what on Earth is "fcs"

Frame Check Sequence, die abschliessende CRC vom Ethernet-Frame.

Autor: Frank aus Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AaaaH, jetz weiss ich was du meinst, da gebe ich dir latürnich recht.

Gruß aus Köln

Frank

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber 100KHz Abtastung mit 16 Bits, also summarum etwa 2MB/s [..]

Nicht ganz. Ich komme da auf
100k Abtastungen/s *2B/Abtastung = 200kB/s
. Das macht dann etwa 1.6MBaud/s (Nutzdaten) auf dem SPI, das sollte mit 
einem 8MHz Takt und Hardware-USART/SPI/.. (sowas hat der Mega64 
hoffentlich) drin sein. Die UDP-Pakete muss man allerdings noch schön 
ansammen, sonst nimmt deren Header Überhand.

HF beim implementieren.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast schrieb:

> Nicht ganz. Ich komme da auf
100k Abtastungen/s *2B/Abtastung =
> 200kB/s
.

Hätte ein kleines "b" werden sollen. Aber die Posts deuten an, dass wohl 
2 Kanäle beteilig sind. Mit Overhead sind es dann 4Mbps, und das scheint 
mir beim ENC mindestens grenzwertig. Das SPI läuft ja nicht per DMA.

Ausserdem müssen die Daten erst einmal in den Controller rein, was 
vielleicht auch nicht so ganz automatisch passiert und zudem ein festes 
Zeitraster erfordern dürfte.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
beim Ethernet (nach IEEE802.3) hat ein Frame min. 64 Bytes, *100kHz 
macht also satte 6,4 MByte/s die über die Leitung gehen. Da kriegt auch 
ein PC dicke Backen wenn man das  per UDP durch den OS Stack schauffelt. 
-> Daten in Häppchen sammeln und Pakete á n Messwerte schicken.
Die UDP Checksum wird mittlerweile von modernen Netzwerkkarten selber 
berechnet, aber ein Enc oder Wiz wird das nicht draufhaben. Und Switches 
verwerfen die Pakete mit falscher Checksum auch nicht, soweit 'lesen' 
und analysieren die (einfachen) Switches garnicht, die ersten Bytes mit 
ZielMAC reichen dem Switch schon.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JojoS schrieb:

> Da kriegt auch ein PC dicke Backen wenn man das  per UDP durch
> den OS Stack schauffelt.

Ach herrje. Die Datenrate ist dabei weniger das Problem (100MB/sec TCP 
gefällig?), der konstante Aufwand pro Frame, also die Framerate, würde 
dabei überwiegen. Aber ein heutiger PC hätte da kein Problem.

Sonderlich tief ist der Stack bei UDP nicht.

> Die UDP Checksum wird mittlerweile von modernen Netzwerkkarten selber
> berechnet, aber ein Enc oder Wiz wird das nicht draufhaben.

Weshalb man sie wie oben schon geschrieben einfach weglässt.

> Und Switches verwerfen die Pakete mit falscher Checksum auch nicht,

Mit falscher UDP-Checksum nicht, mit falscher Ethernet-FCS hingegen 
schon.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JojoS schrieb:

> Die UDP Checksum wird mittlerweile von modernen Netzwerkkarten selber
> berechnet, aber ein Enc oder Wiz wird das nicht draufhaben.

Wie man's nimmt. Irgendeine Checksum-Geschichte die über die FCS 
hinausgeht hat der ENC durchaus an Bord. Wäre da nicht das 
Erratasheet...

Und der Wiznet hat gleich das komplette TCP/IP an Bord, also auch die 
UDP-Checksum - so er sie nicht auch weglässt.

Beim kleineren Wiznet mit zu wenig Puffer für genug Frames kann es 
allerdings passieren, dass er bei TCP jeden Frame gleich doppelt sendet. 
Um das uIP-Anwendern sattsam bekannte Acknowledge-Problem mit 
entsprechend unterirdischen Nettoraten zu umschiffen.

Autor: Michael L. (michaelx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jay Jay,

hast du deine Aufgabe schon mal richtig durchdacht, bevor du dich so in 
die Details hinein vertiefst!?

Du willst folgendes übertragen:

2*16 Bit x 100kHz Abtastrate = 3,2 MegaBit/Sekunde

Der ENC macht 10Base-T, d.h. sendet max. 10 MegaBit/Sekunde (und das 
auch nur in Full Duplex).

Zur Übertragung kommen pro Datenpaket auf der Ebene Ethernet 8 Byte 
Präambel+SFD sowie 18 Byte Protokoll-Overhead hinzu, und wenn weniger 
als 46 Byte Nutzdaten anfallen, wird auf eine Paketgröße von 64 Byte 
aufgefüllt. (Nachzulesen u.a. im ENC Datenblatt unter 5.1)

Auf der IP-Ebene fallen 20 Byte IP-Header sowie 8 Byte UDP-Header 
Protokoll-Overhead an.

Da braucht man nicht lange überlegen, um zu erkennen, dass dein Problem 
nicht die SPI-Schnittstelle zum ENC mit 8MHz Takt ist.

Und wenn man dann noch nachrechnet:

Man kann also bei 10Base-T (auch nur theoretisch!) maximal 17361 
Ethernet-Pakete versenden.

Außerdem ist es für den Durchsatz nicht sinnvoll, weniger als 18 Byte 
Nutzdaten zu versenden, weil sonst der Ethernet-Frame aufgefüllt werden 
muss.

-> Frank aus Köln
42 ist doch nicht die Antwort auf alle Fragen! ;-)

PS: Es zeigt sich mal wieder, wie wichtig eine umfassende Betrachtung 
des Zeitverhaltens es ist.

Autor: Jay Jay (webchen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oha!

Bis vorhin dachte ich dass ich das ganze noch hinbekomme ;)

Ich werde es einfach mal versuchen, und dann dementsprechend den Code 
versuchen so effizient wie möglich zu schreiben.

Je nachdem wie meine Abtastrate dann aussieht, muss sich wohl mein 
Betreuer damit zufrieden geben.

Ich mein, ich bin im 5. Semester Etechnik Bachelor. Bis auf paar 
einfache befehle habe ich mit MCs nicht viel gemacht. Da ich aber 
immerhin was vom Programmieren verstehe und dieses geniale Forum 
existiert, habe ich es immerhin schon bis hierher geschafft!

Danke an alle für die sehr anregenden Antworten.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.