External Interrupt

Go To Last Post
51 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

I have written a code for password based door lock on Atmel Studio 7. I am using external interrupt INT0 to change the password at anytime according to user's wish. But, this interrupt gets executed automatically every time simulation on Proteus is run. As a result, it prompts user to change password every time the simulation is run, which should not happen! I wish the ISR to be executed only when I apply INT0 signal. Kindly help!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We might be abletohelp if you gave us some info. We're not next to you to see your problem.
We could guess at your initialisation or whether youhave pullups enabled but apart from that we know little.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sure.. I am sending you my code.. hope it works for you!

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By default, INT0 triggers on a low-level, and will trigger every time a low is sampled on the pin. I suspect you really want to use an edge triggered mode. Or that your external logic is the wrong polarity.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your code is littered with gotos - you know that is bad juju don't you?

 

Tell us why you use an external interrupt in the first place. Switches and external interrupts are bad juju as well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have attached the code I have written. Kindly refer to it. It will help you understand my problem in a much better way.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How does it differ from the original that i kindly referred to?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay.. then what should I do... 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
How does it differ from the original that i kindly referred to?

I agree I don't have solution to this.. you guide me! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sanket_Agrawal wrote:

Okay.. then what should I do... 

Define your requirements.  Don't tell us HOW (INT0), tell us WHAT you want the code to do.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why did you use an external interrupt? It is totally unnecessary. To put it bluntly, your code is a mess. You mix in reading port pins with menu logic and keyboard. Write some functions to manage the keyboard. Then write functions to manage the lcd and storage/retrieval of eeprom data. Then write your menu logic the get a key value, determine what to do then output to lcd. No need for external interrupts or gotos.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:

Sanket_Agrawal wrote:

Okay.. then what should I do... 

Define your requirements.  Don't tell us HOW (INT0), tell us WHAT you want the code to do.

I am trying to make a password based door lock. It will have a pre-defined one time password. I want this one-time password to get over-written, the very first time the lock is turned ON by the user. Now when the user has over-written the password by the one of his own choice, he can use the newly set password to get the access to the door. Also, in future if user wishes to change the password set by him, he should be able to do so...

This is what my exact theme behind the code is.... 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Why did you use an external interrupt? It is totally unnecessary. To put it bluntly, your code is a mess. You mix in reading port pins with menu logic and keyboard. Write some functions to manage the keyboard. Then write functions to manage the lcd and storage/retrieval of eeprom data. Then write your menu logic the get a key value, determine what to do then output to lcd. No need for external interrupts or gotos.

 

Actually this is what I am trying to do...

 

"I am trying to make a password based door lock. It will have a pre-defined one time password. I want this one-time password to get over-written, the very first time the lock is turned ON by the user. Now when the user has over-written the password by the one of his own choice, he can use the newly set password to get the access to the door. Also, in future if user wishes to change the password set by him, he should be able to do so..."

 

I have header files for keyboard and for lcd too... I am attaching them here.. How can I implement the logic without interrupt?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sanket_Agrawal wrote:

I am trying to make a password based door lock. It will have a pre-defined one time password. I want this one-time password to get over-written, the very first time the lock is turned ON by the user.

By what steps shall the lock be turned on by the user?

Quote:
Now when the user has over-written the password by the one of his own choice,

By what steps shall the user overwrite the password?

Quote:
he can use the newly set password to get the access to the door.

By what steps shall the user use the password to get access to the door?

Quote:
Also, in future if user wishes to change the password set by him, he should be able to do so...

By what steps shall the user change the password?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More bad juju. Don’t put code in header files.
You’ve set the external interrupt to falling edge trigger but your code mentions an AND gate and you’ve turned on the pullup resistor - i had to read the datasheet to figure this out as you weren’t kind enough to put comments in your code.

