AVR Freaks

 

So YOU CHANGE the port to whatever you want.  THe library does not care.

 

Easy.  Break it up between two ports.

 

Look:

#define LCD_PORT         PORTA        /**< port for the LCD lines   */
#define LCD_DATA0_PORT   LCD_PORT     /**< port for 4bit data bit 0 */
#define LCD_DATA1_PORT   LCD_PORT     /**< port for 4bit data bit 1 */
#define LCD_DATA2_PORT   LCD_PORT     /**< port for 4bit data bit 2 */
#define LCD_DATA3_PORT   LCD_PORT     /**< port for 4bit data bit 3 */

and:

#define LCD_DATA0_PIN    0            /**< pin for 4bit data bit 0  */
#define LCD_DATA1_PIN    1            /**< pin for 4bit data bit 1  */
#define LCD_DATA2_PIN    2            /**< pin for 4bit data bit 2  */
#define LCD_DATA3_PIN    3            /**< pin for 4bit data bit 3  */
#define LCD_RS_PORT      LCD_PORT     /**< port for RS line         */
#define LCD_RS_PIN       4            /**< pin  for RS line         */
#define LCD_RW_PORT      LCD_PORT     /**< port for RW line         */
#define LCD_RW_PIN       5            /**< pin  for RW line         */
#define LCD_E_PORT       LCD_PORT     /**< port for Enable line     */
#define LCD_E_PIN        6            /**< pin  for Enable line     */

 

If you simply change the first part:

#define LCD_PORT         PORTB        /**< port for the LCD lines   */
#define LCD_DATA0_PORT   PORTC    /**< port for 4bit data bit 0 */
#define LCD_DATA1_PORT   PORTC     /**< port for 4bit data bit 1 */
#define LCD_DATA2_PORT   PORTC    /**< port for 4bit data bit 2 */
#define LCD_DATA3_PORT   PORTC     /**< port for 4bit data bit 3 */

 

And this to the second part:

#define LCD_DATA0_PIN    0            /**< pin for 4bit data bit 0  */
#define LCD_DATA1_PIN    1            /**< pin for 4bit data bit 1  */
#define LCD_DATA2_PIN    2            /**< pin for 4bit data bit 2  */
#define LCD_DATA3_PIN    3            /**< pin for 4bit data bit 3  */
#define LCD_RS_PORT      LCD_PORT     /**< port for RS line         */
#define LCD_RS_PIN       0            /**< pin  for RS line         */
#define LCD_RW_PORT      LCD_PORT     /**< port for RW line         */
#define LCD_RW_PIN       1            /**< pin  for RW line         */
#define LCD_E_PORT       LCD_PORT     /**< port for Enable line     */
#define LCD_E_PIN        2            /**< pin  for Enable line     */

 

Now the LCD CONTROL lines are on PORTB pins 0, 1, and 2.

 

The LCD DATA lines are on PORTC Pins 0, 1, 2, and 3.

 

Jim

Not unless you tell us

- What toolchain (i.e compiler etc) you are using, and

- What operating system you are using, and

- What programmer you have, and

- What programming software you used the last time (if possible to recall)

 

Without any of that information there will be hundreds of combinations of the above things. We can't list them all..

In the beginning,  God invented AVR Studio 4 (AS4) and it was good.

You young kids!! I started with AS3 which was just out and I still have AS2.

You're very confusing now.

 

Do this:

1. Clear/reset your terminal window.

2. Issue the commands you use to compile your files.

3. Copy the commands and their output, the complet ecommands and the entire output, and pate it in a post here.

 

---

 

The normal way of building a project with multiple source files is to compile each source file separately, and only compile it (you need to be specific about that, or else the cimpiler will try to compile and link in one go). After that you issue a final command to link together the results of the earlier compilations. Something like this:

 

# Compiling...

avr-gcc -c lcd.c -o lcd.o
avr-gcc -c main.c -o main.o

# Linking...
avr-gcc main.o lcd.o -o theProgram.elf

