Prop Code Help (whacky results)

RICoder · 2009-01-31 07:49

I'm having a few problems and weird symptoms, and I don't know if its me, or if its the chip. (the setup is a prop with a DS1620 thermostat chip). I know that the chip is set up properly, because I have moved the jumpers to a BS2 and it works just fine.

I'll be running my code, and it will seem fine, giving me a temperature that looks like what it should be for the ambient temp. As I update my code and move things around doing a few different tests, the values suddenly get all whacked out, like 76 degrees F from the last time I ran, and now its 124 F, which is just crazy.

Meanwhile, I'm using the FullDuplexSerial object from the obex, and that works just fine in the main program routine. Then I try to put some debug code in to inspect the bits I'm getting from the DS1620 in a subroutine, and the output is garbled from the sub, but not in the main.

If this was C++ on a PC, I'd say it was symptomatic of me writing over memory I didn't own...but I don't know about the prop chip. Any insight would be useful.

ex:

PUB Main
  repeat
    lFTemp := GetTemperature (PIN_DQ, PIN_CLK, PIN_RST)
    DEBUG.start (31, 30, 0, 9600)
    DEBUG.str (string ("DEC (F): "))
    DEBUG.dec (lFTemp)
    DEBUG.tx (13)
    TIME.pause1ms (2000)

PUB GetTemperature (DQ, CLK, RST): lTemp | lReadTemp

  outa[noparse][[/noparse]RST]~~
  IO.shiftout (DQ, CLK, io#LsbFirst, CMD_READ_TEMP, 8)
  lReadTemp := IO.shiftin (DQ, CLK, io#LsbFirst, 9) 
  outa[noparse][[/noparse]RST]~
  DEBUG.start (31, 30, 0, 9600)
  DEBUG.bin (lReadTemp, 9)
  lReadTemp := lReadTemp >> 1
  lTemp := lReadTemp * (9/5) + 32

JasonDorie · 2009-01-31 08:41

If I'm not mistaken, FullDuplexSerial uses its own cog, and buffers the data being sent/received. Calling DEBUG.start() more than once in your app is going to wreak all kinds of havoc. For example, the call inside GetTemperature won't have time to finish sending before you re-start the lib.

Take the DEBUG.start() call out of GetTemperature completely, and move the other one outside the repeat loop - That'll probably do it.

Jason

StefanL38 · 2009-01-31 09:50

Hello RICoder,

the FullDuplexSerial-objects (shortname for FullDuplexSerial FDS) runs in its own cog
You start the cog by using the start-command

Now if you start TWO cogs with the FDS-object and BOTH
cogs use the same IO-Pins (31,30) the signals can get messed up
You may ask how this can be using the commands sequential
As the FDS-object runs in its own cog it is completly independent
of all other cogs. Using the str-command fills in the characters
into the sendbuffer of the FDS-object very quickly
it needs time more to send them out at 9600 baud then to write it into the buffer

so it might happen that cog A running FDS still sends out characters of the string
as cog B starts to send out data too

Just start the FullDuplexSerial-object ONE time in your main method

After that you can use the the FDS-methods "str", "dec", "bin" etc. in any other
method like GetTemperature or what methods ever

Simply remove the

  DEBUG.start (31, 30, 0, 9600)

in your GetTemperature-method and it should work
and put the

  DEBUG.start (31, 30, 0, 9600)

in the main-method outside of the repeat-loop

For a more detailed analysis of what happends you have to attach your COMPLETE code
to your posting.

You can do this using the "archive"-function of the proptool

open your *.Spin-file with the main-method
click "file" in the main-menu of the proptool

choose and click "archive... "

choose and click "Project..."

this will create a ZIP-file that contains ALL files that are nescessary for compiling the whole project

best regards

Stefan

RICoder · 2009-01-31 20:37

ok, here's the code (attached).

Run it as is and the serial tool shows:
BIN RAW: 000100011
DEC RAW: 35
BIN SFT: 000010001
DEC SFT (C): 17
DEC SFT (F): 49
SUB TMP: 49

(can't be right)

Comment out the sub call to GetTemperature and serial tool shows:
BIN RAW: 101101000
DEC RAW: 360
BIN SFT: 010110100
DEC SFT (C): 180
DEC SFT (F): 212
SUB TMP: 0

UNCOMMENT the sub call (should be same as before) and serial tool shows:
BIN RAW: 101101000
DEC RAW: 360
BIN SFT: 010110100
DEC SFT (C): 180
DEC SFT (F): 212
SUB TMP: 212

What in god's name am I doing wrong?

StefanL38 · 2009-02-01 09:56

Hello RICoder,

first of all yyou are good at adding well formatted debugoutput to your code

By carefully comparing your code with the DS120-democode from the obex

I discovered a difference

the obexdemo-code uses the constant "io#LsbPre" for reading the temperature

      tc := io.shiftin(dpin, cpin, io#LsbPre, 9)          ' read temp in 0.5° C units

your code uses constant "io#LsbFirst"

  lTemperature := IO.shiftin (PIN_DQ, PIN_CLK, io#LsbFirst, 9)

If you take a close look at this codeline

io#LsbPre, 9 reads in NINE bits

io#LsbFirst, 8 reads in EIGHT bits

I have no DS1620 laying around here that I could do a test on my own.
But there is a good chance that this is the bug.

Before I found this I was thinking about the following questions

Did YOU test the temperature-reading in a REPEAT-loop ?

The democode you attached reads in the temperature ONE time and then only
outputting the results is repeated

As you get different values it might has to do with uncomplete reading data
a.) not enough bits read
b.) wrong bitorder MSBFirst instead of LSBfirst
etc.

By repeating the reading, you test if you are reading the bits the right way

So what could be learned IN GENERAL from this case ?

1.) asking the experts from the forum is a good idea

2.) to get satisfying answers give satisfying info about what YOU want to do

3.) start reading the Datasheet of the DS1620 carefully while waiting for the forum to answer

