> From: Tony Matthews <tony@MAGICNET.NET>
> Hey people
>  I wonder if there is a method of initializing portb for all output on a
> 16c84 that will not set
> the port pins however briefly ? Some pins ok but all pins simultaneously
> no.My reason for asking
> is I am using 7 bits of port b to control an lcd display 4-bit data then
> rs rw e the bit 0 pin is
> for output as well (optocoupler) and I am having a lot of trouble from
> the hd44780 controller not
> acting like it is supposed to not even the simplest routine gives the
> expected response and I have
> been carefull to keep the rw bit low as I intend to write to the lcd and
> not read yet so my routines
> do not shift the trisb register after initialization "as yet". During
> initialization the portb pins
> all go high for two clock cycles.I thought maybe that could be the
> reason for my difficulty with the lcd.
>  Thanks for your time   Tony M.
>

Tony - a little formatting and attention to syntax would go a long way
to improving readability.  If I understand it you want to set port B
glitch-free?  Well, the port is set to all inputs on reset.  That is,
the state of port B pins is determined by the external circuit.  After
reset, write the appropriate value to port B, then write the I/O config
to TRISB, with a zero bit for each output.  When you write the magic
number to TRISB all the port B outputs will simultaneously move to
the state that you previously wrote into the port B latch.

One problem with I/O ports is that a 'read' always gets the current
actual pin logic level, not necessarily what you have written to the port
latch register.  For example, you cannot necessarily set just one
port pin using e.g. BSF PORTB,0.  This doesn't always work because
BSF reads _all_ the pins, sets the bit, then writes back to _all_
the bits in the port latch.  If one of the output pins is being
forced to a 'non-commanded' logic level (perhaps it is driving a
large capacitance) then the original 'commanded level' for that pin
will be toggled.  Usually, you don't expect this sort of behaviour!

The solution to this is to write the correct output bit pattern to
all outputs of the port i.e. don't depend on the current state since
it might not be what you expected.

Regards,
SJH
Canberra, Australia