LCDproc development and user support list

Text archives Help

[Lcdproc] OSX + MtxOrb Driver

Chronological Thread 
  • From: ethan.dicks at (Ethan Dicks)
  • Subject: [Lcdproc] OSX + MtxOrb Driver
  • Date: Tue, 2 Sep 2008 15:56:32 +1200

On Tue, Sep 2, 2008 at 2:18 PM, Kevin Ogden <kdogden at> wrote:

(BTW, I copied the lcdproc list back in because these are the sort of
questions that are good to have on the list archives - folks find the
initial questions and get frustrated when the answers are off-list and
not archived).

> On Aug 31, 2008, at 9:49 PM, Ethan Dicks wrote:
>> On 8/31/08, Kevin Ogden <kdogden at> wrote:
>>> Hey, how hard would it be for the MtxOrb driver support straight serial
>>> LCD's under OSX?
>> It should already. I was using such a setup last year on my Macbook Pro.
> Do the macbooks have serial ports? Or were you using a USB<->serial dongle?

USB<->serial dongle... in that case, a "GUC232A" which took a bit of plist
fiddling to install. :-/

> I need to pick up a more modern board eventually. This Intel D865GSA is
> pretty quirky.

I haven't done much with MacOS on non-Apple hardware - just one
install to prove to myself it worked.

>>> When I tried running LCDd w/ a properly setup config file it just kinda
>>> sits
>>> there...

>> How are you invoking it?
> /usr/local/sbin/LCDd -d MtxOrb

One thing to try is to test-run LCDd from your build directory - one thing
that _can_ occasionally happen is that LCDd can't find its libraries. If
you sit in the top of your build directory and run it as...

./server/LCDd -c ./LCDd.conf -d MtxOrb

... it will use a local copy of the LCDd.conf and should always be
able to find the driver files.

Also, you can invoke it with "-r 5" to crank up the logging level, but
I always compile with debugging turned on, since I do development,
and I don't recall what the default code will log if you _don't_ enable

> It looks like it wants to think about working but nothing happens with the
> LCD. My config file is pointing at the right device and everything.

Looking at the startup messages from _my_ LCDd, it should be
setting contrast, turning off wrap and the cursor, etc., then quickly
blasting out the "welcome" message and going to the "0 clients/
0 screens" screen and idling.

> Not that it makes much difference but it's an LK202-25 serial 20x2 instead
> of the LK204 20x4.

There is a difference in internal RAM addressing on a HD44780 between
2 lines and 4 lines, but the MtxOrb backpack ought to be the one worrying
about that, not LCDd.

> Call me sick but I have a VAX 4000-200 running NetBSD that I use as an end
> table/space heater. It's fun to hack on though. I have an old VAXstation
> 3100 in the closet that runs Ultrix that I fire up every once in a while.

Nice. I don't have any modernish VAXen that small - I have a couple of
VAXstation 2000s and a couple of MicroVAX IIs, but those top out with
so little memory that they really only run stuff from the 1980s well.

>> The two most important things to share are the command line you are
>> using to invoke LCDd and your LCDd.conf.
> I'll see if I can dig up the LCDd.conf tonight.... it's stock except for
> telling it to use the MtxOrb driver, setting it for 20x2 and pointing it at
> /dev/tty.serial1 for the serial port. Baud rate is the default 19200.

That all sounds right.

>>> The display is an old serial MtxOrb LK204 20x2 LCD.
> I used to use it all the time with LCDproc on my old FreeBSD box. It worked
> great in my old Sun Ultra 2 running Slowlaris as well. Unfortunately I
> don't have that box anymore. Probably the last really interesting SPARC
> desktop.

I have a wad of SPARC hardware as well, but only a rackmount Netra
(telco-version of an Ultra 60, but that does _not_ support a graphical
console - there's sheet metal in front of the keyboard and video card
ports) with an UltraSPARC. I got it to twiddle with Solaris 10.

Long ago, back in the LCDproc 0.3.x days, I started to port LCDproc
to Solaris, but it was monolithic, not client-server, so the sticking point
was that Solaris didn't put anywhere near the amount of useful into
into /proc, and my kernel fiddling only coughed up about 60% of
the desired info for the standard LCDproc client screen. Now, of
course, with the client-server model, it pushes all that difficulty to
the lcdproc client program, not that it matters to me much; I only
run 'lcdproc' (the client) to test things like the "K" clock. In normal
operation, I'm usually running my own clients to monitor things
around the office and the local weather and play tunes on XMMS.

> I don't know what it is about serial and parallel ports but they usually
> just plain always work. I can NEVER say that about USB.

I'm in agreement there.

> Onboard serial port on the Intel D865GSA motherboard. It only has one but
> I'm not using it for anything at the moment.

Got it. I didn't understand what your platform was at first.

> I've got a couple of 4-port PCI serial cards in my closet but I doubt they
> are supported by OSX. Might be funny to try though.... dangle a couple
> VT220's off the OSX box LOL Hell they might work, they're pretty standard
> 16550 UARTs.

I have used 8-port PCI serial cards under ancient (pre-9) versions of
RedHat Linux. Fortunately, I haven't had to update that machine in
several years, but when I did install the card, it was a right pain.

> I had similar issues with FreeBSD a while back with various USB devices. I
> guess hot pluggable devices were an afterthought with UNIX. I don't know
> too many VAX/PDP11 Unibus/QBUS machines that had any hot pluggable ANYTHING
> except maybe terminals and SCSI drives and even that half the time could
> cause kernel panics.
> Damn, I sound old.... I'm not even 27....

Heh... I used to twiddle with that era gear when it was new or nearly new.
not quite as young as you, but I get the sentiment. I cut my teeth on
that stuff
when I was 18 - my first UNIX install was Ultrix 1.1 (4.2BSD with lots of
vendor extensions to simplify life with DEC peripherals) onto a VAX-11/730.

Some parts of "the good old days" I don't miss. ;-)

I suppose if I ever got really, really bored, I could port LCDd to VMS.
Except for our VAX8300, for which we never bought a DMB32, so
only had the console ports, we always had plenty of serial ports on
our VAXen. I would have _loved_ to have had LCDproc running on
something, say, about 10 years before it eventually came out. I was
working in a 100% DEC shop at the time, and it would have been
a fun thing to have running in the machine room. I can do it now,
but there's not as much point to it (of course, the easy way to do it
now is to run VMS under simh).

>> If you do have slightly-out-of-date code, the symptoms,
>> for Matrix Orbital displays, would be random character flashing
>> on an otherwise-working screen, not complete freeze-up.
> Like extra 'V' characters on the display with an occasional weird character
> thrown in?

Yep. Go get a copy of the code that's less than three months old and
that problem should vanish.

>> You could also grab the code, compile the Matrix Orbital driver
>> for debugging, and post the results of just starting LCDd with
>> debug level set to '5'...
> If I get a chance, I'll try that tonight.

That's probably a good next step.



Archive powered by MHonArc 2.6.18.

Top of page