Searching \ for '[PIC]: DS1820 problem' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'DS1820 problem'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: DS1820 problem'
2004\08\18@092334 by Michel Meunier

flavicon
face
Hello,

excuse-me to disturb you, but I am working on a system to manage the
temperature of  a CCD camera (Audine), but we have a problem with the
DS1820 sensor.
We read the temperature (in fact 8 bytes), next the CRC byte. But 10% of
the time the CRC is bad. It's seem that a bit is read as 1, but it must
be read as 0. We have a pull-up resistor of 4.7k between the +5v and the
data line. We have made test with a PIC controller and we have used two
different compiler (picc and pic-basic). I have also tried to weld the
sensor just on the pins of the pic to avoid distorsion (but the problem
is the same).
So this problem is not the most important, because when we have a bad
CRC, we read again. But after a while (between 5min and 1 hour),  the
temperature send is allways the same, the CRC is OK, but we know that
it's not the good temperature, for example 40C with ice on the CCD chip!!!
If you have an idea, tell it to me.

Thank you

Best regards

Michel Meunier

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu

2004\08\18@092958 by Dave VanHorn

flavicon
face
Have you read the other thread on 1820 accuracy?

It seems you would be well advised to use a different approach.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu

2004\08\18@095331 by Michel Meunier

flavicon
face
Dave VanHorn a icrit :

>Have you read the other thread on 1820 accuracy?
>
>
Yes, but I haven't found the solution.

>It seems you would be well advised to use a different approach.
>
>--
>http://www.piclist.com hint: To leave the PICList
>piclist-unsubscribe-requestspamKILLspammitvma.mit.edu
>
>
>

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu

2004\08\18@095539 by ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
> excuse-me to disturb you, but I am working on a system to manage the
> temperature of  a CCD camera (Audine), but we have a problem with the
> DS1820 sensor.
> We read the temperature (in fact 8 bytes), next the CRC byte. But 10% of
> the time the CRC is bad. It's seem that a bit is read as 1, but it must
> be read as 0. We have a pull-up resistor of 4.7k between the +5v and the
> data line. We have made test with a PIC controller and we have used two
> different compiler (picc and pic-basic). I have also tried to weld the
> sensor just on the pins of the pic to avoid distorsion (but the problem
> is the same).
> So this problem is not the most important, because when we have a bad
> CRC, we read again. But after a while (between 5min and 1 hour),  the
> temperature send is allways the same, the CRC is OK, but we know that
> it's not the good temperature, for example 40C with ice on the CCD chip!!!
> If you have an idea, tell it to me.

If the temperature is always the same it could be that, for some reason, the temperature sampling is never done, that is - the sensor doesn't execute the CONVERT_T command. When the sensor is powered with +V5 (not parasitic power) you can check that the sensor is indeed doing a conversion (by issuing read-
time slots and verify that it is transmitting 0 while conversion is in progress). If it is powered with parasitic power You should be able to see on the data line that the voltage is lowered some 10ths of mV due to the increase of current.

Have you verified that the read and write timing is OK? I have equipment reading this type of sensor all the time but I very seldom (never) get any CRC errors while reading the scratchpad.


>
> Thank you
>
> Best regards
>
> Michel Meunier

Regards / Ruben==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
EraseMErubenspam_OUTspamTakeThisOuTpp.sbbs.se
==============================

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu

2004\08\18@105420 by Michel Meunier

flavicon
face
part 0 44 bytes
his is a multi-part message in MIME format.
part 1 3099 bytes content-type:text/plain; charset=ISO-8859-1; format=flowed (unknown type 8bit not decoded)

Ruben Jvnsson a icrit :

{Quote hidden}

Good idea!

> When the
>sensor is powered with +V5 (not parasitic power) you can check
>that the sensor is indeed doing a conversion (by issuing read-
>time slots and verify that it is transmitting 0 while
>conversion is in progress).
>
It's a problem I have noticed, in a test program, I send a character
just after the order of conversion have been send, and a new one just
when read-time slot = 1. With a sniffer on RS232 port, i have seen about
2ms only between theses two characters.

