Forum: Mikrocontroller und Digitale Elektronik Interrupt mit ATTiny 2313A


von Matthias (Gast)


Lesenswert?

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.

von S. Landolt (Gast)


Lesenswert?

> Arduino-Umgebung

Ist dort kein sei nötig? Weiß nicht.

von Dyson (Gast)


Lesenswert?

Stell den richtigen Code hier rein und nicht irgendwas ähnliches. PCMSK 
gibt es beim 2313A gar nicht.

von S. Landolt (Gast)


Lesenswert?

> PCMSK  = (1<<PCINT6);

Bringt das keinen Fehler? Im Datenblatt finde ich nur PCMSK0.

von Εrnst B. (ernst)


Lesenswert?

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.
von Stefan F. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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?

von Matthias (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

Hat da jemand ohne Benachrichtigung etwas an meinen Zeilen manipuliert?

von MWS (Gast)


Lesenswert?

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();

von Matthias (Gast)


Lesenswert?

Als Meldung erhalte ich:

SEI() was not declared in this scope.

von Matthias (Gast)


Lesenswert?

Fehler gefunden:

es muss heissen:

sei();

Und nun versuche ich, wieder per attachInterrupt das Ganze hinzubekommen 
und melde mich dann wieder.

von MWS (Gast)


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

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.

von MWS (Gast)


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

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.

von Alexander S. (alesi)


Lesenswert?

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

von Oszi Osborn (Gast)


Lesenswert?

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!*

von MWS (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Matthias (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

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 :-)

von Matthias (Gast)


Lesenswert?

Wie gesagt:
Es funktioniert jetzt.
Der von mir verwendete Code steht weiter oben.

Ich melde mich somit dankend ab.

:-)

von MWS (Gast)


Lesenswert?

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.

von Εrnst B. (ernst)


Lesenswert?

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)

von Matthias (Gast)


Lesenswert?

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.

von S. Landolt (Gast)


Lesenswert?

Fehlt die dazugehorige Interruptroutine? Anders gefragt: wie sieht die 
ISR für PCINT7 aus?

von Georg G. (df2au)


Lesenswert?

Matthias schrieb:
> attachInterrupt(digitalPinToInterrupt(PCINT7),zaehlen, CHANGE);

Lies dir bitte die Doku zur Funktion attachInterrupt noch mal durch. 
PCINT7 ist kein Pin.

von Stefan F. (Gast)


Lesenswert?

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.

von MWS (Gast)


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

was ich nicht verstehe:
All eure Antworten zeigen mir meine FEHLER auf.

Warum gibt es da nicht EINE Antwort fuer eine moegliche Loesung?

von MWS (Gast)


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

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 :-)

von Matthias (Gast)


Lesenswert?

Letztmaliges Update:

Es funktioniert!  Yippie.

Ernst B.  : Deine Zeilen waren es, die mir letztendlich geholfen hatten.

Danke an dich :-)

von MWS (Gast)


Lesenswert?

Matthias schrieb:
> Beschwere ich mich?

Ja.

> Oder suche ich viel eher nach wie vor haenderingend um Hilfe?

Ja und das bald wieder.

von Georg G. (df2au)


Lesenswert?

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"?

von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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.

von Karl B. (gustav)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

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"

von Uuu B. (hansdampf2)


Lesenswert?

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.

von helf_ender (Gast)


Lesenswert?

Erkennt ihr, dass ihr off-topic arbeitet?

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
Noch kein Account? Hier anmelden.