Help with assembler

Mike Green

I've been working still on a Propellor BOE-BOT. The PING and HM55B both seem to work and I decided to add an IR sensor on the PING bracket. Initially I tried the IR Buddy, but I've been unable to get it to work. I've got a single pin LED/IR-sensor combination that plugs into a servo cable. When the signal line is brought low, the LED turns on (a Red and IR LED in series and with a current limiting resistor). The Parallax IR sensor normally keeps the signal line high through a 20K resistance. When it's triggered, it brings the signal line low which turns on the LED, but stops any modulated signal from being continued. The attached program includes an assembly routine that is supposed to switch the signal line at various frequencies (like 40KHz) and sample in the "off" time to see if the sensor has triggered. It reports the number of cycles until the sensor triggers (or some maximum).

What this program seems to do is call this assembly routine several times, then the video display blanks. It shouldn't do that!! I've used this basic program for a while without this kind of behavior (mostly for testing the PING and compass). It doesn't matter even if the LED/sensor is disconnected.

Can anyone spot my bungle? Feel free to use the PING and HM55B routines (and the IR sensor stuff if we can get it to work). They're mostly simplified variations on the existing library routines.

Mike Green

Curiously, if I replace the case statement with an if/elseif/else statement, things work much better.

      if p == -1
        text.str(string("cog not started       "))
      elseif p == 0
        text.str(string("sensor not triggered  "))
      else
        text.dec(p)
        text.str(string(" pulse(s) to trigger"))

I wouldn't expect a malformed case statement in this context to cause the kind of
behavior I'm seeing. Curious ...

KenBash

Hi Mike,

It's funny that you ran into amost the EXACT problem I did while testing the Ping.

I posted a similar request about my screen blanking out.· What was truely weird was
that the code worked fine if my distance was greater than about 20 inches,· closer
than that and the screen started phasing away ( like the PLL timing was changing)
Minor changes in code changed the·WAY the screen went out.

Long story short... I had an array that was'nt big enough for what I was doing.

I was over-running the bounds of my array. Not sure if you're doing anything like that...

but gee.... it sure sounds familiar.·

Ken Bash

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
" Anything worth doing... is worth overdoing. "

··············································· ( R.A.H. )
····································

Mike Green

Ken,
Yeah, I thought of that first. There are no arrays that I reference in a way that can run out of bounds. The clincher is that replacing the case statement with what seems to be an equivalent if/elseif/else statement fixes the problem. This is suspicious!! I can't see any particular interpretation of that case statement that would result in the tv_text or TV objects getting screwed up like this. I suspect there's something wrong with code generation for the case statement or with the arrangement of methods in memory.

cgracey

Mike,

There seems to be some problem with STRING() usage in (CASE) OTHER blocks. I see that the string address is not getting patched and there is some other problem, as well, which is causing the CASE structure to be malformed. I will get to the bottom of this tomorrow and we will post a new version of the Propeller tool.

Sorry about this. When I added STRING() there was some subtlety about CASE statements that I must have overlooked.·I'm glad you found this. Whatever this error is could be lying in wait to cause other problems, too. I'll get to the bottom of it in the morning.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

cgracey

It took a lot of energy to get this problem tracked down! When STRING() is used in code sequences that are compiled out of order (like CASE/OTHER blocks), the patching offsets get mangled. Instead of the patches being placed where they belong, they can go elsewhere and become out-of-context and get executed as Spin byte codes. This can cause your whole program to blow up, as it is did for Mike. I've got this CASE/OTHER instance fixed right now, but it will take some careful effort to go over the whole compiler and find all the points at which this is an issue. Most are practically irrelevant, like using STRING() as a REPEAT/TO argument. Nonetheless, this needs to be accommodated. I will work on this tonight and Jeff should be able to post a new Propeller Tool by noon tomorrow.

Mike, I'm glad you found this. This was·a time-bomb that might have caused a lot of customers some serious head-scratching. Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Mike Green

Thanks for the prompt attention. I know how persnickity these compiler thingees can be. Happy hunting.

Mike