Shop OBEX P1 Docs P2 Docs Learn Events
Frozen Loop — Parallax Forums

Frozen Loop

infoinfo Posts: 31
edited 2014-05-10 09:59 in Propeller 1
I tried to use obex code for Dallas 1-wire device discovery. I use i2c 1-wire master bridge, so I have to modify the code. Somehow I srewed it up and it freezes or refuses to repeat loop and I just can't figure out why. I inserted serial port strings between lines trying to figure out where does it fail. I have no clue. It comes to the end of loop and stops.

Comments

  • ElectrodudeElectrodude Posts: 1,658
    edited 2014-05-09 15:43
    Your indentation is wrong. If you you Spin Tool, try turning on line indentation markers (ctrl+I or ctrl+L, I think?).
      repeat i from 0 to 7
        uarts.hex(0,rom[i],2)
        uarts.tx(0,32)
    
          return
    

    Your return statement returns right after first iteration - unindent it two levels so it's in line with "repeat i from 0 to 7" and not inside it.

    Try:
      repeat i from 0 to 7
        uarts.hex(0,rom[i],2)
        uarts.tx(0,32)
    
      return  'not indented as much (only 2 spaces instead of 6)
    

    electrodude
  • infoinfo Posts: 31
    edited 2014-05-09 16:54
    I do have the indentation turned on. There is grey vertical line from the "repeat maxAddrs" all the way to the end. I just tried all the combinations of indenting the last few lines with expected results, but the 4x loop still stops at the end. I'm fighting it for hours now and I can't figure it out. I guess you're correct about indentation, but it is there shown by the grey line. The inner loop goes around 64 times and the outer loop stops the first time it reaches the end.
  • kuronekokuroneko Posts: 3,623
    edited 2014-05-09 17:13
    This loop repeats exactly maxAdds times (unless exited manually by quit/return/abort/reboot):
    i := 0  
      repeat maxAddrs  
        ' other stuff
        i := i+1
        if i == maxAddrs
          quit
    
    That said, it can be written like this:
    repeat maxAddrs  
        ' other stuff
    
    This suggests that something else is responsible for the lockup. Small steps then, does it reach the end of the loop, e.g.
    i := 0  
      repeat maxAddrs  
        i := i+1
        if i == maxAddrs
          quit
        [COLOR="#FF8C00"]uarts.str(0, string("EOL"))[/COLOR]
    
  • infoinfo Posts: 31
    edited 2014-05-09 17:37
    That's how I feel now. Something else crashes the code, but it stops right before the "quit" and the loop 0-7 below (not connected by any vertical indent) never executes. There is no other action going on at the point where the loop freezes and the print verifies that maxAddrs equals 4, i = 0 and should get incremented. The "i" is not needed there. I put it there to see the value of "i" vs maxAddrs, but I just don't see why the maxAddrs doesn't loop more than once. This is frustrating bump in trying to get simple thing done - find the 1-wire device 64-bit serial number and move on to take some temperature reading. I didn't even write the code yet. I'm stuck here.

    The maxAddrs loop should go around 4 times and fall through to the next code below to print the 8 bytes serial number. That part has to be changed to display the serial number after each loop. I just try to isolate all unnecessary code to fix the frozen loop problem.
  • infoinfo Posts: 31
    edited 2014-05-09 23:55
    Here I'm answering my own question only because it is dissapointing when you read an old thread that ends up in dead end street. I don't learn from that, just waste time reading it.

    After inserting printable string line after line, I found that "longmove" instruction crashed the loop execution. When I comment out the longmove line, the loop executes 4 times as it should.

    I'm not a programmer and while I read the Propeller Manual, spin and also assembly instruction list, I don't understand lot of the memory access, the difference between "MyData", "@MyData", "MyData[x]", accessing cog memory and hub memory, or movig parameters from one to another, etc. To me it's kinda trial and error, but I still wonder why does "longmove" to declared VAR space crashes code when the code from obex most likely works when used as is.

    I tried to write little hex memory dump loop to display few lines of hex dump - whatever fits the small Parallax Terminal window looking for declared VARiables. After few failures I have that work, then I read here somewhere that my variables are re-arranged by the Propeller Tool. I will play with that later because it helps me understand what the program is doing when I can see and verify it.
  • kuronekokuroneko Posts: 3,623
    edited 2014-05-10 00:47
    info wrote: »
    After inserting printable string line after line, I found that "longmove" instruction crashed the loop execution. When I comment out the longmove line, the loop executes 4 times as it should.
    What value do you give to addrPtr when you call oneWIREsearch? IOW what does it point to?
    info wrote: »
    To me it's kinda trial and error, but I still wonder why does "longmove" to declared VAR space crashes code when the code from obex most likely works when used as is.
    The original demo calls the search method like this:
    numDevices := ow.search(ow#REQUIRE_CRC, [COLOR="#FF8C00"]MAX_DEVICES[/COLOR], @[COLOR="#020FC0"]addrs[/COLOR])
    
    where addr is defined as:
    long [COLOR="#020FC0"]addrs[/COLOR][2 * [COLOR="#FF8C00"]MAX_DEVICES[/COLOR]]
    
    as required by the API.
  • infoinfo Posts: 31
    edited 2014-05-10 09:47
    The PUB is called "oneWIREsearch($100,4,oneWireDevices)" where VAR is declared as "long oneWireDevices[128]".

    That should hold 64 devices which is about the maximum considered serviceable by Dallas. I think the old Dallas book said something like up to 100 devices.

    I'm still unable to put the "@rom" back to the VAR location. Whatever I tried so far crashed or didn't work. Also when I print "addrPtr" I get different values like if the Parallax Tool assigned different address to the VAR at every reload.
  • infoinfo Posts: 31
    edited 2014-05-10 09:59
    I need to thank you for help. The error in my code was in the call. The "@" was missing from the "@addr". Now it works. When I do hex dump at the end of search, I can see the 1-wire serial numbers in the VAR location. Thanks again. You caught my mistake.
Sign In or Register to comment.