This chapter describes how the designs from the chapter are realized in C++. It begins with explaining a development environment used and C++ DDF bindings in Section 6.1, followed by Section 6.2 that describes snapshot results for the main use cases of the camera driver.
6.1 Environment setup and C++ DDF bindings
6.1.1. Environment setup
It is quite important that a stable development environment that suits the project development use case be created. In ASML, there are three development environment options: regular Clearcase stream, BOA, and dumbo Clearcase stream. As this project is a prototype, a dumbo Clearcase stream was created from a stable environment reference. This isolated dumbo Clearcase environment was chosen in order to avoid external changes during the duration of the project. Besides, a Wind River Workbench (WRWB) was used for code development and testing.
6.1.2. C++ DDF bindings
Note: Most of the contents in this subsection are internal to ASML and will be left out for the public version of the document
Data Definition File (DDF) is an ASML client-server-based specific internal file format. It is a lan-guage-independent file format that describes an interface, data types, and functions. ASML software components use DDF to communicate and interact with each other. The DDF is written using a specific syntax and translated into various ASML supported programming languages (C, C++, Python, Java).
These different languages need to be bridged so that ASML software components can communicate smoothly regardless of the language used to build them. Hence, every ASML supported language has a DDF binding. Since C++ is used in this project, the binding of DDF to C++ is explained below.
Before starting the generation of the C++ bindings (header and source files) from the DDFs, it is very important to correctly identify the existing type of the DDFs provided by the software component to generate the corresponding binding files. There are three types of DDF based interfaces: server, single-ton, and library. In this project, the DDF based server interfaces were used, and the process to generate the C++ binding files is explained step by step in the confidential version of this document. For more detailed information about the types of DDF interfaces, refer to [12].
6.2 Use case Implementation snippets
The camera driver has many use cases starting from the startup of the driver to grabbing a frame. It provides different interfaces that the clients of this component use. The implementation aspect and code snippet are presented below for the main use cases.
6.2.1. Driver startup and shutdown
The client starts and shuts down the driver process using the provided DriverxDC interface of the driver.
The dispatcher layer of the driver handles the requests coming through this interface from the client and it dispatches them to the lower layers of the component. During startup, all needed software resources and memory are allocated and released after the driver’s shutdown. The dispatcher code snippet for starting and shutting down the driver is shown in Figure 20.
31 Figure 20: Driver startup and shutdown snippets
6.2.2. Hardware initialization and termination
Different hardware types in the image sensor subsystem need to be initialized to communicate and execute the requested hardware command properly. These hardware components are initialized in a step-wise manner under the control of the client. The client uses the provided DRIVERxINIT interface to initialize hardware one step at a time. The dispatcher of the camera driver handles this request and dispatches the request to the proper function in the application layer module. The function then checks if the requested step to initialize hardware is valid. If it is valid, the function dynamically invokes a class that is responsible for initializing the corresponding hardware of the given step. The signature of the dispatcher function for a step-wise hardware initialization use case is shown in Figure 21.
32
Figure 21: Driver hardware initialization and termination snippets
6.2.3. Frame grabbing
This is the main use case of the camera driver: to capture and retrieve a frame using the available image sensor types in the TWINSCAN machine. The client uses the DRIVERxSENSOR to flush the sensor and grab a frame. The request to grab a frame is successful when all the precognitions such as the driver’s hardware initialization, relay selection, and sensor activation are met. Figure 22 shows the function signature that is invoked when the client requests to grab a frame.
Figure 22: Grab frame use case snippet
6.3 Implementation of the redesign improvements
In the driver’s original C implementation, there are many duplications of function table pointers that are used to mimic some of the OO behaviors and properties. In addition, there are many large arrays of structs that contain a sequence of data and function pointers to encapsulate data and function together.
These shortcomings of the C implementation are improved in the C++ prototype implementation by redesigning some of the driver modules and applying OO features such as polymorphism. Large mod-ules are divided into smaller classes that improve the code's modularity, structure, and maintainability.
Other drawbacks in the C implementation are its memory management and exception handling tech-niques. It uses the if statements approach for error handling that increases the overhead to the program and the difficulty of differentiating it from the program's logical code. It also needs explicit allocation and deallocation of memory techniques to allocate memory in a heap dynamically. In the C++ prototype implementation, efficient and better techniques are used for both memory management and exception handling. Smart pointers are used for dynamic memory allocation that reduces memory leak vulnera-bilities. In addition, try-catch pair is used for error handling that improves error debugging. In addition, C macros used for different operations such as string operation are replaced by their corresponding C++
STL features that are efficient, clean, and type-safe code.
33