Rechenleistung von Mikrocontrollern

Erstmal wieder ein Hallo! an alle,

ich überlege gerade mich ein wenig in Mikrocontroller einzuarbeiten (Es geht mal wieder um meinen Roboterarm). Da ich weder Ahnung noch irgendein Gefühl für Controller habe, hier meine Frage zur Rechenleistung:

Die Frage wäre nun, ob so ein Mikrokontroller leistungsstark genug ist um zB eine Spline-Interpolation zu berechnen. Die Splinefunktionen selber würde ich manuell berechnen und dann den Controller damit füttern.
Der Controller müsste jetzt einen Zeitwert in ein Polynom 5.Grades (oder noch höher) einsetzen, mit einem Referenzwert vergleichen und je nach Ergebnis zwei Ausgänge high oder low setzen (-> Schrittmotorsteuerung).

Ansich wahrscheinlich kein Problem, bloß:
Das müsste er nun für 5-6 solcher Funktionen und ca. 500 Mal in der Sekunde durchführen, also ca. 3000 Berechnungen / Sekunde. Es wäre wichtig, dass der Controller die vorgegebenen Zeiten um die Ausgänge zu setzen ( 2ms für 5 Berechnungen bzw. 10 Ausgänge) genau einhält, da sonst der ganze Aufwand mit Splines zu rechnen für den A.... wäre.
Ideal wäre natürlich, wenn noch etwas Luft wäre für Erweiterungen (z.B. Eingänge zwischen den Taktzeiten noch abzufragen etc.)

So, was meint Ihr, packt ein Mikrokontroller das, oder eher nicht?


Gruß hounter

Maximale Taktrate: 20MHz-->2*10^7 Instruktionen pro Sec.
Dann hast du für jeden Prozess 6666 Instruktionen. Nein, mit den 6666 instruktionen kommste nicht weit... 1 Teilen schluckt dir schon fast 500-1000 Instruktionen,.

Bild hier  
Wenn du dich auf das beschränkst, und nur mit festkommazahlen arbeitest, hättest du vielleicht noch eine chance. Aber mit dem "einfachen Ansatz" sollte es von der rechenleistung her gehen.

Die Kunst im MCU Programmieren ist nicht wie im informatikstudium möglichst genau und universell, sondern möglichst einfach. Will sagen, keine Gleitkommazahlen, mehrdimensionale Arrays mit vorsicht genießen, malloc und free mehr als hassen...

okay...

nun, ein Approximationsverfahren, das ich anwenden könnte, würde Potenzieren und Addieren und würde mit Festkommazahlen (2Stellen hinterm Komma) auskommen. Aber so wie das aussieht würde das auch nicht reichen #-o

Wäre es schwierig, mehrere uC's parallel arbeiten zu lassen? z.B. über eine gemeinsame Clock-Leitung und jedes uC übernimmt eine oder zwei Achsen...

Danke schonmal!

Die Geschwindigkeit hängt sehr von der Wahl des Controllers ab. Wegen der Einordnung nehmen ich man einen AVR8, also z.B. Mega32 oder ähnliches an.
Mit Festkommazahlen sollte das noch gehen, mit Fließkomma wird es wohl knapp, könnte aber auch noch gehen. Eine Division wird man dabei aber unbedingt vermeiden müssen. So wie es aussieht kommt da auch keine echte Division vor, nur die Konstante 1/h^2. Für ein Polynom 5 ten Grades braucht es rund 10 Multiplikation und 6 Additionen

Im günstigsten Fall dauert eine 16bitx16 bit multiplication knapp 20 Zyklen, also rund 1 µs bei 20 Mhz Takt. Bei 32 Bit solle es etwa das 4 fache sein. Bei Programmierung in C kommt da aber noch einiges an Zeit dazu um die Daten ins Ram und wieder zurück zu schaufeln. In ASM sollte man also ein Polynom 5 ten grades in rund 250 Zyken bei 16 bit oder 1000 Zyklen bei 32 Bit berechnen können. In C wird es etwas länder dauern. Im zweifelsfall könnte man das relativ leich ausprobieren: einfach mal mit WINAVR übersetzen und im Emulator durchlaufen lassen.

Die Angabe 2 Stellen hinter dem Komma sagt nicht viel aus, wichtiger wäre die Frage ob man 16 / 24 oder 32 Bit braucht.

