keyboard app and avr interrupts ?

hgmjr

Joined Jan 28, 2005
9,027
Here is a screen shot of a short C program for an ATMEGA32. This program compiled without a problem.

You will notice the oval at the bottom of the window. You will see the ATMEGA32 indication. Do you have this indication on your AVRSTUDIO4 screen?

hgmjr
 

Attachments

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
No, I have this
attached is the picture.

I know I need to enable GICR = 0x40 for int0 interrupt.


Also does anybody know if I should use an int array to hold the key values
or something else?

Thanks
 

Attachments

hgmjr

Joined Jan 28, 2005
9,027
I see one problem from your screenshot. If you notice in the list of header files on the left side of the window you will see the header file iom128.h. This should be iom32.h. If you go to the top menu and click on project then scroll down the drop down menu and you will see configuration options. Click on that item and you will see the window. There is selection window labeled DEVICE. You need to click on the dropdown arrow and select the ATMEGA32 device.

hgmjr
 

retched

Joined Dec 5, 2009
5,207
Awww, mathematics!, hgmjr had that figured out two hours ago...

I see one problem from your screenshot. If you notice in the list of header files on the left side of the window you will see the header file iom128.h. This should be iom32.h. If you go to the top menu and click on project then scroll down the drop down menu and you will see configuration options. Click on that item and you will see the window. There is selection window labeled DEVICE. You need to click on the dropdown arrow and select the ATMEGA32 device.

hgmjr
;)

When its a setup problem, you end up with less hair then when you started. Hopefully it all comes together now.
 

hgmjr

Joined Jan 28, 2005
9,027
Never mind I figured it out it was in the configuration setting.
It was some how set to atmega128 or something

compiles now.
Happily you have uncovered the root cause that was sticking you to the mat.

As you move forward, be sure to let us in on your stops and your gos

hgmjr
 

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
Thanks for all your support

This is what it looks like now

Rich (BB code):
#include <stdio.h>
#include <avr/interrupt.h>
#include <avr/io.h>
volatile int keyboard_data = 0 ;
volatile int bitnumber = 0 ;
int main (void)
{
 
  MCUCR = 0x02 ;  //MCU control register 0x02 is for falling edge interrupts
  GICR  = 0x40 ; // this bit enables int0
  sei() ;
 
 while (1) { }
}
 
ISR(INT0_vect)
{
 
  if( bitnumber >= 13 )
  {
    bitnumber = 0 ;
    // AT this point the keyboard data has all lower 13 bits out of the
 //16 bits set with the error code , scancode ,...etc
 //so KNOW I NEED TO STORE THIS DATA IN SOME WAY?
 //I was think creating a large int array but maybe their is a better way.
 // Or some eeprom function I should use 
    // After keyboard_data is stored set it back to zero for next key
    keyboard_data = 0 ;
  }
  // Code to handle the event.
  if( PIND | (1<<PIND4) ) //I put the keyboard data pin on PD4
  {
  // the if statement should execute if PD4 is high
  // if we got here it is a logical one for that particular bit
  // switch statement turns a specific bit on logical 1
   switch( bitnumber )
   {
 
     case 0:
     keyboard_data = 0x01 ;
  break ;
 
     case 1:
     keyboard_data = keyboard_data | 0x02 ;
  break ;
  case 2:
     keyboard_data = keyboard_data | 0x04 ;
  break ;
  case 3:
     keyboard_data = keyboard_data | 0x08 ;
  break ;
  case 4:
     keyboard_data = keyboard_data | 0x10 ;
  break ;
  case 5:
     keyboard_data = keyboard_data | 0x20 ;
  break ;
 
     case 6:
     keyboard_data = keyboard_data | 0x40 ;
  break ;
     case 7:
     keyboard_data = keyboard_data | 0x80 ;
  break ;
  case 8:
     keyboard_data = keyboard_data | 0x100 ;
  break ;
  case 9:
     keyboard_data = keyboard_data | 0x200 ;
  break ;
  case 10:
     keyboard_data = keyboard_data | 0x400 ;
  break ;
  case 11:
     keyboard_data = keyboard_data | 0x800 ;
  break ;
  case 12:
     keyboard_data = keyboard_data | 0x1000 ;
  break ;
 
  default:
  //shouldn't ever get here !
  break ;
 
   }  
 
 
  }
  else
  {
   // if we got here it is a logical zero
   // set nothing 
  }
 
  bitnumber++ ; // increment what bit we are on next out of the 13 bit protocal
}
I am just wondering what is the typical way to store the 13 bit key data.
In memory... I was think just use a int array of max size

But my problem is I want it to remain in memory if I unplug the chip and take it somewhere else. I am going to store all the 13 bit's ,error code ,...etc

Thanks. Normal I would just use a max size int array but I don't think that the array will retain it's values if resetted ...etc

Later I will convert the 13 bit code to a vaild scancode then to ascii...
But for right now I just want away to store it. I know if I am using 13bits I should probably be using a 16bit (int ) for storage <---(this would be the easiest way I would think )

Also I am having a tough time switching over to debug mode. I would like to at least watch what is going on with the key_data variable. Not sure on how to do this though. I am using the avrisp mkII for my programmer if that helps
 
Last edited:

hgmjr

Joined Jan 28, 2005
9,027
EEPROM memory would seem to be the most appropriate way to preserve a value or values over power cycles.

hgmjr
 

