16-bit sample & store, then readback & play, finally store to SD

Op amp ordered.

I attached a version that has been tested with a 1284P.

I updated my AVRISP after a real struggle with Atmel Studio 6.1. The AVRISP now seems to work great, even on the USB 3.0 port.

Atmel Studio 6.1 is astounding, like 4 GB of stuff. I played with it for a while and then deleted it. It’s like backing up a Double Semi Tractor Trailer.

CrossRoads24Aug.zip (22.3 KB)

Hey Bill,
Can you confirm this operation? Checking to make sure the hardware works - digitizing a pot with ADC AD7680, sending it to DAC AD5662-1.
When the output climbs half-way, it jumps to 0 and climbs again.

Seems to be the ADC output doing it.

/* test to read from ADC and write it out to DAC to confirm data stream
 Voltage Reference REF194, 4.5VDC, used as power supply
 AD7680, 16 bit ADC but needs 24 bits read using SPI. 4 leading 0s, 4 trailing 0s
 AD5662-1, 16 bit DAC, but needs 24 bits - leading 0s, 2 more 0s for normal operation
#include <SPI.h>

byte ADCcs = 10;
byte DACcs = 7;
byte upper;
byte middle;
byte lower;
unsigned long combined;

void setup(){
  pinMode (ADCcs, OUTPUT);
  pinMode (DACcs, OUTPUT);
  SPI.setClockDivider(SPI_CLOCK_DIV16); // 2 MHz operation
  SPI.setDataMode(SPI_MODE3); //
void loop(){
  digitalWrite(ADCcs, LOW);
  upper = SPI.transfer(0);
  middle = SPI.transfer(0);
  lower = SPI.transfer (0);
  digitalWrite (ADCcs, HIGH);
  Serial1.print(" U ");
  Serial1.print(upper, HEX);
  Serial1.print(" M ");
  Serial1.print(middle, HEX);
  Serial1.print(" L ");
  Serial1.print(lower, HEX);
  combined = upper & 0x0F;
  combined =(combined<<8) + middle;
  combined = (combined<<8) +lower;
  combined = combined >>4;

  Serial1.print(" C ");

  digitalWrite (DACcs, LOW);
  SPI.transfer (0);
  SPI.transfer (highByte(combined));
  SPI.transfer (lowByte (combined));
  digitalWrite (DACcs, HIGH);


AD7680 16bit ADC SPI.pdf (295 KB)

AD5662 DAC 16 bit.pdf (578 KB)

The only thing I can see is the SPI mode may be wrong.

  SPI.setDataMode(SPI_MODE3); //

My understanding is that mode3 has the clock idle high and data is captured on rising clock.

I read this ugly explanation and looked at figure 20 in the AD7680 data sheet and decided SPI mode 2 was required. Mode 2 is idle clock high and data capture on falling edge.

It is also possible to take valid data on each SCLK rising edge rather than falling edge, since the SCLK cycle time is long enough to ensure the data is ready on the rising edge of SCLK. However, the first leading zero is still driven by the CS falling edge, and so it can be taken on only the first SCLK falling edge.

Mode 3 may cause the first bit to be dropped so all 24 bits are shifted one left. This would cause the the ADC to jump to zero midway since the high data bit would be lost.

That's my guess.

I may have the bit-bang ADC driver wrong.

I'll play some more. I mostly wanted to confirm the hardware chips and my wiring were okay (SMDs on adapters, see pic) before I jump into the stuff you wrote. They seem to work and my wiring in the protoboard is working.
I only have partial confidence my SPI test code is correct, and SPI mode could easily be part of that. They seem to be working despite the odd behavior.

This is what I have working so far. I fed PWM thru a pot to get a 1V signal, fed into the op-amp circuit to get the opamp working. Can't believe how long it took to get that working. Simple op amp with gain, nothing but trouble. Didn't help that I misread my schematic and connected 4.5V to pin 6 instead of pin 8 for a while.

I have your code downloaded and in my library folder. Need to move a couple wires for the big banging pin assignments you have and then get into it. Only looked at the readme.txt so far to start understanding what's needed. Getting there!

Many serial ADC chips are quirky. They do the analog to digital conversion on the fly using the readout clock to control the SAR conversion. The first clocks time the sample and hold then the rest control the conversion.

The AD7680 handles the first bit differently than later bits. A zero bit is presented when chip select goes low and only lasts until clock goes low. I think this may cause the first bit to be lost in SPI mode 3.

One way to verify this would be to modify this line

  combined = combined >>4;

to this

  combined = combined >>5;

If this works, you are only getting three zero bits before the 16 data bits.

You could also try SPI mode 2 which should capture all four leading zero bits.

Will try after fencing class, see it makes a difference. Moving on to your code after that no matter what.

Hi! I'm trying to compile "CrossRoads24Aug.zip" with the latest version of SdFat, but I really don't know how to cope with this error:

C:\Users\user\Documents\Arduino\libraries\CrossRoads\WaveFile.cpp: In member function 'bool WaveStream::open(const char*)':

C:\Users\user\Documents\Arduino\libraries\CrossRoads\WaveFile.cpp:20:23: error: 'class FatVolume' has no member named 'sdCard'

  if (!file.volume()->sdCard()->readBlock(m_bgnLBN, m_buf))

Can anyone help me?