parallax LCD cursor off mode not working

Does anyone have any experience with the Parallax LCDs having this issue? Sending Dec 22 is suppose to
"Turn the display on, with cursor off and no blink." The funny thing is, this used to work.
I've just tested this again, and all of the commands 21 thru 25 do not work. All other commands work as
expected. I've purchased a new LCD thinking that I fried mine, but it does the same thing. Also, another
propeller with the same code mimics the behavior. ????
CON
 _clkmode = xtal1 + pll16x
 _xinfreq = 5_000_000

 Baud = 19_200      ' baud rate for LCD comm.
 LCD = 0

PUB Main | i  
 dira[LCD] ~~
 tx(22)              ' LCD ON, cursor OFF & NO Blink
 tx(12)              ' Form Feed
 waitcnt(clkfreq/10 + cnt)     ' Must wait after a Form Feed
 tx(128)
 str(string("Hellooo"))

PUB Tx(Tx_byte) | t

  Tx_byte := (Tx_byte | $100) << 1
  t := clkfreq / Baud + cnt

  repeat 10
    waitcnt (t += clkfreq / Baud)
    outa[LCD] := Tx_byte & 1
    Tx_byte := Tx_byte >> 1
I've done some more testing, and I find that if I place a tx(12) above the first send to the LCD, it works. But
I don't know why. Like this:
PUB Main | i   
 dira[18] ~~
 outa[18] ~
 dira[LCD] ~~
 tx(12)              ' EXTRA CODE INSERTED TO FIX? ERRROR
 tx(22)              ' LCD ON, cursor OFF & NO Blink
 tx(12)              ' Form Feed
 tx(17)
 waitcnt(clkfreq/10 + cnt)     ' Must wait 5ms after a Form Feed

Does anyone know of the cause of this odd behavior?

Thanks, Daniel

Comments

  • 8 Comments sorted by Date Added Votes
  • The idle state of any serial port is normally 1. When you initialize the serial line, the signal defaults to 0. Stick an
    OUTA[ LCD ] ~~
    
    before the
    DIRA[ LCD ] ~~
    
    to fix it
  • Well, I thought you had to declare direction before an output. But this works. And the really odd thing is, I've used this LCD
    for many years the other way, as in the code above, without issue. So the problem is solved, but the mystery remains.

    Thanks, Daniel
  • Mike GreenMike Green Posts: 22,584
    edited September 21 Vote Up0Vote Down
    If you don't have the OUTA first, the I/O line starts with a logic 0. The serial receiver won't recognize the first character because it needs at least one idle bit (1) then a start bit (0). Depending on what you send immediately it may ignore or mis-interpret several characters. It's often a good idea to leave the serial line initially at idle for at least one character time in case noise on the line got the receiver confused.

    The OUTA is first so the serial line starts up in the 1 state when the DIRA is executed. Often serial receivers have 3 states: open or unknown, 0, and 1. Until you execute the DIRA, the I/O pin is in input mode (open)
  • Mike, Thank you for the clarification. I like knowing the why of how things work. Makes perfect sense.
    I don't know why it had worked for so long up until now, but I will implement the LCD properly from
    here on out.

    Daniel
  • maybe you had some pull-up-resistors, then it does not matter if dira or outa is first.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobots wrote: »
    maybe you had some pull-up-resistors, then it does not matter if dira or outa is first.

    Mike

    No, I've always connected the data line of the LCD directly to the Prop pin. I like using the LCD as a debug device.
    Daniel
  • DRMorrison wrote: »
    msrobots wrote: »
    maybe you had some pull-up-resistors, then it does not matter if dira or outa is first.

    Mike

    No, I've always connected the data line of the LCD directly to the Prop pin. I like using the LCD as a debug device.
    Daniel

    It has been my experience that the actual state of a floating (tristated) I/O is unpredictable. I have seen identical boards where some will be consistently high, others consistently low, and some where it oscillates between the two. No apparent reason for the different behaviors, although I suspect it may be due to the normal variations of chip and board manufacturing. Best to avoid potential problems by making sure the signal is always in a known state via code or pull up/down resistors.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • JonnyMacJonnyMac Posts: 5,870
    edited September 25 Vote Up0Vote Down
    I don't use those displays very often, but when I do, I use the attached object as it has methods I like that that handle display formatting.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
Sign In or Register to comment.