For my application, I need to take note of any level transition in the GPIO port. The program within my ISR currently exceeds the time of the next transition. To solve the problem, I cleared the interrupt right at the start to allow the GPIO port to react to another level transition. As an example with the code below, switching the clear_interrupt from the first line and last line allows me to obtain a delay of 10 seconds when I press and release a push button. What I want to know is if this method has reacted to what I had expected?

cyisr_gpio(example){

clear_interrupt();

Delay(500);

}

Does this also means that two instances of the interrupt is created and executed?

Thanks!

One should always keep the ISR routine as short as possilbe.

and recusive interrupt is HIGHLY not recommened unless it is really necessary.

One thing to remember that PSoC3 is 8051 core and the stack is very small. 

What is your application. People here may be able to suggest a way so you don;t have this problem.

The application is to detect any level transition at the limits of microseconds. Any flag assignment exceeds the limit. There is no workaround than to allow the interrupt to be called again. I need to understand if the interrupt has been called twice or a bug

You mean you want to detect 2 transition which is microseconds apart? 

An input pin can be configured to trigger on both edges so thats

easy. More concern is the high level of MIPs being used if

this pin is toggling at a uS rate.

If your delay in ISR is longer than periodicity of pin toggling rate the implication

is that you are "dropping" ISR events......?

Lastly ISR is causing stack push, recursively doing this is an invitation to

disaster.

Regards, Dana.

@lleung yes, that is the worse case

@dana yes, this would be an issue if the number of interrupt exceeds the stack limit. However, I am more confused if re-calling the same interrupt code is possible. I mean, its possible that GPIO2_ISR is serviced after GPIO1_ISR. But I am not sure of I can service GPIO1_ISR right after GPIO1_ISR. This points to another question: Being a programmable device, can I change the interrupt service stack size?

This might help -

http://www.cypress.com/?docID=34362

Regards, Dana.

And this - http://www.cypress.com/?app=forum&id=2233&rID=56286

Regards, Dana.

You may not put a delay into an ISR. That is against all "rules" and easily may stall your system.

What's about to "count" the level transitions with counters? That could be done easily with a resolution of a few µs or less.

Make some signal conditioning and then input it into two counters, one of them inverted if this is required (You'll have as much low to high as high to low transitions). Polling the counter or waiting for an interrupt on count will give you the actual result of the burst.

Bob

PSoC3 just like other 8051 CPU, use the intenal RAM for stack which is a total of 256 bytes. Some of those are working registers and some are specially used for bit variables.

I am not sure if Keil uses a software stack or not, but software stack slows down ISR.

For PSoC3 the stack is limited by what the compiler allocated for during compilation. Don't think we should touch/change it.

You can allocated the stack size for PSoC5 via creator

Recusive interupt should be avoid as you may overun your stack if the interrupt triggred quicker than your response time. then your system would failed and the outcome is unpredicable. 

Provide that you need to handle interrupts that are comes in a short burst, and as you stated that the interrupt would comes faster than your ISR and is acceptable to you.

You can

1. As suggesteg byt others members, to use a counter in the interrupt routine, and perform the required operation in your main loop by checking the counter (needs to have some mechanism to control accessing of the counter during interrupt and the main loop).

Or.

2. Proveded you ONLY need to handle 2 succesive interrupts. 

use 2 ISR souce to 2 ISR routines say ISR1routine and ISR2routine

in ISR1, clear pending of ISR2 and enable ISR2. Rememeger the prority of the two ISRs, you have to set ISR2 higher IF you wants to handle ISR2 first. otherwise, ISR2 would be handled after ISR1.

@Ileung

I'm not quite sure what you try to accomplish with two ISRs. I think we have to keep in mind that just a handfull or two of instructions will be in the needed reaction time of a few µs. On a 8051 machine only a context-switch to an alternate register set is as fast, but that will not be able to handle more than three signals following each other because there are 4 register banks..

The size of the 8051 stack is fixed to 265 bytes and cannot be changed in the Creator. This only works for PSoC 5 with its ARM architecture. 8051 is an rather old architecture and sometimes we come to its limits.

I just came to anotherr solution that could be capable of handling those requests: Why not doing that in hardware???

Take some D-FFs and some glue-logic like a decoder that at each incoming signal decides which FF has to be set next.

In an ISR or at a poll the FFs are read-out and re-set when handled. When that glue logic is working like a circular buffer you can capture a burst easily. This would be a nice Verilog work.

Bob

@Bob I think Ileung is trying to overcome the dilemma of allowing recurring interupt.

Also for your Verilog solution, can we code in Verilog in Creator?

Oh, yes, you may program in Verilog in creator 2.1. There is a bunch of videos and documents, just type "verilog creator" into the keyword search and the browse through the 500 results (smile)

As an extra: every UDB (a PSoC has 24 max) contains a small programmable ALU, a bi-directional shifter, two FIFOs, a handfull of registers and a lot of status-bits all programmable by the user, search for "DataPath".

Happy coding

Bob

thanks bob. Verilog is so much easier to code than C programming. I will take a look at the tutorials soon.

Well, which one is easier is a matter of taste, I do prefer C. But a hardware solution will always work a lot faster than any software regardless which compiler, language or algorithm you use.

Btw: may you tell us here openly what you are trying to accomplish or what you are measuring with your pulse-burst counter, I've learnt a lot of physics some time ago and may be of some help.

Bob

@Bob My application is simply taking note of all level transitions and the limit is ~1 micro second. All transitions are generated from a signal generator. This would require some real-time aspect of not dropping any transition, for which I have observed.

Unless I missed something its still not clear what you are trying to accomplish.

1) Count all transitions occuring at a uS rate and do a bunch of code execution when you exceed

a certain number of transitions ?

2) In 1) this has to be a continuous process, or can transition counting halt while code executed

after exceeding......

3) What does code have to do when transitions meet or exceed .....?

A more complete description would help all assist you.

Regards, Dana.