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]

Re: MPC555 serial receive drops bytes


>This sounds like your ISR code can take more than one 
>character time to 
>execute. Assuming 8-N-1 data format, a 57600 baudrate works 
>out to 173.6 
>microseconds per character. You don't say what speed your CPU is 
>running, but I suspect 173.6 uS works out to a *lot* of CPU 
>instructions. 

The board is 40MHz which for 173.6 uS corresponds to 6944 instructions
assuming one instruction per clock cycle.
The board is really quite modest when running just the serial_echo test,
the only thing (that I can think of) that's running periodically in at
the ISR/DSR level is the wallclock and serial Rx and Tx ISRs and DSRs.

Thinking about this though, the Tx DSR does sit and try to clear the
send buffer into the hardware register which would make it take longer
than the Rx DSR. It usually only manages to transfer one or two bytes at
a time before giving up and waiting for the next ready to send
interrupt.
If the Tx DSR was blocking the Rx DSR from running in time then I guess
this would show up worst in an serial echo situation which is what I'm
seeing.
I think this warrants further investigation.

>You should not need to sit in the ISR waiting 
>for the line 
>to go idle.

I was thinking to do this in the DSR and not the ISR, but I think the
ISR circular buffer is better.

>I had the same problem with the Coldfire serial driver. The original 
>driver simply masked out the interrupt and called the DSR. That worked 
>great until you got some other DSR taking more than one character time 
>to execute. The serial DSRs got posted, but they didn't run in 
>time. The 
>solution for my driver was to move the data in/out of the UART to a 
>circular buffer in the ISR.
>
>I suspect this issue may occur on other platforms as well.
>
>Alex.

I've had a quick look at coldfire mcf5272_serial.c in cvs which still
does as you say the original driver does.
Does this mean then that this is a potential problem will all of the
serial drivers, particularly the ones which have only a single character
buffer?

I notice also that in the same file there is:

#ifdef CYGOPT_IO_SERIAL_SUPPORT_LINE_STATUS
 // Overrun error
 if (usr_ucsr & MCF5272_UART_USR_OE)
 {
   stat.which = CYGNUM_SERIAL_STATUS_OVERRUNERR;
   (chan->callbacks->indicate_status)(chan, &stat);
 }
#endif

And in packages/io/serial/include/serialio.h
#ifdef CYGOPT_IO_SERIAL_SUPPORT_LINE_STATUS

# define CYGNUM_SERIAL_STATUS_FLOW          0
# define CYGNUM_SERIAL_STATUS_BREAK         1
# define CYGNUM_SERIAL_STATUS_FRAMEERR      2
# define CYGNUM_SERIAL_STATUS_PARITYERR     3
# define CYGNUM_SERIAL_STATUS_OVERRUNERR    4
# define CYGNUM_SERIAL_STATUS_CARRIERDETECT 5
# define CYGNUM_SERIAL_STATUS_RINGINDICATOR 6


This is the error reporting mechanism I was after.

In io_serial.cdl there is the cdl option
CYGOPT_IO_SERIAL_SUPPORT_LINE_STATUS :

requires      { CYGINT_IO_SERIAL_LINE_STATUS_HW > 0 }
"This option indicates that if the serial driver supports it,
 serial line status and modem status information should be
 propagated to higher layers via callbacks."

And in mcf5272_serial.cdl:

implements    CYGINT_IO_SERIAL_LINE_STATUS_HW

So I know how to do this from the driver side, but does anybody know how
this gets reported to "higher layers" and if it currently works?
I can't find any API documentation for this. Ideally I would like the
cyg_io_read() to return with a spcific error code or at least something
that tells me I need to do a cyg_io_get_config() to find out what
happened at the app level.

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]