4
\$\begingroup\$

My design requires a 16-bit DAC with 100kS/s plus and SPI communication. Strangely to me, the cheapest 16-bit DACs that meet the requirement (parametric search) have a 24-bit SPI word, like the AD5662 (pdf) I'm trying to use. The least significant 16-bits are the output value to update and the upper 8-bits are configuration (only 2 of the 8 are actually used). This mode of operation is inconvenient for my 16-bit micro-controller, as the associated ADC in the design has a 16-bit SPI word, ADC161S626 (pdf). This means my micro-controller needs to write x3 8-bit packets instead of x1 16-bit.

Why do manufactures do this? What would be the best way of perform the communication?

If both DAC and ADC were 16-bit SPI word I could read and write at the same time without having to reconfigure the SPI module and data in the micro-controller.

\$\endgroup\$
3
  • 4
    \$\begingroup\$ The only way for you to communicate with this part is as shown in the datasheet. AD (in particular) do this sort of thing because they usually have a family of parts, where different parts use more or less of the configuration word and it is a simple matter to drop in the solution for multiple parts. \$\endgroup\$
    – Peter Smith
    Feb 25, 2018 at 15:28
  • \$\begingroup\$ That's what I'd expect, but I couldn't find a matching ADC+DAC with similar characteristics. Do you know of one? Like mentioned, the DACs in this price range with this performance are similar in the 24bit issue. \$\endgroup\$
    – A. Vieira
    Feb 25, 2018 at 18:31
  • 2
    \$\begingroup\$ "Why do manufacture[r]s do this?" - Because they have more than 16 but less than 24 bits they want to transfer... duh? \$\endgroup\$
    – user253751
    Feb 25, 2018 at 23:14

2 Answers 2

Reset to default
7
\$\begingroup\$

You are making too much of a minor inconvenience.

First, you probably can do two 16 bit transfers. The device will respond with zeros or garbage in the extra 8 bits, and you ignore them in your firmware.

However, the logical thing to do is three 8-bit transfers. Surely your micro can be set up to transfer 8-bit chunks.

At 100 kS/s, you have 10 µs per sample. That's a "long" time for SPI that can probably be clocked at 10 MHz (I didn't check the datasheet, but such speed is usually supported by such devices). Each bit therefore takes 100 ns. Transferring 24 bits therefore takes 2.4 µs just for the bits, plus a little overhead to select and de-select the chip.

Overall, you should be able to transfer the necessary data in about ¼ the available time, certainly within ⅓ the available time.

There is no problem here. You just have to architect the firmware up front, taking the specific characteristics of this D/A into account.

As for why the manufacturers do this? Two whole bytes are used for the data. You said yourself that some status and configuration is also transmitted, so that obviously takes at least a part of one more byte. Most SPI masters have hardware that transfers whole bytes, so they document the extra bits as being in a whole byte. They correctly realize this is really no big deal to firmware writers.

\$\endgroup\$
4
  • \$\begingroup\$ I'm pretty sure that the problem is different configurations for different slaves sharing SPI clock and data. Many microcontrollers will be able to use hardware triggered DMA (whether from a timer or a data ready GPIO) to communicate with multiple devices that each have their own slave select, but not be able to rewrite serial peripheral configuration on a per-slave basis. (Of course, all the SPI transfers can be done using 8-bit words, it's not like the word size has any effect on the wire, as opposed to say I2C) \$\endgroup\$
    – Ben Voigt
    Feb 25, 2018 at 16:34
  • 1
    \$\begingroup\$ The annoying thing with using 8 bit transfers instead of 16 bit is you need a processor interrupt to start the next 8 bits, which can slow you down. Switching to DMA-based SPI will solve that problem. \$\endgroup\$
    – Selvek
    Feb 25, 2018 at 16:38
  • \$\begingroup\$ Thank you Olin. Your comment settles the deal for me. What I felt was weird was the need to set the configuration bits every time you transmit a new sample. I will check how a DMA solution could work. \$\endgroup\$
    – A. Vieira
    Feb 25, 2018 at 18:37
  • 1
    \$\begingroup\$ @A.Vieira it's the simplest possible design from the DAC's point of view. It just has 18 bits of configuration, and all of them are updated on a write. No addresses or commands to decode to figure out which thing you want to write, you just give it a complete state every time. \$\endgroup\$
    – hobbs
    Feb 26, 2018 at 1:23
1
\$\begingroup\$

Why do manufacturers do this?

Impossible to answer, but I will offer you a guess. I think the problem is that you are looking at the wrong DAC for your application.

You have selected it from the parametric search based on the listed speed, without looking at the datasheet. You state that you need more than 100 kS/s. Fine, the datasheet says that you have a settling time of 10 µs - this is roughly in the same ballpark.

But if you take a look at application list and the rest of the datasheet, everything indicates that this DAC was designed for low frequency and accuracy. They don't even mention the frequency range as a feature!

Thus, for the applications this DAC is designed to work in, the number of bits per sample does not matter at all, because it is not meant to be updated at such a fast rate. The simplicity of a stateless design where all information is transmitted in one word outweighs the performance gain with 16 bits per transfer.

\$\endgroup\$
1
  • \$\begingroup\$ I understand what you mean, but I don't think the DAC was designed for low speed (sure 100kHz is on the limit). It states that the SCLK can be as high as 30 MHZ and that you need to wait 33 ns before the next write sequence. This means you can update the output even before one settling period has passed. It is limited by the settling time/slew rate, more than anything. \$\endgroup\$
    – A. Vieira
    Feb 25, 2018 at 18:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.