Controlling a Pinball Machine Using Linux
The module I wrote is based on the examples given in the excellent tutorial The Linux Kernel Module Programming Guide. Every kernel module requires an initialization function that is called when the module is installed via insmod. This is where I write out the control words to the two 8255 PPIs defining which ports are for input and which are for output. Here is also a good place to register a character device file, which is a simple means to communicate between kernel space and user space. I created one called /dev/pmrek.
To turn this module into a periodic process, I declared a workqueue for it. Workqueues are a new feature of the 2.6 kernel. The function in my device driver I want to call with the workqueue is pmrek_process_io(). The workqueue is defined at the global level of the module code with the statements:
static struct workqueue_struct * pmrek_workqueue; static struct work_struct pmrek_task; static DECLARE_WORK(pmrek_task, pmrek_process_io, NULL);
Then, in the module initialization function pmrek_init(), create the workqueue with:
pmrek_workqueue = create_workqueue(pmrek_WORKQUEUE);
This does not actually schedule the workqueue yet. That happens when the supervisory program activates it. Figure 5 is a flowchart of the low-level hardware I/O operations performed by pmrek_process_io().
The first thing it does is read in the switch columns using inb(). If there are any valid switch detections, they are written to a log buffer. This log buffer is consumed by the supervisory process, and game play advances depending on the switches detected. Switch detections are stamped with the exact time they occurred by getting the CPU Real Time Stamp Counter (RTSC) via the inline assembly command:
__asm__ volatile (".byte 0x0f, 0x31" : "=A" (cpu_time));
This sets cpu_time to the number of CPU machine cycles that have occurred since booting. It is handy for precise timing measurements. Some switches, such as the pop bumpers and slingshots, require an immediate solenoid response.
Next, any enqueued commands are executed in order by calling the function pmrek_process_commands(). Commands can be sent from the supervisory program by writing to /dev/pmrek, or they can originate in the module itself. If a momentary solenoid is to be fired, the four-bit solenoid number is output using outb(). Then the enable output is set high to turn on the 74LS154 decoder output. The enable duration is kept by a counter that is decremented by the workqueue process delay, which is three milliseconds. Thus, a 26-millisecond solenoid pulse will take eight workqueue cycles before the enable bit is set low again to turn it off.
Next, the control process services the feature lamps. The AS2518 architecture includes a lamp driver board populated with 60 silicon controlled rectifiers (SCRs) to turn on or off individual light bulbs selectively on the play field and back box. Like the momentary solenoids, these SCRs are driven by decoders that take a four-bit input and turn on one of 16 outputs. To handle all 60 feature lamps, there are four decoders. The control program steps through the 16 positions and selectively turns on any of the four lamps associated with it. All of this must be done at the beginning of every cycle of the 120-Hertz, rectified DC power supply waveform. On the AS2518, this is accomplished using an interrupt triggered by a power supply zero-crossing detector. I decided not to use an interrupt. Instead, I employed a “shotgun” method by executing the control process at double this rate or faster, ensuring that the SCRs are triggered every cycle.
The last I/O operation performed by the workqueue process is to output the next row strobe for the next reading of the switch matrix. Then the process reschedules itself by issuing the command:
queue_delayed_work(pmrek_workqueue, &pmrek_task, pmrek_i.workqueue_delay);
The data structure pmrek_i contains all sorts of information about the pinball control system, including its workqueue delay, which has a value of 3. The kernel timer runs at 1,000Hz and is the heartbeat of the kernel. The workqueue delay is the number of beats before the delayed work is executed. Using this mechanism, frequencies much higher than what can be scheduled for ordinary user processes outside the kernel can be achieved, and they are more efficient in terms of the resources they use each time they execute.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- The Qt Company's Qt Start-Up
- Devuan Beta Release
- May 2016 Issue of Linux Journal
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- BitTorrent Inc.'s Sync
- The US Government and Open-Source Software
- The Humble Hacker?
- Open-Source Project Secretly Funded by CIA
- The Death of RoboVM
- Tech Tip: Really Simple HTTP Server with Python
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide