Touch-LCD & BS2p

johnny_b

Hi Guys and Masters of Stamps,

I have some touch-panel graphic LCDs to work with, giving me a headache.
EA-KIT 129 (http://www.lcd-module.de/eng/touch/touch.htm)

Anybody has some experience with them? They are 1st class modules from Germany, work
great, fast, easy to use and program, full serial interface, lots of flash onboard, etc.

The display requires 4-wire (2-way,synch.) serial connection towards the Stamp.
The data-flow is easily done by using the SEROUT and SERIN·TPin\FPin commands.
Text and macro command data is sent out, and touch-panel info is received by the Stamp.

However, I have problems with some bug. Using the same connections to a PC, everything
is 100% OK. The Stamp on the other hand, seems to lose the sync on the input somehow
randomly, independently from data speed (1200 - 38kBaud). In this case, the display waits
for the sync signal for 25 secs, then cancels the sending. This problem occurs when a longer
operation·(>100ms) takes place in the Stamp.

A sample code:

do
serout ..something...
serin inpin\inFpin, baud, 100, nodata, [noparse][[/noparse]char]
nodata:
loop

In this case, everything is fine. But if a longer operation,·or a longer pause takes place,
the data sent from the display (touch panel) is sometimes lost:
the BS2p is halted (waiting for serial data?), the display waits 25 secs.... then the display
restores sync line levels, and both continue to operate, and the touch info is lost.

This is random. The wires are ok, checked, and work fine with a PC. If there is an other serial
command to an other pin inside the stamp, the out and in FPin states can go crazy on the
BS2p side, making the whole connection unstable.

There are·MAX 232 ICs on both sides, but the situation was the same without them.

Anybody has some experience with this display family (EA-KIT)? Any suggestions?

br, Johnny


·

Bruce Bates

Johnny -

Due to the lack of a hardware UART, the PBASIC Stamp is incapable of full duplex RS-232 communication, which is what it appears you may need here. The fact that it works with a PC (which HAS a hardware UART) almost makes this thought a certainty.

All is not lost, however. Attach a Maxim MAX3100 to the Stamp and that will add a hardware UART (albeit external) and permit full duplex communication. Here are some applications notes to help you, thanks to Dr. Tracy Allen:
http://www.emesystems.com/BS2IrDA.htm

Although those applications notes are intended to show the IrDA capabilities of the MAX3100, they also show how the registers need to be loaded and set for proper transmission, which is the whole key to using the device.

Regards,

Bruce Bates

Post Edited (Bruce Bates) : 12/28/2005 2:10:02 PM GMT

johnny_b

Thanks Bruce, but please make this clear to me: shouldn't the sync signals make
same-time two-way communication possible on BS2p? I mean while the sync signal
is kept low, the data transmission waits, when it goes to high, data comes through?
Right? While the stamp is sending data (or doing sg. else) the sync line is "off", when
the Pbasic program reaches a serin command, the sync line enables the transfer?
I am starting to be confused ;-)))

br, Johnny


·

Bruce Bates

Johnny -

Everything that you say may be true. The question that hasn't been asnwered however, is does this device REQUIRE full duplex communication, as I'm suggesting that it might.

Using the method you are sugesting, you are only running bi-directional half-duplex. That may not be adequate due to the timing considerations of your device.

See the difference now? Half-duplex will never be full duplex, no matter how fast or slow the turn around time is. Full duplex will ALWAYS be faster, since it is concurrent and simultaneous. Half-duplex by its very nature can only be concurrent.

Regards,

Bruce Bates

Bruce Bates

Johnny -

Just a few additional comments, now that I've been able to download the data sheet. The web site was "busy" earlier.

I see nothing in the documentation that would indicate that full duplex is REQUIRED. For now I'd say that shoots that theory to pieces. What baud rate are you using to communicate with the Stamp? Additionally, are you using a a MAX-232 or other line driver between the Stamp and this LCD? I'm just concerned that the higher RS-232 voltages may be necessary for this device.

I noted with some interest that the RS-232 connection on the PCB is quite non-standard. I trust you took that into consideration.

Just in passing, it seems there are two reasons for the flow control lines. The first is that this device only has a 16 byte internal buffer, and the other is due to the possibility of keypad or keyboard input. This is just for reference, and nothing else.

What is it that you were able to accomplish with the PC --> LCD connection, that you can not accomplish with the Stamp --> LCD connection? Apparently there is specialized PC software available to drive this device, unless I misunderstood the data sheet. I wonder if that has any bearing?

Lastly, I didn't happen to notice any start-up timing requirements either. Most LCDs require some sort of initialization, and a determinite pause (varies by LCD) thereafter for the initilization to take place.

Regards,

Bruce Bates

Post Edited (Bruce Bates) : 12/28/2005 7:07:56 PM GMT

johnny_b

Bruce,
Yeah, I try to have half-duplex communication, due to the nature of the Stamp. I am using a max232, the lcd has a max202 on-board,
or direct 5V communication is also possible, using different pins. I have tried both, same results. On the PC, I just ran a normal
terminal window (e.g. PBasic debug window with sync enabled) Sync is REQUIRED for the LCD. If the sync lines are not connected,
then the same "hang" effect happens, as I described, so it seems that there is something wrong with the sync signal from the BSp.
This bug is independent from the data speed. I have tried 1200, 4800, 9600,
19k2, 38k4 and 115kBaud. Now I am using 9600. ON the LCD, the data speed is jumper selectable. The LCD sends the touch info out
as the touch event happens, and can receive data continuously. With the PC, everything was working, as it should. The BSp could
also do these, but with random success or data loss. No start-up init required, the lcd is smart, several macros are programmed
in it, such as a startup macro. If I only send or receive continuously to the lcd, it works fine. The problem starts, when I send
info continuously to the lcd, and check for input periodically.
br, Johnny

