hd44780-serial bug?
Graham Smith <[email protected]> Thu, 06 Feb 2014 08:56:34 +0000
| Newsgroups | gmane.comp.sysutils.lcdproc |
|---|---|
| Message-ID | <[email protected]> |
Brief background: Having just renewed an interest in electronics from
many years ago I have been 'playing' with an Arduino and a HD44780
display and, purely as an exercise, thought I'd try use the arduino to
provide a serial interface to the HD44780 and drive it from lcdproc on
my Ubuntu machine. Looking at lcdproc (and not wishing to write a new
driver) I decided to use picanlcd connection type and reimplement the
PIC code on the Arduino. (Mainly because the serial interface to the
picanlcd was well documented). This worked well but it suffered from
display corruption which it has taken me some time to track down.
In the end I have tracked it down to what I believe is a bug in the
hd44780-serial.c code when it works out if it has to transmit a data
escape code before sending a byte of data. I have implemented a small
patch to correct this but I haven't been able to work out how I should
go about submitting the patch to you.
I believe that there are effectively 2 bugs in the code but these only
show up when using a connection type which requires data escape codes or
supports multiple displays - so currently is only seen with the picanlcd
and vdr_wakeup connection types. (Note that this is based on the 0.5.5
release which is current in Ubuntu 13.10 but I've checked the 0.5.6
release code and it hasn't changed in this area).
Problem 1: I believe that the code is attempting to look up the data
escape code for the connection type in use and then adding the displayID
to it, which it does regardless of whether the connection type supports
multiple displays. This is itself a problem as the function
serial_HD44780_senddata is sometimes called with a displayID of 0 (all
displays) or 1 (1st display) even if the connection type only supports a
single display and this means that for the picanlcd connection type the
data escape character is sometimes sent as 0x12 (if displayID is 0) and
sometimes as 0x13 (if displayID is 1) - however the picanlcd code only
expects a data escape of 0x12 as the 0x13 code is used for other
things. So I believe the code should be modified to only add the
displayID if the connection type supports multiple displays.
Problem 2: The code does not currently add the displayID to the data
escape code for the connection type, but rather it adds the displayID to
the address of the data escape character (as it is the address of the
data to be written that is required in the call to write()). This
leads, for the picanlcd connection type, to the code 0x12 being sent for
displayID == 0 and 0x00 for displayID == 1 (0x00 being the
data_escape_min code in the hd44780_SerialInterface structure which is
at the next address).
My fix is simply to use a temporary variable to hold the data escape
character and only add the displayID if the connection type supports
multiple displays. I then pass the address of the temporary variable to
write.
The patch I've created to fix this is given below - I'd be interested to
hear your views and some advice as to how to correctly submit this as a
bug / patch.
--- hd44780-serial.c.orig 2011-08-14 13:29:16.000000000 +0100
+++ hd44780-serial.c.new 2014-02-06 08:21:17.000000000 +0000
@@ -282,7 +282,8 @@
(((ch >= SERIAL_IF.data_escape_min) &&
(ch < SERIAL_IF.data_escape_max)) ||
(SERIAL_IF.multiple_displays && displayID !=
lastdisplayID))) {
- write(p->fd, &SERIAL_IF.data_escape + displayID, 1);
+ unsigned char esc_ch = SERIAL_IF.data_escape +
(SERIAL_IF.multiple_displays ? displayID : 0);
+ write(p->fd, &esc_ch, 1);
}
write(p->fd, &ch, 1);
}
regards
Graham
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com