First: on ^4 I should have connected the SPI nSS to R-Pi's CE00 pin (oops).

I have been working on the Remote FW for this board, splitting the hulk into smaller parts so they can fit in my brain. Also adding I2C commands that control the bus manager, and trying out the SMBus interface... and then it happened. I did not have a clue what was going on, and it has taken far to long to understand. In short, the R-Pi zero has a problem with clock-stretching.

http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html

After finally understanding the problem and getting past the sinking feeling, I had an idea.

Interleaving between two buffers (A and B) within the twi ISR used by SMBus interface. And without much testing yet, it seems to have done the trick.  

https://github.com/epccs/RPUpi/commit/089455a040c1aaae76031a735f9558047b78a573#diff-5bd95c1d69122d988a6f85757b66c817

The buffer used by the ISR is swapped after passing it to the user (e.g., with receive callback function). The user receive function runs within the ISR context, but now it can be concise (e.g., save the pointer and byte count). Then all the work can be done outside of ISR context since the buffer is no longer in the risk of being changed, at least until a subsequent receive event when it will be swapped back into service.

https://github.com/epccs/RPUpi/commit/089455a040c1aaae76031a735f9558047b78a573#diff-e5edda6dc80c252451acc1b2be91d078

The quick receive event seems to be tolerated by the R-Pi's clock, but more testing is needed. The handle_smbus function is run in the main loop if there are SMBus bytes available.

https://github.com/epccs/RPUpi/tree/master/Remote