Spin help - What am I missing

Paul Sr. · 2007-11-12 18:25

I'm finally spending some serious time with Spin so I can stop fumbling, and have encountered something that has been kicking me around, but I have been reluctant to mention because it seems TOO simple to be asking - but here goes anyway!

I am rewriting a serial LCD driver for different hardware, and I have the following code in it:

Var
  byte  linecnt
  
OBJ
  LCD : "Serial_LCD_PWS"
  DELAY : "Clock"

PUB Demo | temp

  DELAY.Init(8_000_000)

  linecnt := 4
  
  LCD.start(18, 9600, linecnt)

  REPEAT
    LCD.CLS
    delay.PauseSec(1)
    LCD.cursor(2)
    delay.PauseSec(1)
    LCD.str(string("Starting..."))
    delay.PauseSec(1)
'    LCD.backlight(ON,$FF)
'    delay.pausesec(1)
    LCD.cursor(3)
    delay.pausesec(1)
    LCD.gotoxy(2,1)
    LCD.str(string("Line 2"))
    delay.PauseSec(1)
    LCD.backlight(ON,$00)
    delay.PauseSec(1)
'        LCD.cursor(2)
    If linecnt == 4
         LCD.gotoxy(4,2)  
         LCD.str(string("Line 3"))
         delay.PauseSec(1)
         LCD.gotoxy(6,3)  
         LCD.str(string("Line 4"))
    delay.PauseSec(1)

and although I clearly have "linecnt := 4", the statement "If linecnt == 4" never evaluates true!

I have the same issue in the driver (same variable that is passed in through the call). I put a statement in that displays the value on the LCD and it SAYS it is equal to 4, but again, doesn't evaluate as 4.

What on earth did I miss???

Thanks,
Paul

Mike Green · 2007-11-12 18:37

What you've posted seems to be correct and there's no obvious reason why linecnt doesn't test equal to 4.
There may be something in your driver that's overwriting part of memory and may be changing the value stored in linecnt.

Paul Sr. · 2007-11-12 18:51

Mike,

Thanks for the fast response!

I thought of that and I created a new variable, unique to the object and set it equal to linecnt - same results. I also have tried it on two different machines (really stretching here), but it acts the same.

In the driver, I tried the following

  if started
    ' if lcdlines <> 2                                    ' check lcd size  -- NEVER works
      putc(lcdlines + "0")                              ' This SHOWS that lcdlines IS what I think is!
      waitcnt(clkfreq / 200 + cnt)                  ' 5 ms delay 
      case lcdLines
       2:

       4:
        if lookdown(state : 0..1)                     ' qualify mode input
          if lookdown(mode : 3..4)                  ' qualify mode input
            CMD
            if state
               putc(LCD_BIG_ON)
               putc(mode + "0")
            else
               putc(LCD_BIG_OFF)

The CASE statement appears to be evaluating lcdlines as expected, but the commented IF statement NEVER evaluates it correctly.

I even tried obscure [noparse][[/noparse]for a simple IF statement] things like forcing absolute values, etc. to no avail.

I'm really baffled!

Paul

hippy · 2007-11-12 19:21

You could include a TV or VGA driver and display debugging values as the code progresses, or even use a LED+R set when linecnt == 4. Something must be changing linecnt, so start commenting out code until the LED comes on. As you remove things you'll get a clearer focus on where the problem is located.

Mike Green · 2007-11-12 19:28

Again, without seeing the LCD driver, it's hard to tell what's going on. Assuming you're launching it in a separate cog, you may not have allocated enough space for its stack and it's overwriting the rest of the variable space. The same thing might be true of the clock object, but you haven't modified that.

deSilva · 2007-11-12 19:32

(1) How to check that "linecnt" has ben overwritten:
Define "linecnt" not as VAR but as local variable; it then will be a long, but never mind... It most likely will work now...

(2) Why could it have ben overwritten? BYTEs are always arranged at the the end of all VARs... You did not give your main program, but I imagine you will have the stack for some of your objects defined just before it. The size of stack is generally underestimated... Set your stacks to 100 LONGs and see what happens.

Paul Sr. · 2007-11-12 19:48

OK folks - sounds like I need to do a bit more reading!

Common thread here is the STACK - which could very well be it - guess I better understand that better first off.

Thanks again.

Mike Green · 2007-11-12 19:55

Start with the Propeller Manual description of COGNEW/COGINIT and look at the Stack Length program in the Object Exchange (under Tools).

Paul Sr. · 2007-11-13 12:05

Just an update on this - I still need to do some more testing.

Turns out, the issue seems to only exist on the uOled-96-Prop!

I put together another "breadboard" system using a Prop-Stick and the code runs and performs exactly as it should - all IF statements (or more accurately evaluations) are now working correctly!

This all started out when I was working on "polishing up" the Circle method I wrote for the uOled-96. I was getting unexpected results so I decided I wanted an LCD hooked up to pump values out to while things were happening. I have a bunch of the Wulfden/PHAnderson Serial LCD modules around (great little devices!) so I decided to rewrite the Parallax Serial driver to work with them. This is where I ran into the broken evaluations - which apparently explains why I was having trouble with the Circle method. Perhaps the Circle function needs to be in assembly!

So Mike, what was it you were saying "The uOLED-96-Prop cannot "run properly at 128MHz""??? Could this be proof?

Fred Hawkins · 2007-11-13 13:15

Have you tried your program in the oLED-prop at 8x -- 64mhz?

Paul Sr. · 2007-11-13 14:44

Yes, I have - and it works correctly.

When I bump it back up to 16X, it gets unpredictable. Sometimes the evaluations in the main object don't work, then other times, it moves to the driver.

When at 8X, it works correctly/stably and the same as it does on the Prop Stick (at 80Mhz).

hippy · 2007-11-13 15:10

Paul Sr. said...
Yes, I have - and it works correctly.

When I bump it back up to 16X, it gets unpredictable. Sometimes the evaluations in the main object don't work, then other times, it moves to the driver.

When at 8X, it works correctly/stably and the same as it does on the Prop Stick (at 80Mhz).

From an earlier comment it seems you've read these, but for others, see previous discussions at -

http://forums.parallax.com/showthread.php?p=687140
http://forums.parallax.com/showthread.php?p=679308

Spin help - What am I missing

Comments