[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: serial port forever



You might want to take a look in the elinux version
(elinux/drivers/char/etrax100ser.c)
where we set the d_wait bit in the DMA descriptor when setting up the
transmit
so that the interrupt comes after the FIFO is empty - we then only have to
worry
about the last byte that is still in the shift register on it's way out:
/* set up the descriptor correctly for output */
        descr->ctrl = d_int | d_eol | d_wait;
(this might already be implemented in the version you got)

To handle the last byte in the shift register in elinux, we timestamp the
interrupts using
the last_tx_active and last_tx_active_usec fields and make sure we wait
enough
time before closing the port.

Currently, the driver does not support disabling of DMA on the serial ports
and use char-by-char interrupts instead, although it's possible to implement
that.

An easier way to fix the closing might be to simply comment out the row
info->port[REG_TR_CTRL] = (info->tx_ctrl &= ~0x40);
in shutdown() in os/linux/arch/cris/drivers/serial.c
so we don't really disable the port even though we are closing it.
(Don't know if this will have some nasty side effects though)

/Johan

----- Original Message -----
From: Szabo, Tamas <Tamas.Szabo@xxxxxxx.com>
To: 'johan.adolfsson@xxxxxxx.com>
Cc: <dev-etrax@xxxxxxx.com>
Sent: Saturday, October 06, 2001 11:32 AM
Subject: RE2: serial port forever


> Ok, I checked and if I wait it works. But waiting is depends on length of
> string. So, how can I decide that DMA finished to flush fifo or not? Or is
> it possible to disable DMA on ser0 and ser2?
>
> > -----Original Message-----
> > From: johan.adolfsson@xxxxxxx.com]
> > Sent: Friday, October 05, 2001 22:59
> > To: Szabo, Tamas; dev-etrax@xxxxxxx.com
> > Subject: Re: serial port forever
> >
> > The only reason for this behavior I can think of is that
> > we don't wait until all data is sent before we close the port.
> > This should be fixed a while ago in the serial driver for
> > devboard (with Linux 2.0 a.k. elinux) but it might not be fixed
> > in the latest devboard_lx (with Linux 2.4) where the driver isn't yet
> > updated to the improvements made in elinux (work in progress)
> >
> > (Before closing the port we must wait for the DMA to finish,
> >  the fifo to be flushed and then wait one "char time" so that the
> >  last byte being shifted out really leaves the pin before we close
> >  the port)
> >
> > /Johan
> >
> > ----- Original Message -----
> > From: Szabo, Tamas <Tamas.Szabo@xxxxxxx.com>
> > To: <dev-etrax@xxxxxxx.com>
> > Sent: Friday, October 05, 2001 4:23 PM
> > Subject: serial port forever
> >
> >
> > > Hello,
> > >
> > > It seems that I can understand linux or there is a serious problem
with
> > > serial port (I hope the first). I wrote a few mail about my problem to
> > the
> > > list but no answer recieved. I would like to use ser0 and ser2. I try
to
> > > describe my method which is _very_ simple and it works between 2 PC:
> > >
> > > - On PC I start sermon or minicom
> > > - On devboard type: echo -n "blablabla" > /dev/ttyS0
> > >
> > > Unfortunately this is not work. The problem appears after a few
> > characters
> > > (the number of characters depend on baudrate at 9600bps ~3-4 chars).
> > Usually
> > > the last byte(s) does not transmitted. This means somehow the last
> > > characters are cutted (even in middle of byte).
> > >
> > > I use:
> > > cris-dist 1.14
> > > devboard_lx 2.0.0
> > > linux 2.4.5
> > >
> > > I checked the mail list, but I did not find anybody who report this
> > problem,
> > > so I think if this problem only appears for me, this is my mistake.
But
> > I
> > > did not modified the sources or anyting else in packages above, and
> > compile
> > > without errors, then I download image to flash.
> > > And the result is not good. If I can not solve this probem, I can not
> > > develeop the my application.
> > >
> > > Can somebody help me? Peaseeeee!
> > >
> > > Sza2
> > >
> > >
> > >
> > > **********************************************************************
> > > This email and any files transmitted with it are confidential and
> > > intended solely for the use of the individual or entity to whom they
> > > are addressed.
> > > Sony cannot accept liability for statements made which are clearly
> > > the sender's own and not made on behalf of Sony.
> > > (01)
> > > **********************************************************************
> > >
>