AVR (atmega16) LCD interfacing problem

Discussion in 'Programmer's Corner' started by electron_prince, Nov 28, 2013.

  1. electron_prince

    Thread Starter Member

    Sep 19, 2012
    93
    3
    Hello guys,

    I've a program which contains this code

    Code ( (Unknown Language)):
    1. #define rs PB0
    2. #define rw PB1
    3. #define en PB2
    and later it is used as

    Code ( (Unknown Language)):
    1.  
    2. void lcd_cmd(int x)
    3. {
    4. PORTB=x;
    5. PORTB &= ~(1<<rs);
    6. PORTB &= ~(1<<rw);
    7. PORTB |= (1<<en);
    8. _delay_ms(2);
    9. PORTB &= ~(1<<en);
    10. }
    11.  
    My question is why we used PB0, PB1 and PB2 instead of 0, 1 and 2 ??

    doesn't the below code make more sense?

    Code ( (Unknown Language)):
    1. void lcd_cmd(int x)
    2. {
    3. PORTB=x;
    4. PORTB &= ~(1<<0);
    5. PORTB &= ~(1<<1);
    6. PORTB |= (1<<2);
    7. _delay_ms(2);
    8. PORTB &= ~(1<<2);
    9. }

    Please help, it's very urgent.

    Thanks.
     
  2. MrChips

    Moderator

    Oct 2, 2009
    12,440
    3,361
    Why would someone write
    Code ( (Unknown Language)):
    1.  
    2. PORTB |= (1<<2);
    when it is easier to write
    Code ( (Unknown Language)):
    1.  
    2. PORTB |= 0x04;
    The reason one would choose to write PB0, PB1, and PB2 is that one could easily change the port assignments to different pins, for example PB5, PB6, PB7.
     
  3. electron_prince

    Thread Starter Member

    Sep 19, 2012
    93
    3
    sorry I didn't mean that. What I wanted to say is why not use this code

    Code ( (Unknown Language)):
    1.  
    2. #define rs 0
    3. #define rw 1
    4.  #define en 2
    5.  
    which will produce

    Code ( (Unknown Language)):
    1.  
    2. void lcd_cmd(int x)
    3. {
    4. PORTB=x;
    5. PORTB &= ~(1<<0);
    6. PORTB &= ~(1<<1);
    7. PORTB |= (1<<2);
    8. _delay_ms(2);
    9. PORTB &= ~(1<<2);
    10. }
    11.  
    why we are writing PB0 instead of 0 in #define
     
  4. MrChips

    Moderator

    Oct 2, 2009
    12,440
    3,361
    Statements such as
    Code ( (Unknown Language)):
    1.  
    2. #define rs PB0
    belong in a .h header file, not in the main code or module.

    This allows one to reuse the same code even though the hardware assignment has changed.

    This is simply sound systems design practice.

    Better still, one could use
    Code ( (Unknown Language)):
    1.  
    2. #define LCD_PORT PORTB
    3. #define rs 0
    4. #define rw 1
    5. #define en 2
    6.  
    This would allow you to choose any port and pin.
     
    electron_prince likes this.
  5. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,387
    1,605
    Because people are not computers.

    People will at least have a feeling as to what PB0 means, as opposed to "0".

    What does "0" mean? That is extremely dependent on the contest.

    PB0, given the general context of doing a program, has but one meaning: the lowest pin of a port.

    A very wise man once said "Never put a magic number into your code."

    "0" is a magic number. "PB0" is well on it's way to being a self-documenting symbol.
     
    electron_prince likes this.
  6. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    7,387
    1,605
    That is NOT better. You are using magic numbers.

    While you state WHERE they are used you do not state WHY they are used.
    Code ( (Unknown Language)):
    1.  
    2. #define rs PB0
    3. #define rw PB1
    4. #define en PB2
    5.  
    Shows everyone the port pin rs uses, while the former is quite obscure.
     
  7. MrChips

    Moderator

    Oct 2, 2009
    12,440
    3,361
    This will work because PB0, PB1 and PB2 are defined as 0, 1, 2.

    Ernie is correct because if you wanted to change to PORTE, for example:


    Code ( (Unknown Language)):
    1.  
    2. #define LCD_PORT PORTE
    3. #define rs PE5
    4. #define rw PE7
    5. #define en PE2
    6.  
    would also work.

    Edit: Of course you do have a problem if rs is PB0 and rw is PE7, for example.
     
    Last edited: Nov 28, 2013
Loading...