Yahoo Groups archive

Lpc2000

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

Message

Re: GPIO read bug fixed in 2114/2124?

2004-04-13 by philips_apps

Hello Bob,

As it can be seen from user manuals that are accompanying LPC2000 
microcontrollers, port pins can be configured to perform one out of 
up to four digital/analog functions, GPIO pin function being one of 
them. 

In case of the LPC2114/2124 part, the one you are working with, the 
IOPIN register described in the "Table 68: GPIO Register Map" 
("LPC2114/2124/2212/2214 User Manual", page 110, February 03, 2004 
edition) refers to IOPIN as "GPIO Port Pin value register", and not 
to the "Port Pin value…" in general. More detailed description of the 
same register (page 111), starts with: 

"This register provides the value of the GPIO pins…"

Therefore, IOPIN reflects any outside world influence on the GPIO 
configured pins only! Monitoring of non-GPIO configured port pins 
using IOPIN register will not be valid, since activities on non-GPIO 
pins are not indicated in the IOPIN register.

Selection of a single function on a port pin completely excludes all 
other functions otherwise available on the same pin.

The only partial exception to the above rule of exclusion is in the 
case of inputs to the A/D converter. Regardless of the function that 
is selected for the port pin that also hosts the A/D input, this A/D 
input can be read at any time and variations of the voltage level on 
this pin will be reflected in the A/D readings. However, valid analog 
reading(s) can be obtained if and only if the function of an analog 
input is selected. Only in this case proper interface circuit is 
active in between the physical pin and the A/D module. In all other 
cases, a part of digital logic necessary for the digital function to 
be performed will be active, and will disrupt proper behavior of the 
A/D.

This is the way all ports in Philips LPC2000 family of 
microcontrollers are designed to operate. 

Hope this clarifies the subject of GPIO pins. 

Philips apps.




--- In lpc2000@yahoogroups.com, "bobbruce000" <bobbruce000@y...> 
wrote:
> --- In lpc2000@yahoogroups.com, "Lee Studley" <indigo_red@q...> 
wrote:
> > Hi Bob,
> > I wouldnt really say this is a hardware bug, but a documentation
> > bug.
> 
> I guess that is one way to look at it.  So let me rephrase my
> question:
> 
>    The LPC2106 docs contain a bug, when they state that the pins
>    are readable even if an alternate funcion is enabled.
> 
>    The LPC2114 docs contain the same statement.  But is this
>    another "documentation bug", or does it accurately reflect
>    what the hardware actually does?
> 
> Happy now? ;-)
>  
> > Can you switch to GPIO, then get the level, then back as needed? 
> > Or will this cause a glitch.
> 
> No.  I cannot think of any way to do that reliably.  There is always
> a chance of missing a transition.
> 
> The only solution I can think of, is to dedicate additional pins,
> and have the signal go to a capture pin and also to a GPIO pin.
> Since I will have eight capture signals, that means I need to give
> up eight other pins, that I would rather use for other purposes.
> But I need to know before I etch a board, which is why I am asking.
> 
>     -bob

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.