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.

Well instead of me doing work I was supposed to do tonight I instead elected to try making my own custom characters and then load them from FLASH to CGRAM and display them.

It was actually easier than I thought.  While I apologise in advance for my crude custom characters, they are what I created using one of the utilities I posted a link to above to get the HEX values.  I then used the tips in the third link, and I also used a command or two from Peter Fleury's Example program.

Essentially all I am doing is displaying one line of text in sequence with a 250 millisecond delay in between writes.  THe last line of the screen contains both canned text, and the custom characters.