MATLAB® can interface with other languages such as C/C++ or FORTRAN, for example. In some cases, using mixed language programming allows to improve CPU computational efficiency and capabilities of SAW/BAW models. Moreover, such an interface can be useful to gain access to the model libraries not available in MATLAB. The basic idea is that the user can call his own C/C++ functions (implemented in the form of the so-called MEX functions) directly in MATLAB as if they were built-in functions, with the function names being simply the MEX file names. In fact, one should clearly understand that MEX functions are not appropriate for all applications, since MATLAB is a high-productivity environment aimed to eliminate time-consuming low-level programming in compiled languages. However, in particular cases, MEX function programming in C/C++ or Fortran allows to reduce substantially the computational time if compared to the direct MATLAB implementation (for example, in cases, where it is impossible to avoid (nested) looping or apply a proper vectorization of the SAW/BAW model).
To create MEX functions, C/C++ (or Fortran) functions need to be written and compiled using MATLAB-neutral Application Program Interface (API). API library functions are to enable and facilitate the data transfer between MEX functions and MATLAB workspace.
In MATLAB there are two types of the MATLAB APIs, which provide sets of functions for C/C++ applications running outside MATLAB to work with MATLAB functions and data, namely: MATLAB C++ Data API and MATLAB C Matrix API. The MATLAB C++ Data API supports modern C++ features, semantics and design patterns. Users, which prefer programming in C language, can use a simpler MATLAB C matrix API.
Both MATLAB interfaces have been programmed and implemented by an author to call MATLAB SAW/ BAW models from C/C++ applications, in particular, in the form of the User-Compiled Models for Keysight® Pathwave Advanced Design System (ADS).
In addition to mixed language programming, an alternative approach to interface MATLAB SAW/BAW models with external C/C++ applications has been developed and implemented by the author. It is based on MATLAB COM Integration, where COM stands for Microsoft® Component Object Module which is a framework to integrate reusable software components into an external application.
COM implementation requires the MATLAB COM Automation that is a COM protocol allowing to one application (the client or controller) to make use/control of COM objects exported from another application (the server). In our case, the server COM objects expose MATLAB modeling functionality and represent the MATLAB server running in the MATLAB environment and workspace. In practice, the MATLAB server is implemented as the stand-alone MATLAB application.
To communicate between the client and the server COM Automation is required which provides an infrastructure whereby COM automation clients or controllers (C/C++ applications) can access and manipulate shared automation objects which are exported by Automation COM servers (a set of MATLAB functions representing a MATLAB SAW/BAW model).
For data exchange between COM clients and servers for SAW/BAW modeling the author has developed and programmed TCP/IP Interface which is Transmission Control Protocol (TCP) used as a data transport protocol layered on top of the Internet Protocol (IP). MATLAB support for TCP/IP communication enables using network socket to connect an external application or remote host as the TCP/IP client with MATLAB as the server to read (receive) and return (transmit) binary and/or ASCII data. For example, via TCP/IP the client can transmit values of the input parameters to the MATLAB functions to be called from MATLAB server and return the output arguments calculated by the MATLAB functions to the client.
The COM approach using TCP/IP protocol allows to implement effectively data exchange (in the process of simulation or measurement) between an external application as client and MATLAB server. Though it is more sophisticated for programming, it has the advantage that COM components and applications are not mixed and can be compiled separately. This means that upgrades of applications and models are simplified, since only the upgraded components can be substituted without need to recompile the entire software. Moreover, a component's location is transparent to the application, so that the components can be easily relocated to another process or even to a remote system without having to modify an application itself.
