Lecture10:DigitalToAnalogueConversion < Embedded

Tags: view all tags

%SLIDESHOWSTART%
---+ Digital to Analogue Conversion
<h1 align="center">Digital to Analogue Conversion:</h1> <h1 align="center">the mcp4275</h1> <h2 align="center">Lecture 10<br /><br />Uli Raich<br /><br />UCC semester 2017/2018</h2>

---++ 
---+ Analogue versus digital

Up to now we only treated digital signals:
   * on/off for the LEDs
   * on/off to read the LED state
   * Powering or not powering coils to generate magnetic fields in a stepping motor
However:<br /><br />The world is mostly analogue:
   * Temperatures are changing continuously and not in steps
   * Pressure is an analogue value
   * Distance, time, current, resistance … are all analogue values

---++ 
---+ Converting from digital to analogue

Since our computer is a digital device we must<br /><br />
   * Convert digital values to analogue voltage levels<br />Digital to Analogue Conversion (DAC)<br /><br />
   * … and we must convert external analogue values to digital<br />Analogue to Digital Conversion (ADC)
---++ 
---+ Digital to analogue conversion

A digital to analogue converter does not really convert into a continuous waveform<br /><br />Since we have digital values as a base, there will be steps in the output waveform<br /><br />The size of these steps depends on the resolution of the DAC<br /><br />What is the smallest step a 12 bit DAC can produce on a 0..5V scale?

---++ 
---+ Can we smooth the output signal?

Yes, it is possible to smooth out these steps.

We need a low-pass filter, which filters out high frequencies

(the abrupt steps we have in the output signal) and lets pass only slower transitions.

When looking carefully at the output of our sine generator you will

also see these steps. In this case however they come from the

limited number of sine values (100) we calculate. To improve the resolution

we would have to increase the number of samples and the frequency

with which we send these values to the DAC.

---++ 
---+ How does a DAC work?

<img alt="dacPrinc.png" height="309" src="%ATTACHURL%/dacPrinc.png" title="dacPrinc.png" width="380" />

If you want to know more about DAC technology (and you should!)

