170.htm

pcb设计资料初学者难得的入门资料包含工厂制作过程

and the execution of the interrupt handler is called the "interrupt <br>
latency". The time that passes between the interrupt and the <br>
continuation of the execution of the blocked process is called the <br>
"interrupt dispatch latency". We are assuming that the blocked process <br>
is the process with the highest priority (the POSIX.1b scheduler <br>
system calls allow to ensure this). Many real-time applications <br>
require that the interrupt dispatch latency is as short as possible, <br>
some applications require even guarantees for the maximum interrupt <br>
dispatch latency (e.g. 20 microseconds). <br>

At the moment, Linux has basically two types of interrupt handlers: <br>
"fast" and "slow" ones. <br>
The "slow interrupt handlers" call the scheduler each time immediately <br>
after the interrupt has been handled. This guarantees that if the <br>
process has become runnable by handling the interrupt and has the <br>
highest priority, then it will directly get control over the CPU after <br>
the interrupt handler. This ensures a short interrupt dispatch <br>
latency, but the cost is that the scheduler is executed for each <br>
interrupt, which can cause a system performance degradation for <br>
devices with a high interrupt rate (e.g., network controllers). The <br>
slow interrupt handler do not disable other interrupts while they are <br>
being executed. This ensures a low interrupt latency, because other <br>
higher priority interrupts will not be blocked. The "slow" interrupt <br>
handler behavior is what you want for real-time applications. <br>
The "fast interrupt handlers" only mark in a bitmask that an interrupt <br>
has been handled for this device. The scheduler is NOT called after <br>
the fast interrupt handler and the process waiting on the interrupt <br>
may have to wait up to 1 s / HZ = 10 ms for the next timer interrupt <br>
which will call the scheduler again (because the timer interrupt is <br>
handled the "slow" way). "Fast" interrupt handlers are those which are <br>
installed by the driver by specifying the SA_INTERRUPT option when <br>
calling request_irq(). "Fast" interrupt handlers are the reason why <br>

for devices like the serial port, the interrupt dispatch latency can <br>
easily reach 10 ms and more. "Fast" interrupt handlers disable other <br>
interrupts while the handler is being executed. This increases <br>
interrupt latency. The Linux "fast" interrupt handlers cause very low <br>
interrupt handling overhead, but they can be the cause for a lot of <br>
headaches for real-time application developers. <br>
See linux/arch/i386/kernel/irq.c, linux/include/asm-i386/irq.h and <br>
linux/arch/i386/kernel/entry.S for implementation details of how fast <br>
and slow interrupts are handled in Linux. <br>
Examples for "slow" Linux 1.3 interrupt drivers with good interrupt <br>
dispatch latency are <br>
keyboard <br>
floppy disk <br>
timer <br>
sound cards <br>
mouse drivers <br>
some Ethernet cards <br>
Examples for "fast" interrupt drivers with bad interrupt dispatch <br>
latency are <br>
serial port <br>
some Ethernet cards <br>
most harddisk/SCSI drivers <br>

most CD-ROM drivers <br>
Especially for the serial port, it would be very nice to have a way to <br>
switch to low dispatch latency interrupt handling, such that an <br>
application can react as fast as possible on any incoming serial byte. <br>
Apart from the "fast" interrupt handler type, another important cause <br>
of latency in the serial port are the 16550 FIFO UARTs. At the moment, <br>
the UARTs are configured to trigger an interrupt (except for for bit <br>
rates < 2400 bit/s) only if the FIFO is filled with at least eight <br>
bytes or if an UART timeout has occured (this happens after four <br>
character transmission times). The 16550 chip can be configured to <br>
trigger limits 1, 4, 8, and 14, but Linux currently provides no <br>
ioctl() for this. For details about the FIFO UART, please consult the <br>
National Semiconductor PC16550D data sheet. <br>
For real-time applications, it would be very desirable to change the <br>
FIFO trigger limit to one byte so that incoming serial bytes are <br>
immediately delivered to the waiting process. Applications that depend <br>
heavily on minimum serial port interrupt dispatch latency are for <br>
example MIDI music systems, DCF77 reference time long-wave radio signal <br>
receivers in Europe, packet radio network interfaces, and ISO 7816 <br>
smartcard interfaces. <br>
Some existing work in this area: <br>
Stuart Cheshire <[e-mail]> has implemented a "smart" <br>

interrupt handler that can switch between the classic "fast" and <br>
"slow" alternatives (see <URL:http://mosquitonet.stanford.edu/ <br>
smartirq.html> for details). This way, you can get the real-time <br>
advantage of "slow" handling for the serial port without introducing a <br>
permanent system overhead even when no real-time application is <br>
active. <br>
Nick Simicich <[e-mail]> and Rik Faith <[e-mail]> <br>
have written a program called "cytune" which can change the FIFO <br>
thresholds for individual ports in the Cyclades async mux driver. <br>
Problem 2: Timer resolution <br>
On most Linux architectures, a timer interrupt occurs every 10 ms (HZ <br>
= 100). One exception is the Alpha architecture, where the timer <br>
interrupt comes every 1 ms (HZ = 1024). The macro HZ, which specifies <br>
the timer frequency, is defined in <asm/param.h>. At the moment, the <br>
kernel timer mechanism, on which the itimer and nanosleep <br>
implementation is based, checks after each timer interrupt whether a <br>
software timer has expired, makes the corresponding process runnable <br>
again, and calls the scheduler. This means that a highest priority <br>
real-time process can have to wait up to 2 * (1 s / HZ) = 20 ms longer <br>
than requested. <br>
An excellent solution would be to implement an interrupt-on-demand <br>
timer facility. The 8253 timer/counter chip in the PC would then have <br>

