LCDproc development and user support list

Text archives Help


[Lcdproc] MtxOrb older models not supported (anymore ! ?)


Chronological Thread 
  • From: liselorev+lcdproc at gmail.com (Liselore Vermeulen)
  • Subject: [Lcdproc] MtxOrb older models not supported (anymore ! ?)
  • Date: Fri, 26 Oct 2012 17:08:19 +0200

On 2012-03-05 19:27, Ethan Dicks wrote:
> On Mon, Mar 5, 2012 at 12:39 PM, Markus Dolze <bsdfan at nurfuerspam.de>
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ebpmodifications.patch.bz2
Type: application/x-bzip2
Size: 15611 bytes
Desc: not available
URL:
<http://lists.omnipotent.net/pipermail/lcdproc/attachments/20121026/5b46b737/attachment.bin>



  • [Lcdproc] MtxOrb older models not supported (anymore ! ?), Liselore Vermeulen, 10/26/2012

Archive powered by MHonArc 2.6.18.

Top of page