Hi all,
I'm working on a project where I will log measurements from a ADS8353-Q1, a two channel ADC (datasheet) onto the built in SD card with SDIO.
The ADC's SPI protocol starts with sending 16 bits , which programs the register (p. 28). Then the ADC sends 16 bits from its two MISO lines, which are the voltages measured by the ADC. I have two current SPI issues that I would be very grateful for help with.
-Occasionally the Teensy sends out the wrong value according to my AD2. I want to avoid this happening because I don't want to write to a reserved register.
- I don't know how to handle the fact this ADC has two MISO lines. I originally planned to use two SPI busses on the Teensy with one acting as a slave, but apparently the Teensy cannot be a SPI slave. If it can't be done I will simply have to use the 1 MISO mode and accept the lower throughput.
On the first problem - attached is my code, a waveform screenshot from my AD2's logic analyzer, and my wiring.
-Teensy is getting a stable 5V from my laptop, so noise isn't an issue.
- I am using pin 37 for select, 13 for clock and 11 for MOSI. For implementing MISO, I am planning on using pins 12 and 39, but can use any.
-Using only the default SPI.h library with the Arduino IDE. Have not gotten into using any of the SDIO stuff yet.
- Right now the teensy is connected directly to the o-scope, so I do not suspect there is any noise.
The intended transmission is 1000001010000000, with the other values being:
1100001111000000
0100000101000000
1100000101000000
So it seems to be the result of a slight delay on the MOSI, but I'm not sure how to solve it.
I'm working on a project where I will log measurements from a ADS8353-Q1, a two channel ADC (datasheet) onto the built in SD card with SDIO.
The ADC's SPI protocol starts with sending 16 bits , which programs the register (p. 28). Then the ADC sends 16 bits from its two MISO lines, which are the voltages measured by the ADC. I have two current SPI issues that I would be very grateful for help with.
-Occasionally the Teensy sends out the wrong value according to my AD2. I want to avoid this happening because I don't want to write to a reserved register.
- I don't know how to handle the fact this ADC has two MISO lines. I originally planned to use two SPI busses on the Teensy with one acting as a slave, but apparently the Teensy cannot be a SPI slave. If it can't be done I will simply have to use the 1 MISO mode and accept the lower throughput.
On the first problem - attached is my code, a waveform screenshot from my AD2's logic analyzer, and my wiring.
-Teensy is getting a stable 5V from my laptop, so noise isn't an issue.
- I am using pin 37 for select, 13 for clock and 11 for MOSI. For implementing MISO, I am planning on using pins 12 and 39, but can use any.
-Using only the default SPI.h library with the Arduino IDE. Have not gotten into using any of the SDIO stuff yet.
- Right now the teensy is connected directly to the o-scope, so I do not suspect there is any noise.
Code:
// Current Sensing - Channel A. AINP_A recieves VDiff, while AINM_A recieves VREF from the current sense board
// Voltage Sensing - Channel B. AINP_B recieves VMeasured, a 0 to 5V signal. AINM_B recieves a 2.5V referance voltage.
//MSB FIRST
#include <SPI.h>
const int slaveSelectPin = 37;
const word readMOSI = 0;
const word CFR_REGISTER = 33408; //1000001010000000 //See page 28 of datasheet.
void setup() {
// put your setup code here, to run once:
pinMode(slaveSelectPin, OUTPUT); //Slave select as output
digitalWrite(slaveSelectPin, HIGH); //Set as high to create a falling edge to begin transfer.
SPI.begin(); //Begin SPI
}
void loop() {
// put your main code here, to run repeatedly:
adc_Transmit();
}
void adc_Transmit() {
SPI.beginTransaction(SPISettings(20000000, MSBFIRST, SPI_MODE3));
digitalWrite(slaveSelectPin,LOW);
SPI.transfer16(CFR_REGISTER);
SPI.transfer16(readMOSI);
digitalWrite(slaveSelectPin,HIGH);
SPI.endTransaction();
}
The intended transmission is 1000001010000000, with the other values being:
1100001111000000
0100000101000000
1100000101000000
So it seems to be the result of a slight delay on the MOSI, but I'm not sure how to solve it.