EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

HCMS-2912 alphanumeric LED display font

Started by Tom Becker September 16, 2005
I'm using an HP HCMS-2912 alphanumeric LED display in a current project.
Internally, it is a 320-bit shift register that drives 40 columns of 8
pixels each. http://cp.literature.agilent.com/litweb/pdf/5989-3181EN.pdf

HP offers an ASCII and Katakana font table in an application note; I
haven't yet found it in file form so I'll probably need to transcribe
it. Either way, I'll end up with a table that I'll want to put in code
space.

Has anyone tackled a font for this, or a similar, display device? Tom



Internally, it is a 320-bit shift register that drives 40 columns of 8
> pixels each.
http://cp.literature.agilent.com/litweb/pdf/5989-3181EN.pdf

I took a look at this and it looks like you have Graphics Display that
has been adapted to use an ASCII set in various sizes. The Katakana is
an normal extension of ASCII in LCDs. On the other hand, All the
Graphic Displays are based on some form of multiplexing 8-Bit 'Dot
Matrix Printer' style output.

You really don't have to concern yourself with the Dot Matrix Printer
format unless there is an option for 'pure graphics' and you really
want to use it [very ROM intensive].

What you need and most likely want is the intialization sequence and
control sequences that HP has provided [with their character ROM and
its interface]. Most importantly, you need to know how to shift
between different sizes.

In sum, the Fonts are likely a Generic convention, but the Control
sequences are likely proprietary to HP unless they choose it for mass
distribution.

I am unclear if you have a serial interface, parallel interface, or
both. Obviously, serial would be the most convienient. If you have
proper wiring, you probably won't hurt anything by trying Hitachi
codes. {Those I have along with their ASCII chart}

[]


> ... the initialization sequence and control sequences that HP has
provided [with their character ROM and its interface]...

No, this device has none of that.

I manually built a font from an HP app note for the device; I just
didn't want to do that. Even Agilent couldn't find a copy of the font
data in the app note as a file; now they do.

The font data is now in EEPROM with the code as a 256x5 byte Block Data
Table; each character must be shifted into the part serially as five
columns of pixels, 40 bits per character, top to bottom, right to left.

That's uncommon, I believe, unlike any LCDs I know. Tom



Upon a second reading of the material.

1. It seems to take purely a shift-in serial format.
2. Unlike Hitachi LCDs there seems to be no memory other than the shift
registers.
3. Unlike LCDs it may not require a particular intialization sequence
as it is without RAM to be intialized.

Since there is no RAM, it is likely that you have to refresh positions
at a particular rate in order to appear to provide a stationary image.
I am not sure how much the display helps do this or if it is entirely
up to the microcontroller. This particular question might decide
between it being a useful peripheral display or demanding its own
microcontroller with buffered input.



> ... Since there is no RAM, it is likely that you have to refresh...

No, the display latches the shift register data into a 320-bit RAM and
does its own multiplexing. No refresh by the processor is necessary
unless the display is animated.

The display is running, G.; I just needed the font. Thanks. Tom



Sorry, once again I seem to not be reading closely.

With the ROM is 5x[something] and the characters being 5X7, I still
suspect that it is just a 7-bit ASCII format and the same as many
generic LCDs. The Japanese Phonetic Chracters are at the high end of
the series. Try

It appears that at some point, the ASCII code converts to a ROM
address in increments of 5 and outputs the five column by seven rows
to an appropriate location.

It would seem that you could create a small program to just count
from 1 to 128 in binary and shift it into the display. That would
give you a visual confirmation. If you add delays, you could
transcribe your own table fairly simply.

If you just want to POKE a value from the LCD's format into the unit,
the first 17 characters [starting with higher nibble at 0000] are
undefined [may come up blank or garbage] and then all have something;
but bx10100000 [reading high to low from the left] and bx11111110 are
also blank.

BX11111111 lights up the whole 5x7 matrix
>
> The display is running, G.; I just needed the font. Thanks. > Tom


> ... once again I seem to not be reading closely...

Yes, both in the HP document and perhaps here - or I have not made
myself sufficiently clear. I no longer need help with this issue.

Four messages back, I thought I'd indicated that I had located (in a
related HP application note
http://cp.literature.agilent.com/litweb/pdf/5988-7539EN.pdf) an
appropriate font, and the corresponding pixel maps and 5-byte codes for
this device for that font.

Since that data seemed not to be available in file form, I manually
transcribed that data to a Block Data Class source text file, which the
BasicX compiler converts to an EEPROM table image (using the Source
method - see the Basic Express Operating System Reference) which loads
with compiled code into the BX-24. My code uses that EEPROM image to
translate ASCII to the required 40-bit serial stream necessary to
properly depict the character on the display.

The display now works as I need it to and I thank you for your assistance. Tom



G. Kramer Herzog wrote:

> Sorry, once again I seem to not be reading closely.

Exactly.

> With the ROM is 5x[something] and the characters being 5X7, I still
> suspect that it is just a 7-bit ASCII format and the same as many
> generic LCDs....

<< cut out a bunch of more text not relevant to original question >>

> BX11111111 lights up the whole 5x7 matrix

You are still not reading the original question very carefully. Tom
knows all of this already and was asking a completely different
question. Perhaps you need to "read twice, respond once" before trying
to answer other people's questions. Tom is one our BasicX experts so he
in general does not ask trivial questions.

Regards,
Mike



> You are still not reading the original question very carefully.>
Regards,
> Mike

Posted the Hitachi44780 pdf in the files LCD section, see page 18
for 'fonts' for Japanese and European in a 5X7 matrix. That seems to
be the answer.

Mike,

I read the original question and the documentation several times. I
have tried to provide constructive input in good faith without being
authoritative.


G. Kramer Herzog wrote:

>
> > You are still not reading the original question very carefully.>
> Regards,
> > Mike
>
> Posted the Hitachi44780 pdf in the files LCD section, see page 18
> for 'fonts' for Japanese and European in a 5X7 matrix. That seems to
> be the answer.

I'm going to try one more time to explain to you. At this point the
original problem doesn't seem that important anymore.

However what Tom was asking for was softcopy fonts in a file to save him
typing and recreating from scratch. Pointing to a PDF with pictures,
explaining how you think he should interface to the device and other off
topic comments does not answer Tom's question and is uninteresting to
other people. By the way I am conscious that this append is also
uninteresting which is why it will be my last one on this topic.

Tom then later said that he got what he needed from Aligent but yet you
still tried to answer what you thought his question was. In other less
polite forums you would have been flamed by now by several people. I
think we are more respectful than that here but you are really
stretching the patience of people.

Mike



The 2024 Embedded Online Conference