[ECOS] Re: On ecos interrupt process

[Nick Garnett]

张 亮 <johnsonest@hotmail.com> writes:

> Hi,nickg.
>    i am confused that ecos interrupt process:
>    for example:
>      ISR
>        |
>      int_end()
>          {
>             post dsr;
>            ....                (branch 1)
>             unlocks scheduler()------------------|
>          (branch 2)                              |
>          }                                       |       |
> |
>      restore int                                 |
>       return from int                            |
>                                                  |*********
>                                             call  all dsr and wake
> higher threads
>                                                  hal_switch _context()
>                                                       my question is
> whether branch1 is excuted in interrupt level,if yes,
> interrupt disable period is too long even use DSR machanism,if
> not,where exit interrupt level?  Brs/johnsonest

First, let's redraw your diagram to closer reflect the truth of how
eCos works:

interrupt VSR
      |
 {disable interrupts}
      |
 save CPU state
      |
 lock scheduler
      |
 switch to interrupt stack
      |
 [enable interrupts](1)
      |
 call ISR ---------|
                   |
              handle device
                   |
            acknowledge interrupt(2)
                   |
             request DSR run
                   |
      |-------------
      |
 switch back to thread stack
      |
 call interrupt_end() ------|
                            |
                         post DSR
                            |
                        unlock scheduler ----|
                                             |
                                       switch to interrupt stack(4)
                                             |
                                       [enable interrupts](3)
                                             |
                                        call any DSRs
                                             |
                                       [restore interrupt state]
                                             |
                                       switch back to thread stack(5)
                                             |
                            |----------N-new thread?
                            |                Y
                            |                |
                            |           switch context
                            |           {enable interrupts}
                            |                |
                            |           return from switch
                            |           {restore interrupt state}
                            |                |
                            |----------------|
                            |
                      zero scheduler lock
                            |
      |---------------------|
      |
 restore CPU state
 {enable interrupts}


In the above diagram, the actions in square brackets indicate optional
manipulations of the interrupt state. The actions in curly brackets
are implicit changes of state caused by the hardware or restoring a
saved PSR or equivalent.

If the interrupt enable at (1) is present, then the enable at (3) is
not strictly necessary, although it is harmless. If (1) is not present
then (3) causes all DSRs to be run with interrupts enabled. Since the
execution time of DSRs is non-deterministic it is important that they
run with interrupts enabled. Similarly, since their stack usage is
unknown, the stack switches at (4) and (5) help to reduce thread stack
usage. The entire sequence between (4) and (5) is a HAL implementation
option.

Whether it is possible to add the interrupt disable at (1) depends a
lot on the architecture and the interrupt controller. In particular,
how a pending unacknowledged interrupt is handled. If the hardware
behaves sensibly, then with the enable at (1), fresh interrupts will
only be permitted when the current interrupt is acknowledged at (2).
Poorly behaving hardware would cause an immediate re-interrupt at (1).

For simplicity, some HALs have not implemented the additional enable
at (1), but do implement the DSR sequence between (4) and (5). This
helps to reduce the interrupt latency without the added complication
of handling, and debugging, nested interrupts.


-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss