Hello,
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?
Best Regards,
Danny
Danny,
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
Kevin,
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.
Hi Kevin,
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.
Best regards,
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.