Lpc2000

At 12:15 PM 5/3/05 +0000, roger_lynx wrote:
>I found this explanation, in 2131_UM, pg. 88:
>
>Write access to port�s IOSET followed by write to the IOCLR
>register
>results with pins outputting 0s being slightly later then pins
>outputting 1s. There are systems that can tolerate this delay of a
>valid output, but for some applications simultaneous output of
>a binary content (mixed 0s and 1s) within a group of pins on a single
>GPIO port is required. This can be accomplished by writing
>to the port�s IOPIN register.
>
>Following code will preserve existing output on PORT0 pins P0.[31:16]
>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.

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.

>_pin_toggle:
>                 ldr r0, =IODIR
>                 mov r1, #0x80
>                 mov r3, #0x80
>                 str r1, [r0]
>
>                 ldr r0, =IOCLR
>                 ldr r2, =IOSET
>         L3:
>                 str r1, [r0]
>                 str r1, [r2]
>                 b L3
>
>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.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/