i2c with 18X to LM4970

E

elo31271

New Member
Hi all, this is my first post. I have been on the forums for some time now and usually find my answers in others posts. But not this time… I have been searching the net, here, and it appears the i2c tutorial is not what I need. This is my first i2c project.

I am trying to use an 18x to initialize a LM4970 (www.national.com/pf/LM/LM4970.html) with i2c.
I am using the Sparkfun’s breakout board
(http://www.sparkfun.com/datasheets/BreakoutBoards/LM4970-Breakout-Datasheet.pdf). Yes I am a RGB LED freak, love the 08M and the RGB LED.

I believe the I have the device properly hooked up to the 18x with 4k7 pullups (national reconmends 10k ???). I have the LM4970 ADJ pin low =0, I believe this what I need to do...
Sparkfun says they use this to “Start 0xF4 0x04 0x50 0x60 0xBF 0xF2 Stop” to test. These Hex numbers agree with the National data sheet BCD numbers for what I want to do, use the audio sync function of the LM4970.

According to the National’s data sheet F4 is the address and the rest is the data.
Here is couple of many variants I tried:

i2cslave $F4, i2cfast, i2cbyte
writei2c $F4, ($04, $50, $60, $BF, $F2)

Or

i2cslave %11110100, i2cfast, i2cbyte
writei2c 0, ($F4 $04 $50 $60 $BF $F2)

I think my issue is to do with F4 as Sparkfun says is the write command. The National data sheet says the F4 or 11110100 is the address.

Am I way off or can some one shed some light on silly mistake I am making?

Thank you,
Eric
 
Y

ylp88

Senior Member
Alike what Hippy mentions HERE, this is probably one of those devices which the PICAXE doesn't like to run i2c with because the PICAXE expects to send a control byte, address then data, whereas the device you are trying to use expects a control byte then data (page 7 of the datasheet).

I'm not sure if someone's figured out if it is possible to overcome the i2c limitation with the PICAXE. Short of that (or bit-banging):

i2cslave %11110100, i2cfast, i2cbyte
writei2c $F4, ($04, $50, $60, $BF, $F2)

...is probably the closest you can get with the hope that the chip might choose the first byte after the control byte (what the PICAXE intends to be the register address) to by a data byte. That said, I'm a bit fuzzy on the exact i2c signalling so perhaps the PICAXE might throw in an extra of miss an ACK (etc...) which will mess things up.

ylp88
 
W

westaust55

Moderator
Your understanding of the ADR pin and i2c Address at $F4 is correct.
From a quick reading of the datasheet, there are 5 registers, I suggest that you try:

i2cslave %11110100, i2cfast, i2cbyte ; this sets the address as $F4
writei2c ($04 $50 $60 $BF $F2) ; this loads the 5 bytes of data
 
Last edited:
Technical

Technical

Technical Support
Staff member
Hippys page is out of date, the information on his page is not true on current firmware as you can omit the address byte (not needed here). Try

i2cslave %11110100, i2cfast, i2cbyte
writei2c ($04, $50, $60, $BF, $F2)

Note you don't duplicate the slave address ($F4) in the actual read/write command as the PICAXE adds it automatically.

In this particular case you could actually also use this, which is functionally equivalent.

i2cslave %11110100, i2cfast, i2cbyte
writei2c $04, ($50, $60, $BF, $F2)
 
W

westaust55

Moderator
At the possibility of incurring wrath . . .

would not:

writei2c $04, ($50, $60, $BF, $F2)

try to start loading the data at the 4th register?

WRITEI2C location,(variable,variable...)

could in theory leave out the location per your first example
 
Last edited:
Technical

Technical

Technical Support
Staff member
Nope, this chip doesn't use address registers , so $04 is just another data byte as far as it is concerned.

When a chip uses address registers (e.g. EEPROM), the first byte sent is interpreted as the register address. However if the chip doesn't uses addresses to start with the first byte is just pure data.

i2cslave %11110100, i2cfast, i2cbyte
writei2c $04, ($50, $60, $BF, $F2)

and

i2cslave %11110100, i2cfast, i2cbyte
writei2c ($04, $50, $60, $BF, $F2)

both appear on the i2c bus as

Start $F4 $04 $50 $60 $BF $F2 Stop

How the $04 byte is actually used is purely up to the chip!
 
Last edited:
E

elo31271

New Member
Thank you all for the replies!!!

Well I worked on project for about an hour and used this suggestion:

i2cslave %11110100, i2cfast, i2cbyte
writei2c ($04, $50, $60, $BF, $F2)

But I can not confirm that is working...

So I went back and re-examined my wires for errors. I feel good that I am hooked up right.

Useing my trusty meter I checked SDA is held high but SCL is not, should it be high with the pullup in place?
I checked that I am getting and average of 2v or so of signal on the LM's audio IN and about 1v or so pulsing from the LED OUTs. Barely visable pulsing LED...
I am using around 4v for VDD on the 18X and the LM4970.

SO what is voltage is the i2c VDD supose to be? I assume the same VDD I am using on every thing else.

Also how can one check for the 18X is establishing i2c? I do not have a scope.

Again a big thank you to all who replied!

Nickleflipper, after a brief scan of the PCA9635 datasheet, I actual think it is a little clearer on how to use it as opposed to the LM9470... I gonna have to study it closer!

Eric
 
W

westaust55

Moderator
When there is no i2c bus comms in progress, both SDA and SCL should be high.
You should check your circuit with no i2c comms in progress and look for a possible wiring error.

With respect to Vdd, the LM4970 datasheet gives electrical ratings for LED current etc at both 5Vdc and 3Vdc so would suggest that Vdd as low as 3V is acceptable. Therefore operation with Vdd at 4Vdc would not be the cause of problems.

Max audio input voltage is Vdd, so if your audio signal is 2V then should be functioning. You do indicate the LEDs are illuminating slightly. Presume the 2V input signal is audio and depending on your meter may be rms or average.

Can you post your program code and possibly a photo of the actual circuit, People have spotted errors in a photo before today.
 
Y

ylp88

Senior Member
You might consider testing the system without an audio input, rather using the i2c interface to control which LEDs are on. This will narrow down the error to either the i2c interface or to the audio input systems.

On the note of audio input, I don't have time to look at the datasheet again, but one of the last couple of bytes referred to a sensitivity/gain level which you might need to adjust according to your signal levels.

ylp88
 
You must log in or register to reply here.
Top