Hi, ich suche für ein Projekt zur Ansteuerung von mehreren Motoren ein Entwicklungsboard, das echtzeitfähig ist und mittels Timern die Regelung zu festgelegten Zeitpunkten berechnet. Bis jetzt habe ich das mit einem Arduino Mega gemacht, der über die Timer ja sehr gut für zeitlich äquidistante Berechnungen von Regelungen zu nutzen ist. Gut wäre ein Entwicklungboard, das aber ein wenig mehr Geschwindigkeit bietet und am besten direkt einen Ethernetport zur Kommnukation mit dem Rechner bereitstellt.
Xmos kein FPGA sondern eine auf Echtzeit getrimmte MCU mit mehreren Kernen. Die Boards sind auch nicht so teuer, um die 100-200€.
Echtzeit und Ethernet sind <normalerweise> zwei Dinge, die sich beißen, wie gesagt, NORMALERWEISE. Ist ja nicht so, dass sowas in der Austomatisierungsinsudstrie nicht gemacht wird. Der Grund sind die Buffer, die im Media Access Controller sind. Und ehrlicherweise währe ich bei Ethernet+Arduino+Echtzeit sehr skeptisch. Willst du das Ethernet nur als Punkt zu Punkt quasi als Cross Over oder über ein Netzwerk? Denn Ethernet beschreibt nur OSI Layer 1 (Physical Attachment) und OSI Layer 2 (Media Access Control). Ein Netzwerk ist schon etwas mehr und noch mehr Buffer. Ich denke mit Standardroutern wird man keine Echtzeit schaffen. Echtzeit meint ja nicht "so schnell wie möglich" sondern "determinisitisch zu einem bestimmten Zeitpunkt". Daher letztlich auch die Frage, mit welchen Zeitkonstanten sich dein Prozess abspielt - im Millisekundenbereich oder reichen auch Sekunden? Um richtung Echtzeit zu kommen, wirst du etwas brauchen, wo du das Verhalten der Buffer beeinflussen kannst, oder dir jemand einen Stack anbietet und das garantiert. Willst du es Hobbymäßig oder beruflich machen? Schau mal bei TI und in deren e2e Forum vorbei und frag da mal, ob die was für dich haben.
Schau Dir mal die Nucleo-144 (F4/F7)Boards an: - Phy on board - Mac on chip - Ordentlich RAM/Rechenpower und DSP Befehle
Jasson J. schrieb: > Echtzeit meint ja nicht "so schnell wie möglich" sondern "determinisitisch > zu meint ja nicht "so schnell wie möglich" sondern "determinisitisch zu > einem bestimmten Zeitpunkt". > Daher letztlich auch die Frage, mit welchen Zeitkonstanten sich dein > Prozess abspielt - im Millisekundenbereich oder reichen auch Sekunden? Das ist der Knackpunkt. Ohne eine konkrete Zeitangabe und ohne die Art der Regelung zu kennen, kann man da wenig empfehlen. Ist das eine reine Spielerei oder eine professionelle Anwendung? Dann kann sich ja auch schon der Einsatz eines EtherCAT Stacks o.ä. lohnen.
Jasson J. schrieb: > Echtzeit und Ethernet sind <normalerweise> zwei Dinge, die sich beißen, > wie gesagt, NORMALERWEISE. Schon lange nicht mehr. Eigentlich ziemlich genau seit dem Moment, seit dem es nicht mehr zu Kollisionen auf dem Medium kommen kann. Sprich: seitdem man Switches einsetzt. > Ist ja nicht so, dass sowas in der Austomatisierungsinsudstrie nicht > gemacht wird. Eben... > Denn Ethernet beschreibt nur OSI Layer 1 (Physical > Attachment) und OSI Layer 2 (Media Access Control). Genau... > Ein Netzwerk ist > schon etwas mehr und noch mehr Buffer. Hahaha... Es KANN natürlich mehr sein. Aber es MUSS *NICHT* mehr sein. Das genau ist der Punkt. Da man ja die volle Kontrolle über alle Geräte eine Netzwerksegments hat (zumindest haben sollte...), kann man die Sache sehr leicht Richtung Echtzeit trimmen. Lustigerweise sind hier primitive Consumer-Switches (oder die völlig überteuerten Industrieversionen der exakt gleichen Hardware) viel besser geeignet als schweineteuere managebare L3-Switches. Die sind nur als Border-Gateway zum Echtzeitnetz brauchbar, das dafür dann aber wiederum sehr gut. Denn damit hat man die Möglichkeit, die Kommunikation zwischen dem "normalen" und dem Echtzeitnetz sehr streng zu reglementieren. Das kann bei einem hoch ausgelasteten Echtzeitnetz dann natürlich dazu führen, dass es "Verbindungsprobleme" gibt. Weil Pakete Richtung Echtzeitnetz einfach weggeworfen werden müssen, um die garantierte Zykluszeit innerhalb des Echtzeitnetzes zu sicherzustellen. > Ich denke mit Standardroutern wird man keine Echtzeit schaffen. ROUTER im Echtzeitnetz will sowieso niemand und braucht auch niemand. An der Grenze zum "normalen" Netz sind sie allerdings in vielen Fällen ein denk- und brauchbarer Ersatz für teuere L3-Switches...
> ROUTER im Echtzeitnetz will sowieso niemand und braucht auch > niemand. An der Grenze zum "normalen" Netz sind sie allerdings in vielen > Fällen ein denk- und brauchbarer Ersatz für teuere L3-Switches... Das Stimmt so nicht. So lange keine Last darüber läuft ist die Latenz relativ gering und auch die Schwankungen. Sobald aber Pakete darüber laufen ändert sich dies. Ohne eine Regel wer Vorfahrt hat kommen die Pakete unbestimmt an oder auch gar nicht wenn die Lebenszeit überschritten wurde. Ethercat, AVB und andere Video/ Audio Streams brauchen schon eine Reservierte Bandbreite und garantierte Latenz. Sonst kommt es zu Drop Outs im Signal. Da xmos einen AVB Stack zur Verfügung stellt sind sämtliche Mechanismen die hierzu nötig wären schon vorhanden. PTP usw. Die xmos MCUs sind eigentlich ideal für alles wo es auf "Echtzeit" ankommt. Diese besitzt mehrere Kerne welche über Channels kommunizieren. Man kann Sie sogar Verlinken (Xlink). Es ist eben ein Zwischenschritt zum FPGA. Für die meisten Anwendungen durchaus praktikabel da sie sich in C programmieren lassen. Wer beide Welten Arm u. xmos verbinden möchte dem sei das xcore-XA empfohlen. Das Board besitzt einen J-Link OB für den ARM und auch einen Debugger für den Xmos.
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.