Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: [lpc2000] LPC2106 port driving problem (longer post)

2005-05-06 by Peter Jakacki

Hi Roger,
    I think you hinted at and disregarded what the problem is when you 
used IOPIN directly and the waveform was too "analog". Philips haven't 
figured out how to make the outputs analog yet so that can't be the 
problem ;) You must have a bit of capacitance on those lines to be 
experiencing this effect. Verify this by buffering at least one line and 
observing.

Use of IOSET/IOCLR will only slow down access to the pin and give you a 
less "analog" :) waveform.

I could continue with some more explanation but this is the obvious 
course you should be pursuing.

*Peter*


roger_lynx wrote:

>Hello,
>
>I need to write a nibble to P0.31-P0.28. When I write a value, it is
>not output correctly:
>
>ex. I write 0x7E 5C 38 A1 sequence and 
>  I get out 0x7C 4C 38 80 sequence, sometimes the bit(s) get sticky on
>P0.29/28, seldom on P0.31.
>
>I use IOSET/IOCLR, I gave up on IOPIN, since the waveform is "too
>analog". :-)(slow rise/fall time) 
>
>I found this explanation, in 2131_UM, pg. 88:
>
>Write access to port\ufffds 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\ufffds 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
>
>....etc.
>
>My questions are:
>1. Is this example correct? If so, *why* is it correct?
>2. Is pin behaviour on 2106 same as another LPC member, such as 2131?
>3. Is GPIO 31-28 really *General*?
>4. I tested this code:
>
>_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.
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.