WinAVR -> IAR - Compiler

Gast #180199
Hi!
Ich habe mein funktionstüchtiges WinAVR - Programm für den mega 128
gestern mal in die Testversion des IAR-Compilers gestopft. sei(); und
cli(); kannte er nicht und auch die Einleitung der Interruproutine ist
nicht SIGNAL, sondern mit

#pragma vector=TIMER0_COMP_vect
__interrupt void irqHandler_t0(void)

einzuleiten, glaube ich zumindest. Naja, jedenfalls läuft es nicht,
kaum 1 sek nach dem Programmstart gib es einen Rest.
Ich vermute den Fehler bei meiner abgekupferten Zeile zur Einleitung
der Interruptroutine.
Wie müßte das richtig aussehen, oder woher könnte der Rest kommen?
Gast
Eigentlich sollte das Forum "gcc" genau den anderen Weg beschreiben,
denke ich :)

So weit ich mich da erinnere geht das auch folgendermaßen:

interrupt[VECTOR] void irqHandler_foobar(void)
{
    /* some code */
}

Ansonsten sind doch bestimmt Beispiele bei dem IAR-Compiler dabei!?
Gast
@OldBug
Das oben ist ja aus dem Beispiel, ich hab nur keine Ahnung was es
bedeutet. Dein Beispiel werd ich mal ausprobieren.

<< das Forum "gcc" genau den anderen Weg beschreiben,

Na ja! Das ist schon richtig und ich mag WinAVR ja eigentlich auch
lieber als den IAR schon der Anschaffungskosten wegen, aber wenn der
WinAVR meine doubles zu floats macht, ist die Genauigkeit meiner
Berechnug zum Teufel und die ganze Arbeit schlicht und ergreifend für
den A....
Gast
#pragma vector = 0x08
__interrupt void timer2_ovf_isr(void)
Das ist die Deklaration für Timer 2 Überlauf. Du mußt für deinen
Controller die richtige Vectoradresse einfügen.
MW
Gast
Was für eine Performance erreicht man denn so mit 64-bit-
Gleitkommazahlen?  Da braucht ja jede Zahl 8 Register für die
Darstellung, ich stelle mir das grausig vor.
Gast
@Michael
Na das sollte er ja auch sein und die Vectoradresse kommt doch aus der
can128.h, oder?

@Jörg
Naja, ich brauche es ja nicht für alle Zahlen, aber für ein Paar eben
schon. Im Moment liegt die Berechnungszeit bei knapp 1 sec. Das ist,
finde ich, nicht schlecht.
Gast
Es hat übrigens auch mal jemand ein 64-bit-FP-package gepostet,
entweder an die avr-libc-dev oder an die avr-gcc-list Mailingliste.
Allerdings hatte das Teil eine ziemlich unorthodoxe
Operandenzugriffsmethode (eigener Softwarestack), sodass es sich nicht
direkt in den Compiler integrieren lässt.
Gast
"Da braucht ja jede Zahl 8 Register für die Darstellung, ich stelle mir
das grausig vor."

Das täuscht. MUL/DIV als 'float' braucht um die 40µs für die
Operation und 'double' so 120 - 150µs, soweit ich es in Erinnerung
habe. Und bevor jetzt wieder das Geschreie losgeht, man dürfe nichts
und wieder nichts miteinander vergleichen, die double-Berechnung ist
echt fix !
Die Routinen selber zu schreiben, traut sich in der Regel niemand; aber
wenn man es macht, warum sollte es nicht fix sein ? Auch 'float'
anstatt 'int' zu nehmen trifft immer wieder auf unzutreffende
Vorurteile.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 21 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.