Mon Mar 28 10:16:33 EDT 2011
Try to use only 2 wires.
1. REQ: Simple connection
The objective of the Staapl comm over ICSP pins is to reduce comm pin
and part count on small circuits. The ICSP has to be there anyway, so
better use it for debug comm. The reason to only use 2 wires apart
from simplicity is that not everyone wires up the PGM (AUX) port. Any
other wiring assumptions need to be dropped as most circuits just
connect PGC and PGD directly.
2. REQ: Async operation
The problem is sync. In the ICSP protocol the host initiates transfer
which means the target needs to be listening. In the Staapl console
case the target can detach and execute code before it comes back to
listen for comm. So some kind of sync is necessary.
3. Separate handshake?
Using one of the ICSP lines (the AUX/PGM line) to implement busy/ready
handshake makes it easy to solve the sync issue when the software is
Using the PGD line to indicate busy/ready state works, but creates bus
conflicts which needs to be handled in hardware by using current
Both of these solutions add extra hardware constraints.
4. Synchronous preamble
The other option is to encode the sync information in the data stream,
and use the fact that a non-asserted PGD line is pulled low by the
PK2, i.e. when the client is not listening, the host will read 0.
The PK2 can poll a single bit at a time, so the simplest solution
seems to be to send a 1 bit to indicate target-ready state.
Note that bus conflicts can still occur when the sync gets off so it's
still safer to use current limiters but at least it has a chance of
To make this work efficiently, it's probably best to switch to packet
mode: the sync is valid for a full data packet. The first byte
transmitted after the sync is the packet size.
Whether this needs buffering depends on what is actually sent. For
the Staapl protocol, an execution command will always be the last byte
in the comm, requiring resync for the reply.
Note: the preamble needs to be at least 2 bits: bit 1 for signalling
the host and bit 2 for releasing the line.
5. Synchronous postamble
We have to release the line after the last bit is written, but we
don't have any timing info. Seems that a postamble might be
If we use a generic command/reply structure the postamble can be