to be programmed such that it delivers an interrupt with microsecond <br>
precision exactly at the time when a software timer expires. This <br>
would increase the software timer precision by a factor of 10 000! As <br>
the 8253 timer would be programmed in a single shot mode, a lost <br>
interrupt might cause an accidental system halt. If this is problem, <br>
the CMOS battery clock, which can also be used to implement periodic <br>
interrupts, should be utilized to trigger periodic calls to the <br>
scheduler in order to ensure process preemption and kernel clock <br>
update. The time stamp counter (TSC) available in all Pentium <br>
processors is a 64-bit counter clocked at CPU frequency. It can be <br>
used on Pentium systems in order to get extremely precise timing <br>
information with theoretically close to nanosecond resolution and <br>
without overflow problems. <br>
Literature <br>
---------- <br>
For those of you who have become interested in POSIX.1b, there exists <br>
a good book: <br>
Bill O. Gallmeister, POSIX.4 -- Programming for the Real World, <br>
O'Reilly & Associates, 1995, ISBN 1-56592-074-0. <br>
This book is not only a good introduction into POSIX.1b (which was <br>
originally called POSIX.4), it is also an easy reading nice way into <br>
the world of real-time operating systems for those developers who have <br>

so far been very UNIX and time-sharing oriented. <br>
You can order the POSIX.1b standard (officially called IEEE Std <br>
1003.1b-1993; this book includes also all text of POSIX.1 and costs <br>
114 USD) as well as the other POSIX standards directly from IEEE: <br>
phone: [phone] (TZ: eastern standard time) <br>
1 800 678 4333 (from US+Canada only) <br>
fax: [phone] <br>
e-mail: [e-mail] <br>
Information about POSIX and other IEEE standards is also available on <br>
<URL:http://stdsbbs.ieee.org/> and <URL:http://www.knosof.co.uk/ <br>
posix.html>, however unfortunately the full standard documents are <br>
only available as books or on CD-ROM, not on the Internet. Having <br>
access to the POSIX specs is certainly a good idea for any Linux <br>
kernel hacker. <br>
Here is a brief list of some of the POSIX standards: <br>
POSIX.1 Basic OS interface (C language) <br>
POSIX.1a Misc. extensions (symlinks, etc.) <br>
POSIX.1b Real-time and I/O extensions (was: POSIX.4) <br>
POSIX.1c Threads (was: POSIX.4a) <br>
POSIX.1d More real-time extensions (was: POSIX.4b) <br>
POSIX.1e Security extensions, ACLs (was: POSIX.6) <br>
POSIX.1f Transparent network file access (was: POSIX.8) <br>

POSIX.1g Protocol independent communication, sockets (was: POSIX.12) <br>
POSIX.1i Technical corrections to POSIX.1b <br>
POSIX.2 Shell and common utility programs (date, ln, ...) <br>
POSIX.3 Test methods <br>
POSIX.5 ADA binding to POSIX.1 <br>
POSIX.7 System administration <br>
POSIX.9 FORTRAN-77 binding to POSIX.1 <br>
POSIX.15 Supercomputing extensions (checkpoint/recovery, etc.) <br>
and a few others which are still in early draft stage. If you want to <br>
follow progress on POSIX standardization, you should read the <br>
announcements in the moderated USENET group comp.std.unix. The current <br>
status of POSIX drafts is summarized in <URL:http://stdsbbs.ieee.org/ <br>
groups/pasc/standing/sd11.html>. <br>
ISO has also published POSIX.1 as ISO/IEC 9945-1:1990. ISO and IEEE <br>
will soon publish the new revision of this standard: ISO/IEC <br>
9945-1:1996. This will be the new 1996 revision of POSIX.1, which will <br>
contain in one single standard POSIX.1(1990), POSIX.1b(1993), <br>
POSIX.1c(1995), and POSIX.1i(1995) (perhaps also POSIX.1a(1996) if it <br>
gets ready in time). If you want to order the POSIX standard but are <br>
not in a hurry, may be it is a good idea to wait a few months until <br>
ISO/IEC 9945-1:1996 is available. All differences between <br>
POSIX.1(1990) and POSIX.1(1996) will be marked by bars at the page <br>

margins. <br>
This text just summarizes POSIX.1b and related work on Linux. Many <br>
people interested in POSIX.1b support seem also to be interested in <br>
POSIX.1c support (threads). Some information about POSIX.1c support is <br>
on <URL:http://www.mit.edu:8001/people/proven/pthreads.html> and <br>
<URL:http://www.aa.net/~mtp/>. There is now a production release <br>
package called "PCthreads (tm) POSIX threads for Linux" available from <br>
<URL:ftp://sunsite.unc.edu/pub/Linux/devel/lang/c/>. It is maintained <br>
by Michael T. Peterson <[e-mail]>. A POSIX.1c package that <br>
provides real kernel-threads using the clone() system call is <br>
available from <URL:http://pauillac.inria.fr/~xleroy/linuxthreads/> <br>
and has been developed by Xavier Leroy <[e-mail]>. <br>
Markus <br>
-- <br>
Markus Kuhn, Computer Science student -- University of Erlangen, <br>
Internet Mail: <[e-mail]> - Germany <br>
WWW Home: <http://wwwcip.informatik.uni-erlangen.de/user/mskuhn> <br>
  <br>
-- <br>
  <br>
※ 来源:·BBS 水木清华站 smth.org·[FROM: 166.111.161.11] <br>
</small><hr>
<p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="143.htm">上一层</a>][<a href="171.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>