Note that the above is not complete, missing a lot of options (e.g. optimization) etc. It is only an illustration of the "flow of the process". After the above you need to make a .hex file based on he .elf file. For this you use the objcopy command, something like this (again an example, not complete)

 

objcopy -o ihex -R theProgram.elf theProgram.hex

So you see this is not a trivial thing, with just a few short'n'simple commands involved.

 

I really recommend the MFile utility to get you started. It will let you focus on the code rather than fighting with poor build processes.

It is pretty close, isn't it?

 

I'd leave the cursor off in the final animation, but suit yourself.

 

Examine your yy logic.  Don't you want your test when yy == 3 ?

 

Next you can try a simple loop outputting 80 asterisks after a clear screen.  The driver should do the line wrapping for you.

 

 

I'm watching that video standing on my head. It hurts.. ;-)

Ok, I'll byte, what are you having issues with understanding Mr. Fleury's code?  It is very well commented right out of the box.

 

JIm

Just to say that "rasterization" is probably the wrong term when a character LCD rather than a GLCD is being used.

Every time I read a thread about HD44780 and custom characters my first thought is "did they make a mistake by not selecting a GLCD?"

 

(that "only 8 definable" is often going to bite one in the posterior!)

There is something I'm not familiar with in Peter's code

 

How do we store the custom chars in CGRAM?

I know it's done by these lines, but don't know how!

 

lcd_command(_BV(LCD_CGRAM));  /* set CG RAM start address 0 */
      for(i=0; i<16; i++){
         lcd_data(pgm_read_byte_near(&copyRightChar[i]));
      }

 

I don't know exactly what that pgm_.... function is doing and how it stores the chars in CGRAM.

 

You need to take this on in a structured way. What are the unknowns? Well, probably..

 

First:  The pgm_read_byte_near( ...) function. Do an internet search for that and you will soon find that it is a function to read data out of flash (rather than RAM) of the AVR. You will fins that it is a part of the avrlibc library - the support library for your compiler. You can the go to the avrlibc documentation, and you will find more info on it here: http://www.nongnu.org/avr-libc/u...

 

Second: A parameter to pgm_read_byte_near() is 

&copyRightChar[i]

so look in the source code for where copyRightChar is defined. It looks like this:

 

static const PROGMEM unsigned char copyRightChar[] =
{
	0x07, 0x08, 0x13, 0x14, 0x14, 0x13, 0x08, 0x07,
	0x00, 0x10, 0x08, 0x08, 0x08, 0x08, 0x10, 0x00
};

Once again, PROGMEM is something that helps to store data in flash rather than RAM, so again look in the avrlibc documentation linked to above.

 

Now for the data. Let's translate those values in there to binary. 0x07 is binary 00000111, 0x08 is 00001000 and so on. Taking the whole first line (forming one user defined character) and placing each binary byte on its own line, we have

00000111
00001000
00010011
00010100
00010100
00010011
00001000
00000111

Doesn't make much sense yet. Let's continue! Well place the bytes of the second line to the right of the bytes of the first line:

 

00000111 00000000
00001000 00001010
00010011 00001000
00010100 00001000
00010100 00001000
00010011 00001000
00001000 00001010
00000111 00000000

A little hard to read. Let's reform that, substituting  * where we have a 1 and a blank where we have a 0.

     ***         
    *       *  
   *  **     *   
   * *       *   
   * *       *   
   *  **     *   
    *       *    
     ***         

Do you see a, somewhat ill formed, copyright sign ( © )? The space column between th left and right part is somewhat disturbing. Peter has chosen to use two character cells for a copyright sign and there will always be a blank column between two character cells on an 44780-base LCD display. He could have opted for a copyright sign taking up only one character cell, e.g. 

 

  ****
 *    *
*  **  *
* *    *
* *    *
*  **  *
 *    *
  ****

but that is not what he is doing, so to stay with his example let's leave that one-character-cell-copyright-sign for now.

 

So, the big picture is: To define a custom character you set up a "bitmap" defining which pixels in the charater cell should be set and which should be clear.

 

Peter has opted to store this in flash, which complicates his example a bit, but do understand that this has nothing do do with the defining of a custom character as such. He's just preserving precious RAM, sacrificing less precious flash memory.

 

