Odd COM3 problem....

[Genesis]

Anyone else having problems writing to Parallax serial LCD from the ZX on COM3?

I've got an application that works perfectly on the Parallax 2Pe with the display at 19200 baud, and am trying to port it to the ZX. All the other I/O - a Dallas 1307 RTC chip, the TLC2543 ADC chip that I'm using, and a bunch of other hardware - all work fine. I've got those parts figured out.

However, writing to the Parallax serial LCD is flaky. The only thing their documentation states in terms of delays is that one must wait a given amount of time after issuing a "clear screen". Ok, no problem there.

But if I issue a bunch of writes of varying data, eventually I get a scrambled screen. Positioning commands fail to execute or move the cursor randomly, or other characters are garbled in transit (mostly positioning and other command codes though.)

The odd thing is that if I kick off the other tasks I intend to run on the ZX (so there are more tasks running) it gets worse - even though those tasks don't do any I/O to the LCD (they are talking to other devices in the system.)

Oddly enough as well, turning the baud rate down to 2400 stops it....

Anyone else seen something like this? Am I simply running into a hardware limitation - undocumented - on the Parallax LCD controller?

[DH*]

I've never used that serial LCD but have found that all of the others I have used require a delay (20-25ms) after any positioning command.

[spamiam]

[dkinzer]

I don't have a specific answer to your question but a couple of things come to mind. Firstly, the Stamp and the ZX handle serial I/O in fundamentally different ways. The Stamp's I/O is unbuffered. When you output a character, the processor outputs each bit of the frame and then proceeds to the next command. With the ZX, the character is put into a queue of characters to be sent and the processor proceeds to the next command immediately. The actual outputting of the character is handled in the background and the timing for that process is derived from a series of precisely timed interrupts. The downside is that foreground commands that disable interrupts can interefere with the serial transmission and reception process. To determine if this may be occurring in your system you can disable all other activity (the #if 0 ... #endif pair is useful for this).

Note that with the Stamp, it is best to run the serial I/O at the fastest possible rate because that minimizes the delay incurred by your program for each character transmitted or received. For the ZX, it is best to run the serial I/O as the slowest possible rate because that reduces the overhead and makes it less sensitive to periodic disabling of interrupts by other operations. The fact that the problems seem to disappear when you slow down the I/O to 2400 baud may suggest a serial timing intereference problem.

Dave's suggestion of a required delay is worth investigating. Your observation that lower I/O speed fixes the problem may indicate that a missing delay is the problem.

[spamiam]

[Genesis]

[DH*]

I believe the Parallax LCD controller was designed by Wirz Electronics and originally sold as SLI-OEM for mating with the LCD of your choice.

The SLI-OEM documentation stated...

[Genesis]

You may have a point here..... the only way to insure that a delay will be taken is for the code to wait for the queue to drain before writing the positioning command, then write it and wait for the queue to drain again - THEN take the delay.

Otherwise you can't be sure that the delay actually occurs before other character(s) go down the pipe.....

I'll try that and see if it makes the problem go away....thing is the Parallax docs only note a delay requirement for a clear screen command - not for anything else.... it doesn't ball up when connected to a BS2Pe, but the stamp may be slow enough that it can't provoke the problem......

I ordered up a couple of other displays and that other "backpack" noted above, as they have much more friendly power numbers. Going from 30ma to about 5ma with the backlight off turns into a BIG difference in battery life......

[mikep]

I too have a serial LCD driver (LCD07 from Dr. Anderson) which shows a similar problem. If I drive it too fast, the PIC resets itself which takes 2-3 seconds to bring back the display. This is VERY annoying when I'm trying to use the display to monitor the status of my 10Hz robot control loop. There is no flow control or any method to find out if the PIC or LCD is busy and the last thing I want is to delay my control loop waiting for the LCD display.

I now have a more expensive LCD driver that I'm going to try in the next few weeks.

[dkinzer]

[spamiam]

[Genesis]

The Sparkfun interface has one MAJOR problem - its backlight control is severely broken in that it cannot be shut completely off!

Specifically, 124 128 is supposed to turn it OFF. It does not - it turns it on full.

All the OTHER settings (129-157) appear to work as described.

This is nasty, as the backlight is a huge part of the power consumption of these displays. While shutting it "almost off" can be done, you get a LOT of (very visible) flicker interface with the refresh on the display, leading to some interesting moire effects.

Anyway, just thought folks should know about this - I'mupset about it because it makes the interface, for my purposes, completely useless - I've got two soldered-up boards that are of course non-returnable and neither works right.

Oh, I also get occasional freak-outs with it at 9600 bps, and it doesn't support 2400 - at all.

There went a quick $50 in the toilet.

Grrrr.....

Any other ideas?

[Genesis]

Ok, so assume I need to talk to something async - and can't use the system port, because I need it available for programming and data dump.

So - if I must use a software port, is there a way around the timing problems?

Let's assume I can afford a task that "keeps the processor" for a millisecond at a time (1 character at 9600bps)

I think there is, no? What if I was to use SHIFTOUTEX instead of the build-in async I/O routines? SHIFTOUTEX holds interrupts off during its execution, yes - therefore, there should be no timing problem.

Will this work? Or am I shooting at a target that WON'T work?

It appears - from what I can determine - that if I was do something like this, it SHOULD work:

Data byte to output = 0x20 (ascii " ")

register.timerspeed1 = (what goes in here to get a 1/20th ms bit time?)
outb = 0x20
outb = outb or &H100 ' Add start bit
outb = shl(outb, 1) ' Make space for the stop bit
outb = outb or 1 ' Add the stop bit
shiftoutex(datapin, garbagepin, 10, outb, &H04, 2) ' 2 = 1/10th ms bit time


Should work, no - and should avoid timing problems with async serial on the other end.... or am I missing something?

If I then have a task that does GETQUEUEs and, when it sees bytes, outputs them using the above, I've got a bit-time-invarient serial output routine - I think!

[spamiam]

[Genesis]

I have posted to their forums on the issue - and got back stony silence.

The code in the unit is CLEARLY not what is published either. What's on their web page shows two commands that they do not document in the data sheet (turn on and turn off the backlight, at the saved value) which also do not work.

I got one of the blue-on-white LCDs and it draws MUCH less power with the backlight on - I'm down to ~5ma with the backlight at "minimum" and ~60ma with it on "full", which is far better than the Parallax display - which pulls ~20ma with the backlight OFF, and north of 100ma with it on!

But - the glitching problem is still there. I've put delays in positioning commands, which I know can cause this, but one of the major problems with the glitches is that if you get the wrong kind of glitch you can scramble the controller's settings due to the passthrough commands - you now have an UNRECOVERABLE situation with the display (without power-cycling.)

Under stress I can reproduce this quite easily.

That's unacceptable for obvious reasons.

Problem is, I'm not sure I have a better solution available no matter who I go to in terms of buying something.

I've yet to find a better "backpack" type device - there are a couple more but none support the backlight, and I need that capability.

It appears I may be left with the unpleasant requirement to talk to the LCD controller directly thorugh some circuitry of my own - due to wiring constraints (the display is at the end of a cable) I can't really do it in nibble mode directly of the ZX - it has to be through some kind of serial link.

This application is one in which I cannot live with having to power down the controller during use. That's flatly impossible when the unit is in actual use - the power connection is going to be inside a sealed container and not available to user at that point!