www.mikrocontroller.net

Forum: Compiler & IDEs Tangens sprengt die Codemenge


Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe unter anderen folgenden Codeabschnitt geschrieben:
tmpDouble1 = atan2( stpNeu.spul2, stpNeu.spul1 );  //den arcus Tangens (Ergebnis als Winkel im Bogenmaß -Pi bis +Pi) aus den beiden ED's berechnen
//  tmp16 =  180 / M_PI * tmpDouble1 ;             //in Grad [°] umrechnen
if (tmp16<0) tmp16 = 360 + tmp16;                  //negativer Winkel? Umrechenen in positiven.
stpNeu.winkel = tmp16;                             //Winkel eintragen

Wenn ich das so compeliere erhalte ich
"Program:    1392 bytes (68.0% Full)"

Wenn ich aber die Auskommentierung // in der zweiten Zeile weg nehme 
kommt
"Program:    4802 bytes (234.5% Full)"!!!

Leider komme ich so auch nicht in den Simulator um nach zu schauen was 
da passiert.

Hat da einer eine Idee wie ich das schreiben kann, dass ich unter 100% 
code komme?

Autor: Roland Praml (pram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- Anderen Controller verwenden mit genug Flash

- auf die Fließkommaarithmetik verzichten und das ganze evtl in 
Ganzzahl- oder Fixpunktarithmetik rechnen (kommt auf den Anwendungsfall 
an)

Gruß
Roland

Autor: ARM-Fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab aus dem gleichen Grund mal die Arcustangensfunction aus einer
math-lib, deren sourcecode im Internet vorlag, genommen, weil die ganzen
Bibliotheken sonst den Rahmen gesprengt hätten.

Ist aber schon ne Weile her. Mußt du dich mal umschauen.

Evtl. kann ich am Montag noch was zu dem Thema rauskramen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ ARM-Fan (Gast)

>Ich hab aus dem gleichen Grund mal die Arcustangensfunction aus einer
>math-lib, deren sourcecode im Internet vorlag, genommen, weil die ganzen
>Bibliotheken sonst den Rahmen gesprengt hätten.

Der Compiler ist schlau genug, nur die Funktionen einzubinden, die auch 
wirklich benutzt werden.

MFg
Falk

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der atan2 alleine braucht bei mir etwas über 1100 Bytes. Dass bei dir
das Programm nach Einfügen besagter Zeile so stark explodiert, ist evtl.
damit zu erklären, dass der Compiler bei Nichtbenutzung des Ergebnisses
der atan2-Funktion nicht nur diese, sondern noch eine ganze Menge
weiteren Code wegoptimiert. Wenn du diesen weiteren Code wirklich
brauchst und die darin keine Vereinfachungen vornehmen kannst, bleibt
wohl nur der Weg zu mehr Flash-Speicher.

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
µC-Typ AVR? Mit -lm gelinkt?

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie wärs wenn du dir den tan selber baust, schau dir einfach mal die 
summenformel an, kann man nachprogrammieren

Autor: gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hatten wir mal irgenswann im 1.semester gemacht, evtl kannst das ja 
umsetzen wenns dir schnell genug ist

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Vorschläge. Ich habe es mal versucht ohne Gleitkomma 
auszukommen:
tmp32 = (int32_t) (1000 * atan2( stpNeu.spul2, stpNeu.spul1 ));  
tmp32 *= 180;
tmp32 /= 3141;
tmp16 =  tmp32;
if (tmp16<0) tmp16 = 360 + tmp16;      
stpNeu.winkel = tmp16;          

Lieder hilft es nicht:

Program:    5008 bytes (244.5% Full)

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich habe es mal versucht ohne Gleitkomma
>auszukommen:
>tmp32 = (int32_t) (1000 * atan2( stpNeu.spul2, stpNeu.spul1 ));
                           ^^^^^

Der ist aber nach wie vor in Gleitkomma wenn du ihn nicht selber in 
Integerarithmetik programmiert hast.

Gruss Helmi

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ helmi1


das soll eigentlich der Ausdruck "(int32_t)" machen.
Wie wandelt man richtig ein Double in int32 ?

Autor: Ralf Schwarz (spacedog) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Überleg nochmals: Du machst einen typecast nach int32_t, weil atan2 
einen double ausspuckt. atan2 ist irgendwie so definiert:

double atan2( double y, double x );

Das heisst, dass du immer noch mit double rechnest, auch wenn du das 
ganze nachher nach int32_t castest. Somit wird auch die ganze 
Floatingpoint-Bibliothek eingebunden und der Code wird riesig.

Ich denke nicht, dass es in der C-Bibliothek eine 
Fixkomma-atan2-funktion gibt. Deshalb must du dir die selber 
zusammenwursteln.

Autor: Max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Tangens von (+/-)pi/2 ist (+/-)unendlich. Der arctan ist daher für 
(+/-)pi/2 unbestimmt. Könnte es sein das dein Compiler damit Probleme 
hat?

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmals: Es bringt wenig, nur an den paar geposteten Programmzeilen
herumzudoktern, da sie einschließlich hinzugelinkten Bibliotheksfunk-
tionen (FP-Arithmetik und atan2-Funktion) nur etwa 25% des Gesamtcodes
ausmachen. Um unter die 2K-Grenze zu gelangen, musst du den Programmcode
aber um fast 60% reduzieren. Das geht (wenn überhaupt) nur, indem du das
gesamte Programm nach Speicherfressern durchforstest.

Autor: Tavin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie genau brauchst Du eigentlich den Tangens ? macht es vieleicht auch 
eine kleine Tabelle mit Tangenswerten auch ?

Autor: B e r n d W. (smiley46)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Fly

In welchem Wertebereich muss denn der atan() funktionieren? Vielleicht 
lässt sich der Bereich über ein Polynom nachbilden oder durch eine 
Tabelle mit linearer Interpolation.

Bernd

Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> atan(x) = cos(x) / sin(x);    // für sin(x)=0 -> atan(x)=unendlich

Sechs, setzen.

Autor: B e r n d W. (smiley46)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Konstruktive Kritik bitte!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Bernd Weeber (smiley46)

>Konstruktive Kritik bitte!

Hat er doch gemacht. Es wurde nach dem ARCUStangens gefragt 
(Umkehrfunktion des Tangens), nicht dem COtangens!

MFG
Falk

Autor: ABu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei http://de.wikipedia.org/wiki/Arkustangens steht unter 
"Reihenentwicklung", wie man den atan mit einem Polynom annähert. Das 
kann man beliebig lang machen und so die Werte beliebig genau, bzw. den 
Wertebereich beliebig groß machen.

Berechnung dann mit Horner-Schema 
http://de.wikipedia.org/wiki/Hornerschema dann kann man sich die Bildung 
hoher Potenzen sparen.

Grüße

Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Konstruktiv:
http://www.restena.lu/convict/Jeunes/Math/arctan.htm

Wer aber mit (int32_t) versucht, das Gleitkomma auszutreiben,
wird wohl nichts damit anfangen können.

Autor: ABu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Das Polynom konvergiert nur im Bereich -1 bis +1 auf der Wiki 
Seite über den atan steht aber unter der Reihenentwicklung, wie man das 
umgehen kann.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bezüglich AVR-GCC ist für float ein 2kB-Chip völlig untauglich, ein 4kB 
absolutes Minimum und erst ab 8kB wirklich sinnvoll.

Ich war es vom 8051 her gewohnt, float auch auf MCs mit 2kB Flash 
(AT89C2051) einzusetzen, aber mit dem AVR-GCC geht das definitiv nicht.

Ich benutze daher als 20-pinner den ATtiny861, ist ohne UART und nur 16 
IOs aber nicht gerade der Brüller.

Vielleicht schafft es ja Microchip endlich den ATtiny2313 als Attiny8313 
mit 8kB zu entwickeln.
Und ein ATmega32313 mit 32kB Flash, 4kB SRAM und 18 IO-Pins wär 
natürlich super.


Peter

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo das geht ja richtig ab hier!

Das Programm soll aus dem PWM Signal für einen Schrittmotor, der über 
ein Getriebe einen Zeiger dreht, mir die Stellung des Zeigers berechnen. 
Die Hardwarelösung dazu wäre Poti an den Zeiger und die Spannung messen. 
Das fande ich aber uncool.
Den Tangens brauche ich um aus den beiden Spulenströmen den mechanischen 
Winkel zu Berechnen. Die Genauigkeit des Winkels ist mir eigentlich 
nicht so wichtig. Allerdings addiere und subtraiere ich ständig den dazu 
gekommenen Winkel so das sich der Fehler auf die Dauer aufsummiert.
Deswegen hatte ich gerade die Idee lediglich festzustellen in welchen 
Quadranten (oder kleinere Auflösung) sich der Schrittmotor befindet um 
dann nur glatte 90° zu add/sub.
Dazu wäre die Tabellenlösung gut. Macht man das in Form einer SWITCH 
Anweisung?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Fly (Gast)

>Das Programm soll aus dem PWM Signal für einen Schrittmotor, der über
>ein Getriebe einen Zeiger dreht, mir die Stellung des Zeigers berechnen.

Und dazu braucht man den Arcustangens?

>Den Tangens brauche ich um aus den beiden Spulenströmen den mechanischen
>Winkel zu Berechnen. Die Genauigkeit des Winkels ist mir eigentlich
>nicht so wichtig.

Dann nimm ne Tabelle.

> Allerdings addiere und subtraiere ich ständig den dazu
>gekommenen Winkel so das sich der Fehler auf die Dauer aufsummiert.

Bei nen Schrittmotor? Dann machst du was falsch.

>Dazu wäre die Tabellenlösung gut. Macht man das in Form einer SWITCH
>Anweisung?

Um Gottes Willen NEIN! Schon mal was von einem Array gehört?

MFg
Falk

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und dazu braucht man den Arcustangens?
ähm jup, aber es gibt bestimmt auch andere Lösungen.


>Bei nen Schrittmotor? Dann machst du was falsch.
Der Schrittmotor wird nicht einfach im Vollschritt angesteuert sondern 
jede Spule im PWM betrieben, so das sich ein Sinusförmiger Strom ergibt. 
Die ander Spule entsprechend Cosinus.

>Um Gottes Willen NEIN! Schon mal was von einem Array gehört?
Die Dinger?    meinArry[][];

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:

> Bezüglich AVR-GCC ist für float ein 2kB-Chip völlig untauglich, ...

Naja, das ist vielleicht etwas übertrieben. FP-Additonen/Subtraktionen
brauchen weniger als 400 Bytes. Nimmt man noch Multiplikationen hinzu,
sind es knapp 600 Bytes, mit der Division knapp 800 Bytes. Mit den vier
Grundrechenarten kann man schon eine Menge anstellen und hat immer noch
mehr als den halben Flash frei.

Auch die sqrt-Funktion ist mit zusätzlichen 200 Bytes noch recht human.
Die transzendenten Funktion schlagen mit jeweils 200 bis 500 Bytes zu
Buche, wobei Gruppen verwandter Funktionen wie sin/cos, asin/acos oder
log/log10 nur wenig mehr Speicher als die Einzelfunktionen belegen, da
sie viel gemeinsamen Code benutzen.

Nur die pow-Funktion braucht fast 1KB, da sie sowohl log als auch exp
benötigt und auch selbst noch einiges an Code mitbringt.

Ich bin auch kein Freund von FP-Berechnungen auf Mikrocontrollern, aber
bevor man den halben Flash leerstehen lässt, ist es manchmal sinnvoll,
sie mit Bedacht zu verwenden. Natürlich kann auf einem 2K-AVR kein
wissenschaftlicher Taschenrechner mit allen mathematischen Funktionen
programmiert werden, aber es gibt viele Anwendungen, wo nur die
Grundrechenarten und vielleicht noch etwas Trigonometrie benötigt
werden.

Auch Festkommaarithmetik, Look-Up-Tabellen, Interpolationen u.ä. kosten
deutlich Speicher, vor allem dann, wenn sie nicht in Assembler, sondern
C programmiert werden. Und man geht dabei das Risiko zusätzlicher
Programmierfehler ein.


Fly schrieb:

> Der Schrittmotor wird nicht einfach im Vollschritt angesteuert sondern
> jede Spule im PWM betrieben, so das sich ein Sinusförmiger Strom
> ergibt. Die ander Spule entsprechend Cosinus.

Wer erzeugt denn die Sinus/Cosinus-Signale für die Spulen? Der gleiche
Controller? Wenn ja, dann muss der Winkel ja schon irgendwo vorliegen.
Wenn nein, was macht den der Controller sonst noch wildes, dass 4,8KB
Programmcode benötigt werden? Der atan2 alleine bringt das
(Speicher-)Fass sicher nicht zum Überlaufen.

Vielleicht postest du mal den Quellcode der Funktion, aus dem die obigen
4 Zeilen stammen, oder noch besser das ganze Programm. Ich bin mir fast
sicher, dass sich darin noch ein anderer gewaltiger Speicherfresser
versteckt, der leichter zu eliminieren ist als die atan2-Funktion :)

