Lpc2000

I was surprised to discover that GPIO pins, just after they're 
configured as outputs, default LOW (the opposite state of its startup 
high-impedance input mode).  For my design, LOW is an ACTIVE state.  
I can immediately set the output HIGH but I'm stuck with a 
LOW 'glitch' to deal with.  Every other micro GPIO I've worked with 
would maintain the HIGH when switching from input to output mode.

Just wondering if anyone knows something I don't here...I certainly 
can't find any Philips documentation on the issue.  And I know I can 
design for a HIGH state and put pulldowns on the lines but, again, I 
hate to redo everything just to find that the initial GPIO output 
state is undefined or arbitrary...or, again, that there's something I 
dont' know about.

Thanks folks,

At 08:39 PM 10/26/04 +0000, you wrote:
>I was surprised to discover that GPIO pins, just after they're
>configured as outputs, default LOW (the opposite state of its startup
>high-impedance input mode).  For my design, LOW is an ACTIVE state.
>I can immediately set the output HIGH but I'm stuck with a
>LOW 'glitch' to deal with.  Every other micro GPIO I've worked with
>would maintain the HIGH when switching from input to output mode.

Just a stab in the dark, I would have thought they would default to the 
state of the output register.  Did you set the output before changing to 
output?



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

Yes, I actually tried setting the state (IOSET) before setting the 
direction to output with no effect.  And the 22xx user's manual does 
state that performing an IOSET on any bit which is an input will have 
no effect.  I also spoke with a Philips FAE after I sent this first 
message and he confirmed that output will definitely be born low and 
there's no workaround.

Thanks

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 08:39 PM 10/26/04 +0000, you wrote:
> >I was surprised to discover that GPIO pins, just after they're
> >configured as outputs, default LOW (the opposite state of its 
startup
> >high-impedance input mode).  For my design, LOW is an ACTIVE state.
> >I can immediately set the output HIGH but I'm stuck with a
> >LOW 'glitch' to deal with.  Every other micro GPIO I've worked with
> >would maintain the HIGH when switching from input to output mode.
> 
> Just a stab in the dark, I would have thought they would default to 
the 
> state of the output register.  Did you set the output before 
changing to 
> output?
> 
> 
> 
> 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

> Yes, I actually tried setting the state (IOSET) before setting the 
> direction to output with no effect.  And the 22xx user's manual 
does 
> state that performing an IOSET on any bit which is an input will 
have 
> no effect.  I also spoke with a Philips FAE after I sent this 
first 
> message and he confirmed that output will definitely be born low 
and 
> there's no workaround.

I'm not sure what you're using your pin(s) for, but I know working 
around multidirectional GPIO pins can be a pain software-wise. 
Regardless, I never underestimate the power of hardware.

Use an Inverter :)

Leighton

Hi

Just my two cents on the matter

>I'm not sure what you're using your pin(s) for, but I know working 
>around multidirectional GPIO pins can be a pain software-wise. 
>Regardless, I never underestimate the power of hardware.

This could actually be a great problem I my self have created several
PLC controllers where I wanted the output to be high on birth and when
its undetermined a weak pull up insured the state.

>Use an Inverter :)

Using additional logic, transistors etc. all costs money and I actually
think It's sad that Philips didn't make their hardware "the right way"
from the start...

/Lasse

> This could actually be a great problem I my self have created 
several
> PLC controllers where I wanted the output to be high on birth and 
when
> its undetermined a weak pull up insured the state.

Currently there are 2 Output pins on my prototype board that 
requires pullup resistors to work, or else I'll have no way of 
controlling them. 

> Using additional logic, transistors etc. all costs money and I 
actually
> think It's sad that Philips didn't make their hardware "the right 
way"
> from the start...

Point taken on the cost factor...unfortunately, most mcu's aren't 
that perfect yet because of cases where the firmware just can't get 
around critical hardware problems. That's the "give-and-take" nature 
of the design game.

All,
     I have verified that the port pins (GPIO) will be driven low if 
they are switched to output mode.  BUT, I have also verified that 
they will switch high if the corresponding bit in the IOSET register 
is set FIRST (eg before IODIR is set to one).  This should eliminate 
the aforementioned problems.

Richard




