Greetings,
I am developing on a conversion system that shares two ADS1258 converters on the same SPI bus. I have a few questions regarding the converter operation that isn't completely clear from the documentation (revised Oct 2007), and also a question about our setup.
First of all, our conversion mode is fixed channel. Originally our general method of reading data was to start a conversion, then read the data using the Channel Data Register format read command until the NEW bit was set. This seems to be indicated to be the ideal method of refreshing data, but another point of the documentation says that the status byte of the data is undefined in fixed channel mode. Which is correct? Is the only way to monitor for new data in fixed channel mode to monitor DRDY?
Another clarification of the documentation: are the DLY bits only relevant to auto scan mode, or are they relevant to fixed-channel mode as well?
Also, we are having some difficulties in trying to run the converter with different data rates. We use a general "sample and read" function that looks like this (in pseudocode):
sample_and_read(channel) {
toggle CS;
write channel to MUXSCH;
start conversion;
loop until DRDY;
read data using direct register format
stop conversion;
}
Based on my understanding of the converter, the only thing that should be different in the previous function for different sample rates is the length of time for loop until DRDY. The previous function works fine for most data rates, but occasionally for one data rate, the converter will somehow have a CONFIG register written to that sets the converter in auto-scan mode, thus corrupting further reads. It appears to be a timing issue. Could a command be misinterpreted if the SPI interface was borderline on the reset interval when the chip writes another command? We suspected this was the problem, so we modified the function to the following:
sample_and_read() {
toggle CS;
write selected channel to MUXSCH;
start conversion;
loop until DRDY;
toggle CS;
read data using direct register format
stop conversion;
}
However, this introduces a new problem. For a different data rate, this ends up giving less accurate measurements, but only for a certain channel selection. It is not unit specific, as we have demonstrated this on several units with the converters. Any ideas what our problem might be, or is there a much bigger issue with our sample and read function?
Thanks,
Corey