DS1620.setTempHi()?

Jeff Dege · 2006-02-04 21:52

Is there some reason why DS1620.setTempHi() and DS1620.setTempLo() do not set the temperature threshold values within the DS1620?

Peter Verkaik · 2006-02-04 22:19

Post your program!

regards peter

Jeff Dege · 2006-02-05 05:12

In other words, if you want it done, do it yourself?

I will, though it might take me a couple of days.

Peter Verkaik · 2006-02-05 05:43

No, I mean there is a DS1620 class with the methods you mentioned.
You claim those methods do not work, so show your code calling
those methods. There may be something wrong in your declarations
or the way you use the DS1620 class.

regards peter

Jeff Dege · 2006-02-05 15:30

My code is the example straight out of the manual.

And the DS1620 class does _not_ have setTempHi() or setTempLo() methods. They're non-virtual methods that it inherits from TempSensor.

In other words, setTempHi() and setTempLo() only set the threshold values within the TempSensor class. They do not create "WRITE TH" or "WRITE TL" commands and send them to the DS1620.

The two classes as they exist now work just fine for communicating the temperature to a Javelin program, and provide a Javelin program the information it needs to turn heaters/AC on or off. But they do not put the DS1620 into thermostat mode, and the three thermostat output pins on the DS1620 cannot be used for anything.

It should be simple enough to change the methods in class TempSensor to virtual, and then provide over-riding methods in class DS1620 that set the temperature thresholds within the chip.

Peter Verkaik · 2006-02-05 16:59

Note that DS1620 extends the TempSensor class, therefore any TempSensor method
becomes part of the DS1620 class.
Now you ask the question so I can undestand it (I don't use the DS1620 and had no
idea it has multiple modes).
If you want more functions, you can extend the DS1620 class or adapt the
DS1620 class. Note that TempSensor is an abstract class. Not all temperature sensors
have multiple modes. So it looks you must write code for the other mode yourself.
Perhaps someone else already has done this, but I don't remember any post about
the DS1620.

regards peter
·

Jeff Dege · 2006-02-05 17:48

The DS1620 example in the Javelin manual includes a diagram of the chip, with pins 5,6, and 7 connected to the high, low, and combined thermostat outputs. So I assumed that the DS1620 class was written so as to enable those outputs. When I ran the example program and those outputs did not change, I assumed I'd done something wrong.

It turns out that the DS1620 class is not written so as to enable those outputs. I will modify the classes in question so that these outputs are enabled, and post the code here. (I can't simply extend the class, because the methods in question were not declared virtual in the base class.)

Peter Verkaik · 2006-02-05 17:59

You can extend the DS1620 class or add methods to it.
You can override the setTempLo() and setTempHi() with code that
also call super.setTempLo()·etc. so the private treshold
parameters are set also.
You also need to write a method that instructs when which output
is switched (if that is not already dictated by the sensor itself)
and a method that returns the state of those switches.

regards peter

Jeff Dege · 2006-02-05 19:02

Sorry, I'm confusing Java with C++ (which I work with a great deal more than I do with Java). I was taking the absence of the "virtual" keyword in the TempSensor class to indicate that its methods could not be extended. But there is no "virtual" keyword in Java.

Peter Verkaik said...

You can override the setTempLo() and setTempHi() with code that
also call super.setTempLo() etc. so the private treshold
parameters are set also.

Exactly.

Peter Verkaik said...

You also need to write a method that instructs when which output
is switched (if that is not already dictated by the sensor itself)
and a method that returns the state of those switches.

I could override getTempLo() and getTempHi() to return the values in the chip, but the tempLo() and tempHi() and tempOK() methods in TempSensor are written to access the member variables tLo and tHi directly, rather than through the access functions getTempLo() and getTempHi(). So I'd have to override tempLo() and tempHi(), as well, if I wanted to consistently use the settings in the chip to drive the behavior.

Of course, it might make most sense to have tempLo(), tempLo(), and tempOK() work from the corresponding in the chip's status register.

I did notice something, while we are at it.

The CPU flag on the DS1620 is stored in non-volatile RAM. The datasheet says it can be written at least 50,000 times.

But the constructor the DS1620 class writes it every time an object is constructed. It'd probably be better to read the flag first, and to set it only if it had been cleared, rather than writing it every time.

Peter Verkaik · 2006-02-06 07:06

I checked the datasheet, the treshold settings are also stored
in eeprom. So you need to read those to check if a new value
is to be written.
You can make the private treshold settings in TempSensor protected,
then you can directly access them from DS1620.
The DS1620 as is, was written for the free-running mode of the DS1620.
You could write an entire new class DS1620th that supports the thermostat mode.
I don't think a given DS1620 will be used in both modes in the same application.
regards peter
·

DS1620.setTempHi()?

Comments