This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
回复: [ECOS] put unmask in ISR rather than DSR causing interrupt lost
- From: Randy <randyqiuxy at hotmail dot com>
- To: Randy <randyqiuxy at hotmail dot com>, "Stanislav Meduna" <stano at meduna dot org>
- Cc: "eCos Discussion" <ecos-discuss at sourceware dot org>
- Date: Wed, 10 Apr 2013 17:29:43 +0800
- Subject: 回复: [ECOS] put unmask in ISR rather than DSR causing interrupt lost
- References: <CA+QuBBfU01exmSPQQuXqhGOLASYa=4w32Gp=R0bR9DaUWvJJtA at mail dot gmail dot com>, <51546EFC dot 5050603 at dallaway dot org dot uk> <BLU0-SMTP3646F7EEA8206EF237E9FD3C3DD0 at phx dot gbl>, <5158269C dot 5000804 at meduna dot org> <BLU0-SMTP36883F43DD5BCCFFF94355FC3DD0 at phx dot gbl>, <51597647 dot 1010803 at meduna dot org> <BLU0-SMTP3875CC7A757A307F1E468B2C3C40 at phx dot gbl>, <516172E4 dot 6080207 at meduna dot org>, <BLU0-SMTP313D1383BE6FA15183677A7C3C70 at phx dot gbl>
- Reply-to: randyqiuxy <randyqiuxy at hotmail dot com>
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
>>
>>