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