--- In lpc2000@yahoogroups.com, "Leighton Rowe" <leightonsrowe@y...> 
wrote:
> 
> > This could actually be a great problem I my self have created 
> several
> > PLC controllers where I wanted the output to be high on birth and 
> when
> > its undetermined a weak pull up insured the state.
> 
> Currently there are 2 Output pins on my prototype board that 
> requires pullup resistors to work, or else I'll have no way of 
> controlling them. 
> 
> > Using additional logic, transistors etc. all costs money and I 
> actually
> > think It's sad that Philips didn't make their hardware "the right 
> way"
> > from the start...
> 
> Point taken on the cost factor...unfortunately, most mcu's aren't 
> that perfect yet because of cases where the firmware just can't get 
> around critical hardware problems. That's the "give-and-take" 
nature 
> of the design game.

Richard,

I have tried to perform an IOSET before IODIR and it had NO EFFECT.  
And the LPC2114 user's manual specifically states that performing an 
IOSET or IOCLR on pins which are inputs will have no effect.  What 
processor did you perform this on?



--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> 
wrote:
> 
> All,
>      I have verified that the port pins (GPIO) will be driven low 
if 
> they are switched to output mode.  BUT, I have also verified that 
> they will switch high if the corresponding bit in the IOSET 
register 
> is set FIRST (eg before IODIR is set to one).  This should 
eliminate 
> the aforementioned problems.
> 
> Richard
> 
> 
> 
> 
> --- In lpc2000@yahoogroups.com, "Leighton Rowe" 
<leightonsrowe@y...> 
> wrote:
> > 
> > > This could actually be a great problem I my self have created 
> > several
> > > PLC controllers where I wanted the output to be high on birth 
and 
> > when
> > > its undetermined a weak pull up insured the state.
> > 
> > Currently there are 2 Output pins on my prototype board that 
> > requires pullup resistors to work, or else I'll have no way of 
> > controlling them. 
> > 
> > > Using additional logic, transistors etc. all costs money and I 
> > actually
> > > think It's sad that Philips didn't make their hardware "the 
right 
> > way"
> > > from the start...
> > 
> > Point taken on the cost factor...unfortunately, most mcu's aren't 
> > that perfect yet because of cases where the firmware just can't 
get 

> > around critical hardware problems. That's the "give-and-take" 
> nature 
> > of the design game.

I have tried it on a LPC2129 and one of our newer derivitives.  I use 
a weak pullup on the GPIO (220K) to pull the pin to a known state.  
Before I run the debugger I can see that the pin is floating.  The 
pin is still floating after I write to IOSET.  The pin is driven high 
when I write ones to IOSET, this is verifed by switching the pullup 
to a pulldown and still seeing the pin high.  I am using pin P1.16 on 
an MCB2100 board and am using the Rowley tools.

Richard

--- In lpc2000@yahoogroups.com, "markcrow" <mcrow@p...> wrote:
> 
> Richard,
> 
> I have tried to perform an IOSET before IODIR and it had NO 
EFFECT.  
> And the LPC2114 user's manual specifically states that performing 
an 
> IOSET or IOCLR on pins which are inputs will have no effect.  What 
> processor did you perform this on?
> 
> 
> 
> --- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> 
> wrote:
> > 
> > All,
> >      I have verified that the port pins (GPIO) will be driven low 
> if 
> > they are switched to output mode.  BUT, I have also verified that 
> > they will switch high if the corresponding bit in the IOSET 
> register 
> > is set FIRST (eg before IODIR is set to one).  This should 
> eliminate 
> > the aforementioned problems.
> > 
> > Richard
> > 
> > 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "Leighton Rowe" 
> <leightonsrowe@y...> 
> > wrote:
> > > 
> > > > This could actually be a great problem I my self have created 
> > > several
> > > > PLC controllers where I wanted the output to be high on birth 
> and 
> > > when
> > > > its undetermined a weak pull up insured the state.
> > > 
> > > Currently there are 2 Output pins on my prototype board that 
> > > requires pullup resistors to work, or else I'll have no way of 
> > > controlling them. 
> > > 
> > > > Using additional logic, transistors etc. all costs money and 
I 
> > > actually
> > > > think It's sad that Philips didn't make their hardware "the 
> right 
> > > way"
> > > > from the start...
> > > 
> > > Point taken on the cost factor...unfortunately, most mcu's 
aren't 

