public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Randy <randyqiuxy@hotmail.com>
To: "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: Wed, 10 Apr 2013 08:36:00 -0000	[thread overview]
Message-ID: <BLU0-SMTP313D1383BE6FA15183677A7C3C70@phx.gbl> (raw)
In-Reply-To: <516172E4.6080207@meduna.org>

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?
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-10  8:36 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               ` Randy [this message]
2013-04-10  9:27                 ` 回复: [ECOS] put unmask in ISR rather than DSR causing interrupt lost Randy
2013-04-14 11:39                   ` 回复: " Randy
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-SMTP313D1383BE6FA15183677A7C3C70@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).