> If it is powered with parasitic
>power You should be able to see on the data line that the
>voltage is lowered some 10ths of mV due to the increase of
>current.
>
>Have you verified that the read and write timing is OK? I have
>equipment reading this type of sensor all the time but I very
>seldom (never) get any CRC errors while reading the scratchpad.
>
>
In the program with picc, the routines are included, and timing seems
ok. Perhaps the pull-up resistor is to strong (4.7k).
I have joined my small test program. About 1/20 up to 1/10 of my rom
readings have a bad CRC, and it's allways a bit wich is 1 and must have
been 0.

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu




part 2 3926 bytes content-type:text/plain;
(decoded 7bit)

/////////////////////////////////////////////////////////////////
//                                                             //
//                AlAudine                                     //
//       Version devant marcher correctement a la place        //
//       de celle d'origine                                    //
//                                                             //
/////////////////////////////////////////////////////////////////

//    Version 0.03

/////////////////////////////////////////////////////////////////
//
//    0.01, on commence avec les inits de variables
//    0.02  gestion LCD perso (derive de celui de base)
//    0.03  lecture du capteur de temperature

/////////////////////////////////////////////////////////////////
// #define debogage

#include "D:\Astro\AlAudine\Test en C\Alaudine.h"
#include "D:\Astro\AlAudine\Test en C\TOUCH.C"
// #include <TOUCH.C>
#include "D:\Astro\AlAudine\Test en C\CRC.C"


#use fast_io(B)
#use fast_io(A)

#define OW0    PIN_B0
#define OW1    PIN_B1
#define MST    PIN_B2
#define PWRLCD PIN_B3
#define PLUS   PIN_B4
#define MOINS  PIN_B5
#define MENU   PIN_B6
#define MARCHE PIN_B7

#define LIGHTLCD  PIN_C1
#define PELTIER   PIN_C2
#use rs232(baud=38400, xmit=PIN_C6, rcv=PIN_C7)

#ORG 0x1E00,0x1FFF
RESERVE()
{
}

int16 peltier_duty=0;
int16 lcd_duty=0;

void init() {
  port_b_pullups(TRUE);
  setup_adc_ports( NO_ANALOGS );
  set_tris_a(0b000000);
  output_a(0);
  set_tris_b(0b11110000);
  output_low(MST);
  output_low(PWRLCD);
  set_tris_c(0b11011001);
  output_high(PELTIER);
  setup_ccp1(CCP_PWM);   // Configure CCP1 as a PWM, it's peltier
  setup_ccp2(CCP_PWM);   // Configure CCP2 as a PWM, it's LCD light
  setup_timer_2(T2_DIV_BY_1, 255, 1);

  set_pwm1_duty(peltier_duty);
  set_pwm2_duty(lcd_duty);
//   setup_counters(RTCC_INTERNAL,RTCC_DIV_16);
//   setup_timer_1(T1_DISABLED);
//   setup_timer_2(T2_DISABLED,0,1);
}

int16 read_tempe()
{
  int i,crc,crc_calcul,entiere,virgule;
  int t[9];
  int16 result;
  if (touch_present()==TRUE){
     delay_ms(10);
     i=touch_write_byte(SKIPROM);
     delay_ms(10);
     i=touch_write_byte(CONVERT);
//      delay_ms(800);
  }
  else
     return(10000);
  if (touch_present()==TRUE){
     i=touch_write_byte(SKIPROM);
     delay_ms(10);
     i=touch_write_byte(READSCRA);
     delay_ms(10);
     for (i=0;i<9;i++) {
     t[i]=touch_read_byte();
     delay_ms(10);
     }
     i=touch_write_byte(SKIPROM);
     delay_ms(10);
     i=touch_write_byte(READSCRA);
     delay_ms(10);
     for (i=0;i<9;i++) {
     t[i]=touch_read_byte() & t[i];
     delay_ms(10);
     }
     crc=t[8];
     crc_calcul=generate_8bit_crc(t,8);
  }
  else
  {
     printf("oups \n\r");
     return(10000);
  }
  for (i=0;i<8;i++) printf("%u ",t[i]);
  printf("%u ",crc);
  printf("%u ",crc_calcul);
  result=((MAKE16(t[1],t[0]&0xFE)) << 3)-4+16-t[6];

  if (BIT_TEST(result,15)==0) {
     entiere=result>>4;
     virgule=((result & 0x000F)*5+4)>>3;
     printf("+%u.",entiere);
  }
  else {
     entiere=((result-1)>>4) ^ 0xFFFF;
     virgule=(10-(((result & 0x000F)*5+4)>>3)) % 10;
     printf("-%u.",entiere);
  }
  printf("%u ",virgule);

  if (crc==crc_calcul) printf("OK\n\r");
  else printf("NO\n\r");
//   delay_ms(2000);
  return(result);
}

void main()
{
  int16 tempe;
  int p;
  init();
#ifndef debogage
  while  (input(MARCHE)); // waits for MARCHE to be press
#endif
  output_high(MST);
  delay_ms(1000);
  output_high(PWRLCD);
  output_high(LIGHTLCD);
  while (TRUE) tempe=read_tempe();
}

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu




part 3 1126 bytes content-type:text/plain;
(decoded 7bit)

[PROJECT]
Target=Alaudine.HEX
Development_Mode=
Processor=0x876F
ToolSuite=CCS

[Directories]
Include=D:\Program Files\PICC\devices\;D:\Program Files\PICC\dr
Library=
LinkerScript=

[Target Data]
FileList=Alaudine.c;
BuildTool=C-COMPILER
OptionString=+FM
AdditionalOptionString=
BuildRequired=1

[Alaudine.c]
Type=4
Path=
FileList=
BuildTool=
OptionString=
AdditionalOptionString=

[mru-list]
1=Alaudine.c

[Windows]
0=0000 Alaudine.c 0 0 796 451 3 0

[Opened Files]
1=D:\Astro\AlAudine\Test en C\Alaudine.c
2=D:\Astro\AlAudine\Test en C\Alaudine.h
3=D:\Astro\AlAudine\Ca marche\Alaudine.lst
4=D:\Astro\AlAudine\Test en C\TOUCH.C
5=
6=D:\Astro\AlAudine\Ca marche\TOUCH.C
7=D:\Astro\AlAudine\Ca marche\crc.c
8=
9=
[debugperif]
selected=Analog/Digital Conv
[debugram]
autoread=1
[debugeedata]
autoread=1
[debugbreak]
count=1
f1=D:\Astro\AlAudine\CRC\crc.c
l1=19
[pcwdebug]
watchcol0=75
[debugwatch]
count=5
e1=data_bit
e2=fb
e3=prov
e4=i
e5=result
[debugexpr]
expr=result
sideeffects=0

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu




part 4 739 bytes content-type:text/plain;
(decoded 7bit)

int generate_8bit_crc(int* data, int length)
{
  int   *current_data;
  int   crc_byte;
  int   byte_counter;
  int   bit_counter;
  byte  fb;
  byte  data_bit;

  current_data = data;
  crc_byte = 0;
  for(byte_counter=0; byte_counter < length; byte_counter++)
  {
     for(bit_counter=0; bit_counter < 8; bit_counter++)
     {
        data_bit=(*current_data>>bit_counter) & 0x01; // next bit
        fb=(crc_byte & 0x01) ^ data_bit;
        crc_byte >>= 1;
        if (fb==1) crc_byte ^= 0x8C;
     }
     current_data++;
  }
  return crc_byte;
}


--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu




part 5 3060 bytes content-type:text/plain; (decode)

2004\08\18@125347 by Michel Meunier

flavicon
face
Hello,

I have perhaps an explaination, I have seen that our program activate
the internal pull-up of the PIC. We have also an external resitor of
4.7k for the pull up. Perhaps it's too much??

Michel

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu

2004\08\18@131630 by ?ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
Hello,

> In the program with picc, the routines are included, and timing seems
> ok. Perhaps the pull-up resistor is to strong (4.7k). I have joined my
> small test program. About 1/20 up to 1/10 of my rom readings have a
> bad CRC, and it's allways a bit wich is 1 and must have been 0.
>

Do You have any interrupts that can extend the
delays. If You read one bit and it is a 0 and your
delays are too long (due to an interrupt for example)
you will read a 1.

Also some notes on your code:


{Quote hidden}

You send a reset (touch_present) right after you
issue the CONVERT_T command if the delay_ms(800) is
commented out.


{Quote hidden}

Why do you (attempt) to read the scratchpad twice and
AND the two results together? The CRC in itself is
enough to do error checking. Also You send two
commands right after each other without having done a
reset in between.

Try removing the second read and put back the 800 ms
delay after the CONVERT_T command.

The delay_ms(10) is not needed between the bytes.

4.7k pullup is good. The internal pull up should not
matter.

Good Luck / Ruben
==============================
Ruben Jvnsson
AB Liros Elektronik
Box 9124, 200 39 Malmv, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
EraseMErubenspampp.sbbs.se
==============================

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu

2004\08\18@132502 by ?ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
One more note:

>    if (touch_present()==TRUE)

Never do a compare to TRUE. TRUE is most likely
defined to 1 while any non zero number is TRUE.

Just do:

if (touch_present())

instead. And:

if (!touch_present())

to compare to FALSE.

Regards / Ruben




==============================
Ruben Jvnsson
AB Liros Elektronik
Box 9124, 200 39 Malmv, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
RemoveMErubenspam_OUTspamKILLspampp.sbbs.se
==============================

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu

2004\08\20@070712 by Michel Meunier

flavicon
face
Thank you for all your helps.
I have work hard, and now with the test program in C, I have no more bad
CRC.
But there are allways bad CRC with the program in Pic Basic.
As the picbasic program use interrupt (because the PIC use I2C as
slave), it'seems that theses interrupts are bad for the DS1820 reading.
The only way I see to solve the problem, is to use GIE=0 just before any
use of OWIN and OWOUT commands.
Have you already seen a program wich use interrupts and DS1820?

Best regards

Michel

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\21@140132 by ?ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
> Thank you for all your helps.
> I have work hard, and now with the test program in C, I have no more
> bad CRC. But there are allways bad CRC with the program in Pic Basic.
> As the picbasic program use interrupt (because the PIC use I2C as
> slave), it'seems that theses interrupts are bad for the DS1820
> reading. The only way I see to solve the problem, is to use GIE=0 just
> before any use of OWIN and OWOUT commands. Have you already seen a
> program wich use interrupts and DS1820?

I have used it with periodical timer interrupts in
the background (virtual peripherials on SX
processor). I solved it by checking the timer
register manually, and if there was time to do the
ow-bit-operation it was done right away, otherwise I
waited until the interrupt just had executed.

This wouldn't work when using the PIC as an I2C slave
though (is it really a slave and not a master talking
to a slave?).

One option might be to either move the ow-bit-
operation to a timer interrupt instead of doing it in
the main thread or, as you say, block interrupts with
GIE. Still, You will need to obey the strict timing
of the one-wire interface, at least for one single
bit which will take up to 60us (writing a 0 time
slot). Perhaps the I2C can't handle that, I don't
know.

In my current project I have used two 12F629s as
slaves for a HCS12 processor, each driving 2 one-wire
channels. One reason for this is to keep the main
HCS12 processor from worrying about timings in the
one-wire communication (there are no interrupts in
the 12F629 but lot's in the HCS12).

Regards / Ruben
==============================
Ruben Jvnsson
AB Liros Elektronik
Box 9124, 200 39 Malmv, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
EraseMErubenspamspamspamBeGonepp.sbbs.se
==============================

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\21@140755 by Dave VanHorn

flavicon
face
>
>In my current project I have used two 12F629s as
>slaves for a HCS12 processor, each driving 2 one-wire
>channels. One reason for this is to keep the main
>HCS12 processor from worrying about timings in the
>one-wire communication (there are no interrupts in
>the 12F629 but lot's in the HCS12).

A good approach.
The one-wire concept was good, but those 10's of uS delays are becoming increasingly more expensive, as they are too fast to release the task.. Clocked serial is a lot easier to deal with.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...