Interrupts occurrence

[Joel Sherrill]

Angelo Fraietta wrote:
> 
> I have to make a correction on those previous calculations. I did not
> read the settings on my CRO correctly. The actual values are 1 message
> every 450 us, (not 4 us) and 1 every 500us.  So I am actually at the
> extremes. The maximum transfer I could expect from a MIDI device would
> be one byte every 320 us (10 bits per byte). So not setting the event
> (as Chris Johns suggested) does save me a valuable 50us.

Aren't you down to the point of counting instructions? :)  450 usecs
isn't
a lot of time/instructions.  Having spend a good portion of my early
career
on smart serial controllers, I have some hard won advice.  If you
actually 
intend to sustain getting a byte every 320 usecs, then you have to
ensure
that your processing per-byte is less than that.  A good first step is
to write down the entire sequence of code executed for each byte.  Then
focus on which parts are unnecessary or not optimal for your case.  Eric 
Norum did this for EPICS and the resulting work sped up mutexes and
counting
semaphores.  I did a similar effort for the GNU Ada run-time "self"
routine and it showed a 5% improvement in system idle time for me
optimizing out about 60 instructions.  You are at the point where 
making sure the path you execute is minimal is important.

> Angelo Fraietta wrote:
> 
> > After some exhaustive testing I have come up with some figures that
> > represent data exchange rates between the Pic microcontroller and
> > the 386 using a PLA as an interface on an ISA bus using an interrupt
> > driven I/O read/write paradigm.
> >
> > What I have done is make the Pic and the 386 communicate with each
> > other, each triggering an interrupt with the other, causing it to
> > write to the other device.
> >
> > With the RTEMS event being triggered every  interrupt I have a
> > constant exchange rate of 1 message each way every 5 us.
> >
> > Triggering the event only if the receive queue is empty gives me an
> > exchange rate of 1 Message every 4 us. I am saving 1 us by not
> > sending the unnecessary event.
> >
> > The big factor in this test, however, is this method that I used to
> > check the exchange rates completely blows the 1 message every  650
> > us measurement I previously made away, thus proving that the
> > interrupt rate will more than adequately sustain an input Midi
> > stream running at maximum transfer rate (31.25kbs, which is about 3
> > bytes per ms)
> >
> > Angelo Fraietta wrote:
> >
> >> You are right. Sending the event if the queue was not originally
> >> empty when the ISR came is not necessary. I was already looping
> >> the task until the queue was empty; I was, however, sending the
> >> event regardless -- which is actually wasting CPU cycles. Thanks
> >> for the tip? I'll see what I can get the interval down to by not
> >> sending an unnecessary event.
> >>
> >> Chris Johns wrote:
> >>
> >> > Angelo Fraietta wrote:
> >> >
> >> >>  Within the ISR I am doing the following:
> >> >>  Reading a 16 bit word from an I/O address
> >> >>  Decoding and adding that word onto a queue that is emptied out
> >> >>  by a
> >> >>  running task
> >> >>  Checking a second queue for data that needs to be transmitted
> >> >>  Transmitting a word to the I/O card.
> >> >>  Setting an event that causes the running task to empty the
> >> >>  queue.
> >> >>
> >> > I would only send the event if the queue is empty and have the
> >> > task loop
> >> > until the queue is empty.
> >> >
> >> >
> >>
> >> --
> >> Angelo Fraietta
> >> PO Box 859
> >> Hamilton NSW 2303
> >> Home Page
> >> http://www.users.bigpond.com/angelo_f/
> >> There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
> >> There are those who seek knowledge to be known by others - that is VANITY
> >> There are those who seek knowledge in order to serve - that is LOVE
> >>     Bernard of Clairvaux (1090 - 1153)
> >>
> >>
> >
> > --
> > Angelo Fraietta
> > PO Box 859
> > Hamilton NSW 2303
> > Home Page
> > http://www.users.bigpond.com/angelo_f/
> > There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
> > There are those who seek knowledge to be known by others - that is VANITY
> > There are those who seek knowledge in order to serve - that is LOVE
> >     Bernard of Clairvaux (1090 - 1153)
> >
> >
> 
> --
> Angelo Fraietta
> 
> PO Box 859
> Hamilton NSW 2303
> 
> Home Page
> 
> http://www.users.bigpond.com/angelo_f/
> 
> There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
> There are those who seek knowledge to be known by others - that is VANITY
> There are those who seek knowledge in order to serve - that is LOVE
>     Bernard of Clairvaux (1090 - 1153)

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985