 |
 |
| View previous topic :: View next topic |
| Author |
Message |
otavio_fisica
Joined: 20 Jul 2006
Posts: 29
|
| Error on sending via RS232 after reading temperature |
 Posted: Tue Dec 12, 2006 1:21 pm |
 |
|
Hi everyone. I'm using a DS1621 to read the temperature, but I have a problem that is making me go crazy. The code I am using is the following:
| Code: |
#include <16F819.h>
#fuses HS,NOWDT,NOPROTECT,NOLVP,PUT
#use delay(clock=8000000)
#use rs232(baud=9200,xmit=PIN_B0,rcv=PIN_B5,ERRORS, parity=N)
#define DAL_SCL PIN_B4
#define DAL_SDA PIN_B1
#use i2c(master,sda=DAL_SDA, scl=DAL_SCL)
int datah,datal,readslope,readcounter,conta1;
float data,conta;
void main() {
output_high(DAL_SDA);
output_high(DAL_SCL);
//---Configure the configuration bits.
i2c_start();
i2c_write(0x90);
i2c_write(0xac);
i2c_write(2);
i2c_stop();
delay_ms(30);
//---Starts the convertion.
i2c_start();
i2c_write(0x90);
i2c_write(0xee);
i2c_stop();
delay_ms(30);
//-------------------
do {
//---Reads the temperature.
output_high(PIN_A2); //(Just for control... there's a led tied to it).
i2c_start();
i2c_write(0x90);
i2c_write(0xaa);
delay_ms(20);
i2c_start();
i2c_write(0x91);
datah=i2c_read();
datal=i2c_read(0);
i2c_stop();
//---To increase resolution.
i2c_start();
i2c_write(0x90);
i2c_write(0xa9);
delay_ms(20);
i2c_start();
i2c_write(0x91);
readslope=i2c_read();
i2c_stop();
i2c_start();
i2c_write(0x90);
i2c_write(0xa8);
delay_ms(20);
i2c_start();
i2c_write(0x91);
readcounter=i2c_read();
i2c_stop();
//---Operations for increasing resolution.
data=(float)datah;
conta1=readslope-readcounter;
conta=(float)conta1/readslope;
conta -=0.25;
data +=conta;
//---Sends the temperature value to the computer via RS-232.
delay_ms(1000);
printf("%3.2g\r\n",data);
//-----------------------------------------------
} while (TRUE);
} |
The problem is that, when I turn it on, it starts sending the information to the computer (I see using the Hyperterminal). As you can see in the code, the PIN_A2 is put high at the beginning of the DO instruction. Since I never put is low again, it should remain high forever. As time passes by, it starts blinking and the pic stops sending the data to the computer. And the period of time it stays low goes increasing until it remains totally low. The craziest thing is that if I switch the PIC off and on immediatelly, it will blink and go low and the pic won't send anything to the computer. But, if I switch the PIC off and wait for some time (tipically minutes) before switching it on again, it will happen what I described inicially. From the temperature value it sends to the computer, the first ones (3 or 4) are wrong, but then the rest is alright with the real temperature value.
What could be hapenning? Could someone give some help? It would be of great value.
Thank you all and have a good work. |
|
 |
