共享中断的问题

OpenQNX中文论坛 四海同心QNX论坛
1

现在我遇到这样一个问题，我的A/D采样卡与网卡共用一个中断，我发现我的A/D卡中断有时会因为网卡将中断短暂屏蔽而无法响应，造成数据丢失，如何使系统不因网卡而将中断短暂屏蔽。

2

如果你需要保证A/D的中断，就不要让它于别人共享中断.

3

可是中断号是PCI总线自动分配的呀

4

换个PCI插槽试试.

5

换来换去不是和网卡共用就是和显卡共用

6

现卡不用IRQ.

7

In the specification, You can find detail information about the communication protocol between devices that shared the same IRQ No.

8

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.

9

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.

10

herbert,你好，感谢你的意见，我想首先告诉你我的MEMCPY（）并不是在ISR中作的，而是在ATTACH的线程中作的，我仔细读了QNX手册中有关共享中断的说明，它只有一小段，手册中说可以将Interruptattach()的最后一个参数改成_NTO_INTR_FLAGS_END,但是我改完后问题还是有，我的A/D卡与网卡共用中断时总是丢失数据，但是只要将网卡驱动卸载掉（slay io-net）,就一切正常，这是否说明是网卡驱动在捣乱呢？另外，唐先生，是不是共用中断就无法保证正常工作呢？那QNX怎能称为实时操作系统呢？

11
  1. Video card doesn’t use IRQ, why not share IRQ with video card?
  2. 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.
  3. 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.
12

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…

13

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.

14

You may also can find it on www.e.pku.edu.cn

15

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.

16

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.

17

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.

18

Yes, embedded NT is RTOS.

19

but.

Is Windows NT (or windows 95, or even Windows CE now) a Real-Time
Operating System?

This question appears repeatedly in this news group. Here are the key
points:

  • Despite a real-time class process, the Win32 API is not suitable to be
    used for a Real-Time System:
  1. Too few priorities for processes and threads
  2. No priority inheritance mechanism
  3. 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:
  1. 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.
  2. The DPC problem could have been avoided by increasing the number of DPC
    levels, but this is not the case.
  3. 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.
20

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.