SPI monitor DO and DI simultaneously.

[SuperDave]

I'd like to build a test board with a separate micro that will monitor the board under development as the pic communicates with the peripheral. This requires that the test board have two simultaneous spi slave readers (one reading DO, the other reading DI). The test board would then convert the readings to serial and feed it to a PC running a terminal program.

My sense is that the PIC (16F1828 but could be other) can't run two spi modules at once. I see some info on using 'stream' but it's not consistent across the potential functions.

Any guidance?

[Ttelmah]

I _think_ what you are talking about, is having a PIC, 'monitor' a separate SPI bus, that is being generated between two (or more) other devices?.

If so, then 'answer' will depend on the bus speed involved.

Software SPI, can't handle being a slave device. You effectively need two slaves, each using a clock, and an SDI.

This could be done two relatively simple ways:
1) If the bus clock rate is not too high, then 'forget SPI'. Just have a PIC that interrupts on the active edge of the clock signal, and then reads the two input signals.
2) For faster clock rates, you really will need a chip with two hardware interfaces. Worth remembering that you can use a USART to read _some_ SPI streams. In synchronous mode, but depends what the active edge is.

Obviously a chip with two SPI hardware interfaces makes this easy at any clock rate The PIC16F1946/47, have two hardware SPI interfaces in the PIC16 family.

As a comment, you don't have to use streams.
You only need to setup_spi on the two hardware ports, monitor one SPI interrupt, then (since the clock will be the same for both ports), just spi_read, and spi_read2, to get the two bytes.

Best Wishes

[SuperDave]

Thanks, but it's a little more complicated or a little simpler depending.

There are actually three (but I'll talk about just two) boards in the system under development. For simplicity, Board A is connected via USB to a PC. Board B has a pushbutton and led. Each board has a 2.4G transceiver connected through SPI to its PIC.

So, close the switch on B which triggers the PIC which sends the data via SPI to the transceiver which sends the data through the air to the transceiver on Board A which sends the data to the Board A PIC which forwards it via USB to the PC. The PC likes the data and sends back over the same multi-hop link to Board B to light the led. If the led doesn't light, where is the link broken? I want to camp on DI and DO on two separate boards (four lines, but actually six since there are three real boards, and six more for separate clocks and enables).

I don't think I can record two separate streams with two similar but non-synchronized clocks. Where I'm heading at the moment is to put, for debug purposes, a small delay between each SPI chip enable and the start of the SPI data. Then detect that enable to set up the SPI monitor to the DO of the source PIC while enabled and then DI of the destination PIC when enabled based on a monitor board direction toggle switch. I know when I'm going to press the pushbutton, I know when the PC is going to light the light, so direction, at least at the debug level is known. There are three boards but B and C only talk/listen to A, they don't talk/listen to each other.

Because of the wireless transmission delay, not huge but not zero. I'll be able to have only one actual SPI DI (and no DO) on the monitor board active at one time. And, for debug purposes I can slow all the SPI clocks down so software SPI will work.

We'll see. (Hope that makes sense.)

[Mike Walne]

I had a similar problem, several years ago with two boards talking to each other via variation on RS232.
There was only one wire link. Each board had to disable its TX when the other was talking.

Solved it with a 2 channel digital 'scope.

Board A talked to board B.
Board B replied but A did not always get the correct response.

So:-
Triggered the 'scope when board A talked, took enough samples to get both sides of conversation.
Used VB on PC to download 'scope traces to PC after each exchange.
Decoded data and decided if response was good or otherwise.
Saved the <1% bad traces, ignored the good ones.
Proceeded from there.

Sounds like you may need more than two channels.
I assume you could get the LED drive to select traces for further examination.
Set up one PIC to effectively operate the button, and automate the whole process.
Leave it to run, drink loads of coffee.

Mike

[temtronic]

hmm.just an idea...

...If you can add one more byte to the datastream..

Since PIC-B is the 'master'(well start of the signalling....) since you push a button there.

Create a 'progress byte' .
When PB is pressed..bit 0 of progress byte is set
When sent from PIC-B(via SPI modem)..bit 1 is set
When PIC-A receives data..bit 2 is set
When PIC-A sends to PC..bit 3 is set
When PC receives it..bit 4 is set
When PC sends data..bit 5 is set
When PIC-A receives it.. bit6 is set
When PIC-A sends it..bit 7 is set
When PIC-B receives it..bit 8 is set.

Somehow a 'transmission timer' should also be set to set a flag if the data doesn't make the trip.If that flag gets set, a query could follow the 'progress byte' trail.

heck, it's an idea...a breadcrumb trail ?

hth
jay

[SuperDave]

Thanks all, at least no one is shooting the idea down.

I'm hoping the terminal program on the PC will sub for the digital scope and decode the data automatically. The monitor board gets SPI in but sends out RS232. I found Termite which can be configured to show both the hex and the ascii of each serial input. Not terribly important for the simple example but useful in the full application when more complex data is involved. Since all the links are essentially pass throughs, the only exception being that the inbound transceiver adds signal strength and link quality bytes, the terminal should show where any problem exists or at least where it was last valid.

Thanks again.

[Ttelmah]

It can certainly be done.

_But, _ I can see it getting complex. If you are slowing things down, I can see problems changing, which then means diagnosis could be useless. Then your diagnosis will also depend on your decoding, which will have delays, and could equally have errors, so again your time being wasted. Then you will impose extra loads, which will also change things. One advantage of the scope is that it'll have high impedance inputs.

Now most digital scopes will offer you vision of the raw data at high sample rates, which will show glitches and ringing, which the PIC system will never show. Then most will also support decoding data, so will do everything you are trying to do at full speed.

Now I don't know how you price your time, but you could hire a digital scope for a week, for less than this project will cost. Or one of the add on digital sample units for a conventional scope would again cost less than this project....

Best Wishes

[Mike Walne]

To me the benefit of using a 'scope is that it more or less shows you everything.
And allows all the signals to run at full speed, albeit with gaps to allow for processing.
Yes, I know you can get 'scopes and analysers which decode most signals.
(In my case, not an available luxury)
I'm also more comfortable with instruments I know, than fighting one I don't.

The problem I had was the return signal start pulse was being corrupted (shortened).
Different devices decoding the same signal were not agreeing with each other!

In your case you may be able to capture fault condition only, then examine by hand.

Mike

[asmboy]

Can you create some hardware aid by using

a pair of 74hc595's (di -do)
and a clock counter plus suitable HC04 inverters
to monitor SPI blocks of 8 bits and

interrupt_on_count overflow (divide by 8 )
to a pic to read the parallel 'catch' of your
spi slave-to-parallel converter
HARDWARE i just envisioned??

Tristating the 595 OE pins lets you
select either of the 595 catch outputs for read back to a parallel port
of your monitor pic.

[Gabriel]

why not just buy a "bus pirate"... or a proper logic analyser?

bus pirate is 30 bucks at sparkfun and does what you want and much more... unless you are trying to do this for your own learning process..
_________________
CCS PCM 5.078 & CCS PCH 5.093

[Ttelmah]

Yes, that is more basic than I was thinking of, but is basically a DsPIC, and USB to UART interface.

Best Wishes

[PCM programmer]

If this is just for project development testing, then a low-cost logic
analyzer with an SPI interpreter would do the job. We have this one,
the LA1034:
http://www.pctestinstruments.com/index.htm

Here's a screen-shot. The middle waveforms show the SPI interpreter:
http://www.pctestinstruments.com/logicport/interpreters.htm

[asmboy]

what a S W E E T Analyzer - sign me up !!!

I am particularly happy with the Input Z spec too.