Lpc2000

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> At 12:15 PM 5/3/05 +0000, roger_lynx wrote:
> >I found this explanation, in 2131_UM, pg. 88:
> >

[edited]

> >and P0.[7:0] and at the same time set P0.[15:8] to 0xA5,
> >regardless of the previous value of pins P0.[15:8]:
> >
> >IO0PIN = (IO0PIN && #0xFFFF00FF) || #0x0000A500
> 
> Ignoring the # as a typo.

Yes, typo, but it is a *logical* AND and OR, as the original text
emphasizes, as well.
 
> That code depends on IO0PIN containing the last result written to
it.  I 
> don't remember that being documented as the case.  I certainly would
not 
> trust it.

I do not either, the result is 1 or 0, no?


> >I got 3.4+ MHz pin state change rate, I need now fraction of it, yet I
> >cannot get it.
> >VPBDIV=1.
> 
> I'm afraid that's it.  I suspect that the update rate using IOPIN
could be > faster but you do have the overhead of a shadow register to 
> consider.  Certainly as far as IOSET/CLR are concerned you've hit
the > limit.  Also note if you use the code example above for IOPIN
control I 
> would not expect a speed increase since it has two access's to IOPIN.

I am concerned about the missing bit updates. 
The speed is okay.
See section "photos", I just uploaded the outcome of that missing bit
update - the text is "rough on edges".

--roger