UART in RTEMS

[João Rasta]

apbuartN is not recognized, only console_N. Either to include your driver or
to use CONSOLE_USE_INTERRUPTS=1 i have to recompile rtems. I'll give it a
try.

I have seen in your driver that rtems_termios_bufsize() can be used to
change the driver buffer size. Can i use it to change the RX and TX size of
the console_N driver?


Best,
JM

On Thu, Aug 12, 2010 at 2:58 PM, Joris van Rantwijk <jorisvr at sron.nl> wrote:

> On Thursday 12 August 2010 13:14:13 João Rasta wrote:
> > No, i have a very low baudrate, 2400. The device is /dev/console_b, as
> > instructed in
> >
> >
> http://www.gaisler.com/cms/index.php?option=com_content&task=view&id=82&Itemid=61
>
> I guess then you got your RTEMS distribution from the Gaisler site,
> not from rtems.org. The Gaisler version of RTEMS has specific
> modifications
> in the UART driver which are not yet on rtems.org.
>
> For example, the /dev/console driver from gaisler.com supports
> tcsetattr(),
> the version from rtems.org does not.
>
> > After doing some tests i'm now sure that the packets are lost on the
> > processor side. The processor is not fast enough to process the
> application
> > and read the incoming packets in time, hence resulting in synchronization
> > problems. The receiving sequence is lost because some packets are not
> > "grabbed". I wonder if this can be improved by increasing the UART HW
> > fifo..?
>
> Increasing the HW fifo should improve at least a little bit.
> Using interrupt-based receiving should help even more. The console
> driver is probably working in polling mode now.
>
> You could try switching the console driver to interrupt mode
> (recompile RTEMS with environment variable CONSOLE_USE_INTERRUPTS=1).
> Or use /dev/apbuartN instead of /dev/console_X.
> Or try our leonuart driver and /dev/leonuartN instead of /dev/console_X.
>
> Joris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100812/3dd56e96/attachment-0001.html>