Hi Leute, hab bei einem meiner Projekte, mit Winkelfunktionen zu rechnen, das ganze mach ich am mega8. Benutzte dazu FastAVR um zu sehen wie das in ASM abläuft. Im Anhang ein von Fastavr generierter Code. Dieser verschlingt jedoch bei 16 MHz Takt ca. 0.4 ms an Rechenzeit bis das Ergebnis ausgespuckt wird. Nun zu meiner Frage an die Profis: Gibt es eine ASM Routine die das bedeutend schneller schafft? Habe das auch mal mit Bascom probiert,hier gibt es Einbußen in der Genauigkeit der Berechnung , würde mir aber allemal genügen, jedoch gibt dieser Compiler kein ASM File aus.
kenne mich zwar mit asm ned so aus, aber ich hätte es mit ner tabelle gemacht in der du dann nachschaust, oder?
"Gibt es eine ASM Routine die das bedeutend schneller schafft?" Ja. Aber eher nicht auf dieser Art Prozessor. Die üblichen 8/16-bitter sind dafür nicht geschaffen. Einzige Alternative: Genug ROM und tabellengestützt arbeiten. Zumindest für Anfangswert. Evtl. reicht auch geringe Genaugkeit.
Hi für float-Zahlen wird das aber eine etwas große Tabelle :-) Ich zweifle das das bedeutend schneller werden kann. FP-Arithmetik ist nunmal nicht gerade die Stärke eines AVR. Matthias
Winkelfunktionen werden mit Reihenentwicklungen implementiert. Die werden teils deutlich schneller, wenn man schon mit einer passablen Näherung anfängt ohne gross rechnen zu müssen. Und das geht mit Tabelle sehr wohl (z.B. 12bit => 16bit, also 8KB). Ausserdem kann man mit weniger Termen arbeiten wenn die volle Genauigkeit nicht benötigt wird. Auch das macht es schneller.
Die Frage ist, brauchst du wirklich FP ? Reicht nicht auch Festkomma oder gar Integer-Arithmetik aus ? Dann lässt sich das einfach und blitzschnell mit einer relativ kleinen Tabelle erledigen. z.B Sin und Cos mit 1 Grad Auflösung und besser als 0,5% Genauigkeit passt in eine 360 Byte grosse Tabelle. Nur noch ein Viertel der Größe nämlich 90 Bytes brauchst du, wenn du die Symmetrien der Winkelfunktion bezüglich der X und Y-Achse ausnutzt. Kein Problem also auch für kleine AVRs. MfG Willi
@A.K. Keine ordentliche Approximation greift mehr auf Reihenentwicklungen zurück. Für den AVR wäre unter Umständen der Cordic gut geeignet, ist aber leider nicht sehr performant (nur Shifts und Adds). Ansonsten approximiert man die Zielfunktion in einem bestimmten Intervall (beim Sinus z.B. zwischen 0 und pi/2, der Rest ergibt sich durch Symmetrien) und geht über ein Polynom. Dieses bestimmt man z.B. mit Hilfe der MKQ oder der Minimax-Methode. Taylorentwicklungen (oder auch Maclaurin-) sind eher schlecht geeignet. Z.T. werden auch iterative Verfahren verwendet, dort besteht das Problem eines geeigneten Anfangswertes sowie der Konvergenz (vgl. Newton). Literatur gibt es zum Thema mehr als genug (vgl. Google "Function Approximation").
Weiss ich. Aber oft ist der Unterschied eher mathematischer als praktischer Natur. Ob nun Reihenentwicklungen, Iterationen oder optimierte Polynome - interessant sind hier die Verfahren, in denen jeder Folgeschritt/term weit weniger zum Ergebis beiträgt als der Vorgänger. Wenn man nur mässige Genaugkeit benötigt, mag u.U. auch ein sonst ungünstigeres Verfahren mit Hilfe von Tabelle(n) schneller sein, als das für volle IEEE Rechnung optimale. Erst recht, wenn bei einem 8bitter ein Tabellenzugriff hundert mal schneller ist als eine Multiplikation. Bei High-End Prozessoren ist das ja eher umgekehrt. Erkenntnisse aus der einen Welt sind für die andere nur bedingt brauchbar. Und grad beim das Problem des Anfangswertes ist eine Tabelle ungemein hilfreich.
Wenn Schritte von 1° und "Puntpositionen" von 255 x 255 ausreichen ist was als Ansatz im Anhang. Fehlen nur die Registerdefinitionen für X2 und Y2. Ist halt ein zugeschnittener Ausschnitt aus einer Elipsenfunktion. Ich schätze mal so ca. 100 Takte für eine Punktrotation. MfG Andi
Auf "schwachbrüstigen" Controllern wie den ATMegas weiche ich bei exzessiver Nutzung bestimmter Funktionen bei vergleichsweise hoher benötigter Genauigkeit oft auf externe Flashs mit Look-Up-Table zurück. Wenn man z.B. die M25Pxx nimmt, dann bekommt man für wenige Euro ein paar MBit speicher. Der MC muss nur eine kurze Adressrechnung ausführen und kann sich dann einen 16 Bit Wert angeln. Die Werte erzeuge ich am PC mit double-Genauigkeit, caste sie dann auf integer und schicke sie per RS232 dem Controller. Dieser programmiert sie in den Flash (muss ja nur einmal passieren). Das Prinzip ist in puncto Laufzeit/Genauigkeit unschlagbar, denke ich.
Ich verstehe nicht, warum sich Leute nie Gedanken über die real benötigte Genauigkeit und Geschwindigkeit machen. Immer gleich einfach drauflos programmieren ohne Sinn und Verstand. Dabei ist die gründliche Projektvorbereitung doch das A und O und hilft dann beim eigentlichen Coden massig Zeit zu sparen und Irrwege zu vermeiden. Also Gerhard, komm erst mal rüber damit, was Du eigentlich willst (welche Funktion und wie genau, wie schnell). Bzw. beschreib mal die Anwendung, z.B. für eine Display-Ausgabe währen ja die 0,4ms bereits massig ausreichend, da wären selbst 100ms noch schnell genug. Dann erst kann man auch konkret helfen und muß nicht rumraten. Peter
also wenn ich mal ein paar tipps weiter geben kann: - für einen sinus (und kosinus) brauchts du nur die erste 1/4 Halbwelle abspeichern (also bekommst du eine höhere auflösung) - dann rechne in kleineren einheiten und skalierten einheiten d.h. nicht in grad oder sowas sondern (um beim beispiel zu bleiben in 360*/(4 * 256) dann hast du eine auflösung von ca. 351m° mit dem selben aufwand und kannst schneller den index in der tabelle finden - rationale brüche für irrationale zahlen z.b. pi = 355 / 113 und dann gibt es noch gute approximations-algorithmen im netz wer suchet, der findet!
Hallo Leute, erstmal vielen Dank für die rege Beteiligung und die vielen brauchbaren Antworten, besonders an Andi K. für das angehängte ASM Programm. Werd unter anderem auch mal versuchen darauf aufzubauen. @Peter Dannegger ""Ich verstehe nicht, warum sich Leute nie Gedanken über die real benötigte Genauigkeit und Geschwindigkeit machen. Immer gleich einfach drauflos programmieren ohne Sinn und Verstand. Dabei ist die gründliche Projektvorbereitung doch das A und O und hilftdann beim eigentlichen Coden massig Zeit zu sparen und Irrwege zu vermeiden."" Dass ich mich nicht hingesetzt hab und mir keine Gedanken gemacht hab da bin ich nicht ganz deiner Meinung, Peter. Da mit dem "gleich mal Losprogrammieren" geb ich dir schon Recht, find ich aber auch nicht verkehrt, hab dadurch schon einiges zum Laufen gebracht, wo mir viele Leute sagten, "das geht sowieso nicht". ""Also Gerhard, komm erst mal rüber damit, was Du eigentlich willst (welche Funktion und wie genau, wie schnell)." Es geht wieder mal um mein Lieblingsthema "CNC Maschinen Steuerungen" Bin derzeit dabei die Nullpunktmitführung der X Y u. Z Achsen beim Schwenken der A bzw. B-Achse an 5 Achs-Fräsmaschinen zu programmieren. Läuft auch derzeit schon, jedoch nur zufriedenstellend im angestellten Betrieb und im 5Achs Simultan Betrieb mit geringen Vorschüben,um hohe Vorschübe simultan fahren zu können muss ich die Berechnung schneller durchführen können. Gruss Gerhard
@Gerhard: Und da sind Atmel-Controller drinne? Ich meine, nicht, das die schwachbrüstig wären, aber früher schon waren in CNC-Maschinen MC680XX drinnen. Und haben die CNC´s nicht eine spezielle Hochsprache? MfG Andi
Hi Andi, ""Und da sind Atmel-Controller drinne ?"" Jo, weil ich sie reingebaut hab... Es handelt sich hierbei um eine absolute Eigenbau CNC wo die Software am PC läuft (Mach2) und über den Druckerport die Servo-Endstufen mit den Atmels gesteuert werden. Gruss Gerhard
@Gerhard "Dass ich mich nicht hingesetzt hab und mir keine Gedanken gemacht hab da bin ich nicht ganz deiner Meinung, Peter." Sich keine Gedanken gemacht zu haben oder kein Wort darüber zu verlieren, ist für den Leser völlig gleichbedeutend, denn er sieht ja keinerlei Unterschied. Zuerst muß man wissen, welche Funktionen wie oft und wie genau benötigt werden Diese Fragen sind ja immer noch völlig offen, sollten aber bei der Programmplanung bereits geklärt worden sein. Für die Genauigkeit ist z.B. wichtig, ob die Berechnungen absolut oder relativ erfolgen. Bei relativ auf das vorherige Ergebnis bezogen kommt es nämlich zu einer Fehleraddition und es ist eine wesentlich höhere Genauigkeit notwendig. Und die Tabellenmethode ist direkt proportional zur Genauigkeit codeaufwendig, z.B. für 1° Genauigkeit nur 90 Byte groß. Auch kann man die Berechnungen auch vorher durchführen, die Wege sind ja bereits bekannt oder steuerst Du direkt über einen Joystick. Schließlich kann man auch rein mathematisch versuchen die Anzahl der rechenintensiven Schritte zu minimieren bzw. sie aus Schleifen herausziehen. Peter
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.