<html>
<head>
</head>
<body>
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
<pre wrap=""> Aren't you down to the point of counting instructions? :)</pre>
I though that this was a figure os speech. I found, however, that that is
exactly what I had to do -- count instructions. <br>
<br>
By stepping through the code using the simulator, I found that<br>
<br>
output_bit (SPI_PLA_DATA, pla_out_data.flags & 0x80);<br>
<br>
used five instructions, however, <br>
<br>
if (bit_test (pla_out_data.flags, 7))<br>
{<br>
output_bit (SPI_PLA_DATA, 1);<br>
}<br>
else<br>
{<br>
output_bit (SPI_PLA_DATA, 0);<br>
}<br>
<br>
only used three instructions. This became a saving of 64 instructions per
exchange. Additionally, I found that <br>
<br>
for (byte_num = 0; byte_num < 8; byte_num++)<br>
<br>
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).<br>
<br>
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.<br>
<br>
Joel Sherrill wrote:<br>
<blockquote type="cite" cite="mid:3CAA7310.C28048E6@OARcorp.com">
<pre wrap=""><br>Angelo Fraietta wrote:<br></pre>
<blockquote type="cite">
<pre wrap="">You are 100% right in what you have stated. I ran a MIDI input into<br>the device and found that at the top level of input, I was getting<br>overflows. I created this situation by sending continuous sysex<br>blocks of 1024 bytes into the device from my PC MIDI output. I had to<br>reduce the time in the PIC for the data exchange by using global<br>variables instead of returned function parameters and using the<br>#use_fast_io to remove any unnecessary changes to the data direction<br>register. Although these coding practices (such as using globals) are<br>normally frowned upon, this is what I had to do to reduce the overhead<br>in data transfers.<br></pre>
</blockquote>
<pre wrap=""><!----><br>On one hand, I am sorry you had to resort to that but on the other, I<br>recall that your CPU is not that fast so it was a necessary evil to<br>extract that last bit of performance. It sounds like the code you<br>tuned was HW specific anyway so it isn't that big a deal in the <br>grand scheme. You can still provide standard interfaces on top of<br>that. <br><br>This is great news.<br><br>--joel<br><br></pre>
<blockquote type="cite">
<pre wrap="">Joel Sherrill wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">Angelo Fraietta wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">I have to make a correction on those previous calculations. I did<br>not<br>read the settings on my CRO correctly. The actual values are 1<br>message<br>every 450 us, (not 4 us) and 1 every 500us. So I am actually at<br>the<br>extremes. The maximum transfer I could expect from a MIDI device<br>would<br>be one byte every 320 us (10 bits per byte). So not setting the<br>event<br>(as Chris Johns suggested) does save me a valuable 50us.<br><br></pre>
</blockquote>
<pre wrap="">Aren't you down to the point of counting instructions? :) 450 usecs<br>isn't<br>a lot of time/instructions. Having spend a good portion of my early<br>career<br>on smart serial controllers, I have some hard won advice. If you<br>actually<br>intend to sustain getting a byte every 320 usecs, then you have to<br>ensure<br>that your processing per-byte is less than that. A good first step<br>is<br>to write down the entire sequence of code executed for each byte.<br>Then<br>focus on which parts are unnecessary or not optimal for your case.<br>Eric<br>Norum did this for EPICS and the resulting work sped up mutexes and<br>counting<br>semaphores. I did a similar effort for the GNU Ada run-time "self"<br>routine and it showed a 5% improvement in system idle time for me<br>optimizing out about 60 instructions. You are at the point where<br>making sure the path you execute is minimal is important.<br><br></pre>
<blockquote type="cite">
<pre wrap="">Angelo Fraietta wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">After some exhaustive testing I have come up with some figures<br>that<br>represent data exchange rates between the Pic microcontroller and<br>the 386 using a PLA as an interface on an ISA bus using an<br>interrupt<br>driven I/O read/write paradigm.<br>What I have done is make the Pic and the 386 communicate with<br>each<br>other, each triggering an interrupt with the other, causing it to<br>write to the other device.<br>With the RTEMS event being triggered every interrupt I have a<br>constant exchange rate of 1 message each way every 5 us.<br>Triggering the event only if the receive queue is empty gives me<br>an<br>exchange rate of 1 Message every 4 us. I am saving 1 us by not<br>sending the unnecessary event.<br>The big factor in this test, however, is this method that I used<br>to<br>check the exchange rates completely blows the 1 message every<br>650<br>us measurement I previously made away, thus proving that the<br>interrupt rate will more th
an adeq<br>uately sustain an input Midi<br>stream running at maximum transfer rate (31.25kbs, which is about<br>3<br>bytes per ms)<br>Angelo Fraietta wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap=""> You are right. Sending the event if the queue was not<br> originally<br> empty when the ISR came is not necessary. I was already looping<br> the task until the queue was empty; I was, however, sending the<br> event regardless -- which is actually wasting CPU cycles.<br> Thanks<br> for the tip? I'll see what I can get the interval down to by<br> not<br> sending an unnecessary event.<br> Chris Johns wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">Angelo Fraietta wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap=""> Within the ISR I am doing the following:<br> Reading a 16 bit word from an I/O address<br> Decoding and adding that word onto a queue that is emptied<br> out<br> by a<br> running task<br> Checking a second queue for data that needs to be<br> transmitted<br> Transmitting a word to the I/O card.<br> Setting an event that causes the running task to empty the<br> queue.<br><br></pre>
</blockquote>
<pre wrap="">I would only send the event if the queue is empty and have<br>the<br>task loop<br>until the queue is empty.<br><br></pre>
</blockquote>
<pre wrap=""> --<br> Angelo Fraietta<br> PO Box 859<br> Hamilton NSW 2303<br> Home Page<br> <a class="moz-txt-link-freetext" href="http://www.users.bigpond.com/angelo_f/">http://www.users.bigpond.com/angelo_f/</a><br> There are those who seek knowledge for the sake of knowledge -<br> that is CURIOSITY<br> There are those who seek knowledge to be known by others - that<br> is VANITY<br> There are those who seek knowledge in order to serve - that is<br> LOVE<br> Bernard of Clairvaux (1090 - 1153)<br><br></pre>
</blockquote>
<pre wrap="">--<br>Angelo Fraietta<br>PO Box 859<br>Hamilton NSW 2303<br>Home Page<br><a class="moz-txt-link-freetext" href="http://www.users.bigpond.com/angelo_f/">http://www.users.bigpond.com/angelo_f/</a><br>There are those who seek knowledge for the sake of knowledge -<br>that is CURIOSITY<br>There are those who seek knowledge to be known by others - that<br>is VANITY<br>There are those who seek knowledge in order to serve - that is<br>LOVE<br> Bernard of Clairvaux (1090 - 1153)<br><br></pre>
</blockquote>
<pre wrap="">--<br>Angelo Fraietta<br>PO Box 859<br>Hamilton NSW 2303<br>Home Page<br><a class="moz-txt-link-freetext" href="http://www.users.bigpond.com/angelo_f/">http://www.users.bigpond.com/angelo_f/</a><br>There are those who seek knowledge for the sake of knowledge -<br>that is CURIOSITY<br>There are those who seek knowledge to be known by others - that is<br>VANITY<br>There are those who seek knowledge in order to serve - that is<br>LOVE<br> Bernard of Clairvaux (1090 - 1153)<br><br></pre>
</blockquote>
</blockquote>
<pre wrap="">--<br>Angelo Fraietta<br><br>PO Box 859<br>Hamilton NSW 2303<br><br>Home Page<br><br><a class="moz-txt-link-freetext" href="http://www.users.bigpond.com/angelo_f/">http://www.users.bigpond.com/angelo_f/</a><br><br>There are those who seek knowledge for the sake of knowledge - that is CURIOSITY<br>There are those who seek knowledge to be known by others - that is VANITY<br>There are those who seek knowledge in order to serve - that is LOVE<br> Bernard of Clairvaux (1090 - 1153)<br></pre>
</blockquote>
<pre wrap=""><!----><br></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">--
Angelo Fraietta
PO Box 859
Hamilton NSW 2303
Home Page
<a class="moz-txt-link-freetext" href="http://www.users.bigpond.com/angelo_f/">http://www.users.bigpond.com/angelo_f/</a>
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)</pre>
<br>
<br>
</body>
</html>