Autor: Fly (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, hier ist nun das Programm. Ich hab mich damit zurückgehalten, weil 
das Programmieren nicht mein täglich Brot ist und damit viel 
"Verbesserungspotential" vorhanden sein wird. Aber aus Kritik kann man 
lernen. Also her damit!
Der Ablauf:

- Interrupt mäßiges einlesen der Eingänge
  * Start mit einer Positiven Flanke an einem der INT0 oder INT1
  * möglichst schnelles einlesen der Eingänge bis zur nächsten positiven 
Flanke

- Auswertung
  * feststellen der Stromrichtung
  * feststellen der Einschaltdauer zwischen den beiden Flanken
  * eliminieren von Fehlmessungen durch vergleich mehrerer Messungen
  * Rückrechnen der Zeigerposition --> dieser Thread
  * Ausgabe über UART

Mit der Rückrechnung habe ich das gerade so, dass lediglich festgestellt 
wird in welchem 1/8 Kreissegment sich der Winkel befindet. So klappt es 
auch mit dem Speicher: Program:    1790 bytes (87.4% Full)

Im folgenden kommt noch ein Flowchart.

Autor: Fly (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier das Flowchart zum Programm.

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne jetzt gleich über das Programm und grundsätzliche Fragen die vorher 
schon aufgeworfen wurden einzugehen:
Die ATAN-Function wird standardmäßig mittels CORDIC algorithmen 
realisiert. Such einfach mal danach im Netz.
Ich hab nur mal schnell hier:
http://de.wikipedia.org/wiki/Cordic

und da was gefunden:
http://www.andraka.com/files/crdcsrvy.pdf
http://www.mathworks.com/matlabcentral/files/19316...

Nimm eine fixed-point Version, dann sollte das mit deutlich weniger 
Flash (und RAM) auskommen.

Mario

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fly wrote:
> So, hier ist nun das Programm. Ich hab mich damit zurückgehalten, weil
> das Programmieren nicht mein täglich Brot ist

Schöne Ausrede, um nicht mal die Frage nach dem verwendeten µC und den 
verwendeten Compileroptionen zu beantworten. Du verarschst uns hier 
doch.

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Schöne Ausrede, um nicht mal die Frage nach dem verwendeten µC und den
verwendeten Compileroptionen zu beantworten. Du verarschst uns hier
doch.

Ne Kollege, da bist du auf dem Holzweg, verarschen ist das letzte was 
ich tuhe.

Bisher hat es noch keinen interessiert aber ich sag es dir gerne:

Compiler: AVR Studio 4.14 mit AVR GCC plugin
Controller: AT90S2313 ja ich weiß den gibt es nicht mehr aber ich habe 
halt noch welche rum liegen.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Controller: AT90S2313

So etwas habe ich fast befürchtet ;-) Als du den Code gepostet hast und
ich beim probeweisen Kompilieren über das UCR-Register gestolpert bin,
war klar, dass es sich bei dem Controller um einen Veteran handelt. Und
die Kombination von UCR und 2KB Flash gibt es nur einmal, nämlich beim
AT90S2313 :)

