From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

High-Speed Digitizers

cancel
Showing results for 
Search instead for 
Did you mean: 

Why is SPI Involved with Clock Select on 5761/2 Digitizers?

Solved!
Go to solution

The CLIP reference for the 5761 and 5762 Sample Clock Commit signal states, "When changed from FALSE to TRUE, updates the Sample Clock according to the settings defined by the Sample Clock Select signal."  The shipping examples bookend the rising edge of Sample Clock Commit with checking SPI Idle.  Why is SPI involved with setting the sample clock?

 

Thanks,

 

Steve K

0 Kudos
Message 1 of 4
(4,596 Views)

The 5761 uses the SPI bus to configure the clock distribution chip. The point of waiting for the SPI to go idle is to confirm that the command has been succsfully written. If the bus isn't idle shortly after issuing a clock commit signal it means something is preventing the command from being written in a timely manner and further investigation is warrented.

 

The comments in the Configure Clock.vi in the 5761 Clock Select example mention this. See comment #4.

 

5761_configure_clock.PNG

Message 2 of 4
(4,565 Views)

Thanks David,

 

I'm trying to build target-driven commands for configuring the sample clock and other things like ADC pedestal configuration.  I guess I'll need 10 msec timeouts on both ends of the sample clock commit signal.  I have a requirement to PLL to IOModSyncClock, so if SPI doesn't go idle within the timeout, should I abort?  In other words, if SPI doesn't go Idle 10 msec after the rising edge of Sample Clock Commit, then I'm not locked (per Sample Clock Select = Lock to IOModSyncClock).

 

Regards,

 

Steve K

0 Kudos
Message 3 of 4
(4,554 Views)
Solution
Accepted by topic author Pie566942.0

I have a requirement to PLL to IOModSyncClock, so if SPI doesn't go idle within the timeout, should I abort?  In other words, if SPI doesn't go Idle 10 msec after the rising edge of Sample Clock Commit, then I'm not locked (per Sample Clock Select = Lock to IOModSyncClock).

I wouldn't abort, rather I would throw a meaningful error that allows you to recover gracefully or stop execution. Otherwise it sounds like you have the correct impression on what the SPI Idle remaining false should imply. Though I think 10ms sounds a little too short. I'd go with at least 100ms, probably closer to 1s just to be safe. If it's taking more than 1s then you can safely assume that something wasn't configured properly prior to committing the clock configuration.

Message 4 of 4
(4,550 Views)