write into a register in ADXL345 through i2c whit stm32f4 's

[mohamad_armoon]

Posted on March 30, 2014 at 09:25

hi guys. for gathering data from adxl345 accelerometer i need to write some data in specified register in this sensor. but in stm32f4xx_i2c.c there isn't any function like :

I2C_SendData(I2Cx, data);

to write in a register which i know it's address.

is there anybody to explain me the procedure of this matter, means connect adxl345(or any sensor which is connected through i2c  ) through i2c to stm32f4

#stm32f4 #i2c #i2c #discovery #accelerometer #discovery #stm32f4

[mohamad_armoon]

Posted on April 05, 2014 at 09:42

i know it has to send ack but im new in stm and i don't know how should i implement this .

i don't know  how to send ack to slave

[stm322399]

Posted on April 05, 2014 at 10:13

This is exactly the purpose of

I2C_AcknowledgeConfig(I2Cx, ENABLE);

This call configures the I2C engine to acknowledge every byte received from the slave. When you arrive at the end of the transfer, you must disable the acknowledge, this will tell the slave to stop sending bytes. Then you close the transfer with a STOP mark.

[mohamad_armoon]

Posted on April 07, 2014 at 09:44

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6ne&d=%2Fa%2F0X0000000bvj%2Fnu4g5eyt3cQzU98KAL4QWSnwxiK9wkxpd.As2g1i6t4&asPdf=false

[chen]

Posted on April 07, 2014 at 11:11

Hi Mohamad

Sorry, I got the impression you were not using a debugger but you are - so that is good.

''one of my guesses is that maybe because in my main loop(while(1)) i never send the stop to slave , the busy flag becomes high and after a few reset it seems ok, and works,''

''any idea would be great.''

The code you showed is out of context but I am guessing that it is in main()

The classic mistake here is that you expect the I2C slave to be ready on power up (you are using the ST Eval board and I am guessing that the I2C slave device is power off the dev board). It probably works OK when you debug and start the program from the debugger but fails when it powers up without the debugger.

The STM32 boots up in mirco seconds and will boot on as little as 1.8V

The STM32 need to either put in a large delay (ms) or be in control of enabling the I2C slave.

[mohamad_armoon]

Posted on April 11, 2014 at 15:28

hi sung.chen_chung

thanks for your useful information. i really helped me. but i think my major problem in i2c was the ack which i didn't send to slave . 

[ben]

Posted on May 04, 2014 at 16:32

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6og&d=%2Fa%2F0X0000000bw7%2FVdRUrnWyO6VFs_k4M_2IOM86A.lbk1i3lYCTH1fd7so&asPdf=false

[mohamad_armoon]

Posted on May 05, 2014 at 13:45

higoyens.ben

i've worked with ADXL345 and HMC5883 with discovery . in i2c stuff getting data from the first sensor is the hardest . so you'd better to debug this code and tell me in which line your code crashes . if not , your main loops works well because i use flags to check step by step of this procedure. if you get continuousdata from usart i think there isn't problem in your code . and you are just getting data as char(character) and you have to get it byte by byte. and in computer side you convert it as float data. in computer side : you should read data from serial port so for example in pc side program (i wrote it in c#) :

while
(
true
){
// receive x0 data
int16 temp1 = serialport.Read();
// receive x1 data
temp1 | = serialport.read() << 8;
// receive y0 data
int16 temp2 = serialport.Read();
// receive y1 data
temp2 | = serialport.read() << 8;
// receive z0 data
int16 temp2 = serialport.Read();
// receive z1 data
temp2 | = serialport.read() << 8;
}

if you can't program in pc so: in micro you can convert this , and send final result as char through usart.

[ben]

Posted on May 06, 2014 at 11:56

Hi Armoun

Thanks for your answer! At the moment my program compiles and runs and I get constantly data through my serial communication (Putty.exe), so I think and hope that it is maybe just the float/char conversion that is making it impossible to read. What program did you use to get the data from the serial communication? I found the next piece of code on this site:

http://eliaselectronics.com/stm32f4-tutorials/stm32f4-usart-tutorial/

void

USART_puts(USART_TypeDef* USARTx,

volatile

char

*s){
while

(*s){
// wait until data register is empty
while

( !(USARTx->SR & 0x00000040) );
USART_SendData(USARTx, *s);
*s++;
}
}

Is this what you mean with converting the data? Or do I need to implement another function? I tried running your code but I am running into trouble using the serialport.read function.. Sorry that these questions may seem stupid but due to the time I am self-educating on the job the parts that I need to know.. The fact that my three sensors send there data through the same SLC and SDA pins don't have an influence on your code? (meaning the device address does not have to be sent each time data is needed?) Greetings Ben

[mohamad_armoon]

Posted on May 07, 2014 at 07:49

higoyens.ben

there is some point i have to mention :

1- i wore my pc side program in c# which read from serial port and it convert my raw data from serial port to accelerate data. but for understanding the

truth of

your raw data you just need to watch your data as hex. i think you get is as char. you know if you getting data accurate you will see that there is e order in your input data.if your sensor is fixed and stable, your data approximately

is the same at every 6 byte. if you split it every 6 byte(because of 6 byte you reading from i2c). but you will never get exactly same data. if you did that i will guide you how to convert is to accelerate . it would be better if you put some of input

data in hex here.

for checking (not converting ) i use this program. there is same software alot :http://msmvps.com/blogs/coad/archive/2005/03/23/SerialPort-_2800_RS_2D00_232-Serial-COM-Port_2900_-in-C_2300_-.NET.aspx

2- the function you mentioned is just for putting data into usart tx. i did it through random delay and this function is absolutely better and logical .

3- in i2c because you using same bus for your 3 sensor. each time you want to get data from each one you need to send it's address to the line(

ReadFromAccel(DATAX0);

). and it when specified sensor get it's address it will ready to put data in

bus.

converting data : you get 2 byte raw data for each axis . this 2 byte is meaning less while you put them together and build a 16bit integer from them. in datasheet you will see which byte is MSB(most significant byte) and LSB(least significant byte).

so you have to organize them like this : i put it in attach .

any question . just ask

________________

Attachments :

msb.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzYT&d=%2Fa%2F0X0000000bNa%2Fgfmte40W6ZGYNq73YqL14Er5L4R6.y8Lfh41EFf_kCc&asPdf=false

[ben]

Posted on May 07, 2014 at 11:08

Hi Armoun

Ok I tried testing my code to see if my USART connection was working, because it would be stupid if that didn't work... So in the main loop I commented all of the sensor readings and just put this: 

USART_SendData(USART3, 0x34);

In the while(1) loop.. Then I opened the port with the application you mentioned and put the data mode on hex the result was: 00 FC 00 FC 00 FC 00 FC ..... (which after googling it seems to be the Ü character) Any Idea why it seems to change the value? Sending 0x01 gives 1C as an output.. 

I just tested also the readout of the sensor and there it is also almost the same (FC 00 00 E0 1C E0 00 FC FC, this keeps repeating) and when I move the sensor the hex data doesn't change so there is still something wrong..

Greetings Ben