I have an ADS8320 hooked up to to an MSP430FR5739 micro-controller.I read in the ADS8320 manual that its SPI need to be clocked 22 times continuously to receive a 16 bits ADC value. (5 for generating a same, 1 returns 0, 16 for the actual data)
The normal MSP430FR5739 SPI eUSCI peripheral can be configured to 7 or 8 bit transfers. When using 3 consecutive 8 bits transfers, the clock to the ADS8320 is non-continuous (it is actually composed of 3 bursts of 8 clocks each).
Can I safely use 3 consecutive 8 bits transfers or do I need to write a dedicated function with continuous clock and polling?
Generally speaking for a SPI bus a disruption in continuity of the SCLK is not a problem so long as CS is also not rebounded. In this case the serial bus is reset and you'd run into problems. Of course sometimes some devices can deviate from this compliance, so it's a worthwhile question to ask. I wrote some quick code to test this, here my clocks are divided into two 11 bit groups and I apply a ludicrously long delay between the pair of clock bursts:
No problems. Just make sure CS stays low and you'll be fine.
-------------------------------------- Kevin Duke Precision DAC Applications
Many thanks for your answer !!!
Glad to help. As one final note here for anyone else that stumbles upon this thread, it's okay to interrupt the SCLK in general but in devices that use the serial clock as a conversion clock as well should not be interrupted during the conversion clock period. This should be a case-by-case investigation for each device.
So now I am confused again. My original question was about the ADS8320. This device has no other clock than its DCLOCK input (clocked in three - 8 bit bursts by my MSP430 SPI output). I am now able to read reasonable values from the ADC. But am I damaging my accuracy by dividing the clock? The datasheet is a bit unclear about this issue.
I did not notice any substantial impact on performance even with the large gap in clocks. As long as you're not inserting an unreasonable amount of time your results should be accurate.
My note was really just intended to keep other people that may notice this post from wildly inserting clock breaks on other devices where there may be a problem.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.