Application Control Interface

What is the Application Control Interface?

The ACI is a set of proprietary Phyton software elements that allows integration of the ChipProg programmers into an external computerized environment, for example Automated Test Equipment (ATE). The ChipProgUSB software includes three Application Control Interface components:
 

1) The ACI.DLL file that specifies a set of ACI functions, which can be invoked from external applications to perform programming operations. This DLL conforms completely to Microsoft's dynamically-linked shared library concept.
 

2) The aciprog.h header file written in the C/C++ language that lists all the ACI functions exported to the ACI.DLL.DLL and the structures associated with these functions.

3) A few program examples that control ChipProg programmers from external applications
 

Requirements

1) The ChipProgUSB software must be installed on the computer that controls the ChipProg operations (hereafter the instrumental or host computer). The latest ChipProgUSB software version is available for free download from the http://www.phyton.com/htdocs/support/update.shtml webpage.

2) The ACI.DLL.DLL requires the Windows XP, Windows 7, or Windows 8 operating system.

3) It is necessary to position the windows.h file before the aciprog.h file in the application program.

32- and 64-bit Microsoft Windows OS - specific of use

There is the difference in Application Control Interface use under control of the 32- and 64-bit Windows. 32-bit applications should use the ACI.DLL dll and the ACI.lib export library; 64-bit - ACI64.DLL and ACI64.lib respectfully. 32-bit applications can be used for working with Application Control Interface under control of either Windows versions: 32- and 64-bit.

How does the Application Control Interface works?

The ACI.DLL launches the programmer’s executable file by means of the ACI_Launch()  function and then controls the ChipProgUSB software by calling other ACI functions. The ChipProgUSB executable, universal for all Phyton USB-hosted programmers, is UProgNT2.exe.

Each ACI function, being called by an external application, sends back to this application a unique function return code. The return code constants - ACI_ERR_xxx - are defined into the aciprog.h file included in the ACI software set.

The ACI.DLL launches the programmer executable file by means of the ACI_Launch()  function and then controls the ChipProgUSB software by calling other ACI functions. The ChipProg executable, universal for all USB-hosted programmers, is the UProgNT2.exe.

Each ACI function, being called by an external application, sends back to this application a function return code. The return code constants - ACI_ERR_xxx - are defined into the aciprog.h file included into the ACI software set.

An external application can call either an ACI function without any parameter (just by the function name) or by the function name with an added pointer to the parameter structure. The very first member of any structure is always the 'UINT size' parameter that defines the structure size. This insures compatibility of different ACI.DLL versions. The only exception is the ACI_IDECommand() function. Here we sacrificed uniformity of the structure format in behalf of simplicity of the pseudo-function declaration.

Names of all the ACI objects (functions and structures) always begin with the prefix ACI. Names of the structure patterns complete with the suffix _Params.

Numbers of the memory buffers and layers in memory buffers begin from zero. All addresses have a 64-bit format and consist of two 32-bit halves (low and high), in order to be compiler-independent. For example, if the compiler recognizes the uint64 type of data, then the function call for the function that assigns a 64-bit memory buffer address in the structure ACI_Memory_Params, can be presented as:

ACI_Memory_Params params;

*((uint64 *)params.AddressLow) = 0x123456789ABC;

Note! All addresses in the structures are shown in the format specified by the device manufacturer, i.e. in Bytes, Words, etc. For example, for any 16-bit microcontroller the address format is always a Word, not a Byte.

In most cases, in a process in which the programming is under control of an external application, it is not necessary to make visible the ChipProgUSB graphical user interface (GUI). The ACI allows you to hide the ChipProgUSB GUI. However, it may be necessary to unhide the programmer GUI, or just some windows and dialogs, for setting up the programming environment and for debugging purposes (for example, for selecting the target device, loading the file, etc.). When the programming environment is set up, the ChipProgUSB user interface can be hidden to free more display space for the controlling application.

How to control multiple device programmers by means of the Application Control Interface?

It is possible to remotely launch an unlimited number of ChipProg programmers and to drive each of them individually via ACI. After launching a programmer, the ACI creates in the ACI.DLL a special unique object - "a connection". A particular connection is defined by the ConnectionID parameter that defines a particular device programmer running under ACI control. The ACI_SetConnection function allows for selection of a particular device programmer among others. Then, after the programmer is selected, all the ACI functions will serve only one of these connections; i.e. they all will affect one selected device programmer. If only one programmer is under control, the connection will be set automatically.

It is important to remember that more than one ChipProgUSB can be launched in either the Single-programming or the Multi-programming or Gang-programming mode. If, for example, a cluster of six ChipProg programmers was launched in the gang mode, then a whole cluster driven by the ACI will represent a single connection, not six connections. So, in terms of the ACI, this cluster will have one ConnectionID.

for example Automated Test Equipment (ATE)