03-18-2016 06:38 PM
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
Solved! Go to Solution.
03-21-2016 03:35 PM
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.
03-21-2016 04:13 PM
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
03-21-2016 04:27 PM
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.