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.
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_Protocol#UDP-Datagramm Gruß aus Köln Frank
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!
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...
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?
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
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 ;)
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 ;)
wenn die fcs nicht stimmt sollte ein switch den frame schon in die tonne treten ;-)
>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.
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.
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
@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.
Frank aus Köln schrieb:
> what on Earth is "fcs"
Frame Check Sequence, die abschliessende CRC vom Ethernet-Frame.
AaaaH, jetz weiss ich was du meinst, da gebe ich dir latürnich recht. Gruß aus Köln Frank
> Aber 100KHz Abtastung mit 16 Bits, also summarum etwa 2MB/s [..]
Nicht ganz. Ich komme da auf1 | 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.
Gast schrieb:
> Nicht ganz. Ich komme da auf1 | 100k Abtastungen/s *2B/Abtastung = |
2 | > 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.
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.
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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.