About five days of coding and debug of the tCam and tCam-Mini firmware has yielded the first attempt at a higher performance version of tCam with the Lepton VoSPI pipeline and json image encoding being performed by the ESP32 on a tCam-Mini and the rest of tCam operation running on the ESP32 in the tCam prototype.  With mixed results.

The two boards are connected using a serial interface (at 230400 baud) and SPI interface (at around 6 MHz).  Communication between the two boards is via the same json command protocol that is used over the network.  All packets, except image packets, are sent back and forth via the serial interface.  This allowed easy re-use of the command processing code.  The image packet (at about 52 kB) is too large for the serial interface and is read by the tCam ESP32 from the tCam-Mini ESP32 with a SPI interface after tCam receives a new "image_ready" packet via the serial interface.

My main goal in splitting the processing between two ESP32 chips (four cores) was to improve performance and that seems to have been achieved.  I can now get over 7 fps on the tCam LCD display (up from 3-4.5 fps before).  The GUI update process is now the longest running activity per frame and limited, I think, by the maximum 26.67 MHz SPI clock rate of the HX8357 LCD controller.   The update process should be shortened, and fps increased further, by using a controller like the ILI9488 with a 40 MHz SPI interface.

Unfortunately there is occasional data corruption in the image data transferred via SPI between the two ESP32s.  SPI Signal quality looks good (clean edges and plenty of setup and hold time) so I suspect that the tCam-Mini ESP32 SPI Slave can't always keep up (or there is some data corruption by the tCam SPI Master).  The ESP32 SPI Slave is a pretty simple device and comes with a lot of caveats.  For my scenario, where it only supplies data, I setup a buffer full of data, trigger the driver to start operating when it sees chip select asserted and wait for a callback from it indicating it's ready.  Then I send a short json "image_ready" packet via the serial interface which triggers the tCam SPI master to initiate the transaction.  The transaction is pretty long, typically around 52 kB.  It might be possible to try smaller transactions except each one will need a handshake via the serial interface which, at some point, will probably make it impossible to keep up.  A kludge might be to include a checksum and simply discard corrupt images but that seems like an ugly fix and will impact performance. 

So unfortunately my initial experiment is of mixed success and there is more digging to do...