Thu Mar 31 03:33:08 EDT 2011

It's working, now make it faster

It's not particulary fast because of the large delays.  Let's see if
we can up the clock speed back to 3us.  That doesn't do anything.

I've added the syncs in-channel, and it seems to work except for 13
(stackptr) which replies with 0 for a while and then sends:

icsp-recv: h:#t a:#f b:(0 244 15)
icsp-recv: h:#t a:#f b:(0 8 0)

Which is this on the line (LSB first):

   00 00101111 11110000

That's indeed a 10 sync followed by a #xFF address and a #x00 size
byte.  Tshifting it should be no problem.

The (0 8 0) is:

   00 00010000 00000000

Which is a sync bit followed by 2 zeros.  This is because the device
is in receive mode, and it will clock in address + size, and ignore 0
size message.

Ok, receive sync seems to work.  However, sending out the command
really needs a proper sync as otherwise the targets gets messed up.
It seems there are significant delays so we assume the target is
always there.

When the send sync is on, the receive sync doesn't seem to be invoked.
Maybe there's plenty of pause?

Next option: see if it can be solved with a loop in a PK2 script using