public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
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
>>>
>>>

  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).