I’m faced with the possibility of having to develop an interrupt hander/device driver in QNX 4.25. I am an experienced QNX developer, and have developed interrupt hanlders in DOS environments. Here are my questions:
(1) Is this a formidable task? I know it will involve some work, but are there pitfalls lurking about?
(2) Are there any samples to view? There is an older reference on the QNX website to the QUICS site, but I can’t trace this link.
It’s a piece of cake under QNX 6.x (QNX 4.x maybe the same). A simple handler can be made from a specified function using InterruptAttach(). This allows you to share the heap space. It feels very similar to dos.
All the obvious restrictions apply, like don’t call library code unless it’s a listed safe function to use in interrupts and be wary of how much cpu the function uses. Don’t use the fpu unless you ensure it’s preservation. Be careful with non-atomic operations as the interrupt cannot wait, you either buffer or disgard the result. And if swap should suddenly appear as a qnx feature then there is also the requirement to only use memory that is locked, it would be a good idea to code for this anyway.
Another neat option in QNX 6.x is InterruptAttachEvent() which gives you normal process level execution and can be viewed as a way of getting a super high priority timer and the added benefit of using your prefered interrupt source.
Excuse me if this sounds like a sales pitch but qnx’s support for interrupt coding makes me 
Update: QNX 4.x equivalent of InterruptAttach() is called qnx_hint_attach(). I don’t think there is an equivalent of InterruptAttachEvent()
There is a practical equivalent of InterruptAttachEvent, and that is to write your interrupt handler with only 2 lines (1 to mask the interrupt, and the other to return a proxy).
At process time do a Receive, and if it is a proxy, service the hardware and unmask the interrupt.
Of course it isn’t as neat as InterruptAttachEvent, but it gets you the same benefits.