have a look at this [[http://www.analog.com/media/en/training-seminars/tutorials/MT-014.pdf][excellent tutorial]], from which I have copied the above illustration.

---++ 
---+ The MCP4725 12 bit DAC

As a demo device we bought the MCP4725 DAC<br /><br />This is a 12 bit DAC which can be accesses by the I2C bus<br /><br />Here is its [[https://cdn-shop.adafruit.com/datasheets/mcp4725.pdf][data sheet]]

and here a photo of the device

<img alt="dac_front.png" height="396" src="%ATTACHURL%/dac_front.png" title="dac_front.png" width="372" />

---++ 
---+ The !I2C bus

The I2C bus is an industrial standard 2 wire bus using a data (SDA) and a clock (SCL) line.

Adding Vcc and Gnd we need a mere 4 wires to connect

a I2C device to the Raspberry Pi cobbler

The I2C bus was invented by Philips

---++ 
---+ Typical !I2C connections

<img alt="i2c_conn.png" height="274" src="%ATTACHURL%/i2c_conn.png" title="i2c_conn.png" width="739" />

---++ 
---+ Open drain signals

Open drain signals mean that you can pull a line down

but you cannot set it to a high level.

If nobody pulls the line down, then it is at Vcc level,

pulled up by a pull-up register.

Like this the contention problem is solved where one device tries

to set a line to a high level, while another sets it to low,

thus creating a short circuit.

---++ 
---+ I2C Master and slave

The I2C bus has at least one master (in our case the interface in the

Raspberry Pi’s ARM processor) and several slaves

We have the following I2C slave devices:<br /><br />
   * mcp4275 DAC<br /><br />
   * bmp180 barometric pressure sensor<br /><br />
   * pcf8581 8 bit ADC<br /><br />
   * ads115 16 bit ADC<br /><br />
   * at24c32 eeprom<br /><br />
   * ds1307 real time clock<br /><br />
   * mma845x accelerometer<br /><br />
   * pcf8574 I/O expander used on the 2-line LCD display
---++ 
---+ I2C addressing

Since there can be several slaves on the bus there must

be a means of distinguishing them through addressing:

Every I2C slave has a 7 bit address associated with it

Usually this address is determined by the manufacturer but

often there are address pins on the devices allowing the

user to have several devices of the same type on the bus

---++ 
---+ I2C buses and !I2C addresses on the Raspberry Pi

The Raspberry Pi has 2 I2C buses with bus 1 being put onto the cobbler

You can find out the addresses of the I2C slaves are currently

connected with the<i> i2cdetect</i> command

<img alt="i2cdetect.png" height="278" src="%ATTACHURL%/i2cdetect.png" title="i2cdetect.png" width="467" />

---++ 
---+ Initiating an !I2C transfer

<img alt="initiate.png" height="225" src="%ATTACHURL%/initiate.png" title="initiate.png" width="555" />

---++ 
---+ Start stop conditions

The master starts a transfer by creating a

start condition:<br /><br />
   * high to low transition on SDA while SCL is high
and ends the transfer with a <br /><br />
   * stop condition:
 low to high transition on SDA while SCL is high4

<img alt="startStop.png" height="217" src="%ATTACHURL%/startStop.png" title="startStop.png" width="392" />

---++ 
---+ Data transmission

Data are transmitted with the SDA line stable with SCL is high

<img alt="dataTransfer.png" height="344" src="%ATTACHURL%/dataTransfer.png" title="dataTransfer.png" width="690" />

---++ 
---+ A write cycle

A write cycle:<br /><br />After the start condition the device address. The eighth bit, the R/W bit is kept low.<br /><br />The second data byte is considered the register byte and the last one the data byte<br /><br />The slave acknowledges each byte transfer.

<img alt="writeCycle.png" height="117" src="%ATTACHURL%/writeCycle.png" title="writeCycle.png" width="636" />

---++ 
---+ The read cycle

The read cycle is a bit more complex:

First the master sends the slave address with R/W set to write

Then it sends the register information.

After that another address byte is sent, this time with RW set to read

And finally the slave sends the data. The master still sends the clock but

releases the SDA line allowing the slave to control it

<img alt="readCycle.png" height="91" src="%ATTACHURL%/readCycle.png" title="readCycle.png" width="702" />

---++ 
---+ I2C clock frequency

I2C bus supports different transfer speeds:<br /><br />
   * Standard: 100 kbps<br /><br />
   * Fast: 400 kbps<br /><br />
   * High speed: 3.4 Mbps
pigpio seems to use the standard speed

while the Raspberry Pi can run I2C transfers of up tp 1.66 Mbps

However: you need more low level libraries or direct register

access to accomplish these high speeds

---++ 
---+ MCP4725

<img alt="mcp4725Desc.png" height="329" src="%ATTACHURL%/mcp4725Desc.png" title="mcp4725Desc.png" width="481" />

---++ 
---+ Specs of the MCP4275

<img alt="dacSpecs.png" height="369" src="%ATTACHURL%/dacSpecs.png" title="dacSpecs.png" width="377" />

---++ 
---+ MCP4275 registers

<img alt="dacRegs.png" height="459" src="%ATTACHURL%/dacRegs.png" title="dacRegs.png" width="810" />

---++ 
---+ MCP4275 !I2C fast write

How does the I2C write cycle look like in the MCP4275?

The MCP4275 fast write cycle write only the DAC register and not the EEPROM.

This is enough for what we want to do.

<img alt="mcp4725i2cWrite.png" height="221" src="%ATTACHURL%/mcp4725i2cWrite.png" title="mcp4725i2cWrite.png" width="718" />

---++ 
---+ MCP4275 normal write cycle

<img alt="mcpNormalWrite.png" height="661" src="%ATTACHURL%/mcpNormalWrite.png" title="mcpNormalWrite.png" width="877" />

---++ 
---+ Read back the DAC data

<img alt="mcp4725ReadCycle.png" height="450" src="%ATTACHURL%/mcp4725ReadCycle.png" title="mcp4725ReadCycle.png" width="775" />

---++ 
---+ pigpio: i2c_open

<img alt="i2c_open.png" height="193" src="%ATTACHURL%/i2c_open.png" title="i2c_open.png" width="652" />
---++ 
---+ I2C access initialization with pigpio

In addition to opening the library with pigpio_start we now also must

make a connection to the I2C driver:

<img alt="pigpio_i2cInit.png" height="477" src="%ATTACHURL%/pigpio_i2cInit.png" title="pigpio_i2cInit.png" width="658" />

---++ 
---+ Accessing !I2C with pigpio

Coming back to fast write mode, we must write 3 bytes:<br /><br />
   * Address + R/W
   * Register
   * Data
The register byte contains also the high 4 bits on the 12 bit DAC data word

The first byte is created and written within the library extracting the !I2C address

for the !I2C initialization call

<img alt="mcp4725i2cWrite.png" height="221" src="%ATTACHURL%/mcp4725i2cWrite.png" title="mcp4725i2cWrite.png" width="718" />

---++ 
---+ i2c_write_byte_data

The pigpio library provides a function

<img alt="i2c_write_byte_data.png" height="194" src="%ATTACHURL%/i2c_write_byte_data.png" title="i2c_write_byte_data.png" width="646" />

This means we have to split our 12 bit DAC data into 2 parts:

The highest 4 bits go into i2c_reg, the lower 8 bits into bVal

---++ 
---+ Writing the DAC value, an example

_dacValue_ is a _short_, while _reg_ and _value_ are _unsigned char_

<img alt="dacWriteExample.png" height="183" src="%ATTACHURL%/dacWriteExample.png" title="dacWriteExample.png" width="717" />

---++ 
---+ DAC performance

There are a number of criteria which characterize the performance of a DAC<br /><br />
   * Its resolution or its least significant bit (lsb)<br /><br />
   * Its settling time (maximum speed you can go)
   * Its integral non-linearity or relative accuracy
   * Its differential non-linearity
   * Its offset error
   * Its gain error ...
---++ 
---+ Relative accuracy
| <img alt="INL_Def.png" height="362" src="%ATTACHURL%/INL_Def.png" title="INL_Def.png" width="385" /> | <img alt="inlDiag.png" height="387" src="%ATTACHURL%/inlDiag.png" title="inlDiag.png" width="385" /> |
---++ 
---+ Differential non-linearity
| <img alt="dnldescr.png" height="369" src="%ATTACHURL%/dnldescr.png" title="dnldescr.png" width="383" /> | <img alt="dnlDiag.png" height="391" src="%ATTACHURL%/dnlDiag.png" title="dnlDiag.png" width="378" /> |
---++ 
---+ Offset error
| <img alt="offsetDesc.png" height="151" src="%ATTACHURL%/offsetDesc.png" title="offsetDesc.png" width="363" /> | <img alt="offsetDiag.png" height="271" src="%ATTACHURL%/offsetDiag.png" title="offsetDiag.png" width="366" /> |

---++ 
---+ Gain error
| <img alt="gainErrorDesc.png" height="214" src="%ATTACHURL%/gainErrorDesc.png" title="gainErrorDesc.png" width="361" /> | <img alt="gainError_Diag.png" height="362" src="%ATTACHURL%/gainError_Diag.png" title="gainError_Diag.png" width="394" /> |
---++ 
---+ Settling Time

| <img alt="settlingTime.png" height="193" src="%ATTACHURL%/settlingTime.png" title="settlingTime.png" width="386" /> | <img alt="settlingHigh.png" height="274" src="%ATTACHURL%/settlingHigh.png" title="settlingHigh.png" width="372" /> |
| <img alt="settlingLow.png" height="264" src="%ATTACHURL%/settlingLow.png" title="settlingLow.png" width="361" /> | |
%SLIDESHOWEND%

-- %USERSIG{UliRaich - 2017-10-31}%

---++ Comments

%COMMENT%

Attachments

Topic attachments
I	Attachment	History	Action	Size	Date	Who
png	INL_Def.png	r1	manage	28.9 K	2017-11-06 - 10:46	UnknownUser
png	addressing.png	r1	manage	31.1 K	2017-10-31 - 18:03	UnknownUser
png	blockDiagram.png	r1	manage	26.2 K	2017-10-31 - 18:03	UnknownUser
png	connection.png	r1	manage	30.9 K	2017-10-31 - 18:03	UnknownUser
png	dacPrinc.png	r1	manage	39.1 K	2017-11-01 - 08:57	UnknownUser
png	dacRegs.png	r1	manage	57.5 K	2017-11-06 - 09:48	UnknownUser
png	dacSpecs.png	r1	manage	33.9 K	2017-11-06 - 09:51	UnknownUser
png	dacWriteExample.png	r1	manage	28.4 K	2017-11-06 - 10:23	UnknownUser
png	dac_front.png	r1	manage	1097.6 K	2017-10-31 - 18:03	UnknownUser
png	dataTransfer.png	r1	manage	18.7 K	2017-11-03 - 16:50	UnknownUser
png	dnlDiag.png	r1	manage	23.7 K	2017-11-06 - 10:44	UnknownUser
png	dnldescr.png	r1	manage	31.5 K	2017-11-06 - 10:44	UnknownUser
png	eqation.png	r1	manage	17.0 K	2017-10-31 - 18:03	UnknownUser
png	gainErrorDesc.png	r1	manage	18.9 K	2017-11-06 - 10:44	UnknownUser
png	gainError_Diag.png	r1	manage	29.4 K	2017-11-06 - 10:44	UnknownUser
png	i2c_conn.png	r1	manage	23.8 K	2017-11-03 - 16:26	UnknownUser
png	i2c_open.png	r1	manage	15.0 K	2017-11-06 - 10:20	UnknownUser
png	i2c_write_byte_data.png	r1	manage	19.2 K	2017-11-06 - 10:20	UnknownUser
png	i2cdetect.png	r1	manage	25.5 K	2017-11-03 - 16:44	UnknownUser
png	initiate.png	r1	manage	19.2 K	2017-11-03 - 16:49	UnknownUser
png	inlDiag.png	r1	manage	24.6 K	2017-10-31 - 18:03	UnknownUser
odp	lecture_10.odp	r1	manage	2016.0 K	2017-11-16 - 18:32	UnknownUser
png	mcp4725Desc.png	r1	manage	38.5 K	2017-11-06 - 09:51	UnknownUser
png	mcp4725ReadCycle.png	r1	manage	56.8 K	2017-11-06 - 09:58	UnknownUser
png	mcp4725i2cWrite.png	r1	manage	30.8 K	2017-11-06 - 09:58	UnknownUser
png	mcpNormalWrite.png	r1	manage	109.9 K	2017-11-06 - 09:58	UnknownUser
png	offsetDesc.png	r1	manage	13.8 K	2017-11-06 - 10:45	UnknownUser
png	offsetDiag.png	r1	manage	18.6 K	2017-11-06 - 10:45	UnknownUser
png	pigpio_i2cInit.png	r1	manage	58.0 K	2017-11-06 - 10:10	UnknownUser
png	pinout.png	r1	manage	33.6 K	2017-10-31 - 18:03	UnknownUser
png	readCycle.png	r1	manage	12.7 K	2017-11-03 - 16:49	UnknownUser
png	resolution.png	r1	manage	17.6 K	2017-10-31 - 18:03	UnknownUser
png	settlingHigh.png	r1	manage	31.5 K	2017-10-31 - 18:03	UnknownUser
png	settlingLow.png	r1	manage	30.4 K	2017-10-31 - 18:03	UnknownUser
png	settlingTime.png	r1	manage	16.9 K	2017-10-31 - 18:03	UnknownUser
png	startStop.png	r1	manage	7.8 K	2017-11-03 - 16:50	UnknownUser
png	writeCycle.png	r1	manage	11.8 K	2017-11-03 - 16:49	UnknownUser

Topic revision: r6 - 2017-11-16 - uli