"Befürchtet" schrieb ich deswegen, weil es für diesen Controller keinen
pinkompatiblen Ersatz mit mehr Flash gibt, der dein Problem
wahrscheinlich am leichtesten lösen würde.

> ... weil das Programmieren nicht mein täglich Brot ist

Gerade deswegen ist es deutlich weniger stressig, genügend Flash und RAM
zur Verfügung zu haben, was beim AT90S2313 leider nicht der Fall ist.

Ich habe mir dein Programm durchgesehen mit folgendem Ergebnis:

Mit der atan2-Funktion ist der erzeugte Code tatsächlich sehr groß,
allerdings ist mir nicht ganz klar, wie du auf die 4802 Bytes kommst.
Bei mir (GCC 4.2.4, AVRLibc 1.6.2) sind es nur etwa 3200 Bytes, was aber
natürlich immer noch zu viel ist.

Lässt man den atan2 weg, kommt man zwar unter die 2KB-Grenze, aber es
bleibt kaum Platz für eine Alternativlösung, es sei denn, man ist mit
einer sehr ungenauen Berechnung zufrieden. So etwas hast du ja schon
versucht, indem du die 360° in acht Intervalle von 45° unterteilt hast
und prüfst, in welchem dieser Intervalle der Wert liegt.

Eigentlich hatte ich gehofft, eine Stelle im Programm zu finden, an der
man auf einen Schlag 1KB wegoptimieren kann. Leider verteilt sich der
Speicherfresser auf das ganze Programm, so dass keine schnelle Lösung
möglich ist.

