I think the answer is no. Since the ISR might be handled completely during that time, there is no trace left afterwards (except when you set a flag, as you already mentioned).
What do you want to do? You mention you have a time-critical code part - why are you not able to disable interrupts when it runs? (And why is it problematic when an interrupt occurs during its run-time?)
Within this procedure I need absolutely determinable calculation delay (physical device while measuring). The ISR on the other side is needed for communication that can not be done with UDBs (complexity).
I can live with dropping results rather than having wrong calculation delay. There is time extrapolation working in.
One better solution could be to save the interrupt request over the critical section, that is short. I will check.
How long does the calculation take? What are its input parameters? (When I understand you right you have a physical device, measure some of its parameters and do a calculation from these values). Maybe you can elaborate a little bit more on that?
Maybe its simpler to just store the values at exactly the right point in time, by using using either hardware (ADC with DMA?) or a high-priority ISR. Then do the calculation later on, when it can be interrupted.
When you mark your code as 'critical section', any interruots occuring during that section will be handled when the section ends. You don't need to handle this manually. (See the System reference guide at http://www.cypress.com/?docID=36846 , look for CyEnterCriticalSection).
Oh, and on a side note: even when your calculation is not interupted its won't run in the same duration every time. Factor like branches, cache misses, memory access delays and different execution paths all will affect that time the code takes.
Hi, this would be the solution, because my critical section only needs, that no (longer) interrupt will occur.
I did not read out, that CyExitCriticalSection will raise interrupts, that were pending during the critical section.
Can you explain this further?
Thanks in advance!
EnterCriticalSection() will disable all interrupts temporarily and with ExitCriticalSection() interrupts will be set back to their original state. Since no programming is done to the interrupt controllers, all during that critical time signalled interrupts are saved and will run in the order of priority when the critical section is ended.
Since there might be other time-critical processes running, as I2C, I would like to know how long your section endures.
Okay it works as supposed :-)
Until today I thought, that while working inside critical section I will loose all incoming interrupts. So I didn't used it.
The time cricital part is 5 to 10us, so short enough for my interface interrupts, that are able to wait this time.
Thanks for your help!
I'm glad to hear you got it working.
(But I still think that using hardware to do such time-sensitive stuff is the way to go)
Of course it is mixed hardware / software stuff with high complexity :-)
It is a fusion of several measured incoming data that is extrapolated to a future timestamp, that the data will have, when it's write to datapath is completed ;-) It is a synchronized system with manual limited optimization for the special code parts, that are written to have nearly the same delay for each branchpath. Further we have timing parameters that can be adjusted. It is working as it should.