This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Serial buffer overrun
On Wed, Jan 15, 2003 at 08:23:49PM -0800, Shannon Holland wrote:
> I also notice that the low level ISR immediately schedules a DSR - how
> long is the delay from the exit from the ISR until the DSR routine is
> called?
That depends on what other DSRs are running or how long an
application or driver has DSRs locked out.
> I also noticed that in the DSR it pulls in a single byte and then calls
> out to the channel callback, then gets the next byte, etc. Just for
> grins I modified this code to pull in a number of bytes at a time before
> calling the channel callback. I'm not sure this will buy me anything
> (doesn't change behavior) - I need to read up on the uart docs!
I gave up on the single-character callback scheme years ago and
made my DSR cognisant of the cbuf structure so that data bytes
are transferred directly to/from the circular buffers. I found
that using the single-character callbacks I had no chance
whatsoever to keep up with multiple serial ports at high baud
rates.
> I also have another question as to how the debugger printf's interact
> with program flow: I notice I drop a whole ton of bytes if I call printf
> (anywhere from 20-60 bytes!). Are interrupts disabled when using the
> monitor printf?
Don't know. The diag_printf with which I'm familiar busy-waits
on the UART to which it's writing. If you call it with
interrupts disabled, then interrupts stay disabled the whole
time. If not, they stay enabled the whole time.
--
Grant Edwards
grante@visi.com
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss