Difference between revisions of "Example SPI test"

From wiki.emacinc.com
Jump to: navigation, search
m (Your parameters are inconsistent. Here, you name them device and length, but down below, you refer to them as device and channel)
 
(17 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{todo|Buggy (2.21.14-17:40->BS+);(2.24.14-13:00->MD-)(2.28.14-17:48->BS+)(03.10.14-13:30->MD-)|Brian Serrano|project=oe 4,md,Buggy,bs}}
+
{{todo|Buggy (2.21.14-17:40->BS+);(2.24.14-13:00->MD-)(2.28.14-17:48->BS+)(03.10.14-13:30->MD-)(08.27.14-16:55->BS+)(09.09.14-17:20->MD-)(09.10.14-17:00->BS+)(09.13.14-21:40->MD+) |Brian Serrano|project=oe 4,md,Complete,bs}}
  
 
This is a guide to the <code>spi_test</code> example project included in the EMAC OE SDK.
 
This is a guide to the <code>spi_test</code> example project included in the EMAC OE SDK.
Line 15: Line 15:
 
The <code>spi_test</code> project builds one executable: <code>spi_test</code>.
 
The <code>spi_test</code> project builds one executable: <code>spi_test</code>.
  
== Opening, Building, and Uploading the Project Files ==
+
== Opening, Building and Uploading the Project Files ==
  
For information on opening the project from within Eclipse, please see, [[Importing the EMAC OE SDK Projects with Eclipse]].  Then follow, [[Using the EMAC OE SDK Projects with Eclipse]], for information on how to build, upload, and execute the example.
+
For information on opening the project from within Eclipse, please see [[Importing the EMAC OE SDK Projects with Eclipse]].  Then, follow [[Using the EMAC OE SDK Projects with Eclipse]] for information on how to build, upload and execute the example.
  
The example is located in the path below:
+
Alternatively, the <code>Makefile</code> can be used with the <code>make</code> command from the commandline to build and upload the example.  For information on this method, please see [[Using EMAC OE SDK Example Projects]].
  
=== This isn't quite correct.  This is you typing a relative path (not absolute) at the command prompt. It should be something more like: ===
+
====EMAC SDK 5.X====
=== ${path_to_EMAC_SDK}/projects/spi/ ===
+
 
<syntaxhighlight lang=console>
+
For information on opening the project from within QtCreator, please see [[Getting_Started_With_Qt_Creator#Adding_Source_Files | QtCreator: Adding Source Files]].  Then, follow [[Getting Started With Qt Creator]] for information on how to build, upload and execute the example.
developer@ldc:~$ path/to/EMAC/SDK/projects/spi
 
</syntaxhighlight>
 
  
Alternatively, the <code>Makefile</code> can be used with the <code>make</code> command from the command-line to build and upload the example.  For more information on this method, please see, [[Using EMAC OE SDK Example Projects]].
+
Alternatively, the <code>CMakefile.txt</code> can be used with the <code>cmake</code> command from the commandline to build and upload the example.  For information on this method, please see [[Getting_Started_with_the_EMAC_OE_SDK#Target_Machine_Compiling | Getting Started with the EMAC OE SDK]].
  
 +
Code can be found at http://git.emacinc.com/OE/example-projects
 
== Usage and Behavior ==
 
== Usage and Behavior ==
 
===Hardware Requirements===
 
===Hardware Requirements===
Line 38: Line 37:
 
The <code>indexed_atod_test</code> program is executed from the console. It takes two parameters.  
 
The <code>indexed_atod_test</code> program is executed from the console. It takes two parameters.  
  
=== Your parameters are inconsistent.  Here, you name them ''device'' and ''length'', but down below, you refer to them as ''device'' and ''channel'' ===
+
  root@emac-oe~:$ ./indexed_atod_test device channel
  root@emac-oe~:$ ./indexed_atod_test device length
 
  
 
:* <code>device</code>: Name of the <code>indexed_atod</code> device node.
 
:* <code>device</code>: Name of the <code>indexed_atod</code> device node.
Line 45: Line 43:
  
 
{|style="margin: 0 auto;"
 
{|style="margin: 0 auto;"
| [[File:Potentiometer_Circuit.png|left|thumb|300px|alt=A potentiometer circuit.|Figure 1: Potentiometer Circuit]]
+
| [[File:Potentiometer3.jpg|left|thumb|300px|alt=A potentiometer circuit.|Figure 1: Potentiometer Circuit]]
 
| [[File:Hdr8_chan1.jpg|right|thumb|250px|alt=HDR8 Analog I/O|Figure 2: HDR8 ANALOG I/O]]<br clear=all>
 
| [[File:Hdr8_chan1.jpg|right|thumb|250px|alt=HDR8 Analog I/O|Figure 2: HDR8 ANALOG I/O]]<br clear=all>
 
|}
 
|}
  
=== The dots should be on the lines, not near them, in the diagram. The C dot should be between the ground symbol and the bottom of the pot (on the line); likewise, the A dot should be on the line between the Vcc rail symbol and the top of the pot. The B symbol should be on the line just to the right of the wiper of the pot. The dots on the mechanical drawing of the pot look strangeNormally, the mechanical drawing will have a drawing of the physical shape of the terminals rather than a schematic representation of them.  It would be better to give the mechanical drawing legs, and label the legs A, B, and C. ===
+
This example command was run on an EMAC SoM-150ES carrier board with a SoM-9G20M. This test uses a potentiometer for input to the A/D. You will be communicating with the mcp3208 chip, which is an 8-channel 12-bit A/D converter with SPI Serial Interface. Figure 1 provides a potentiometer test circuit for help on connection to the SoM-150ES carrier boardA circuit like this is recommended for familiarizing oneself with the A/D code before connecting the actual device to be measured by the A/D.
  
This example command was run on an EMAC SoM-150ES carrier board with a SoM-9G20M. This test uses a potentiometer for input to the A/D. You'll be communicating to the mcp3208 chip, which is a 8-channel 12-bit A/D converter with SPI Serial Interface. Figure 1 provides a potentiometer circuit for help on connection to the SoM-150ES carrier board.
+
Before running the command in the terminal, you will need to connect the potentiometer to the carrier board as diagrammed. Figure 2 shows where to connect the potentiometer on Header 8 of the SoM-150ES. You will be focusing on CARR_ANL_1 for this example.  
  
Before running the command in the terminal, you'll want to connect the potentiometer to the carrier board. Figure 2 shows where to connect the potentiometer on Header 8 of the SoM-150ES. You'll be focusing on CARR_ANL_1 for this example. Turn the potentiometer counter-clockwise as far as it goes. You'll see the results when you run the command below. Test results will be displayed in the terminal.
+
Turn the potentiometer counter-clockwise as far as it goes. You'll see the results when you run the command below. Test results will be displayed in the terminal.
  
 
<syntaxhighlight lang=console>
 
<syntaxhighlight lang=console>
Line 63: Line 61:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
The results that are displayed from the terminal show channel 1 analog value at 4094. All the other results are just noise coming from the mcp3208 chip.
+
The results that are displayed from the terminal show channel 1 analog value at 4094. All the other results are just noise coming from the mcp3208 chip.  This noise can be virtually eliminated by grounding the unused A/D inputs.
  
 
For the second example, turn the potentiometer clockwise as far as it goes. You'll see how channel 1 results will change when running the command below. Test results will be displayed in the terminal.
 
For the second example, turn the potentiometer clockwise as far as it goes. You'll see how channel 1 results will change when running the command below. Test results will be displayed in the terminal.
Line 75: Line 73:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
The results show channel 1 analog value at zero. You can fluctuate the value by turning the potentiometer in different directions.  
+
Here, the results show channel 1 analog value at zero. Your results may vary, depending on the characteristics of your potentiometer and the ADC noise present.  You can alter the value by turning the potentiometer to different positions.  
  
 
[[File:Hdr8_chan6.jpg|center|thumb|250px|alt=HDR8 Analog I/O|Figure 3: HDR8 ANALOG I/O]]<br clear=all>
 
[[File:Hdr8_chan6.jpg|center|thumb|250px|alt=HDR8 Analog I/O|Figure 3: HDR8 ANALOG I/O]]<br clear=all>
  
Before doing example 3, you'll want to put the wiper (B) wire on pin 9 of the SoM-150ES carrier board. Figure 3 shows that pin 9 is CARR_ANL_6. Turn the potentiometer counter-clockwise about half way. You'll see how channel 6 results will change when running the command below. Test results will be displayed in the terminal.
+
Before doing example 3, you'll want to put the wiper (B) wire on pin 9 of the SoM-150ES carrier board. Figure 3 shows that pin 9 is CARR_ANL_6. Turn the potentiometer counter-clockwise about half way. You will see how the values on channel 6 will change when running the command below. Test results will be displayed in the terminal.
  
 
<syntaxhighlight lang=console>
 
<syntaxhighlight lang=console>
Line 92: Line 90:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
The results show channel 6 analog value at 2044, which is about half way. You can change any of the channels value with the potentiometer as long as you put the wiper pin on the channel you want to change.
+
The results show the channel 6 analog value at 2044, which is about half way (4095/2). You can change any of the channels value with the potentiometer as long as you put the wiper pin on the channel you want to change.
  
=== Using spi_test ===
+
Due to ADC noise, you may see the values fluctuate slightly from one run to the next.  This is normal behavior.  This fluctuation can be more severe with some potentiometers than it is with others; some potentiometers are more prone to picking up noise.  The noise will also be more severe with longer wires, due to transmission line effects.  Eliminating noise is typically the greatest challenge in high resolution A/D conversion (especially at 18 bit and above), so you should expect to see some noise when performing an informal test such as this.
  
The <code>spi_test</code> program is executed from the console. It takes three parameters.
 
  
root@emac-oe~:$ ./spi_test device length mosi
+
==Updates for iPac9x25==
 +
In order to run these examples on the board, either follow the schematic from figure 4 or use part MIKROE-304.
 +
{|style="margin: 0 auto;"
 +
|[[File:Spi Test Schematic.png|thumb|Figure 4: Schematic used to set up spi test for iPac9x25]]
 +
<br clear=all>
 +
|}
  
:* <code>device</code>: Name of the <code>spi</code> device node.
 
:* <code>length</code>: Length of <code>spi</code> transactions in bytes.
 
:* <code>mosi</code>: Hex value to be transmitted in hexadecimal.
 
 
This example command was run on an EMAC SoM-150ES carrier board. Test results will be displayed in the terminal. 
 
 
<syntaxhighlight lang=console>
 
root@emac-oe~:$ ./spi_test /dev/mcp3208 3 CDEF
 
MOSI  MISO
 
CD  : 00
 
EF  : 01
 
FF  : 04
 
</syntaxhighlight>
 
During the <code>SPI</code> clock cycle, the master sends a bit on the MOSI line; the slave then reads it from that line. Next, the slave sends a bit on the MISO line; the master then reads it from that same line.
 
 
For this example, we are using an <code>mcp3208</code> device with a <code>length</code> of 3, and a hex value of <code>CDEF</code>.
 
 
<syntaxhighlight lang=console>
 
root@emac-oe~:$ ./spi_test /dev/mcp3208 4 CCDD
 
MOSI  MISO
 
CD  : 00
 
EF  : 01
 
FF  : AC
 
FF  : 00
 
</syntaxhighlight>
 
When using the same device, but different length and hex value, the results differ.
 
<syntaxhighlight lang=console>
 
root@emac-oe~:$ ./spi_test /dev/mcp3208 5 EEFF
 
MOSI  MISO
 
EE  : 00
 
FF  : 00
 
FF  : F8
 
FF  : 00
 
FF  : 00
 
</syntaxhighlight>
 
In this third example, the results change again because of the different length and hex value.
 
 
<!--
 
'''NOTE: A better description of the output is needed, along with more examples of using it.  There should be at least 3-5 examples.  As an example, you can see the way I demonstrated usage of the MySQL commandline [http://liferay.emacinc.com:8080/web/engineering/wiki/-/wiki/Main/Using+the+MySQL+Command+Line on our Liferay site].'''
 
-->
 
 
== Summary ==
 
== Summary ==
The <code>spi_test</code> C example project demonstrates how to use the <code>SPI</code> device. <code>SPI</code> is simply a way to send data from device to device in a serial fashion (bit by bit). <code>SPI</code> provides good support for communication with peripheral devices that are accessed intermittently. This protocol is used for things like SD memory cards, MP3 decoders, memory devices, and other high speed applications.
+
The <code>indexed_atod_test</code> C example project demonstrates how to use a 12 bit A/D converter chip (mcp3208) with SPI Serial Interface. <code>SPI</code> is simply a way to send data from device to device in a serial fashion (bit by bit). <code>SPI</code> provides good support for communication with peripheral devices that are accessed intermittently.
 
 
<code>SPI</code> can operate at extremely high speeds (million of bytes per second), which may be too fast for some devices. It can also achieve significantly higher data rates than <code>I²C</code> devices or SMBus. <code>SPI</code> is better suited than <code>I²C</code> for applications that are naturally thought of as data streams (as opposed to reading and writing addressed locations in a slave device).
 

Latest revision as of 14:22, 30 November 2022

TODO: {{#todo:Buggy (2.21.14-17:40->BS+);(2.24.14-13:00->MD-)(2.28.14-17:48->BS+)(03.10.14-13:30->MD-)(08.27.14-16:55->BS+)(09.09.14-17:20->MD-)(09.10.14-17:00->BS+)(09.13.14-21:40->MD+) |Brian Serrano|oe 4,md,Complete,bs}}

This is a guide to the spi_test example project included in the EMAC OE SDK.

The SPI protocol works in a master/slave setup. The master is responsible for sending the clock pulses. At each clock pulse, data will be sent and received. The rising or the falling clock edge will be used to synchronize the transfer depending on the CPOL setting.

SPI devices have a slave select pin. Every device will share the MISO (Master Input Slave Output), MOSI (Master Output Slave Input), and Clock pins, but each device will have its own slave select pin (also know as chip select). The slave select pin is used to set one device to be active on the bus while deactivating the rest. Theoretically, this means a virtually unlimited number of devices can be used on the same SPI bus; in practice, the number is limited by a number of factors, such as required transaction rates, mechanisms (GPIO pins, bus expanders, etc) available for selecting specific devices, and physical routing constraints. The slave select pin can be active high or active low depending on the device.

The SPI protocol defines four signal lines, but only requires three to operate properly. The fourth line is only required if you have more than one device on the SPI bus; otherwise, you can hard-wire the chip select pin of the only device on the SPI bus so that it is always selected.

This procedure provides an overview of how to compile and run the spi_test C example project. This is an example test interface for sending a transaction to an EMAC SPI device interface. It is only relevant if the EMAC SPI device interface is enabled for an external SPI device that is connected to the bus. It assumes familiarity with the C programming language and is intended to be used by experienced programmers who are looking to learn the EMAC SDK.

For more information about the SPI protocol, see the following page: http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus

The spi_test project builds one executable: spi_test.

Opening, Building and Uploading the Project Files

For information on opening the project from within Eclipse, please see Importing the EMAC OE SDK Projects with Eclipse. Then, follow Using the EMAC OE SDK Projects with Eclipse for information on how to build, upload and execute the example.

Alternatively, the Makefile can be used with the make command from the commandline to build and upload the example. For information on this method, please see Using EMAC OE SDK Example Projects.

EMAC SDK 5.X

For information on opening the project from within QtCreator, please see QtCreator: Adding Source Files. Then, follow Getting Started With Qt Creator for information on how to build, upload and execute the example.

Alternatively, the CMakefile.txt can be used with the cmake command from the commandline to build and upload the example. For information on this method, please see Getting Started with the EMAC OE SDK.

Code can be found at http://git.emacinc.com/OE/example-projects

Usage and Behavior

Hardware Requirements

The spi_test C example project will run on any EMAC carrier board which has an SPI interface (see also the EMAC SPI Programming page).

Using indexed_atod_test

The indexed_atod_test program is executed from the console. It takes two parameters.

root@emac-oe~:$ ./indexed_atod_test device channel
  • device: Name of the indexed_atod device node.
  • channel: Number of indexed_atod channels to be displayed.
A potentiometer circuit.
Figure 1: Potentiometer Circuit
HDR8 Analog I/O
Figure 2: HDR8 ANALOG I/O

This example command was run on an EMAC SoM-150ES carrier board with a SoM-9G20M. This test uses a potentiometer for input to the A/D. You will be communicating with the mcp3208 chip, which is an 8-channel 12-bit A/D converter with SPI Serial Interface. Figure 1 provides a potentiometer test circuit for help on connection to the SoM-150ES carrier board. A circuit like this is recommended for familiarizing oneself with the A/D code before connecting the actual device to be measured by the A/D.

Before running the command in the terminal, you will need to connect the potentiometer to the carrier board as diagrammed. Figure 2 shows where to connect the potentiometer on Header 8 of the SoM-150ES. You will be focusing on CARR_ANL_1 for this example.

Turn the potentiometer counter-clockwise as far as it goes. You'll see the results when you run the command below. Test results will be displayed in the terminal.

root@emac-oe~:$ ./indexed_atod_test /dev/mcp3208-gpio 4
[0] = 83
[1] = 4094
[2] = 61
[3] = 267

The results that are displayed from the terminal show channel 1 analog value at 4094. All the other results are just noise coming from the mcp3208 chip. This noise can be virtually eliminated by grounding the unused A/D inputs.

For the second example, turn the potentiometer clockwise as far as it goes. You'll see how channel 1 results will change when running the command below. Test results will be displayed in the terminal.

root@emac-oe~:$ ./indexed_atod_test /dev/mcp3208-gpio 4
[0] = 62
[1] = 0
[2] = 10
[3] = 95

Here, the results show channel 1 analog value at zero. Your results may vary, depending on the characteristics of your potentiometer and the ADC noise present. You can alter the value by turning the potentiometer to different positions.

HDR8 Analog I/O
Figure 3: HDR8 ANALOG I/O


Before doing example 3, you'll want to put the wiper (B) wire on pin 9 of the SoM-150ES carrier board. Figure 3 shows that pin 9 is CARR_ANL_6. Turn the potentiometer counter-clockwise about half way. You will see how the values on channel 6 will change when running the command below. Test results will be displayed in the terminal.

root@emac-oe~:$ ./indexed_atod_test /dev/mcp3208-gpio 7
[0] = 53
[1] = 0
[2] = 56
[3] = 0
[4] = 29
[5] = 43
[6] = 2044

The results show the channel 6 analog value at 2044, which is about half way (4095/2). You can change any of the channels value with the potentiometer as long as you put the wiper pin on the channel you want to change.

Due to ADC noise, you may see the values fluctuate slightly from one run to the next. This is normal behavior. This fluctuation can be more severe with some potentiometers than it is with others; some potentiometers are more prone to picking up noise. The noise will also be more severe with longer wires, due to transmission line effects. Eliminating noise is typically the greatest challenge in high resolution A/D conversion (especially at 18 bit and above), so you should expect to see some noise when performing an informal test such as this.


Updates for iPac9x25

In order to run these examples on the board, either follow the schematic from figure 4 or use part MIKROE-304.

Figure 4: Schematic used to set up spi test for iPac9x25


Summary

The indexed_atod_test C example project demonstrates how to use a 12 bit A/D converter chip (mcp3208) with SPI Serial Interface. SPI is simply a way to send data from device to device in a serial fashion (bit by bit). SPI provides good support for communication with peripheral devices that are accessed intermittently.