INT0 IRQ beim Tiny44A vs. Tiny44 (WINAVR-20100110 )

[HildeK (Gast)]

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:

#define EXT_INT0_vect_num  1
#define EXT_INT0_vect      _VECTOR(1)  /* External Interrupt Request 0 */

und die anderen x4-Tinys bekommen über iotnx4.h die defines

/* External Interrupt Request 0 */
#define INT0_vect                _VECTOR(1)
#define EXT_INT0_vect            _VECTOR(1)
#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 ...

[Johann L. (gjlayde)]

Eine aktuelle Toolchain verwenden?  Ein grep gibt bei mir:

./avr/include/avr/iotnx4.h:#define INT0_vect          _VECTOR(1)
./avr/include/avr/iotnx4.h:#define EXT_INT0_vect      _VECTOR(1)
./avr/include/avr/iotnx4.h:#define PCINT0_vect          _VECTOR(2)
./avr/include/avr/iotn441.h:#define INT0_vect            _VECTOR(1)
./avr/include/avr/iotn44a.h:#define EXT_INT0_vect      _VECTOR(1)  /* External Interrupt Request 0 */
./avr/include/avr/iotn44a.h:#define PCINT0_vect      _VECTOR(2)  /* Pin Change Interrupt Request 0 */

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 (Gast)]

Ok, Danke.
Aber es scheint gar nicht so einfach zu sein, eine aktuelle Toolchain 
für mein AVR Studio 4.18 zu finden ...

[Ingo L. (corrtexx)]

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?

[HildeK (Gast)]

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:

./avr/include/avr/iotn44a.h:#define EXT_INT0_vect      _VECTOR(1)  /* External Interrupt Request 0 */
./avr/include/avr/iotn44a.h:#define PCINT0_vect      _VECTOR(2)  /* Pin Change Interrupt Request 0 */

und nicht, was ich gehofft hatte

#define INT0_vect   _VECTOR(1)

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.

[Johann L. (gjlayde)]

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.

[HildeK (Gast)]

Johann L. schrieb:
> evtl. in den
> Mailing-Listen nachfragen, warum genau das so ist.

Ja - das war ja mein Versuch hier ...
Danke für deine Bemühungen!

[Melder (Gast)]

> 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?

[HildeK (Gast)]

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?

[Melder (Gast)]

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?

[HildeK (Gast)]

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 (Gast)]

HildeK schrieb:
> neben INTERRUPT0

Meinte SIG_INTERRUPT0.

[Melder (Gast)]

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.