| View previous topic :: View next topic |
| Author |
Message |
Fuat360
Joined: 05 Jul 2020
Posts: 7
|
| problem in using i2c |
 Posted: Sun Jul 05, 2020 7:36 am |
 |
|
Hello
I am trying to use i2c to take the temperature measurement from four TC74 sensors. My CCS program doesn't show any errors but when i use the hex file in Proteus the transmitted data from the sensor always has a fixed value and proteus is always showing me this error:
| Quote: | [PIC16 ADC] PC=0x01AA. ADC conversion clock period (1.25e-07) is possibly invalid for device clock frequency. [U1]
|
Can you help me to solve this problem using simple instructions as i am still a beginner in mcu programming.
My codes
| Code: |
#include<16f877A.h>
#fuses NOWDT,HS, NOPROTECT,NOBROWNOUT,NOLVP,NOPUT,NOWRT,NOCPD,
#use delay (clock=16MHz)
#use RS232(baud = 9600, XMIT = PIN_C6 )
#use I2C(master,I2C1,sda=PIN_C4,scl=PIN_C3,Fast=400000)
long int data1=0, data2=0, data3=0, data4=0;
void sensor1() {
i2c_start();
i2c_write(0x90);
i2c_write(0x02);
i2c_start();
i2c_write(0x91);
data1=i2c_read(0);
i2c_stop();
}
void sensor2() {
i2c_start();
i2c_write(0x92);
i2c_write(0x02);
i2c_start();
i2c_write(0x93);
data2=i2c_read(0);
i2c_stop();
}
void sensor3() {
i2c_start();
i2c_write(0x94);
i2c_write(0x02);
i2c_start();
i2c_write(0x95);
data3=i2c_read(0);
i2c_stop();
}
void sensor4() {
i2c_start();
i2c_write(0x96);
i2c_write(0x02);
i2c_start();
i2c_write(0x97);
data4=i2c_read(0) ;
i2c_stop();
}
void main()
{
while(TRUE)
{
sensor1();
printf("====%ld",data1);
}
}
|
|
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9221
Location: Greensville,Ontario
|
|
| Posted: Sun Jul 05, 2020 8:29 am |
|
|
PROTEUS is busted !! Please read the PIC101 'sticky' at the top of the forum.
I've yet to see ONE Proteus schematic that will actually work in the real World, using real parts.
Now when you get parts....be sure to download and run the I2C Scanner program in the Code Library ! Run it before trying ANY program that uses I2C peripherals. It will confirm/deny IF the PIC can 'see' the I2C devices AND printout their addresses.
As for your code, it's best to get into the habit of using 'define's for values like I2C addresses, commands, data etc. IE: I have no idea if 0x92 is valid for your application.
Also get into the habit of adding comments after most/all lines of code.
say
i2c_write(0x90); //address of 1st I2C sensor
instead of
i2c_write(0x90);
While you know what the code is now....others don't AND 3 days or 3 weeks from now YOU might not remember !
Always check the 'code library' forum ! There's LOTS of drivers and other working code that's been posted by programmers. while it might be exactly what you need, it'll help show you possible solutions or methods to do what you want. |
|
|
dluu13
Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON
|
|
| Posted: Sun Jul 05, 2020 8:39 am |
|
|
Looking at the datasheet the command for reading temperature appears to be 0x00 rather than 0x02 like you have.
Note that it's not necessary to use 16-bit data when the sensor only returns 8 bits unless you're doing something with it later that needs the extra bits. You should be aware that depending on which MCU you are specifically using, "long" can mean different things so you should use variables that say how many bits they contain. You can find those in CCS manual.
Also while sensors with alternative addresses are available, they need to be custom ordered, so be aware of that.
As temtronic says, there's nothing better than real world parts... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Sun Jul 05, 2020 9:33 am |
|
|
It's 'misreporting' what the problem actually is, but there is a very significant
issue with the code:
| Quote: |
#use I2C(master,I2C1,sda=PIN_C4,scl=PIN_C3,Fast=400000)
|
What makes you think the device supports 400KHz I2C?.
From the data sheet:
| Quote: |
SMBus/I2C Clock Frequency fSMB 10 — 100 kHz
|
100KHz _max_.....
Your I2C setup needs:
#use I2C(master,I2C1,sda=PIN_C4,scl=PIN_C3,Slow=100000)
This is a standard I2C device, not a fast mode device. It also requires the
slower turn round times for a slow I2C device.....
This is why reading the data sheet is vital before programming things
like clock rates... 
However that having been said, I 'second' the comments about Proteus.
Understand that I do use lots of tools to try to help when developing. ICD's
ICE's, etc. etc.. I have Proteus design suite, but while a great schematic
package, and the analog simulator is totally competent, as a PIC emulator
it perhaps scores 2 out of 10 max. It is very incapable indeed. I have
working designs, that it says won't work, but also designs that could never
have even a remote chance of working, that it says are fine.
Basically it is likely to waste more time than it saves.
Last edited by Ttelmah on Sun Jul 05, 2020 9:36 am; edited 1 time in total |
|
|
Fuat360
Joined: 05 Jul 2020
Posts: 7
|
|
| Posted: Sun Jul 05, 2020 9:33 am |
|
|
| temtronic wrote: | PROTEUS is busted !! Please read the PIC101 'sticky' at the top of the forum.
I've yet to see ONE Proteus schematic that will actually work in the real World, using real parts.
Now when you get parts....be sure to download and run the I2C Scanner program in the Code Library ! Run it before trying ANY program that uses I2C peripherals. It will confirm/deny IF the PIC can 'see' the I2C devices AND printout their addresses.
As for your code, it's best to get into the habit of using 'define's for values like I2C addresses, commands, data etc. IE: I have no idea if 0x92 is valid for your application.
Also get into the habit of adding comments after most/all lines of code.
say
i2c_write(0x90); //address of 1st I2C sensor
instead of
i2c_write(0x90);
While you know what the code is now....others don't AND 3 days or 3 weeks from now YOU might not remember !
Always check the 'code library' forum ! There's LOTS of drivers and other working code that's been posted by programmers. while it might be exactly what you need, it'll help show you possible solutions or methods to do what you want. |
How can I use the i2c scanner ?
The address are taken from the datasheet of the sensor.
Do you thınk if i change Proteus version it would work ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Sun Jul 05, 2020 9:39 am |
|
|
You posted while I was typing.
The I2C scanner is a simple program in the code library. Take your chip
header, add the code from this. Add a serial port, and it will report the
address where the I2C device(s) is/are found. It is a vital diagnostic tool
for I2C.
However change your I2C clock rate first.... |
|
|
Fuat360
Joined: 05 Jul 2020
Posts: 7
|
|
| Posted: Sun Jul 05, 2020 9:43 am |
|
|
| Ttelmah wrote: | You posted while I was typing.
The I2C scanner is a simple program in the code library. Take your chip
header, add the code from this. Add a serial port, and it will report the
address where the I2C device(s) is/are found. It is a vital diagnostic tool
for I2C.
However change your I2C clock rate first.... |
I have already tried what you said before but it doesn't work. |
|
|
dluu13
Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON
|
|
| Posted: Sun Jul 05, 2020 9:47 am |
|
|
To add to that, we use the scanner because it is a known working program that we can use to ensure that at least the hardware design and assembly is in a working state. In embedded development there are so many different factors where things can go wrong. Was it the design that was flawed in the first place? Was the assembly sloppy and you have bridged pins? Did you perform your setup properly in the code? What about your application code?
In light of all those, a simulated hardware in a program will never be a definitive indication of whether a combination of hardware and code will work. It is just another layer to the puzzle where things can go wrong. These PICs are very complex parts on top of your own application circuit. There are literally countless ways to put everything together.
This is why we take Proteus results with a grain of salt. There have been a few documented cases where a design works in Proteus but not in real world or vice versa in that sticky thread that was references earlier. |
|
|
Fuat360
Joined: 05 Jul 2020
Posts: 7
|
|
| Posted: Sun Jul 05, 2020 9:50 am |
|
|
| dluu13 wrote: | Looking at the datasheet the command for reading temperature appears to be 0x00 rather than 0x02 like you have.
Note that it's not necessary to use 16-bit data when the sensor only returns 8 bits unless you're doing something with it later that needs the extra bits. You should be aware that depending on which MCU you are specifically using, "long" can mean different things so you should use variables that say how many bits they contain. You can find those in CCS manual.
Also while sensors with alternative addresses are available, they need to be custom ordered, so be aware of that.
As temtronic says, there's nothing better than real world parts... |
I also took a look for the datasheet reading temperature appears to be 0x02.
But i tried what you said, 0x00. It doesn't work.
And also i changed the variables types for float, double, int.
But it never works. |
|
|
Fuat360
Joined: 05 Jul 2020
Posts: 7
|
|
| Posted: Sun Jul 05, 2020 9:52 am |
|
|
| dluu13 wrote: | To add to that, we use the scanner because it is a known working program that we can use to ensure that at least the hardware design and assembly is in a working state. In embedded development there are so many different factors where things can go wrong. Was it the design that was flawed in the first place? Was the assembly sloppy and you have bridged pins? Did you perform your setup properly in the code? What about your application code?
In light of all those, a simulated hardware in a program will never be a definitive indication of whether a combination of hardware and code will work. It is just another layer to the puzzle where things can go wrong. These PICs are very complex parts on top of your own application circuit. There are literally countless ways to put everything together.
This is why we take Proteus results with a grain of salt. There have been a few documented cases where a design works in Proteus but not in real world or vice versa in that sticky thread that was references earlier. |
I am doing this project only in the simulation program (Proteus) not in the real world,
thanks a lot for your comment. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19496
|
|
| Posted: Sun Jul 05, 2020 9:55 am |
|
|
and have you changed the I2C rate as I have already said twice....
The chip is _not_ rated to run at 400KHz. |
|
|
dluu13
Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON
|
|
| Posted: Sun Jul 05, 2020 9:59 am |
|
|
Just to be sure, I am looking at this datasheet:
https://www.microchip.com/wwwproducts/en/TC74
The command list is on table 4-1.
Regarding the data types, you need to read the CCS manual which will explain what each type is and how their data is represented. |
|
|
Fuat360
Joined: 05 Jul 2020
Posts: 7
|
|
| Posted: Sun Jul 05, 2020 10:05 am |
|
|
| Ttelmah wrote: | and have you changed the I2C rate as I have already said twice....
The chip is _not_ rated to run at 400KHz. |
I did what you said but it didn't work. |
|
|
dluu13
Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON
|
|
| Posted: Sun Jul 05, 2020 10:11 am |
|
|
Could you be a little more specific? What does the output of the i2c bus scanner say? How are you verifying the result of your i2c_read()?
What is your circuit? Do you have the right pull up resistors on your clock and data lines? What about bypass capacitors on your power pins? Your PIC is a 5v part. Are you also using the 5v version of the sensor or did you have a 3.3v version? |
|
|
Fuat360
Joined: 05 Jul 2020
Posts: 7
|
|
| Posted: Sun Jul 05, 2020 10:24 am |
|
|
| dluu13 wrote: | Could you be a little more specific? What does the output of the i2c bus scanner say? How are you verifying the result of your i2c_read()?
What is your circuit? Do you have the right pull up resistors on your clock and data lines? Your PIC is a 5v part. Are you also using the 5v version of the sensor or did you have a 3.3v version? |
I am using virtual termlnal to see the output.
The i2c scanner shows lots of ?????
https://drive.google.com/file/d/1hxWuJ-80L_HbrKF_KrjX5K6WTw1mpJfS/view?usp=sharing |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
