(v13) Accessing hardware

This page applies to Harlequin v13.1r0 and later; and to Harlequin MultiRIP but not Harlequin Core

Methods

Hardware access can be achieved in the following ways:

• Through an existing interface. This is the easiest method, and is appropriate when communicating via sockets, writing to a parallel port device, reading from a serial port, writing to the file system or a display, and so on. It might work for some kinds of SCSI or USB device.
• Using memory mapping. The interface card (or whatever) has sufficient logic to act as a cooperative process which can remove or supply data in a buffer shared with the plugin, according to some protocol known to both. The memory might be part of the computer's main memory or be resident on the board. This is also quite easy to implement, but can lead to expensive interface cards or processors.
• By using a custom device driver.

Device driver considerations

Input and output almost always go via a device driver. While this manual does not explain how to write device drivers, there are some general important points which are covered below.

A key decision when designing a device driver is establishing which features will be available in the driver, and which in the calling plugin. Device drivers are harder to debug than user code, so it is desirable to make then as straightforward as possible. On the other hand, a driver may be appropriately used in several applications, and re‐using as many features as possible is worthwhile as well.

From the RIP's point of view, however, performance is often the deciding criterion as system calls can prove expensive.

Making one call to the device driver for each band of raster data rather than each scanline normally gives much better performance in an output plugin, for example, even if the device is scanline‐oriented. This might then require a scanline‐processing loop within the driver.

Should there be a tradeoff to make between making system and device‐driver calls, and making an additional copy of the data, making the copy is nearly always the better choice for performance in NT.

Where interrupts are involved, it is important to make the interrupt handler part of the device driver.