Can someone validate that the idea I have for a cheesey, hokey SPI sniffer will work?
I have a device which contains a PIC and a NEC chip, which talk via SPI. Single master, single slave. I want to see all the data going in both directions and see it in relation to each other so I can figure out the protocol the PIC is talking.
My thought is that I will make a sniffer for one direction (say, from the PIC to the NEC chip) as follows, then duplicate this to sniff the other direction (say, NEC chip to PIC):
Take a PIC and connect it’s SPI input and clock lines to the line-to-be-sniffed and clock going between the PIC and NEC chip. Have some simple software on the PIC which reads data from the SPI line into a FIFO as it comes in, then writes it out the UART as it can.
Then I’ll take the data coming out the UART, run it through a MAX232 to make it RS232 levels, and feed it into a serial port.
I figure two of these tied to two serial ports and a cheesey little VB app to do the decoding (as I learn the protocol) could make for a nice, simple sniffer.
I could even take it further by shoving the TTL level serial into one of the readily available TTL serial to USB chips, but that’s probably overkill for what I want to do.
I think this should work… Can any of you see a reason why it wouldn’t? It’d be cheaper / more specific than a SPI-decoding logic analyzer, as I should be able to have lengthy samples, and matching the timing of the SPI line will easily be handled by the PIC.
(I think first mentioned doing it this way… I think…)
Box from 