So the loop  you pointed out reads the bitmap, byte by byte, out of flash and calls lcd_data() with the byte ass parameter. The lcd_data() function is a function in Peters librry so you can go analyze it on your own.

 

Also note that the call to 

lcd_command(_BV(LCD_CGRAM));  /* set CG RAM start address 0 */

says that what follows is the first spacial character of the eight that the 44780 can handle. Remember that each character is defined by 8 bytes. This means that the second special character is defined in the eight bytes starting at _BV(LCD_CGRAM) + 8. In general, to define special character n  you need to 

lcd_command(_BV(LCD_CGRAM) + n * 8);  /* set CG RAM to define spacial character n */

 

You'll have enough to investigate now with this help, I believe. Remember to try to sort out any detail you don't know about by searching, reading documentation  etc. Then try to put it together to see the bigger picture.

 

This document is invaluable for understanding the controller chip on your display: https://www.sparkfun.com/datashe... . Download it and keep it close to you when working with the 44780. It is technically "dense" but holds information about how defining a special character works, from the perspective of the 44780 LCD controller.

 

If you want to get rid of the complication of PROGMEM and pgm_read_byte... to begin with, change Peters example so that you have

 

static const unsigned char copyRightChar[] = // "PROGMEM" removed
{
	0x07, 0x08, 0x13, 0x14, 0x14, 0x13, 0x08, 0x07,
	0x00, 0x10, 0x08, 0x08, 0x08, 0x08, 0x10, 0x00
};



    .
    .
    .
    
       lcd_command(_BV(LCD_CGRAM));
       for(i=0; i<16; i++)
       {
           lcd_data(&copyRightChar[i]);   // pgm_read_byte_near( ... ) removed
       }

 

His manual:

 

http://homepage.hispeed.ch/peter...

 

says you send commands to the LCD with lcd_command() and that there is LCD_CGRAM defined to set the address for writing to CG locations. In fact that is exactly what Johan showed above:

lcd_command(_BV(LCD_CGRAM));  /* set CG RAM start address 0 */
      for(i=0; i<16; i++){
         lcd_data(pgm_read_byte_near(&copyRightChar[i]));
      }

