Interrupt Handling Problem

The problem is that you are calling the same function from both interrupt and non-interrupt code:

http://www.keil.com/support/man/docs/lx51/lx51_l15.htm

It is also usually very bad practice to do stuff like printing from within an interrupt.
In general, Interrupt Service Routines (ISRs) should do the minimum necessary to capture any data, and inform the main loop of the event; the main loop then does any long-winded processing like printing.

The problem is that you are calling the same function from both interrupt and non-interrupt code:

http://www.keil.com/support/man/docs/lx51/lx51_l15.htm

It is also usually very bad practice to do stuff like printing from within an interrupt.
In general, Interrupt Service Routines (ISRs) should do the minimum necessary to capture any data, and inform the main loop of the event; the main loop then does any long-winded processing like printing.

Hi Andy,
I only want to take input for my key press but i want to also redirect to another function without going back to main which is not possible from what i have read till now so i wanted to do the display there.
i am running a critical process which should quit only on interrupt. In my main loop i don't want to check for any value. I can always put the value of the key press in a memory location and read it but that is what i want to avoid. Reading any thing will put my critical process out of loop. Do you think it is possible for me to go to another function without going to main. ie quiting the main only on an interrupt and doing the rest of function outside.

Ex. Let us say
This is my main

void main()
{
while (1)
{
}
}

and

void int0 (void) interrupt0
{

}

myproc()
{

}

can i run my proc directly on interrupt but myproc is quite long and will have displaying and various other functions that are in other function which are not in main but called from it. main is very small.

i am running a critical process which should quit only on interrupt.<p>

In that case, the process cannot be really "critical" (since it can be interrupted). You may want to specify the processing needs of this process more clearly, as in when and how long it may not be running.

The usual way it to set some flag in the interrupt service routine, and have main (or some other function that runs periodically) check this flag to see if the actual processing/output routine needs to be called.

Hi Christoph,

I say it is critical because i am checking for wegand data such that it is comming at any interval and needs to be processed as soon as it arrives if i miss a few bits the whole data is of no use and i do not have a buffer for it either. When an interrupt comes from key pad the data is assumed to be stoped and even if it arrives should be ignored that is the reason i said it is Critical. i am using interrupt to avoid missing any data.

void Inter0 (void) interrupt 0
{
clear();
init1();init1();
iprint("Inside Interrupt");
}

iprint is a display function which is

void iprint(char *aaa){
unsigned int i=0;
for(;aaa[i]!=0;i++)display(aaa[i]);
}

Just figure: how long does this interrupt take to process.

Erik

Hi,

I would suggest that you look into structuring your code so that the ISR accumulates the Wiegand data into a buffer as it arrives and sets a flag to indicate accumulation complete.

Then, the main foreground loop can poll the 'accumulation complete' flag and process all of the data when available.

It would be critical to accumulate the bits with no chance of missing any - Processing the data is not (normally) so critical.

I have used this technique on a number of media acquisition modules (Wiegand, magstripe and barcode) for a number of years and found it to be a good reliable method.

The key point is that you should try to keep the ISR as small (and efficient) as practically possible - Get in and out quickly.

I would suggest that you look into structuring your code so that the ISR accumulates the Wiegand data into a buffer as it arrives and sets a flag to indicate accumulation complete.

The baove, while correct, is too limited. This, by no means, is a 'wiegand' or such issue.

more complete : if at all possible, no processing of incoming data should take place in the ISR

Erik

more complete : if at all possible, no processing of incoming data should take place in the ISR

Erik,

I totally agree with your comment - It is a maxim which I have followed for years.

Since the thread originator mentioned wegand (meaning Wiegand ?), I thought that it might be useful (to him) to describe the task in that manner.

Whichever - I hope he finds my/your/our comments useful.

David.

Hi David,

Sorry for the late reply but i'm from india and for me your input came in the night.
I am not so good with interrupts as you might have seen from my code.
How do I use the ISR to collect data ? should i give the data pin to an interrupt?.

Thanks.
Ajay

Hi,

Assuming you are talking about collecting Wiegand data:

If you have the CPU resources available, one way would be to connect D0 to INT0 (P3.2) and D1 to INT1 (P3.3). Depending upon your hardware, you may need to invert the signals.

Configure both inputs as edge interrupts.

When an interrupt occurs:

1 - Add a ZERO or a ONE to an accumulation buffer (depending upon which interrupt occured)
2 - Increment a 'bit received' count
3 - If all data has been received, disable the interrupt(s) and set a flag to say 'acquisition complete'

This is a similar technique to one I have used on a number of platforms with a number of CPU cores - Although I have various other checks to ensure that it is completely resilient to all predicted possible situations. For example, you may want to include a timeout check to ensure that the acquisition does not wait forever if a bit is unexpectedly missed.

Hope this helps,

David.

Hi David,

Thats will work, i think, i will try it out and yes i mean Wiegand data, sorry about the spelling mistake i'm weak at English.
Thank You very much.
Ajay

"Wiegand" sounds more like German to me!

;-)

You never know it might have been a German who thought of it and named it after his son :))))