3x4's have been done to death on the internet - suggest you just look at one of the many existing examples.

The point surely is that you do not look for somplete 8 bit patterns in the input such as:

if (PINC==0b00101000)

but you "walk a bit" across the outputs then check each bit of the input in turn to see if it is seen coming back in there.

because AVRs have pull-ups rather than pull-downs it's most usual to use a 0 bit rather than a 1 bit as your "walking bit". You then check the inputs for seeing it coming back in and can then detect one (or more) intersections between the output and the input.

In your code you have:

DDRC|= 0XF0;
PORTC|= 0X0F;

which suggest you are using C4..C7 as your outputs and C0..C3 as your inputs?

Yet after this you never actually do anything to change the state of the outputs and only read PINC looking for complete 8 bits patterns (of which 4 bits are actually output).

If you don't know how to read/set individual bits in a port then read the "bit manipulation 101" thread in the tutorial form here. And after that just google "4x3 AVR" and look at some of the 100's of existing projects that already show how to do this.

I also looked at the links you provided me with but got stuck somewhere during returning the value. But tried to come up with this new code as shown above. Please have a look and let me know for any mistakes.

Now you have no manipulation of DDRC or PORTC, yet you expect PINC to have a particular value?

You haven't told us the wiring of your keypad, as far as I can see.

I thought that link I gave was pretty darned good introduction/how-to.

I usually use [about] 2.5ms per column. That give it time to overcome capacitance and such and settle down. At the end of the time period, the row is read, the previous column turned off, and the new column energized. I take the readings from all the rows and combine the values for a complete pass of all columns, and enter into my debounce mechanism. That results in a word of bit flags for current state and a word of bit flags for new presses. (In some apps I'll create or calculate another word for falling edges.)

Is JTAG enabled?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

If we assume you keypad works and gives us keycodes for each keypress, then it is a matter of solving the program logic that has nothing to do with the keypad or AVR. Sit down with a pencil and paper and map out the steps to get a keypress and decode it the way you want.

You want to input date - how? What feedback do you have for the user? An LCD?

Also consider that you are not the first person in the world to do this - I'm sure Google has some examples. Have you done some research rather than blindly asking on a forum?

If we assume you keypad works and gives us keycodes for each keypress, then it is a matter of solving the program logic that has nothing to do with the keypad or AVR. Sit down with a pencil and paper and map out the steps to get a keypress and decode it the way you want.

You want to input date - how? What feedback do you have for the user? An LCD?

Also consider that you are not the first person in the world to do this - I'm sure Google has some examples. Have you done some research rather than blindly asking on a forum?

Yes your assumption is right and feedback is through LCD. Keypad works for each keypress and i am able to put in the numbers through keypad. But my program isn't coming out of the loop after certain limit. Did some research but no luck on it. So wanted to make sure if there was any other way to do it. Well, Thanks for your suggestion.

How do we know what your program is and what the problem might be? If you post the code, then we may be able to assist.

How i usually would structure my code would be having the keypad scanned in a timer isr and the keys put into a queue. My menu code can then read a keypress from the queue and process it in a state machine. Simples.

How do we know what your program is and what the problem might be? If you post the code, then we may be able to assist. How i usually would structure my code would be having the keypad scanned in a timer isr and the keys put into a queue. My menu code can then read a keypress from the queue and process it in a state machine. Simples.

I'm rather guessing that "=" was originally destined to become "==" in fact ;-)

PS a lot of people find this counter-intuitive (I know I do!) but you can avoid this kind of error by reversing the test:

} while (0xFF == keypressed);

On the occasion you mis-type that as:

} while (0xFF = keypressed);

the compiler simply won't let you get away with making that mistake (you cannot assign a variable to a constant!).

You were right. That was one of the problems. Now i can see each key press is printed on LCD. But i m trying to take all the numbers and print it at once. But i donot see that happening. It is printing each time i press a key.

So that seems to be setting the returned value to low numbers like 0x01, 0x02, 0x03 etc. But then you do:

buffer[i]=keypressed;

and then finally:

Lcd8_Write_String(buffer);

So how on earth is that going to work? There is nothing here to convert 0x01, 0x02, 0x03 into '1', '2', '3' or whatever. Did you mistakenly think that 0x01, 0x02 etc in a buffer[] was going to appear as "123" ? It won't.

You should comment out those lines, they are no longer doing anything useful.

Yes, I have used Lcd_write_string earlier and it works fine. and those lines are not from previous versions. That was the way described in Atmel website in order to use matrix and read values from it for each key pressed.

Well, i have to go through some steps before reaching this point. So here's the complete code i have been using. and i guess the previous if loop that i have been using is causing the key press to be displayed. But not sure how to go with it.

and nothing ever sets i back to 0 again. Once you have consumed the buffer:

Lcd8_Write_String(buffer);

then you should set i = 0.

BTW what is up with the indentation in your code? The whole point of indenting C is to make the flow of execution obvious to the reader. Your code goes out of the way to obfuscate this!! Either forget indentation all together:

Of course this is assuming your LCD library has functions called Lcd8_Num() and Lcd8_Write_Char() but as "Lcd8_" is quite an unusual name I think I may have found the site that shows that it DOES have these functions.

Of course this is assuming your LCD library has functions called Lcd8_Num() and Lcd8_Write_Char() but as "Lcd8_" is quite an unusual name I think I may have found the site that shows that it DOES have these functions.

I do not have Num function in my LCD library but i tried to print each character for every key press. But even after 8 keys, it just goes on printing as i keep going.

What I am suggesting here is that you don't try to print the return value of read_key() as character but you convert the numeric value to ASCII strings and print those. itoa() will achieve that (itoa = integer to ascii)

What I am suggesting here is that you don't try to print the return value of read_key() as character but you convert the numeric value to ASCII strings and print those. itoa() will achieve that (itoa = integer to ascii)

Thank you so much for all your help. I really appreciate it. I tried this as well. But i dont see anything on my LCD. I am sorry. I am trying too .

Did you ever see any output from Lcd8_Write_Char(). If not then it's clearly stuck in:

do{
keypressed=read_key();
}while(keypresses==0XFF);

so that suggests the routine ALWAYS returns 0xFF.

But you have an LCD here! Why not pepper the read_key() routine with calls to Lcd8_Write_String("got this far") and see exactly what is happening in that code - is it following the path of execution you expect it to? If your LCD permits you to print the value of key variables at various stages then do those variables contain the values you expect them to have?

This is the whole nature of debugging - you annotate code so you can follow it's path, see it's data, check when either the data values or the flow of execution deviate from what you expect.

If your LCD permits you to print the value of key variables at various stages then do those variables contain the values you expect them to have?

This is the whole nature of debugging - you annotate code so you can follow it's path, see it's data, check when either the data values or the flow of execution deviate from what you expect.

Yes, my LCD permits to print the value of key variables at various stages and those variables contain the values i expect them to have. In this program itself i use read_key() function thrice to get to "planting_date" and it works fine.