Hi Joep, On Jan 13, 7:12 pm, Joep Suijs <[email protected]> wrote: > Hi Vasi, > > Can you confirm that thermometer.jal is intended for a single device > on the 1wire bus and thermometer2.jal potentially supports more > devices?
Yes, this is correct. > If so, it is probably best to start a test file with thermometer that > shows the use of all the relevant functions of the lib. There are > quite a few procedures and there function is 'quite briefly' > documented and not shown in the samples. And the ones that are used, > have no explanation (in contrast to the lcd use ;). So some work to > do. > All functions that start with s_ prefix are intended for an unique device on wire. You can change the prefix with u_ if you find it more appropriate (you can change the name of all procedures and add another ones if you want). These three functions are as in datasheet, "primitive commands" to work with the device: procedure match_rom_18B20 procedure skip_rom_18B20 procedure convert_18B20 This procedure is sending the sensor ID: procedure send_ID_18B20 This procedure read either ID or scratchpad of sensor and verify the CRC: procedure read_18B20_with_CRC( byte in nbre_byte ) This procedure reads the ID of a unique device. The opposite function, will be one for scanning "an entire wire of sensors" but is not present as I didn't needed nor I see it practical - but you can make it, of course: procedure s_read_rom_18B20 These two procedures read directly the raw value (word) of temperature. They goes exactly at the required index in scratchpad to read the two bytes. After that you can convert to Celsius or Faraday (for unique device or multiple): procedure raw_temp_18B20(byte out h, byte out l ) procedure s_raw_temp_18B20(byte out h, byte out l ) These two procedures read the temperature WITHOUT CRC and convert it to Celsius (for both unique and mutliple): procedure temp_18B20(byte out inches, byte out fraction, bit out signed) procedure s_temp_18B20(byte out inches, byte out fraction, bit out signed) These two procedures read the temperature using CRC and convert it to Celsius - here you need that retry variable max_crc_errors: procedure temp_18B20_CRC(byte out inches, byte out fraction, bit out signed, byte in max_crc_errors) procedure s_temp_18B20_CRC(byte out inches, byte out fraction, bit out signed, byte in max_crc_errors) Faraday procedures are missing and must be added. > An other thing is the parameter max_crc_errors. I think this is the > maximum number of retries. Correct? Yes > Such a parameter suggests crc errors are quite common. How often do > you get CRC errors? None errors on a development board, one error from five readings in a normal environment, or error at every reading in a very bad environment (the program freezed) > Also, does it make sense to pass this as a > parameter? If it is a fixed value, we could add a constant. But when > there is a limited number of retries, there remains a chance that get > invalid reading back. No, can't get an invalid read out of the "celsius" functions. It will continue to read the sensor until the CRC is ok, or number of retries are meet. The number of retries can be chosen regarding to the environment in question. It can be set only "in field". Read back the topic, I said in the examples if I get 5 wrong readings in line, in a normal environment, then something is wrong for sure. > And how would you act upon this? Going along the wire to see where is the problem. > Maybe it makes > more sense to have a constant that either says unlimited retries or no > (automatic) retries at all, but return a succes indicator. If your > program has to handle the error, it will probably has some retry > mechanism anyway. Or do I miss something? See above. > > Once the first test-file is done, it would be good to create a second > one to show the use of multiple devices on the bus. Are you able to > create a program (like termometer2) which works with two (or more) > devices on the same bus? Does the library support discovery of devices > on such a bus or should one first determine the ID of each device when > they are alone? In his library-example (ds1822_1_wire.jal), Bert have a procedure for selecting one of the 5 sensors. The procedure gets a byte as parameter (a value between 1 and 5) and and one of the five IDs of the temperature sensors is loaded in the array. These IDs can be "stored" inside the program (as Bert is doing), or in EEPROM (internal or external) and can be better presented in a tutorial or two.. And, without real sensors, you can only present a mechanism, without the ability to check it (even if you know it is working) - I have only one sensor. . Yes, somewhere is presented a mechanism of scanning and reading all the IDs from the wire, one by one but then you still need to address them separately. So, in practice, you don't start planting sensors along the wire without knowing how to identify them. The "standard" procedure is to read them one by one and mark them with a label. So, the first example is doing exactly that: reading the ID and showing the temperature for test. > > Joep > > 2011/1/13 Joep Suijs <[email protected]>: > > > Hi Vasi, > > > I start working on it but had not much time. With a bit of luck, I can > > spend a few hours tonight and probably send you some questions. > > For now, I am okay ;) > > > Joep > > > 2011/1/13 funlw65(Vasi) <[email protected]>: > >> I don't compiled using SVN version. > >> For the file 18f2550_ds18b20_therm.jal I have: > > >> jal 2.4n (compiled Jun 2 2010) > >> 0 errors, 0 warnings > >> Code area: 2294 of 32768 used (bytes) > >> Data area: 81 of 928 used > >> Software stack available: 847 bytes > >> Hardware stack depth 5 of 31 > > >> and for the file 18f2550_ds18b20_therm2.jal I have: > >> jal 2.4n (compiled Jun 2 2010) > >> 0 errors, 0 warnings > >> Code area: 2104 of 32768 used (bytes) > >> Data area: 80 of 928 used > >> Software stack available: 848 bytes > >> Hardware stack depth 5 of 31 > > >> On Jan 13, 11:03 am, "funlw65(Vasi)" <[email protected]> wrote: > >>> Hi Joep, > > >>> I think I did not touched 1_wire.jal, is as it is from Bert package... > > >>> I compared them with Winmerge: I added a line in comments and better > >>> arranged two if structure, without touching the code logic. > > >>> Vasi > > >>> On Jan 12, 6:04 pm, Joep Suijs <[email protected]> wrote: > > >>> > Vasi, > > >>> > If fixed part of the problem: the garbage in the files came either > >>> > from gmail or Microsoft :( > >>> > Only the pragma issue remains. I don't understand why, but this is not > >>> > relevant since I'll move it to a board file anyway. > >>> > Just to be certain: I have the 18-8 version of 1wire.jal. Is this the > >>> > correct one? > > >>> > Thanks, > >>> > Joep > > >>> > 2011/1/12 Joep Suijs <[email protected]>: > > >>> > > Hi Vasi, > > >>> > > In your 15-12 version, 1_wire.jal is missing. When I grab the one you > >>> > > original posted and try to compile it I get: > > >>> > > jal 2.4n (compiled Jun 2 2010) > >>> > > generating p-code > >>> > > 18f2550_ds18b20_therm2.jal:17: unknown pragma target: voltage pragma > >>> > > 18f2550_ds18b20_therm2.jal:21: unknown pragma target: ccp2mux pragma > >>> > > 1_wire.jal:95: "x" not defined > >>> > > 1_wire.jal:96: unexpected token: "end" > >>> > >ds18b20.jal:248: "t" not defined > >>> > >ds18b20.jal:248: unexpected token: "t" > >>> > > 18f2550_ds18b20_therm2.jal:134: unexpected token: ""e"" > >>> > > 7 errors, 0 warnings > > >>> > > It seems that all three files have issue's. E.g. in the crc routine of > >>> > >ds18b20, line 248 is "t tmp_1_7 shared at tmp[1] : 7", which is not > >>> > > valid JAL. Also there are some fuse-related messages. > >>> > > Are you compiling against the svn version of jallib? And can you post > >>> > > a compilable set of files? > > >>> > > Thanks, > >>> > > Joep > >>> > > 2011/1/12 funlw65(Vasi) <[email protected]>: > >>> > >> Can't wait to see the result :) > > >>> > >> On Jan 12, 9:30 am, Joep Suijs <[email protected]> wrote: > >>> > >>> Hi Vasi, > > >>> > >>> Thanks for you work. I will start working on this library set (I > >>> > >>> have > >>> > >>> the chips now ;) > > >>> > >>> Joep > > >>> > >>> 2011/1/11 funlw65(Vasi) <[email protected]>: > > >>> > >>> > Thank you very much. > >>> > >>> > Joep, all three authors agree with the change of license for > >>> > >>> > inclusion > >>> > >>> > in Jallib. > > >>> > >>> > Vasi > > >>> > >>> > On Jan 11, 11:07 pm, "jfm68" <[email protected]> wrote: > >>> > >>> >> hi, > > >>> > >>> >> for me, it's ok . > >>> > >>> >> this part my work is completely free, you can use and reuse it. > > >>> > >>> >> jean Marchaudon > > >>> > >>> >> ----- Original Message ----- > >>> > >>> >> From: "funlw65(Vasi)" <[email protected]> > >>> > >>> >> To: "jallib" <[email protected]> > >>> > >>> >> Sent: Tuesday, January 11, 2011 9:41 AM > >>> > >>> >> Subject: [jallib] Re: One wire library > > >>> > >>> >> Ok, I will contact them. > > >>> > >>> >> On Jan 11, 9:32 am, Joep Suijs <[email protected]> wrote: > >>> > >>> >> > Hi Vasi, > > >>> > >>> >> > > If I remember well, Marchaudon said it > >>> > >>> >> > > is ok. Remains Vasile and Bert. > > >>> > >>> >> > To change the license, I'd like to have the conformation from > >>> > >>> >> > all > >>> > >>> >> > three. Will you look into this? > >>> > >>> >> > The license need to be changed to add the library to jallib. > > >>> > >>> >> > Joep > > >>> > >>> >> -- > >>> > >>> >> 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 > >>> > >>> >> athttp://groups.google.com/group/jallib?hl=en. > > >>> > >>> > -- > >>> > >>> > 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 > >>> > >>> > athttp://groups.google.com/group/jallib?hl=en. > > >>> > >> -- > >>> > >> 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 > >>> > >> athttp://groups.google.com/group/jallib?hl=en. > > >> -- > >> 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 > >> athttp://groups.google.com/group/jallib?hl=en. -- 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.
