DETAILS
	In the TI5416 DSP demo, the interrupt latency introduced by the kernel is under 5 microseconds when running at 80MHz. In the 68331 demo running at 16MHz the worst case latency is 144 microseconds. The Linux demo does not affect interrupt latency since it just blocks and unblocks the real time alarm signal to invoke the timer's tick() routine. The Windows demo doesn't affect latency since it uses a WM_TIMER callback to call the timer's tick() routine. A kind of priority inversion is exhibited by the Win32 system due to it's use of that WM_TIMER message. See the readme for the Win32 demo for more information. The six components fit into roughly 900 'C' source statements, excluding commentary. In the TI5416 system, that code and data occupies about 4K words. In the MC68331 system, it occupies 7k bytes. Stack size requirement depends upon the number of priorities used, and the processor used. The test systems easily gets by with 500 bytes.

DETAILS

In the TI5416 DSP demo, the interrupt latency introduced by the kernel is under 5 microseconds when running at 80MHz. In the 68331 demo running at 16MHz the worst case latency is 144 microseconds.

The Linux demo does not affect interrupt latency since it just blocks and unblocks the real time alarm signal to invoke the timer's tick() routine.

The Windows demo doesn't affect latency since it uses a WM_TIMER callback to call the timer's tick() routine. A kind of priority inversion is exhibited by the Win32 system due to it's use of that WM_TIMER message. See the readme for the Win32 demo for more information.

The six components fit into roughly 900 'C' source statements, excluding commentary. In the TI5416 system, that code and data occupies about 4K words. In the MC68331 system, it occupies 7k bytes.

Stack size requirement depends upon the number of priorities used, and the processor used. The test systems easily gets by with 500 bytes.