<html>
<head>
</head>
<body>
I think the essence of the problem lies in the fact that failing UART is
not a 16550 while the one in the BSP is. It is not that big a drama for me
because the problem only occurs on the machine I am using as a simulator
and not my embedded target (it is a very old 386dx). <br>
<br>
If I really wanted to, however, I could run a pseudo watchdog on the task
when it starts the transmit, and if it does not return, the watchdog task
could flush the buffer. Alternatively, there could be some sort of mechanism
in the driver that acertains how long it has been waiting for the UART interrupt
that notifies it that the Tx buffer is empty. This, however, would probably
mean more overhead for something that would not normally occur.<br>
<br>
Alternatively, there could be a different device driver for the PC386 BSP
that could be defined in the rtems_driver_address_table Device_drivers[]
 as a MACRO<br>
<br>
I personally don't think is is worth worrying about too much and I am happy
to live with it.<br>
<br>
<br>
Joel Sherrill wrote:<br>
<blockquote type="cite" cite="mid:3D53B86E.3745EA62@OARcorp.com">
  <pre wrap=""><br>Angelo Fraietta wrote:<br></pre>
  <blockquote type="cite">
    <pre wrap="">I have found the problem.<br>The PC that I am using is a very old PC, which I think is not using a<br>16550 UART and probably not full duplex. Everything worked fine at<br>most times, however, if data was received at the same time, the Tx<br>seemed to get lost, and so the transmit function never returned.<br></pre>
    </blockquote>
    <pre wrap=""><!----><br>Is there a real way to fix this without kludging something or is this<br>an ugly thing that must just be lived with. :(<br><br></pre>
    <blockquote type="cite">
      <pre wrap="">I overcame this by setting the retry time-out in the application that<br>communicates with my RTEMS device to a slower speed. This overcame the<br>problem.<br><br>I want to say, however, the problem did not occur on my embedded<br>device (DIMMPC) because I think the UART is full duplex.<br><br>Andrew N. Maximov wrote:<br><br></pre>
      <blockquote type="cite">
        <pre wrap="">Hello Angelo,<br>Thursday, August 08, 2002, 2:23:30 AM, you wrote:<br>AF> Did you ever find the problem to this? I am having a similar<br>problem now<br>AF> on the pc386<br><br></pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">There is some problems with termios. System hangs after I try<br>to output to console more than 64 characters. My configuration:<br>HARDWARE: MC68MH360<br>RTEMS: RTEMS-4.5.0<br>BSP: m68k<br><br></pre>
            </blockquote>
            </blockquote>
            <pre wrap="">My test is not correct. It calls printf function from timer's<br>service<br>routine. It is wrong. Because timer's routine is called from<br>interrupt<br>handler. If you need to output some debug info from isr, you must<br>use<br>printk. I have no problems with RTEMS-4.5.0 on MC68MH360, now. Our<br>system based on RTEMS works about four months uninterruptedly. But<br>we<br>use RTEMS on pc386 for test's purpose only.<br><br></pre>
            </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>
            </body>
            </html>