rtems-users Digest, Vol 27, Issue 2
allanh-rtems2 at kallisti.com
Mon Dec 1 18:14:38 UTC 2008
Ed Sutter wrote:
> Joel Sherrill wrote:
> > MOLM wrote:
> >> I have an application running on a BF537 stamp card, using posix code
> >> that is working using uClinux on the same card. What I experience now
> >> is loss of characters, even at 300baud, so I do not think the problem
> >> is primary interrupthandler related. I have ended up with a test
> >> scenario connecting the Tx line to the Rx line of the uart, writing a
> >> string of characters, and then reading one by one characters back.
> >> When the string written contains more than 3 characters I am only able
> >> to read back the last three characters. I have scanned through the
> >> termios implementation, buf it seems to me that the default buffersize
> >> is not modified by the BSP implemetation. Below is the code I used for
> >> the test and the output. Anyone experienced something like this?
> > Random thoughts without reading the hardware manual.
> > Since you have tied the TX to the RX, is there any chance that the
> > RX has a 3 byte FIFO and the TX has a deeper one? If this is the
> > case, then you would keep putting characters into the TX and
> > simultaneously overflowing the RX.
> > Another possibility is that the serial port is polled by default.
> If I recall correctly, the BF537's UART doesn't have a FIFO, so for
> anything real you have to turn on the DMA engine hooked to the UART.
> Then, the DMA buffer is essentially the equivalent of the FIFO.
> Is there any chance that the RTEMS port of the BF537 isn't using
The Blackfin UART driver in RTEMS does not use DMA. However there's no
reason at this point to believe MOLM's application will require it. I
just duplicated MOLM's test result with the UART driver in polled mode
(which is the default). If I build it interrupt-driven (with the
configure option CONSOLE_USE_INTERRUPTS=1) then that test passes. I tried
making the string somewhat longer with no problems, and I expect it to be
fine up to the termios buffer size.
Incidentally, when in polled mode, only receiving the last three bytes
sent is explained by a combination of the tx and rx buffering, not rx
alone which only has a single byte holding register. The other two bytes
are the one being transmitted/reassembled at the time read is called and
the one still in the transmit holding register.
Allan N. Hessenflow allanh at kallisti.com
More information about the users