LCDproc development and user support list

Text archives Help


[Lcdproc] Some help with multiple heartbeat characters


Chronological Thread 
  • From: ethan.dicks at gmail.com (Ethan Dicks)
  • Subject: [Lcdproc] Some help with multiple heartbeat characters
  • Date: Wed, 6 Apr 2016 17:17:46 -0400

On Wed, Apr 6, 2016 at 4:31 PM, ZV <zv at ziva-vatra.com> wrote:
> On 06/04/16 20:51, Ethan Dicks wrote:
>> Wow... that's reaching back.
>>
>> I wrote the original pic-an-lcd driver, many, many years ago...
>
> Heh, I never used it before, as there was always an abundance of
> parallel ports on my machines. However now with parallel ports vanishing
> as well, the only port I have is USB, and the Arduino appears as a
> serial port to the PC, so seemed like the easiest thing to implement in
> order to get something working.

I also used to use the parallel port a lot and have had to stick an
AVR in the mix.

> Plus pic-an-lcd being so old, I figured most mainstream lcd software
> should have support for it, and the bugs should be ironed out by now. If
> I wrote my own interface I would have to write, debug and maintain a
> driver for lcdproc too.

Yes and no. The pic-an-lcd was, for a short time over 15 years ago, a
popular way to do this. It had its moment in the sun and was
eclipsed. Now, I think it's older-than-old and not well supported at
all.

If you'd asked before starting, I would have suggested adopting the
Matrix Orbital serial protocol. *That* has a lot of application
support since they were one of the early and popular commercial
vendors. LCDproc started with Matrix Orbital support from day one. I
still have a number of MtxOrb displays and do regression testing on
them. There's even an emulator for PalmOS (PalmOrb) that I
occasionally use. I think there is at least one Arduino-based
implementation of MtxOrb floating around. The advantage, of course,
is that you wouldn't have to write any drivers there either, and it
has additional features like keypad support.

The old pic-an-lcd driver probably used more of the native
functionality, but as there became more variants on HD44780 LCD
hardware connections but with the same underlying chip features,
things were completely re-written to just force all the logic into a
common section and have unique "transport layer" code for each
variant. It means having to fix lower-layer bugs in fewer places than
back in "the old days" when each driver was more standalone.

>>> I have got a version working, however I seem to have the heartbeat
>>> appearing multiple times...
>
> It seems to happen with both. I will send you some pictures of it.

I've seen the pictures. The fact that you are alternating a heartbeat
char (0x07) and a block char suggests to me that something isn't
processing an escape char properly. Your heartbeat1.jpg shows 2
bargraphs, the lower one is empty (zero value) and properly bracketed.
The upper one looks like @#@#@#@# (I can see 4 hearts and 4 solid
blocks) and the rendered characters are running over the right
bracket. So it looks to me like your code is parsing the stream from
the LCDproc server and rendering this as two LCD characters, either
0x07 and 0xFF or maybe 0x07 and 0x00, depending on which value is the
BLOCK_ICON (old LCDs have a permanent solid block at 0xFF, some
alternate char LCDs do not so there's code to supply a solid block
when the ROM character set does not).

Your heartbeat2.jpg looks like what's supposed to be a histogram with
different vertical values from left to right, but those random-height
blocks are interleaved with "hearts" (0x07) which would be from the
same cause as the hbar.

Check what chars are getting sent to your LCD (via debug mode on LCDd)
and check on how you are handling character escape.

-ethan




Archive powered by MHonArc 2.6.18.

Top of page