Hallo, ich sitze nun schon seit Stunden am externen Interrupt und sehe langsam den Wald vor lauter Bäumen nicht. Mein Interrupt soll einfach nur bei steigender Flanke auslösen, einen Wert hoch zählen und dann wie den Rest auch auf meinem Display bzw UART ausgeben. Ich habe das Gefühl der Interrupt löst nicht aus oder ich mache etwas grundlegendes bei der weiteren Verarbeitung falsch. Das Signal kommt am Pin an. Das habe ich mit dem Oszi gecheckt.
initInterrupt() auskommentiert
Gast
#4885002
wo wird denn initInterrupt aufgerufen? was soll das darstellen?
1 | |
und cli() und sei() habe auch nichts in einer ISR zu suchen.
Johnny B. schrieb: > initInterrupt() auskommentiert Die ist inzwischen leer, deswegen auch auskommentiert. Das findet derzeit in der normalen init() statt.
Christian M. schrieb: > Johnny B. schrieb: >> initInterrupt() auskommentiert > > Die ist inzwischen leer, deswegen auch auskommentiert. Das findet > derzeit in der normalen init() statt. Na dann bitte den aktuellen Code wieder reinstellen, ist ja kein Quiz zum Zeitvertreib hier.
Gast
#4885014
Peter II schrieb: > und cli() und sei() habe auch nichts in einer ISR zu suchen Das wird in diesem konkreten Fall richtig sein, ist aber in dieser allgemeinen Form/Ansage falsch. Wobei, ich würde dann, wenn es nötig ist, sicherlich auf die atomic Macros zurückgreifen, aber die mache im Grunde ja das gleiche.
Gast
#4885015
Arduino F. schrieb: > Das wird in diesem konkreten Fall richtig sein, ist aber in dieser > allgemeinen Form/Ansage falsch. ok, gilt für die Atmels ( 8bitter). > Wobei, ich würde da sicherlich auf die atomic Macros zurückgreifen, aber > die mache im Grunde ja das gleiche. auch das mach in einer ISR keine sinn.
Johnny B. schrieb: > Christian M. schrieb: >> Johnny B. schrieb: >>> initInterrupt() auskommentiert >> >> Die ist inzwischen leer, deswegen auch auskommentiert. Das findet >> derzeit in der normalen init() statt. > > Na dann bitte den aktuellen Code wieder reinstellen, ist ja kein Quiz > zum Zeitvertreib hier. Gerne auch wenn es keine Änderung am ausgeführten Code gibt. Peter II schrieb: > wo wird denn initInterrupt aufgerufen? > > was soll das darstellen? > >
1 | |
2 | |
Ein Überbleibsel meiner vielen Versuche. Ist entfernt > > und cli() und sei() habe auch nichts in einer ISR zu suchen. Ebenso entfernt
Gast
#4885028
initInterrupt ist doch immer noch aus kommentiert.
Gast
#4885030
Peter II schrieb: > auch das mach in einer ISR keine sinn. Du bist zu absolut. Macht selten Sinn, da stimme ich zu. Man muss dann extrem aufpassen, da stimme ich auch zu. Aber KEINEN Sinn? Im Sinne von NIE? Da gibts einen Einspruch!
Wenn ich das lese: Christian M. schrieb: > einen > Wert hoch zählen und dann wie den Rest auch auf meinem Display bzw UART > ausgeben. und das lese:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
dann scheint mir das Programm beim "hochzählen" nicht allzu weit zu kommen, selbst wenn der Interrupt triggert.
Peter II schrieb: > initInterrupt ist doch immer noch aus kommentiert. So ist es.
Christian M. schrieb: > ich sitze nun schon seit Stunden am externen Interrupt und sehe langsam > den Wald vor lauter Bäumen nicht. Und warum fällst du die Bäume dann nicht?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
Wenn das geht, bist du schon mal nicht zu doof, den Interrupt einzuschalten. Vor allen Dingen erhärtet es den Verdacht, daß der Fehler ganz woanders liegt. Arduino F. schrieb: > Aber KEINEN Sinn? > Im Sinne von NIE? > Da gibts einen Einspruch! Genau: Blödsinn, Unsinn, Schwachsinn,... Jede Menge Sinn.
Gast
#4885072
Welcher µC wird benutzt?
So, das war gestern nicht mehr mein Tag. Geistig war nicht nicht mehr so fit (wie man initInterrupt gesehen hat). Also habe ich alles weggelegt und gehe heute mit "leerem Kopf" wieder ran. Zur Info, ich nutze einen Mega16. Als erstes habe ich den Vorschlag umgesetzt: Thomas E. schrieb: > Christian M. schrieb: > Und warum fällst du die Bäume dann nicht? Ich habe alles raus geschmissen und folgenden Code geschrieben. Zuerst ohne Ausgabe auf dem Display, als das klappte mit dem Display:
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 | |
Und siehe da. Es funktioniert. Also doch nicht ganz doof. Jetzt versuche ich Schritt für Schritt wieder den Rest einzubinden. Ich habe eine Ahnung an was es liegen könnte aber erklären werde ich es mir nicht können. Dazu fehlt mir das tiefer gehende Wissen. Jetzt erst mal sehen wie weit ich komme.
Gast
#4885818
Christian M. schrieb: > uart_puts(itoa (way, s, 10)); der zugriff auf way muss bei einer 16bit variabel Atomar sein.
1 | |
2 | |
3 | |
4 | |
5 | |
Peter II schrieb: > Christian M. schrieb: >> uart_puts(itoa (way, s, 10)); > > der zugriff auf way muss bei einer 16bit variabel Atomar sein. > >
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Ok das sind jetzt Regionen über die ich schon was gelesen habe, aber mich nicht so gut auskenne. Muss ich dass dann auch hier vorher machen? Also atomar?
1 | |
Gast
#4886363
Christian M. schrieb: > Ok das sind jetzt Regionen über die ich schon was gelesen habe, aber > mich nicht so gut auskenne. Gute Gelegenheit da weiter zu machen...!! Tipp: Wenn du einmal das "Warum atomar?" verstanden hast, dann ist das "Was atomar?" leicht selber zu beantworten. (vermute ich mal)
Gast
#4886372
Christian M. schrieb: > Muss ich dass dann auch hier vorher machen? Also atomar?tmp8 = > convertWay(way); vermutlich, aber ich kann nicht wissen wo du das convertWay im Code hinschreibt. In dem letzten Quellcode gibt es das noch nicht.
Arduino F. schrieb: > Christian M. schrieb: >> Ok das sind jetzt Regionen über die ich schon was gelesen habe, aber >> mich nicht so gut auskenne. > > Gute Gelegenheit da weiter zu machen...!! > > Tipp: > Wenn du einmal das "Warum atomar?" verstanden hast, dann ist das "Was > atomar?" leicht selber zu beantworten. > (vermute ich mal) Soweit ich das verstanden habe, wird bei der atomaren Schreibweise (kann man das so nennen?) verhindert, dass sich ein Wert aus dem Interrupt ändert, während dieser Wert weiter verarbeitet wird. Ganz grob gesagt, es ist ähnlich einem cli(). Gerade bei 16bit großen Zahlen, die in zwei 8bit-Paketen verarbeitet werden kann es sein, dass dann die einen 8bit (LSB, denke ich oder umgekehrt) zum alten Wert gehören während die anderen (MSB)bei einem inzwischen erfolgten Interrupt die neuen Werte haben könnten.
Peter II schrieb: > Christian M. schrieb: >> Muss ich dass dann auch hier vorher machen? Also atomar?tmp8 = >> convertWay(way); > > vermutlich, aber ich kann nicht wissen wo du das convertWay im Code > hinschreibt. In dem letzten Quellcode gibt es das noch nicht. Habe hier meinen aktuellen Code. Läuft im groben und ganzen ganz gut. Habe die Variable way für einen anderen Wert genommen und die alte way in pulse umbenannt. Jetzt stehe ich nur vor der Aufgabe meine UART- und Displayausgabe aus der main () zu bekommen bzw zu vereinfachen. Und das am Ende bei meiner Weganzeige die Nachkommastelle richtig angezeigt wird wenn die Zahl negativ ist.
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 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
Gast
#4886398
Christian M. schrieb: > if (PIND & (1<<SENSOR1B)) { > pulse ++; > } > if (!(PIND & (1<< SENSOR1B))) { > pulse --; > } das sieht doch stark nach einen Drehgeber aus, wenn ja ist es so nicht zu empfehlen. https://www.mikrocontroller.net/articles/Drehgeber
Peter II schrieb: > Christian M. schrieb: >> if (PIND & (1<<SENSOR1B)) { >> pulse ++; >> } >> if (!(PIND & (1<< SENSOR1B))) { >> pulse --; >> } > > das sieht doch stark nach einen Drehgeber aus, wenn ja ist es so nicht > zu empfehlen. > > https://www.mikrocontroller.net/articles/Drehgeber Du meinst wegen dem Prellen? Ich habe hier einen bzw. später zwei Glasmaßstäbe, das sollte, falls du das prellen meinst, keine Rolle spielen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.