This totally bizarre code behavior has me baffled (DS18B20 w/ VGA)

ElectricAye

Hi guys,

normally when I encounter a problem like this, I find a bandaid fix, suppress my curiousity·and just move on, but this one seems so weird that I can't let it go.

I'm reading a temperature off of one digital thermometer, a DS18B20, something I've done plenty of times.· Lately, though, I've·moved my display from a TV to a VGA.··After suffering many hours trying to find out why I sometimes see a correct temperature on the VGA and sometimes get a (very wrong) zero, I stripped my program down to a mini-version that continues to display a behavior I find totally bizarre.· In short, if I do NOT·ask the temperature reading loop to print SOMETHING (it doesn't matter what it is) to the VGA, then it appears that the DS18B20 will not be read at all.· Thinking that maybe the DS18B20 loop required a time delay of some sort, I tried inserting·some waitcnt functions, but that has no affect.· My bandaid fix is to have the VGA "print" something useless/harmless during the temperature reading loop - like a backspace or new line·- but why I must call up the VGA at all has me perplexed.
In my program, see the line (circa line 281) that looks like this:

            print_string(string("This line seems mysteriously essential..."))

Without that line, or some other command to the VGA, the temperature will simply read zero.
·Anybody think they can solve this mystery and dispell my suspicions that my Propeller has a little demon hiding inside?

thanks,
Mark






▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Watching the world pass me by, one photon at a time.

Post Edited (ElectricAye) : 5/11/2009 8:30:21 PM GMT

Bill Drummond

That the classic behavour of overwriting a varable, like an array not large enough or 2 varables sharing the same address space.

Rayman

maybe it's just a delay you need... I see a commented out waitcnt there. Did you try setting it to one second or so?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Rayman

On second thought, I agree with Bill! What's the i<<3 for?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

MagIO2

i<<3 multiplies i with 8 ... That's for calculating the adress of the array element for device number i ... *4 because size is long and *2 because 2 longs are needed per device.

It's another way to say @addrs[noparse][[/noparse] i*2 ]

But are you sure that you really want to pass a pointer to the array element or the content of the array element?

ElectricAye

To Bill, Rayman, and MAGIO2,

thanks for taking a look at this.· I must confess that I am not smart enough to come up with the DS18B20 reading software myself; it was something I took from Micah Dowty's SpinOneWire-test.spin program last year and I've used it for a long time with the TV display and never had anything strange happen with it.· I have attached a copy of Dowty's original.

I agree that it smells like a memory stomp issue, maybe, but, as usual, I have no idea how one is supposed to map out memory to surely avoid such issues.· If it is a memory stomp, I'm baffled that adding a VGA command would prevent it: it seems to me that the VGA call would, if anything, make it worse.

thanks for your interest,

Mark·



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Watching the world pass me by, one photon at a time.

MagIO2

I believe it's not the vga-command itself, but the string. This has to be stored somewhere, which moves the variables or other stuff in a way that it works.

Bill Drummond

I'm baffled that adding a VGA command would prevent it: it seems to me that the VGA call would, if anything, make it worse

That's exactly why I think your overwriting some variable, adding a variable or·constant, in this case, can change what gets overwritten and when. Sometimes the order is the key, if your variable is changed before you·update it, then no effect. You might try changing the order that you declare things to see what happens.

ElectricAye

MagIO2 said...
I believe it's not the vga-command itself, but the string. This has to be stored somewhere, which moves the variables or other stuff in a way that it works.

To Bill and MAGI02,

I now have little doubt that what you're saying is true and I thank you for pointing this out to me. But how on earth is a poor wretch supposed to keep track of variables in such a way as to ascertain that this sort of thing can't happen? It seems like there should be a way to assure it can't happen other than shifting variable declarations and trial-and-error. This memory stomp issue has always left me feeling naked and vulnerable. Such a thing makes me feel like I'm working with a Jack in the Box. I wish there were a way I could map out the memory of my Prop so I could see that I'm in danger of having one variable stomp over another. Is such a mapping system even remotely possible???

thanks for shedding some light on my dull programming skills,
Mark

Mike Green

