Real-Time Communication Drivers
All of the real-time systems I wrote involved some form of communication with other processes but many of those did not communicate directly with hardware. The fluid models I wrote for plant simulators simply made all of the relevant data available in shared memory. The Level 2 supervisory control systems communicated with the Level 1 system, and it was the Level 1 system that handled hardware I/O. However, I spent quite a bit of time supporting two previously-existing products that interacted directly with hardware.
The first was the MeltMinder control system that Inductotherm provided with their induction melting furnaces. They communicated with a wide variety of devices using serial communications. The core of the program communicated with OMEGABUS(R) digital transmitters that managed analog and digital I/O on the hardware side and communicated via text strings on the serial side (RS-232 and RS-485). The system would read a text configuration file on startup and then allocate memory for control of one, two, and sometimes three furnaces and their associated control devices. The devices included load cells, temperature sensors, position/tilt sensors, and controls for opening and closing the lid (if applicable) and tilting the furnace. The code to interface with each Omega device (we called them "hockey pucks") was allocated as an object and included functions for handling inputs and outputs, communication errors and retries, CRC checks, and more. Other serial ports were used to talk to the Variable Inductance Power Supply (VIPS) units, spectrometers, and text display panels (used to display the weight of charged material). The code ran on a DOS machine and was a legacy affair I only inherited after it had been modified using at least three wildly varying design concept over at least the previous ten years. I write about that here but the main point is that I was successfully able to make all the required fixes, updates, and additions while I was guiding another teams toward creating a replacement product.
The second time I wrote code to interface directly with hardware was at my next job, where I worked with a product line of devices for control of HVAC systems. I modified the driver layer of the software framework that allowed PCs to monitor, configure, and control remote devices via serial and TCP/IP communications. TCP/IP events were generated by interrupts and the DLL read and wrote each field of each data packet individually. I had to make a number of mods to that code to overcome issues our customers had identified. The DLL also communicated with networks of serial devices using that company's published protocols, PUP and PHP. The article linked above describes my experience with this software product as well. Blissfully, it looks like the company has updated all of its UI and control software at this point.