Interrupts occurrence

[Angelo Fraietta]

I don't ever intend on sustaining that rate of input for more than eight 
character bursts.

Last night I did some of the optimizations already within the PIC, 
removing all the unnecessary 1us delays in the device driver used to 
alleviate the original problems -- shifting errors in the PLA -- which 
were now unnecessary as I had developed an error detection algorithm 
that looks at a single byte. By removing these delays, I was able to 
reduce the time to 370us. Additionally, this also reduced the number of 
errors from 5-15 errors per 65K data transfers down to 1 error per 500K 
errors.

Thanks a lot for your advice and I will keep it in mind as I develop the 
project further.

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 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)
>>
>

-- 
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/20020327/2d144e3e/attachment-0001.html>