> > > that perfect yet because of cases where the firmware just can't 
> get 
> > > around critical hardware problems. That's the "give-and-take" 
> > nature 
> > > of the design game.

I tried it on LPC2106 and LPC2129 boards and if nothing is done
 from reset, the pins go to zero like said, but if you write back the pins
 set the ones you want, they they are high when IODIR is changed.
 or IOPIN can be read from and then written to:

IsoMax V1.0 Preliminary
HEX IOPIN @ U. FFC2400C  OK
-1 IODIR ! IOPIN @ U. 20000  OK
0 IODIR ! IOPIN @ U. FFC2400C  OK
IOPIN @ IOPIN ! -1 IODIR ! IOPIN @ U. FFC2400C  OK


 On a separate but related thread,  I use GPIO P0.16 as a
 receiver for a software UART and I run into unexpected territory
 when also using that pin as an external interrupt.

 For my software asynchronous receiver, I use P0.16 as EINT0
 triggering on a low level and taking that as the start bit.  When
 I get this interrupt my state machine moves into sample mode
 and uses a second interrupt, timer1, to sample the data bits
 to make a byte.  The problem I ran into is that when P0.16 is
 set to GPIO (PINSEL1 is xxx0), I can read the incoming serial
 data fine but when I switch P0.16 to EINT0 function (PINSEL1
 is xxx1), then P0.16 always reads as zero even if it is a one.
 What's the logic in that?  So in order to use P0.16 as an interrupt
 and as a data pin, I have to switch between pin modes using
 PINSEL1.  Gack!

 Anyway, with the extra mucking around (I refuse to use a
 second pin), the software asynchronous receiver state machine
 (6 states) works just dandy, reading GPS input at 4800 baud.  It
 also handles recovery when lost and contiguous data.

 Rob

--- In lpc2000@yahoogroups.com, "Richard" <richas@y...> wrote:

> 
> I have tried it on a LPC2129 and one of our newer derivitives.  I use 
> a weak pullup on the GPIO (220K) to pull the pin to a known state.  
> Before I run the debugger I can see that the pin is floating.  The 
> pin is still floating after I write to IOSET.  The pin is driven high 
> when I write ones to IOSET, this is verifed by switching the pullup 
> to a pulldown and still seeing the pin high.  I am using pin P1.16 on 
> an MCB2100 board and am using the Rowley tools.
> 
> Richard
> 
> --- In lpc2000@yahoogroups.com, "markcrow" <mcrow@p...> wrote:
> > 
> > Richard,
> > 
> > I have tried to perform an IOSET before IODIR and it had NO 
> EFFECT.  
> > And the LPC2114 user's manual specifically states that performing 
> an 
> > IOSET or IOCLR on pins which are inputs will have no effect.  What 
> > processor did you perform this on?
> > 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> 
> > wrote:
> > > 
> > > All,
> > >      I have verified that the port pins (GPIO) will be driven low 
> > if 
> > > they are switched to output mode.  BUT, I have also verified that 
> > > they will switch high if the corresponding bit in the IOSET 
> > register 
> > > is set FIRST (eg before IODIR is set to one).  This should 
> > eliminate 
> > > the aforementioned problems.
> > > 
> > > Richard
> > > 
> > > 
> > > 
> > > 
> > > --- In lpc2000@yahoogroups.com, "Leighton Rowe" 
> > <leightonsrowe@y...> 
> > > wrote:
> > > > 
> > > > > This could actually be a great problem I my self have created 
> > > > several
> > > > > PLC controllers where I wanted the output to be high on birth 
> > and 
> > > > when
> > > > > its undetermined a weak pull up insured the state.
> > > > 
> > > > Currently there are 2 Output pins on my prototype board that 
> > > > requires pullup resistors to work, or else I'll have no way of 
> > > > controlling them. 
> > > > 
> > > > > Using additional logic, transistors etc. all costs money and 
> I 
> > > > actually
> > > > > think It's sad that Philips didn't make their hardware "the 
> > right 
> > > > way"
> > > > > from the start...
> > > > 
> > > > Point taken on the cost factor...unfortunately, most mcu's 
> aren't 
> > > > that perfect yet because of cases where the firmware just can't 
> > get 
> > > > around critical hardware problems. That's the "give-and-take" 
> > > nature 
> > > > of the design game.