I am so totally banging my head against the wall on this. I've learned quite a bit (I think) from the comments thus far, I think I get the jist of what is supposed to be happening here..... but its not happening that way.
Running the scanner produces the following ( I used a similar script when I was getting started, thats how I was able to get the device address to begin with...... I have no idea why 3 devices are showing up, this is a single device).
I2C scanner. Scanning ...
Found address: 16 (0x10)
Found address: 17 (0x11)
Found address: 96 (0x60)
Done.
Found 3 device(s).
As far as the while loop goes - I haven't noticed anything 'breaking' regardless of how that was set, so I haven't really focused there yet.
I also added in the error handling stuff - I'm not getting errors either way, so I believe that we're getting a return of 0 indicating success, and I also believe we're getting 2 bytes back, as we should.
Something you said earlier has me a bit confused
After staring at it for a while I think they are saying that the device address is in fact the register. So, for example, say we want to set some bits in register 2:
Yes there are multiple registers. of Primary interest to me is Register 2, 3,4,5,10, and 11. But I believe it's using a standard i2c style address (we see 3 devices in a bus scan).
When I try 16 (0x10) I get 00000001 00111111. I get the same result after a 'set'
When I try 17 (0x11) I get 11111111 11111111. I get the same result after a 'set'.
This is what clued me in initially that I should use the third address.
So I've clearly picked an oddball piece of hardware, ehh? lol
What I wish I could do is really 'see' the bitstream as I run the routine. See what crosses the bus, and see what comes back. I guess I just don't trust it until I prove it. But that's just me ranting about not believing what I'm seeing
I would be tempted to do a "read" of all possible 256 registers. After all that shouldn't hurt them, and you would find which ones seem to have reasonable data in them.
When in write transfer, data bytes is written out from MCU, and when in read transfer, data bytes is read out from RDA5807SS. There is no visible register address in I2C interface transfers.
For read transfer,
after command byte from MCU, RDA5807SS sends out the first register high byte, then the first register low byte, then the second register high byte, till receives NACK from MCU. MCU gives out ACK for data bytes besides last data byte. MCU gives out NACK for last data byte, and then RDA5807SS will return the bus to MCU, and MCU will give out STOP condition. The RDA5807SS supported two type I2C interface:RDA5807SS Mode and TEA5767 Mode. The different register defined in different interface Mode. Details refer to RDA5807SS Programming Guide.
I see what you're referencing.... but I'm not sure I understand how to implement it. How does it know what register I'm trying to write to if I don't specify the address?
When reading use an address byte. When writing do not use an address byte.
The following snip-it works:
'========================[Write/Read data to/from FM module ]=====================
Write_ConfigRegs: ' Write Data to Configure Registers
I2COUT SDA, WrFM, [Conf2.Highbyte, Conf2.Lowbyte, Conf3.Highbyte, Conf3.Lowbyte, Conf4.Highbyte, Conf4.Lowbyte, Conf5.Highbyte, Conf5.Lowbyte, Conf6.Highbyte, Conf6.Lowbyte]
RETURN
Read_Status:
I2CIN SDA, RdFM, 0, [Status1,Status2,status3,status4]
DEBUG CRSRXY,10,1,"Status : ", HEX2 status1, " ", HEX2 status2, " ", HEX2 status3, " ", HEX2 status4, " "
RETURN
'================================================= =========================