Hallo Forum Es geht um einen ATTiny 2313 A, den ich auf der Arduino-Umgebung programmiere. Eine Lichtschranke ist an PCINT6 angeschlossen. Im Code ist das Pin 15. Hardware-Pin ist 18. Sobald an der Lichtschranke ein change erkannt wird, soll ein gewisser Code ausgefuehrt werden. Als Beispiel soll eine LED angehen, die angenommen an PCINT5, also Pin 14 angeschlossen ist. Folgenden Code habe ich mir dazu geschrieben: void setup() { PCMSK = (1<<PCINT6); } void loop() { } ISR (PCINT0_vect) { Impuls = Impuls +1 ; digitalWrite(14, HIGH); } Dieses Testprogramm macht also als loop gar nichts, sondern es wird so lange gewartet, bis der Interrupt ausgeloest wird und dann soll die LED leuchten. Die leuchtet aber nie! Ich bin kein Programmierer, sondern Maschinenbauer. Aber fuer meine Maschine die ich baue, benoetige ich diese Funktion. Um Hilfe wird gebeten :-) PS: Der erste Prototyp wurde mit einem Arduino Nano realisiert. Das ging problemlos mit attachInterrupt. Da war die L>ichtschranke an Pin 2 angeschlossen.
Stell den richtigen Code hier rein und nicht irgendwas ähnliches. PCMSK gibt es beim 2313A gar nicht.
> PCMSK = (1<<PCINT6);
Bringt das keinen Fehler? Im Datenblatt finde ich nur PCMSK0.
Ist die Lichtschranke denn so schnell, dass der Interrupt Not tut? Du vertrödelst doch in der Loop sowieso schon Zeit, da kannst du auch darin ständig per digitalRead o.Ä. den Lichtschrankenstatus überwachen. Ansonsten fehlt dir zumindest im GIMSK das PCIE-Bit.
Beitrag #7208826 wurde von einem Moderator gelöscht.
Beitrag #7208839 wurde von einem Moderator gelöscht.
Das ist ja echt verwirrend. In der Datei iotn2313a.h habe ich drei Vektoren gefunden:
1 | #define PCINT0_vect_num 11
|
2 | #define PCINT0_vect _VECTOR(11) /* Pin Change Interrupt Request 0 */ |
3 | |
4 | #define PCINT1_vect_num 19
|
5 | #define PCINT1_vect _VECTOR(19) /* Pin Change Interrupt Request 1 */ |
6 | |
7 | #define PCINT2_vect_num 20
|
8 | #define PCINT2_vect _VECTOR(20) /* Pin Change Interrupt Request 2 */ |
PCINT0_vect ist also richtig. Normalerweise schaue ich immer auf https://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html wie die Interrupt Vektoren heißen müssen. Da habe ich gerade dumm geguckt, denn der ATtiny 2313 mit "A" fehlt dort. Die Doku ist von 2016, sollte man/ich vielleicht besser nicht mehr benutzen. Weiterhin finde ich in der iotn2313a.h Datei folgende relevante Register/Bits, was zum Datenblatt passt:
1 | #define GIMSK _SFR_IO8(0x03B)
|
2 | #define PCIE1 3
|
3 | #define PCIE2 4
|
4 | #define PCIE0 5
|
5 | #define INT0 6
|
6 | #define INT1 7
|
7 | |
8 | #define PCMSK _SFR_IO8(0x020)
|
9 | #define PCMSK0 _SFR_IO8(0x020)
|
10 | #define PCINT0 0
|
11 | #define PCINT1 1
|
12 | #define PCINT2 2
|
13 | #define PCINT3 3
|
14 | #define PCINT4 4
|
15 | #define PCINT5 5
|
16 | #define PCINT6 6
|
17 | #define PCINT7 7
|
18 | |
19 | #define PCMSK1 _SFR_IO8(0x004)
|
20 | #define PCINT8 0
|
21 | #define PCINT9 1
|
22 | #define PCINT10 2
|
23 | |
24 | #define PCMSK2 _SFR_IO8(0x005)
|
25 | #define PCINT11 0
|
26 | #define PCINT12 1
|
27 | #define PCINT13 2
|
28 | #define PCINT14 3
|
29 | #define PCINT15 4
|
30 | #define PCINT16 5
|
31 | #define PCINT17 6
|
Da sehen wir, warum er für PCMSK keine Fehlermeldung bekommen hat. PCMSK = PCMSK0. Also hat ernst es wohl fast richtig getroffen: Εrnst B. schrieb: > Ansonsten fehlt dir zumindest im GIMSK das PCIE-Bit. Das Bit heißt PCIE0.
Stefan ⛄ F. schrieb: > Normalerweise schaue ich immer auf > https://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html > wie die Interrupt Vektoren heißen müssen. Da habe ich gerade dumm > geguckt, denn der ATtiny 2313 mit "A" fehlt dort. Die Doku ist von 2016, > sollte man/ich vielleicht besser nicht mehr benutzen. Jetzt wollte ich eine aktuelle Variante von der Doku finden und musste zu meinem erstaunen feststellen, dass die von Microchip ebenso veraltet ist: https://onlinedocs.microchip.com/pr/GUID-317042D4-BCCE-4065-BB05-AC4312DBC2C4-en-US-2/index.html Weiß jemand, wo die aktuelle Doku liegt?
Hallo Ernst B. Die bisherigen Antworten helfen mir als *Nicht-Programmierer absolut nicht weiter, weshalb ich deinen Vorschlag bevorzuge. Hier der Code, den ich geschrieben habe, um die gewuenschte Funktion zu erhalten. Weiter unten erklaere ich, was er bewirken soll ( aber leider noch nicht tut) void warte_auf_stillstand() { Stillstand = false ; flag = 0; LS = digitalRead(Pin_LS); LS_initial = LS; while (!Stillstand) while (flag != 0 ) {currentMillis = millis(); LS = digitalRead(Pin_LS); if (LS != LS_initial) { flag = 1; LS_initial = LS; // es herrscht also Bewegung } if (currentMillis - previousMillis >= 5000) { previousMillis = currentMillis; LS= digitalRead (Pin_LS ); } } Impuls = 0; beide_nach_oben(); delay(1500); } Eigentlich ist der Code bereits anhand der Variablen-Namen selbsterklaerend. Was genau soll er bewirken: Die Funktion warte_auf_Stillstand soll das Programm so lange lahmlegen, bis ein Stillstand erkannt wurde. Stillstand = keine Impulse binnen der naechsten 5 Sekunden. Das ist auch schon alles :-) Wer mir dabei hilft, diesen Code lauffaehig zu machen, der erhaelt ein Produkt bis maximal Euro 50.- seiner Wahl aus dem KPF-Zeller-Shop gratis. Versprochen.
Matthias schrieb: > Die bisherigen Antworten helfen mir als *Nicht-Programmierer absolut > nicht weiter Warum programmierst du dann? Ich denke du kannst das lernen, wenn du willst. Ohne es zu lernen wirst du vermutlich schon morgen am nächsten Punkt hängen bleiben. Wir können dir nicht alles vorkauen.
Wie ich oben bereits schrieb. Ich programmiere, weil ich es fuer mein Produkt benoetige. Und ich bin bereit, mich erkenntlich zu zeigen. Es gibt keinen naechsten Punkt, ich bin kein Programmierer.
Hat da jemand ohne Benachrichtigung etwas an meinen Zeilen manipuliert?
Matthias schrieb: > Das ging problemlos mit attachInterrupt. Warum nimmst Du das dann nicht wieder? Matthias schrieb: > Im Code ist das Pin 15. > Hardware-Pin ist 18 > Als Beispiel soll eine LED angehen, die angenommen an PCINT5, also Pin > PCMSK = (1<<PCINT6); Verwirrt? PCTINT5 oder 6? Beim 2313A in Bauform MLF/VQFN ist PCINT 5 an Pin 15, PCINT6 ist an Pin 16. Konfiguriert man zu Fuß: PCMSK0 = (1<<PCINT5); GIMSK = (1<<PCIE0); SEI();
Fehler gefunden: es muss heissen: sei(); Und nun versuche ich, wieder per attachInterrupt das Ganze hinzubekommen und melde mich dann wieder.
Matthias schrieb: > Fehler gefunden: > es muss heissen: > sei(); Solche überschwenglichen Dankbekundungen wäre aber jetzt wirklich nicht nötig gewesen. Dass das sei() fehlen könnte, schrieb Dir übrigens ein Teilnehmer in der ersten Antwort. S. Landolt schrieb: > Ist dort kein sei nötig? Ich würde auch wetten, dass Dein vorheriger Entwurf keinerlei Hinweis auf GIMSK enthielt.
Ich glaube wirklich, dass ihr alle mich komplett falsch einschaetzt. Was sei () und all das andere bedeutet: Das weiss ich alles nicht. Ich fummele mir hier Bruchstuecke aus verschiedenen Quellen zusammen und hoffe so, es irgendwann zu einem Erfolg zu bringen. Nochmals: Ich habe keine tiefgreifenden Programmierkenntnisse. Ich kann einfache BASIC-Programme schreiben und moechte mein Wissen dahingehend auch nicht erweitern. Sonst haette ich einen Kurs besucht anstatt in Foren um Hilfe zu betteln. Das mit dem attachInterrupt hat uebrigens nicht funktioniert. Die Interrupt-Routine wird nach wie vor nicht aufgerufen.
Matthias schrieb: > Ich glaube wirklich, dass ihr alle mich komplett falsch einschaetzt. Meine Einschätzung ist, dass Du ein undankbarer, arroganter Klotz bist. Was Du zusätzlich bist oder willst, ist nicht von Bedeutung.
Wenn du meine Zeilen korrekt liest wirst du feststellen, dass es genau umgekehrt ist. Ich suche nach Hilfe nicht weil ich arrogant bin, sondern weil ich keine Ahnung von dieser Materie habe. Toll waere, wenn sich jemand kurz die Zeit nehmen koennte und mir ein paar Zeilen eines funktionierenden Quellcodes hier reinschreiben kann. Alles andere wird mir nicht viel Helfen, da ich wie gesagt kaum weiss, was ich da mache. Sorry, falls du mich da in irgendeiner Weise missverstanden hast.
Wenn du mir eine Email sendest an service@kpf-zeller.de, dann sende ich dir meinen kompletten Quellcode zu, damit du da mal drueberschauen kannst. Waere klasse.
Bitte Thema schliessen. Es funktioniert nun. Der Fehler lag daran, dass die Lichtschranke nicht an Pin 15, sondern an Pin 16 angeschlossen ist. Heftiger Irrtum also meinerseits. Mein nunmehr funktionierender Code lautet wie folgt: PCMSK0 = (1<<PCINT7); GIMSK = (1<<PCIE0); sei(); attachInterrupt(digitalPinToInterrupt(PCINT7),zaehlen, CHANGE); Vielen Dank an alle, die hier mitgeholfen haben.
Stefan ⛄ F. schrieb: > Normalerweise schaue ich immer auf > https://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html > wie die Interrupt Vektoren heißen müssen. Da habe ich gerade dumm > geguckt, denn der ATtiny 2313 mit "A" fehlt dort. Stefan ⛄ F. schrieb: > Jetzt wollte ich eine aktuelle Variante von der Doku finden und musste > zu meinem erstaunen feststellen, dass die von Microchip ebenso veraltet > ist: > https://onlinedocs.microchip.com/pr/GUID-317042D4-BCCE-4065-BB05-AC4312DBC2C4-en-US-2/index.html > > Weiß jemand, wo die aktuelle Doku liegt? Ganz oben beim zweiten Link steht "The latest version of this document is always available from http://savannah.nongnu.org/projects/avr-libc/ " Da dreht man sich natürlich im Kreis bzw. es bedeutet wohl, dass es keine aktuellere Doku gibt. In dieser App-Note werden aber die Unterschiede zw. ATtiny2313 und ATtiny2313A beschrieben: AVR533: Migrating from ATtiny2313 to ATtiny2313A https://ww1.microchip.com/downloads/en/Appnotes/doc8261.pdf Table 3-2. New Interrupt Vectors in ATtiny2313A Vector Address Source 20 0x013 Pin Change Interrupt Request A 21 0x014 Pin Change Interrupt Request D
MWS schrieb: > Meine Einschätzung ist, dass Du ein undankbarer, arroganter Klotz bist. > Was Du zusätzlich bist oder willst, ist nicht von Bedeutung. *Vorsicht vor dem bissigen Hund!*
Matthias schrieb: > Es funktioniert nun. > > Der Fehler lag daran, dass die Lichtschranke nicht an Pin 15, sondern an > Pin 16 angeschlossen ist. > Heftiger Irrtum also meinerseits. Aha. Laut Datenblatt befindet sich PCINT7 bei Bauform PDIP/SOIC an Pin 19, bei Bauform MLF/VQFN an Pin 17. Wenn PCINT7 bei Dir an Pin 16 liegt, dann erklär' mal, welche interessante Bauform Du verwendest.
Matthias schrieb: > Der Fehler lag daran, dass die Lichtschranke nicht an Pin 15, sondern an > Pin 16 angeschlossen ist. Heftiger Irrtum also meinerseits. Darauf hatte MWS schon gestern hingewiesen.
Die Sache mit den Pins hat mich Anfangs ja auch verwundert. Fakt ist, dass der Hardware-Pin 19 im Code mit 16 angesprochen werden muss. Anbei ein Bild.
Matthias schrieb: > Die Sache mit den Pins hat mich Anfangs ja auch verwundert. > Fakt ist, dass der Hardware-Pin 19 im Code mit 16 angesprochen werden > muss. Oder als PB7. Ist jetzt nicht wirklich überraschen, denn es steht klipp und klar im Datenblatt. Stefan ⛄ F. schrieb: > Ohne es zu lernen wirst du vermutlich schon morgen am nächsten > Punkt hängen bleiben. Ich hab's dir gestern gesagt. Aber du gibst lieber patzige Antworten.
Ich versuche, meine Ausgangssituation nochmals zu erklaeren, dann wird das mit den Pins eventuell besser erklaert. Zunaechst basierte mein Programm auf einem Arduino Nano. Dort war die Lichtschranke an Pin 2 angeschlossen, also konnte ich dort mit attachInterrupt mit Pin 2 das ganze zum Laufen bekommen. -------------- Dann habe ich anstatt dem Nano einen ATTiny 2313A verwendet. Dort wurde die Lichtschranke an Hardware-Pin 19 angeschlossen. Um die Lichtschranke ohne Interrupt, also nur mit digitalRead anzusprechen, musste ich den Pin 16 verwenden ( siehe Bild eins weiter oben) Warum das so ist, ist fuer mich nicht erklaerbar. Auch nur durch das zufaellige Finden dieses Bildes konnte ich ueberhaupt erstmals die Lichtschranke einlesen. ------------- Beim Versuch, diese Sache mit einem Interrupt zu loesen bin ich nun der Logik ( MEINER Logik ;-) ) davon ausgegangen, dass ich auch hier diesen Pin 16 anzuwenden habe. Hoffentlich kann das jemand entwirren :-)
Wie gesagt: Es funktioniert jetzt. Der von mir verwendete Code steht weiter oben. Ich melde mich somit dankend ab. :-)
Matthias schrieb: > Um die Lichtschranke ohne Interrupt, also nur mit digitalRead > anzusprechen, musste ich den Pin 16 verwenden ( siehe Bild eins weiter > oben) > Warum das so ist, ist fuer mich nicht erklaerbar. Die Erklärung liegt darin, dass es eine Eigenart von Arduino ist, die Portpins beginnend von 0 an durchzuzählen und das nicht unbedingt in der erwarteten Reihenfolge PortA, B, C, D... "Pin in Code" entspricht damit nicht "Pin an µC". Benutzt man die Kapselung durch Arduino, so muss für dessen Befehle die Arduino-Nummerierung verwendet werden, spricht man dagegen direkt mit dem Compiler ohne das Arduino-Gedöns selbst, dann sind die Bezeichner des Compilers zu verwenden. Die genauen Bezeichner/Nummern gehen aus Deinem verlinkten Bild hervor, oder auch aus dem Schaltplan des jeweiligen Modells. Matthias schrieb: > Fakt ist, dass der Hardware-Pin 19 im Code mit 16 angesprochen werden > muss. > Anbei ein Bild. Das lag vor Deiner Nase.
MWS schrieb: > Die genauen Bezeichner/Nummern gehen aus Deinem verlinkten Bild hervor, > oder auch aus dem Schaltplan des jeweiligen Modells. Oder man nutzt die netterweise in manchen Arduino-Geschmacksrichtungen (z.B. "MiniCore") vorhandenen #defines, hier PIN_PB7, um die besch***eidenen Arduino-Pin-Nummern wieder durch vernünftige Namen zu ersetzen. sh. pins_arduino.h https://github.com/MCUdude/MiniCore/blob/master/avr/variants/standard/pins_arduino.h#L154 (der Link passt nicht zum Attiny2313A)
Hallo Forum. Ich hatte das Thema als erledigt abgehakt. Dem ist leider nicht so. Etwas ganz kurioses passiert - und das erklaere ich vorab nur einmal erst in schnellen Worten, vielleicht mache ich da ja noch etwas Grundlegendes verkehrt. Der code im setup umfasst unter anderem: PCMSK0 = (1<<PCINT7); GIMSK = (1<<PCIE0); sei(); attachInterrupt(digitalPinToInterrupt(PCINT7),zaehlen, CHANGE); ATTiny wird mit Strom versorgt. Er fuehrt seine Initialisierung im void setup ordnungsgemaess durch. Das erkenne ich daran, dass er im setup einen Motor ansteuert. Nach durchlaufenem setup habe ich jetzt versuchsweise eine void loop mit { } erstellt. Jetzt kommt das Kuriose: Sobald sich nun der Zustand an PCINT7 aendert, fuehrt der ATTiny einen Reset durch und startet erneut. Fuer mich ( wie immer ) voellig unverstaendlich. Habe ich etwas vergessen? Beste Gruesse.
Fehlt die dazugehorige Interruptroutine? Anders gefragt: wie sieht die ISR für PCINT7 aus?
Matthias schrieb: > attachInterrupt(digitalPinToInterrupt(PCINT7),zaehlen, CHANGE); Lies dir bitte die Doku zur Funktion attachInterrupt noch mal durch. PCINT7 ist kein Pin.
Matthias schrieb: > Ich hatte das Thema als erledigt abgehakt. > Dem ist leider nicht so. War mir klar. Bildlich gesprochen hasst du gerade ein Tintenfass in deinen Laserdrucker gekippt und wunderst dich nun, dass dein Federhalter immer noch nicht schreibt. Vielleicht arbeitest du erst mal das Datenblatt und ein Tutorial für deinen Mikrocontroller durch, dann eins für Arduino. Dann wird dir auch klar, warum man nicht alles wild miteinander vermischen kann.
Matthias schrieb: > PCMSK0 = (1<<PCINT7); > GIMSK = (1<<PCIE0); > sei(); > attachInterrupt(digitalPinToInterrupt(PCINT7),zaehlen, CHANGE); Entweder C-, oder Arduino-Sprech verwenden, die 3 ersten Zeilen entsprechen der vierten, würden jedoch eine ISR namens "PCINT0_vect" gegenüber "zaehlen" erwarten.
was ich nicht verstehe: All eure Antworten zeigen mir meine FEHLER auf. Warum gibt es da nicht EINE Antwort fuer eine moegliche Loesung?
Matthias schrieb: > was ich nicht verstehe: > All eure Antworten zeigen mir meine FEHLER auf. > Warum gibt es da nicht EINE Antwort fuer eine moegliche Loesung? Bist Du blind? Du schaffst es nicht einmal die Minimalanforderung zu erfüllen, den fehlerhaften Code einzustellen, beschwerst Dich hingegen, wenn Dir keine goldene Federchen in den Allerwertesten geblasen werden. Du taugst weder für die Aufgabe noch für die Kommunikation darum, geh' Bäume fällen oder planz' Gartenzwerge.
Beschwere ich mich? Oder suche ich viel eher nach wie vor haenderingend um Hilfe? Da haben ein paar Helfer mittlerweile einige sinnvolle Kommentare hinterlassen, denen ich auf den Grund gehen werde. Danke :-)
Letztmaliges Update: Es funktioniert! Yippie. Ernst B. : Deine Zeilen waren es, die mir letztendlich geholfen hatten. Danke an dich :-)
Matthias schrieb: > Beschwere ich mich? Ja. > Oder suche ich viel eher nach wie vor haenderingend um Hilfe? Ja und das bald wieder.
Matthias schrieb: > Warum gibt es da nicht EINE Antwort fuer eine moegliche Loesung? Weil es auf Dauer nur hilft, wenn du selbst die Lösung findest. Kennst du diesen Spruch: "Gib dem Hungrigen keinen Fisch sondern eine Angel"?
Georg G. schrieb: > "Gib dem Hungrigen keinen Fisch sondern eine Angel"? Nein, hier sieht man mal wieder, wie nützlich es sein kann, auf die Assemblerprogrammierstufe zu gehen. Gerade beim Portieren von einem Target auf das andere wird nicht jeder x-beliebige C-Compiler mitspielen mögen. Bei ASM muss ich zwangsläufig alles auskommentieren. Dann sehe ich aber auch, wie die "Maschine" tickt, oder warum nicht. Erst mal das richtige inc-File angeben. ciao gustav P.S.: Ja, Atmel Studio 4.19 läuft mit Prolific-USB auch auf Windows 11.
:
Bearbeitet durch User
Du mußt Dich einfach nur entscheiden. Entweder Du schreibst Init und Interrupt in C oder Du benutzt die Arduino-Funktionen. Beides durcheinander zu mixen geht beliebig schief. Schon die Pin-Syntax unterscheidet sich erheblich.
Dyson schrieb: > PCMSK > gibt es beim 2313A gar nicht. Bist Du Dir da sicher? .equ PCMSK = 0x20 Number : AVR000 ;* File Name : "tn2313Adef.inc" ;* Title : Register/Bit Definitions for the ATtiny2313A ;* Date : 2011-08-25 ;* Version : 2.35 ;* Support E-mail : avr@atmel.com ;* Target MCU : ATtiny2313A File Name : "2313def.inc" hat's allerdings nicht ciao gustav
Ich finde den Blick in die *.inc Dateien wenig sinnvoll, denn die sind für Assembler, nicht für C. Schaut doch lieber in die *.h Dateien, die wirklich verwendet werden. Ich habe bereits aus ihnen zitiert, siehe Beitrag "Re: Interrupt mit ATTiny 2313A"
Stefan ⛄ F. schrieb: > Da habe ich gerade dumm > geguckt, denn der ATtiny 2313 mit "A" fehlt dort. ... Das war wohl damals eine größere Umstellung bei Atmel (heute Microchip) in der Waferproduktion. Es betraf auch alle Serien; die ICs wurden dann etwas billiger. Neben der (positiven) Verringerung der Stromaufnahme wurden die Eingänge leider auch etwas empfindlicher gegen (normalerweise nicht auftretende) negative Spannungen. Bei einigen AVRs wurden dabei kleine Ergänzungen eingefügt, wie hier beim 2313A, sie blieben aber weitgehend abwärtskompatibel.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.