Hallo allerseits, ich habe vor ein kleines Projekt mit einem Controller durch zu führen. Hauptbestandteil dabei ist viele Daten über einen UPD Socket zu verschicken. Die einzelnen UDP Packete haben etwa eine größe von 50 Bytes. Der Controller soll es schaffen weit über 1000 Telegramm zu empfangen zu bearbeiten und ca 50 Telegramm zu senden. Jetzt habe ich schon ein Test mit Controller durch geführt und musste natürlich fest stellen das dieser meinen Anforderungen nicht genügt. Um nicht noch maßig Zeit und Controller zu verschwenden würde ich gerne als nächstes einen Controller wählen der meinen Anforderungen genügt. Derzeit überlege ich einen Dimm Pc mit ca 200 Mhz zu nehmen. Allerdings habe ich nicht einen blassen schimmer ob der es bringt. Welches OS ist für solch eine Aufgabe geeignet. Bremsen mich Os wie yLinux oder WinCe 6.0 zu stark aus?. Würde mich sehr über eure Antworten freuen. Schöne Grüße
@ Tom (Gast) >verschicken. Die einzelnen UDP Packete haben etwa eine größe von 50 >Bytes. Der Controller soll es schaffen weit über 1000 Telegramm zu >empfangen zu bearbeiten und ca 50 Telegramm zu senden. Macht 50kB in RX Richtung. In welcher Zeit? Gleichzeitig? >Derzeit überlege ich einen Dimm Pc mit ca 200 Mhz zu nehmen. Allerdings >habe ich nicht einen blassen schimmer ob der es bringt. ??? So eine DIMM Speicherriegel kann man nicht ohen weiteres an einen uC anschliessen. >Welches OS ist für solch eine Aufgabe geeignet. Bremsen mich Os wie >yLinux oder WinCe 6.0 zu stark aus?. Naja, kommt drauf an was sonst noch gemacht werden soll. MFg Falk
Hallo, wow das ging aber jetz mal schnell. Vielen Dank schonmal für die Antwort -Macht 50kB in RX Richtung. In welcher Zeit? Gleichzeitig? Ja richtig. Dies muss aber nicht unbedingt gleichzeitig sein! mehr wäre mir aber lieber. Optimal wären 300KByte. Aber Achtung die Datenrate hängt stark von der größe der UDP Telegramme ab! D.h ein Controller der 1000KByte bei einer Datengröße von 1000 Byte schafft, schafft bei einer größe von 50 Byte eine wesentlich geringere Datenrate!!! -So eine DIMM Speicherriegel kann man nicht ohen weiteres an einen uC anschliessen. Meinte keinen Speicher sonder einen Controller der auf eine Checkkarten großen Karte sitzt und auf einen Dimm Sockel gesteckt werden kann wie z.B http://de.kontron.com/index.php?id=82&cat=34 -Naja, kommt drauf an was sonst noch gemacht werden soll. Schätzungsweise -10 Task -10 Queus -10 Semaphoren -4 UARTs mit Treiber -Webserver -ftp Server -logik sollte also noch ein bisschen Platz sein. Kennt jemand Performance Statistiken von senden und empfangen von UDP Telegrammen? Wie berechnet man so etwas Schöne Grüße
@ Andi (Gast) >-Macht 50kB in RX Richtung. In welcher Zeit? Gleichzeitig? >Ja richtig. Dies muss aber nicht unbedingt gleichzeitig sein! IN WELCHER ZEIT? 1 Sekunde oder eine Stunde? >http://de.kontron.com/index.php?id=82&cat=34 Nett. >Schätzungsweise >-10 Task >-10 Queus >-10 Semaphoren >-4 UARTs mit Treiber >-Webserver >-ftp Server >-logik Was sollen den die Task machen? Und was soll mit den 50kB UDP Daten passieren? Ich würde mal schätzen, dass so ein 133MHz Mini-PC mit schlankem OS das recht gut hinbekommen sollte. MFG Falk
>-Macht 50kB in RX Richtung. In welcher Zeit? Gleichzeitig? >Ja richtig. Dies muss aber nicht unbedingt gleichzeitig sein! Hi, >-Macht 50kB in RX Richtung. In welcher Zeit? Gleichzeitig? >Ja richtig. Dies muss aber nicht unbedingt gleichzeitig sein! 1 Sekunde. Sonst wäre es ja zu einfach >Schätzungsweise >-10 Task >-10 Queus >-10 Semaphoren >-4 UARTs mit Treiber >-Webserver >-ftp Server >-logik Was sollen den die Task machen? Und was soll mit den 50kB UDP Daten passieren? Task/Queus/Semaphoren sind für die UARTs und den eigentlichen Empfang und senden von Daten.(und noch ein paar andere Kleinigkeiten). Es werden Daten von UDP über die seriellen Schnittstellen und umgekehrt gesendet. Dabei erfolgt noch ein bisschen Konvertierung der Daten mehr aber nicht!! ftp und web sind mehr zur Konfiguration! Schöne Grüße
@ Andi (Gast) >Task/Queus/Semaphoren sind für die UARTs und den eigentlichen Empfang >und senden von Daten.(und noch ein paar andere Kleinigkeiten). >Es werden Daten von UDP über die seriellen Schnittstellen und umgekehrt >gesendet. Dabei erfolgt noch ein bisschen Konvertierung der Daten mehr >aber nicht!! Na wenn DAS ein 133 MHz Prozessor nicht gebacken kriegt dann weiss ich es auch nicht. Das ist 1 Paket/ms. Das sind 133000 Takte! Die UARTs sollten FIFOs haben, ist aber glaub ich heute selbstverständlich. >ftp und web sind mehr zur Konfiguration! Also Nebensache und kann eher langsam sein. MFG Falk
Hi, mhh ja rein Gefühls mäßig hätte ich das auch gedacht. Aber zum Beispiel der Beck IPC mit 96 Mhz http://www.beck-ipc.com/de/products/sc2x/index.asp schafft keine 1000 Telegramme pro Sekunde. Das Probelm ist nun, bevor ich mir eine neue Plattform aussuche würde ich mir gern recht sicher sein, dass es funktioniert. Schöne Grüße
@ Andi (Gast) >mhh ja rein Gefühls mäßig hätte ich das auch gedacht. Aber zum Beispiel >der Beck IPC mit 96 Mhz >http://www.beck-ipc.com/de/products/sc2x/index.asp >schafft keine 1000 Telegramme pro Sekunde. Naja. Was ist das denn für ein Prozessor? AFAIK ein 386er im Kleinformat. Kommt dann auch auf das OS und die restliche Software an, und, was denn genau mit den Paketen gemacht werden muss (volle UPD Verarbeitung, Prüfsummen etc.) Naja, die frage ist nicht einfach zu beantworten. >Das Probelm ist nun, bevor ich mir eine neue Plattform aussuche würde >ich mir gern recht sicher sein, dass es funktioniert. Wenn es soooo einfach wäre . . .;-) MFG Falk
Na dann mach mal.... 1000 Telegramme ist schon einiges, aber die Kenndaten spielen ja auch noch mit: Wie schnell ist denn Dein Ethernet ? Wer ist noch auf dem Segment unterwegs ? Wenn die Rahmenbedingungen nicht stimmen, dann kannst Du nicht sicher sein, dass es überhaupt so funktioniert. Lass Dich aber nicht entmutigen, vielleicht geht es ja doch.
Hallo Falk, du hast recht die Frage ist eben nicht ganz einfach zu beantworten! Welche Prozessor im Beck Ipc enthalten ist weiß ich leider nicht! Um das ganze mal ein bisschen einzuschränken. Sagen wir mal die CPU soll nach empfang eines UDP Telegramms dieses koppieren und sofort wieder über UDP verschicken. Um das UDP Protokoll an sich möchte ich mich eigentlich nicht kümmern. Das soll das OD machen. WinCE oder Linux. Schöne Grüße
@ Andi (Gast) >Um das UDP Protokoll an sich möchte ich mich eigentlich nicht kümmern. >Das soll das OD machen. WinCE oder Linux. Dann hilft nur eins. System kaufen und messen. MFg Falk
Hi, oje genau das wollte ich eigentlich vermeiden. Es ist nämlich ganz billig solch ein Board zu kaufen. Hat sonst noch jemand eine Idee? Schöne Grüße
Hallo, du könntest einen ARM9 benutzen. z.B. die von ATMEL. Sind für solche Spielereien auf alle Fälle ausreichend. Hier gibt es fertige Boards: http://www.taskit.de/produkte/portux/index.htm Am besten suchst du mal nach AT91RM9200 und schaust ob z.b. Linux für das Board portiert wurde.
Hi, ja gut. Aber reicht nun Arm mit 200Mhz und Linux für die Anwendung??? Das ist meine Frage. Schöne Grüße
es hängt auch viel von dem OS ab. Wenn man das umgeht und die Pakete selber verschickt schafft man auch 2000 pro s auf einem 386er mit 25Mhz (das sind die Eckdaten einer Customhardware die wir einsetzen). Mit WindowsCE auf X86 Basis klappt das auch ganz gut, aber auch hier gehts schneller wenn man nicht durch den OS IP Stack laufen muß. Wenn man kleine Pakete hat die in einen Ethernetframe passen und man sich nicht um Fragmentierung kümmern muß ist es auch nicht so schwierig die UDP Datagramme selber zu bauen.
@ Andi (Gast) >ja gut. Aber reicht nun Arm mit 200Mhz und Linux für die Anwendung??? >Das ist meine Frage. Die wird sie kaum jemand wirklich beantworten können. MfG Falk
Hallo JojoS, intressant!!!! Vielen Dank schonmal für die Informationen vor weg. Ich glaube das hat mir ganz schön geholgen: Dennoch habe ich nun einiege Fragen. -Was ist Fragmentierung -Woher weißt Du das?? -Wenn Packete selber verschickt und erstellt, dann muss es doch das OS auch unterstützen selber Packete zu verschicken uns zu senden oder? Wie programmiert man so etwas. Kennst Du Beispiele für zum Beispiel linux oder Win CE? -Was macht das Os dann noch, dass das direkte schicken so viel schneller ist Vielen Dank schonmal für die Beantwortung der Fragen und Schöne Grüße
@ Andi (Gast) >ja gut. Aber reicht nun Arm mit 200Mhz und Linux für die Anwendung??? >Das ist meine Frage. - 1000 x 50 Byte INPUT - work - 50 x 50 Byte OUTPUT Was machst du mit den empfangenen Daten ? Wenn das nicht soo viel ist reicht mit Sicherheit auch eine andere 32bit CPU mit weniger MHz. Du solltest vorher noch abklären ob du Fließkomma-Berechnungen benutzt und in welchem Umfang.
Hallo ARM, Fließkomma benötiege ich nicht. Alles nur Bit und Byte Operationen. Diese sollen wie schon gesagt im wesentlichen dann auf die UARTs gesendet werden. Was mich aber nun doch noch mehr intressiert ist die Wahl des OS. Derzeit hatte ich vor ein recht gut ausgebautes Os zu nehmen wie Linux oder WinCe. Damit mit ich zum Beispiel mit dem FTP bzw Web Server nicht so viel ärger haben. Warum ich immer noch ein bisschen zweifle ist wegen der BeckIpc geschichte. Wenn Jojos wirklich recht hat und durch das um gehen des Betriebssystems wesentlich mehr UDP Telegramme gesendet/empfangen werden können intressiert mich dies schon enorm. Die Frage ist nur wie macht man das? Schöne Grüße und Vielen Dank für die guten und hilfreichen Antworten
Hallo, ich habe keine guten Erfahrungen mit dem BeckPC. Die Programmierung war damals sehr eigen. Man brauchte ein uralt BorlandC und der Netzwerktest war dann auch nicht so berauschend (vor ~3Jahren). Falls du Linux benutzen willst, schau ob es ein BSP (Board Support Package) gibt und welche Anwendungen (ftp/www ...) schon mit bei sind. Linux/Windows Entwicklungsumgebung/Compiler .... . Falls du alles selber bauen musst, kann das sehr abendfuellend werden und ist einem Anfänger nicht zu empfehlen ! Wenn deine Wahl auf WinCE fällt, kannst du dich schonmal drauf einstellen für die Entwicklungsumgebung etwas Geld zu bezahlen.
Nachtrag: >Wenn Jojos wirklich recht hat und durch das um gehen des Betriebssystems >wesentlich mehr UDP Telegramme gesendet/empfangen werden können >intressiert mich dies schon enorm. Die Frage ist nur wie macht man das? Das kann ich mir beim BeckIpc gut vorstellen.
das UDP ist z.B. im Wikipedia einfach beschrieben. Ist eben 'nur' eine Struktur von Headerdaten die man richtig ausfüllen muß. Beim UDP gibt es ja kein Handshake oder irgendeine Fehlerkontrolle. Man bekommt höchstens auf IP Level eine Antwort das die Gegenstelle keine Daten auf Port xy erwartet wenn man ein System anfunkt wo keiner auf dem Port lauscht. Die Fragmentierung kann bei der Weiterleitung der Pakete entstehen, z.B. ist bei IP über ein Analogmodem die MTU kleiner als bei Ethernet und die grösseren Frames müssen dann in kleinere aufgeteilt werden. Aber bei reiner Ethernet Verbindung dürfte das keine Rolle spielen. Im OS steckt im IP Stack eine ganze Menge mehr, z.B. die Prüfung der Felder auf gültige Daten. Früher wurde das weniger gecheckt bis dann die ganzen berühmten 'Denial of Service' Attacken kamen die solche Lücken ausgenutzt haben. Dann gehen die Pakete ja evtl. noch durch eine Firewall, werden verschiedenen Protokollen angeboten, werden vielleicht mehrfach umkopiert usw.
Hallo, ich komme mit 64Mhz 32Bit CPU/100Mbit Netz bei einer TCP-Verbindung auf über 1MByte/sek. . Aja, Linux-Kernel 2.4.XX. . Ich sehe nur Probleme bei sehr wenig Speicher, schlechter Netzwerkhardwareanbindung oder einer sehr sehr langsamen CPU.
Was willste denn von einem OS ? Es sind im Wesentlich nur I/O operationen. Vorne an den UDP noch einen Header dranpfriemeln sollte nicht so schwer sein. Sollte eigentlich mit einem 20MHz AVR machbar sein. Der macht in einer milisekunde 20k operationen. Da sollte man doch noch 2 packete zu je 50 bye herumschieben koennen.
Weil es den Anforderungen von Tom nicht genügt ? > Was mich aber nun doch noch mehr intressiert ist die Wahl des OS. > Derzeit hatte ich vor ein recht gut ausgebautes Os zu nehmen wie Linux > oder WinCe. Damit mit ich zum Beispiel mit dem FTP bzw Web Server nicht > so viel ärger haben.
Hallo, also vielen Dank für die vielen Antworten @6623 -Ich werde auf alle Fälle ein Board mit fertigem OS nehmen, damit ich wenig äger haben und Threads, Queues, Semaphoren, Web, Ftp, DHSP, etc.... @Arm -"ich komme mit 64Mhz 32Bit CPU/100Mbit Netz bei einer TCP-Verbindung auf über 1MByte/sek. . Aja, Linux-Kernel 2.4.XX. . Ich sehe nur Probleme bei sehr wenig Speicher, schlechter Netzwerkhardwareanbindung oder einer sehr sehr langsamen CPU." Das schafft der Beck Ipc auch bei extrem großen Datenpacketen. Wie groß sind Deine Packete die Du verschickst? @JojoS Ok verstanden habe ich das jetzt. Was mir noch nicht ganz klar ist wie die Implementierung erfolgt. z.B. bei Linux oder Win Ce. Denn das Os wird ja keine Funktion haben wie send_raw_ip_packet oder? Wie kommt man also direkt an die Schnittstelle ran ohne über den TCP/IP Stack zu gehen. Kannst Du mie zum Beispiel für Linux ein Beispiel geben/Literatur/Web links Vielen Dank schonmal für eure Antworten und Schöne Grüße
bei WindowsCE muß man sich da mit NDIS und Miniport Treibern beschäftigen. Wir haben das von einer externen Firma entwickeln lassen und ich kenne die Details auch nicht. http://msdn2.microsoft.com/en-us/library/ms895493.aspx ist vielleicht ein Anfang, aber die CE Entwicklung ist nicht ganz trivial und man braucht ein Board Support Package vom HW Hersteller. Der sollte auch Tipps in Richtung Entwicklungsresourcen geben können. Mit Linux kenne ich mich so gut wie garnicht aus, da müssen dir andere weiterhelfen. Und es gibt noch Libpcap / Winpcap, das sind Paket Capture / Sende Funktionen für Linux und XP. Mit der C# Variante sharp-pcap baue ich gerade einen Analyzer für die schnelle zyklische Datenübertragung mit UDP. In der WinPCap Variante ist auch ein Beispiel für das Senden von UDP Daten.
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.