Ein Ansatzpunkt für eine Optimierung wäre, das zweidimensionale Array
stepZustand zu eliminieren. Musst du wirklich die gesampelten
Eingangspegel in ein Array schreiben, um sie hinterher auf die Dauer des
High-Pegels zu analysieren? Das könnte man doch sofort beim Einlesen der
Signale tun, indem man auf die Flanke wartet (entweder gepollt oder per
Interrupt) und auf den Timer schaut, wann sie eintrifft. Arrayzugriffe
kosten auf dem AVR nicht nur viel Programmspeicher, sondern auch Zeit,
was auch die Auflösung deiner Zeitmessung deutlich verschlechtert.

Du startest die Messung mit einem Interrupt auf die steigende Flanke.
Die fallende Flanke fragst du aber in einer Schleife ab. Besser ist es,
für beide Flanken das gleiche Erkennungsverfahren anzuwenden, da sich
dann die Latenzzeit (zumindest teilweise) aufheben. Also entweder beide
Flanken per Interrupt (ich hoffer, dass der AT90S2313 schon auf beide
Flanken reagieren konnte) oder beide per Abfrageschleife. Die
Schleifenmethode ist in diesem Fall wahrscheinlich sogar etwas genauer
und spart auch Programmspeicher, da kein Interrupthandler und keine
Volatile-Variablen benötigt werden.

