How do I use rtems_termios_bufsize?! No doc!

[João Rasta]

Hi all,

Well i have been able to reproduce the problem. Instead of the previous host
(dSPACE), i used a PC as a host and implemented a simple application to
perform both reads and writes via the serial link to the FPGA board running
rtems. The rtems software simply performs writes() to the serial line at a
fixed rate. I saw that:

1) If the rtems running on the FPGA board only sends data to the host, it's
OK.

2) Instead of only reading, if the host also writes, even if there are no
read()'s at the rtems side which only keeps write()'ing, i start to loose
bytes received at the host side.

Since there are two independent Rx and Tx lines, i did not expect this to
occur. Also, there are two separated hardware fifos for both Tx and Rx and
since i have no read()'s on the rtems side i expect no software calls when
bytes arrive, hence no software overheads.

What am i missing?


Best,
JM


On Fri, Sep 24, 2010 at 4:41 PM, João Rasta <freakforever at gmail.com> wrote:

> In order to discard hardware issues I now tried the same application on a
> more powerful FPGA. Here the leon-3 processor runs at 80MHz and UART
> hardware fifos size are doubled to 32 bytes. However the problem is still
> the same. Rx works well, the packets received are ok but the packets sent
> are not correct.
>
> I suspect of a problem on the driver. If i set a big buffer, 1024 as chris
> suggested, "trash" bytes are sent. This does not happen if i set a buffer
> lower than the message i want to send but in this case i loose bytes.
>
> Termios is well configured, the simplest way possible. I'm using POSIX
> rtems support.
>
> Can that warning on the driver be the problem? Transmissions in interrupt
> mode not working well? Is there any other driver i can use?
>
>
> Best,
> JM
>
>
>
>
> On Fri, Sep 24, 2010 at 3:25 PM, João Rasta <freakforever at gmail.com>wrote:
>
>> Sorry, it is this one:
>>
>> rtems-4.10-mingw\src\rtems-4.10\c\src\lib\libbsp\sparc\leon3\console
>>
>>
>>
>>
>> On Fri, Sep 24, 2010 at 3:15 PM, Sebastian Huber <
>> sebastian.huber at embedded-brains.de> wrote:
>>
>>> On 09/24/2010 04:04 PM, João Rasta wrote:
>>> > The filename is console.c. I'm using rtems 4.10 from
>>> >
>>> > ftp://gaisler.com/gaisler.com/rcc/src/
>>>
>>> There are 48 console.c files in this archive.
>>>
>>> >
>>> >
>>> > Best,
>>> > JM
>>> >
>>> > On Fri, Sep 24, 2010 at 1:13 PM, Sebastian Huber
>>> > <sebastian.huber at embedded-brains.de
>>> > <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>> >
>>> >     On 09/24/2010 02:01 PM, João Rasta wrote:
>>> >     > Hi,
>>> >     >
>>> >     > I have checked the termios configuration again, it seems ok. No
>>> >     software
>>> >     > flow control, no canonical mode. Also the same configuration
>>> works
>>> >     fine
>>> >     > on a x86.
>>> >     >
>>> >     > I'm using gaisler's console driver and when i opened the rtems
>>> driver
>>> >     > file it said this:
>>> >     [...]
>>> >
>>> >     What is the file name path of this file and the CVS version in your
>>> >     case?
>>> >
>>> >     --
>>> >     Sebastian Huber, embedded brains GmbH
>>> >
>>> >     Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>>> >     Phone   : +49 89 18 90 80 79-6
>>> >     Fax     : +49 89 18 90 80 79-9
>>> >     E-Mail  : sebastian.huber at embedded-brains.de
>>> >     <mailto:sebastian.huber at embedded-brains.de>
>>> >     PGP     : Public key available on request.
>>> >
>>> >     Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des
>>> EHUG.
>>> >     _______________________________________________
>>> >     rtems-users mailing list
>>> >     rtems-users at rtems.org <mailto:rtems-users at rtems.org>
>>> >     http://www.rtems.org/mailman/listinfo/rtems-users
>>> >
>>> >
>>>
>>>
>>> --
>>> Sebastian Huber, embedded brains GmbH
>>>
>>> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>>> Phone   : +49 89 18 90 80 79-6
>>> Fax     : +49 89 18 90 80 79-9
>>> E-Mail  : sebastian.huber at embedded-brains.de
>>> PGP     : Public key available on request.
>>>
>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100927/075c251b/attachment-0001.html>