You code has a lot of repeated code -especially with the keypad and strange code like:
if ( PIND & PORTD......
I have no idea of why you’d write such code.

Anyways, structure your code so you:
Read the inputs
Do program logic
Update outputs
Rinse and repeat.

If i were to use interrupts, i would only use a timer interrupt, with thetimer in CTC modetointerrupt every 10ms. The timer isr would scan the keypad, debounce the keys and put them in a queue.

Last Edited: Fri. Dec 14, 2018 - 12:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:

Sanket_Agrawal wrote:

I am trying to make a password based door lock. It will have a pre-defined one time password. I want this one-time password to get over-written, the very first time the lock is turned ON by the user.

By what steps shall the lock be turned on by the user?

Ans: Lock will be turned on as usual with a power key!

Quote:
Now when the user has over-written the password by the one of his own choice,

By what steps shall the user overwrite the password?

Ans: As soon as the lock is turned ON, it will automatically ask for a new password. User will enter new password and it will be stored in EEPROM for future at the same memory location where one time password is stored . Hence it gets over written.

Quote:
he can use the newly set password to get the access to the door.

By what steps shall the user use the password to get access to the door?

Ans: lock will always ask for the password to allow access.

Quote:
Also, in future if user wishes to change the password set by him, he should be able to do so...

By what steps shall the user change the password?

Ans: lock will have a key for resetting the password. If the key is presed, it will direct to furthur steps.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Store the password in EEPROM somehow, on each power up, first read the password from EEPROM, if password is something invalid request user to change password.

Make sure to ship device with invalid password (blank EEPROM).

- Brian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you!

I will reach you back if I face any other trouble..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thats an option you suggested but my problem is something different...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

How about just reading the input instead of using interrupt?

 

There's really shouldn't be anything time critical in a reset-password-switch.

- Brian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Geronimo wrote:

How about just reading the input instead of using interrupt?

 

There's really shouldn't be anything time critical in a reset-password-switch.

Ans: In my program I have used external interrupt. It's true, it hasn't got anything time critical.  

 

I am trying to make a password based door lock. It will have a pre-defined one time password. I want this one-time password to get over-written, the very first time the lock is turned ON by the user. Now when the user has over-written the password by the one of his own choice, he can use the newly set password to get the access to the door. Also, in future if user wishes to change the password set by him, he should be able to do so...

This is what my exact theme behind the code is....

Last Edited: Fri. Dec 14, 2018 - 02:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why do you use external interrupt? What is your motivation to use it? Why do you think it is necessary?

- Brian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Geronimo wrote:

Why do you use external interrupt? What is your motivation to use it? Why do you think it is necessary?

 

Its not necessary for me to use interrupt.. How else will I be able to change the password in the mid execution of program? That's where my point is.... 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sanket_Agrawal wrote:

How else will I be able to change the password in the mid execution of program? That's where my point is.... 

 

Think about it...what else will your program be doing at the time that you want to change the password? Why will it need an interrupt? It's a lock. It does nothing until you press a button. It is either locked or unlocked. If it's unlocked then a valid password has been entered. If it's locked then the only way to unlock it is to enter a valid password.

 

Now, using that knowledge, draw a flowchart and design your program.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

Sanket_Agrawal wrote:

How else will I be able to change the password in the mid execution of program? That's where my point is.... 

 

Think about it...what else will your program be doing at the time that you want to change the password? Why will it need an interrupt? It's a lock. It does nothing until you press a button. It is either locked or unlocked. If it's unlocked then a valid password has been entered. If it's locked then the only way to unlock it is to enter a valid password.

 

Now, using that knowledge, draw a flowchart and design your program.

 

You are true. But I want to add a feature that facilitates user to change password anytime according to his wish. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sanket_Agrawal wrote:
I want to add a feature that facilitates user to change password anytime according to his wish.

I would think this user must first be authenticated (by entering the correct password first) before a change will be permitted.

So the lock must be in the unlocked state, during this state, scan for the user asking to change the password, (how is this done, button press other then the keypad, or specific key press on keypad)

In the unlocked state, what else would the program be doing, so should be easy to poll for the change password input.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
https://www.onegold.com/join/7134f67c2b814c5ca8144a458eccfd61

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sanket_Agrawal wrote:
But I want to add a feature that facilitates user to change password anytime according to his wish.

I don't quite know how to explain this, nor tell you where to look for an explanation.   A microcontroller application can do many things.  Yes, only one at a time, but you service the events in a timely manner.

 

Perhaps an example.  Consider yourself, sitting at your desk.  You can only do one thing at a time.  let's say you are playing online Texas Hold'em tournament, like I am doing now.

 

Does that mean I cannot listen for the ring of the phone?  No.  Does that mean I cannot check my email periodically?  No.  Does that mean you canot check the clock occasionally, to see if it is time to go to bed?  No.

 

In your case, you check repeatedly for the command to be issued to enter the password change state of you application.  Most commonly, every few milliseconds (5 milliseconds or 10 milliseconds are common) you cgather the state of all your inputs.  Then you enter them into your multi-stage debounce routine.  Then you check the confirmed/debounced state.   This all takes a few microseconds every few milliseconds -- about 0.1% of your CPU bandwidth.  When you have a confirmed command, then you act upon it.

 

 

 

 

 

 

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But I want to add a feature that facilitates user to change password anytime according to his wish. 

Your lock program is running.  Maybe it is locked, maybe unlocked.  In any case, it is executing perhaps a million instructions per second, over and over and over.  How can you use some of those instructions to allow user interaction?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When the lock in shipped, you can put in eeprom a flag indicating that this is a brand new lock. So, when turned on, it will prompt the user for the initial password, store it in eeprom, then change the flag to indicate a valid password now exists. This part is easy.

 

What I don't understand, is what you mean by "a feature that facilitates user to change password anytime". Maybe the user presses certain buttons at the same time, this will enter "password changing mode", but obviously, the user must first authenticate with the old password!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

Sanket_Agrawal wrote:
I want to add a feature that facilitates user to change password anytime according to his wish.

 

how is this done, button press other then the keypad, or specific key press on keypad

 

 

I am doing exactly the same thing. In your words, key is getting pressed on its own for the first time. Hence instead of verifying one time password, it directly asks user to change the password. 

Now got my point!...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

 

What I don't understand, is what you mean by "a feature that facilitates user to change password anytime". Maybe the user presses certain buttons at the same time, this will enter "password changing mode", but obviously, the user must first authenticate with the old password!

 

 

consider yourself a customer. you bought a new password based lock for your home. obviously you will power it ON. When you will power it ON, it will check one time password (The motive of this checking is to ensure that the lock has not been tempered in mid way and is being turned ON by the end user for the first time). As soon as it verifies the one time password, it will prompt you to change the password (obviously because one time password was stored in it). Now when you have changed the password, you can gain access to door anytime. Hope you understand till here...

 

Now if you feel like changing the password, that you had set upon receiving the lock, you should be able to do so. For this purpose I have used External Interrupt in my code. However, it is not mandatary for me to get this task done through interrupt only. But I am unable to figure out other method! 

 

Now the problem that I am facing with my code is external interrupt is getting executed on its own for the first time when I turn ON the lock, which should not happen. In my knowledge external interrupt should get triggered only when user pushes a button attached to INT0 pin of the controller.

 

I hope now I am able to deliver the exact idea!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think we understand the task better than you. We’re getting you to explain it for your education, not ours. Based in your code and your explanation, i still see no need for an external interrupt. And why the PORT & PIN code all over the place - i cannot make sense of that or why you would do this.

You’ve still not told us how the switch is connected to the external interrupt.

If you’re interested, we can advise how to improve your code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
I think we understand the task better than you. We’re getting you to explain it for your education, not ours. Based in your code and your explanation, i still see no need for an external interrupt. And why the PORT & PIN code all over the place - i cannot make sense of that or why you would do this. You’ve still not told us how the switch is connected to the external interrupt. If you’re interested, we can advise how to improve your code.

 

Kindly see the picture.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
        GICR=0x40;
		MCUCR=0x02;
		PORTD=PORTD | 0x04;

		should be

		GICR = (1<<INT0);      //enable extint0
		MCUCR = (1<<ISC01);    //falling edge trigger extint0
		GIFR = (1<<INTF0);     //clear extint0 flag
		PORTD |= (1<<PD2);     //enable pullup on extint0

and don't do this:

if((PINB & PORTB)==0xe0)

I suspect your keypad code is flawed unless you have diodes in your keypad. The rows (columns?) should only be held low or set to input. Your code actively drives them high. Certain key combinations will cause a short circuit.

Last Edited: Sat. Dec 15, 2018 - 08:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

        GICR=0x40;
		MCUCR=0x02;
		PORTD=PORTD | 0x04;

		should be

		GICR = (1<<INT0);      //enable extint0
		MCUCR = (1<<ISC01);    //falling edge trigger extint0
		GIFR = (1<<INTF0);     //clear extint0 flag
		PORTD |= (1<<PD2);     //enable pullup on extint0

and don't do this:

if((PINB & PORTB)==0xe0)

I suspect your keypad code is flawed unless you have diodes in your keypad. The rows (columns?) should only be held low or set to input. Your code actively drives them high. Certain key combinations will cause a short circuit.

 

I have made the changes. Now the code runs fine. But now some other doubts regarding this have come up in my mind.

 

#1 How do the two syntax differ..

GICR=0x40;

MCUCR=0x02;

PORTD=PORTD | 0x04;

 

          should be GICR = (1<<INT0); //enable extint0

                         MCUCR = (1<<ISC01); //falling edge trigger extint0

                         GIFR = (1<<INTF0); //clear extint0 flag

                         PORTD |= (1<<PD2); //enable pullup on extint0

I am asking this for my concept because the way I have written it, never troubled me. It works....

 

#2 If I trigger interrupt immediately after "WELCOME" is dispalyed, then it returns to main program after its execution. However, if I trigger it during the time when "YOUR PIN?" is displayed, it does not return to main program after its execution. It remains stuck at "PIN MATCHED". Then if I restart simulation, it works fine for the latest pin I have set.

 

#3 Also it is given in the data sheet that INTF0 gets cleared upon execution and gets set upon triggering of interrupt. Then what is the purpose of writing GIFR = (1<<INTF0);

Last Edited: Sat. Dec 15, 2018 - 09:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. You used 'magic numbers' - Google that. 0x40 = bit 6 which in this instance is a bit named INT0 in the GICR register.  The #define INT0 is equal to 6. (1<<6) = 0x40. So I've just used bit names to make the code easier to read. For all intents and purposes, the code is identical but mine is readable to humans.

 

2. Your code sucks. If you can't debug the code you've written, then you didn't understand it. Rewrite it so you understand how it works.

 

3. What happens on startup? You enable falling edge so this might trigger INTF0 but because the interrupt is not enabled, nothing happens but INTF0 is still set. When you enable interrupts, what happens? The purpose of clearing the bit should now be obvious.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Everything clear till here. The door lock I was trying to make is now working exactly the way I wished it to. During simulation I tried to interrupt the lock's normal operation and observed that INT0 does not return to main program after execution. 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gee, I had to look in K&R to find that goto is really available in C.  I thought they did away with it after FORTRAN.  Now I am going to have to find a way to use it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sanket_Agrawal wrote:
observed that INT0 does not return to main program after execution.

Sigh.  You know that we will find that hard to believe -- unless you messed with ISR mechanism.  Let's see a short complete program that exhibits this behavior.

 

 

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

3. What happens on startup? You enable falling edge so this might trigger INTF0 but because the interrupt is not enabled, nothing happens but INTF0 is still set. When you enable interrupts, what happens? The purpose of clearing the bit should now be obvious.

I wish more people were aware of this issue.  Including me when I was young and stupid-smart.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
I wish more people were aware of this issue.

I guess one could all it an "issue".  Is it an "issue" that the sky is blue because of certain factors?

 

Kartman wrote:
3. What happens on startup? You enable falling edge so this might trigger INTF0 ...

Now, I cannot remember digging into this particular situation, but this bit might nearly always be set, if the INT0 pin is low at startup?  Isn't the default "low level"?  [Yes.] [[ however, he datasheet says "logic change" so it would have to 'get' to low level, I guess.]]  The point is that one can construct a case for nearly all of the interrupt flags to be set.

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

 

The point is that one can construct a case for nearly all of the interrupt flags to be set.

That's the issue.  It's not obvious, certainly not to novices, and it will bite you until you learn to be aware of it and to preempt it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The way to create good software is to think about it, design it, increase detail on the design and finally implement it. Don't rush straight to implementation without thought/design as it's clear you have done here. If you come up with a well structured design then implementation will be trivial. I bet you determine during the design phase that there is no justification for doing password changes within interrupts!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So the password is reset by a button? And how is that button accessed? You know this is a bad idea in terms of security, right?

 

Last Edited: Sun. Dec 16, 2018 - 01:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

So the password is reset by a button? And how is that button accessed? You know this is a bad idea in terms of security, right?

 

 

Actually I was wondering the same ?!

 

if the above schematics is true, it means that it can be reset anytime by anyone

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And I dont understand why you dont make it easy for yourself by atleast making pin definitions,

 

e.g:

 

#define BUTTON_PIN 2

#define .................... 3

 

etc...etc.

 

Sit down with yourself, realize again the concept that you would like to implement, because based on what you said it doesnt make sense at all.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Moe123 wrote:

El Tangas wrote:

So the password is reset by a button? And how is that button accessed? You know this is a bad idea in terms of security, right?

 

 

Actually I was wondering the same ?!

 

if the above schematics is true, it means that it can be reset anytime by anyone

 

For resetting the password, it requires old password to be verified first. Else "Fail to change password".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reset button is on the inside of the door, so one must open the door to get to the button, or at least I would think so!

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
https://www.onegold.com/join/7134f67c2b814c5ca8144a458eccfd61

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

The reset button is on the inside of the door, so one must open the door to get to the button, or at least I would think so!

 


yes. The reset button is on the other side of the door.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you never stayed in a hotel with a safe in the wardrobe? I'd just examine exactly how those are implemented and copy exactly that!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, the password reset button can be read in the same loop that reads the keypad, there is no need to complicate things IMO.