math-Coprozessor?

[yaro]

Hallo Leute,
ich brauche für mein Projekt sehr viele Berechnungen, die ich in kürzester Zeit rechnen muss. Ich verwende einen 8bit-AVR(die bekanntlich nicht die schnellsten sind). Auf einen ARM oder ähnliches umzusteigen ist schon zu spät.
Lohnt es sich, einen math-Coprocessor zu benutzen? Hat man dadurch große Ersparnisse?

Ich habe an sowas wie den hier gedacht: http://www.sparkfun.com/commerce/product_info.php?products_id=8129

Hat jemand Erfahrungen mit sowas gemacht? Oder kennt jemand vielleicht ein besseres Modell?

Gruß, Yaro

[Vitis]

die übertragung der zu rechnenden daten wird aufwändiger sein als
die eigentliche berechnung selbst denk ich

[s.o.]

Die Frage ist, brauchst du Floats oder Doubles?
Es gibt bei AVRs so eine Regel: Verwende nie Floats solange du nicht einen driftigen Grund dazu hast. Die meisten Berechnungen klappen auch gut mit Festkommazahlen - und dann ist der AVR verdammt schnell. Nur beim Teilen musst du aufbassen - das muss man noch über Software machen... Schneller als jeder Math-Prozessor für 20 $...

[MeckPommER]

Man müßte wirklich genau auseinanderpflücken, was berechnet werden soll und ob und wie man es optimieren kann. Manchmal kann man Zwischenergebnisse gezielt weiterverwenden, manchmal helfen lookup-tables oder einfach nur 4 Bier, nach denen einem einfällt das man bisher viel komplizierter als nötig gerechnet hat.
Trotzdem ist so ein Coprozessor eine Interessante Sache und es kann generell nicht schaden, wenn jemand sich sowas mal zulegt, anstöpselt und hier von seinen Erfahrungen berichtet.

Gruß MeckPommER

[Besserwessi]

Diese matho Coprozessoren sind auch nur µCs wie AVR oder gar PIC mit einem entsprechende Programm. Das wird also kaum schneller als es gleich im AVR zu machen. Wegen der Datenübertragung lohnt sich das ohnehin nur für kompliziertere Rechnungen wie die Winkelfunktionen oder einen Logarithmus, der dann parallel zum normalen µC arbeiten kann.

[Gock]

Natürlich gibt es CoP, die wesentlich schneller rechnen als die AVRs, ob der genannte dazu gehört und wieviel das ist kann ich auf den ersten Blick ins Datenblatt nicht erkennen. Das macht ohnehin keinen guten Eindruck auf mich, weil ich entscheidende Dinge nicht finden konnte, wie zB die Taktmenge pro Befehl und die Registerbreite. Zwar reden die von einem 32Bit Prozessor, im Instructionsummary werden 32Bit Werte aber in 4x8Bit aufgeteilt.
Wenn Du ein Beispiel geben kannst, was berechnet werden soll, könnte man versuchen abzuschätzen, ob das mit einem AVR noch Sinn macht.
Gruß

[yaro]

Ich brauche öfters Winkelfunktionen (sin, cos usw.), und muss auch ab und zu floats teilen und multiplizieren.
Lookup-Tabellen habe ich schon einige erstellt, klappt aber leider nicht für alle anwendungen. Optimirt habe ich auch schonn einge Menge, nur scheints, als ob das alles nicht genug sein wird. Ich komme im Moment mit der Leistung zwar noch hin, aber das sollte nicht mehr lange der fall sein, denn ich brauche immer mehr Winkelfunktionen, die ich kaum ersetzen kann, und die Genaugkeit der floats ist auch z.T. notwendig.

Der co.Prozessor hat eine 32bit Architektur, deswegen habe ich gehofft, dass er viel schneller ist.
Der bus sollte nicht so ein großes problem sein, über SPI kann es angesteuert werden. Großzügig gerechnet macht das dann ca. 30Takte pro übertragenes Byte, also ca 120T für ein float. Wenn man bedenkt, dass sin() 1500T braucht, scheint das schon etwas Zeitersparniss zu bringen (vor allem, weil man ja parallel noch rechnen kann).

Aber wie Gock schon meint, ist das mit der 32bit Architektur sone Sache...

Ich hoffe immernoch, dass jemand erfahrungen mit soeinem Ding gemacht hat, und mir vielleicht ein besseres exemplar empfehlen kann.

Gruß, Yaro

[Besserwessi]

Im daten blatt sind die Zeiten angegeben: ein Sin / Cos / Exp dauert etwa 100 µs, ist also etwa so schnell wie der AVR. Wobei mit das für EXP sogar eher langsam vorkommt, der geht normalerweise schneller als Sinus. Dafür kommen mir Funktionen wie ASIN usw relativ schnell vor.

Sicher wird es schnellere µCs geben.

[yaro]

Ich habe bisher leider nur langsamere gefunden.
Wie kann denn sowas eigentlich sein? das Ding arbeitet mit 30MHz mit
einer 32bit Architektur, und ist dabei genauso schnell, wie ein AVR mit
einer 8bit Architektur und 16MHz

[Besserwessi]

Mein Tip wäre ganz stark, das das ein PIC ist. Ein PIC mit 30 MHz ist halt mit einem AVR bei 8 MHz vergelichbar.
Die 32 Bit beziehen sich wohl auf das Fleißkommaformat, nicht auf den eigentlichen Prozessor.

Edit:
Von der Pinbelegung könnte das ein
dsPIC30F3012 sein. Damit wäre der Controller wirklich etwas schneller als ein AVR, aber nicht gerade viel. Das könnte auch erklären warum Arcsin usw. relativ schnell sind. Einen exp besonders langsam zu programmieren ist einfacher als einen genial schnellen Arcsinus.

[yaro]

Ich habe mich nochmal gründlich über diese ganzen Co-Prozessoren informiert, und bin zu dem Entschluss gekommen, dass sie kaum Zeitgewinn mit sich bringen. Wenn ich mehr Leistung brauche, werde ich einfach einen zweiten AVR anschließen (vllt sogar über einen Parallelprort), und mir keinen großen Aufwand machen, mich mit diesen Dingern zu beschäftigen.


Danke für die vielen und schnellen Antworten
Gruß Yaro

[ähM_Key]

Lookup-Tabellen habe ich schon einige erstellt, klappt aber leider nicht für alle anwendungen.

Hast du schonmal gestaffelte LUT probiert?
Das sieht dann in etwas so aus:

http://www.abload.de/img/zwischenablage-1vhn5.png

Und damit kann man schon recht hohe Genauigkeiten bei kleinem Speicherbedarf realisieren.

[yaro]

Sowas habe ich (aber nicht ganz so extrem) bei einer arccos-funktion angewendet.
Wie hast du die nötigen Werte dann rausgelesen? ich habe das mit Intervallschachtellung gemacht, das ging recht schnell.

Gruß, Yaro

[mwoidt]

Ich würd auch sagen am allereinfachsten ist es einen zweiten AVR zu benutzen. Du schreibst ja nicht viel über dein Problem da ist es auch etwas schweirig einen konkreten tip zu geben. Ich denke prinzipiell musst du dir erstmal überlegen ob ein AVR die komplette rechnung schafft und du nur das Problem hast das er sich um nichts anderes kümmern kann. In diesem Fall würde ich den Sensor oder was sonst die Datenquelle ist wenn möglich gleich an den AVR hängen der rechnet und dann nur die Ergebnisse übertragen. Wenn du die Aufgaben aufteilen willst und die Daten schnell zwischen einem AVR zum anderen übertragen willst würd ich mir auch einen Parallelport bauen, sofern der Datendurchsatz nicht zu hoch ist. Du musst immerhin alles in Software machen...
musst halt mal überlegen wieviel Rechenzeit die Datenübertragung im Vergleich zur Rechnung frisst. In der Regel lohnt sich sowas immer dann, wenn du zwei drei Werte zur berechnung brauchst, mit denen ewigkeiten rumrechnest und die Ergebnise zurückgibst. Wenn du einen Hohen Datendurchsatz mit einfachen Rechnungen hast wie Beispielsweise Bildverarbeitung, wird das so nicht Funktionieren

[Ceos]

wenn man die flankenzeiten der controller und die empfindlichkeit hernimmt, kommt man bei ca. 4 notwendigen rechenzyklen raus, um eindeutige pegelstände zu erkennen, das sind dann 0,5µS, also 2µS für 32bit bei 8bit parallel ... wenn man jetzt davon ausgeht, dass die prozessoren synchron takten, könnte man sich mit assembler ein paar ganz ausgefuchste mathematische funktionen schreiben, die quasi mehrkern berechnet werden

mh ... ich merke gerade dass ich mein assembler wieder auffrischen müsste

[Felix G]

Also der verlinkte Coprozessor könnte dem AVR zwar etwas Arbeit abnehmen...

aber wenn man floats wirklich schnell verarbeiten möchte, braucht man was anderes, wie z.B. einen CPLD auf dem man eine FPU implementiert. Das wäre dann extrem schnell, hat aber den gravierenden Nachteil, daß man dafür erstmal VHDL lernen muss.

[Vitis]

von vornherein intelligent programmieren wird
am effektivsten sein.
Einsparungspotential nutzen wo möglich, z.B.

Muss wirklich float verwendet werden oder reicht
Ganzzahl,
Mittelwertbildung über arrays in Zweierpotenzen (2/4/8/16 ...)
sodass man die Summe nur shiften muss.
Muss bei jedem Programmzyklus berechnet werden oder reicht alle
x Zyklen oder gar x Millisekunden

daraus folgt dann die Verwendung von State Machine, Timer etc.

Ich hatte mit der Rechenleistung des AVRs bisher nur einmal
Engpässe, da gings um verarbeitung von Bilddaten und es wurden
Megabytes/sec. durchgeschaufelt.

[Besserwessi]

Da dieser "Coprozesssor" auch nur ein µC ist, könnte man auch gleich das ganze Prorgamm auf solch einem µC laufen lassen. Ein 2 ter µC hilft nur dann, wenn man nicht zu viel Zeit für die Datenübertragung verliert.

[PICture]

Hallo!

Es ist genauso, wie der Besserwessi geschrieben hat. Fur mich wäre es am einfachsten, wenn der "Coprozessor" ("Co") und "Hauptprozessor" ("Haupt") einen externen Speicher (Puffer) nutzen würden.

Der "Haupt" könnte die alle Daten und die Funktion zum Berechnen in den Puffer reinschreiben und den "Co" wie ein Timer starten. Wenn es berechnet ist, könnte der "Co" sich per Interrupt melden und der "Haupt" das Ergebnis einlesen. Ich finde solche Lösung am schnellstem, da die Prozessoren paralell mit schnelstmöglichem Datenaustausch arbeiten sollen. So wurde es früher in PCs realisiert.

MfG

[yaro]

So ähnlich habe ich das auch realisiert. Ich habe einfach 2 ATmegas zur berechnung verwendet. Allerdings brauche ich keinen Puffer, sondern übertrage nie nötigen Daten direkt, rechne dann auf beiden Controllern und lese dann, nachdem der "Co-Prozessor" gerechnet hat, die Ergebnisse in den eigentlichen Prozessor ein.
Dass er fertiggerechnet hat, signalisiere ich mit einer Signalleitung.

Gruß, Yaro