Fellow PIClisters!

I am considering using a PIC16F628 as a "write-only" slave device in a
bigger system.  I think I have a solution that will meet my needs, but
it seems uneconomical on I/O pins, and so I would appreciate any ideas
on improving it.

I need to create an interface from the master controller to the slave
PIC to send commands (each a few bytes in length).  It is important that
this interface imposes minimum software overhead on the master device
and consumes a small number of I/O pins at both ends (i.e. serial mode).

Asynchonous serial data transfer is probably ruled out as I don't have a
spare hardware UART on the master controller and I'm planning to operate
the PIC16F628 in "internal 4MHz oscillator mode", which isn't guaranteed
to be accurate enough to avoid mis-timing of bit reads.

Synchronous Slave Receive mode of the USART on the PIC16F628 looks like
a good option, as the master controller can send commands by shifting
clock and data bits out of two I/O pins in a tight loop.  The physical
connections between the master and slave are very short, so it should be
okay to clock the serial lines at maximum speed without any added delays
in the master controller.  This also allows the PIC to be put into SLEEP
mode (or 37kHz oscillator mode) between commands.

I anticipate two problems which I think will require extra I/O pins to
resolve:

1. Byte synchronisation
-----------------------

In theory, the master and slave should always remain synchronised at the
end of each byte as long as the master sends clock pulses in multiples
of eight.  However, I would like to include a mechanism to guard against
the possibility of extra or missing pulses throwing the two devices out
of sync.  As far as I can tell, there is no automatic mechanism in the
PIC hardware to support this.

My proposed approach is to add a status line from the master controller
to the PIC.  The master asserts this line just before it starts to clock
out data bits, and de-asserts it at the end of the transfer.  The PIC
firmware keeps CREN disabled (holding the hardware bit counter reset)
until it sees the status line asserted.  Once the transfer is complete,
the PIC firmware disables CREN again.

2. Flow control
---------------

The master controller needs to know whether the PIC is ready to receive
a serial command before it attempts to clock out a byte, to allow for
latency in the PIC between receipt of the last clock bit and emptying of
RCREG in software (e.g. by an interrupt routine).

Also, I'm not sure how long it takes for the PIC to wake up from SLEEP
in "internal 4MHz oscillator mode" (is this specified in the data sheet?
- I don't see it!).  This will add to the latency.

My proposed approach is to add another status line from the PIC to the
master controller to hold off the next byte transfer until the PIC is
ready.  This can also provide confirmation that CREN has been enabled
after the master has asserted the synchronisation signal (see 1 above).

The problem here is that it is not possible to assert an output signal
from the PIC automatically when RCREG is loaded - only in software when
the interrupt routine to deal with RCREG is entered.  This raises the
problem of latency (see above).

My proposed solution is to add external hardware - a flip-flop which is
triggered by a rising edge on the bit clock and reset by a signal from
the PIC.  The output of the flip-flop goes back to the master controller
and prevents it from sending a new byte until the current one has been
acknowledged by the PIC.

Summary
-------

I think my proposed solution above will work and impose minimum software
load on the master controller.  However, it feels inefficient to add two
extra signals to the serial clock and data in order to achieve my goals.

It seems a shame to me that the PIC hardware doesn't provide better
support for these functions - for example, if the state of the RCIF bit
could be routed to an I/O pin, then it might be possible to solve both
issues using just one extra line from the PIC to the master controller.

I'd appreciate any thoughts on the above.  Has anyone else out there
been successful with this type of approach?

Many thanks in advance.
--
Ian Chapman
Chapmip Technology, UK

--
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