|
-- > Most of HC11/HC12/HCS12 flags are cleared by writing > '1' (one) to flag. That's why PIFP|=0x80 should work for > PIFP.bit7, > but will also clear all other ones of PIFP.. see below. Yep, that seems to be the way it is for status bits. Thx for your answer Stefan |
|
From: "Stefan Loos" stefan_l_01@y Sent: Monday, August 30, 2004 11:55 AM > Hi > > Im new to this group. Im from Germany so please excuse mistakes in > my english. > > We encountered a strange behaviour modifiing bitwise the PIFP > Register. We use cosmic debugger. The PIFP adress is declared as > 0x25f afair (16Bit ext. adress?) > > The guys you gave us the control where the Star12 is integrated write > in their interrupt routine the following code to check the interrupt: > > if ( PIFP & 0x80 ) > { > ... Do something > PIFP |= 0x80 // Reset Register > } > > Now, the problem is that a |= operator usually isnt used to take out > a bit but to set a bit or a bitmask. The strange thing is : It work, > at least it seems to work. The problem is that this operator always Most of HC11/HC12/HCS12 flags are cleared by writing '1' (one) to flag. That's why PIFP|=0x80 should work for PIFP.bit7, but will also clear all other ones of PIFP.. see below. > sets the register back to 0x00 and doesnt care about the bitmaskbyte. > For example when PIFP is 0x9F, the result of PIFP |= 0x80 is also > 0x00. Yes, because 0x9F | 0x80 = 0x9F. CPU has to write 0x80 to PIFP register in order to make PIFP.bit7==0. PIFP=0x80 is correct way to clear PIFP.bit7 keeping other PIFP bits untouched. > The assembler code seems to be ok, its 1c25f080 > We changed the command line to PIFP ^= 0x80 and PIFP &= ~0x80 which > is the usual C-coding to take back a bitmask, but this does strangly > SETS the PIFP register to 0x80. ^=0x80 is wrong. 0x9F ^ 0x80 = 0x0F , clears bits 0..3 PIFP &=~0x80 is wrong too 0x9F & 0x7F=0x1F, clears bits 0..4 Use PIFP =0x80 to clear only PIFP.bit7. PIFP &=0x80 also is fine, 0x9F & 0x80=0x80. Even using read-modify write instruction BCLR it's still fine: BCLR PIFP,#0x7F Don't use C bitfields to clear flags. PIFP.bit7=1 is wrong because it will translate into: LDAB PIFP ; B=0x9F ORAB #0x80 ; B=0x9F STAB PIFP ; clear bits 0..4,7 or BSET PIFP,#0x80; reset all ones of PIFP. PIFP.bit7=0 is also wrong, because LDAB PIFP ; B=0x9F ANDB #0x7F ; B=0x1F STAB PIFP ; clear bits 0..4 and BCLR PIFP,#0x80 ; clear all ones of PIFP, except bit7 PIFP.bit7= !PIFP.bit7 is again wrong BRSET PIFP,#0x80,L1 BCLR PIFP,#0x80 ; 0x9F & 0x7F=0x7F BRA L2 L1: BSET PIFP,#0x80 ; 0x9F | 0x7F = 0x9F L2: Edward > Any help? > > Thx > Stefan |
|
|
|
Hi Im new to this group. Im from Germany so please excuse mistakes in my english. We encountered a strange behaviour modifiing bitwise the PIFP Register. We use cosmic debugger. The PIFP adress is declared as 0x25f afair (16Bit ext. adress?) The guys you gave us the control where the Star12 is integrated write in their interrupt routine the following code to check the interrupt: if ( PIFP & 0x80 ) { ... Do something PIFP |= 0x80 // Reset Register } Now, the problem is that a |= operator usually isnt used to take out a bit but to set a bit or a bitmask. The strange thing is : It work, at least it seems to work. The problem is that this operator always sets the register back to 0x00 and doesnt care about the bitmaskbyte. For example when PIFP is 0x9F, the result of PIFP |= 0x80 is also 0x00. The assembler code seems to be ok, its 1c25f080 We changed the command line to PIFP ^= 0x80 and PIFP &= ~0x80 which is the usual C-coding to take back a bitmask, but this does strangly SETS the PIFP register to 0x80. Any help? Thx Stefan |
|
|