One wire library
vasi vasi
but lots of warnings. Here is also a "disabled" sensor config.range and resolution function , not tested - needs advices from experts. All functions which start with "s_" are for a unique device on bus - others require the ID for access a sensor on multiple sensors on bus.First example (thermometer.jal and an image included) is reading a unique device on 1wire bus and the second is reading the device on a multi. sensor bus, using the ID discovered in first example.
Maybe is useful in taking some decisions about this (new and general libraries, samples, etc...)
--
Vasi
Joep Suijs
2010/8/18 vasi vasi <fun...@gmail.com>
>
> We don't have yet a 1wire library and I needed it for a DS18B20 temperature sensor.
> But I found one written by Vasile and adapted by Jean Marchaudon, included in
> Bert van Dam package. Is there a reason why not including it in Jallib?
Probably because no-one has spent the effort required. IMO it would be
good to have it. It is good to see there is a distinct between the
1-wire part and the device part. Like i2c, a well-designed interface
for the 1wire interface is important for future expansion with 1wire
devices.
Joep
vasile surducan
--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
funlw65(Vasi)
Not tested it yet but I will! do it tomorrow - pentru ca azi mai am de
taiat niste lemne cu drujba :-D
On Dec 13, 9:12 am, vasile surducan <vsurdu...@gmail.com> wrote:
> Hi Vasi,
>
> I'm just curious, this library works Ok with negative temperatures too?
>
> thx,
> Vasile
>
> > We don't have yet a 1wire library and I needed it for a DS18B20 temperature
> > sensor. But I found one written by Vasile and adapted by Jean Marchaudon,
> > included in Bert van Dam package. Is there a reason why not including it in
> > Jallib? For a DS18B20 library, I did one (not really necessarily) looking at
> > And-Tech.pl samples for their EvB 4.3 board and at Bert library,
> > tested - needs advices from experts. All functions which start with "s_"
> > are for a unique device on bus - others require the ID for access a sensor
> > on multiple sensors on bus.
> > First example (thermometer.jal and an image included) is reading a unique
> > device on 1wire bus and the second is reading the device on a multi. sensor
> > bus, using the ID discovered in first example.
> > Maybe is useful in taking some decisions about this (new and general
> > libraries, samples, etc...)
> > --
> > Vasi
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "jallib" group.
> > To post to this group, send email to jal...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
> 330.png
> < 1KViewDownload
vasile surducan
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
funlw65(Vasi)
do it... if there is not another source...
Vasi.
On Dec 13, 1:51 pm, vasile surducan <vsurdu...@gmail.com> wrote:
> OK, apai nu cred c-o sa mearga...because you didn't computed the two's
> complement for negative temperature display.
>
> Vasile
>
funlw65(Vasi)
from your library :)
Vasi
vasile surducan
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
funlw65(Vasi)
assembler?
I really need to find some time to learn assembler. I did once for
Z80, but I had the required book... don't have it anymore...
On Dec 13, 2:04 pm, vasile surducan <vsurdu...@gmail.com> wrote:
> if sign == high then ; negative temperatures
> assembler
> comf t_lsb,f ;complement all two bytes
> comf t_msb,f
>
> incf t_lsb,f ;inc. low byte always
> skpnz ;skip if no carry to higher bytes
> incf t_msb,f ;carry to next byte
> end assembler
> end if
>
> Maybe you translate this in jal, as word is producing too long code...
>
> Vasile
>
> > <jallib%252Buns...@googlegroups.com<jallib%25252Bun...@googlegroups.com>
vasile surducan
Thank you for solution. You mean, JAL is more efficient than
assembler?
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
jfm jfm
my source is since long time in :
http://tech.groups.yahoo.com/group/jallist/files/DS1820%20with%20CRC%20%2B%20USB%20BOOT%2018F/
no negatif temp but check crc.
i'm happy you can use it.
jean Marchaudon
>
> > > > <jallib%2Bunsu...@googlegroups.com<jallib%252Bunsubscribe@googlegroups.com>
> > <jallib%252Buns...@googlegroups.com<jallib%25252Bunsubscribe@googlegroups.com>
> > > > > > .
> > > > > > For more options, visit this group at
> > > > > >http://groups.google.com/group/jallib?hl=en.
>
> > > > > 330.png
> > > > > < 1KViewDownload
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "jallib" group.
> > > > To post to this group, send email to jal...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > jallib+un...@googlegroups.com<jallib%2Bunsu...@googlegroups.com>
> > > > .
> > > > For more options, visit this group at
> > > >http://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 jal...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jallib+un...@googlegroups.com<jallib%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
>
> - Show quoted text -
funlw65(Vasi)
Vasi
> my source is since long time in :http://tech.groups.yahoo.com/group/jallist/files/DS1820%20with%20CRC%...
funlw65(Vasi)
int16_t rawTemperature = (((int16_t)scratchPad[TEMP_MSB]) << 8) |
scratchPad[TEMP_LSB];
Is used a signed word.
Look at examples, I think library support also negative temperatures.
The temperature is computed later, in another procedure and a sign is
detected...
For an unique sensor on wire:
procedure s_temp_18B20(byte out inches, byte out fraction, bit out
signed)
procedure s_temp_18B20_CRC(byte out inches, byte out fraction, bit out
signed) is
For multiple sensors:
procedure temp_18B20(byte out inches, byte out fraction, bit out
signed) is
procedure temp_18B20_CRC(byte out inches, byte out fraction, bit out
signed) is
Vasi
On Dec 13, 2:17 pm, vasile surducan <vsurdu...@gmail.com> wrote:
> > Thank you for solution. You mean, JAL is more efficient than
> > assembler?
>
> > <jallib%252Buns...@googlegroups.com<jallib%25252Bun...@googlegroups.com>
>
> > > > <jallib%252Buns...@googlegroups.com<jallib%25252Bun...@googlegroups.com>
> > <jallib%25252Bun...@googlegroups.com<jallib%2525252Bu...@googlegroups.com>
> < 1KViewDownload
funlw65(Vasi)
They wrote them on C (and Bascom) for their board, EvB4.3. Others are
from you (1Wire library), Marchaudon and Bert. The library require
also a sensor setup procedure (there is one but disabled - not tested)
and it needs more testing also form others (for me is working well).
And because we are in winter, we can easily test the negative
values :)
I don't know if procedure names are chosen well, but for this I think
jallib team can decide and adapt.
vasile surducan
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
vasile surducan
The raw temperature on Arduino library is computed like this:
int16_t rawTemperature = (((int16_t)scratchPad[TEMP_MSB]) << 8) |
scratchPad[TEMP_LSB];
Is used a signed word.
Look at examples, I think library support also negative temperatures.
The temperature is computed later, in another procedure and a sign is
detected...
For an unique sensor on wire:
procedure s_temp_18B20(byte out inches, byte out fraction, bit out
signed)
procedure s_temp_18B20_CRC(byte out inches, byte out fraction, bit out
signed) is
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
funlw65(Vasi)
Unfortunately I don't have a second sensor :) to be able to test.
The last two procedures (better be functions) with CRC must be
rewritten to check if the CRC (GOOD_crc variable) is OK or not - and
the examples too.
Vasi
> > <jallib%25252Bun...@googlegroups.com<jallib%2525252Bu...@googlegroups.com>
>
> > > > <jallib%25252Bun...@googlegroups.com<jallib%2525252Bu...@googlegroups.com>
> > <jallib%2525252Bu...@googlegroups.com<jallib%252525252B...@googlegroups.com>
funlw65(Vasi)
in the last two procedures from the library, the reading continue in a
loop until GOOD_crc will be zero (a good reading). What if no reading
will return a good one? How many times we can afford to cycle in that
loop? Here experience is needed and I don't have it yet.
The procedures can remain procedures and we can test the GOOD_crc
variable status also in the testing programs.
Vasi
> > <jallib%25252Bun...@googlegroups.com<jallib%2525252Bu...@googlegroups.com>
>
> > > > <jallib%25252Bun...@googlegroups.com<jallib%2525252Bu...@googlegroups.com>
> > <jallib%2525252Bu...@googlegroups.com<jallib%252525252B...@googlegroups.com>
>
funlw65(Vasi)
a long cable which can have radio parasites... I'm missing real
conditions. This is why this library must be tested by many, in all
kind of conditions.
Also, the library is working with sensors coupled in normal
connections (three wires cable) and not in parasitic mode.
Vasi
>
> read more »
jfm68
my 1_wire bus work good since 10 years ago without problemes, i use three
wires cables 20 metres long and fives probes ds1820 in the same bus.
sometime the crc is bad but one time in my (for 5 loop test) loop...never be
bad in my printer control which print all temperature every 15 min since 10
years !!
So your lib is probably good in real condition, because the 1-wire protocole
is make for noise environnement.
Have you play with a adressable switch ds2405, it can swicth on/off a relais
or read a press-buttom in a 1-wire_bus with multiples probes?
jean Marchaudon
Vasi
> read more �
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to
jallib+un...@googlegroups.com.
funlw65(Vasi)
On Dec 14, 6:30 pm, "jfm68" <jf...@wanadoo.fr> wrote:
> hi vasi,
>
> my 1_wire bus work good since 10 years ago without problemes, i use three
> wires cables 20 metres long and fives probes ds1820 in the same bus.
>
> sometime the crc is bad but one time in my (for 5 loop test) loop...never be
> bad in my printer control which print all temperature every 15 min since 10
> years !!
to see how it will behave when is about a defective sensor...
>
> So your lib is probably good in real condition, because the 1-wire protocole
> is make for noise environnement.
>
> Have you play with a adressable switch ds2405, it can swicth on/off a relais
> or read a press-buttom in a 1-wire_bus with multiples probes?
>
required that. I see you have a file archive about that... I will look
at it.
Best regards,
Vasi
funlw65(Vasi)
vasile surducan
jfm68
funlw65(Vasi)
Vasile's) are of a real value for the community. This kind of things
we need for good developed libraries, examples and final applications.
Is pure gold. Thank you!
What about this algorithm?
------ start algorithm ------------
- In a repeat-until loop, we start two counters.
- One is measuring the number of cycles, and another is counting the
number of bad CRC's.
- We have a maximum (let's say) of 5 or 10 cycles?
- If at the end of cycles we have the same numbers of CRC errors as
the maximum number of cycles, then something is WRONG (be it the line
or the sensor).
------ end algorithm ------------
Any opinions?
Best regards,
Vasi
> hi Vasile,
>
> I am a poor farmer who is working his four small probes in +1 to +4°C environnement in a cold room
>
> not like you on the planet Mars with extreme environnement ;-) !
>
> so Vasi, 1-wire is better in electric-static noise not in cooking mode...
>
> jean Marchaudon
>
> ----- Original Message -----
> From: vasile surducan
> To: jal...@googlegroups.com
> Sent: Tuesday, December 14, 2010 6:07 PM
> Subject: Re: [jallib] Re: One wire library
>
> Hi Jean,
>
> I have an automation of three solar water panels (entirely manufactured by myself). I'm measuring temperatures between +80C in summer time to about -25C in winter time on the panel pipes and on the boiler. There are also huge moisture variations on the pipes. I've mounted the 1wire bus cable near the pipes and then add the isolation above the cable and the pipe, so the cable was heated by the pipe itself.... Bad move.
> The result was an increase of the cable temperature (and it's internal resistance) which creates huge problems on communications, even the cable is only 30m long and 3 sensors on the bus. Problem cured after the cable was taken apart near the pipes.
>
> Vasile
>
> On Tue, Dec 14, 2010 at 8:30 AM, jfm68 <jf...@wanadoo.fr> wrote:
>
> hi vasi,
>
> my 1_wire bus work good since 10 years ago without problemes, i use three wires cables 20 metres long and fives probes ds1820 in the same bus.
>
> sometime the crc is bad but one time in my (for 5 loop test) loop...never be bad in my printer control which print all temperature every 15 min since 10 years !!
>
> So your lib is probably good in real condition, because the 1-wire protocole is make for noise environnement.
>
> Have you play with a adressable switch ds2405, it can swicth on/off a relais or read a press-buttom in a 1-wire_bus with multiples probes?
>
> jean Marchaudon
>
>
> read more »
funlw65(Vasi)
If the maximum number of cycles is achieved (so, we use only one
counter), then really here is a problem.
>
> read more »
funlw65(Vasi)
for that. Is only to ensure that your application will not be blocked
there (maybe we have also other tings to monitor and take decisions)
if CRC on a specified sensor is always bad.
funlw65(Vasi)
>
> read more »
vasile surducan
hi Vasile,I am a poor farmer who is working his four small probes in +1 to +4°C environnement in a cold roomnot like you on the planet Mars with extreme environnement ;-) !
mattschinkel
Could it be put into a separate library?
Matt.
funlw65(Vasi)
accurate programmer my want to use only CRC verified readings) but
Marchaudon knows better.
Vasi
Oliver Seitz
> 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
jfm68
I'm not then inventor of that CRC, i juste adapte it to jal.
It is the algoritm crc that DALLAS semiconductor compute for the 1-wire
protocole.
see crc section of :
http://datasheets.maxim-ic.com/en/ds/DS18B20.pdf
----
"CRC GENERATION
CRC bytes are provided as part of the DS18B20's 64-bit ROM code and in the
9th
byte of the scratchpad
memory. The ROM code CRC is calculated from the first 56 bits of the ROM
code and is contained in the
most significant byte of the ROM. The scratchpad CRC is calculated from the
data stored in the
scratchpad, and therefore it changes when the data in the scratchpad
changes. The CRCs provide the bus
master with a method of data validation when data is read from the DS18B20.
To verify that data has
been read correctly, the bus master must re-calculate the CRC from the
received data and then compare
this value to either the ROM code CRC (for ROM reads) or to the scratchpad
CRC (for scratchpad reads).
If the calculated CRC matches the read CRC, the data has been received error
free. The comparison of
CRC values and the decision to continue with an operation are determined
entirely by the bus master.
There is no circuitry inside the DS18B20 that prevents a command sequence
from proceeding if the
DS18B20 CRC (ROM or scratchpad) does not match the value generated by the
bus master.
The equivalent polynomial function of the CRC (ROM or scratchpad) is:
CRC = X8
+ X5
+ X4
+ 1
The bus master can re-calculate the CRC and compare it to the CRC values
from the DS18B20 using the
polynomial generator shown in Figure 9. This circuit consists of a shift
register and XOR gates, and the
shift register bits are initialized to 0. Starting with the least
significant bit of the ROM code or the least
significant bit of byte 0 in the scratchpad, one bit at a time should
shifted into the shift register. After
shifting in the 56th bit from the ROM or the most significant bit of byte 7
from the scratchpad, the
polynomial generator will contain the re-calculated CRC. Next, the 8-bit ROM
code or scratchpad CRC
from the DS18B20 must be shifted into the circuit. At this point, if the
re-calculated CRC was correct, the
shift register will contain all 0s. Additional information about the Maxim
1-Wire cyclic redundancy check"
----
if somebody has understand something after that !!! bravo
my loop test juste the value of crc that the ds1820 has send and compute
itself.
If you want to compute the crc value of nnbytes with this algorithm, perhaps
the loop will do the job !
test it, i have not time yet....but i will be very happys to use a crc_libs,
of course ;-)
-- not industrial standart procedure ;-)-
procedure d1w_read_byte_with_CRC( byte in nbre_byte, byte out GOOD_crc ) is
var byte bb = 0, n = 0 , crcbyte = 0 -- ! crcbyte must be set to 0
var bit bb_bit0 at bb : 0
var bit crcbyte_bit0 at crcbyte : 0 , crcbyte_bit2 at crcbyte : 2
var bit crcbyte_bit3 at crcbyte : 3 , crcbyte_bit7 at crcbyte : 7
var bit crcbit
for nbre_byte loop -- 8 bytes for readrom ID, 9 bytes for read
temp
d1w_read_byte( bb )
n = n + 1 -- �ne byte
if n == 1 then d1 = bb end if -- note d1 to d9 are globals
var
if n == 2 then d2 = bb end if --
if n == 3 then d3 = bb end if --
if n == 4 then d4 = bb end if --
if n == 5 then d5 = bb end if
if n == 6 then d6 = bb end if
if n == 7 then d7 = bb end if
if n == 8 then d8 = bb end if
if n == 9 then d9 = bb end if
-- ---calcul of crc---------------
for 8 loop
crcbit = crcbyte_bit0 ^ bb_bit0
crcbyte = crcbyte >> 1
crcbyte_bit7 = crcbit
crcbyte_bit2 = crcbyte_bit2 ^ crcbit
crcbyte_bit3 = crcbyte_bit3 ^ crcbit
bb = bb >> 1
end loop
-- ---------------------------------
end loop
if d5==0x_FF & d6==0x_FF & d7==0x_FF & d8==0x_FF & d9==0x_FF then --
control
crcbyte = 1 -- probe is not present, all read to 1 == 0x_FF
d1=198 -- reset temp with error scale 99�c
end if
if crcbyte == 0 then
GOOD_crc = true
else
GOOD_crc = False
end if -- crcbyte must be 0 for crc without error
end procedure
good luke
jean Marchaudon
----- Original Message -----
From: "funlw65(Vasi)" <fun...@gmail.com>
To: "jallib" <jal...@googlegroups.com>
Sent: Tuesday, December 14, 2010 9:04 PM
Subject: [jallib] Re: One wire library
Vasi
--
funlw65(Vasi)
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
funlw65(Vasi)
- 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
funlw65(Vasi)
funlw65(Vasi)
--
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
--
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
funlw65(Vasi)
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.
funlw65(Vasi)
reading is good, it will leave the loop :-P. Ok, good night to
everyone on this part of the world!
Vasi
Oliver Seitz
> [...]
> i = i + 1
> if ((i == max_crc_errors) & (GOOD_crc == 1)) then
> exit loop
> end if
> until GOOD_crc == 0
I think this is a quite complicated implementation of something like
[...]
i = i + 1
until ( GOOD_crc == 0 ) | ( i == max_crc_errors )
And, GOOD_crc is not checked after the loop. So bad readings are processed just the same way as good readings. Only the probability to have a good reading is increased. That should not be the goal, I think.
Greets,
Kiste
Oliver Seitz
> procedure s_temp_18B20_CRC([...], byte in max_crc_errors) is
> var byte i = 0
> repeat
> [...]
> i = i + 1
> until ( GOOD_crc == 0 ) | (i == max_crc_errors)
Comparisons between two variables take more code space, more data space and more execution time than comparisons between a variable and a constant. And, a comparison between a variable and "zero" takes even fewer code space and execution time than a comparison between a variable and any other constant. So this one would be more efficient:
procedure s_temp_18B20_CRC([...], byte in max_crc_errors) is
var byte crc_retries
crc_retries=max_crc_errors
repeat
[...]
crc_retries = crc_retries - 1
until ( GOOD_crc == 0 ) | (crc_retries == 0)
You don't have to change it if it's more readable the other way, the difference is not very big for byte variables. Just my bit of academic smartassing...
Greets,
Kiste
funlw65(Vasi)
in Pascal and very little in C. I like both constructions and I will
keep this one:
> procedure s_temp_18B20_CRC([...], byte in max_crc_errors) is
> var byte i = 0
> repeat
> [...]
> i = i + 1
> until ( GOOD_crc == 0 ) | (i == max_crc_errors)
Oliver Seitz
> well received. My background is more
> in Pascal and very little in C.
Your're welcome!
I hardly understand C at all, my favourite languages are JAL and assembler for PICs, and Pascal on PCs. Sometimes I have to use C, but it takes me days to even get a few lines to compile, let alone run ;-)
Greets,
Kiste
funlw65(Vasi)
more with the last one but not tested), and another 4 bytes with a
little one by me:
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
match_rom_18B20
send_ID_18B20
d1w_write_byte(0xBE)
read_18B20_with_CRC(9)
until (GOOD_crc == 0) | (i == max_crc_errors)
tmp[1] = scratchpad[1]
-- signed = 1
-- end if
signed = tmp_1_7
fraction = byte((tmp[0] & 0x0F)* word(625)/1000)
end procedure
well.
Joep Suijs
What is the status of this library? Does it work?
As far as I know it is not part of jallib yet. I see a lot of authors,
in combination with GPL license. Did you get permission to release
this code under zlib? If not, can you obtain this so we can add it to
the repository?
Thanks,
Joep
2010/12/15 vasi vasi <fun...@gmail.com>:
> The files until now.
>
> --
> Vasi
>
funlw65(Vasi)
From my part, library is working ok - tested and posted on my site.
Don't know if others tested it. If I remember well, Marchaudon said it
is ok. Remains Vasile and Bert. For AndTech it is what I learned
buying their learning board - no special note on my package, no
copyright, no author on that example file.
Vasi
On Jan 10, 10:14 pm, Joep Suijs <jsu...@gmail.com> wrote:
> Hi Vasi,
>
> What is the status of this library? Does it work?
> As far as I know it is not part of jallib yet. I see a lot of authors,
> in combination with GPL license. Did you get permission to release
> this code under zlib? If not, can you obtain this so we can add it to
> the repository?
>
> Thanks,
> Joep
>
Joep Suijs
> 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
funlw65(Vasi)
jfm68
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)" <fun...@gmail.com>
To: "jallib" <jal...@googlegroups.com>
Sent: Tuesday, January 11, 2011 9:41 AM
Subject: [jallib] Re: One wire library
--
funlw65(Vasi)
Joep, all three authors agree with the change of license for inclusion
in Jallib.
Vasi
Joep Suijs
Thanks for you work. I will start working on this library set (I have
the chips now ;)
Joep
2011/1/11 funlw65(Vasi) <fun...@gmail.com>:
funlw65(Vasi)
> the chips now ;)
>
> Joep
>
Joep Suijs
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) <fun...@gmail.com>:
Joep Suijs
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 <jsu...@gmail.com>:
funlw65(Vasi)
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
funlw65(Vasi)
Tell me if you need to send you the files archived.
funlw65(Vasi)
For the file 18f2550_ds18b20_therm.jal I have:
jal 2.4n (compiled Jun 2 2010)
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:
Code area: 2104 of 32768 used (bytes)
Data area: 80 of 928 used
Software stack available: 848 bytes
Hardware stack depth 5 of 31
Joep Suijs
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) <fun...@gmail.com>:
Joep Suijs
Can you confirm that thermometer.jal is intended for a single device
on the 1wire bus and thermometer2.jal potentially supports more
devices?
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.
An other thing is the parameter max_crc_errors. I think this is the
maximum number of retries. Correct?
Such a parameter suggests crc errors are quite common. How often do
you get CRC errors? 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. And how would you act upon this? 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?
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?
Joep
2011/1/13 Joep Suijs <jsu...@gmail.com>:
Joep Suijs
-- 1 wire JAL library for the DS18B20
--
-- file : ds18b20.jal
-- authors : And-Tech.pl, Bert van Dam, Jean Marchaudon, Olivier Seitz
-- : Vasile Surducan
funlw65(Vasi)
it for Jalv2, as stated by Bert in the header of the file included in
his package.
Joep Suijs
Joep
2011/1/13 funlw65(Vasi) <fun...@gmail.com>:
funlw65(Vasi)
On Jan 13, 7:12 pm, Joep Suijs <jsu...@gmail.com> 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?
> 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.
>
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:
signed, byte in max_crc_errors)
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?
> Such a parameter suggests crc errors are quite common. How often do
> you get CRC errors?
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.
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?
> 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?
>
> 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?
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 <jsu...@gmail.com>:
>
> > 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
>
funlw65(Vasi)
from AndTech, arranged in layers and seasoned by me, as I thought it
can be more pleasant for the clients...
On Jan 13, 9:37 pm, Joep Suijs <jsu...@gmail.com> wrote:
> Okay, this is the same for both one wire andds18b20then?
>
> Joep
>
funlw65(Vasi)
On Jan 13, 10:38 pm, "funlw65(Vasi)" <funl...@gmail.com> wrote:
> ds18b20is a sandwich. Is inspired by Bert's example and some example
funlw65(Vasi)
Florin Tanasa
Joep Suijs <jsu...@gmail.com> wrote:
>>> 2011/1/13 funlw65(Vasi) <fun...@gmail.com>:
>>>> For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
funlw65(Vasi)
vasile surducan
vasile surducan
Oliver Seitz
> Forgot to say that Olivier optimized
> the Celsius code.
>
> Dam, Jean Marchaudon, Olivier Seitz
> > > >> -- : Vasile Surducan
And I want to point out that this was not me ;-)
Greets,
Kiste
funlw65(Vasi)
On Jan 14, 10:14 am, vasile surducan <vsurdu...@gmail.com> wrote:
> Meaning, (to be clear) that he must be the first author in both jal and
> jalV2 versions of the actual DS18B20 library.
> The other 1Wlibrary author (which works OK under jalV2 too) is Philip
> Pemberton.
>
>
> > Jean Marchaudon library was the reference for all modifications.
>
> > Vasile
>
> >> .
> >> 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
> >> jal...@googlegroups.com.
> >> >>>>> > >>> > To unsubscribe from this group, send email to
> >> .
> >> 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 jal...@googlegroups.com.
> >> >>>>> > >> To unsubscribe from this group, send email to
> >> .
> >> 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 jal...@googlegroups.com.
> >> >>>> To unsubscribe from this group, send email to
> >> .
> >>http://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 jal...@googlegroups.com.
> >> >To unsubscribe from this group, send email to
> >> .
> >>http://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 jal...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> .
> >> For more
>
> ...
>
> read more »