« Close

Datasheets and User Guides

App Notes

Software & Driver

 

5.2.15 - SPI

Requires U3 hardware version 1.21. Sends and receives serial data using SPI synchronous communication.

Table 5.2.15-1. SPI Command Response

Command:    
Byte    
0 Checksum8  
1 0xF8  
2 4 + NumSPIWords  
3 0×3A  
4 Checksum16 (LSB)  
5 Checksum16 (MSB)  
6 SPIOptions  
    Bit 7: AutoCS
    Bit 6: DisableDirConfig
    Bits 1-0: SPIMode (0=A, 1=B, 2=C, 3=D)
7 SPIClockFactor  
8 Reserved  
9 CSPinNum  
10 CLKPinNum  
11 MISOPinNum  
12 MOSIPinNum  
13 NumSPIBytesToTransfer  
14 SPIByte0  
 
     
Response:    
Byte    
0 Checksum8  
1 0xF8  
2 1 + NumSPIWords  
3 0×3A  
4 Checksum16 (LSB)  
5 Checksum16 (MSB)  
6 Errorcode  
7 NumSPIBytesTransferred  
8 SPIByte0  
 
  • NumSPIWords: This is the number of SPI bytes divided by 2. If the number of SPI bytes is odd, round up and add an extra zero to the packet.
  • SPIOptions: If AutoCS is true, the CS line is automatically driven low during the SPI communication and brought back high when done. If DisableDirConfig is true, this function does not set the direction of the lines, whereas if it is false the lines are configured as CS=output, CLK=output, MISO=input, and MOSI=output. SPIMode specifies the standard SPI mode as discussed below.
  • SPIClockFactor: Sets the frequency of the SPI clock. A zero corresponds to the maximum speed of about 80kHz and 255 the minimum speed of about 5.5kHz.
  • CS/CLK/MISO/MOSI -PinNum: Assigns which digital I/O line is used for each SPI line. Value passed is 0-19 corresponding to the normal digital I/O numbers as specified in Section 2.8.
  • NumSPIBytesToTransfer: Specifies how many SPI bytes will be transferred (1-50).

The initial state of SCK is set properly (CPOL), by this function, before CS (chip select) is brought low (final state is also set properly before CS is brought high again). If CS is being handled manually, outside of this function, care must be taken to make sure SCK is initially set to CPOL before asserting CS.

All standard SPI modes supported (A, B, C, and D).

Mode A: CPOL=0, CPHA=0
Mode B: CPOL=0, CPHA=1
Mode C: CPOL=1, CPHA=0
Mode D: CPOL=1, CPHA=1

If Clock Phase (CPHA) is 1, data is valid on the edge going to CPOL. If CPHA is 0, data is valid on the edge going away from CPOL. Clock Polarity (CPOL) determines the idle state of SCK.

Up to 50 bytes can be written/read. Communication is full duplex so 1 byte is read at the same time each byte is written.

18 comments

What would an example of using this function look like? I am pretty new to programming still and do not understand how to make a list of bytes correctly, and I am not exactly what value should be entered for each byte, such as Checksum16.

What OS and language are you using?  What chip do you want to talk to?

 

I am using the Fedora OS and Python. I want to talk to the FIO4 port in order to toggle it on and off using the SPI protocol.

Make sure you have LabJackPython installed and working.

To use the SPI function specifically, you can use code like this example:

import u3
d = u3.U3()

# A list of bytes to write using SPI
SPIBytes = [0x12, 0x34, 0x45, 0x67]

# Call the SPI Functions. Shown with all arguments:
d.spi(SPIBytes, AutoCS=True, DisableDirConfig = False, SPIMode = 'A',
      SPIClockFactor = 0, CSPINNum = 4, 
      CLKPinNum = 5, MISOPinNum = 6, MOSIPinNum = 7)

Feel free to contact us directly if you need more help.

Thank you very much! This give me a good place to start.

Hi,

It says:
Mode A: CPHA=0, CPOL=0
Mode B: CPHA=0, CPOL=1
Mode C: CPHA=1, CPOL=0
Mode D: CPHA=1, CPOL=1

But in 4.3.10 it says:
 

//Mode A:  CPHA=1, CPOL=1.

 

