From: Randy <randyqiuxy@hotmail.com>
To: Randy <randyqiuxy@hotmail.com>, "Stanislav Meduna" <stano@meduna.org>
Cc: "eCos Discussion" <ecos-discuss@sourceware.org>
Subject: 回复: 回复: [ECOS] put unmask in ISR rather than DSR causing interrupt lost
Date: Sun, 14 Apr 2013 11:39:00 -0000 [thread overview]
Message-ID: <BLU0-SMTP14119AC133E089A26AE1335C3C30@phx.gbl> (raw)
In-Reply-To: <BLU0-SMTP2924A182475BCD6AEDEC91C3C70@phx.gbl>
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
>>>
>>>
next prev parent reply other threads:[~2013-04-14 11:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 14:40 [ECOS] Is eCosPro a fork of eCos? Liam Knight
2013-03-28 16:25 ` [ECOS] " John Dallaway
2013-03-28 18:40 ` Liam Knight
2013-03-31 8:08 ` [ECOS] why should ISR arrange that the same interrupt would not recur until DSR completed? Randy
2013-03-31 12:06 ` Stanislav Meduna
2013-03-31 14:48 ` Randy
2013-04-01 11:59 ` Stanislav Meduna
2013-04-07 12:05 ` Randy
2013-04-07 13:21 ` Stanislav Meduna
2013-04-10 8:36 ` [ECOS] put unmask in ISR rather than DSR causing interrupt lost Randy
2013-04-10 9:27 ` 回复: " Randy
2013-04-14 11:39 ` Randy [this message]
2013-04-18 2:50 ` [ECOS] why did not enable interrupt before call pending dsr while not use interrupt stack Randy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BLU0-SMTP14119AC133E089A26AE1335C3C30@phx.gbl \
--to=randyqiuxy@hotmail.com \
--cc=ecos-discuss@sourceware.org \
--cc=stano@meduna.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).