So you start by issuing the LCD_CGRAM command (with optional offset if you aren't going to set all characters from address 0) then you keep calling lcd_data() to send the bytes that define the characters.

 

The characters you define are 0 .. 7. So just as you might use lcd_putc(0x41) or lcd_putc('A') to print an 'A' you use lcd_putc(3) to print the 4th user defined character.

 

As Lee says, your bitmap for the character is not in flash. You removed the PROGMEM as I suggested.

But then you should not try to read the bitmap out of flash!

 

Change

      lcd_data(pgm_read_byte_near(&customChar[i]));

to 

      lcd_data(&customChar[i]);

as I said in #30.

 

Those two changes go together.

EITHER have bitmap in flash (PROGMEM) and read out of flash (pgm_read_byte...),

 OR have bitmap in RAM (no PROGMEM) and read out of RAM (no pgm_read_byte...).

No, it is not.  And it was completely explained in #30, as well as #36.

 

From "Peter's code":

/*
** constant definitions
*/
static const PROGMEM unsigned char copyRightChar[] =
{
	0x07, 0x08, 0x13, 0x14, 0x14, 0x13, 0x08, 0x07,
	0x00, 0x10, 0x08, 0x08, 0x08, 0x08, 0x10, 0x00
};
...
       /*
        * load two userdefined characters from program memory
        * into LCD controller CG RAM location 0 and 1
        */
       lcd_command(_BV(LCD_CGRAM));  /* set CG RAM start address 0 */
       for(i=0; i<16; i++)
       {
           lcd_data(pgm_read_byte_near(&copyRightChar[i]));
       }

 

You will have to stress a bit more and try to understand my ASM code this is from an old project for the music store HMV (RIP)

 

These are the 8 special graphics, at this stage they are just flash data

 

cg_codes:
;0x00 or 0x08
.db	0,0,0,7,5,6,5,0		;"Repeat" graphic

;0x01 or 0x09
.db	16,24,28,30,28,24,16,0	;"Play" graphic

;0x02 or 0x0a
.db	28,16,28,7,29,6,5,0	;"Shuffle" + "Repeat" graphic

;0x03 or 0x0b
.db	27,27,27,27,27,27,27,0	;"Pause" graphic

;0x04 or 0x0c
.db	28,16,24,23,29,7,1,0	;"Eq" graphic

;0x05 or 0x0d
.db	31,31,31,31,31,31,31,0	;"Stop" graphic

;0x06 or 0x0e
.db	0x01,0x03,0x07,0x0f,0x07,0x03,0x01,0x00	;< Reverse graphic

;07 or 0x0f
.db	0,0,0,7,5,6,5,0		;"Repeat" graphic

during the initialization  that data is copied to the LCD cg ram location using the control write command with a loop of 8 counts.

 

To display the corresponding graphic at run time you call the print routine with the code (say 0x05 for Stop graphic) instead of say A, B etc.

 

Sorry no C code that I can remember, maybe I have one but don't know where.

 

OK it is now clear that you aren't reading what we post, or are reading sloppily. In #30 I wrote

 

Also note that the call to 

lcd_command(_BV(LCD_CGRAM));  /* set CG RAM start address 0 */

says that what follows is the first spacial character of the eight that the 44780 can handle. Remember that each character is defined by 8 bytes. This means that the second special character is defined in the eight bytes starting at _BV(LCD_CGRAM) + 8. In general, to define special character n  you need to 

lcd_command(_BV(LCD_CGRAM) + n * 8);  /* set CG RAM to define spacial character n */

It is not the _BV(LCD_CGRAM) that specifies where in CGRAM the special character ends up. The _BV(LCD_CGRAM) bit tells the LCD that this whole byte is to set the CGRAM address. It is the rest of the byte is the address where the first byte of the bitmap is to end up. And then every write will auto-increment the address into CGRAM with 1. This probably would have been clear if you had opened up the Hitachi PDF that I linked to somewhere above, and read there about CGRAM.

 

To write to the first special character in CGRAM you start at byte 0 in CGRAM. With my general code from above that would be:

lcd_command(_BV(LCD_CGRAM) + 0 * 8);  /* set CG RAM to define spacial character 0 */

and since 0 * 8 == 0, and thus can be left out, Peters code simply says

lcd_command(_BV(LCD_CGRAM));  /* set CG RAM to define spacial character 0 */

 

I believe I have spent at least two hours thinking out and typing posts to you. Typing a lengthy post to try to explain something thoroughly, only to then find it was not read (or read sloppily) is frustrating and feels like a complete waste of time.

 

 I will not spend any more time here until you start reading. (Begin with e.g. browsing the Hitachi document from beginning to end so that you have a hunch about what's in there. Not everything is excellent info, but there are a lot of things are important and useful.)

 

Same thing as a Custom Character.

 

 

Hmmmm, Maybe you need to take a little break from all of this and go outside for a day or so and catch your breath !

 

 

 

Jim

 

EDIT:

After I read through the posts in this thread I started wondering about the Custom Character RAM and how its used etc.  I put the following into GOOGLE:

 

creating custom characters for HD44780

 

The return hits were quite helpful.  Since I do not know how your returns may show up here are the first few that came back for me:

 

This is a utility for creating the values for your character

https://omerk.github.io/lcdcharg...

 

Another great utility:

https://www.quinapalus.com/hd447...

 

This link gives a basic, yet decent understanding of how it works:

http://www.circuitvalley.com/201...

 

 

If you put the same search term, but add AVR to teh end of it you get several threads and projects from this site as well....and Johan is ion the thick of those threads too!

 

I may put together a little test program of my own just to see what happens using the threads I posted above.

Read the Hitachi document I linked to!!! There is an EXCELLENT table showing the bit patterns for EVERYTHING you can do with the 44780.

 

EDIT: Table 6 on pages 24-25.

Bad internet connection :(

Sorry.

+1 

 

 

" 20 x 4 LCD - DDRAM Address            

  Row1     0x80 0x81 0x82 0x83 through 0x93
  Row2     0xCO 0xC1 0xC2 0xC3 through 0xD3
  Row3     0x94 0x95 0x96 0x97 through 0xA7
  Row4     0xD4 0xD5 0xD6 0xD7 through 0xE7 "

 

0x80 is address of DDRAM at row 1 col 1 to be specific. 0x81 is col 2 and so on. 

 

Edit: typo

 

MG

I see Johan ans Micro have posted while I was writing and I now understand what DDRAM is.  If my understanding is correct DDRAM are simply locations in the VISIBLE area of the display.

 

So when you use:

lcd_gotoxy(x,y);

the library converts your X/Y position to a HEX value for the location in DDRAM, and thats where your next character is printed.    The LCD will then increment the DDRAM counter to print the next character, unless you use the lcd_gotoxy() command to change this.

 

Thanks Johan and Micro!

 

Jim

lcd_command((1<<LCD_DDRAM)+LCD_START_LINE1+x);

LCD_DDRAM is 

#define LCD_DDRAM             7      /* DB7: set DD RAM address             */

and thus

1<<LCD_DDRAM

is binary 10000000 or hex 0x80 .

 

I'm not entirely sure what you mean here, but I think you're wrong:

• lcd_gotoxy() will "select" DDRAM (since it sends an instruction/command with the high bit set, i.e. 1xxxxxxx)
• lcd_command(0x40) will "select" CGRAM (since it sends an instruction/command with the two high bits set to 01, i.e. 01xxxxxx)

Incorrect.  You will have to load a new character, or set of characters into CGRAM.  Meaning you can have as many as you want, you only have eight at a time to work with.

 

Yes, you are missing a few basic concepts, that really have nothing to do with using PROGMEM, or __FLASH. I am only suggesting you hold off on jumping to another topic until you have understood the operation of the LCD first.  Using PROGMEM or __FLASH really has no impact on the way the CGRAM gets loaded in the end.

 

REally?  All these posts back and forth and you already knew what to do?

 

YOu are

 

Wrong! 

 

The datasheet mentions about using the space, but it's not worth it as the AVR has far more RAM available than a few bytes in a slow LCD.  In this case I strongly say forget about it....not worth the hassle.

 

 

If you are now all set on the LCD operation and no longer need our help on it, I suggest you start a new thread on the next item you do not understand.  If you have more questions on LCD, then add them to this thread.

 

Jim

CGRAM and DDRAM is 2 different memory area. So anything you do to CGRAM has no effect to DDRAM until you do gotoXY and lcd_data() or print().
.
DDRAM holds what on the screen means it holds the character so you won't be notice what's going on behind the screen. Or else you'll see flickering or blinking screen while you change the char.
.
So basically lcd_clear() doing is nothing than clearing DDRAM.
.
As other hint is to display some thing on the screen, say it temperature.
You don't have to change the whole text, just the value.
.
On screen: Temperature: 30 °C (assume this text placed on row 2)
.
You want to update the value 30 to 27 so what you should do is:
- gotoXY(13,1) - (13 is location of "3")
- print("27"). - overwrite it with 27
That's all. No need to print("Temperature: 27 °C")
.
I hope you know what I tried to explain. That's how DDRAM works.
.
But one thing to remember, RAM means it only holds when there's a vcc supply on it.
Once the vcc to LCD was cut (then powered back) and you only do gotoXY(13,1) and print("27") your "Temperature: °C" won't be there anymore. Except "27" at col 13 location.
.
I hope I make it clearer not more confusing. :)
.
Edit: - damn autocorrect

        - wrong answer about DDRAM refresh update. Changing at CGRAM which already displayed on the screen (inside DDRAM) will be updated (refreshed) by internal controller automatically.
.
MG

You can never display more than 8 different custom characters at a time because there are only 8 definable. If you go back and change one then all already on the display will change.
.
Have you thought about getting a GLCD as that's clearly what you really need!

Just test it yourself. It's not hard to do it don't it? It won't break your MCU or LCD anyway.

 

 

 

 

 

MG

YES you are RIGHT and I'm COMPLETELY WRONG about this. I'm sorry for misleading you about this refreshing thing.

 

You are absolutely right!

 

I just tested this CGRAM thing, thank's to El Tangas which make me think to check it again. I feel stupid now. Sorry guys.

 

I edited my post #72 in case other reader will also get misleading by reading that.

 

 

 

MG

 

I'm not sure I follow.

 

 

 

MG

 

Yes. Close to what I suggested somewhere above. The combination of CGRAM and CGROM forms a LUT (look-up table) or mapping from a single char value to a 8x8 bytes bitmap.

 

 

 

Yes. Let try to visualize this. What follows is not code running in the AVR but a description of roughly what goes on in the 44780 controller. Roughly!

 

1) Think of the combination of CGRAM and CGROM as one array of bitmaps, i.e. an 128x8 array of bytes. Let's call it "CGMEM". (The first 8x8 bytes are the CGRAM and the following 120x8 bytes are the CGROM).

 

2) The DDRAM consists of 80 bytes.The HD44780 controller constantly loops over all DDRAM elements, picks the value of the element, uses that as an index into the "CGMEM", gets the bitmap (8 bytes) and uses that to set the individual pixels in the physical display.

 

