LINX I2C PmodAD2 WRITE/READ ERROR

[TCA2]

Hi,

I recently purchased one of the LabVIEW Home Computing Kits with the Beagle Bone Black along with a PmodDA2 (I2C interface) and a PmodDA1 (SPI interface) from Digilent.   My goal is to make low cost, LabVIEW based controller for an EV that I have built.  I was able to get the BLINK VI to work without any issue once I realized what Debian Image would work with LINX.  (As mentioned on this forum  8.6 is the latest).  I am currently running 8.4 on my BBB but I cannot seem to get the LINX I2C interface to work.  The code required for the PmodDA1 appears straight forward compared to other, more complex I2C Pmods.  I have attached a screen shot of the LINX I2C Write error I keep getting.  I get a similar error if I try to perform a read.  I know that channel 2 is the only I2C channel available on the  BBB according to a LINX pinout for the BBB I found on the LabVIEW MakerHub site, so the only issue I can think of is that I am just not sending the 17 bit slave address (0101000b) correctly.   Any assistance would be greatly appreciated.     

[JColvin]

Hi @TCA2,

Do you perhaps mean the Pmod AD2 rather than the Pmod DA2? The Pmod DA2 uses a somewhat SPI based communication (with two MOSI's rather than a MOSI and MISO), but the Pmod AD2 does use I2C.

The address you are sending does appear to be correct. What I'm a little confused about though is why you have a write VI setting the already existing default values to the configuration register (it's okay to do, just not needed) and then only a single read VI. As per page 21 with more detail on page 24 of the AD7991 datasheet, two reads are needed where the first 2 bits are 0's, followed by two bits of the channel ID, finally followed by 12 bits of data. My LabVIEW skills are a bit rusty, but it looks like you only read the first 8 bits which gets you the first 4 MSBs of channel 0, issue a restart, and then close the I2C communication.

To get all 4 channels worth, you'll probably want to call the read VI 8 times either by putting the block 8 times or doing a for loop 7 times with what you have (I presume a restart no stop is needed as the master ACK? I haven't readily found documentation on it, so maybe just "no stop" will work) followed by a final 8th time with a stop.

Let me know if you have any questions about this.

Thanks,
JColvin

[TCA2]

I do mean Pmod AD2.  I purchased a Pmod AD2 so that I can read a higher voltage range than the 1.8 volts of the BBB's onboard analog inputs .   I am using the I2C Write VI so that I can configure the AD7991 per page 20 of the datasheet.  I understand it is not needed to get the Pmod AD2 to work, as the default is the reading of all four of the AD7991 channels, but I was not sure if D3 (in Table 10) needed to be set (in addition to the jumper on the board) in order to define the reference voltage.  

The I2C Read VI reads bytes (Bytes to Read),  not bits, so I don't believe that I should have to perform a read 8 times.   Once I establish communication to the board, the rest will be on the LabVIEW side.

Again, I believe the issue is with the specific I2C addressing with this particular Pmod/AD7991.   See Page 23 of the AD7991.   I interpret this to mean that a R/W bit must be included in the end of the address in order to "write to" or "read from" the AD7991.   The Pmod documentation states: "Unlike other devices that use I²C, no addresses are associated with these two registers; only the read/write bit at the end of the slave address distinguishes between the two registers."  However, drilling down in both  I2C Write and Read VIs I quickly reach a function call and therefore cannot tell what the code is doing at that point. 

Either I am just missing a key detail or there must be a way to "trick" the I2C Write and Read VIs to work with this Pmod.

 The only mention of using the Pmod AD2  with LINX and BBB I found was on BeagleBoard.org (https://beagleboard.org/p/ella-rickerson/beaglebone-black-minisumo-bot-pt-2-8a55b6).  But of course, when I downloaded the sample code, I see that the two VIs I believe I need were not included. There is another reference to using I2C with LabVIEW (LINX) on the Instructables web site (https://www.instructables.com/id/How-to-use-I2C-in-LabVIEW/).   But no example for the Pmod AD2 was given.   However, the author (Sudharsan Sukumar) worked for Digilent at the time.  Is he still with Digilent? Maybe he can assist.

BTW, some background on me:  I have been programming with LabVIEW since LabVIEW 3.0 and have done many LabVIEW, LabVIEW RT, and LabVIEW FPGA projects over the years as a NI Alliance Member.   But the NI hardware has always been kind of pricey for home use/little projects.  So I was kind of excited when NI created LINX/MakerHub and Digilent (2014-2016 time frame). However, it just seemed to die after that .  So there just seems that a little more support/documentation is needed for us LabVIEW users.  For this reason, I plan on uploading all of my projects with the BBB and LINX (and the Pmods) to this and the LabVIEW MakerHub site as I develop them so that other LabVIEW users that purchased one of your Home Computing Kits can have additional support.  Time to give back I guess.

Regards,

TCA2 

[JColvin]

Hi @TCA2,

I don't have any I2C Pmods with me right now since I am working from home, but I will get one from my desk (hopefully both the Pmod AD2 and the Pmod TMP3 which has a built-in example) to see if I can get it to work; I don't have a BBB though, so if there is any hardware particulars with it, I'll be of limited help in that regard. Dharsan left Digilent a number of years ago (back in 2016 if I recall correctly), so he is not available unfortunately. Much of the LabVIEW work that Digilent had been doing was superseded by other tasks as dictated by the powers-that-be, and as you have noticed has not returned.

I do suspect that you are correct in that the 7-bit address probably needs to be adjusted to an 8-address with a 1 as the LSB for Read and a 0 for Write. I do not know if that is the case though since I encounter the same thing you do where you eventually get to a Call Library Function Node and as far as I can tell it just straight passes the I2C address; I can't tell where it ever might add in the read bit, which I am a little surprised at, but I know I have seen the base TMP3 demo working, so I would like to think that is in there somewhere.

I'll let you know what I find out.

Thanks,
JColvin