readtemp takes 750ms - utilizing the time?

KTarke · May 7, 2010

EDIT:WHAT WAS ACHIEVED IN THIS THREAD.
-new code to read temperature in 100ms (9-bit resolution)
-several codes to translate DS18B20's temp readings to degrees

I wan't to confirm, that I have thought right... (or wrong)

Most examples show someting like this.
Readtemp 1,b0
pause 750
use the result...

I think, why wait?
readtemp 1,b0
readtemp 2,b1
gosub test buttons pressed...
gosub do something else...
if still time left, THEN pause the rest of waiting time
use the results of readtemps

questions:
-I can use the command "readtemp" for several sensors in a row without pauses (it is the RESULTS that take time to form...) right or wrong? (difficulties to understand HOW intepreted commands work, WHAT is it, that takes time)
OR do I have to put pause between two readtemps from different ports/sensors?

-How to determine, how much a simple sub-procedure takes time (for example reading some input-pins,IF there is no input, which takes more time...)? ( = where to find info, how much different commands consume time)

I have earlier utilized DS1820 only on a PC, with Maxim's example code (Java,VBscript) and don't recall any "additional" pauses to wait for results...
(maybe delays were in the code, don't remember,but reading several sensor feeled quicker than n*750mS)

Earlier had electronics and computers as a hobby for a real long time... Programmed with Basic SOME rows

So, Picaxe-basics "style" of doing things feels a bit alien... already several times had a risen bloodpressure, when quite usual, very much "habit" ways of basic-programming, result a "intepret error" on Picaxe... manual2 has been in keen use, but some answer can't be found there (for example this timing-thing for readtemp)

MartinM57 · May 7, 2010

KTarke said:
I think, why wait?

You don't wait - the READTEMP command waits...have a read of the DS18B20 data sheet - that explains why it waits 750mS. It's not a PICAXE limitation.

READTEMP followed by PAUSE 750 is not needed to ensure READTEMP works. Not sure where you've seen it.

To use the 750ms usefully you can use a PICAXE that supports the OWOUT/OWIN commands. You issue the OWOUT, then come back 750ms (or longer later) and do the OWIN - see Manual 2. It's all in there...

KTarke · May 7, 2010

MartinM57 said:
You don't wait - the READTEMP command waits...have a read of the DS18B20 data sheet - that explains why it waits 750mS. It's not a PICAXE limitation.

READTEMP followed by PAUSE 750 is not needed to ensure READTEMP works. Not sure where you've seen it.

To use the 750ms usefully you can use a PICAXE that supports the OWOUT/OWIN commands. You issue the OWOUT, then come back 750ms (or longer later) and do the OWIN - see Manual 2. It's all in there...

So, I thought I remembered that the time was needed IN the sensor.

And that was also what I didn't know, that READTEMP waits until the whole thing is done.

I really did see readtemp+pause 750 in some threads, and nobody then remarked that (been reading old posts to learn).

Yes, need to use OW-commands, then I can use the time between...
(sorry, forgot to mention that I use 28x1 or 28x2)

That was cleared, thank You!

Still, there is the other question:
Where to get information, how much time different commands take?
Or how to measure used time of a sub-procedure?
I've got a expression that because of the "high-level" Picaxe-interpreter, it is not so easy to sum clock-pulses (as in assembler) and get the run-time for some commands.

Marcwolf · May 7, 2010

Ouch 750ms
Thats a significant slice of processing time. I was planning to use a DS18B20 in a circuit but now I'll best go back to READADC and a thermister. I can calibrate using a temp proble on my digitel multimeter.

Thanks for the heads up
Dave

BeanieBots · May 7, 2010

The 750mS wait seen in old threads is historic.
Once-apon-a-time the command did NOT wait until it was finished and you would get errornous readings. This has been fixed a long time ago now.

If you want to "do something" during the 750mS conversion time then you must use one wire commands as suggested by Martin.

MartinM57 · May 7, 2010

KTarke said:
Still, there is the other question:
Where to get information, how much time different commands take?
Or how to measure used time of a sub-procedure?

Not published I'm afraid. Been discussed here a lot - search for "timings". Generally 250uS per command at 4Mhz and it scales with SETFREQ - except for X2 chips

e.g.
http://www.picaxeforum.co.uk/showthread.php?t=11007&highlight=250us
and
http://www.picaxeforum.co.uk/showthread.php?t=13262

How to time a subprocedure? - write a test harness that calls it 1000 times, time it and divide by 1000 will get you close

MartinM57 · May 7, 2010

BeanieBots said:
Once-apon-a-time the command did NOT wait until it was finished...

well I never knew that. Thanks for the history lesson BB - way before my time here

Chavaquiah · May 7, 2010

KTarke said:
Where to get information, how much time different commands take?

If you're going to use OWOUT/OWIN you MUST read the DS18B20 datasheet.

Some sources:
http://www.datasheetcatalog.com/
http://www.alldatasheet.com/
http://www.datasheetarchive.com/

The datasheet explains quite well how to determine when the temperature conversion is done (by polling the sensor) and also how long it takes. If you can live with less than 12 bit precision, it will be much faster.

westaust55 · May 8, 2010

PICAXE command timing

KTarke said:
Still, there is the other question:
Where to get information, how much time different commands take?

BeanieBots is the only member here who has published some time data and that was long ago.

Okay and now for a a round about response/link here.

If you have a look through my tutorial on how to do an advanced search on the PICAXE forum in this thread:
http://www.picaxeforum.co.uk/showthread.php?t=11053

That tutorial actually uses the thread with BB's data as an example

Follow the tutorial in real life and find BB's timing information

KTarke · May 8, 2010

MartinM57 said:
Not published I'm afraid. Been discussed here a lot - search for "timings". Generally 250uS per command at 4Mhz and it scales with SETFREQ - except for X2 chips

e.g.
http://www.picaxeforum.co.uk/showthread.php?t=11007&highlight=250us
and
http://www.picaxeforum.co.uk/showthread.php?t=13262

How to time a subprocedure? - write a test harness that calls it 1000 times, time it and divide by 1000 will get you close

Thank You for advice.
Didn't occur to me to run sub 1000 times. Doing so, it is already possible to use a stopwatch...

KTarke · May 8, 2010

Chavaquiah said:
If you're going to use OWOUT/OWIN you MUST read the DS18B20 datasheet.

Some sources:
http://www.datasheetcatalog.com/
http://www.alldatasheet.com/
http://www.datasheetarchive.com/

The datasheet explains quite well how to determine when the temperature conversion is done (by polling the sensor) and also how long it takes. If you can live with less than 12 bit precision, it will be much faster.

I have used 1-wire products before, with a PC. So, basics are clear, it was just the readtemp-command, that confused me...

And yes, in most cases less than 12bit accuracy is well acceptable, have to refresh my memory reading the datasheet.

KTarke · May 8, 2010

Marcwolf said:
Ouch 750ms
Thats a significant slice of processing time. I was planning to use a DS18B20 in a circuit but now I'll best go back to READADC and a thermister. I can calibrate using a temp proble on my digitel multimeter.

Thanks for the heads up
Dave

3/4 seconds is a long time, if one has several sensors.
But in my experience,in most applications (temperature meters, thermostates,frost warners etc.) it is all the same, if one checks the temp only in a period of 5 seconds.

I started this thread to discuss, how the "reading time" could be used beneficially, though I COULD have coped with readtemp and waiting...

I prefer DS1820 to other sensors, because one does not have to deal with analogue errata, caused by voltage and cable lenghts, etc. and math with the result is easy/reliable (analog sensors readings are not necesserely linear)
Cables can be very long, too (unless sensor is used by parasite power, that is asking for trouble)

With Picaxe, connecting DS1820 is easier than with PC ,too. With a PC one might have problems, when connecting "real" Vcc. (With Picaxe Vcc and data-line grounds are definitely at the same potential, which is not the case with the common "floating ground" PC/1-wire adapter)

And, as CHAVQUIAH pointed out, with OW-commands there is a chance to shorten processing time.

It was the biggest reason for me to start using Picaxe, that it has support for 1-wire products.

Dippy · May 8, 2010

I thought hippy or Beaniebots had done some one-wire code to issue a request, do something else briefly, then come back and read the data?
I thought they had developed some code as opposed to hypothesising (??).

Availability accepted, there are other digital options inlcuding the TSIC types from ZMD. Much faster response. The downside will be that you will almost certainly have to develop your own code to communicate.

Having a dedicated second PICAXE may help, such that it would have the data ready when interrogated. Extra cost may be a problem.

With analogue sensors there are ways to deal with analogue issues e.g. digitising or even V2F at the sharp end. I'm not sure of the performance of unbuffered I2C anyway over long lengths which would obviously depend on the environment and cable. Ultimately it depends on budgets, sizes and how much extra gubbins you wish to add. The upside would be speed.

All depends on what you can put up with and the Application.

MartinM57 · May 8, 2010

Set up a 750ms timed interrupt and alternately do the OWIN and OWOUT commands in the interrupt routine (just use a flag to indicate whether the next interrupot needs to do OWIN or OWOUT).

The rest of your 'main' program can then run and hardly be aware that anything else is happening at all.

I'm sure someone can knock up some example trivial code in a few mins - I gotta go to a wedding right now (not mine

)

BeanieBots · May 8, 2010

The code for using a DS18B20 to start a conversion "do something" and then read the result is in the manual as an example for one-wire.
That's probably where the "pause 750" came from as it's the "do something" in the example.

For those who don't want to read the manual

Code:

main:
owout 1,%1001,($CC,$44)     &#8216; send &#8216;reset&#8217; then &#8216;skip ROM&#8217;
                                        &#8216; then &#8216;convert&#8217; then apply &#8216;pullup&#8217;
pause 750                          &#8216; wait 750ms with strong pullup [B](or do something useful during the wait!)[/B]
owout 1,%0001,($CC,$BE)
                                        &#8216; send &#8216;reset&#8217; then &#8216;skip ROM&#8217;
                                        &#8216; then &#8216;read temp&#8217; command
owin 1,%0000,(b0,b1) &#8216; read in result
sertxd (#w0) &#8216; transmit value
goto main

westaust55 · May 9, 2010

rmeldo in post 4 here:
http://www.picaxeforum.co.uk/showthread.php?t=11100

gives code he used with an X1 part and several DS18B20 temp sensors on a single pin using one-wire.

Have recently purchased some extra DS18B20's myself and looking to do a project reading multiple temps through a single pin so this will be a good starting point.

KTarke · May 10, 2010

westaust55 said:
rmeldo in post 4 here:
http://www.picaxeforum.co.uk/showthread.php?t=11100

gives code he used with an X1 part and several DS18B20 temp sensors on a single pin using one-wire.

Have recently purchased some extra DS18B20's myself and looking to do a project reading multiple temps through a single pin so this will be a good starting point.

Ofcourse a entertaining project to put several components to a single input, but I see no other purpose. Picaxe has a lot of pins, if one does not need dozens of DS1820's...

Exeption is, if further tempsensor are a long way from Picaxe, then it is nice to have several in one wire.

With PC ,it was "really something" to put several temp-sensors, and especially "switches" (DS2406) to a looooong wire, and control them individually by address.

With Picaxe, I see the simple approach: no need of 2406's, cause there IS outputpins, and INTERNAL command to read temp (which ignores addresses and all the complicated stuff

)

2480, mentioned in the link, is a "router" which makes a "subnet" to ONE wire. Makes possible to "branch" from the "main line", and connect a lot more sensors... in my opinion, hardly usefull with Picaxe?

More I am interested (and have to later dig in to it) in some more peculiar Maxim-chip usage with 1-wire. For example, there is a quite fancy circuit, where Maxims "laptop-battery-monitor-chip" is used to interface a K-type thermocouple to 1-wire bus. Efficient and quite accurate (i don't remember the chips number now, tell later, it has a very good adc...)

MORA99 · May 11, 2010

From my code folder

I used the interrupt from a DS1307 set at 1Hz to see when we could retrieve the results, its a bit unprecise since that can be 1.00 or 1.99 seconds depending on when we read it.

however the DS1307 can be set to a 4khz instead if needed.

Code:

'****************** Starts a convert on all sensors
startConvert:
 owout 1,%1001,($CC,$44) 'send ‘reset’ then ‘skip ROM’ then convert then apply ‘pullup’ 
 convertStart = tics MAX 1
RETURN

'****************** Checks if timeout is reached, and stores all converts
checkConvert:
TEMP1 = tics - convertStart

if TEMP1 > 1 AND convertStart > 0 then 
 convertStart = 0
 owout 1,%0001,($CC,$BE) 'send ‘reset’ then ‘skip ROM’ then ‘read temp’ command
 owin 1,%0000,(b10,b11) 'read in result
endif 
RETURN



convertDS18B20:
  'Gets SENSORVALUE and converts it into the MSB and LSB "human version"

   SignBit = SENSORVALUE / 256 / 128
   If SignBit <> 0 Then 
    ' its negative
    SENSORVALUE = SENSORVALUE ^ $ffff + 1 ' take twos comp
   endif

   TempC =  SENSORVALUE * 6		' TC = value * 0.0625
   SENSORVALUE = SENSORVALUE * 25 / 100
   TempC = TempC + SENSORVALUE

   SENSORVALUEMSB = TempC / 100
   SENSORVALUELSB = TempC % 100

   if SignBit <> 0 Then
     SENSORVALUEMSB = SENSORVALUEMSB + 128
   endif
   
   'When printing the LSB must be printed in 2 steps, first / 10 then % 10 (Otherwise values less than 10 will look wrong, ie. 25.5 instead of 25.05)
RETURN

BeanieBots · May 11, 2010

KTarke said:
Ofcourse a entertaining project to put several components to a single input, but I see no other purpose. Picaxe has a lot of pins, if one does not need dozens of DS1820's...

Maybe you should have another think about it.
Functionality of that nature is the difference between a hobby and a business. It also saved a lot of copper weight when (true story) they used many DS18B20s in the space shuttle.
I/O is one of the most valueable assets a micro can have. Anything which can reduce it's useage is extremely important.

InvaderZim · May 12, 2010

I'm a tiny bit confused as to the application, but here's an observation:

If you are polling many sensors, and each requires you to wait until they deliver a valid result, you can get away with a single wait period. Just send a "start conversion" command to each device in series, then wait one conversion time (or do something useful). Then you can go back and poll each device for its result.

It should take negligibly longer to poll 10 devices than it would just one, since they can all do a conversion at the same time. No need to wait for one to finish before starting the next. So you can poll 10 temp sensors in under a second, instead of ~8 seconds if you were waiting for each one sequentially.

hippy · May 12, 2010

@ InvaderZim : You are absolutely correct, it doesn't need to be -

Start First
Wait
Read First
Start Second
Wait
Read Second
etc

one can do -

Start First
Start Second
Start ...
Wait
Read First
Read Second
Read ...

If not requiring fast temperature updates it may be easier / simpler to do them individually and cyclicly rather than all together.

KTarke · May 12, 2010

BeanieBots said:
Maybe you should have another think about it.
Functionality of that nature is the difference between a hobby and a business. It also saved a lot of copper weight when (true story) they used many DS18B20s in the space shuttle.
I/O is one of the most valueable assets a micro can have. Anything which can reduce it's useage is extremely important.

WoW! They used DS1820 in space shuttles...
You did not "quote" long enough what I wrote: I agree, that several sensors in one lead is very good, in case when they are far away... then one saves in cable usage.
And true, I/O pins are a asset WHEN the application does many more things,than reading temps... But when talking about basic thermostates ,which need only a few tempsensors, and some outputs (relays), there will be a lot unused pins...

And I understand ,that when doing big scale production ,every $cent is important. I am developing commercial products ,too, but amounts are smaller, and applications VERY dedicated (even designable by buyers wishes).
It leads to, that I chose ONE Picaxe model to suit all needs ,even when some projects could have used a smaller Picaxe,(only) a FEW $ cheaper...
When using only one (or two) models, I don't have to remember, what commands works where ,the boxing and wiring goes by the same design etc...

Picaxe 28 X1/X2 is very much overkill for a simple thermostat-project, but (as I explained before) ,it is very much easier to stick with a single module (lowers development/manufacturing cost). I even use ready made project boards! though "made" pcb:s would be a lot cheaper.
When making small amounts/desing-products, it is easier to use a little "oversized" and standard components, than loosing time with wondering during the "production".

AND in one other answer mentioned "dedicated 08" for reading temps is a very good idea, and certainly not too expensive! In this thread I was just searching a software-solution.

KTarke · May 12, 2010

BeanieBots said:
The code for using a DS18B20 to start a conversion "do something" and then read the result is in the manual as an example for one-wire.
That's probably where the "pause 750" came from as it's the "do something" in the example.

For those who don't want to read the manual

Code:

main: owout 1,%1001,($CC,$44) ‘ send ‘reset’ then ‘skip ROM’ ‘ then ‘convert’ then apply ‘pullup’ pause 750 ‘ wait 750ms with strong pullup [B](or do something useful during the wait!)[/B] owout 1,%0001,($CC,$BE) ‘ send ‘reset’ then ‘skip ROM’ ‘ then ‘read temp’ command owin 1,%0000,(b0,b1) ‘ read in result sertxd (#w0) ‘ transmit value goto main

""For those who don't want to read the manual"" a BIT "catched my ear"
I AM new with Picaxe and HAVE tried to read all available documents, but...
I consider Picaxe manual a little hard to understand sometimes, and I HAVE read old posts to learn, and we saw, what it can lead to... What I was asking in the first post of this thread (readtemp+wait) was old knowledge (the command has CHANGED during the time)

I wonder, are old posts obsolete, should one read them at all ,and should one use "search" on old threads, if old information is "no good" with "developed" intepreter.

I THOUGHT that I don't ask stupid questions, which can be solved by reading the manual, but am not sure anymore.

KTarke · May 12, 2010

hippy said:
@ InvaderZim : You are absolutely correct, it doesn't need to be -

Start First
Wait
Read First
Start Second
Wait
Read Second
etc

one can do -

Start First
Start Second
Start ...
Wait
Read First
Read Second
Read ...

If not requiring fast temperature updates it may be easier / simpler to do them individually and cyclicly rather than all together.

The code-example was exactly, what I was thinking/searching for!

But it leads to another question (never tried THAT with 1-wire and pc...)
WHAT IF the gap between "starts" and "reads" will be streched...?
Does it matter or not, if a subroutine prolongs the time, before the program "has time" to read in the values?
I recall, that in Maxims examples result is read right away, when "ready", but that is essential when using "parasitic power". When using "real power", does it matter?

Chavaquiah · May 12, 2010

I could swear I read somewhere that the temperature registers keep their values until another CONVERT T command is initiated. Couldn't find that in the datasheet but I'm pretty sure you can safely stretch the wait time. Indeed, I'm even sure (like I've never been wrong before!

) you can reissue repeated read commands to get the last measured temperature.

hippy · May 13, 2010

I'm sure DS18B20 will hold their temperature result until it is read, no matter how long the time to reading is. This should also be the case for parasitic powered devices as long as the 'apply stong pull-up after data' bit is maintained. I'll do some testing.

KTarke · May 13, 2010

hippy said:
I'm sure DS18B20 will hold their temperature result until it is read, no matter how long the time to reading is. This should also be the case for parasitic powered devices as long as the 'apply stong pull-up after data' bit is maintained. I'll do some testing.

Thank You CHAVAQUIAH an HIPPY, that answer simplifies things.

I had some trouble with parasitic power in the past, and have a faint image in my memory, that applying strong pull-up for longer times, may affect other devices on the same bus... (not sure, if I remember right)

hippy · May 13, 2010

It could be that long-time parasitic powering may present problems, especially if interactive with other things on the bus, I haven't ever tried that.

One thing I noticed while reading the DS18B20 datasheet is that it doesn't have to be a 750ms delay. Only when reading 12-bit data. For each bit of resolution you are prepared to lose you can halve the sample time -

12-bit = 750ms
11-bit = 375ms
10-bit = 187ms
9-bit = 94ms

The DS18B20 selects 12-bit mode at power-up but you can force it to be different.

A thought ... If the DS18B20 is not parasitically powered, is connected to +V, then maybe a one-wire write to configure 9-bit mode say, and subsequent READTEMP12 commands may actually return the 9-bit result within 100ms ? There's always fun to be had with a PICAXE

premelec · May 14, 2010

Past multi unit work..

http://www.anotherurl.com/therm/logger.htm - mention of a system using up to 64 sense units. This was a solar system design item and deserves a look at his logging software etc.

westaust55 · May 14, 2010

from the DS18B20 D/S:

The 1-Wire bus requires an external pullup resistor of approximately 5kΩ; thus, the idle state for the 1-Wire bus is high. If for any reason a transaction needs to be suspended, the bus MUST be left in the idle state if the transaction is to resume. Infinite recovery time can occur between bits so long as the 1-Wire bus is in the inactive (high) state during the recovery period. If the bus is held low for more than 480μs, all components on the bus will be reset.

Convert-T
This command initiates a single temperature conversion. Following the conversion, the resulting thermal data is stored in the 2-byte temperature register in the scratchpad memory and the DS18B20 returns to its low-power idle state.

Read Scratchpad
This command allows the master to read the contents of the scratchpad. The data transfer starts with the least significant bit of byte 0 and continues through the scratchpad until the 9th byte (byte 8 – CRC) is read. The master may issue a reset to terminate reading at any time if only part of the scratchpad data is needed.

Based upon the above extracts from the DS18B20 datasheet, the Convert-T operation performs a single temp conversion and puts the data in the scratchpad. Thus when (timewise) you subsequently read the data using the Read Scratchpad command is irrelevant, so long as it is before another Convert-T command or power is removed.

KTarke · May 16, 2010

BeanieBots said:

For those who don't want to read the manual

Code:

main:
owout 1,%1001,($CC,$44)     ‘ send ‘reset’ then ‘skip ROM’
                                        ‘ then ‘convert’ then apply ‘pullup’
pause 750                          ‘ wait 750ms with strong pullup [B](or do something useful during the wait!)[/B]
owout 1,%0001,($CC,$BE)
                                        ‘ send ‘reset’ then ‘skip ROM’
                                        ‘ then ‘read temp’ command
owin 1,%0000,(b0,b1) ‘ read in result
sertxd (#w0) ‘ transmit value
goto main

Yes, read examples, but what there is to learn, if code is not working.
The code works only with parasite power, BUT on the page 155 is a picture, where external power is used.
If one has connected the sensor AS SHOWN ELSEWHERE IN THE MANUAL, the example does not work.

With external power, strong pullup MUST NOT be used.
owout 1,%0001,($CC,$44)

MartinM57 · May 16, 2010

This works perfectly for me with external power to the DS18B20...and it seems identical to the above

Code:

#picaxe 28x2
#NO_DATA
#NO_TABLE
#TERMINAL 38400

setfreq em32

Symbol TReading = W0
Symbol Whole = B2
Symbol Fract = B3
Symbol SignBit = B4
Symbol Digt = B5
Symbol TempC_100 = W3

again:

	'send &#8216;reset&#8217; then &#8216;skip ROM&#8217;
	'then &#8216;convert&#8217; then apply &#8216;pullup&#8217;
	owout B.3,%1001,($CC,$44)

	'wait 750ms with strong pullup
	pause 4000
	
	'send &#8216;reset&#8217; then &#8216;skip ROM&#8217;
	owout B.3,%0001,($CC,$BE)
	
	'then &#8216;read temp&#8217; command
	owin B.3,%0000,(b0,b1) 'read in result
	
	SignBit = TReading / 256 / 128
	If SignBit = 0 Then Positive
	' its negative
	TReading = TReading ^ $ffff + 1 ' take twos comp
	SerTxD ("-")

Positive:
	TempC_100 = TReading * 6		' TC = value * 0.0625
	TReading  = TReading * 25 / 100
	TempC_100 = TempC_100 + TReading

	Whole = TempC_100 / 100
	Fract = TempC_100 % 100
	IF fract > 75 then
		INC Whole
		Fract = 0
	elseif fract <= 25 then
		Fract = 0
	else
		Fract = 5
	endif	
	
	SerTxD (#Whole, ".", #Fract, CR, LF)

GoTo again

KTarke · May 16, 2010

SOLVED, no need to wait...

If one has to wait 750ms, something might be done in the waitingtime.
If one has to wait only 100ms, then there is no problem.

Thank You HIPPY to remind me that resolution can be changed, and that shortens waiting time.

I wrote the code and am going to share it now.

Notes:
-CHECK, that You certainly have DS18B20 (this code does not work W/ DS18S20)
-Since the datasheet says, that chips accuracy is "only" +-0,5 degreess ,NOTHING is "lost" if reading resolution is dropped from 0,06 degrees to 0,5 degrees! (usually even only whole degrees are shown...)
- My code expects, that temperatures stay above 0.
-My code expects that the sensor is alone in the line

Code:

init:
pause 500
dirsc = %00000000
#picaxe 28x1
#freq m4

owout 1,%0001,($CC,$4E,$00,$00,%00011111)         'send reset ,
                                                  'send skip rom (sensor ALONE in the line)
                                                  'send write scratchpad
                                                  'send 2 alarm-setting bytes and configuration register
                                                  'config.reg-byte ,bits 6 and 7 sets temp resolution to 9 bit                           

main:

gosub readtemp9
gosub convert
gosub show

goto main

end


readtemp9:

owout 1,%0001,($CC,$44)                           'send skip rom ,send convert temperature (Use %1000 if parasitic power)

pause 100                                         'wait ONLY 100ms ,because 9-bits converts faster! 
             
owout 1,%0001,($CC,$BE)                           'send skip rom ,send read scratchpad
                           
owin 1,%0010,(b0,b1)                              'send reset AFTER reading to cut off reading 7 bytes.more..
                                                  '(the first 2 bytes contains the temp reading)
return


convert:                                          'this code works only with X1/X2 parts
                                                  'negative temperatus are not expected and not processed
b2 = 0                                            'temperature is shown with resolution of 0,5 degrees
b3 = 0                                            'How temperature register is built, can be seen in datasheet

if bit3=1 then
b3 = 5
endif
if bit4=1 then 
b2 = b2+1
endif
if bit5=1 then 
b2 = b2+2
endif
if bit6=1 then 
b2 = b2+4
endif
if bit7=1 then 
b2 = b2+8
endif
if bit8=1 then 
b2 = b2+16
endif
if bit9=1 then 
b2 = b2+32
endif
if bit10=1 then 
b2 = b2+64
endif                                     
                                                  
return


show:

serout 7,N2400,(254,1)
serout 7,N2400,(#b2,".",#b3," C")

return

westaust55 · May 17, 2010

Untested but you could try using this subroutine with far less IF...THEN statements

Code:

convert:
	IF bit3=1 THEN : b3 = 5 : ENDIF
	b2 = w0 / 16 AND 127
	RETURN

KTarke · May 17, 2010

westaust55 said:
Untested but you could try using this subroutine with far less IF...THEN statements

Code:

convert: IF bit3=1 THEN : b3 = 5 : ENDIF b2 = w0 / 16 AND 127 RETURN

Yes, nice short code ,and works.
Much better programming, than mine.

Whatabout this one:

Code:

if bit3=1 then:b3 = 5:endif
b2 =w0 >> 4

The long version is just "more educational" ,if someone is interested, which bits were "fetched" from the high and low byte of the temp-register.

hippy · May 17, 2010

Or, if you're going for minimum program memory used ...

b3 = bit3 * 5
w0 = w0 << 5 >> 9
SerTxd( #w0, ".", #b3, "C" )

KTarke · May 17, 2010

hippy said:
Or, if you're going for minimum program memory used ...

b3 = bit3 * 5
w0 = w0 << 5 >> 9
SerTxd( #w0, ".", #b3, "C" )

Please explain!

w0 = wo << 5 >> 9 clears b1. In my code b1 is ignored...
Should my code rather be: ?
w0 = w0 >> 4
b2= b0
then only the lower byte is used. Or what did You mean by the memory usage?

I used b2, because it makes possible to measure/show two lines with same subroutines, like this:

Code:

symbol line = b10

main:

b10 = 1
gosub readtemp9
gosub convert
b4=b2
b5=b3

b10 = 2
gosub readtemp9
gosub convert

gosub show

goto main

end


readtemp9:
owout line,%0001,($CC,$44)           
pause 100                                      
owout line,%0001,($CC,$BE)                           
owin line,%0010,(b0,b1)                             
return


convert:                                       
b2 = 0                                          
b3 = 0                                         

if bit3=1 then:b3 = 5:endif
b2 =w0 >> 4                                     
return


show:

serout 7,N2400,(254,1)
serout 7,N2400,(#b4,".",#b5," C")
serout 7,N2400,(254,192)
serout 7,N2400,(#b2,".",#b3," C")

return

hippy · May 17, 2010

KTarke said:
Please explain!

w0 = wo << 5 >> 9 clears b1. In my code b1 is ignored...
Should my code rather be: ?
w0 = w0 >> 4
b2= b0
then only the lower byte is used.

You could do it that way, but it seems a shame to use b2 when you've already got the number you need in b0 ( and w0 ).

The shift left 5 gets rid of the msb of the temperature so ultimately equivalent to the "& $7F", the shift right 9 is the equivalent of shift right 4 but takes account of the earlier shift left.

KTarke · May 17, 2010

hippy said:
You could do it that way, but it seems a shame to use b2 when you've already got the number you need in b0 ( and w0 ).

The shift left 5 gets rid of the msb of the temperature so ultimately equivalent to the "& $7F", the shift right 9 is the equivalent of shift right 4 but takes account of the earlier shift left.

Alright, I understood ,what You meant.
So, in the "2-channel" experiment I should use b0 and b3 in the "first stage", b2 = b0 is a obsolete memory-eater.

(Not used to think about optimizing the code, I always take "over capacitated" modules to work with...)

marks · May 22, 2010

negative stuff

Hi Ktarke try this as your covert program
even tho accuracry only of the sensor 5% from-10 to 85 degrees.
this will give you a bit more resolution.
and give you a negative result to

Code:

Convert.
IF w0 > 64655 THEN                  '  info     - 55 degrees          = 64656
                                             ' display temp negative degrees -c                           
w0 = - w0                                ' make neg positive lol
ENDIF
w0 = w0* 5/8                           ' do the temp pos side  (0.0625)
                                              'accuracy   to 12bit (on the maths side lol)
let b2=w0/10
let b3=w0//10

readtemp takes 750ms - utilizing the time?

Senior Member

Moderator

Senior Member

Senior Member

Moderator

Moderator

Moderator

Senior Member

Moderator

Senior Member

Senior Member

Senior Member

Moderator

Moderator

Moderator

Moderator

Senior Member

Senior Member

Moderator

Senior Member

Technical Support

Senior Member

Senior Member

Senior Member

Senior Member

Technical Support

Senior Member

Technical Support

Senior Member

Moderator

Senior Member

Moderator

Senior Member

Moderator

Senior Member

Technical Support

Senior Member

Technical Support

Senior Member

Senior Member