Interrupts, Help!

DDLP · Joined: 08 Jun 2011 Posts: 7

Hey there, I'm new to these forums and using BASCOM/AVR products and whatnot, so I would really appreciate some help! So this might be kind of a tricky problem but basically I'm using an ATmega324p chip, and I'm trying to run a stepper motor constantly, and use an interrupt triggered by a pushbutton to turn on a LED and then update an LCD display to show which LED is on. My problem is with the pushbutton and therefore the LED/LCD setup, basically I can't get a consistent trigger for whatever reason, it's not very responsive and seems to turn the LED on haphazardly. Here's my code so far, if someone wouldn't mind taking a look and perhaps giving me some ideas/suggestions. Thanks!

DDLP · Joined: 08 Jun 2011 Posts: 7

"Interrupt Flags can also be cleared by writing a logic one to the flag bit position(s) to be cleared." So a better question might be how do I write a logic one to the flag bit position, or what's the syntax really. Thanks.

DDLP · Joined: 08 Jun 2011 Posts: 7

So just in case any other newbs are having similar troubles... To solve this issue I changed the INT0 trigger to falling, and used a bitwait low so stop any bouncing after the button was pushed, and then cleared the external interrupt flag register to stop any bouncing that may have occurred when the interrupt was triggered....or I just got lucky, anyways here's the changed bit of code.

mattcro · Joined: 03 Oct 2007 Posts: 324 Location: Scotland

To clear the interrupt flag (best to do it just before returning from the interrupt handler), just use something like:

AdrianJ · Joined: 16 Jan 2006 Posts: 2470 Location: Queensland

There is already a Bascom solution for reading switches. Look up DEBOUNCE in the Bascom Help.

Mattcro is right, you should not use wait statements inside interrupt routines.

IMHO, you should not use an interrupt at all to read a mechanical switch. IRQs are for reading fast things, down in the order of microseconds, where the processor cannot easily access the line that fast. Mechanical switches pushed by humans are at most 5 times a second. There you can use a poll in the main loop, or even better use a timer ISR to poll the switch at a fixed rate. 100 times a second is plenty fast enough.

ivangel · Joined: 20 Sep 2010 Posts: 41 Location: Poland

You are right but the interrupt is one great advantage: it generates an interrupt, and interrupts the main program which is sometimes necessary ...

DDLP · Joined: 08 Jun 2011 Posts: 7

Hey thanks for the suggestion guys. @mattcro I'll have to try that timer interrupt for the motor. I definitely only disabled and enabled the interrupt as a precaution but I gather bascom is unique in that you don't have to, so I'll get rid of that. I only used the bitwait so that if on pushing the button, it bounced into the interrupt, it would have to wait for the button to be released to switch on the led, but that's definitely "kludgy". I have read that the external interrupts are commonly used for pushbuttons, and in this case I used it because I actually need the motor to turn back and forth like an oscillating fan, so I don't think I could really poll the main loop for satisfied IF statements, I'll try the timer ISR though that sounds great. @ AdrianJ I have used the debounce in other programs(and I tried in this one if you look at the first bit of code), but I had no success with it in this program although I don't think I was clearing the interrupt flag when trying it. It was very finicky in any case, perhaps it's just an even worse idea within an interrupt.

Thanks again all,

DDLP

EDIT: I was just thinking I probably could use if statements if I used a simple counter to count the number of times the motor pulse has been sent, and then at a certain value switch directions...oh well, my goal was to learn about interrupts, and I guess I've achieved that at least haha.

AdrianJ · Joined: 16 Jan 2006 Posts: 2470 Location: Queensland

You definitely should not use DEBOUNCE inside an interrupt. For a start, it looks for both edges of a switch closure, whereas the IRQ looks only for one edge ( usually ). So it will never work properly.

If you construct your main loop so it normally executes in a few msec, then polling a switch, or using DEBOUNCE, will work perfectly. That is not to say that you cant run much longer routines in a main loop. but you can usually organize it to run those only when some condition is met, so not on every main loop cycle.

Refreshing an LCD is typical. You cant read an LCD faster than about 2 per second, so why refresh it any faster ? So you can run a fast loop, and only refresh the LCD every nth loop, n being a counter set so that the refresh time is about 500 msec. Many other processes can be handled the same way.

DDLP · Joined: 08 Jun 2011 Posts: 7

Hey, so just as a follow up to this thread, I did end up using TIMER0 to run the motor, as it runs it very smoothly, as opposed to running it from a main loop and subroutine which sends the pulses out much slower, resulting in choppy movement. I also opted to use a dip switch for the LED's, and given that I used the timer interrupt for the motor, it is seemingly necessary to use interrupts(both external and pc) to trigger the LED's, in any case it runs very smoothly using all interrupts. Here's the latest iteration of the code, but please note it's not a final pristine product. Also please note that the LCD is configured using the built-in LCD options.(Options->Compiler->LCD)

AdrianJ · Joined: 16 Jan 2006 Posts: 2470 Location: Queensland

Good that your code works, and you are happy with it.
I would have done it more like this:

DDLP · Joined: 08 Jun 2011 Posts: 7

Great, thanks for taking the time to put that together, I'll have to try it out tomorrow.

DDLP · Joined: 08 Jun 2011 Posts: 7

Hey so I tried out you're program Adrian, but it doesn't seem to work at all. For whatever reason the motor wouldn't spin, and the lights wouldn't trigger. I believe it might be because if the timer interrupt is executing so quickly, or even before the pulseout is finished and then just piling up, then the main loop is never going to run, and it would essentially just keep pointlessly setting birqflag.0 without doing anything else.

AdrianJ · Joined: 16 Jan 2006 Posts: 2470 Location: Queensland

Hmm. Yes I suppose its possible. Timer0 is an 8 bit timer, so max count 256. And since you use prescale=1, that is 256 processor clock cycles. It might take nearly that to enter and exit the timer IRQ. You dont give the processor clock frequency, so I suppose its the default 1 MHz. You should really tell the compiler what frequency you run the processor at with the $crystal directive near the start of your code, else the value is taken from the compiler defaults, which may not be what you actually use in the processor.

Do you need the IRQ that often ? If you have those waitus 400 statements in your IRQ, then in fact the timer IRQ is not being executed every 256 usec either, its just that you dont notice it when you run that way. Typical steppers I have seen use pulses around every 1 msec or so at max, which is roughly what you have when you put the waits in the timer IRQ. You would get the same effect by setting a timer0 prescale of say 8 or even 64.

If you want finer control over the motor pulse timing, consider using Timer1, which has a 16 bit range. Then you reload the timer value inside the IRQ with a value to set the pulse width to whatever you need, in the range 0 - 65535. In reality the bottom limit is about 200, not 0. And remember the timer counts from the value you set up to 65535, then the IRQ happens as it rolls over to 0 again.

Of course, you could simply revert to your code, which works. The problem with that is that it is not really working how you think it is, so changing anything in it is likely to result in unexpected behaviour, and tracing exactly what is wrong in an even more complex program can be a hard task.