[<<][staapl][>>][..]Thu Apr 7 00:26:25 EDT 2011
Let's use different addresses to distinguish between return and call.
I.e. sending to 0xFF causes the host command to terminate, while
sending to 0xFE causes a command to be executed.
: bar 65 emit 65 emit ;
icsp:send h:#t b:(0 3 3 214 2)
icsp-recv: h:#t a:#f b:(1 255 1)
icsp-recv: h:#f a:#t b:(65)
icsp-recv-message: (255 1 65)
Aicsp:send h:#t b:(0 0)
icsp-recv: h:#t a:#f b:(1 144 0)
icsp-recv-message: (144 0)
icsp:send h:#f b:(0 0)
icsp-recv: h:#t a:#f b:(2 0 0)
icsp-recv-message: resync: 10
icsp-recv-message: resync: 1
icsp-recv-message: (0 0)
There seems to be a collision when both sides are writing on the bus.
Saved scope capture as:
How to view the waveform?
What I see is:
* host sending 0 3 3 x x
* target sending 255 1 65
x host sending 2 pulses, where target replies ack 1,0
* host sending out 16 pulses, target replies 0 (receives!)
* host and target both send data
The trouble is at x: target sees the pulses and performs ack, but host
doesn't seem to see the ack?
Every poll then clocks the device while it's in a 2 byte read. When
that is finished it replies.
Let's look at the transmit part. It misses the sync bit. Why?
Does it actually ack when it receives a zero packet?
It doesn't so I changed that. This has no effect though.
It doesn't see that pulse... Damn. Why? BUG in PK2?
FOUND IT: in pk2-in, an icsp-ack was sent while the internal
message-oriented code in icsp.ss already performs the handshake.