Interrupts occurrence
Joel Sherrill
joel.sherrill at OARcorp.com
Thu Apr 4 18:33:41 UTC 2002
Angelo Fraietta wrote:
>
> The speed is fine when I am using a 386DX at 33MHZ. When using the
> DIMMPC (386SX 40Mhz), however, the speed was still too still too slow.
> It was about 50us too slow to work at full speed. When you stated
>
> Aren't you down to the point of counting instructions? :)
>
> I though that this was a figure os speech. I found, however, that that
> is exactly what I had to do -- count instructions.
I did not intend it to be a figure of speech. Many embedded systems
have to worry about the amount of code executed per "byte" processed.
For high speed RS-232/RS-422 links this is critical. For example, at
19200 baud (not that fast :) with stop and start bits, you theoretically
get 520 microseconds between the arrival of each character. By the
time you vector an ISR, handle the chip, return you have consumed some
CPU time. My assumption is that you want to do real work with the byte
so you must leave some time over for that.
At higher baud rates or more serial ports, this problem gets
progressively
worse.
I will also throw out that I have seen many systems where you get a
single interrupt to indicate that one of N serial ports on the system
needs attention. You then have to "go fishing" to figure out which
one and why. This can end up consuming a lot of time in an ISR.
> By stepping through the code using the simulator, I found that
>
> output_bit (SPI_PLA_DATA, pla_out_data.flags & 0x80);
>
> used five instructions, however,
>
> if (bit_test (pla_out_data.flags, 7))
> {
> output_bit (SPI_PLA_DATA, 1);
> }
> else
> {
> output_bit (SPI_PLA_DATA, 0);
> }
>
> only used three instructions. This became a saving of 64 instructions
> per exchange. Additionally, I found that
>
> for (byte_num = 0; byte_num < 8; byte_num++)
>
> used 10 instructions; I replaced the code within the for loop with an
> inline function and called it eight times. Although it does bloat the
> code, it cut enough time off the function to make it worth it (320
> instructions per exchange).
>
> The reason I have detailed a bit more on what I actually did was so
> others may find a use for some of the techniques I used.
Yes. Optimizing frequently executed code is important to overall system
performance.
RTEMS has an optimized "self" for the GNAT run-time. I recall that
doing this saved only about 60 instructions but the system I did this
for was calling "self" about 5000 times per second when the system was
largely idle. This resutled in a noticeable amount of CPU time being
freed for real application code.
> Joel Sherrill wrote:
>
> > 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 th
> >> >> >
> >> >> > an 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)
> >>
>
> --
> 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
More information about the users
mailing list