UART in RTEMS
freakforever at gmail.com
Thu Aug 12 15:25:14 UTC 2010
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
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?
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
> I guess then you got your RTEMS distribution from the Gaisler site,
> not from rtems.org. The Gaisler version of RTEMS has specific
> in the UART driver which are not yet on rtems.org.
> For example, the /dev/console driver from gaisler.com supports
> 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users