Chris Savage

johnny_b said...(trimmed)
Thanks Bruce, but please make this clear to me: shouldn't the sync signals make
same-time two-way communication possible on BS2p? I mean while the sync signal
is kept low, the data transmission waits, when it goes to high, data comes through?

I believe what you mean is flow-control (not sync).· And yes, if the device supports flow control, it should not be trying to send when the stamp says it's not ready yet.· However, there may be a limit in the outgoing buffer to how much data it can store while waiting.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com

Bruce Bates

Johnny -

I trust you realize that you will need the control lines (you call them synch) on both the SEROUT and SERIN. Otherwise, indeed the "synch" will be lost. Due to the way that you're using them the SERIN and SEROUT are true companion commands, not just associated PBASIC commands, and must be identical in all ways possible. Additionally, the control lines (sync lines) must pass through the line driver as well, presuming you are using one for the signal lines (Tx and Rx).

With a PC they are used on EVERY I/O if they are so specified. It would be quite helpful if you showed us an entire program, rather then just incomplete program segments which won't even pass successfully through the IDE/Editor. This way we can see exactly what you're doing, and possibly even try to replicate the problem with some other type of device as the "slave". It's unlikely that it's a bug, but one never knows.

When you use the word "hang" I presume you mean a SERIN timeout? Have you tried increasing the SERIN time limit? If you are using a BS2p (and not a BS2px) the timer units are 1 ms each. The range can be from 0-->65535 units. One other thing to consider I guess, is if the prior SEROUT or some external action (whichever is appropriate) doesn't cause the LCD to produce any output, then the Stamp's SERIN will surely timeout, regardless of the length of the timeout parameter. What I'm saying is, just make sure that a responce IS EXPECTED.

If "tapping" (evesdropping) the RS-232 line would help, head over to the WinTech web site, and look at their demo-ware. Pick up a copy of of Listen32, which is essentially a software RS-232 datascope which will run under Winodws. Real handy to "tap" the RS-232 line in situations like this. I don't know if it can trap the conditions of the control (synch) lines or not. I've never used it for that type of application.

Regards,

Bruce Bates

johnny_b

Okay, here's the application:
slot0: start
slot1: main
slot2: set

it is incomplete at the moment, but the most important part is there.

After boot-up, the alarm waits for a remote-controller signal. Then asks for an iButton key. The main window displays date and time from a PocketWatchB module, and two temperature readings from 2 dallas 1622 chips. if a touch key is pressed, the display changes to the window control display, etc.

The touch LCD sends 1 byte long data for each touch, a number from 1-12, according to the touch events.
Sorry, but some parts are in Hungarian ;-))))

br, Johhny

johnny_b

oh, and all lines are passing through the max232. this attached schematic is a previous version of the "universal board", but the rs232 lines are essentially the same.
johnny

johnny_b

sorry, dallas ds1822 1 wire thermometers...

johnny_b

Yeah!

I found out what the problem was. I have used two-way communication with flow-control, both ways. There was a chance that the Stamp wanted to send data, but the LCD did not let it happen, because it wanted to sent touch info, and the two devices were waiting for each other's flow control signal. The situation normalized after the lcd abandoned the sending, and the Stamp finally was able to send the data to the LCD, but the touch info was lost.

A similar time-out would be a good idea to include in the Stamp firmware for the serout command·;-)

Anyway, I have solved the problem using non-flow-controlled info sending to the LCD, and flow-controlled input from the LCD. So no touch info gets lost, and no "lock-up"s occur any more.
I hope this info was useful for someone ;-))
br, Johnny

Bruce Bates

Johnny -

Can you surmise from this that the reason it worked with the PC connected was that the PC was able to capture the incoming data and then turn the line around faster than the Stamp could? If not, how do you explain the difference, where the PC worked, and the Stamp didn't?

Glad you found the answer, but I'd be tempted to mention it to the maufacturer. That "lock-up" really shouldn't happen if the flow control is properly respected by both parties. If they DOCUMENT that a not ready on a SEROUT which continues more than nn mS, one needs to enter a special procedure, that's another story, but I saw no such warning.

As a suggestion, an "attention" control line might be appropriate, if the smart LCD has something to say that needs attention before the further ordinary back-and-forth communication, the attention line is raised. That way, if "attention" is raised, you do an additional SERIN prior to the next successive SEROUT. This continues until the attention line is no longer raised. Then you continue with the pending SEROUT. I hope that makes somes sense. Typical coding follows:

Check_Pending_Output:

IF attention = 1
GOSUB Special_Serin
GOTO Check_Pending_Output
ELSE
SEROUT .....


Regards,

Bruce Bates

johnny_b

Bruce,
Yes, that was one of my ideas also. But it seems the LCD can also force sending touch data between two bytes (which were sent with one serout command...), so there we go again...
A simpler way for me is to totally abandon flow control for the serout command. Simpler, and with using a touch key, the contents of the display are always changed, so a data loss is not noted. When this situation is not possible to occur (no output is being sent to the lcd, just waiting for touch input), I continued to use flow control for serout. This solution seems to work flawlessly, I have tested this thoroughly.
I had this "deadlocking" problem since 3-4 weeks, which halted the whole project... So now I am happy ;-)
Have a Happy New Year!
br, Johnny