Hmm...
Now I am definitely confused.

So I found this in the instruction set info for MOVWF in the mid-range
manual:

Q1 Decode
Q2 Read register 'f'
Q3 Process Data
Q4 Write Register 'f'

That seems to put a nail in the coffin, and I would drop this here and
now if I hadn't been using IOC for months now.
I looked at some other instructions, namely CLRW:

Q1 Decode
Q2 Read register 'f'
Q3 Process Data
Q4 Write Register 'f'

Now we all know that CLRW does not take a 'f parameter and doesn't
affect any file registers right?

The documentation is clearly copy/pasted. Perhaps the documentation for
MOVWF is also bogus and whoever wrote "All write operations are
read-modify-write operations" was just confused from reading the
documentation ;-)

So I think I will need to call Mchip Monday and ask them to explain
this mess.

-Ben



On Jun 12, 2004, at 7:51 AM, Tom wrote:

> All write ops perform a read first. From the '629/675 manual:
>
> "Reading the GPIO register reads the status of the pins,
> whereas writing to it will write to the port latch. All write
> operations are read-modify-write operations. Therefore,
> a write to a port implies that the port pins are read,
> this value is modified, and then written to the port data
> latch."
>
>
> Further along:
>
> "Any instruction that specifies a file register as part of
> the instruction performs a Read-Modify-Write (R-M-W)
> operation. The register is read, the data is modified,
> and the result is stored according to either the instruction,
> or the destination designator  d . A read operation
> is performed on a register even if the instruction writes
> to that register... For example, a CLRF GPIO instruction will read
> GPIO,
> clear all the data bits, then write the result back to
> GPIO. THIS EXAMPLE WOULD HAVE THE UNINTENDED RESULT
> THAT THE CONDITION THAT SETS THE GPIF FLAG WOULD BE
> CLEARED."
>
> (my emphasis added)
>
> As noted by others, the IOC function can be used as long as the above
> is
> taken into condsideration. But the R-M-W "glitch" is real and must be
> dealt
> with. Ignoring it (as I did early on) will eventually result in
> software
> that seems flakey and intermittent.
>
> Hope this helps-
> Tom
>
>> Quote from the 12f manual:
>> "If a change on the I/O pin should occur when the read operation is
>> being executed (start of the Q2 cycle), then the GPIF interrupt flag
>> may not get set. "
>>
>> It specifically mentions the Q2 cycle.
>>
>> Quote from the mid-range manual:
>> "Q1: Instruction Decode Cycle or forced No operation
>> Q2: Instruction Read Data Cycle or No operation
>> Q3: Process the Data
>> Q4: Instruction Write Data Cycle or No operation "
>>
>> So to me this looks like the bug is only in the Q2 read cycle, and
>> does not affect the write cycle.
>>
>> I could be doing something terribly evil, but I have several
>> prototypes that do a lot of constant writing to GPIO and still rely on
>> IOC to interupt and have not had any problems.
>>
>> - Ben
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>
>

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.