Re: [ECOS] ISR Vs DSR

[Gary Thomas <gary at mlbassoc dot com>]

Please copy email to the discussion list so that all may benefit.

On Thu, 2005-01-13 at 14:33 -0800, ecosrtos ecosrtos wrote:
> thanks Gary
> regarding one point you made 
> Quote"  Not really as you could get incorrect results if your interrupt occurred
> during the time that the system clock DSR was running! " EndQuote
> 
> What I understand from the above sentence is that my interrupt's ISR
> may block the Kernel from incrementing the real time clock tick count.
> is that correct?

That's not what I was implying.  Your ISR could run while the system
clock DSR is running (this is allowed - DSRs can be interrupted by ISRs)
If your ISR then made a call to cyg_current_time(), it might not get the
correct value as the interrupt could happen just while that value was
being changed.

> Well if this is the case, then any ISR could do that, no matter how
> small it is. So surely ecos must have the interrupt responsible to
> increment RTC tick count to be highest priority and will always occur.
> Please explain.
> 
> 
> 
> On Thu, 13 Jan 2005 15:03:31 -0700, Gary Thomas <gary@mlbassoc.com> wrote:
> > On Thu, 2005-01-13 at 13:55 -0800, ecosrtos ecosrtos wrote:
> > > Reference to Page 47 Step 9 ECOS book by Massa book
> > >
> > > http://www.informit.com/content/downloads/perens/0130354732.pdf
> > >
> > > If scheduler lock variable is 0 then the DSR executes else the thread
> > > that locked the scheduler variable executes, therby delaying the DSR.
> > > In my application I want to timestamp when the interrupt occurs (using
> > > cyg_current_time() and HAL_CLOCK_READ()) accurately right after the
> > > interrupt occurs and these functions are called in the DSR of the
> > > interrupt.
> > >
> > > Now if the DSR is delayed because some other thread starts running
> > > then I will get a wrong reading of the time. An option is to transfer
> > > the timestamping code into the ISR. However this goes against the
> > > 'conventional' philosophy that ISR should do as little as possible.
> > >
> > > Question) Is there a better way to solve this issue that putting
> > > timestamping code into ISR?
> > 
> > It depends on what the timestamp is supposed to represent.  If you want
> > it to mean the absolute time when the interrupt occurred, then you'd
> > have to take the timestamp in the ISR.  If you mean it to be the time
> > when "meaningful" action for that interrupt takes place, then put it
> > in the DSR.
> > 
> > >
> > > Note timestamping code is really just 3 – 4 lines of code. Is it just
> > > OK to leave it in the ISR?
> > 
> > Not really as you could get incorrect results if your interrupt occurred
> > during the time that the system clock DSR was running!
> > 
> > Depending on your hardware, you might be able to use a separate
> > timer (hopefully high resolution) to capture the timestamps.  Then
> > a simple correlation between those timer values and the system
> > time (cyg_current_time()) would get you the absolute time.
> > 
> > --
> > ------------------------------------------------------------
> > Gary Thomas                 |
> > MLB Associates              |  Consulting for the
> > +1 (970) 352-4947           |    Embedded world
> > http://www.mlbassoc.com/    |
> > email: <gary@mlbassoc.com>  |
> > gpg: http://www.chez-thomas.org/gary/gpg_key.asc
> > ------------------------------------------------------------
> > 
> >
-- 
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 352-4947           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------


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