The datasheet says

"Writing to the E2 typically requires 10 ms at room temperature. After issuing a write command no
further writes should be requested for at least 10 ms."

you are waiting only 5msec in your code
for testing I would wait for 20msec to make REALLY sure that this detail works properly

best regards

Stefan

RICoder · 2009-02-01 17:23

@Stefan, thanks, those are some really good comments on what I'm doing (and even how I'm posting). I've been reading and thinking a lot, so I'll go do some experiments like you were saying and report back.

RICoder · 2009-02-01 19:06

...As a programmer I should be used to it, but there are just so many variable.

- Is it the Prop chip since I can't be 100% sure it is working
- Is it the DS1620 chip, since I am not sure if I may have fragged it with my code
- Is it the C code for the chip, since I just started coding for it

...oh...maybe its just that my calculation for Centigrade to Fahrenheit is wrong! d'oh!

(it was also the stuff stefan said...so thanks)

FYI: My code runs flawlessly now, but the DS1620 object is not so accurate. It may still be that my code is wrong, but giving me the right results. If I figure it out, I'll post.

Beau Schwabe · 2009-02-02 00:14

RICoder,

"My code runs flawlessly now, but the DS1620 object is not so accurate"
You should consider looking at the DS1620 in high resolution mode.
In Standard mode, 0.5 Deg C resolution translates to 0.9 Deg F resolution. In High-resolution mode you get 0.0625 Deg C resolution that translates to 0.1125 Deg F resolution.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

RICoder · 2009-02-02 00:32

Allow me to retract and restate. With my code, the chip works fine, and I get proper readings. With the DS1620 code, I get unusual, sometimes completely flawed readings (like 148d F). I might have screwed a little with the code in the DS1620 object, and will re-download and try again.

Prop Code Help (whacky results)

Comments