If this was C code, how would it look? Well, roughly:

 

typedef uint8_t[8] bitmap_t;

bitmap_t cgmem[128];  // Actually 8 bitmaps in CGRAM and 120 bitmaps in CGROM

uint8_t ddram[80]; 

while (1) {
    for (int i = 0; i<128; i++) {
        bitmap_t bitmap = cgmem[ddram[i]];

        // Use bitmap to set pixels in character cell i in physical display
    }
}

A change in CGRAM will hve an immediate effect on what is displayed even if there is no change in DDRAM.

 

The above code is an illustration of parts of the "back-end" of the 44780. There's more to it - hidden in my simple comment "Use bitmap to set pixels...".

 

The CGRAM and DDRAM is (at least conceptually) double-ported. I.e. at the same time the back-end does what I sketch above, the front end can write to CGRAM and DDRAM. The "front-end" is what your AVR is communicating with. What your AVRwrite to the 44780 goes through it's front end into CGRAM or DDRAM (or is interpreted as an instruction which affects the state of the 44780 in some way).

 

Again, this is "sketch" but not so far from the detailed truth. .E.g. take a look at the block diagram on page 3 in thee Hitacchi data sheet.

 

---

 

A side observation regarding MicroGyros code, mentioned in #47 (linking to http://www.circuitvalley.com/201... ):

 