otavio_fisica
Joined: 20 Jul 2006
Posts: 29
|
| More Information |
| Posted: Tue Dec 12, 2006 1:30 pm |
|
|
| For general information, I use 2k pull-up resistors. I have already seen in the osciloscope the clock signal and it is perfect. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Dec 12, 2006 1:32 pm |
|
|
Your driver is wrong. I didn't study it in detail, but I immediately see
that you're missing the "NAK" on the i2c_read() statements when you
read the Slope and the Counter registers.
See this thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=23359
Notice that in the Slope and Counter read sections, the i2c_read()
function has a 0 parameter, which means to do a "NAK" on that read. |
|
|
otavio_fisica
Joined: 20 Jul 2006
Posts: 29
|
|
| Posted: Tue Dec 12, 2006 1:43 pm |
|
|
| Yeah, that was missing, but I changed and nothing happened. And these strange things were already hapenning even before using the high precision algorithm. I was testing with the 0.5ºC precision, and I used to have exactly the same problem. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Dec 12, 2006 1:55 pm |
|
|
Try a very simple program, that doesn't use the DS1621, as shown below.
Notice that I've added the Brownout fuse. Also, for some reason, you
had the baud rate set to a non-standard value of 9200. Why ?
I changed it to 9600 baud. Run this program and see if you still get
the problem.
Also, do you have a pull-up resistor on the MCLR pin ? The flakey
behaviour that you're describing could possibly be caused by a floating
MCLR pin. What is your Vdd voltage for the PIC ? Is it +5v or +3.3v ?
| Code: | #include <16F819.h>
#fuses HS,NOWDT,NOPROTECT,BROWNOUT,PUT,NOLVP
#use delay(clock=8000000)
#use rs232(baud=9600,xmit=PIN_B0,rcv=PIN_B5)
//============================
void main()
{
while(1)
{
printf("Hello World\n\r");
delay_ms(1000);
}
} |
|
|
|
otavio_fisica
Joined: 20 Jul 2006
Posts: 29
|
|
| Posted: Tue Dec 12, 2006 2:19 pm |
|
|
Good idea to test this simples program without the DS1621. Result: the same thing. Some data are corrupted and it sends too fast (shouldn't it send one line per second instead of several lines per second??). The baud rate 9200 was a mistake I had made before putting the code here. I haven't used this baud rate, I've used 9600. I also tried the pull-up resistor in the MCLR, but nothing changed. My Vdd voltage is 5V.
Do you have any other idea? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Dec 12, 2006 2:53 pm |
|
|
| Quote: | | Shouldn't it send one line per second instead of several lines per second ?. |
This could mean that the PIC is constantly resetting. Run the following
program and see what it says. It will display a byte that gives the
reason for the reset. If it displays several different values, then post
all of the results.
| Code: | #include <16F819.h>
#fuses HS,NOWDT,NOPROTECT,BROWNOUT,PUT,NOLVP
#use delay(clock=8000000)
#use rs232(baud=9600,xmit=PIN_B0,rcv=PIN_B5)
//============================
void main()
{
int8 result;
result = restart_cause();
printf("%X\n\r", result);
while(1)
{
printf("Hello World\n\r");
delay_ms(1000);
}
} |
| Quote: | | I also tried the pull-up resistor in the MCLR, but nothing changed. |
What resistor value do you have for the MCLR pull-up ? |
|
|
otavio_fisica
Joined: 20 Jul 2006
Posts: 29
|
|
| Posted: Wed Dec 13, 2006 4:52 am |
|
|
Hi... I guess you have discovered the problem. I did what you've recommended and the byte it return was "18". Sometimes, it worked fine, such as in this example below:
| Quote: | 18
Hello World
18
Hello World
18
Hello World
18
Hello World
18
Hello World
18
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World |
It was restarting and sending the restart byte (18), then it started to send one "Hello World" per second (as it should be). After this, it began to restart again... I tried pull-up resistors for MCLR such as 1K, 1K2 and 5K: no difference between them. The one I used in the test I've just posted was 1K2. I've looked at the .h file for the 16F819 and I saw that the possible bytes returned by the restart_cause command are 3, 11, 19, 27, 24 and 26. Do you have any idea of what I could do to solve my problem?
Thank you for your help. |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Dec 13, 2006 5:25 am |
|
|
Restart_cause, puts together it's value, from the bits laid out as:
0 0 0 TO PD 0 POR BOR
The bits are all -ve logic.
You then have 'BOR' low which implies a brownout condition, and PD low, which is meant to imply a sleep condition!. So the combination, ought to be a 'brownout restart from sleep'. An odd combination, but one that really does say you need to be looking at the supply to see why the brownout bit is being triggered. Decoupling close to the PIC, and checking that the regulator is not oscillating, would be a good place to start.
How on earth this is happenign from 'sleep', is odd. Normally this is caused by running off the end of main, and hitting the 'hidden' sleep instruction there, but the code as posted, should not be doing this.
Best Wishes |
|
|
otavio_fisica
Joined: 20 Jul 2006
Posts: 29
|
|
| Posted: Wed Dec 13, 2006 6:50 am |
|
|
Well, I've verified the power supply with an osciloscope. It's ok... no problems. I tried to change the PIC for another 16F819 and the result was the same. I really don't know what is hapenning. But, if the problem is with the brownout reset, what if I turn this option down? Result: it works perfectly. It reads the temperature and sends to the computer without mistakes, and one per second, as is in the code above.
Any suggestion for what could be hapenning?
Thank you all for the help. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Wed Dec 13, 2006 7:24 am |
|
|
| What is your compiler version? (check top of the *.lst file, something like v3.249 of v4.018) |
|
|
otavio_fisica
Joined: 20 Jul 2006
Posts: 29
|
|
| Posted: Wed Dec 13, 2006 8:55 am |
|
|
| The version is 3.235. Why? Is that important? Do you think there may be something wrong with the compiler? |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Dec 13, 2006 10:24 am |
|
|
Seriously, try the scope on AC, and look at the 5v rail. The brownout comparator, can respond to spikes of only a typically 100uSec, and is often faster than this. What suppression is immediately adjacent to the chip?. Are you _sure_ that you are looking at the voltages on the pins themselves?. Remember also the voltage only has to fall to 4.35v (depending on the tolerance of the chip), for it to trigger.
The fact that turning the brownout off, makes it work, says that the the chip _is_ receiving something to trigger the event. Something silly, like a resistive ground connection to the chip itself, so it's 0v rail is rising, would be a typical 'cause'.
Best Wishes |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Dec 13, 2006 10:48 am |
|
|
| Quote: |
But, if the problem is with the brownout reset, what if I turn this option
down? Result: it works perfectly. It reads the temperature and sends to
the computer without mistakes, and one per second, as is in the code
above.
Any suggestion for what could be hapenning? |
The Brownout reset voltage for the 16F819 can be as high as 4.35 volts.
If your +5v supply is drooping because of excessive current load and
high impedance connections to the PIC (ie., lightweight 30 AWG wires)
then you could get a brownout reset.
1. What is the source of the +5v for your board ? Is a voltage regulator,
or a bench power supply, or batteries ? Please describe it in detail.
2. Measure the +5v with a digital voltmeter. What does it show ?
3. Do you have a 0.1 uF (100 nF) capacitor on the Vdd pin of the PIC,
with the other side going to ground ? Is this capacitor placed very
close to the pin, with very short leads ?
4. Do you have a bulk capacitor of at least 10 uF at the point where
power enters the board (either from a voltage regulator or bench
power supply).
5. How is this board constructed ? Is it a printed circuit board, or
a 3M breadboard with jumper wires, or something else ?
Do you have short, heavy wires that bring power to your board ?
(I see I've duplicated many items in Ttelmah's post above. But I was
interrupted for a few minutes while I was typing this in, so I didn't see
his post before I posted this). |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Dec 13, 2006 3:55 pm |
|
|
Stereo is good.
Quadraphonic can get a bit 'OTT', but has happened here before!.
It is usually me, who has 90% typed a post, then gets interrupted, posts it, and realises that someone else has already posted. 
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
