 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Mahdi
Joined: 21 Aug 2012
Posts: 47
|
|
 Posted: Sat Aug 25, 2012 12:22 am |
 |
|
| bkamen wrote: | | Mahdi wrote: | | for a project |
And that would be a project for school? Work? Personal Fun? |
For work. It is used in making the Flush or Protractor. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Sat Aug 25, 2012 4:41 am |
|
|
| sseidman wrote: | | Ttelmah wrote: | No, the reason that only software will work, is the input, not the output.
The hardware MSSP (I2C) module has a Vih, of 0.8* the PIC's Vdd. So with a 5v PIC, 4v. So if it is being being driven off an I2C device with the pull-ups going to 3v, it'll never see a 'high', and won't work....
This is the point about choosing pins with TTL input buffers, where Vih is low enough to happily work off the 3v device.
Best Wishes |
Thanks! I'm in a design now where I'm pulled up to 3V using hardware i2c, and everything seems to be working. I'm on an 18f, and in i2c mode Vih is 0.7 Vdd, so it shouldn't and does, but I'll assume it won't do so reliably! The plan is to isolate this part of the 12c bus anyway, so I'll just have the microcontroller bus pulled to 5v anyway, but it's nice to know! |
Which particular PIC?.
Most 18F chips still have Vih for the Schmitt buffers at 0.8*Vdd. However some have the data input buffer on the pins used by the hardware I2C, using TTL buffers, and only the hardware module using Schmitt levels. I'd guess you are actually using _software_ I2C, and don't realise it!. A quick look at the assembler generated will tell you. Remember the internal library defaults to using software, and 'FORCE_HW' is needed to use the hardware. This differs from #use RS232, where if you use the hardware pins, it defaults to using the hardware.....
If you look (for instance), at the 18F4550, on this the I2C pins are RB0/RB1, and the input buffers on these pins are TTL, but the input buffers when using the hardware I2C, are Schmitt. Then in the DC Characteristic table, Vih, for pins with Schmitt buffers is given at 0.8*Vdd, only pins RC3, and 4, have 0.7*Vdd thresholds.
On the chip being used here (16F877A), the I2C is on pins RC3/RC4, and these have Schmitt input buffers when used as normal I/O. However these pis have the 0.7*Vdd threshold, making the voltage nominally 3.5v, which with a 3.3v supply to the second IC, is 'right on the borderline'......
Best Wishes |
|
|
Mahdi
Joined: 21 Aug 2012
Posts: 47
|
|
| Posted: Sun Aug 26, 2012 7:56 am |
|
|
| i want to write in CLKSEL[2:0] in PWR_MGMT_1 register.what is the address of clksel register? how to write data in clksel?What is the hexadecimal address clksel register? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Sun Aug 26, 2012 11:43 am |
|
|
CLKSEL, is not a register. It is bits 2:0 of the PWR_MGMT_1 register.
Looks like address 107, from what you post,but we can never tell without knowing the PIC....
Best Wishes |
|
|
Mahdi
Joined: 21 Aug 2012
Posts: 47
|
|
| Posted: Sun Aug 26, 2012 12:45 pm |
|
|
| Ttelmah wrote: | CLKSEL, is not a register. It is bits 2:0 of the PWR_MGMT_1 register.
Looks like address 107, from what you post,but we can never tell without knowing the PIC....
Best Wishes |
in the first post i said pic16f877a
thanks alot |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Sun Aug 26, 2012 2:42 pm |
|
|
The 877a, doesn't have any CLKSEL bits. These are only present on chips with run time oscillator switching. It doesn't have a power management register either, this only exists on chips supporting different sleep levels. You seem to have pulled the data from a completely different chip, hence my question.....
Best Wishes |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Aug 26, 2012 2:43 pm |
|
|
The address of the PWR_MGMT_1 register is given on page 8 of this pdf:
http://invensense.com/mems/gyro/documents/RM-MPU-6000A.pdf
It's 0x6B. You should use that exact number in your code. Don't left-
shift it. Don't left-shift any register addresses. The left-shift is only
done for the i2c Slave address, and it's only done for data sheets that
give the slave address in Philips 7-bit format. |
|
|
ROBO12
Joined: 28 Aug 2012
Posts: 4
|
|
| Posted: Tue Aug 28, 2012 9:40 am |
|
|
Hi. I bought an mpu6050 sensor and I was able to set it up but there is a problem. There are 2 parameters for each axis. For example in x accel axis there are 2 contain, Xout_H[15:8] and Xout_L[7:0]. In accel_XOUT_H I can read data and it is clear on lcd but in XOUT_L the data is not clear and altered.
The register address for _H = 0x3b
The register address for _L = 0x3c
Code for _H:
| Code: |
i2c_start();
i2c_write(0xd0);
i2c_write(0x3b);
i2c_start():
i2c_write(0xd1);
x=i2c_read(0);
i2c_stop();
|
code for _L:
| Code: |
i2c_start();
i2c_write(0xd0);
i2c_write(0x3c);
i2c_start():
i2c_write(0xd1);
y=i2c_read(0);
i2c_stop(); |
Where is the problem? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Aug 28, 2012 12:23 pm |
|
|
| Quote: | the data is not clear and altered.
|
What does this mean ? Give an example. |
|
|
ROBO12
Joined: 28 Aug 2012
Posts: 4
|
|
| Posted: Wed Aug 29, 2012 5:10 am |
|
|
| PCM programmer wrote: | | Quote: | the data is not clear and altered.
|
What does this mean ? Give an example. |
According to datasheet for each axis there are 2 contain.accel_XOUT_H[15:8]
and accel_XOut_L[7:0]
The axis is a 16-bit output.H contain 8 bit and L contain 8bit
The output value of accel_Xout_H is in correctly is shown on lcd and accel_Xout_H value changes with change angle but the output value of accel_XOUT_L is not constant and changing continuously while the sensor is fixed and does not change the angle.
My English is poor. I'm Sorry. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Aug 29, 2012 3:24 pm |
|
|
According to the i2c section in the MPU-6050 data sheet, you can do a
Burst Read operation, where you read sequential bytes. So you can
probably read both the H and L values in one i2c transaction, as shown
below. If you read it this way, it might solve your problem. I don't know.
If not, then post your code that shows how you display it on the LCD.
| Code: |
#include <16F887.H>
#fuses INTRC_IO, NOWDT, BROWNOUT, PUT, NOLVP
#use delay(clock=4M)
#use rs232(baud=9600, UART1, ERRORS)
#use i2c(Master, scl=PIN_C3, sda=PIN_C4)
#define MPU6050_SLAVE_WRT 0xD0
#define MPU6050_SLAVE_RD 0xD1
#define ACCEL_XOUT_H 0x3B
#define ACCEL_XOUT_L 0x3C
int16 MPU6050_read_word(int8 reg_addr)
{
int8 lsb, msb;
int16 retval;
i2c_start();
i2c_write(MPU6050_SLAVE_WRT);
i2c_write(reg_addr);
i2c_start();
i2c_write(MPU6050_SLAVE_RD);
msb = i2c_read(); // Read MSB byte first.
lsb = i2c_read(0); // Do a NACK on the last read
i2c_stop();
retval = make16(msb, lsb);
return(retval);
}
//===================================
void main()
{
int16 x_accel;
// Put MPU6050 init code here.
// Read X Accel word.
x_accel = MPU6050_read_word(ACCEL_XOUT_H);
while(1);
} |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Thu Aug 30, 2012 2:19 am |
|
|
Other comments:
The signal is quite likely to fluctuate a tiny amount. This will depend on how the noise filters are programmed, and even with a completely stable signal, the output from the conversion will change. If you have a signal sitting 'between' two steps on any ADC, the output generally will be the two numbers each side, with the statistical probability of the two readings representing 'where' the voltage is between the levels. The signal will also always have sampling noise, thermal noise, and noise from the reference source, 'modulating' the result a little.
This might be being made 'worse', if the supply is a little noisy, or the smoothing on the internal regulator is not correctly designed. 'Bigger is not better' here. You want a capacitor that has good high frequency performance (larger capacitors often don't).
So try the burst read mode, and if the signal is jumping by more than perhaps one or two counts, start looking at the hardware.
Best Wishes |
|
|
sseidman
Joined: 14 Mar 2005
Posts: 159
|
|
| Posted: Thu Aug 30, 2012 7:04 am |
|
|
| Ttelmah wrote: |
Which particular PIC?.
Most 18F chips still have Vih for the Schmitt buffers at 0.8*Vdd. However some have the data input buffer on the pins used by the hardware I2C, using TTL buffers, and only the hardware module using Schmitt levels. I'd guess you are actually using _software_ I2C, and don't realise it!. A quick look at the assembler generated will tell you. Remember the internal library defaults to using software, and 'FORCE_HW' is needed to use the hardware. This differs from #use RS232, where if you use the hardware pins, it defaults to using the hardware.....
|
Thanks Ttelmah-- I'm using the 18f4520, w/ Force_HW in the #use line. |
|
|
ROBO12
Joined: 28 Aug 2012
Posts: 4
|
|
| Posted: Sat Sep 01, 2012 2:55 am |
|
|
| Quote: | | then post your code that shows how you display it on the LCD. |
Mr. pcm does not work your method.
this is my code :
| Code: | #include <16F877a.h>
#use delay(clock=4000000)
#define use_portb_lcd TRUE
#define LCD_ENABLE_PIN PIN_D2
#define LCD_RS_PIN PIN_D0
#define LCD_RW_PIN PIN_D1
#define LCD_TYPE 2
#use I2C(master,sda=PIN_C4,scl=PIN_C3,slow,restart_wdt)
#include <lcd.c>
void main()
{
set_tris_b(0x00);
lcd_init();
int8 x;
while(true)
{
i2c_start();
i2c_write(0xd0);
i2c_write(0x3c);
i2c_start();
x=i2c_read(0);
i2c_stop();
lcd_gotoxy(1,1);
printf(lcd_putc,"%u",x);
}
} |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Sat Sep 01, 2012 2:49 pm |
|
|
You have to send the device address again after a restart.
Sequence is:
start
device address with direction bit set to write
register address
data to go to register (optional - remember register will normally increment)
restart
device address with direction bit set to read
read data from register
stop.
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
