What specific display are you using?
Is it a one line display with taller than 5x8 pixels per character?
If so you have to tell the library to initialize the display a bit differently.
Also there are some other psuedo hd44780 displays that do some funky things with their fonts and require messing with the bits in the FUNCTION SET command.
I use an DfRobot LcdKeyPad 1602 v1.1. The chars are 5x8. I just do not understand why those symbols are "like this".
Some of them can clearly be fully contained in the upper 7 or 8 lines. Why having so much space above then ?
Most of the chars of those two columns are still fully displayable on a 5x8 chars display. Some are just shortened, some are literaly cut.
It's for the 231, 234 and 249 that the problem is really important. 231 and 249 only have 8 used rows, so they can be easily pushed up to fit. So I don't understand why they are in such places. OK, I can use simple letters instead (y and g) and for the 234, I can use j. But then, why are they there ?
This sounds as weird for me as to have removed the backslash from the chars and replaced it by the yen currency sign. It should have been put in some "upper table part" char...
It's for the 231, 234 and 249 that the problem is really important. 231 and 249 . . .
There is no way in .... that I am going to convert these decimal numbers into binary so I can find them on the ROM Code chart. Why did you express them in decimal when the chart in question uses binary?
This sounds as weird for me as to have removed the backslash from the chars and replaced it by the yen currency sign. It should have been put in some "upper table part" char...
The yen symbol IS in the "upper table part" as would be readily apparent if you expressed the numerical values for the characters in binary instead of decimal.
EDIT: If your 'it' refers to the backslash then where would you put it?
The ASCII code is a seven-bit code. These codes cover all of the characters that appeared on a standard typewriter at the time the code was (excuse the pun) codified. When expressed as a 8-bit number these ASCII codes all have a zero for the most significant bit.
The 'extra' bit is frequently used to create 'extended ASCII' symbols for which there is no standard - or for which there are many standards, depending on your viewpoint.
The designers of this controller wisely chose to populate the upper half of the ROM with characters that are not in the well defined ASCII character set instead of leaving it blank. Since the chip was designed in Japan the inclusion of Japanese characters, including the yen currency sign, was quite logical from their point of view.
You need to understand the history of the controller, it was designed by Hitachi, a Japanese company, hence the Kana characters and the Yen symbol for the Japanese market.
The HD44780 chip has been popular and successful for 30 years and spawned many clones, so the designers got it right. It is one of those few enduring classic chips, like the 555 timer.
You have 8 characters you can reprogram, if that is not enough then you will need to rethink what you want to display, dynamically reprogram the custom characters on the basis that all 8 will not be on the screen at one time, or select a different display.
@floresta : Yes, the "'it" was for the backslash. It should have been put in the 128+ range.
Why I have not expressed it in binary ? Just because I don't care about how it is written in the table, and because I haven't used this specific table but another one with decimal values.
And when I use this way to display chars (cast into char or byte), I use hexadecimal or decimal, not the B00110011 way. And when I use a simple loop to go through the table, I do not convert the value into binary before printing it...
OK, I can convert for you...
231 : 11100111
234 : 11101010
249 : 11111001
Moreover, the yen is in the place of the backslash in the lower part, so it's not "ASCII standard complient". I know ASCII standard is the 7-bits part and the 8-bits is extended. But here, there is nothing between 128 and 160, there is enough space to have put the yen sign (and many other ones, or allow to use this range to define more "createChar" possibilities). And this should have been a better choice since all the other japanese chars are in this upper part.
@bodmer : You're right, history is the key. I didn't knew it. So thanx. I use the custom chars and yes, when they are not enough, I reprogram them dynamically. I just ask why having chosen to use the 2 "extra bottom lines" with adding white lines above the chars to define chars that only need less than 8 lines to be fully displayed.
Confusion occurs with some users because there are two font versions, your first post indicates you have the Japanese ROM version. There is another ROM version as shown in the datasheet on pages 17 and 18.
Sometimes sellers do not say which character set is loaded
Anyway, you have the answer and other Forum readers will find your post when they have the same question.
Confusion occurs with some users because there are two font versions,
I have seed more than two different font roms.
And I've even seen a few that use the font bit and the other unused bits in the FunctionSet command to select other onboard fonts.
While recently helping someone with their i2c backpack lcd, I saw a module that was a disaster.
The ascii characters were in the font from 0x80 to 0xff
and the lower 0x80 glyphs were about half ascii glyphs and the few ascii glyphs that it did have were assigned to the ascii code points.
Even if remapping code points you couldn't get a full a-z set of characters from the lower code points.
Some were missing and they ones that were there were not even all the same case!
And even in the upper half where the "ascii" codes were, there were 3 or 4 characters missing that were replaced with odd symbols.
The funny part on that module was that because they made up their own lower 0x80 characters and replaced 0x20 with some funky arrow, the module would clear the display with these funky arrows instead of spaces.
i.e. the firmware assumed 0x20 was but that wasn't was in the font at that code point.
It was a mess.
The ONLY reason I can see for doing this, is you built a product and you wanted to ensure lockin.
So you made a custom LCD module that required custom funky s/w to use it.
I learned this somewhere in the eighties, when i decided to go and get a printer.
Matrix printers were the thing you'd get with your Commodore 64 and the like.
Have a look at this text.
Do you see that in the line above, all characters have the same base (their lowest part) ?
They share that with the same position the period is in.
But here are characters that do descend beyond that.
Look where these next characters go, and use the periods as your guide:
q.y.p.g.j.
Do you see that their lowest part is actually lower than the base line ?
Your LCD, which is in many ways very similar to dot matrix printing, doesn't have that with the normal set.
The y is lifted up a bit, which looks a bit goofy, doesn't it ?
That's why someone came up with what (as i remember) was called true descend fonts.
Nowadays we're used to that, then that was something special to have in a printer.
Compare character 01110110 in the above table to 01111110 (the one you're asking about).
Doesn't one look more natural than the other one ?
That's why those characters exist.
There's also ascending characters.
Those rise above the other characters.
It's: tdfhklb, but they don't look that silly compared to the descend characters.
