Hallo Zusammen, ich habe mit einem STM32 und der Ethernet-Schnittstelle noch nicht so viel Erfahrungen. Ich habe eine Datenübertragung per UDP (mit HAL und LWIP) aufbauen können. Jetzt möchte ich aber nicht über UDP, sondern über ein anderes Protokoll nach IEC61850-9-2 senden. Hilfreich wäre eine Funktion, mit der ich einfach Rohdaten über die Ethernet-Schnittstelle senden könnte. Ich habe allerdings keine Ideen, wie ich das hin bekomme. Sämtliche Versuche sind leider fehlgeschlagen. Habt ihr eventuell ein Beispielprojekt für mich, oder andere Tipps, wie ich der Lösung etwas näher komme? Gruß Sören
Sören D. schrieb: > Jetzt möchte ich aber nicht über UDP, sondern > über ein anderes Protokoll nach IEC61850-9-2 senden. STM hat in seinen LWIP-Beigaben für viele LAN-Protokolle ein Beispiel-Programm mitgeliefert. Da solltest du ansetzen um das Rad nicht neu zu erfinden / erfinden zu müssen.
Sören D. schrieb: > Habt ihr eventuell ein Beispielprojekt für mich, oder andere Tipps, wie > ich der Lösung etwas näher komme? https://www.st.com/content/ccc/resource/technical/document/application_note/fd/5d/64/cf/7c/38/4c/30/DM00036052.pdf/files/DM00036052.pdf/jcr:content/translations/en.DM00036052.pdf
Hallo Zusammen, das aussenden habe nun mittlerweile über die low_level_output Funktion hinbekommen. Mein Problem ist jetzt aber, dass die Daten über die Ethernetschnittstelle nicht nach meinem gewünschten Timing ausgesendet werden. Mal dauert es länger, mal geht es schneller bis die Daten übertragen werden. Habt ihr Tipps, wie ich das Timing des PHY beeinflussen kann? Gruß Sören
Sören D. schrieb: > Mein Problem ist jetzt aber, dass die Daten über die > Ethernetschnittstelle nicht nach meinem gewünschten Timing ausgesendet > werden. Mal dauert es länger, mal geht es schneller bis die Daten > übertragen werden. Nenne mal konkrete Zahlen.
Ein Datensatz hat 128 Byte und ich muss alle 250µs einen Datensatz aussenden. Mal kommen die Daten aber nach 250µs, ein anderes mal nach 275µs, dafür das nächste Mal nach 230 µs... ich muss die 250µs aber sehr genau einhalten. Die low_level_output Funktion wird mit einem Timer aufgerufen, der sehr stabil läuft (mit Oszilloskop nachgewiesen), nur die Aussenden kommen wann sie wollen...
> ich muss die 250µs aber sehr genau einhalten
Das habe ich mir gedacht. Leier muss ich Dir mitteilen, dass du auf das
falsche Pferd gesetzt hast. Ethernet eignet sich nicht für exakte
Timings.
Wenn es hier um mehr als 1ms gehen würde, hätte ich gesagt, dass das nur
mit Glück klappen wird. Aber so wie du es brauchst sehe ich da keine
Hoffnung.
Sei froh, dass du nicht mehr mit anderen Teilnehmern an einem gemeinsam
genutzten Koaxial-Kabel hängst, sonst würde es noch schlechter laufen.
Sören D. schrieb: > Habt ihr Tipps, wie ich das Timing des PHY beeinflussen kann? Der PHY hat mit dem Timing das du meinst überhaupt nichts zu tun. Das Übertragen von Daten ist davon abhängig wieviele Teilnehmer dein LAN belasten. Daher gibt es keine Garantie für eine "getimte" Übertragung (auf einem normalen LAN). Der Ethernet Core im STM32 wird solange versuchen ein Paket zu senden bis er eine zeitlich Lücke findet, das kann mal früher oder auch mal "viel später" passieren.
Sören D. schrieb: > und ich muss alle 250µs einen Datensatz aussenden. Wenn du dies als Aufgabe gestellt bekommen hast dann zeigt der Auftraggeber damit dass er keine Ahnung hat was er verlangt.
Stefanus F. schrieb: > Das habe ich mir gedacht. Leier muss ich Dir mitteilen, dass du auf das > falsche Pferd gesetzt hast. Ethernet eignet sich nicht für exakte > Timings. Gewagte These. EtherCAT macht extrem schnelle Übertragung und genaue Timings über Ethernet. Auch alle anderen großen Ethernet Feldbusse wie Profinet oder Ethernet/IP haben einen "IRT" Modus mit präzisen Timings (Profinet IRT bzw. CIPSync). Gehen tut es schon. Wenn dann sind die meisten Stacks in den meisten System nicht dafür geeignet. Warum allerdings bei einem Bare-Metal programmierten STM32 solche Abweichungen auftreten ist schon merkwürdig. Oder ist da beim TE noch irgendein RTOS drüber? > Das Übertragen von Daten ist davon abhängig wieviele Teilnehmer > dein LAN belasten. In heutigen sternförmigen Netzwerken gibt es dieses Problem doch gar nicht mehr. Eine Übertragung bis zum Switch sollte immer möglich sein.
:
Bearbeitet durch User
>> Das Übertragen von Daten ist davon abhängig wieviele Teilnehmer >> dein LAN belasten. Cyblord -. schrieb: > In heutigen sternförmigen Netzwerken gibt es dieses Problem doch gar > nicht mehr. Eine Übertragung bis zum Switch sollte immer möglich sein. Aber der Switch ist nicht das Ziel der Übertragung.
Stefanus F. schrieb: > Aber der Switch ist nicht das Ziel der Übertragung. Völlig korrekt. Nun gehe ich aber nach diesem Satz: > dass die Daten über die > Ethernetschnittstelle nicht nach meinem gewünschten Timing ausgesendet > werden. davon aus dass schon an der Quelle und nicht am Ziel gemessen wird. Also wann der Controller tatsächlich sendet. Alles andere wäre hier in der Tat verschwendete Lebenszeit, wenn noch Latenzen der Switche und allgemeine Netzlast in die Rechnung kommen würden.
Sören D. schrieb: > Mal kommen die Daten aber nach 250µs, ein anderes mal nach > 275µs, dafür das nächste Mal nach 230 µs. wo kommen denn die Daten an? Bei einer Punkt zu Punkt Verbindung zwischen zwei µC wird auch Ethernet ohne Latenz übertragen, wenn da ein PC mit irgendeinem OS als Gegner steht wird es schwierig.
STM Apprentice schrieb: > Wenn du dies als Aufgabe gestellt bekommen hast dann zeigt der > Auftraggeber damit dass er keine Ahnung hat was er verlangt. Ich bin mein eigener Auftraggeber... Die Norm IEC61850-9-2 ist leider so definiert. Da kann ich nichts dran ändern. Zudem habe ich hier einige Geräte stehen, die mir zeigen, dass das ganze auch funktioniert. Cyblord -. schrieb: > davon aus dass schon an der Quelle und nicht am Ziel gemessen wird. Also > wann der Controller tatsächlich sendet. Ich kann leider nur am Ziel messen. Ich gehe von dem STM aber direkt in einen PC, da hängt nichts anderes dazwischen. Johannes S. schrieb: > wo kommen denn die Daten an? Bei einer Punkt zu Punkt Verbindung > zwischen zwei µC wird auch Ethernet ohne Latenz übertragen, wenn da ein > PC mit irgendeinem OS als Gegner steht wird es schwierig. Zur Zeit an einem PC. Wenn ich ein anderes vorhandenes Gerät nehme und die Zeiten messe, kommen die Daten immer nach 249,9µs. Ohne Abweichungen. Schließe ich dann meinen STM an, kommen die Daten wie sie wollen.
:
Bearbeitet durch User
Hast du schon in Erwägung gezogen, deine Daten mit Zeitstempeln zu bündeln und früher zu senden, als die vom Empfänger gebraucht werden? Dafür gibt es fertige Protokolle.
Sören D. schrieb: > STM Apprentice schrieb: >> Wenn du dies als Aufgabe gestellt bekommen hast dann zeigt der >> Auftraggeber damit dass er keine Ahnung hat was er verlangt. > > Ich bin mein eigener Auftraggeber... Die Norm IEC61850-9-2 ist leider so > definiert. Da kann ich nichts dran ändern. Na wenn du dein eigener Auftraggeber bist, warum hast du dann eine Norm gewählt, die solche extremen Timing-Anforderungen hat? > Ich kann leider nur am Ziel messen. Ich gehe von dem STM aber direkt in > einen PC, da hängt nichts anderes dazwischen. Wie misst du denn die Zeiten auf dem PC? Hoffentlich mit Hardware-Zeitstempelung unter Verwendung eines Ethernet-Ports, der das kann. > Johannes S. schrieb: >> wo kommen denn die Daten an? Bei einer Punkt zu Punkt Verbindung >> zwischen zwei µC wird auch Ethernet ohne Latenz übertragen, wenn da ein >> PC mit irgendeinem OS als Gegner steht wird es schwierig. > > Zur Zeit an einem PC. Wenn ich ein anderes vorhandenes Gerät nehme und > die Zeiten messe, kommen die Daten immer nach 249,9µs. Ohne > Abweichungen. Schließe ich dann meinen STM an, kommen die Daten wie sie > wollen. Wie verwendest du denn LWIP? Direkt auf der untersten Lowlevel-Schicht ohne RTOS mit separaten Threads?
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.