Does this also means that two instances of the interrupt is created and executed?
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
@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?
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.
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.
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).
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.
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 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".
thanks bob. Verilog is so much easier to code than C programming. I will take a look at the tutorials soon.