This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

MPC555 serial driver delay


I've noticed a significant execution delay in my application caused by
sending out data on the serial port.

I modified twothreads.c to have one thread for a control loop and
another to report status info over the serial line.
There are no dependencies between these threads. Once I set the control
thread to a higher priority than the serial thread this worked happily.

I thought I would give the termios compatablility layer a go as I've
already got some code that uses this, but found that I needed hardware
serial drivers enabled to get /dev/ser0 etc. This is where the problem
began. I was sending out about 30 characters about twice every second
and my control loop was running at about 100Hz using
cyg_thread_delay(1). It seems that sending out over the serial port was
blocking the execution of all threads and not just the one attempting to
write out.

I then set the buffer size in cdl,
CYGNUM_IO_SERIAL_POWERPC_TARGET_A_BUFSIZE to zero so that serial
interrupts would not be used. The problem went away when I did this.

After stepping though the code with interrupts enabled it seems that
there is a single byte hardware buffer that generates a transmit
interrupt when it is empty. When cyg_io_write() is called the ISR/DSR
are setup and the TX interrupt is enabled. The DSR is called straight
away as the buffer is already empty.

The problem is that the DSR mpc555_serial_tx_DSR() in turn calls the
generic serial_xmt_char() in serial.c which then calls
mpc555_serial_putc() for each byte in the software buffer to copy it
into the single byte hardware buffer each time testing to see if the
buffer is empty. The execution of application threads seems to be
blocked all the while until the whole buffer is written out because it
is taking place in a DSR context of the back of a single interrupt.

Surely the correct behaviour is to write out one byte per TX interrupt
syncronously to the harware buffer allowing application code to run in
between?

Can anybody tell me if I have miss understood something before I start
to modify driver code?

Steven

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]