Re: MtxOrb older models not supported (anymore ! ?)

On 2012-03-05 19:27, Ethan Dicks wrote:
> On Mon, Mar 5, 2012 at 12:39 PM, Markus Dolze <[email protected]> wrote:
>> On 05.03.2012 13:21, Liselore Vermeulen wrote:
>>> I'm using LCDproc at my workplace for some time (a customised version of 0.4-pre9)
>>> where the Matrix Orbital 2041 display is the only visualisation available.
>>>
>>> We have a large number of these devices.  They are MtxOrb 2041 Rev. 1.3 devices,
>>
>> Matrix Orbital displays are the reason why LCDproc exists. Therefore I
>> guess we will support even older devices. There has been a lot of work
>> at the end of the 0.4-series on the MtxOrb driver and I do not guarantee
>> that everything went into 0.5.
>
> As someone who was working on the code back to 3.x, even I have no
> idea if all the work from late 0.4 made it into 0.5.  There weren't
> very many MtxOrb owners left by then.  Most people moved to Crystal
> Fontz or other devices.
>
>> Two settings in LCDd.conf are important when using older devices:
>>
>> Type = lcd
>> hasAdjustableBacklight = no
>
> Yes.  It's essential to get those right no matter what Matrix Orbital
> device you have.
>
> I have had a Matrix Orbital VKD204 for a long time (13 years or so).
> It's a VFD, not an LCD, so I can only test certain aspects of the
> MtxOrb driver.  Having been through some driver testing about 5 years
> ago, I know that we tested against my VFD and had to make some
> assumptions about LCDs.  I'm always willing to run regression tests
> against my ancient VFD.  I keep it within a serial-cable reach of my
> desk.  I would do the same for an LCD, but I have no older ones (just
> a newer Matrix Orbital model with an RGB LED backlight)
>
> -ethan
>

Ok,...
so excuses for the long delay in responding to this thread.

First of all,... the suggestion to "play around" with type and 
hasAdjustableBacklight didn't do the trick for me.
Our devices are Type=lcd (lcd2041),
but we have 2 models: the "legacy" types (Rev 1.3) with
only one single output, and the more recent type (PCB Rev 2.0), with 3 
GP contacts.

The code to set c.q. clear the GPO, writes two bytes ("\xFEV" c.q. 
"\xFEW"), however the newer version (PCB2) having 3 GP contacts, 
requires 3 bytes (third byte being the address of the GPO).  Hence if 
only 2 bytes are written to the board, the next time something is 
written to the display, the first byte of that is "consumed" as address. 
  This way, on the recent version, the display becomes
rapidly distorted.

Furthermore, the older version does not support retrieval of model type,
nor firmware etc.  We thought it would be nifty to have a possibility to
configure a "default model" (in case the request for model id does not 
respond).

The chosen timeout when waiting for communication (500 micro seconds), 
is only just enough to transmit one character at 19200 baud.
This timeout doesn't take into account processing time of the PCB, and 
is certainly not enough to cover for the reception of more than one byte.
We do have devices configured to run at lower speed, and the 
select()call times out prior to arrival of the response.

Especially since the module can be configured to communicate with 
devices at different baudrate, this timeout should be:
- or configurable
- or calculated based upon the baudrate and the size of expected bytes.



We thought it would be preferred to "extract" properties of the device from
the device table (modulelist[]). like:
- number of GPO
- whether 1 GPO is addressable or not
- whether the model implements a difference for legacy devices
- this could also cover the (removing requirement for configuration):
   . hasAdjustableBacklight
   . type (lcd c.q. vxd) (kd covers the presence of keyboard)


Our boards are used in a semi-embedded system, and we only want to 
support one
single version of program configuration, we needed a single 
configuration-file that
supports both versions.

Since efforts are being made to retrieve model information
(and firmware version) from the device, I think this information (if 
received)
should be used to the fullest.  The model information can - for instance -
indicate info like Type, Size, hasAdjustableBacklight.


Hence we adapted the code, which I propose as patch:

- attempts were made to keep the behaviour from the 0.5.5 code.

- through configuration keys, the behaviour can be altered.

- all reading from and writing to the device is done through a "timed" 
function that will return (even when action was not completely finished).
   e.g. when reading 2 bytes for firmware revision, and the device only 
responds with one single byte, this would otherwise "hang" the driver

- ADD configuration keywords: SingleByteTimeout (format: sec:usec 
default: 0:500) allow the timeout for reading and writing (tv-values for 
select) to be configured.
The hardcoded values (500 micro seconds) will only allow one single 
character to be communicated at 19200 baud, the timeout doesn't allow 
for configured lower baudrates

- ADD configuration keyword: FallbackModelId (format: number default:0)
   specifies the device-type to select if no response to model-request AND
   if configuration keyword FallbackToLegacy is set

- ADD configuration keyword: FallbackToLegacy (format: on|off default:off)
if on, and the device does not respond in a timely fashion to a "get 
model" or "get firmware version", select "FallbackModelId" as model id.

- ADD configuration keyword: LegacyDevice (format: on|off default: off)
   activates (forces) legacy implementation (Revision 1.3).
   This includes "only one (non addressable) GPO" (no arguments for 
instruction "V" and "W").





and further there's a tiny patch to clients/lcdproc/disk.c
that allows compilation with the legacy compiler gcc 2.95.


greetings.
L.V.

_______________________________________________
LCDproc mailing list
[email protected]
http://lists.omnipotent.net/mailman/listinfo/lcdproc