USB-6255 PFI Clock DI SPI Question

[Wmarchewka]

Im clocking in SPI data using the SPI clock wired to PFI0 as the DI clock.  This works. Although I dont understand why i have to feed a "rate" into the clock, when the rate is set by the clock of the SPI data...

However, i need to clock in another SPI bus, but it appears you can only have one DI clock.

I tried about setting up a Change Detection on my clock pin, falling edge, and using that as a clock source to my timing block as "/Dev2/ChangeDetectionEvent" but in my read loop, it never read data and timed out.

EDIT: This would not work for my application, as i just read "Even though only one task can monitor for change detection at a time, any number of tasks can use the ChangeDetectionEvent as an input signal. "

I'm using AI for another task, though i do have spare pins on the AI.  

Any idea on how i can clock in 2 seperate SPI bus data?

[Kevin_Price]

Short answer: Nope, not with a USB-6255, at least not directly.  You *might* have been able to use AI for one of them if you weren't already consuming it for another task.

Longer (and more speculative) answer:  Maybe.  It'd take more post-processing work though.  You'd need to both wire and capture the 2 clock signals and all your data lines in your single DI task configured for change detection.  Then you'd need to split this data into 2 processing streams depending on which clock caused the change detection sample.  You probably need to consider the case where they both changed at the same time so you can send *that* sample to *both* streams.  You'd need to do the appropriate bit-masking for each individual stream too.  But this ought to get you to the point of having 2 separate SPI streams.

-Kevin P

[Wmarchewka]

I had thought about this briefly, but disregarded based on the fact that i would not be able to differentiate a simultaneous message.  Sending a simultaneously received message to be processed to have each stream to decide who it belongs to is a great idea.  One SPI channel is "message based" and the other is chip select driven.  

However, before i try this, im wondering if two SPI packets arrived at the same time, assuming each message is 32 bits in length, it appear I would receive 64 clocks. I guess i could sort this out in software.

[Kevin_Price]

Caveat: I have only a vague awareness of SPI but haven't ever done anything with it. 

That said, there are some subtle constraints with change detection when changes are very nearly coincident.  The change detect event rate is more limited than the sample latching rate -- see this msg for more info.  (Some of the rest of the thread might help for context, but quite a bit won't be relevant too.)

In a case where 2 SPI clocks very nearly coincide, it may be hard to predict exactly what will happen.  You may need to be prepared to look for and compensate for different scenarios.  In addition to checking for clock state as a method for detecting which clock edge caused sampling, you might also need to check the respective digital data for a change that happened when the corresponding SPI clock came too near the other SPI clock and couldn't cause another sample to be latched.   That kind of thing.

-Kevin P

[Wmarchewka]

Thank you for your time.