| >     movf   PORTB,W
| >     iorlw  1<<clock_bit
| >     movwf  PORTB
| >     andlw  ~(1<<clock_bit)
| >     movwf  PORTB
|
| Note that this still does a read/modify/write.


Just to be sure: The movwf 's (?). (the movf not because destiny is W)


| However, I think the RMW problem has been blown out of proportion.  It
| only
| matters if 1: you have other bits in the port that you will be toggling
| between input and output and you don't explicitly set their state when
| switching to output, and 2: if the external circuit holds a PIC output in
| its opposite state.  You have full control and knowledge of #1.  #2 is
| rare
| because it usually means poorly designed hardware, although it could
| legitimately happen for short periods of time (a few uS) after the output
| is
| switched if the external circuit has considerable capacitance.


You forgot the open-source pin possibility, when it's configured as output
but being driven externally.


| Therefore, for most cases, the original code was just fine:
|
|     bsf   portb, clock_bit
|     bcf   portb, clock_bit
| This will put out a pulse that is one instruction time long.  This is a
| reasonable thing to do, for example, when clocking an external flip flop.
| I've done this sort of thing a number of times when multiplexing one of
| the
| ports as a data bus.
|
|
| ********************************************************************
| Olin Lathrop, embedded systems consultant in Littleton Massachusetts


S.-

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics