Int0 gibt 2 Impulse?!

[Searcher]

Das macht zwar am hier gezeigten Beispiel keine Probleme, aber ansonsten führt GIFR.INTF0 = 1 dazu, dass intern das Register gelesen, das Bit gesetzt und somit mit dem Originalregisterinhalt ver-odert und zurückgeschrieben wird.
Dies führt bei einem Flag-Register zum Löschen aller anderen gesetzten Flags, bei mehreren Interrupt-Ereignissen will man das natürlich nicht.

Das wäre ja eine üble Falle. Zumindest in der Bascom Version 2.0.5.0 sieht es nicht so aus. Hab dazu ein kleines Programm gemacht, compiliert und die hex-Datei mit ReAVR disassemblieren lassen. Relevante ASM Befehle unten im Code.
Weder bei Gifr.intf0 = 1, Gifr = Bits(intf0) oder Set Gifr.intf0 wird Gifr geladen.

Gifr = Gifr Or &B01000000 muß man aber vermeiden

'###############################################################################
'IDE: BASCOM-AVR Demoversion 2.0.5.0
'###############################################################################
$regfile = "attiny45.dat"
$framesize = 32                         'default?
$swstack = 32                           'default?
$hwstack = 34                           'default?
$crystal = 8000000

!nop                                  'nop zum code auffinden in ASM
Gifr.intf0 = 1
!nop
Gifr = Bits(intf0)
!nop
Set Gifr.intf0
!nop
Gifr = Gifr Or &B01000000
!nop

End



ASM von ReAVR V3.2.0

    nop                            'Gifr.intf0 = 1
    ldi    r24,k40
    out    p3A,r24              '3A ist Adresse von GIFR im ATtiny45
    nop                            'Gifr = Bits(intf0)     
    ldi    r24,k40           
    out    p3A,r24
    nop                            'Set Gifr.intf0     
    ldi    r24,k40
    out    p3A,r24
    nop                            'Gifr = Gifr Or &B01000000
    in    r24,p3A
    ori    r24,k40
    out    p3A,r24
    nop

Gruß
Searcher

[MagicWSmoke]

Searcher

Das wäre ja eine üble Falle.

das war eine Falle, die zumindest für Flag-Register im normalen IO-Bereich beseitigt wurde.

Um das wieder rauszukramen musste ich weiter zurückgehen als ich annahm. Ver 1.11.9.8 zeigt den Fehler noch, Ver 2.0.0.0 dagegen nicht mehr.
Gemeldet hab' ich den Bug an Mark im Feb 2010, in der von mir damals moderierten Rubrik steht's zum 21.2.2010, Ver 1.11.9.8, das könnte so passen.

Wie ich gerad' festgestellt hab', gibt's das Problem aber immer noch, sobald auf Ext IO zugegriffen wird.

Bei der von Dir verwendeten Version 2.0.5.0 ist das noch so, genauso in 2.0.7.3
Compilier' doch mal für 'nen ATM128 das hier: ETIFR.OCIE1C = 1, da kommt dann raus:

ETIFR.OCIE1C = 1
LDS       R24,0x007C
ETIFR.OCIE1C = 1
ORI       R24,0x01
STS       0x007C,R24

Da, wo der Zugriff nicht über ON/OUT stattfindet, sondern per LDS/STS hat sich das Problem wohl gehalten.
Für alle Fälle liegst Du mit meinem Vorschlag auf der sicheren Seite.

Werd' das gleich mal melden...

[Searcher]

Für alle Fälle liegst Du mit meinem Vorschlag auf der sicheren Seite.

Vielen Dank für die Tipps! Ich hab mit Ver 1.11.9.8 angefangen und nichts davon gewusst. Werde mich nun sicher an die BITS Funktion gewöhnen.

Gruß
Searcher

[MagicWSmoke]

Vielen Dank für die Tipps!

Bitteschön, gerne

Werde mich nun sicher an die BITS Funktion gewöhnen.

Um ein einzelnes Flag zu löschen, ginge übrigens auch:

ETIFR = 2 ^ OCIE1C

Für mehrere Flags:

Const Clear_Flags = 2 ^ OCIE1C or 2 ^ OCIE3C
ETIFR = Clear_Flags