Leider hat der AT90S2313 keine zwei Input-Capture-Einheiten. Sonst
könntest du die Zeitmessung noch einfacher und noch genauer über diese
abwickeln.

Durch die Messung der Zeit während des Einlesens der Signale wird nicht
nur die Einleseroutine kürzer und schneller. Vor allem bei der
Auswertung sparst du Code und Zeit, weil die ganzen Sampels nicht noch
einmal durchgegangen werden müssen.

Ich würde fast behaupten, dass du auf diese Weise und mit ein paar
kleineren lokalen Optimierungen 1KB oder mehr an Code einsparen kannst,
so dass du bei der Wahl des Verfahrens zur Winkelberechnung aus dem
Sinus- und dem Cosinuswert ausreichend Luft gewinnst.

Trotzdem würde ich an deiner Stelle in Erwägung ziehen, den AT90S2313
durch einen größeren Controller (mindestens einen ATmega8) zu ersetzen
und diesen über eine geeignete Adapterplatine an deine Schaltung
anpassen. Sonst stößt du bei jeder kleinen Erweiterung des Programms
wieder auf Probleme.

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ yalu

Erstmal ganz fetten Dank für die ausführliche Analyse meines Programms!
Das hilft mir echt weiter.

Den Ansatz die Eingänge direkt auszuzählen anstatt erst einmal nur 
stumpf einzulesen überrascht mich. Ich dachte es gibt nichts schnelleres 
als Port einlesen und abspeichern. Trotzdem finde ich es gut, besonders 
wenn man dadurch das speicherintensive Arry stepZustand los wird.

Wo wir auch gleich beim nächsten Thema sind. Ich hatte die Idee die 
Zuordnung in die 360°/8 in einem Arry zu organisieren. So wie ich aber 
eben gelernt habe ist das vielleicht garnicht Speicher sparsamer wegen 
dem Arry oder sehe ich das falsch?

