Ich glaube es gibt keinen Bascom Befehl der das Interruptflag löscht. Im zweifelsfall rufst du eine ASM-Routine auf und machst es per Hand.
Ich glaube es gibt keinen Bascom Befehl der das Interruptflag löscht. Im zweifelsfall rufst du eine ASM-Routine auf und machst es per Hand.
Schaut ruhig mal auf meiner Homepage vorbei :
http://kampis-elektroecke.de
Oder folge mir auf Google+:
Daniel Kampert
Es gibt 10 Arten von Menschen. Die einen können Binär, die anderen nicht.
Gruß
Daniel
Da glaubst Du falsch.
Wobei ich zugebe, dass ich es auch schon mal besser gewusst habe.
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.
Richtig ist also: GIFR = Bits(INTF0)
Damit gibt's das Problem nicht.
Völlig sinnfrei.Im zweifelsfall rufst du eine ASM-Routine auf und machst es per Hand.
Edit:
@stfan1409,
Der Bascom Befehl lautet genauso wie ich ihn geschrieben habe. Die Abfolge RegisterX.BitX = WertX ist Bascom-Standard, nennt sich Bitmanipulation. Aus besagten Grund verwende allerdings Bits(), Info dazu findest Du in der Hilfe.aber natürlich nicht, wie der Bascom-Befehl heißt
Geändert von MagicWSmoke (08.01.2012 um 14:05 Uhr)
Ah ok. Danke für die Korrektur
Schaut ruhig mal auf meiner Homepage vorbei :
http://kampis-elektroecke.de
Oder folge mir auf Google+:
Daniel Kampert
Es gibt 10 Arten von Menschen. Die einen können Binär, die anderen nicht.
Gruß
Daniel
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
Code:'############################################################################### '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
Hoffentlich liegt das Ziel auch am Weg
..................................................................Der Weg zu einigen meiner Konstruktionen
Searcher
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:
Da, wo der Zugriff nicht über ON/OUT stattfindet, sondern per LDS/STS hat sich das Problem wohl gehalten.Code:ETIFR.OCIE1C = 1 LDS R24,0x007C ETIFR.OCIE1C = 1 ORI R24,0x01 STS 0x007C,R24
Für alle Fälle liegst Du mit meinem Vorschlag auf der sicheren Seite.
Werd' das gleich mal melden...
Hoffentlich liegt das Ziel auch am Weg
..................................................................Der Weg zu einigen meiner Konstruktionen
Lesezeichen