8451 I2C Loop Running Slowly When Reading Data

[MarcoMauri]

---

2) Os Limitations:

Running a loop over the kHz rate in Windows is impossible.

Regards,

Marco

---

ehm... in the rush I've been quite inaccurate 😉

You can run faster than that of course, but the rate is not garanteed.

See here:

http://forums.ni.com/t5/LabVIEW/Looping-Time-Less-Than-1-ms/td-p/323567

[lgbav8r]

After being at this for a few days, I suspect Mario may be on to something with the 5kHz data rates only being available over SPI.  So I have tried to hook up the accelerometor using SPI (4 wire mode) rather than I2C.  However, I can't get any data transfer between labview and the accel.

• clock polarity idling high
• clock phase set to second edge
• supplied voltage of 3.3V for both Vdd and Vdd_IO
• SDI on USB-8451 connected to SDO on chip
• SDO on USB-8451 connected to SDI on chip
• The 16 bit read command sent to SDI is 10001111 10001111.  The first bit to indicate reading, the second bit to auto increment registers which is not needed since I’m only interested in the one register and 001111 to address the 0x0F register address.  The 2^nd byte is just dummy data and has no affect (since I'm only reading)

I should see a return of 0x33 but not seeing anything come back either in labview or using the oscilloscope.  The CS, SCL, and SDO lines all appear to be working per the data sheet (viewed all 4 lines using an oscilliscope).

I've read, re-read, and re-re-read the data sheet and can't find anything that I am doing wrong.  I have also tried the SPI interface on 2 different accels. to ensure it wasn't a faulty accel (both work no problem with I2C).  I suspect I still have something messed up but can't figure it out for the life of me.

I have built a simple VI based off the SPI General Read example VI and it is attached.  I am also running the latest package for the USB-8451.

Can anyone shed any light on this?

[lgbav8r]

Here is the attachment

[Nick-C]

lgbav8r,

There doesn't appear to be anything in your code that jumps out as incorrect. All other lines functioning properly, but no data being returned would tend to indicate to me that there might be a problem with the read command. However, it sounds like you have checked this several times. What is the address at which you expect to read data? When you scope the lines, do you see no change at all after issuing the command, or are you reading back junk data?

-Nick-

[lgbav8r]

Nick,

I am trying to read address 0x0F which should be returning 0x33.  I am sending the byte 10001111 (0x8F).  The first bit is 1 to indicate reading the address, the second bit is zero since I don't need multiple byte reading, and bits 3-8 are the 6-bit address.  Attached are the oscope pictures.  The MOSI line looks correct based on the data sheet.  The MISO line looks very strange.  As an asside, I have tried this on two different accelerometers with the same results.

[Nick-C]

It seems like everywhere else in the documentation for that sensor, bit 0 (which is the read bit) is the least significant bit of the byte you are writing. 

Can we try writing 00111101 or 0x3D? This would put the read bit as the least significant bit (or bit 0) and put the address as bits 2:7.

-Nick- 

[lgbav8r]

Nick,

Trying to address 0x3D does not return anything on the MISO line.  I'm not sure how you determined the read bit being the LSb.  From what I can tell on page 21 of the data sheet, the read bit is the MSb or the first bit being passed in. 

"The first bit (bit 0) starts at the first falling edge of SPC after the falling edge of CS while the last bit (bit 15, bit 23, ...) starts at the last falling edge of SPC just before the rising edge of CS."

It also says the data being read and written are all MSb first.  For giggles, I also tried addressing with 10111100 and 11110001 and got nothing.

[Nick-C]

I don't think we are on the same page. Page 21 of the data sheet you attached shows Table 12 which indicates to me that the read bit is the the least significant bit of these bytes. This is confirmed by examining the Hex value listed in the last column of the table

I read in the data sheet that data is returned MSB first, but I was unable to find where the Read bit was referred to as the MSB. Can you point out where this is listed?

-Nick-

[Nick-C]

On page 23 under section 6.2.1, the read bit for SPI is listed as Bit 0. To me, this indicates LSB. Are we sure that the byte written isn't LSB first?

-Nick-

[lgbav8r]

Hmmmm.  I see the reasoning behind the read bit being the LSb.  In section 6.2, DI(7:0) and DO(7:0) are described as data being written or read MSb first.  Looking at figure 6, the higher index is what is shown first in the signal trace.  That is why I thought MSb was first and why the read bit is the MSb for the first byte.

Regardless of that, I was trying to send the signal to the accelerometer in the same way figure 6 describes.  So the first bit sent is the read/write bit followed by the MS bit and then the address which if I follow the logic from above, is MSb first.  So I would the address registering byte would be 10001111 (0x8F) to read address 0x0F.  These were the charts shown in my previous post (MOSI and MISO charts).

I also tried the following read commands with these responses

• 10111100 to send the entire byte LSb first (with read bit as LSb) and recieved 0x00
• 00111101 to send byte MSb first with the r/w bit as the LSb and recieved no response on the MISO line.  I think this is because the first byte sent is 0 which indicates write and therefore nothing is recieved on the MISO line.
• 11110001 to send address with LSb of address first and then the read bit and recieved 0x00.  Although I think this means read while incrementing the address starting at 0x31.

Am I just not understanding the data sheet correctly?