Ich versuche gerade INT0 auf dem Atttiny441 zum laufen zu bringen,
bekomme das aber nicht so zum laufen wie erwartet.
Mein Code sieht so aus:
1
DDRB&=~(1<<DDRB1);
2
3
MCUCR|=((1<<ISC01)|(1<<ISC00));
4
GIMSK=(1<<INT0);
5
sei();
6
7
ISR(INT0_vect)
8
{
9
// toggle led for debugging
10
}
Testsignal am Eingang B1 hab ich mir mit dem Scope angesehen, das ist
ok. Mit einer while(1) Testschleife kann ich Port B1 auch auslesen und
die LED toggeln. Versuche ich das über die Interruptroutine oben, dann
passiert leider nichts. Sieht da jemand da einen Fehler in der Source,
bin da gerade etwas betriebsblind.
Hallo,
das ist doch kein vollständiges Programm.
Wo sind die Include Dateien und die void main (...);?
Input einlesen und LED ausgeben, wo finde ich das?
#include <avr/io.h>
#include <avr/interrupt.h>
int main() mit einer for(;;) {} ist der Rest, auf den ich es für die
Tests reduziert habe.
Ich habe gerade entdeckt, daß es anscheinend ein Fehler von meiner GCC
Toolchain ist. Wenn ich es unter Atmel Studio compiliere, geht es.
Ist die Interruptinitialisierung aus Eurer Erfahrung korrekt?
Marlin schrieb:> Ist die Interruptinitialisierung aus Eurer Erfahrung korrekt?
Schreib erst mal ein paar Kommentare in den Code, sonst ist das nicht
eindeutig zu beantworten.
Marlin schrieb:> Ich versuche gerade INT0 auf dem Atttiny441 zum laufen zu bringen,> bekomme das aber nicht so zum laufen wie erwartet.>> Mein Code sieht so aus:>
1
>DDRB&=~(1<<DDRB1);
2
>
>
Am Ende soll DDRB.1 gesetzt sein, also Schau dir obige Zeile noch mal
intensiv an.
S. Landolt schrieb:>> Am Ende soll DDRB.1 gesetzt sein>> ?> PB.1 ist der Interrupteingang für INT0.
Stimmt. So ist es, wenn man Texte zu rudimentär liest ;-)
Bleibt noch die Fragen:
Wie wurde der Fehler erkannt?
Welcher PortPin sollte etwas tun?
Wie wurde der initialisiert.
Bei dem (kumulierten) geposteten Code würde ich keine außen erkennbare
Reaktion des Chips erwarten.
S. Landolt schrieb:>> Am Ende soll DDRB.1 gesetzt sein>> ?> PB.1 ist der Interrupteingang für INT0.
Genau: der springende Punkt ist hier: EINGANG. Dass Bit sollte also
gelöscht sein. Und genau das stellt der von Carl inkrimierte Ausdruck
wirklich sicher.
Da steckt der Fehler also ganz sicher nicht.
Karl M. schrieb:> Wo sind die Include Dateien und die void main (...);?
Wenn die fehlen würden, dann hätte es von Errors nur so gehagelt.
BTW: void main() meckert mein Compiler immer an, er will int main(),
obwohl kein return x im Programm steht. WinAVR-20100110.
S. Landolt schrieb:> Zum ATtiny441 kann ich nichts sagen, aber beim ATtiny44 heißt der Vektor> 'EXT_INT0_vect' (warum auch immer).
Das 'Warum' hatte ich schon mal gefragt - ohne schlüssiges Ergebnis. War
aber nur beim 44A, der 44 kennt INT0_vect.
Beitrag "INT0 IRQ beim Tiny44A vs. Tiny44 (WINAVR-20100110 )"
Aber auch das hätte einen Error zur Folge gehabt.
Aber das Problem lag ja an anderer Stelle.
S. Landolt schrieb:>> Am Ende soll DDRB.1 gesetzt sein>> ?> PB.1 ist der Interrupteingang für INT0.
Ja, das war offenbar nur ein Programmausschnitt, bei dem der LED-Pin gar
nicht genannt wurde. Warum muss man die Leute immer wieder darauf
hinweisen, einen vollständigen Code zu posten, der den Fehler enthält?
> ... aber nur beim 44A, der 44 ...
So tief bin ich nicht eingestiegen, ich verließ mich auf die
Interruptvektorentabelle von Microchip, und dort finde ich weder 441
noch 44A, sondern nur 44 mit 'EXT_INT0_vect'.
S. Landolt schrieb:> ich verließ mich auf die> Interruptvektorentabelle von Microchip, und dort finde ich weder 441> noch 44A, sondern nur 44 mit 'EXT_INT0_vect'.
Den 441 habe ich auch nicht angeschaut.
Das Problem war aber nicht die Bezeichnung im Datenblatt von Microchip
(beide waren mit INT0 angegeben), sondern in den Headerdateien der
üblichen Compiler. Ich habe bei mehreren geschaut, weil meiner ja schon
älter ist - überall gleich. Da war für den 44 sowohl INT0_vect als auch
EXT_INT0_vect definiert, für den 44A jedoch nur letzteres. Und noch
SIG_INTERRUPT0 für den 44.
Ich bezeichne es noch immer als Unsauberkeit in den Headerdateien, einen
anderen Grund sehe ich momentan nicht. Und es behindert den Umstieg vom
44 auf den 44A.
PS:
Also um ehrlich zu sein, hatte ich später mit meiner
zusammengestoppelten C-Umgebung für den ATtiny44 beides, also INT_vect
und EXT_INT_vect, ausprobiert, und fand in beiden Fällen im
Assemblerlisting das korrekte "0x34 <__vector_1>".
Da Marlin auch von Problemen mit der C-Umgebung sprach, grauste es
mir, ich vergaß das Ganze schnellstens und freute mich auf mein nächstes
Assemblerprogramm.
S. Landolt schrieb:> Also um ehrlich zu sein, hatte ich später mit meiner> zusammengestoppelten C-Umgebung für den ATtiny44 beides, also INT_vect> und EXT_INT_vect, ausprobiert, und fand in beiden Fällen im> Assemblerlisting das korrekte "0x34 <__vector_1>"
Ja, sagte ich doch, nur beim 44A passt es nicht.
S. Landolt schrieb:> Nicht das Datenblatt
Naja, wenn der, der die Headerdateien schrieb, nicht dort seine Qelle
hatte, kann es schon mal differieren.
Wichtig ist, das man weiß, dass es Inkonsistenzen geben kann.
HildeK schrieb:> Ja, das war offenbar nur ein Programmausschnitt, bei dem der LED-Pin gar> nicht genannt wurde. Warum muss man die Leute immer wieder darauf> hinweisen, einen vollständigen Code zu posten, der den Fehler enthält?
Der LED Pin war ja nicht das Problem wie im ersten Post geschrieben,
daher hab ich nur die Stelle gepostet die nicht funktioniert. Der Fehler
ist in einem iotn441.h Patch aus dem Netz für den GCC Cross Compiler in
meiner Toolchain.
Hier das gesamte Testprogramm, das läuft mit AVR Studio d.h. ich muss
mich jetzt um die korrekten Includes kümmern. Da fehlte im Vergleich zu
oben nur die LED Initialisierung, und die war ja schon getestet.
Marlin schrieb:> Hier das gesamte Testprogramm,
Es ist wieder nicht das gesamte Testprogramm. Z.B. die Includes fehlen.
Ein Compiler wird das so nicht übersetzen.
Meine Kritik war dahingehend gemeint: Du zeigst nur einen Ausschnitt und
die ersten Antworten bemängeln bereits fehlende Teile. Die sind zwar in
deinem vollständigen Programm enthalten. Das wäre nicht der Fall, wenn
das, was du zeigst, übersetzbar ist und auch das Fehlverhalten zeigt. Es
muss nicht dein gesamtes Programm sein, aber der Ausschnitt sollte für
einen Helfer in seine Umgebung kopierbar und übersetzbar sein.
…besonders wenn man Prozeduren leer lässt, die der Compiler dann
entsorgen darf. Du patchst am GCC herum, für deine eigene Toolchain? Was
ist am AVR-GCC schlecht? Ich betreibe auch gern mal Compiler-Pr0n (das
andere Wort triggert eine Spam-Meldung) und mache etwas Crossdev, aber
den AVR-GCC würd' ich nie gegen den Gnu-CC tauschen wollen. Woher sollen
die Gnu-CC-Entwickler die schmotzigen Details der AVR-Experten kennen?
Und wenn ich überheblich sein will, weil ich es besser kann, dann
schreib ich ASM ins C – in 100 Programmen bisher nur ein einziges mal.
HildeK schrieb:> Marlin schrieb:>> Hier das gesamte Testprogramm,>> Es ist wieder nicht das gesamte Testprogramm. Z.B. die Includes fehlen.> Ein Compiler wird das so nicht übersetzen.> Meine Kritik war dahingehend gemeint: Du zeigst nur einen Ausschnitt und> die ersten Antworten bemängeln bereits fehlende Teile. Die sind zwar in> deinem vollständigen Programm enthalten. Das wäre nicht der Fall, wenn> das, was du zeigst, übersetzbar ist und auch das Fehlverhalten zeigt. Es> muss nicht dein gesamtes Programm sein, aber der Ausschnitt sollte für> einen Helfer in seine Umgebung kopierbar und übersetzbar sein.
Ok, verstanden. Ich war nicht davon ausgegangen, daß das jemand versucht
zu übersetzen, sondern eher das ein fachkundiger erfahrener Blick sieht,
ob ich da was grundlegend falsch gemacht habe.
Die includes:
Thread beobachten
Seitenaufteilung abschalten