Alan,<br><br>Sorry for wasting your time, after having a quick scan of the BSP source, I simply drew the conclution that interrupt was enabled, without catching that the "#define CONSOLE_USE_INTERRUPTS 1" was commented out! Anyway, thanks for porting BF537 to RTEMS! <br>
<br>MOLM<br><br><div class="gmail_quote">2008/12/1 Allan Hessenflow <span dir="ltr"><<a href="mailto:allanh-rtems2@kallisti.com">allanh-rtems2@kallisti.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ed Sutter wrote:<br>
> Joel Sherrill wrote:<br>
> > MOLM wrote:<br>
> >> I have an application running on a BF537 stamp card, using posix code<br>
> >> that is working using uClinux on the same card. What I experience now<br>
> >> is loss of characters, even at 300baud, so I do not think the problem<br>
> >> is primary interrupthandler related. I have ended up with a test<br>
> >> scenario connecting the Tx line to the Rx line of the uart, writing a<br>
> >> string of characters, and then reading one by one characters back.<br>
> >> When the string written contains more than 3 characters I am only able<br>
> >> to read back the last three characters. I have scanned through the<br>
> >> termios implementation, buf it seems to me that the default buffersize<br>
> >> is not modified by the BSP implemetation. Below is the code I used for<br>
> >> the test and the output. Anyone experienced something like this?<br>
> ><br>
> > Random thoughts without reading the hardware manual.<br>
> ><br>
> > Since you have tied the TX to the RX, is there any chance that the<br>
> > RX has a 3 byte FIFO and the TX has a deeper one?  If this is the<br>
> > case, then you would keep putting characters into the TX and<br>
> > simultaneously overflowing the RX.<br>
> ><br>
> > Another possibility is that the serial port is polled by default.<br>
<br>
> If I recall correctly, the BF537's UART doesn't have a FIFO, so for<br>
> anything real you have to turn on the DMA engine hooked to the UART.<br>
> Then, the DMA buffer is essentially the equivalent of the FIFO.<br>
> Is there any chance that the RTEMS port of the BF537 isn't using<br>
> DMA?<br>
<br>
The Blackfin UART driver in RTEMS does not use DMA.  However there's no<br>
reason at this point to believe MOLM's application will require it.  I<br>
just duplicated MOLM's test result with the UART driver in polled mode<br>
(which is the default).  If I build it interrupt-driven (with the<br>
configure option CONSOLE_USE_INTERRUPTS=1) then that test passes.  I tried<br>
making the string somewhat longer with no problems, and I expect it to be<br>
fine up to the termios buffer size.<br>
<br>
Incidentally, when in polled mode, only receiving the last three bytes<br>
sent is explained by a combination of the tx and rx buffering, not rx<br>
alone which only has a single byte holding register.  The other two bytes<br>
are the one being transmitted/reassembled at the time read is called and<br>
the one still in the transmit holding register.<br>
<br>
allan<br>
<font color="#888888"><br>
--<br>
Allan N. Hessenflow      <a href="mailto:allanh@kallisti.com">allanh@kallisti.com</a><br>
_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a><br>
<a href="http://rtems.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://rtems.rtems.org/mailman/listinfo/rtems-users</a><br>
</font></blockquote></div><br>