Forum: Mikrocontroller und Digitale Elektronik Attiny2313A in AVR Toolchain (noch) nicht unterstützt?


von Andreas S. (emc2)


Lesenswert?

ich verwende AVR Studio4 mit der aktuellsten AVR Toolchain, habs aber 
auch schon mit Version 6 versucht, doch beim PCINT_vect (wie er beim 
Attiny2313 auch genannt wird) gibts eine Warnung:

../main.c:355:1: warning: 'PCINT0_vect' appears to be a misspelled 
signal handler [enabled by default]

und auch wenn man auf PCINT1_vect oder PCINT2_vect umstellt funktioniert 
es nicht...

Wenn ich aber Device und Compiler auf Attiny2313 (ohne A) umstelle läuft 
der Compiler ohne Warnung und Fehler durch und das Programm funktioniert 
auch wunderbar am Attiny2313A (sind ja an sich nicht viele Unterschiede 
zwischen A und nicht A)

aber warum funktioniert das nicht wie es sollte?

von Spess53 (Gast)


Lesenswert?

Hi

>../main.c:355:1: warning: 'PCINT0_vect' appears to be a misspelled
>signal handler [enabled by default]

Vielleicht, weil es nur einen Interrupt 'PCINT' gibt.

MfG Spess

von Hannes L. (hannes)


Lesenswert?

Spess53 schrieb:
> Vielleicht, weil es nur einen Interrupt 'PCINT' gibt.

Müsste das nicht in der entsprechenden Headerdatei oder Doku zu finden 
sein?

...

von Oliver J. (skriptkiddy)


Lesenswert?

Die avr-libc unterscheidet strikt zwischen attiny2313 und attiny2313a. 
Das macht auch Sinn, weil die neue Variante mehr Features hat. Das sind 
unter anderem 2 zusätzliche Pin-Change-Interrupts für PORTA und PORTD.

avr/iotn2313a.h:
1
#define PCINT_B_vect_num  11
2
#define PCINT_B_vect      _VECTOR(11)  /* Pin Change Interrupt Request B */
3
4
#define PCINT_D_vect_num  20
5
#define PCINT_D_vect      _VECTOR(20)  /* Pin Change Interrupt Request D */
6
7
#define PCINT_A_vect_num  19
8
#define PCINT_A_vect      _VECTOR(19)  /* Pin Change Interrupt Request A */


Gruß Oliver

von cyblord (Gast)


Lesenswert?

Hm meist gibt es in der Toolchain keinen Unterschied zwischen A und 
nicht A Varianten. Beim tiny44 z.B. ist auch die Signatur identisch so 
dass überhaupt nicht erkannt werden kann, welche Variante programmiert 
wird. Dito 168(A).
Da beim 2313 tatsächlich Features dazukommen, ist dann die Signatur auch 
anders?

von Oliver J. (skriptkiddy)


Lesenswert?

cyblord schrieb:
> Da beim 2313 tatsächlich Features dazukommen, ist dann die Signatur auch
> anders?

Nein.

von cyblord (Gast)


Lesenswert?

Oliver J. schrieb:
> cyblord schrieb:
>> Da beim 2313 tatsächlich Features dazukommen, ist dann die Signatur auch
>> anders?
>
> Nein.

Und dann unterscheidet der sich wirklich? Ist doch merkwürdig.

von Thomas E. (thomase)


Lesenswert?

cyblord schrieb:
> Da beim 2313 tatsächlich Features dazukommen, ist dann die Signatur auch
> anders?
Natürlich nicht.

For the ATtiny2313 the signature bytes are:
1. 0x000: 0x1E (indicates manufactured by Atmel).
2. 0x001: 0x91 (indicates 2KB Flash memory).
3. 0x002: 0x0A (indicates ATtiny2313 device when 0x001 is 0x91).


For the ATtiny2313A the signature bytes are:
1. 0x000: 0x1E (indicates manufactured by Atmel).
2. 0x001: 0x91 (indicates 2KB Flash memory).
3. 0x002: 0x0A (indicates ATtiny2313A device when 0x001 is 0x91).


Bis auf die Pinchange-Interrupts auf allen Ports und den entsprechenden 
Vektoren sind die wohl auch gleich. Also für 2313 kompilierter Code 
müsste auf dem 2313A laufen. Umgekehrt nicht unbedingt.
Also einen 2313 kann man wohl bedingungslos durch einen 2313A ersetzen. 
Deswegen auch die gleiche Signatur. Nicht daß der Brenner rebelliert, 
wenn die Signatur im elf-File nicht passt.

Sollte man trotzdem nicht allzu lange drüber nachdenken.

mfg.

von Andreas S. (emc2)


Lesenswert?

Danke für die schnellen und vielen Antworten!
Wie gesagt, der Code vom 2313 läuft auch am 2313A, aber warum sind die 
Namen der Interrupts im Manual (PCINT0..2) anders als in der 
avr/iotn2313a.h (PCINT_A .. B .. D)??

Naja, danke jedenfalls!

von Andreas S. (emc2)


Lesenswert?

aber ein Fehler bleibt in der iotn2313a.h dennoch:

#define GIMSK _SFR_IO8(0x03B)
#define PCIE 5
#define INT0 6
#define INT1 7

sollte lt. Datenblatt

#define GIMSK _SFR_IO8(0x03B)
#define PCIE1 3
#define PCIE2 4
#define PCIE0 5
#define INT0  6
#define INT1  7

sein...

sehe ich das richtig?

von Thomas E. (thomase)


Lesenswert?

Andreas S. schrieb:
> sehe ich das richtig?
Ja.

Die Flags fehlen auch.

#define EIFR _SFR_IO8(0x03A)
#define PCIF 5
#define INTF0 6
#define INTF1 7

PCMSK ist nicht in PCMSK0 geändert. Aber PCMSK1 und PCMSK2 sind richtig.

Der Hugo, der das geschrieben hat, war wohl betrunken.

mfg.

von tiny (Gast)


Lesenswert?

Andreas S. schrieb:
> sollte lt. Datenblatt
>
> #define GIMSK _SFR_IO8(0x03B)
> #define PCIE1 3
> #define PCIE2 4
> #define PCIE0 5
> #define INT0  6
> #define INT1  7
>
> sein...
>
> sehe ich das richtig?

Ja, das ist richtig, da der 2313A Pin-Change Interrupts an allen Pins 
hat bin ich damals unter AVR Studio4 vom 2313 auf den 2313A umgestiegen 
und habe mich über solch einen Fehler gewundert. Nach der Korrektur 
dieser falschen Dateien per Texteditor hat dann alles funktioniert. Nach 
dem Umstieg auf AVR Studio5 war das Problem erneut vorhanden. Und beim 
Umstieg auf AVR Studio6 wieder.

D.h. ich muss dann bald beim Umstieg auf Studio7 wieder die Dateien 
korigieren.

von Andreas S. (emc2)


Lesenswert?

da hat wohl jemand bei ATMEL ziemlich gepfuscht...

Ich bin zwar neu bei AVR-Programmierung, aber sowas sollte ja eigentlich 
nicht passieren, oder?

von Oliver J. (skriptkiddy)


Lesenswert?

Thomas Eckmann schrieb:
> Bis auf die Pinchange-Interrupts auf allen Ports und den entsprechenden
> Vektoren sind die wohl auch gleich.

Nicht ganz. Siehe die AVR533.

Gruß Oliver

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.