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


> I had in mind that if it fixed the problem, then the ISR could be
> made to store the received byte somewhere until the DSR was called
> to process it, rather than waiting for the DSR to lift it out of the
> data register. As it happens the latency is still too much so this
> isn't the answer.

Yep, you could add our own buffering in the ISR and then call the DSR
periodically. However, it makes much more sense to use the hardware
receive buffer. It will considerably lower your CPU usage.
 
> Just to re-iterate a previous question, is there any mechanism for
> reporting errors from a DSR? 

Not errors. You can indicate flow control conditions with the callback
serial_indicate_status(). I've never used it, don't know how it works,
so i would suggest seeing if there is a driver which makes use of
this.

> Also is it considered to be a good or bad practise to have asserts
> in a DSR to catch unreported errors?

Asserts in general in DSR are O.K. Asserts are always fatal, so it
does not matter if calling an assert destroys the stack, corrupts
threads etc. You are dead, so shooting yourself in the foot as you die
makes little difference.

However, is an assert the correct thing to do? Is the error fatal?
Dropping a few characters is not fatal. It happens. The protocol
layers running above have to expect this and deal with it. So i would
not assert on an overrun error, a parity error, etc.

    Andrew

-- 
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]