Lpc2000

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.