The post above is wrong and that means I must go to sleep. If a single reading is good, it will leave the loop :-P. Ok, good night to everyone on this part of the world!
Vasi On Dec 15, 2:35 am, "funlw65(Vasi)" <[email protected]> wrote: > But you can have max_crc_errors - 1 good readings and the > max_crc_errors a bad one and it will be reported as defective wire or > sensor... well, I tried to save a byte but is not possible... I will > rethink the algorithm and.. if someone can have a solution, it is my > guest, thank you. > > On Dec 15, 2:20 am, "funlw65(Vasi)" <[email protected]> wrote: > > > 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.
