Tachesacht,
da ich die ganze Zeit auf ner long mit Überläufen zu kämpfen habe,
dachte ich mir ich spendiere meinem Atmega2561 einfach nen 40Bit
Datentyp anstelle der 32Bit des longs. Dann kam eine Weile Grübelei und
jetzt bin ich auf dem Stand das ich da ja im Prinzip dem Teil nen neuen
Assembler Befehl beibringen müsste. Sprich einem Assembler Befehl
Maschinencode zuordnen?!
Wollte deswegen mal rumfragen ob es da auch ne einfachere Variante gibt
an die ich gerade nicht denke bzw. ob mir jemand nen Tipp oder Lektüre
zum beibringen geben kann?! Wäre großartig!
Danke schonmal im Vorraus,
Icke_Wa
Ähem, Atmega2561?
Seit wann kann der auf Assemblerebene denn mit 32Bit-Daten umgehen?
In welcher Sprache programmierst Du? Assembler zu 99,99% nicht...
Such dir für diese Sprache eine entsprechende Mathebibliothek.
Vieleicht liegen die Überläufe nur an einer ungeschickten
Aneinanderreihung der Operationen.
Was willst du ausrechnen?
Wie sieht dazu dein Code aus?
Wie ist der Wertebereich der Variablen?
Nene ich programmiere das Ding braf in C, aber beim grübeln hab ich den
Ratschlag meiner Mathelehrerin vergessen "Denk nicht immer so
kompliziert!"
Mathebibliothek klingt ganz gut. Durchstöber gleich mal die einfache
Mathe library.
Wie schauts sonst aus mit structs wo man selber Bits zuweisen kann? Hab
da hier gerade was gefunden. Das klang irgendwie auch ganz vernünftig.
www.mikrocontroller.net/topic/148581
nen 64er Int dauert zu lange. Ich bin in der Bearbeitungszeit ganz gut
limitiert und 64Bit dauern zu lange
Gerechnet wird da einiges.
Das Problem ist, dass ich einen Wertebereich von 2Vorkommastellen und
bis zu 7Nachkommastellen abdecken muss. Wenn ich das so skaliere dass
ich da nichts verliere, werden die Zahlen einfach so riesig, dass bei
der erst besten Multiplikation schon mein signed long überläuft.
An ungünstigen Programmablauf kann ich da irgendwie nicht so richtig
glauben. Der Zahlenbereich ist einfach zu krass.
Hm das klingt ja schonmal mehr als einfach nur perfekt. Wenn ich dadurch
im zeitlichen Rahmen trotz 64BIt wäre, wäre das perfekt ... nur komm ich
mir schon wieder so dumm vor, dass ich mich schon wieder heulend in die
Ecke verkriechen, und über meine Zukunft nachdenken könnte. Wie füge ich
den ein .s file hinzu? in deinem testfile z.B. kommt ja sowas wie nen
include nich vor und wenn ich die File einfach in irgend nen
Ordnerschupse weiß der Compiler ja immernoch nich dass das Ding
existiert.
Danke für die Hilfe, aber ich brauch noch mehr ;)
Icke_Wa schrieb:> Wie füge ich> den ein .s file hinzu?
Linke Seite unter Source Files markieren und dann rechte Maustaste.
Dann Add Existing Source File.
hm also im Prinzip einfach die Datei zu dem anderen ins Projekt werfen?
Dem Vertrau ich irgendwie nicht. Da hab ich jetzt so nen graues Fenster
wie als ob ich was zum drauf rumklicken für Windows schreiben wollen
würde.
Ist aber glaube ich eh so ne Sache mit der Nutzung dieses Codes. Mache
grade nen Praktikum und da sollte ich vielleicht nichts reintippern für
was die Firma später wegen copyright und plagiat bla bla auf die Finger
bekommt...
Für einen Frequenzmesser ist eine schnelle Rechnung unnötig.
Man will ja keinen Augenkrebs kriegen von dem ständigen Geflackere.
Eine Anzeigerate von 2..5 Meßwerten/s ist ergonomisch.
Wichtiger ist da eher die Codeeinsparung von ~7kB.
Damit paßt der Frequenzmesser bequem in den ATtiny2313.
Peter
Nochma ne Zwischenfrage bevor ich mir weiter dir Birne darüber
zerbreche. Peter meinte der standart AVR-GCC compiler wäre da nicht so
fit. Gilt das auch für den AVR IAR C/C++ Compiler??? Den benutz ick
nämlich hier :/
Hallo Peter,
ja richtig, deshalb verwende ich bei diesem Projekt [1] auch eine
Messzeit (Torzeit) von 0,5 - 0,75 Sekunden.
Deine 64Bit-Lib hat bei mir den Anstoß gegeben, die Ausführungszeiten
der verschiedene 64Bit-Libs und der 64_32Bit Routinen zu untersuchen und
ich hatte mir dafür eine Testumgebung [2] programmiert.
So war es für mich als mathematisch geprägter Programmierer sehr schön
zu sehen, was wie schnell funktioniert.
Einzug gefunden habe diese Erkenntnisse in der Berechnung der Frequenz
Tuning Word (ftw) bei verschiedenen DDS Bausteinen: AD9834, AD9851 und
AD9951.
Links
[1] Beitrag "Reziproker Frequenzzähler+ Optimierte 64bit uint Routinen"
[2] Beitrag "Re: Stack Überschreiber beim Rechnen mit uint64_t"
Hallo Icke_Wa ,
es ist nicht der avr gcc Compiler, sondern die 64Bit Bibliothek, die wir
mit dem Assembler 64Bit-Lib ersetzen !
Zum /AVR IAR C/C++ Compiler/ kann ich nichts beitragen, habe nur noch
einen Keil C51 da.
Icke_Wa schrieb:> Gilt das auch für den AVR IAR C/C++ Compiler???
Nein, auf keinen Fall.
Meine Assemblerdatei läuft nur mit dem AVR-GCC. Sie benutzt dessen
Registerzuweisung und Funktionsnamen.
Peter
hm gut zu wissen. Dann kann ich mir die Frage ja spahren warum ich das
auf biegen und brechen nicht hinbekomme :P Stellt sich nur die Frage
nach der Alternative...
Icke_Wa schrieb:> Stellt sich nur die Frage> nach der Alternative...
Hast Du überhaupt festgestellt, daß beim IAR 64Bit zu langsam ist und
wie?
Was mußt Du berechnen und wie schnell?
Peter
Jop dasses zu langsam ist habe ich bereits festgestellt.
Ich berechne ne Regelschleife nach Zustandsraum. Sprich schön lecker
Matritzenmultiplikation. Um das ganze durchzurechnen brauche ich 6ms,
darf aber nur 4,4ms brauchen.
Habe aber gerade das ok go bekommen dein Dingsie da durchzuverstehen und
es für den IAR umzuwurschteln. Jetzt heisst es Assemblercodes googeln
und das Hirn auf Maraton schicken :P
Achso das mit dem Wie ist eigentlich ne gute Frage. Da hab ich mir noch
nicht wirklich ne Platte drum gemacht :/
Meinste den kompilierten Assemblercode mal anschauen wär keien schlechte
Idee oder wat?
Hallo Icke_Wa,
/Um das ganze durchzurechnen brauche ich 6ms, darf aber nur 4,4ms
brauchen./
Du alle alle Optimierungen und Vereinfachungen durchgeführt hast, könnte
man noch den µP höher Takten, so würde das Programm auch schneller sein.
Manchmal kann man auch kleine Ergebniswerte, bzw. deren Berechnung
weglassen und durch eine Fehlerabschätzung ersetzen.
Wie schnell läuft die CPU Atmega2561 ?
Morgen alle zusammen.
Wie schnell die ist weiß ich ehrlich gesagt garnichtmal. Glaube die
rennt mit 14MHz. Höher Takten ist keine Option. Das Ding geht in die
Medizintechnik. Die Spring mir im Dreieck mit der Idee :P.
Hoffe mal das Peters angepasstes Dingen dann funktioniert und ausreicht.
Icke_Wa schrieb:> Hoffe mal das Peters angepasstes Dingen dann funktioniert und ausreicht.
Da muß ich Dich enttäuschen. Die Routine ist auf Codegröße optimiert,
nicht auf Laufzeit.
Die Laufzeit ist zwar auch schneller als die AVR-GCC Lib, aber der IAR
wird bestimmt besser optimiert sein.
Peter
Hm ... das wäre natürlich Schade.
Aber ich hätte da trotzdem noch nen paar Verständnissfragen. Ich raffe
noch nicht so ganz wie der Linker überhaupt weiß dass er jetzt dein File
nehmen soll und nicht die Standartvariante. Wird das ganze durch die
Variable __umoddi3 aufgerufen? Wie kann es dann sein, dass keine
Mehrdeutigkeit auftritt?
Die 64-Bit Routinen beim AVR-GCC sind m.W. in C programmiert und als
eine Art Basisimplementierung gedacht, die ohne Anpassung auf jeder
Prozessorarchitektur verfügbar ist. Sie ist u.a. deswegen sehr langsam,
weil in C nicht auf prozessorspezifische Dinge wie Carry-Flag u.ä. zuge-
griffen werden kann, so dass Additionen (und damit auch Multiplikationen
und Divisionen, die intern Additionen nutzen) nur sehr umständlich rea-
lisiert werden können.
Ich gehe aber davon aus, dass die IAR-Bibliothek bei den 64-Bit-Routinen
direkt in Assembler implementiert und gut optimiert sind, so dass du mit
Peters oder einer eigenen Implementation nicht unbedingt besser werden
wirst.
Wenn dir allerdings — wie im Thread-Titel angedeutet — 40 Bit reichen,
könnte da schon etwas machbar sein. Bei den Addition sparst du damit
etwa 37% Laufzeit, bei den Multiplikation noch mehr. Damit wäre eine
Verbesserung von 6ms auf 4,4ms durchaus realistisch.
Icke_Wa schrieb:> Ich raffe noch nicht so ganz wie der Linker überhaupt weiß dass er> jetzt dein File nehmen soll und nicht die Standartvariante.
Der GNU-Linker durchsucht die Libraries in einer bestimmten Reihenfolge,
durch die die Prioritäten bei Mehrdeutigkeiten festgelegt werden. Es
gibt auch Linker-Optionen, mit denen er angewiesen wird, bestimmte
Symbole nicht aus der Standardbibliothek zu nehmen.
Klingt so als wäre das hier nicht sonderlich Erfolgsversprechend.
Alternativ nen Tip wo ich mir die 40Bit Variante ins Hirn prügeln kann.
Ne libary hab ich dazu bisjetzt nicht gefunden.
Das sollte doch kein Problem sein, die benötigten Operationen zu
formulieren.
Addition und Multiplikation sind direkt binomisch hinzuschreiben.
Subtraktion über zwei Stufen und Division einfach interativ.
Am Besten baust du dir das für einen 48Bit-Typ = 3*16. Das gibt
Symmetrische Gleichungen und sollte nicht mehr Platz und Rechenzeit
benötigen, als die 40er-Variante mit 16+16+8.
Hehe amen Bruder! Doch was dir so klar ist, ist mir gänzlich unklar. Den
Code dafür erstmal zu formulieren macht mir garnicht sooo die Angst,
aber ich habe einfach keine Ahnung wo ich das am besten mache. Wie ich
dem Compiler dann klar mache dass es einen neuen Datentyp gibt und wo er
hin muss um mit diesem Datentyp zu rechnen usw.
Aber direkt dazu vielleicht mal ne kurze Frage. Wenn ich das mache mit 3
Integers nehmen, dann sollte ich ja trotzdem die multiplikation in
Assembler schreiben oder? In C kommen mir nur Ideen die dann
wahrscheinlich genau so langsam wären. Wenn ich jetzt an ne Funktion ne
oder besser 3 Integers übergebe. Wie muss ich die denn dann in Assembler
ansprechen. Meine Register sind ja nur 8Bit lang, sprich. Wie finde ich
herraus in welche beiden Register der mein INT packt?
Vielleicht würde auch schon ein zweites mal durchlesen reichen. Auf den
Schlipps treten wollte ich hier zumindestens keinem. Meine
Rechtschreibung und Satzstellung sind nur schon länger der Grund lieber
was mit Zahlen zu machen ...
Danke für die Links. Sobald ich wieder Zeit frei habe, werde ich mich da
mal durchwühlen.
>Vielleicht würde auch schon ein zweites mal durchlesen reichen.
Bestimmt! Aber damit es nicht jeder 2-mal durchlesen muss, bitte ich
Dich, es selber 2 x durchzulesen und zu korrigieren, bevor Du auf den
"Absenden" Knopf klickst!
Ich stimme Clemens zu, Deine Texte sind wirklich sehr mühsam zu lesen
und zu verstehen.