Jetzt muss ich mir wohl ertsmal überlegen was einfacher ist, das 
Programm umschrieben oder einen größeren Controller einzusetzen.

Autor: Bender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Vielleicht schafft es ja Microchip endlich den ATtiny2313 als Attiny8313
>mit 8kB zu entwickeln.

ATtiny  von Microchip? ;)

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fly wrote:
> Bisher hat es noch keinen interessiert aber ich sag es dir gerne:

Lüg' nicht, das war meine erste Frage.

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ pnuebergang

>µC-Typ AVR? Mit -lm gelinkt?

Ja jetzt sehe ich es auch, sorry habe ich übersehehen. Und jetzt komm 
mal bitte von deinem Wut Trip runter, das hilft hier keinen weiter.

Was aber weiter hilft ist, wenn du mir sagst was mit -lm gemeint ist und 
wie ich das herausfinden kann.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:
> Peter Dannegger schrieb:
>
>> Bezüglich AVR-GCC ist für float ein 2kB-Chip völlig untauglich, ...
>
> Naja, das ist vielleicht etwas übertrieben. FP-Additonen/Subtraktionen
> brauchen weniger als 400 Bytes. Nimmt man noch Multiplikationen hinzu,
> sind es knapp 600 Bytes, mit der Division knapp 800 Bytes. Mit den vier
> Grundrechenarten kann man schon eine Menge anstellen und hat immer noch
> mehr als den halben Flash frei.

???


Die kleine Testfunktion:
float test( float a, float b )
{
  return (a * 3.21 + 4.73) / b;
}
ergibt:
GCC 4.3.0
   text    data     bss     dec     hex filename
   2564       8       0    2572     a0c test.out

Die 4 Grundrechenarten passen also definitiv nicht in den ATtiny2313.


Peter

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Den Ansatz die Eingänge direkt auszuzählen anstatt erst einmal nur
> stumpf einzulesen überrascht mich. Ich dachte es gibt nichts
> schnelleres als Port einlesen und abspeichern.

Nicht, wenn die direkte Messung so einfach ist, wie in diesem Fall.

So oder so ähnlich hätte ich's gemacht:
  uint8_t tper, thigh;
  // warten auf steigende Flanke und Zeit nehmen
  while(!(PIND & (1<<PD0)));
  tper = TCNT0;

  // warten auf fallende Flanke und Zeit nehmen
  while(!(PIND & (1<<PD0)));
  thigh = TCNT0 - tper;

  // warten auf steigende Flanke und Zeit nehmen
  while(!(PIND & (1<<PD0)));
  tper = TCNT0 - tper;

In tper und thigh stehen nun die Periodendauer und die Dauer des
High-Pulses. Du brauchst also ein großes Stück deines Auswertecodes
nicht mehr.

Der Compiler erzeugt daraus folgendes:
.L5:
  sbis 48-0x20,0
  rjmp .L5
  in r25,82-0x20
.L7:
  sbis 48-0x20,0
  rjmp .L7
  in r22,82-0x20
.L9:
  sbis 48-0x20,0
  rjmp .L9
  in r24,82-0x20
  sub r22,r25
  sub r24,r25

Das sind 22 Bytes, und die CPU benötigt 3 Zyklen pro Schleife. Die
erreichbare Zeitauflösung ist als 3 Taktzyklen.

So sieht der entsprechende Teil in deinem Programm aus (ich habe die
Abfrage auf maxAbt weggelassen, weil das in meinem obigen Code auch
fehlt):
  while(!(GIFR & (1<<INTF0))) {
    stepZustand[messungen][wdh] = PIND;
    messungen ++;
  }  
  stepZustand[maxAbt][wdh] = messungen;

Er sieht zwar auf den ersten Blick kürzer aus, aber der Compiler erzeugt
daraus folgendes Code-Monster:
  in __tmp_reg__,90-0x20
  sbrc __tmp_reg__,6
  rjmp .L9
  lds r20,wdh
  mov r18,r20
  clr r19
  lds r25,messungen