MicroGyro creates a battery status indicator. He does so by defining 8 separate battery icons, each with a different "filling factor". It uses up all of the CGRAM. Different battery levels are displayed by using one of the 8 different characters on CGRAM. There is no space left for any other special characters.

 

A better solution Designate just one of the CGRAM characters/bitmaps for a battery indicator. To display a battery indicator, use this CGRAM character. To vary the actual battery indicator displayed, write different bitmaps to the CGRAM bitmap. You now have 7 bitmaps freee for other special characters.

 

When you think about it for a while, you can actually expand this technique to have 8 different "animated characters" displayed all at once. One battery indicator, one hourglass, one signal level indicator, two forming a stereo VU level indicator, one blinking eye, one beer glass being emptied, one 8x8 snake game, and another 8x8 snake game (in a different state than the first one!).

 

If you want an animation in one character position, you only need to use one of the eight custom characters.

Oh come on. Just read and think for once. There's spoon feeding then there's spoon feeding!
.
If you just "can't get" this feature then forget about trying to use it. Already it's clear to me that it's not going to deliver your final goal here anyway.
.
The big 'A' you show in #69 looks like it would need 13 new characters all defined and onscreen at once. You have only 8.

Johan, but that's just the A. He said "BIA" and while the I may be possible with existing blocks a big B will require as much as A.
.
A GLCD could even have a picture of Bia.