The best way to deal with the variable stomp problem is to engineer it out of your programs. That doesn't mean it won't happen ... we all make mistakes, but adding checks for boundary conditions in every piece of code that uses subscripts or pointers can help (and I don't mean to put a check before every subscript). Using REPEAT statements and named constants for the ends of ranges (maxCount or lastEntry) helps a lot. It also helps point out suspicious parts of your program so you can focus you efforts there.

localroger

ElectricAye, I've never looked at this driver before but perusing the docs I see this...

'' array_ptr = Pointer to 5,120 long-aligned words, organized as 80 across by 64 down,
'' which will serve as the tile array. Each word specifies a tile bitmap and

...and in your code...

cols = 80
rows = 64
tiles = cols * rows
...
LONG array[noparse][[/noparse]tiles/2]

Now my handy dandy calculator reveals that 80 * 64 = 5120. So I'm not sure why you are dividing it by two but I'd say you aren't leaving enough room for the tile array, and of course it's declared first before all your other vars so if it overruns it will stomp everything.

ElectricAye

localroger said...
ElectricAye, I've never looked at this driver before but perusing the docs I see this...

'' array_ptr = Pointer to 5,120 long-aligned words, organized as 80 across by 64 down,
'' which will serve as the tile array. Each word specifies a tile bitmap and

...and in your code...

cols = 80
rows = 64
tiles = cols * rows
...
LONG array[noparse][[/noparse]tiles/2]

Now my handy dandy calculator reveals that 80 * 64 = 5120. So I'm not sure why you are dividing it by two but I'd say you aren't leaving enough room for the tile array, and of course it's declared first before all your other vars so if it overruns it will stomp everything.

Hi localroger,
I'm sorry, but my documentation should have specified that that little tidbit was extracted from
VGA_Tile_Driver_Demo_2 from the OBEX.· Frankly, I have no idea what it does and I'm lost on how VGA works at all.· For a while it looked like I really had this VGA kluged together well enough to work, but as I continue testing things, I'm starting to have all sorts of Jack in the Boxes pop out and bite me.· Lord knows I've tried to understand how this VGA stuff works, but my usual complaint is that there are few comments in the OBEX code and I've never been able to find a VGA for Morons book that I could sit down and read.·

Now it looks like I've got the VGA driver 4-wheeling all over my variables.· I can't even get the simplest things to work right anymore.· I must have been out of my mind to've changed from TV to VGA.·

CassLan

I dont know exactly how that driver works, but the TV_Text Driver uses words which would be longs/2. I dont know, I haven't used the VGA driver but I'm just saying. I don't have a prop set-up with me to test it out now, but I will.

Rick

localroger

Well, the tile drivers are very different things from the TV drivers. Since the problem developed from the transition from TV to VGA, that's where you should look for the problem -- and the first thing I'd try is removing that /2 from the source and trying it. The docs very clearly say it needs 5,120 longs. This is really the answer to EA's question of how you debug this stuff -- there are a limited number of constructs that can cause a memory stomp in Spin, so when you suspect one you audit them. One by one you look 'em over and ask if there is any way they can escape their confines. And while this might not be EA's real problem it's clearly something that needs to be explained one way or the other.

kuroneko

localroger said...
The docs very clearly say it needs 5,120 longs.

VGA 1280x1024 Tile Driver said...
array_ptr = Pointer to 5,120 long-aligned words, organized as 80 across by 64 down, which will serve as the tile array.

localroger

@kuroneko -- Oops.

ElectricAye

localroger said...
@kuroneko -- Oops.

Hey, don't feel bad. The lack of comments in most of these drivers leaves me totally in the dark. It almost makes me feel better to see experienced people get confused by stuff like that, too. I'm not sure why so many programmers are biased against commenting their code. It's a cultural thing, I guess. ...Words. Hmpf! Who needs'em.

Siri

ElectricAye,

I am not an expert programer by by any standard but I use both VGA and Tv displays.My use of these are so far

strictly for displaying TEXT.I have not had much difficulty so far.

I use the VGA.Text and Tv.text objects.

So if you are displaying only text,use these objects - while trying to learn about the tile drivers.

Siri

kuroneko

ElectricAye said...
My bandaid fix is to have the VGA "print" something useless/harmless during the temperature reading loop - like a backspace or new line - but why I must call up the VGA at all has me perplexed.

Does printing a backspace on its own (i.e. nothing else) actually work? If so - a backspace just modifies the col variable - I don't think that the VGA object is at fault here. More like that putting some code in that location causes stuff to be moved around. Not much help but worth checking.

localroger

@ElectricAye -- I figured out about 20 years ago that if I didn't document my stuff, in detail, *I* wouldn't be able to figure it out a few years later. Which leaves me with a sense of bafflement the lack of docs in some of this stuff, especially when it is using extremely clever optimizations.

Bill Drummond

*I* wouldn't be able to figure it out a few·years days later.