回复: 回复: [ECOS] put unmask in ISR rather than DSR causing interrupt lost

[Randy <randyqiuxy at hotmail dot com>]

Hi all,
I know what's wrong with my understanding..
If I unmask interrupt in ISR, it is possible that the same interrupt recurs just before the OS put its DSR in DSR FIFO_List, then when the ISR is over again, OS finds that the dsr_count is not zero, so it just do "dsr_count++". So, there is only one DSR in FIFO list but keeping dsr_count(>0) for this interrupt, if I don't care "count" parameter in DSR, it seems that I lose one interrupt.
--------------
Thanks a lot..
Best regards,
Randy
>Hi all,
>sorry that I maybe not very clear to describe my problem..
>>Hi Stano & all,
>>>On 07.04.2013 14:06, Randy wrote:
>>>
>>>> After one ISR is over, the DSRs in FIFO queue starts to run one by
>>>> one like A=>B=>C=>... If one interrupt comes when B is running, then
>>>> what will happen?
>>>> If B is stoped and the new ISR is going to run,
>>>> then, how and when does the B come back(we may cann't use
>>>> "reschedule" to describe it)?
>In fact, the problem I faced make me think about the interrupt model details like above.
>The problem described as this mail title shows,
>eCos require that we should unmask interrupt in DSR, but why would we lost any interrupt when I unmask in ISR rather than DSR?
>#######  losing interrupt here means that, sometimes DSR didn't run when I put unmask in ISR rather than DSR.
>Thanks for your advance..
>>>
>>>The processor detects the interrupt, saves the current program
>>>counter on the stack, looks up the table defining wich handler
>>>is to be run for tha particular interupt source and runs the
>>>handler.
>>>
>>>When this handler returns, then whatever the handler interrupted
>>>will continue where it was interrupted, in this case B.
>>>
>>>The exact sequence of steps is hardware- and configuration-dependent,
>>>the interrupt and exception handling is where the architectures
>>>differ significantly.
>>>
>>>> Or, could you tell me which code snippet in eCos3.0 shows the handler?
>>>
>>>This is architecture specific partly assembler code. Look for
>>>vectors.S and other files in your HAL, but you will only
>>>understand it if you have quite detailed knowledge about your
>>>processor. I never needed to go that deep.
>>>
>>>Regards
>>>-- 
>>>                                         Stano
>>>
>>>