.L6:
  in r24,48-0x20
  mov r30,r25                    ; \
  clr r31                        ;  |
  lsl r30                        ;  |
  rol r31                        ;  |
  add r30,r18                    ;   > Arrayzugriff
  adc r31,r19                    ;  |
  subi r30,lo8(-(stepZustand))   ;  |
  sbci r31,hi8(-(stepZustand))   ;  |
  st Z,r24                       ; /
  subi r25,lo8(-(1))
  in __tmp_reg__,90-0x20
  sbrs __tmp_reg__,6
  rjmp .L6
  sts messungen,r25
  rjmp .L4
.L9:
  lds r20,wdh
.L4:
  mov r30,r20
  clr r31
  subi r30,lo8(-(stepZustand))
  sbci r31,hi8(-(stepZustand))
  lds r24,messungen
  std Z+20,r24

Das sind schon 70 Bytes, also mehr als das Dreifache. Man sieht
deutlich, welcher Aufwand getrieben werden muss, nur um ein einzelnes
Byte in das Array zu schreiben. Eine Abfrageschleife dauert 16 Zyklen,
also fünfmal so lange, was die erreichbare Zeitauflösung verschlechtert.

Da das Ganze im Interrupthandler läuft kommen nochmal über 40 Bytes für
das Retten und Wiederherstellen der Registerinhalte dazu.

Und die Bestimmung der Periodendauer und der Dauer des High-Pulses kommt
erst noch und frisst weitere 400 Bytes.

Somit belegt die Bestimmung der Zeitdaten alleine schon ein Viertel des
Flash-Speichers


Auweia =8-O, jetzt habe ich in meinem Eifer übersehen, dass die
Schrittmotorsignale nach positivem und negativem Stromfluss
unterschieden werden müssen. Dann ist die Messroutine doch nicht ganz so
einfach, wie oben beschrieben. Das ändere ich heute aber nicht mehr ;-)
Ich schätze aber, sie wird dadurch höchsten um 50% länger, da man die
Unterscheidung wahrscheinlich nur bei der Detektion der ersten Flanke
machen muss.

>>µC-Typ AVR? Mit -lm gelinkt?
>
>Ja jetzt sehe ich es auch, sorry habe ich übersehehen. Und jetzt komm
>mal bitte von deinem Wut Trip runter, das hilft hier keinen weiter.

Bei Problemen jeglicher Art ist es für den Antworter eine große Hilfe,
wenn er das Problem bei sich nachstellen kann. Manchmal geht das
schlecht, weil die notwendigen Hardwaremittel fehlen. In diesem Fall
wird aber nur der Quellcode, der richtige Compiler (Versionsnummer) und
die Kommandozeile, mit der dieser aufgerufen wird (alle übergebenen
Optionen einschließlich derjenigen für den Controllertyp, alternativ ein
Makefile), benötigt. Anstelle des kompletten Quellcodes genügt oft auch
eine abgespeckte Version, die das Fehlerverhalten immer noch zeigt.
Je mehr nützliche Informationen du im Eingangspost gibst, umso größer
ist die Chance, schnelle und hilfreiche Antworten zu erhalten. Also beim
nächsten Mal ... :)

> Was aber weiter hilft ist, wenn du mir sagst was mit -lm gemeint ist
> und wie ich das herausfinden kann.

Die Option -lm veranlasst den Linker, die Mathebibliothek einzubinden.
Diese enthält Funktionen wie sin, atan2, pow und log und bei der
AVR-Libc zusätzlich handoptimierte Versionen von Gleitkommaarithmetik-
routinen (+, -, *, / usw.), die schneller und kompakter als die beim GCC
mitgelieferten sind. Wenn man Floats und Doubles verwendet, ist es
deswegen immer ein ratsam, -lm anzugeben, auch dann, wenn man nichts mit
Sinus und Co. am Hut hat.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:

> Die 4 Grundrechenarten passen also definitiv nicht in den ATtiny2313.

Dann hast du das -lm vergessen (s. letzter Abschnitt in meinem vorigen
Post). Damit braucht das Programm einschließlich eines leeren main
weniger als 1KB.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:
> Peter Dannegger schrieb:
>
>> Die 4 Grundrechenarten passen also definitiv nicht in den ATtiny2313.
>
> Dann hast du das -lm vergessen

