GLCD MPASM Character Set Lookup Table(s)

[blueroomelectronics]

Nicely done. As for the double size bitmaps can't you simply double the standard font Hx2 Vx2?

 

[jpanhalt]

Thanks for the compliment, Bill.

I could fairly easily just double height and width. What I am looking for is something that has the "thickness" of the letters increased so they are more readable at a distance. It will not be that hard to do, I was just hoping it had been already been done by someone.

John l

 

[Mr RB]

Yep, I've done it. But not in assembler.

See this page on Tut 11. I have included the font data table in the source code, and the bitmap that was used to generate the double sized font data.
https://romanblack.com/SG/SG_tutorial.htm

I posted in your other thread that assembler is probably not the best option once working with graphic LCDs and fonts. This is one of the reasons; if using graphics LCDs there are about 50 times more source code examples you can get in C compared to examples in PIC asm.

 

[jpanhalt]

Thank you, Roman.

That bitmap is perfect. Will try it this evening at the farm.

As for C vs. Assembly, I know what you mean about the ratio of code examples. Fortunately, I don't foresee doing a lot of graphics, with the exception of some custom characters and icons, right now.

I have been putting off working on the wireless kink between the accelerometer and display/processor. Now, I have no excuse. The trouble with wireless (I have a pair of XBee's) is that I can't see where my mistakes are.

John

 

[Mr RB]

Re the bitmap, that was manually made by enlarging the standard Hitachi font (as used in text LCDs) to double sized, and added in smoothing pixels. It's a good match to your other font.

I could say "the wireless part will also be easier in C" but won't. It's an interesting project!

 

[jpanhalt]

@RB

It's not the learning curve that worries me. It is the forgetting curve. Mine seems to be very steep. I had everything downloaded to my Cleveland PC yesterday and thought I had moved it to a USB stick. No such luck. I just forgot the critical step. So, today, I will try that table. Just looking at the size and hex, I think it will work fine.

As for serial communications, I had that working last year with some routines from Mike K8LH and Pommie. It is "just" a matter of getting the XBee to work with them.

John

 

[jpanhalt]

After a very wet month, we had severe rain on Tuesday. The river just North of my home was at about 3 feet over its banks, and I was marooned. That was the highest it has been in recent memory.

Here is an update:



I tested RB's font set, and it is too big for me. I need 6 characters on half of the screen (64 columns wide). So I made an 8x11 character set and used rotates to calculate offsets for a look-up table. I had to insert a blank column to separate characters during the print process. Yesterday, thanks to the flood, I played with a character display program that would allow unlimited character widths and did not use rotates. I am attaching the heart of it here. The bitmap table is separate from the logic.

The characters shown, except the "2" are 8x11. There are two versions of 6 and 9. The 6 is a little more rounded. Anyone want to give a preference?

The "2" is 9x13. Now that I have done a whole set of bit maps, it is really not that hard. However, if someone has a really good programfor doing it on a PC, I would like to hear about it. Graph paper and pencil work, but are a little tedious.

Regards, John

View attachment Big Number program.asm
View attachment Big Number bitmaps.asm

 

[Mr RB]

I edit pixels in a graphics (paint type) program, after zooming right in to max zoom so the pixels are about 1/4" each in size. My graphics program puts a square box around each pixel when at max zoom, making it easy to count white pixels etc.

Re your characters, it's good to stick to conventions. For instance, your 1 has only a single row of pixels on the bottom bar, all other characters have two rows of pixels on the horiz bars. Also, the diagonal lines on your 7,4,3 look good with only two pixels width. But your 6 and 9 have a 3 pixel wide diagonal, making them look blocky. I would fix that and also make the loose ends of the 6 and 9 more curved for improved recognition. And your 5 has a single pixel in the bottom curve, it would look better I think if more like your 3, or at least make the bottom curves on the 3,5,and 9 all match.

 

[jpanhalt]

Thanks for the suggestions. I will incorporate them in the characters shown here and in the 9x14 set I am working on. That set may end up 9x13, but I will probably stay with the original, smaller "big" numbers.

As for designing fonts, I found the Mikr...(common program, don't have link here) GLCD font design program. It allows one to expand the design to any size on screen, click to darken pixels, rt. click to clear, and some other manipulations, such as mirroring. Printing function is very limited, so I print screen, then use Photoshop to get the design. I still need to convert the bitmaps to hex manually, but that is not too hard -- just boring.

John

Edit: Here's a link to the font program I used: https://www.mikroe.com/glcd-font-creator/

 

[Mr RB]

Yeah I have that software, and a lot of other MikroE stuff. I use their PIC C compiler too.

I still prefer fornt design done in a paint program. That gives more power than GLCD Font Creator as it just edits pixels. A paint program lets you copy letters and paste them into words so you can see how the letters work and look together etc, also you can change to any colour foreground and background to see how it would look on a LCD.

Why convert the bitmaps to hex manually? The main benefit of GLCD Font Creator is that it will generate a text table from the pixel data. I've used that feature before, even if you have to put each font character on its side to get the pixels:bytes aligned vertically.