[<<][staapl][>>][..]

Fixing emit

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.

Problem.  With:

: bar 65 emit 65 emit ;

bar
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)
OK

There seems to be a collision when both sides are writing on the bus.

Saved scope capture as:
~/staapl/NewFile1.wfm

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.

Very strange.

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.



[Reply][About]
[<<][staapl][>>][..]