Driver design for photoelectric encoders under WinCE
In recent years, embedded technology has developed rapidly, and embedded systems have been widely used in various industries. However, due to the specialized nature of embedded computers, the hardware and software structures of these systems vary greatly, and their input devices are no longer as simple as those of general-purpose computers. Input devices for embedded computers typically include mice, keyboards, touchscreens, buttons, and knobs. Photoelectric encoders (commonly known as "single-key shuttles") are particularly suitable for embedded instruments and handheld devices due to their flexible, simple, and reliable input characteristics, allowing the entire system to use only one key as input. Touchscreens are also favored for their convenience, flexibility, space-saving design, and intuitive interface, but they suffer from drawbacks such as short lifespan and susceptibility to errors over prolonged use. Using photoelectric encoders to assist touchscreens as input devices would significantly enhance system reliability and make the human-machine interface more user-friendly. However, since photoelectric encoders are not standard input devices in WinCE, their drivers are not provided in the Windows CE Platform Builder embedded operating system. This article uses an embedded system development board with Samsung S3C2410 (ARM9 chip) as the CPU as the platform, and elaborates on the design method of photoelectric encoder driver under the WinCE embedded operating system for reference by peers.
1. Working principle of photoelectric encoder
An optical encoder, commonly known as a "single-button rotary encoder," resembles a potentiometer in appearance. It features an external knob that can be rotated left and right while also being pressed down. Many devices (such as monitors and oscilloscopes) use it as a human-machine interface. The following explanation uses an optical encoder manufactured by Greyhill Corporation of the United States as an example to illustrate its working principle and usage. The internal circuit of the optical encoder is shown in Figure 1. It contains one light-emitting diode (LED) and two phototransistors. When the knob is rotated left or right, the central light-shielding plate rotates with it, sequentially blocking the phototransistors. This results in the A and B phases outputting the waveform shown in Figure 2. When the knob is pressed down, pins 2 and 3 are connected, functioning like a regular button.
When rotating clockwise, phase A of the photoelectric encoder will lead phase B by half a cycle; conversely, phase A will lag phase B by half a cycle. By detecting the phases of phases A and B, it can be determined whether the knob is rotating clockwise or counterclockwise. By recording the number of changes in phases A or B, the number of times the knob has rotated can be determined. By checking whether pins 2 and 3 are connected, it can be determined whether the knob has been pressed. The specific phase detection rules are as follows:
When A is the rising edge and B=0, the knob is turned clockwise.
B is the rising edge; when A=1, the knob rotates clockwise.
When A is the falling edge, and B=1, the knob rotates clockwise.
B is the falling edge; when A=0, the knob is turned clockwise.
B is the rising edge; when A=0, the knob rotates counterclockwise.
When A is the rising edge and B=1, the knob rotates counterclockwise.
B is the falling edge; when A=1, the knob rotates counterclockwise.
When A is the falling edge and B=0, the knob rotates counterclockwise.
The rotation direction of the knob can be easily determined using the method described above. Adding an appropriate delay during the determination process can eliminate jitter interference.
2. Driver model provided by WinCE
The WinCE operating system supports two types of drivers. One is the native driver, which implements the device driver as an independent task, directly performing hardware operations at the top-level task level, thus having a clear and specific purpose. Native device drivers are suitable for devices integrated into the Windows CE platform, such as keyboards, touchscreens, and audio devices. The other is the stream interface driver, which has a custom interface. It is a general type of device driver. Stream interface drivers take the form of user-level dynamic link libraries (DLLs) that implement a fixed set of functions called "stream interface functions." These stream interface functions allow applications to access these drivers through the file system. The photoelectric encoder discussed in this article belongs to the stream interface device category.
2.1 Streaming device driver loading process
When the WinCE.NET system runs, it launches the DEVICE.exe process, which is responsible for loading the stream driver. The DEVICE.exe process loads the driver by loading the registry enumerator (RegEnum.dll). In WinCE.NET, all device resource information is recorded in the system registry by the OAL (Operational Access Registry). RegEnum.dll scans the subkeys under the registry key HEKY_LOCAL_MACHINE\Driver\BuilTIn one by one, and initializes the hardware device according to the contents of each entry when a new device is found.
2.2 Interrupts and Interrupt Handling
If a driver needs to handle an interrupt, it first needs to create an event using the `CreateEvent` function and then bind the event to an interrupt flag by calling the `InterruptInterruptIdentify` function. The Interrupt Thread (IST) in the driver can then use the `WaitForEventObject` function to wait for the interrupt to occur. After a hardware interrupt occurs, the operating system enters the exception handler, which calls the `OEMInterruptHandler` function of the Operating Array Thread (OAL). This function detects the hardware and returns the interrupt flag to the system. The system, upon receiving the interrupt flag, finds the event corresponding to that flag and wakes up the thread (IST) waiting for the event. The IST then performs interrupt handling. After handling is complete, the IST calls the `InterruptDone` function to inform the operating system that interrupt handling is finished. The operating system then calls the `OEMInterruptDone` function in the OAL again, finally completing the interrupt handling. Figure 3 shows the flowchart of interrupt handling in WinCE.NET.
3. Design of the photoelectric encoder driver
3.1 Hardware Interface between Photoelectric Encoder and S3C2410
The interface circuit between the photoelectric encoder and the S3C2410 is shown in Figure 4. Phases A and B of the photoelectric encoder are open-collector outputs. Since the I/O port level of the S3C2410 is 3.3V, it is pulled up to 3.3V through resistors and then connected to the CPU's EINT0 and EINT1 pins respectively; P1 is directly connected to 3.3V, and P2 is pulled down to GND through a resistor. When the knob is pressed, the P2 port outputs a high level; otherwise, it outputs a low level.
In operation, EINT0 and EINT1 are configured as external interrupts triggered by both rising and falling edges, and EINT2 is configured as an interrupt triggered by the rising edge. When the knob is pressed, the EINT2 pin generates a rising edge triggered interrupt.
3.2 External Interrupt Initialization and Interrupt Service Routine Writing
First, the CPU's I/O ports and interrupts must be initialized, and then the interrupt handlers must be written. This involves four steps:
Initialize the I/O ports. In the Port_Init() function, initialize EINT0 and EINT1 as interrupts triggered by both rising and falling edges. Initialize EINT2 as an interrupt triggered by the rising edge.
Add an interrupt number. Add a macro definition for the photoelectric encoder interrupt vector in oalint.h. The code is: #define SYSINTR_OED(SYSINTR_FIRMWARE+20)
Add functions for interrupt initialization, disabling, and resetting, and add relevant code to functions such as OEMInterruptEnable(), OEMInterruptDisable(), and OEMInterruptDone().
Returns the interrupt flag, which is returned by the OEMInterruptHandler() function (SYSINTR_OED).
3.3 Writing a stream interface driver
Windows CE.net divides interrupt handling into two parts: Interrupt Service Routine (ISR) and Interrupt Service Thread (IST). The ISR is typically required to be as short and fast as possible; its sole task is to return the interrupt flag. Because the ISR is small and can only perform minimal processing, the interrupt handler calls the IST to perform most of the interrupt handling. The Interrupt Service Thread (IST) remains idle until it receives a signal from the waitForSingleObject() function indicating that an interrupt has occurred. Upon receiving an interrupt signal, it calls subroutines in the PDD layer of the native device driver. These subroutines, in turn, access the hardware to obtain its status. The IST registers itself using the InterruptInitialize() function and then waits for an interrupt signal using the waitForSingleObject() function. If an interrupt signal arrives, the status of the photoelectric encoder should be recorded and stored in the variable OED_Status. OED_Status=1 indicates the knob is pressed, OED_Status=2 indicates the knob is rotated counterclockwise, and OED_Status=3 indicates the knob is rotated clockwise.
There is also a simpler phase detection rule. The specific steps are as follows: when the thread is created, the level state of EINT1 is read and stored in the variable PreEINT1. Each time an interrupt occurs, it first checks whether EINT2 is high. If it is high, it means the button is pressed; if EINT2 is low, it checks whether the level of EINT1 is the same as that of PreEINT1. If they are the same, it means the knob is rotated counterclockwise; otherwise, the knob is rotated clockwise. The judgment process is shown in Figure 5.
The Windows CE streaming interface driver model requires driver developers to write 10 interface functions. For a photoelectric encoder driver, this primarily involves writing two functions: device initialization and data reading. The Windows CE device filename prefix consists of three uppercase letters, which the operating system uses to identify the device corresponding to the streaming interface driver. Here, the device filename prefix is defined as "OED" (OptICalEncoder). The device initialization function OED_Init() is used to create interrupt events and interrupt service threads when Windows CE loads the driver. The OED_Read() function returns the photoelectric encoder's status (OED_Status).
3.4 Package the driver and add it to WinCE
Compiling a dynamic link library (DLL) using the above method is not enough, because its interface functions are not yet exported. It's also necessary to tell the linker what functions to export; therefore, a file with the .def extension must be created. In this design, it's named OpticalEnccder.def. Below is the content of this file:
A specific stream interface driver and the registry are inseparable. There are two methods to add registry entries to the WinCE kernel: one is to directly modify the .reg file under PlatformBuilder; the other is to write a custom registry file and add the dynamic link library file to the kernel by adding components. Here, we use the second method to add OpticalEncoder.dll to the kernel. The content of the registry file is as follows:
Finally, write a CEC file to modify the custom kernel registry and add OpticalEncoder.dll to the system kernel. Then, you can directly add the pre-written driver in PlatformBuilder.
Conclusion
This paper mainly introduces the principle and application method of photoelectric rotary encoders, and details the structure of the WinCE driver. A driver for the photoelectric encoder under the embedded operating system WinCE was successfully developed. Experiments prove that the method is correct and feasible, and the program runs stably and reliably.
