procedure s_temp_18B20_CRC(byte out inches, byte out fraction, bit out
signed, byte in max_crc_errors) is
--
var byte tmp[2] at temperature
var volatile bit tmp_1_7 shared at tmp[1] : 7
var byte i = 0
signed = 0
repeat
skip_rom_18B20
d1w_write_byte(0xBE)
read_18B20_with_CRC(9)
tmp[0] = scratchpad[0]
tmp[1] = scratchpad[1]
i = i + 1
if ((i == max_crc_errors) & (GOOD_crc == 1)) then
exit loop
end if
until GOOD_crc == 0
if (tmp_1_7 == 1) then
signed = 1
end if
inches = tmp[1]<<4 | tmp[0]>>4
fraction = byte((tmp[0] & 0x0F)* word(625)/1000)
end procedure
procedure temp_18B20_CRC(byte out inches, byte out fraction, bit out
signed, byte in max_crc_errors) is
--
var byte tmp[2] at temperature
var volatile bit tmp_1_7 shared at tmp[1] : 7
var byte i = 0
signed = 0
repeat
match_rom_18B20
send_ID_18B20
d1w_write_byte(0xBE)
read_18B20_with_CRC(9)
tmp[0] = scratchpad[0]
tmp[1] = scratchpad[1]
i = i + 1
if ((i == max_crc_errors) & (GOOD_crc == 1)) then
exit loop
end if
until GOOD_crc == 0
if (tmp_1_7 == 1) then
signed = 1
end if
inches = tmp[1]<<4 | tmp[0]>>4
fraction = byte((tmp[0] & 0x0F)* word(625)/1000)
end procedure
On Dec 15, 12:38 am, "funlw65(Vasi)" <[email protected]> wrote:
> Personally, I can solve this in a quick way:
> - putting "maximum_CRC_errors" as a parameter and let users define
> what is the maximum.
> But which will be that number? 5, 10, 15? What number a newbie will
> chose? Based on what?
> This is why I'm asking experts :) .
>
> This is how I understand the thing:
> I suppose a cable in a normal environment, will behave as in case
> number one, described by Marchaudon. The worse environment will be,
> the more and frequent failures you will have. So, choosing the right
> number of maximum failures in line (one after another) depends on
> environment and you can judge the environment only making tests in
> that environment. So, I propose that this variable to be a parameter
> to those last procedures inside library.
>
> It is right? It is good to have such functions inside the library, or
> their place is inside user application? If is inside a library, then
> is handy for everyone. If not, then it must be in an included sample
> program to avoid reinventing the wheel.
>
> Vasi
>
> On Dec 15, 12:15 am, "funlw65(Vasi)" <[email protected]> wrote:
>
> > Hi Kiste,
>
> > Both things you request are in library. The readable temperature
> > (Celsius) and a global flag about the status of CRC.
>
> > The problem is inside those procedures which gives you the readable
> > temperature. Is there a loop where you read the temperature with CRC.
> > You can leave that loop only if a good CRC happened. So, you need a
> > protection against freezing your program.
>
> > Now, we have two notable cases here:
>
> > 1. The case of Marchaudon. He used 5 temp. sensors on a 20meters three
> > wire cable 10 years without a single problem. In this case, a bad CRC
> > can happen at every 5 readings so, you will not be stuck inside
> > library.
>
> > 2. The case of Vasile where the cable had an increased electrical
> > resistance because of heat. There problems were solved only rerouting
> > the cable (so, you can get stuck inside that loop in library).
>
> > Now, my question was, what is the maximum acceptable number of cycles?
> > How many bad CRC's we can receive in line (one after another) before
> > we can declare that the cable (or sensor) have problems? So, you must
> > be secured against such a case because you also must take care of
> > other sensors and tasks.
>
> > Vasi
>
> > On Dec 14, 10:14 pm, Oliver Seitz <[email protected]> wrote:
>
> > > > But, again, how many cycles to
> > > > consider as maximum?
>
> > > I haven't had a look at the lib yet, perhaps this fits badly... But how
> > > about giving the read temperature, abd a flag if the CRC was ok? The lib
> > > user can then decide in his program what to do with that.
>
> > > Greets,
> > > Kiste
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en.