hgmjr

Joined Jan 28, 2005
9,027
A quick check of the datasheet indicates the atmega32 has 1024 bytes of EEPROM. Hopefully that will be enough for you to store what you need.

hgmjr
 

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
Is eeprom memory the only way to store data so it doesn't get lost between reset and powering on/off???

Because 1024 bytes is kind of small.

Either way what would be the syntax to store the key values in eeprom memory ? Do I need any additional header files to include.

And other then eeprom memory is the rest of the memory "flash" or is their another type that I can use on this chip.

How about using some of the flash to store the key values is that possible to suppliement the eeprom memory?
 

hgmjr

Joined Jan 28, 2005
9,027
Is eeprom memory the only way to store data so it doesn't get lost between reset and powering on/off???
That is it....
Because 1024 bytes is kind of small.
I suppose you could add an external eeprom memory if you needed more storage.
Either way what would be the syntax to store the key values in eeprom memory ?
Yes. You will need to declare the variables of type EEMEM.
Do I need any additional header files to include.
I think it is eeprom.h
And other then eeprom memory is the rest of the memory "flash" or is their another type that I can use on this chip.
There are three types of memory in the AVR. Flash memroy were the executable code is stored, SRAM where RAM based variables are stored, and EEPROM where you store values across power cycling.
How about using some of the flash to store the key values is that possible to suppliement the eeprom memory?
Yes, some programmers store program constants in the flash memory space.

hgmjr
 

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
Flash memory were the executable code is stored, SRAM where RAM based variables are stored, and EEPROM where you store values across power cycling.
I know eeprom stores your values across power cycling
But can SRAM store them across power cycles as well if so then how do you store stuff in SRAM what is the syntax
Also if I can store stuff in flash memory that would also give me add storage space.

I am finding out that these avr chips cann't hold alot of input data based on your post ,....etc about the 1024 bytes.

So I am curious what chips do they usually use for hardware keyloggers and how much memory do they usually use for storage of this data.
 

hgmjr

Joined Jan 28, 2005
9,027
I know eeprom stores your values across power cycling
But can SRAM store them across power cycles as well if so then how do you store stuff in SRAM what is the syntax
The data stored in the AVR's SRAM space is not protected against power removal. Cycling power will leave the contents of SRAM in an unknown state. This is true of pretty much all microcontrollers with internal SRAM.

EEPROM memory space is not generally large. This too is true of most microcontrollers.

If you are looking to store large amounts of data that needs to survive power cycling then you will need to add an EEPROM memory device and use the microcontroller to write to the externally connected EEPROM.

Battery backed up external SRAM memory is another way to go but the design becomes a bit more involved.

hgmjr
 

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
If you are looking to store large amounts of data that needs to survive power cycling then you will need to add an EEPROM memory device and use the microcontroller to write to the externally connected EEPROM.
Ok, if that is the case what external memory can I get to use with the atmega32 avr chip? Also how much memory could I concieveable get?

Another last minute question is does anybody know what chips that use to make hardware keyloggers ,...etc and how much memory they typically have for storage.

Get away from these questions if I just wanted to see it store a few hundred keystrokes I should be fine. Just to see it work I am going to use it as is now... but is their away to dump the eeprom memory to a few on your computer for analysis that it is storing the key data correctly?

I am using avr studios so I should beable to read the eeprom memory to file? Yes/No?
 

hgmjr

Joined Jan 28, 2005
9,027
Here is a link to an 8-pin 4K by 8-bit EEPROM memory at the Digikey website. It is a serial device so that it will not take up a lot of your IO pins to provide an interface. It will also not take up a lot of room on your circuit board. Keep in mind that EEPROM memory is rather slow to write to. That should not be a problem for a hardware key-logger since speed is not a big problem. One strategy would be to send captured keystrokes to SRAM temporarily and then have a background routine that would move the contents of SRAM to the EEPROM. You will need to write your on read and write routines since eeprom.h supports the AVR's internal eeprom memory space.

If you socket this memory device you could consider moving to a separate board for the purpose of extracting its contents. You would also need to consider whether you might want to go to the next level and time stamp the keystrokes. This would make it easier to determine what keys were pressed in a particular time-frame. If you consider a 4 byte record for each key press you could capture 1000 keystrokes in this memory device.

hgmjr
 

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
I am using avr studios so I should beable to read the eeprom memory to file? Yes/No?
If yes how do you do it is it just pushing the button
read and entering a new file name on where to store it.

Because this would be the only easy way of verifying that the keys are being stored correctly that I know of.

I am not willing to buy an LCD screen and code for it to display the keys.
And at the last possiblity hopefully don't have to reach it is coding for serial/hyperterminal display. So if I can just dump the eeprom memory to a file that would be a simply way to analysis it.

If anybody knows the steps in doing this please let me know
 

hgmjr

Joined Jan 28, 2005
9,027
If yes how do you do it is it just pushing the button
read and entering a new file name on where to store it.

Because this would be the only easy way of verifying that the keys are being stored correctly that I know of.

I am not willing to buy an LCD screen and code for it to display the keys.
And at the last possiblity hopefully don't have to reach it is coding for serial/hyperterminal display. So if I can just dump the eeprom memory to a file that would be a simply way to analysis it.

If anybody knows the steps in doing this please let me know
You can read the contents of the EEPROM into a file using AVRSTUDIO4 just as you described.

hgmjr
 
Top