Interrupts occurrence

Wed Apr 3 03:12:16 UTC 2002

Angelo Fraietta wrote:
> 
> You are 100% right in what you have stated. I ran a MIDI input into
> the device and found that at the top level of input, I was getting
> overflows.  I created this situation by sending continuous sysex
> blocks of 1024 bytes into the device from my PC MIDI output. I had to
> reduce the time in the PIC for the data exchange by using global
> variables instead of returned function parameters and using the
> #use_fast_io to remove any unnecessary changes to the data direction
> register.  Although these coding practices (such as using globals) are
> normally frowned upon, this is what I had to do to reduce the overhead
> in data transfers.

On one hand, I am sorry you had to resort to that but on the other, I
recall that your CPU is not that fast so it was a necessary evil to
extract that last bit of performance.  It sounds like the code you
tuned was HW specific anyway so it isn't that big a deal in the 
grand scheme.  You can still provide standard interfaces on top of
that. 

This is great news.

--joel

> Joel Sherrill wrote:
> 
> > 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 adeq
> >> > uately 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)
> >>
> 
> --
> 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