I2c comunication
- Thread starter pmonro
- Start date
BeanieBots
Moderator
Welcome to the forum.
Don't recall anyone here using it.
Posting a link to the datasheet will help people to help you
Don't recall anyone here using it.
Posting a link to the datasheet will help people to help you
I2c Comunications
The Memsic chip is MC2120X from the USA and the DCss503 is with support items on a breakout board from China.
http://www.memsic.com/products/mmc212xm.htm
There is a heap of data on the memsic site but I was trying to see if any one had tried the Picaxe i2c with this chip.
One can also see these items for sale on ebay. Search "magnetic sensor"
The Memsic chip is MC2120X from the USA and the DCss503 is with support items on a breakout board from China.
http://www.memsic.com/products/mmc212xm.htm
There is a heap of data on the memsic site but I was trying to see if any one had tried the Picaxe i2c with this chip.
One can also see these items for sale on ebay. Search "magnetic sensor"
Last edited:
BeanieBots
Moderator
You can hope, but unlikely.
Can't help without a device datasheet. (I'm not going to search for it!).
I2C is normally quite straightforward. Just a question of sending the correct command to the correct register and reading back from the correct address.
All locations will be published in the datasheet including comms speed but if in doubt, using SLOW should work in all instances.
Maybe drop a line to your eBay supplier for help with it.
Can't help without a device datasheet. (I'm not going to search for it!).
I2C is normally quite straightforward. Just a question of sending the correct command to the correct register and reading back from the correct address.
All locations will be published in the datasheet including comms speed but if in doubt, using SLOW should work in all instances.
Maybe drop a line to your eBay supplier for help with it.
kranenborg
Senior Member
Hi pmonro
The device code was incorrect, it must be MMC2120xMG, better be accurate on these things. The i2c protocol description in the associated datasheet is not extremely clear as it lacks any figures, but from the textual description I distilled the following code that may give you a start:
You will have to test yourself, but as I see it the device follows the i2c protocol genuinly. Note that you must check the device address yourself since Memsic provides them with several i2c address options (see datasheet)
Best regards,
Jurjen
PS: Do a refresh on this page if you cannot see the full code, this is an Internet Explorer bug ...
The device code was incorrect, it must be MMC2120xMG, better be accurate on these things. The i2c protocol description in the associated datasheet is not extremely clear as it lacks any figures, but from the textual description I distilled the following code that may give you a start:
Code:
REM >>untested<< code for performing measurement and
REM subsequent reading of MEMSIC MMC2120xMG
#picaxe-28x1
SYMBOL Memsic_address = %01100000
SYMBOL MSB_Xchannel = b0
SYMBOL LSB_Xchannel = b1
SYMBOL MSB_Ychannel = b2
SYMBOL LSB_Ychannel = b3
REM Make the device known
HI2Csetup i2cmaster, Memsic_address, i2cfast, i2cbyte
REM Perform continuous measurements
DO
REM Wake-up call and perform measurement (write 1 to command register 0)
HI2Cout %00000000, (%0000001)
REM Wait 5 ms according to datasheet
PAUSE 5
REM Now read the results (registers 1-4 contain the data)
HI2Cin %00000001, (MSB_Xchannel, LSB_Xchannel, MSB_Ychannel, LSB_Ychannel)
LOOPBest regards,
Jurjen
PS: Do a refresh on this page if you cannot see the full code, this is an Internet Explorer bug ...
Last edited:
Thankyou for your suggestion
I feel humbled by your reprimand on accuracy.:
perhaps I am using the wrong commands. I used
main:
i2cslave %00110000, i2cfast, i2cbyte
writei2c 0,(00000001)
pause 100
readi2c 0,(b0,b1)
pause 10
debug b1
goto main
The chip I have is 18x.
I will try your suggestion shortly.
Thankyou again
I feel humbled by your reprimand on accuracy.:
perhaps I am using the wrong commands. I used
main:
i2cslave %00110000, i2cfast, i2cbyte
writei2c 0,(00000001)
pause 100
readi2c 0,(b0,b1)
pause 10
debug b1
goto main
The chip I have is 18x.
I will try your suggestion shortly.
Thankyou again
Update
I checked my 18X code against the 28X code suggested by Kranenborg and they are essentially equivalent.
I checked, using an oscilloscope, that the output on the data line corresponds to the adress entered for the slave and that data and control signals occur at the correct time following the write signal. Yet the data in debug shows $FFFF.
However b0 should be 0 or 1.
I can change the adress and the data line changes acordingly on the oscilloscope.
I can change fast to slow but the data remains fast at about 400khz
I checked my 18X code against the 28X code suggested by Kranenborg and they are essentially equivalent.
I checked, using an oscilloscope, that the output on the data line corresponds to the adress entered for the slave and that data and control signals occur at the correct time following the write signal. Yet the data in debug shows $FFFF.
However b0 should be 0 or 1.
I can change the adress and the data line changes acordingly on the oscilloscope.
I can change fast to slow but the data remains fast at about 400khz
lanternfish
Senior Member
This isn't a case where the pull-up resistors on the i2c lines are missing, is it?
Cheers
Cheers
lanternfish
Senior Member
westaust55
Moderator
As already alluded to, this memsic chip is available with 4 different i2c addresses.
As indicated in the datasheet, that lower case "x" in the part number will in fact be a digit (0-3) which determines the actual/full i2c address.
Have you verified the correct address from the IC markings for your specific sensor chip?
kranenborg
Senior Member
Hi pmonro,
The i2c education is proceeding very well but not yet completely finished ;o) because ...
the i2c device address that you provide in your example code above is wrong:
It should be (xx stands for the particular device address option of your part, you may have to try all four options)
An i2c address is always 7-bit (in this case %0110xx0), with the 8th R/W-bit appended to the RIGHT (and in defining the device via i2cslave or hi2csetup this bit is always 0. The picaxe itself takes care of setting this bit appropriately when performing the i2c transactions; for example a read requires a write operation first (for addressing the appropriate register in the device), then completes with read transactions to get the data out). The 7-bit address alignment in a byte often gives rise to some confusion. I find the i2c transaction description in the eeprom datasheet (24LC512) much easier to understand and it works in a similar way.
Hope this helps, you are almost there (this thread also shows the importance of showing real code)!
/Jurjen
The i2c education is proceeding very well but not yet completely finished ;o) because ...
the i2c device address that you provide in your example code above is wrong:
Code:
i2cslave %00110000, i2cfast, i2cbyte
Code:
i2cslave %0110xx00, i2cfast, i2cbyteHope this helps, you are almost there (this thread also shows the importance of showing real code)!
/Jurjen
Last edited:
kranenborg
Senior Member
Hi pmonro,
Another remark to your code, namely regarding the read operation:
This code will read the contents of the command register first (since it is located at internal address 0) into b0 and then the MSB of the X-channel (at internal address 1) into b1.
I assume however that you want to read the MSB and LSB value (i.e. total 16-bit word) of the X-channel. Thus you would like to use the following code to start reading form internal register 1 and subsequently register 2:
The Y-channel word value can be read via
PS: the picaxe-18x is different regarding i2c bus speed compared to the other picaxes as it does not have all the hardware onboard. According to the manual therefore the 18X will run the bus always at 100KHz, irrespective of i2cfast/i2cslow. You note interestingly that you measured 400KHz constantly instead. Could you check again, otherwise we have an unknown 18X feature here (see, you already have started educating us)!
Regards
/Jurjen
Another remark to your code, namely regarding the read operation:
Code:
readi2c 0,(b0,b1)I assume however that you want to read the MSB and LSB value (i.e. total 16-bit word) of the X-channel. Thus you would like to use the following code to start reading form internal register 1 and subsequently register 2:
Code:
readi2c 1,(b0,b1)
Code:
readi2c 3,(b0,b1)PS: the picaxe-18x is different regarding i2c bus speed compared to the other picaxes as it does not have all the hardware onboard. According to the manual therefore the 18X will run the bus always at 100KHz, irrespective of i2cfast/i2cslow. You note interestingly that you measured 400KHz constantly instead. Could you check again, otherwise we have an unknown 18X feature here (see, you already have started educating us)!
Regards
/Jurjen
Last edited:
various
Your response on the frequency is very helpful. I wondered why there was no apparent change between fast and slow. I am inclined to believe that the frequency is 100khz rather than 400 I stated. It is a bit difficult to see at 2.5usec/division sweep rate. I wonder if this difference of frequency is the source of the problem.
You correctly spotted the incorrect address 00110000. However even with the correct address of 01100000 it will not comunicate.
The chip is a 2120. I read that from the face of the chip. This according to the data sheet is 60H address which agrees with the manual and the address used. In any event I tried all 4 addresses and also 11000000 and numorous others.
Concerning the read command I am looking for a 0 or 1 in b0 to confirm comunication. The other bits of the data can be added when this is confirmed
I guess my next step is to try a 28X chip at 400khz but I am not very hopeful this will cure the problem.
Your response on the frequency is very helpful. I wondered why there was no apparent change between fast and slow. I am inclined to believe that the frequency is 100khz rather than 400 I stated. It is a bit difficult to see at 2.5usec/division sweep rate. I wonder if this difference of frequency is the source of the problem.
You correctly spotted the incorrect address 00110000. However even with the correct address of 01100000 it will not comunicate.
The chip is a 2120. I read that from the face of the chip. This according to the data sheet is 60H address which agrees with the manual and the address used. In any event I tried all 4 addresses and also 11000000 and numorous others.
Concerning the read command I am looking for a 0 or 1 in b0 to confirm comunication. The other bits of the data can be added when this is confirmed
I guess my next step is to try a 28X chip at 400khz but I am not very hopeful this will cure the problem.
kranenborg
Senior Member
Could you post a circuit diagram and a picture of the actual circuit? Probably something has gone wrong there. A first try, did you exchange sda & scl ?
/Jurjen
/Jurjen
Hi Kranenborg I see you are online
No I have not tried to interchange data and control lines. I will do that as you suggest. I have been particularly careful to be sure to avoid any stress to the chip but this is unlikely to cause any harm.
I will post a picture of my test device. It has the 18x chip on a PC board I made and the sensor in a solderless DIP plug board with interconnecting wires.
It will take me say half an hour to post it
Regards
I had some problem with the picture. The freeservers website will not allow a download so you can only see it by pasting the link
" http://monro.freeservers.com/temp/picaxememsic.jpg"
No I have not tried to interchange data and control lines. I will do that as you suggest. I have been particularly careful to be sure to avoid any stress to the chip but this is unlikely to cause any harm.
I will post a picture of my test device. It has the 18x chip on a PC board I made and the sensor in a solderless DIP plug board with interconnecting wires.
It will take me say half an hour to post it
Regards
I had some problem with the picture. The freeservers website will not allow a download so you can only see it by pasting the link
" http://monro.freeservers.com/temp/picaxememsic.jpg"
Last edited:
Control and data lines
I interchanged these without effect.
I am inclined to believe this memsic chip is not functional. This was the reason for my initial question asking for anyone who had made it work with picaxe. If I had found such a person and then compared my code then I could come to the decision about the integrity of this chip. However in the absence of such confirmation, I think we have given it a pretty good examination
I interchanged these without effect.
I am inclined to believe this memsic chip is not functional. This was the reason for my initial question asking for anyone who had made it work with picaxe. If I had found such a person and then compared my code then I could come to the decision about the integrity of this chip. However in the absence of such confirmation, I think we have given it a pretty good examination
kranenborg
Senior Member
You could always test by exchanging the memsic device with an ordinary, functioning eeprom (assuming that you have one available like the 24LC256); there is a lot of code examples for the eeprom available on this forum. You could write just a byte and then see whether you can read it back. Preferrably use the same test setup: In this way you can test whether it indeed is the memsic chip or that the problem lies elsewhere (could be the connection somehow, since you already tested the 18X to be functional as it generated proper signals on your scope. Where did you measure; on the 18X pins or at the memsic device?)
I could not make any useful conclusions from the photo as the electrical connections at various places back on the prints cannot be traced.
/Jurjen
I could not make any useful conclusions from the photo as the electrical connections at various places back on the prints cannot be traced.
/Jurjen