Interrupts occurrence
Angelo Fraietta
angelo_f at bigpond.com
Thu Apr 4 01:12:54 UTC 2002
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.
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.
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20020404/a31f0b6a/attachment.html>
More information about the users
mailing list