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?
Gast
#2918283
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
Spess53 schrieb: > Vielleicht, weil es nur einen Interrupt 'PCINT' gibt. Müsste das nicht in der entsprechenden Headerdatei oder Doku zu finden sein? ...
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Gruß Oliver
Gast
#2918349
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?
cyblord schrieb: > Da beim 2313 tatsächlich Features dazukommen, ist dann die Signatur auch > anders? Nein.
Gast
#2918391
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.
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.
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!
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?
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.
Gast
#2918613
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.
da hat wohl jemand bei ATMEL ziemlich gepfuscht... Ich bin zwar neu bei AVR-Programmierung, aber sowas sollte ja eigentlich nicht passieren, oder?
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
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.