LCDproc development and user support list

Text archives Help

[Lcdproc] Crystalfontz 635 usb lcd noise

Chronological Thread 
  • From: a.foss AT (Andrew Foss)
  • Subject: [Lcdproc] Crystalfontz 635 usb lcd noise
  • Date: Tue Mar 28 22:06:02 2006

Great, could just slow us down enough to overcome, whatever buffer
limits are along the way and probably 250ms is way higher than you need:-)

Now to see what to submit to the project, as a bug or how to fix?

lcdproc folks any suggestions?


Frederick Nacino wrote:
> Andrew
> Good news! CFONTZ633_WRITE_DELAY set at 250 did the job! I get clean
> screens all around!! You're awesome man :)
> So apparantly you are correct CFONTZ633_WRITE_DELAY is apparantly
> missing and much needed in order to poll for receiving data!
> Fred
> Andrew Foss wrote:
>> ok, what I'm stuck on is why 2 lines works. I was on that area,
>> because the 633 has a specific command to set data for lines one and
>> two, only that's different than the command used to set data for
>> lines 1-4(send_bytes_message command I was breaking), thought maybe
>> when set to 2 lines that those commands might be used instead, but
>> that doesn't appear to be the case, unless you tell it you're a 633
>> model, which can be done, but that doesn't look like what we're
>> doing. The base driver is kind of an odd amalgam of the original 633
>> protocol, extended for more lines and models.
>> I think you're right we can assume that that send_bytes_message of
>> type CF633_Send_Data_to_LCD, is actually fine. Then we're still left
>> w/ why 2 lines work, and 4 doesn't, sort of where I started w/ flow
>> control thinking that at this baud rate we're just on the hairy edge
>> of overrunning some receive buffer and need to be told to stop, but
>> if that's the case on the serial then either it's not able to do
>> xon/xoff or ctsrts, since you tried both of those, or it's something
>> annoying like a very small fifo buffer on the uart, but we're only
>> talking maybe 100 bytes here...
>> Each packet sent to the lcd has a CRC, so should be ok, but it's not
>> clear to me that if the lcd were to reject a packet w/ a bad crc that
>> we'd ever know it or resend.
>> the other are that makes me wonder is in CFontz633io.c
>> look for this line,
>> #if defined(HAVE_SELECT) && defined(CFONTZ633_WRITE_DELAY) &&
>> do you HAVE_SELECT in your config.h? I do in mine, but no
>> WRITE_DELAY. What that appears to mean then is we're writing bytes to
>> the usb, 4 command msgs each up to 25 bytes in size each, back to
>> back, w/ no pause. What if there's no flow control to the usb and a
>> small fifo on the uart and we're overrunning it, so some commands are
>> missed by the lcd? That could be one difference between 2 lines and
>> four, we could try WRITE_DELAY(up to 250 according the comments,
>> that's 250 msecs) and/or a better set of tcsetattr options for the
>> port in the init. After each command packet is written we do
>> test_packet, to see if there's a packet rcv'd from the lcd, if there
>> is we never do anything w/ it, so I guess if you were unlucky enough
>> to press a key in that time, we'd ignore it. without the spec, I
>> don't know if there's a resend request command from the lcd either...
>> The other possibility, which I think is less likely, is we have many
>> structures, out, in, COMMAND_PACKET etc. that are never initialized
>> to 0 and a quick look says that all the data fields are referenced w/
>> a length and that length is used and checked so you shouldn't need to
>> init those structs to 0, though some compilers will do it for you
>> anyway, right? Seems like that kind of thing would show up at 16x2,
>> as well.
>> In the screwy screens that I saw, it looks like whole lines are
>> missing, is that true?
>> I'd try building w/ WRITE_DELAY 250 next, since it's easy...
>> andrew

Archive powered by MHonArc 2.6.18.

Top of page