Overview
HWAccess communicates with external libraries in order to display H/W information ints main view. A list of messages and sample code is provided by Asymmetric Software to encourage developers to create new libraries for HWAccess.
Several silicon access functions are integrated with the HWAccess application. External DLLs can access H/W components by using the HWAccess services. Each library may contain specific knowledge for a PC component or even a remote component meaning a device that is connected to an external port in the system. A library may acquire, analyze and format data before sending them to the main application for displaying and further processing.
The way HWAccess and external libraries communicate is shown in the diagram where the main application is responsible for propagating user requests to the DLLs, updating the main view area, updating the GUI controls and panels. On contrast the libraries acquire and process silicon component information.
Events
Sequence of events is critical. On the one hand the libraries must execute as fast as possible their scripts, methods and functions with the system functionality and resources saved and restored as quickly as possible. Yet the main application may have to service more than a single library request at a time especially in configurations with multiple watches, tests and sampling processes. For each message documented there is a note for the thread priority used on the particular DLL service. Services initiated by HWAccess fall into two categories. GUI and auxiliary services. GUI services are functions where the main objective is to update controls, views or panels within the framework. Auxiliary services are those where the low priority process is sufficient to satisfy an application request. For instance retrieving or formating data from a library is considered an auxiliary process and a background thread would be sufficient. On the other hand when a button is pressed on the active controls of a library the response must be instantaneous. The libraries could instantiate threads with different priority levels. Watches, tests, data sampling may initiate separate threads for processing information. The main application keeps one thread for each library to service H/W requests. The DLL must utilize the thread by using the appropriate H/W service. For example having several watches active for PCI will only require a single service to acquire all data for all watches. Implementing a separate access for each watch will degrade the performance of the library and reduce the minimum sampling period the system may offer.
Messages
There are 2 types of messages for information exchange between libraries and main application. AM_ messages are send by HWAccess to a DLL. LM_ type messages are send by the DLL to HWAccess requesting service. The AM_ messages are within the User message range WM_USER to WM_USER+0x0FFF. The LM_ messages are within the User message range WM_USER+0x1000 to WM_USER+0x1FFF.
The DLL interface seializes the LM_ messages send to HWAccess. This is transparent to the DLLs built with MFC and the common library (which is in effect an interface library) as the later provides several functions to propagate a request from the DLL to the main application. Multiple threads could initiate H/W service requests from the DLL end. These are serialized before the main application processes them. At the same time HWAccess is responsible to serialize requests targeting the DLLs. All documented messages handled by a library must include error handling. This is necessary as the interface library will throw user exceptions on main program termination or communication loss between APP/DLL. Active watches or H/W tests at any time should be gracefully terminated if such an exception takes place.
For further reading see HWAccess Message Interface.
