Ich habe eine INT0 ISR des Tiny44A mit ISR(INT0_vect) geschrieben - so
wie ich es bisher gewohnt war bei diversen Tinys.
Mein WinAVR-20100110 meldet jedoch "warning: 'INT0_vect' appears to be a
misspelled signal handler". Also INT0_vect ist nicht bekannt, obwohl es
den IRQ laut DB unter dem Namen INT0 gibt.
Das selbe übersetzt für den Tiny44 (ohne A) ist erfolgreich.
Etwas Suche in den io.h-Files (iotn44a.h) brachte für den 44A zu Tage:
und die anderen x4-Tinys bekommen über iotnx4.h die defines
1
/* External Interrupt Request 0 */
2
#define INT0_vect _VECTOR(1)
3
#define EXT_INT0_vect _VECTOR(1)
4
#define SIG_INTERRUPT0 _VECTOR(1)
Das erklärt das Verhalten und das Problem ist nach dem Suchen und Finden
mit dem Aufruf ISR(EXT_INT0_vect) gelöst.
Ist das jetzt einfach eine Unsauberkeit in iotn44a.h oder hat das einen
tieferen Grund?
Es leidet eben ein wenig die Portierbarkeit eines Programms darunter ...
Da du eine alte und nicht mehr supportete Toolchain verwendet, liegt der
Support dann quasi bei dir (oder du beauftragst jemand damit). Wie die
Änderung der Header auszusehen hat, ist ja ziemlich klar.
HildeK schrieb:> Aber es scheint gar nicht so einfach zu sein, eine aktuelle Toolchain> für mein AVR Studio 4.18 zu finden ...
Kannst du nicht jede Toolchain einbinden die du magst?
Wurde inzwischen zwar fündig, aber weder in
avr-gcc-8.0.1_2018-01-19_mingw32
noch in
avr8-gnu-toolchain-installer-3.5.4.91-win32.any.x86
von ST
oder in der von
gnutoolchains.com
ist das anders enthalten.
Johann L. schrieb:> Ein grep gibt bei mir:
Ja, du hast aber für den 44a auch nur gefunden:
Ingo L. schrieb:> Kannst du nicht jede Toolchain einbinden die du magst?
Naja, mit der von http://gnutoolchains.com/avr/ hat das make nicht
funktioniert. Aber der iotn44a.h war an der Stelle eh gleich.
Wie du hier siehst, habe ich einiges gefunden, das aber die
Ausgangsfrage nicht geklärt hat. Es liegt nicht an der 'alten'
Toolchain, sondern ist auch bei aktuellen Varianten so enthalten.
Mit dem Aufruf ISR(EXT_INT0_vect) kann ich auch leben, er ist ja auch
bei den anderen Tinys in den Headers definiert.
HildeK schrieb:> Ja, du hast aber für den 44a auch nur gefunden:
Ah ja. :-/ Dann halt über ein ifdef __AVR_ATiny44A__ parametrisieren.
> Wie du hier siehst, habe ich einiges gefunden, das aber die> Ausgangsfrage nicht geklärt hat. Es liegt nicht an der 'alten'> Toolchain, sondern ist auch bei aktuellen Varianten so enthalten.
Dann liegt die Ursache wohl in den Hardware-XMLs, aus denen die Header
erzeugt werden... Musst in der avr-libc rumwühlen, evtl. in den
Mailing-Listen nachfragen, warum genau das so ist.
> Mit dem Aufruf ISR(EXT_INT0_vect) kann ich auch leben, er ist ja auch> bei den anderen Tinys in den Headers definiert.> mit [...] at das make nicht funktioniert.
Einfach die WinAVR/util/bin in PATH nach vorne, oder den util/bin-Pfad
der neuen Tools erst garnicht in den Pfad aufnehmen.
> Ist das jetzt einfach eine Unsauberkeit in iotn44a.h oder hat das einen> tieferen Grund?> Es leidet eben ein wenig die Portierbarkeit eines Programms darunter ...
Offenbar ist die übergreifende Notation
EXT_INT0_vect
und für alte Software (Tiny44ohneA) ist die funktionsidentische, alte
Variante noch da:
INT0_vect
War doch jetzt nicht schwer, oder?
Melder schrieb:> War doch jetzt nicht schwer, oder?
Ja, klar, das habe ich auch gesehen. Es ist ja nur eine imho fehlendes
#define (auch für den 24A und 84A). Ich fragte mich nur, warum hat man
das da weggelassen? Ist es am aussterben, so wie das SIG_INTERRUPT0?
HildeK schrieb:> Ist es am aussterben, so wie das SIG_INTERRUPT0?
Vereinheitlicht scheinen Externe Interrupts eben EXT_INTn_vect zu
heißen.
Ist aber egal, denn wenn alle eine Variante benutzen, nur einer
zusätzlich noch eine zweite, was ist dann der Ausreißer?
Melder schrieb:> Ist aber egal, denn wenn alle eine Variante benutzen, nur einer> zusätzlich noch eine zweite, was ist dann der Ausreißer?
Naja, mir ist bisher nur INT0_vect begegnet (neben INTERRUPT0 in ganz
alten Quelle), was aber nichts heißen muss. Und die PCINTs werden auch
nicht EXT_PCINTx genannt und das sind auch externe.
HildeK schrieb:> Melder schrieb:>> Ist aber egal, denn wenn alle eine Variante benutzen, nur einer>> zusätzlich noch eine zweite, was ist dann der Ausreißer?>> Naja, mir ist bisher nur INT0_vect begegnet (neben INTERRUPT0 in ganz> alten Quelle), was aber nichts heißen muss. Und die PCINTs werden auch> nicht EXT_PCINTx genannt und das sind auch externe.
PinChange vs EXTernal_INTerrupt[0-3]
Eigentlich gut herleitbar.
Die SIG_*-Varianten sind wohl nur noch historische Altlast.
