This is the mail archive of the ecos-discuss@sources.redhat.com 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] |
Nick Garnett wrote:
One other thought is if you are doing any diagnostic I/O using e.g. diag_printf, especially if it's to GDB, then interrupts are disabled for that time, which can reduce interrupt latency. diag output isn't intended for "real" applications :-).
None of the system alarm functions do anything significant, mostly
they just wake a thread up somehow. So they should not be absorbing
enormous amounts of time.
Of course DSRs also get delayed by thread-level code when it claims
the scheduler lock, so maybe a combination of several factors is
causing problems.
It should be alright if the buffer is large enough so that you can be conservative with how much you want to be able to put in at once.I was thinking about before getting any data, using data_rcv_req() to get a peace of the buffer and writing in the ISR direct in this buffer. In the DSR I call then data_rcv_done() and get with data_rcv_req() a new peace of the buffer.
That's worth trying, but they only really work if you know how much data is coming, or can detect when there is no more to come. I'm not sure how well they would work for a normal serial device.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |