Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

Labjack U3 and MAX7300 I/O Extender


  • Please log in to reply
7 replies to this topic

#1 darkhawk

darkhawk
  • Members
  • 5 posts

Posted 17 April 2013 - 05:08 AM

I have a Labjack U3 and a MAX7300 I/O Extender. I'm actually looking to use 16 of these I/O Extenders, all with different addresses, but for now I'm just getting the code working with a SINGLE MAX7300. Let me preface this by saying I'm using Labview to control the Labjack, and using the functions provided here for I2C communication via the Labjack. They have been modified slightly (to accomodate different message lengths, and to be able to address different MAX7300's when called), but still output the data correctly when probed with an oscilloscope. The problem I'm running into is that I don't seem to be communicating properly to the MAX7300. I know that the data I'm sending is getting there, as I get the ACK's when I send the data, but I can't seem to actually get the chip to function as I would expect. I first set it up by configuring it for Input with Internal pullup's. This is done by first sending [hex bits] [0x9] [0xFF]. I then attempt to read this data back, and I get bad data back (basically, just garbage). I'm an electrical engineer with quite a bit of experience with Labview and digital design, but this has me baffled. The datasheet for the MAX7300 does not help the situation either.

#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 17 April 2013 - 08:31 AM

Have you tried adding 4.7k pull-ups from SDA to VS and SCL to VS? If you are powering the MAX7300 from VS, a guaranteed logic high input is 0.7*5 = 3.5V, so the U3's internal pull-ups to 3.3V might not be doing the job.

Strange, though, that you are seeing the ACK as that suggests that the chip likes the first byte and thinks the address is right.

Note that we and customers have had good luck with the MCP23S17 SPI port expander IC:

http://ww1.microchip...eDoc/21952b.pdf

#3 darkhawk

darkhawk
  • Members
  • 5 posts

Posted 17 April 2013 - 09:26 AM

Have you tried adding 4.7k pull-ups from SDA to VS and SCL to VS? If you are powering the MAX7300 from VS, a guaranteed logic high input is 0.7*5 = 3.5V, so the U3's internal pull-ups to 3.3V might not be doing the job.

Strange, though, that you are seeing the ACK as that suggests that the chip likes the first byte and thinks the address is right.

Note that we and customers have had good luck with the MCP23S17 SPI port expander IC:

http://ww1.microchip...eDoc/21952b.pdf


I do in fact have 2 x 4.7k ohm resistors pulling from the SCL and SDA to +VS on the labjack, as well as a 10 uF cap from GND to +VS on the small adapter board.

I'll have to get some plots and include the labview code tomorrow when I have access to it all again.

I'm thinking I'm just not setting something correctly, which really wouldn't surprise me.

This particular one is set with both address lines going to GND, which would make it address 0, and due to everything else, the byte needs to be set to 0x80.

Anyway, more to come.

Thanks!

#4 darkhawk

darkhawk
  • Members
  • 5 posts

Posted 18 April 2013 - 04:58 AM

Ok. Both AD0 and AD1 are tied to ground, this gives it a slave address of 0x80 (1000 0000) for the first byte of data sent. I want to configure the device to have all ports be GPIO Input with Pullup's, so I start with 0x0B (ports 12-15, because the MAX7300 only has ports 12-31 on it) as my command byte register. Since I want to configure them to be GPIO Input with Pullups, my data byte is 0xFF (1111 1111). This means I first set the VI to send a 0x80 byte, then 0x0B byte, and then 0xFF byte. This would setup the first 4 pins (P12-P15) to be GPIO Inputs with Pullups.

Attached Thumbnails

  • tek00004.png
  • tek00005.png

Attached Files



#5 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 18 April 2013 - 08:40 AM

I agree that it looks like the proper data is being sent to the chip.


From a quick look at the datasheet here's my initial checklist:

*Check iSet resistor. Connections, and verify proper resistance (not blown etc.).
*Try reading some registers. After a power cycle is reg 0x0B the startup value of 0xAA.
*Read the Configuration register 0x04. Check bit zero to see if the chip is in shutdown mode.


I would take a quick look at the resistor then read reg 0x04. Hopefully bit zero is clear = shutdown mode. The datasheet says the chip is in shutdown by default, so this likely the problem.


Let us know how it goes.

#6 darkhawk

darkhawk
  • Members
  • 5 posts

Posted 18 April 2013 - 10:07 AM

I agree that it looks like the proper data is being sent to the chip.


From a quick look at the datasheet here's my initial checklist:

*Check iSet resistor. Connections, and verify proper resistance (not blown etc.).
*Try reading some registers. After a power cycle is reg 0x0B the startup value of 0xAA.
*Read the Configuration register 0x04. Check bit zero to see if the chip is in shutdown mode.


I would take a quick look at the resistor then read reg 0x04. Hopefully bit zero is clear = shutdown mode. The datasheet says the chip is in shutdown by default, so this likely the problem.


Let us know how it goes.


The resistors and connections all are good.
reg 0x0B reads a value of 170 (0xAA hex).
reg 0x04 reads a value of 0 (0x00 hex).

I'm still a bit confused. How do I make it so the chip is NOT in shutdown mode? This datasheet from Maxim is really not very good, atleast by my standards of what I'm used to anyway.

Is this just a matter of writing a '0x01' to register 0x04?
How would I then setup all the ports to be an input with pullup? Again, a matter of writing '0xFF' to all the port configurations (0x0B to 0x0F)?

#7 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 18 April 2013 - 11:21 AM

I believe you are correct. Just write a 1 to bit zero (0x01) to bring the chip out of shutdown. If you intend to use the transition detect feature then also set bit seven (0x81). As I understand it, after the chip is out of shutdown mode you can go about controlling the DIO.

#8 darkhawk

darkhawk
  • Members
  • 5 posts

Posted 19 April 2013 - 04:35 AM

Thanks much! I got everything working great now. Now to just finish the rest of the program and hardware..... :lol:


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users