Gast
#3971496
Ich bastel immer noch an meinem twi rum. Nachdem er sich eh bei der Benutzung der Atmel ASF routinen nach einer gewissen Laufzeit aufhängt versuche ich seit gestern das senden von Bytes interrupt basiert zu lösen. Nachdem ich die routinen eigentlich schon trocken vorgeschrieben hatte, habe ich das Ganze wieder auf ein Minimum reduzieren müssen, da ich schon ein grundlegendes Problem habe. Sobald ich (nach initialisierung des NVIC und des TWI) das interrupt enable register (IER) beschreibe und dort die Flags TXCOMP und TXRDY setze bleibt der Prozessor immer in dem TWI0_Handler. Der nachfolgende Code wird nicht mehr ausgeführt. Steppe ich allerdings im einzelschrittmodus beim Debuggen durch, wird auch der nachfolgende Code ausgeführt. Sonst nicht. Die Flags TXCOMP und TXRDY sind natürlich (automatisch) gesetzt im Status Register (SR). Aber kommt deshalb der Interrupt andauernt? Ist das so gedacht? Soll man den in der Handler disabeln und zum Ende des Handlers, wenn man auf ein bestimmtes Flag wartet, wieder einschalten?! Ich dachte eher, dass wenn eine !Änderung! im SR vorhanden ist der Interrupt (wenn die Maske übereinstimmt) auslöst und ich dann das SR auslese und "gucke" was passiert ist. Und erst dann der nächste Interrupt ausgelöst wird, wenn sich das SR ändert! Muss ich den interrupt noch irgendwie bestätigen?! Eigentlich ja nicht oder? Meine timer interrupts etc. funktionieren ja auch tadellos. Nur bei dem TWI ist es irgendwie verrückt. Atmel selbst hält sich auch ziemlich bedeckt im Datenblatt was den TWI mit Interrupts angeht. Demnach ist es einfach (was ich auch bis gestern Mittag dachte). Hier der Code
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |