Hej Thomas McGahee. Tack fšr ditt meddelande 11:06 1999-10-19 -0400 enligt nedan:
>Morgan,
>Check the data sheets. If I recall correctly, the
>current operation is completed prior to the
>interrupt routine being invoked.

...and there is also a latency

I wonder if it is only the jump to isr that is checked between instructions, or is also the hardware setting of flags buffered and delayed until between the instructions?  I believe not.

>But, if you are worried about such things, just
>disable the global interrupt enable, use BSF to
>set the individual interrupt bit you want,
>enable the proper interrupt enable bit, and then
>re-enable the global interrupt enable bit.

The GIE only enables jump to isr, the pheripheral will set the request bits anyway.  Let me describe the problem more clearly:


What if a pheripheral set its interrupt flag while the BSF executes on a request flag register :

1) BSF first reads the byte of interrupt flags

2) a pheripheral set its flag

3) BSF writes back the byte with the bit i wanted set, but at the same time *overwrites* the bit set by the pheripheral in 2)back to the state it had in 1)!

And the event in 2) is missed.

(Well if we generate the interrupt this way, we will enter the service routine anyway, but we can there not resolve the event in 2) by checking it's flag )

Maybe the set pulse from the pheripherals to the flags are enabled only in machine phases that do not affect BSF/BCF, or they are active long enough time to override?

I have not seen any details on this.
Demands heavy testing, and i winder if it will be consistent on different PICs with different pheripherals... and maybe even clock speed sensitive whether it work reliable or not....

Thinking about it more:
The same problem is actually during normal interrupt processing, when we reset the flag during service of the relevant interrupt.

If using BCF to clear is guraranteed to work, then using BCF to set a flag should be guaranteed to work too.

And using BCF to clear is what we regularly do, right?

I am suprised that I have just not seen any explanation/gurarantee as to why it do work, guraranteed if another interrupt occours during execution of a BxF command.

Using IORWF so set / ANDWF to clear should be the same problem, BTW.

/Morgan

>Fr. Tom McGahee
>
>----- Original Message -----
>From: Morgan Olsson <morgans.rt@TELIA.COM>
>To: <PICLIST@MITVMA.MIT.EDU>
>Sent: Tuesday, October 19, 1999 8:01 AM
>Subject: Software interrupt
>
>
>How is software interrupt best generated on a PIC?
>
>Most reliable seem to make a pheripheral generate an interrupt i.e by loading a timer so it will
>wrap immediately/very soon, or manipulate the RB0/INT pin so that generates an interrupt.
>
>But I need the timers for other tasks, and manipulating RB0/INT violates the interrupt on change
>functions.
>
>An idea might be to directly set a pending flag (and of course the enable bit) for an else unused
>interrupt source.
>The manuals tell some of them are read/write :)
>
>My worry about that is that the BSF command is a read-modify-write opeartion, and what will happen
>if an interrupt flag get set by hardware between the read and write of the BSF.  Probably that
>interrupt flag will be overwrittten with the previous state!
>
>Are there more reliable solutions?
>Some experience?
>
>Regards
>/Morgan
>
>Morgans Reglerteknik, Hdllekes, 277 35 KIVIK, SWEDEN
>    tel +46(0)414-446620, fax -70331,   mrt@iname.com 

Morgans Reglerteknik, HŠllekŒs, 277 35 KIVIK, SWEDEN
   tel +46(0)414-446620, fax -70331,   mrt@iname.com