Frage zu TIMSK

Gast #4716827
Lesenswert?

Hallo,

ziehe grade mit einem Programm von Attiny nach Atmega 168P um (der 
Speicher war doch etwas zu kein geworden ;-)).

Auf dem Attiny wird der Interupt

ISR(TIM0_OVF_vect)  (Timer/Counter0 Overflow)

und das Register

TIMSK   (Timer Interrupt Mask Register)

benutzt.

"TIMSK" ohne Zahl kennt der Atmega nicht, deshalb habe ich es in TIMSK0 
gewandelt.



Nun kann das Programm fehlerfrei compiliert werden, aber es gibt eine 
Warnung zum ISR(TIM0_OVF_vect)

'ISR(TIM0_OVF_vect)' appears to be a misspelled signal handler.


Kann jemand sagen, wo das Problem mit der ISR-Bezeichnung liegt?
Gast #4716921
Lesenswert?

Tr schrieb:

> Die heißt halt beim ATmega anders. Müsste "TIMER0_OVF_vect" sein.
>
> Findest du alles im Datenblatt

Nein, DAS findet er nicht im Datenblatt. Das ist rein deklarativer 
Scheiss. Sprachabhängig und u.U. sogar Compiler-abhängig. Sowas findet 
man also logischerweise in den Device-spezifischen Includes des 
verwendeten Compilers bzw. Assemblers.

Bei Assembler ist das ziemlich einfach, weil man das passende Include 
sowieso "von Hand" angeben muss. Da weiss man also auch sofort (nachdem 
man erstmal das Prinzip der Nomenklatur der Includes durchschaut hat), 
wo man sowas nachschauen muss.

Bei dieser C-Gülle ist das hingegen zusätzlich hinter einem Haufen 
völlig sinnloser Präprozesser-Logik verborgen, den man erst einmal 
durchschauen muss, um herauszufinden, welches Include nun das ist, was 
der Compiler auch tatsächlich benutzt. OK, ist zwar keine 
Raketenwissenschaft, aber offensichtlich doch hinreichend komplex, um 
einen Anfänger auszuschäkeln.

Letztlich schuld ist aber Atmel selber. In den allermeisten Fällen sind 
diese Brüche in der Nomenklatur völlig schwachsinnig und sinnlos. Wenn 
da mal irgendwer bei Atmel ernsthaft drüber nachgedacht hätte, bevor 
dieser Schrott auf die Menschheit losgelassen wurde, könnte Millionen 
Mannstunden eingespart werden, in denen sich gestandenen Programmierer 
damit befassen müssen, diesen Kram mit Unmassen weiterem 
Präprozessorcode auszubessern und die Sache damit "portabel" zu 
gestalten.

Das Allerschlimmste aber sind die eigenen Versuche von Atmel, 
"Kompatibilitäts-patches" in die Includes einzubringen. So blöd, wie die 
gestrickt sind (offensichtlich mit dem geistigen Horizont eines 
Architektur-Einsteigers verfasst), richten sie viel mehr Schaden an, als 
sie Nutzen bringen. Wenn also irgendwo in den Includes der Kommentar 
"for compatibility" auftaucht, ist höchste Vorsicht geboten... Man muss 
sofort die eigenen Werke diesbezüglichen daraufhin überprüfen, ob das 
nicht irgendwo ein Loch aufreisst.

Zum Glück ist die AVR8-Architektur samt Peripherie noch einigermaßen 
überschaubar...
Gast #4717040
Lesenswert?

c-hater schrieb:
> Nein, DAS findet er nicht im Datenblatt. Das ist rein deklarativer
> Scheiss.

Schön daß Du mal wieder über Sachen schreibst von denen Du keine Ahnung 
hast.
An die Bezeichnungen von Atmel halten sich alle Compiler und Atmel gibt 
sogar AplicationNotes zu den Änderungen bei Generationswechseln, z.B. 
vom Mega8 zum Megaxx8 http://www.atmel.com/images/doc2553.pdf

Aber hauptsache Du konntest mal wieder über C und Atmel herziehen.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren