Lpc2000

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�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

....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.

Please, advise. 
(am using GNU 3.3.1, I looked at assembled code, I see nothing
strange)
Thank you.

--roger

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/

--- 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

At 02:34 PM 5/3/05 +0000, roger_lynx wrote:
>--- 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.

Somehow I missed the logical operation part.  I must have been blinded by 
the # :).  I can't imagine a circumstance in which that would work.

>
> > 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?

The result is always 1, any nonzero value logically ored with another value 
will result in a 1 by definition in C or C++.



> > >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".

The only problems I'm aware of with IOSET/CLR are
  - phasing, inherit with this method
  - speed, not an issue for me but some people want to do fast bit banging 
through the ports.
  - IIC pins (those that can be mapped to be IIC) do not pull up even when 
set high even when not used as IIC.

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/

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:

 
> The result is always 1, any nonzero value logically ored with
another value 
> will result in a 1 by definition in C or C++.

Thanks. 
So much for the datasheet correctness in this already hazy area. Say
what you mean, mean what you say (Alice in Wonderland).
:-)

Could Philips write an app note on this topic?

> The only problems I'm aware of with IOSET/CLR are
>   - phasing, inherit with this method
>   - speed, not an issue for me but some people want to do fast bit
banging 
> through the ports.
>   - IIC pins (those that can be mapped to be IIC) do not pull up
even when 
> set high even when not used as IIC.

What is IIC pin?
Do all LPC parts behave the same way as far as the GPIO IOCLR/SET?

Thanks for your input.
:-)

--roger

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.
>