In the specification, You can find detail information about the communication protocol between devices that shared the same IRQ No.
If you are convinient, you can check the Windows DDK, for some clue. In fact, any OS have the similar way to solve the problem. Windows And QNX even the Solaris and Linix, they use the same IA32 system. To your application, PCI isn’t the bottleneck. You can check your code. First, you should check if you do the right thing in the ISR. Second, you should check your memcpy, it’s a bad way to copy data in the isr. How the optimize your code? Remeber more coding better performance, less code , less rom , worse performance.
I checked your previous question. I think it will be a lot of help to read some documents before you start to work. Maybe these materials will be helpful: PCI Specification, Windows NT or Windows 200 DDK. You 'd beter to write some assembly program. And check the execution time elipse for each machine code. It will be helpful to build a strong concept of performance.
- Video card doesn’t use IRQ, why not share IRQ with video card?
- The handler that you attached with InterruptAttach() is part of ISR.
InterruptAttachEvent() is always recommended unless what you do
in ISR is very very short.
- Shared IRQ is not good, because the kernel will not unmask the
interrupt unless it called all ISR (by InterruptAttach()) and all interrupt
handler attached be InterruptAttachEvent() unmasked the IRQ.
Sharing IRQ, especially two time critial threads.
Windows NT Or Windows 2k kernel. Shared IRQ is determined by hardware. It’s usual to share IRQ. How to handle different hardware event? This had beed discribed in the book. And you’d better to add a queue to your ISR. Remeber DOS keyboard ISR? Copy the idea. You must can fix that.
Don’t worry about the shared IRQ. All PCI Matchmaker support it. QNX, LINUX, WINDOWS… CAN WORK WELL. You can do this test: add as much as possible same type of NIC to you PC, start all net service, and check is there shared IRQ? I can forecast: it can work well And have shared IRQ.
So don’t worry about OS support and compiler. Many years before, I trust myself very much, but worry about OS, compiler and so on. But A is my fault.
Keep walking , keep walking…
In my second note, I should say you 'd better copy data using another way except memcpy.
Really that give you a lot of convinience, but the performance still can be improve.
You may also can find it on www.e.pku.edu.cn
Sure it will work fine because there is TCP/IP stack handles network
error, that means even you lost packets, the stack will automatically
resend them. So Lost a couple of packets is not a big deal in netowrk.
But in his case, even a single DSP interrupt can’t be lost.
BTW, I don’t think Windows is real time OS.
You can use raw packet without tcpip, without error handler. To Realtime OS, In ABB MACH2 system, they use Windows NT Embeded to handle 0.5-1ms Task, It’s same to QNX. So I think it’s prety good in realtime.
I already said, it’s unfair to compare NIC with his case. the IRQ can be queued at ethernet, but in his case, queued IRQ means lose data.
You can always use any type of comunication without protocal, if you don’t care about reliability.
Handle 0.5-1ms task? sure, even DOS can.
Yes, embedded NT is RTOS.
Is Windows NT (or windows 95, or even Windows CE now) a Real-Time
This question appears repeatedly in this news group. Here are the key
- Despite a real-time class process, the Win32 API is not suitable to be
used for a Real-Time System:
- Too few priorities for processes and threads
- No priority inheritance mechanism
- Some calls are synchronous with process from the Dynamic Class
- Despite a good interface to hardware for CLASSICAL applications, this
interface is not suitable to develop a Real-Time System:
- Most of the job in a device driver is done at the DPC level. And most
COTS DD take too much time in the DPC.
- The DPC problem could have been avoided by increasing the number of DPC
levels, but this is not the case.
- Pentium Power Management interrupt can preempt your system for an
unpredictible amount of time (depending of the BIOS)
- Real-Time clock
There is a lack of programmable timer.
To my opinion, his application is a sampling and calculation and then send result to somewhere. So there at least 2 differenct task. One is sampling, other is FFT. That application needn’t calculate FFT every sample time. The application need to shift FFT start point.
So AD need to be calculated every time.
But FFT need to be calulated maybe every 5ms.
So a queue is suitable to cache the data.
And a queue will help to prevent mutually access to a single resource. You needn’t add any handler to ensure exclusive access.
What I want to discuss is software queue. It will be really helpful to prevent some unpredictable problem.