Wich one is correct?

And... does a zero (0) means mode 'A', a one (1) mode 'B', a two (2) mode 'C', and a three (3) mode 'D'? Because I need to use CPHA=0 and CPOL=1, and I don't know what value to send:
 

AddRequest(lngHandle, LJ_ioPUT_CONFIG, LJ_chSPI_MODE,?????,0,0);

 

Thanks!

PD: I'm using LabVIEW. I'm actually modifying an example you provided.

Hi All,

I am trying send my sensor's data through SPI ports to U3 Lab jack Serial to USB port and see the data on hyper terminal.

Is there any reference code or help on such topic? I am quite new to Lab jack :)

I am using sensor as shown on the link below

http://www.analog.com/en/mems-sensors/low-g-accelerometers/adis16210/products/product.html

I there any guide to learn the syntax of programming in Lab jack?

 

regards,

Syed

I think you are going to need a PC application that will interpret data from the sensor, then put together a UART packet that will send the desired text. If possible, it would be easier to simply display the data in the main application.

 

The easiest way to become familiar with programming for LabJack devices is to look at our examples here: http://labjack.com/support/ud/examples If you prefer reading section 4 of the user's guide is a good place to start.

Hello Support,

I want to get data from my accelorometer sensor ADIS16210 http://www.analog.com/en/mems-sensors/low-g-accelerometers/adis16210/products/product.html and display it on my serial port or com port hyperterminal window initially.

Secondly this sensor required clock rate of 830Khz, is LabJack able to operate at this clock rate, Please have a look at the data sheet and advice me how to proceed with my task

thanks

The LabJack's maximum SPI clock speed is about 120kHz. From page 4 of the datasheet it looks like ADIS16210 will work between 10 and 830 kHz. So, the LabJacks clock speed should be fine.

Hello,

Thanks for prompt response, yes I think clock should be fine. Do you have any example code to retreive data from sensor's registers through SPI ports? It would be of great help.I am planning to use DAQFactroyExpress for programming and retreiving the data. Do you have any better suggestion to get it done more easily and efficiently.

Secondly I read the pseudo code for SPI in the user guide also, which language is that? is it LabJack's own syntax?

Regards,

Syed

We do have an SPI example for DAQFactory. You can download it here.

 

The pseudo code looks to be C, but then it is pseudo.

Hello,

Thanks for replying back. I have tried this example, it is very generic and doesn't make use of CS or CLK pin however for interfacing with sensor you need to use all four pins. So I was looking for a sample SPI code for getting data from the sensor and display it on the serial port. Please let me know if you have such sample available. I am using ADIS16210 Accelerometer Sensor.

http://www.analog.com/en/mems-sensors/low-g-accelerometers/adis16210/products/product.html

Thanks a lot for your support!

Regards,

Syed

Check out the SPI sequence in SPI.ctl. In there is sets up the CLK, and CS lines.

Yeah I ran that program (SPI.ctl) but I meant to say that this sample code is not quite conclusive for SPI communication establishment, even if I don't connect the clock pin or CS pin to any pin on the other device, this program works. I connected MOSI to MISO so I can see the data send through as if its coming in. I want to establish communication between two chips through SPI, my sensor & LabJack and for that I was looking for a suitable reference code if its available.

Thanks!

Hi Syed,

Let's move this conversation to the forums. That way we can get support staff assigned to it.

Hi,

I currently own a 3U and have the need to communicate with an SPI device that excepts 12-bit words. The 6U documentation describes a method for doing so via byte 8 (bits 0:2). However, this function is NOT listed for the 3U and instead, byte 8 is listed as "Reserved".

Does the 3U support the same function as th 6U in this manner? And if not, is there any way that I can transmit to an SPI device that supports only 12-bit words?

 

No, the U3 does not support the partial byte feature.

Most SPI devices will ignore extra bits. Usually the most recent bits received will be used. So if you write 16-bits the first 4 are ignored.  When reading 16-bits the last 4 will be junk data. It's rare for hardware to be able to do partial byte transactions, so it is necessary to ignore extra bits if a part is going to be compatible with modern ICs. We have used a lot of analog's parts and have never encountered a situation where 8-bit transactions couldn't work.