Hello! I was writing a program to communicate to an AD5722/AD5732/AD5752 DAC (GitHub link), and it works through 24-bit SPI communication to send over an 8 bit header and 16 bits of data.
While everything does work virtually as intended, with the DAC producing the output voltages I want, I've noticed when looking at my signals through a scope and also logic analyzer that between every 8 bits there's a very odd quirk. It seems that the data bits go high for a very brief time, much shorter than a clock cycle and it never gets read by the DAC, as it does not occur on the falling edge of the clock like it needs to. Additionally, the clock itself at that cycle is extended by the exact same amount of time as that spike. I figure this is just a weird quirk when using multiple SPI.transfer() functions one after another, but it even happens in the middle of a SPI.transfer16() function.
While this doesn't affect functionality and it is not crucial that it gets fixed, I'm still curious as to why this happens, if it's bad practice to keep it like this, and how I would change it so that it doesn't do that. Thank you very much for the help!
Attached is my code (too long to paste) and an image of the logic analyzer showing the spikes.
I'd interpret the datasheet that way that this device is SPI mode 1.
const int CLOCK_SPEED = 10000; // DAC is rated for 30MHz, Arduino clock is much lower? Signal started looking really bad @100kHz
The slowest possible clock speed is 125kHz (16MHz / 128), the hardware cannot make it slower.
The hardware is allowed to change the MOSI line in mode 1 and 2 as long as the signal is table at the falling edge of SCL.. The resolution of the screen shot is to low to tell if the timing is correct but it seems that everything is OK. This is not bad practice, is simply inside the specs.
Confirmed for an Arduino Uno. Only in the data signal MOSI and only at the rising edge of the clock.
This was happening on both my sparkfun arduino uno and my arduino nano. It occurs in the MOSI line, and it also makes the clock cycle at where it occurs slightly longer than the other clock cycles.
It is just a glitch. Perhaps it can be avoided with better code in the SPI library. Perhaps no one cares.
Alright thank you! I just thought it was a weird quirk but I knew it shouldn't be a problem because it's occurring in both the data and the clock, I just wanted to know if it was my doing or not. Maybe I'll have to take a look through the library and see what's causing it if I have the time, but at least I know that it's alright and will work fine regardless. Thanks for all the help!