Stimmt, jetzt gehts:
   text    data     bss     dec     hex filename
    930       0       0     930     3a2 test.out


Peter

Autor: floating point (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@yalu

Du fällst hier ja immer wieder durch erfreuliche, sachgerechte Beiträge 
auf. Erfreulich diesmal ist, daß Du das "Monster" 'floating point' auf 
seine reale Größe gestutzt hast.

Somit gibt es eigentlich keinen zwingenden Grund, auf Integer oder 
'fixpoint' Rechnerei auszuweichen, selbst auf ATtiny25/45/85 nicht. Und 
- wie angedeutet - bekommt man kein Geld vom Hersteller zurück, wenn man 
1-2kB Flash-Speicher ungenutzt läßt.

Jetzt höre ich gleich wieder das Argument der unzureichenden 
Geschwindigkeit, die aber meist an anderen Stellen im Programm zunichte 
gemacht wird.

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ yalu

>Auweia =8-O, jetzt habe ich in meinem Eifer übersehen, dass die
>Schrittmotorsignale nach positivem und negativem Stromfluss
>unterschieden werden müssen. Dann ist die Messroutine doch nicht ganz so
>einfach, wie oben beschrieben. Das ändere ich heute aber nicht mehr ;-)
>Ich schätze aber, sie wird dadurch höchsten um 50% länger, da man die
>Unterscheidung wahrscheinlich nur bei der Detektion der ersten Flanke
>machen muss.

Lass mal, das Prinzip habe ich verstanden. Ich muss es halt für die 4 
Eingänge anpassen. Du hast schon genug getan und dafür ein fettes 
DANKESCHÖN!

Autor: Manni (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist ein atan2 algorithmus, basierend auf der bereits 50 Jahre alten 
atan2 approximation von „Hastings“. Der |Fehler| ist < 0.005 radians und 
sei 3-5x schneller (sagt man, hab's aber nicht ausprobiert) als der gcc 
atan2 algorithmus.

Mit AVR Studio und der unteren main routine belegt er 1124 bytes auf'm 
ATmega32 (mit -Os).

#include <stdio.h>
#include <avr/interrupt.h>
#include <math.h>

float arctan2 (float y, float x);

int main (void)
  {
  float c;

  c = arctan2 (0.65f, 1.34f);

  return 0;
  }

Gruß Manni

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@floating point:

Danke, freut mich :)

@Manni:

Das von dir beschriebene Verfahren ist für die wenigen
Rechenoperationen, die es benötigt, erstaunlich genau und deswegen eine
gute Alternative zum atan2 der AVR-Libc, wenn man nicht die volle
Genauigkeit braucht und an anderer Stelle sowieso schon mit Floats
rechnet. Die AVR-Libc berechnet den atan[2] über eine Potenzreihe mit 9
Summanden, was schon deutlich mehr Zeit braucht, die ich allerdings
nicht nachgemessen habe.

Die Genauigkeit ist übrigens nicht ±0,005, sondern etwa ±0,01, was aber
dem Nutzen des Verfahrens keinen Abbruch tut. Es gibt aber auch ein
Verfahren mit ±0,005, das ebenfalls mit wenigen Rechenoperationen
auskommt. Hier sind beide beschrieben:

  http://lists.apple.com/archives/PerfOptimization-d...

Welches letztendlich schneller ist, müsste man ausprobieren. Das zweite
(genauere) braucht zwar etwas weniger Additionen und Multiplikationen,
dafür aber eine zusätzliche Division. Der maximale Fehler ist
tatsächlich ±0,01 bzw. ±0,005, das habe ich ausprobiert. Das zweite
Verfahren hat noch den kleinen Schönheitsfehler, dass es bei |x|=|y|
unstetig ist.

Autor: Manni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja du hast recht: genau die zweite Funktion meinte ich auch, denn die 
Graphs beziehen sich auf die verwendete Funktion im zweiten Verfahren 
mit:

atan = z/(1.0f + 0.28f*z*z);

Habe die Info auch von dieser Seite, nur wußte ich den Link nicht mehr, 
da ich mir den Text vor einiger Zeit einfach in ein Dok file kopiert 
hatte.

Im AVR ist dieser Code nur unwesentlich größer: 1220 bytes.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.