Ein aufteilen auf mehrere Kontroller wäre eventuell möglich. Immhin sind die kleineren Controller (z.B. Mega48) auch nicht langsamer. Es kommt dann aber einiges an extra KOmmunikation dazu. Dafür kann man aber natürlich mehrere gleiche Teile (?Platinen) relativ einfach entwickeln.

Zitat:

---

Zitat von hounter

Wäre es schwierig, mehrere uC's parallel arbeiten zu lassen?

---

Propeller? (Ist ein Mehrkerncontroller. Wahren das ges. 164 Mhz in gleichem Gehäuse wie M32??? Oder hab ich nen Knick im Gedächnis?)

Mit der SuFu wirst du da mehr Infos finden.

Gruß

öha ... die operation auf die cogs verteilen wird aber auch ne
herausforderung und dann noch klaro in asm, weil spin
ne ganze ecke langsamer ist, sprich den propeller
dann ziemlich bremst.
ich vermute es wird dann eher in arm7 richtung gehen,
eher noch stärker.

Wenn es nur um die Berechnung der Polynome geht, dann sollte das ohne weiteres zu schaffen sein. Für ein einfaches Polynom 5 ten Grades braucht GCC ca. 300 Zyklen bei 32 bit Inetegern. Das ist weniger als oben gedacht, denn es sind tatsächlich nur je Multiplicationen und Additionen. Bei Festkomma käme wohl noch einiges an Shifts dazu, aber auch das sollten bei weitem keine 6300 Zyklen sein.

Eine der leicht übersehenen Beschränkungen ist das relativ knappe RAM. Für große Tabellen mit Werten ist da nicht viel Platz.

Vielen Dank erstmal für die Hilfe!

okay, also wenn ich das jetzt so richtig sehe, ist es auf jeden Fall kritisch.

Bin jetzt am überlegen, für jede Achse einen einfachen Controller mit ein paar Standardfunktionen (alá "fahre von Punkt A nach Punkt B und zurück) zu verwenden und das ganze über einen "Großen" zu koordinieren. Speziellere Funktionen des Roboterarms könnte dann auch der Große mit einem langsameren Takt übernehmen.
Hätte zumindest den Vorteil, dass ich mich langsam in die Microcontrollerwelt vortasten könnte und erst nach und nach einen bzw weitere Controller zuschalte.

Oder sehe ich als "Vollblutmechaniker" das schon wieder aus dem falschen Blickwinkel? Ich hab irgendwie das Gefühl, dass ich da noch in zu einfachen Strukturen denke...

Der Ansatz erst mal einen Controller für eine Achse zu planen ist nicht schlecht. Da hat man ein einfacheres Projekt. Für den Anfang ist das auch schon allemal genug.

Die Rechengeschwindigkeit kann man aber auch ohne Hardware schon mit dem Simulator abschätzen. Einfach mal den Zeitkrischen Teil Programmieren und den Simulator Zyken zählen lassen. So knapp scheint das hier von der Rchenzeit gar nicht zu sein. Das könnte eventuell sogar noch mit Fließkommazahlen gehen.

jo, und die achsencontroller dann per bus mit daten versorgen ...
i²c oder usart oder gar spi sollte gehen für überschaubare entfernungen

Zitat:

---

jo, und die achsencontroller dann per bus mit daten versorgen ...

---

öhm, wie gesagt, ich bin Anfänger...
ich dachte eigentlich mehr daran, jedem Achscontroller einfach mehrere Varianten (verschiedene Splines für verschiedene Verfahrwege) einzuspeichern und durch den Verwaltungscontroller nur zu steuern, welche Variante als nächstes ausgeführt werden soll. Also keine Datenübertragung oder Ähnliches. Dafür müsste ich halt bei jeder Umprogrammierung des Arms alle Controller neu programmieren :/ Aber das wäre glaub immer noch einfacher als gleich mit bus einzusteigen...


Ich glaub ich bestell mir einfach mal eine Grundausstattung an Elektronik (kostet ja nicht die Welt...) und sobald ich mal drin bin fang ich nochmal von vorne an meine Steuerung zu gliedern...


Gruß hounter

Es würde schon sinn machen, das der Controller für die Achse den Spline (oder Polynom) auswertet und der Hauptcontroller die Polynomparameter rüberschickt. Die Ganze Kurve ins Flash zu schrauben macht eher weniger sinn.

das ist richtig, aber es wird dann halt eher weniger zeitkritisch,
weil der Master sich dann nur noch ums Rechnen und Verschicken
kümmern muss. Die Slaves steuern dann die Motoren
an und fahren auf die vorberechneten angewiesenen Werte.