Method and device for running VISA library based on ARM embedded platform

Abstract

The application provides a VISA library running method and device based on an ARM embedded platform, and relates to the technical field of testing and measurement, and comprises the following steps: initializing a layered architecture of a VISA library; the layered architecture of the VISA library comprises an application layer, an API interface layer, a core logic layer, a hardware abstraction layer and a driver layer; discovering and establishing a communication session connection with at least one measuring instrument; wherein a session attribute and a preset attribute associated with a data reading operation are included in a session structure body of the communication session; setting at least one preset attribute for the VISA library; sending at least one control command to a target measuring instrument; wherein the target measuring instrument comprises at least one; reading response data for the control command from the target measuring instrument based on the preset attribute and writing the response data into a buffer; and closing the communication session established with the at least one measuring instrument, so as to alleviate the technical problem that the VISA library is difficult to meet the requirements of an embedded application scenario in high performance.

Description

Technical Field

[0001] This invention relates to the field of testing and measurement technology, and in particular to a method and apparatus for running the VISA library based on an ARM embedded platform. Background Technology

[0002] VISA (Virtual Instrument Software Architecture) is a standardized interface specification in the field of automated test and measurement. Its core value lies in enabling interoperability between test instruments from different vendors and with different interface types. VISA provides a standard I / O function library for instrument programming, known as the VISA library.

[0003] Current mainstream VISA implementations (such as NI-VISA, Keysight IOLibraries, etc.) have the following technical characteristics:

[0004] 1. Primarily designed for desktop operating systems (such as Windows and x86-based Linux systems);

[0005] 2. Adopting a closed-source commercial software model;

[0006] 3. High system resource consumption;

[0007] 4. Lack of optimized design for resource-constrained ARM embedded platforms makes it difficult to meet the needs of high-performance embedded application scenarios. Summary of the Invention

[0008] The purpose of this invention is to provide a method and apparatus for running the VISA library based on an ARM embedded platform, so as to alleviate the technical problem that the VISA library is difficult to meet the high performance requirements of embedded application scenarios.

[0009] In a first aspect, the present invention provides a method for running a VISA library based on an ARM embedded platform, applied to an experimental box for running the VISA library, the experimental box being used to control at least one measuring instrument, the method comprising:

[0010] The layered architecture of the VISA library is initialized; wherein the layered structure of the VISA library includes an application layer, an API interface layer, a core logic layer, a hardware abstraction layer, and a driver layer.

[0011] Discover and establish a communication session connection with the at least one measuring instrument; wherein the session structure of the communication session includes session attributes and preset attributes for associated data reading operations;

[0012] Set at least one of the preset attributes for the VISA library;

[0013] Send at least one control command to the target measuring instrument; wherein the target measuring instrument includes at least one;

[0014] Based on the preset attributes, the response data for the control command is read from the target measuring instrument and written into the buffer;

[0015] Close the communication session established with the at least one measuring instrument.

[0016] In an optional implementation, the step of discovering and establishing a communication session connection with the at least one measuring instrument includes:

[0017] The application layer uses the initialized VISA library to send a communication session request to at least one measuring instrument connected to the experimental box through a preset communication protocol interface;

[0018] The API interface layer performs preset parameter verification on the communication session request and passes the verified communication session request to the core logic layer.

[0019] The core logic layer parses the resource string in the verified communication session request to determine the interface type, enabling the hardware abstraction layer to establish communication with the at least one measuring instrument based on the interface type; it creates a communication session with the at least one measuring instrument, stores the session structure of the communication session in memory allocated by the memory allocator, and initializes the preset attributes in the session structure; based on the device information for the interface type returned by the hardware abstraction layer, it determines the preset communication protocol applied by the at least one measuring instrument and prepares the corresponding state of the protocol stack for the preset communication protocol.

[0020] The hardware abstraction layer interacts with the driver of the preset communication protocol of the driver layer; it searches for at least one measuring instrument corresponding to the interface type; if it is found successfully, it obtains the interface information and endpoint information, and returns the search success information and the endpoint information to the core logic layer through the configured DMA controller.

[0021] The driver layer, based on the driver processing of the preset communication protocol, sends the device information and endpoint information of at least one measuring instrument establishing a communication session to the hardware abstraction layer.

[0022] In an optional implementation, the step of setting at least one of the preset attributes for the VISA library includes:

[0023] The application layer establishes a setting request for at least one preset attribute of the VISA library;

[0024] The API interface layer performs preset parameter verification on the setting request and transmits the setting request that passes the verification to the core logic layer.

[0025] The core logic layer searches for the attribute value to be set based on the verified setting request, and determines whether the attribute value to be set meets the requirements; if it does, it updates the preset attribute in the session structure; it determines whether the preset attribute of the hardware type exists; if it does, it unifies the setting request of the hardware type into a standardized interface request.

[0026] The hardware abstraction layer converts the standardized interface request into a preset format for parsing by the driver layer, and calls the driver function of the driver layer corresponding to the standardized interface request based on the hardware type.

[0027] The driver layer configures the standardized interface request based on the driver function.

[0028] In an optional implementation, the step of sending at least one control command to the target measuring instrument includes:

[0029] The application layer sends a write request for a control command of a first preset length; wherein the write request includes preset basic information of the target measuring instrument;

[0030] The API interface layer performs preset parameter verification on the write request and passes the verified write request to the core logic layer.

[0031] The core logic layer encapsulates the write request of the control command into a standard data packet that can be parsed by the hardware abstraction layer according to the session attributes; and sends at least one of the standard data packets to the hardware abstraction layer based on preset transmission requirements.

[0032] The hardware abstraction layer parses the received standard data packets, and transmits the received standard data packets to the preset communication protocol controller via the DMA controller. The converted standard data packets are then converted into target data packets executable by the driver layer and transmitted to the driver layer.

[0033] The driving layer parses the target data packet according to a preset communication protocol and sends it to the target measuring instrument.

[0034] In an optional implementation, the step of reading response data for the control command from the target measuring instrument based on the preset attribute and writing it into the buffer includes:

[0035] The application layer prepares a buffer that meets a preset byte requirement and sends a request to read the response data of the target measuring instrument in response to the control command; wherein, the buffer includes a circular buffer;

[0036] The API interface layer performs preset parameter verification on the read request and passes the verified read request to the core logic layer.

[0037] The core logic layer retrieves the preset attribute from the session structure, and based on the read request, calls the hardware abstraction layer to send a message header of a second preset length to the corresponding endpoint of the target measuring instrument and reads the response data of the control command; it determines whether the parsed response data is complete and valid based on the preset attribute; if so, it copies the valid data to the buffer and records the number of bytes of the valid data; if the number of bytes is greater than a preset byte threshold, it uses the NEON SIMD instruction set to accelerate the format conversion, verification, and calculation of the valid data.

[0038] When the response data arrives at the preset communication protocol controller, the hardware abstraction layer notifies the core logic layer through the RTOS event mechanism, and moves the response data from the receive FIFO of the preset communication protocol controller to memory through the DMA controller.

[0039] The driving layer, based on the read request, transmits the response data of the target measuring instrument to the control command to the preset communication protocol controller through a preset communication protocol interface.

[0040] In an optional implementation, the step of closing the communication session established with the at least one measuring instrument includes:

[0041] The application layer sends a request to close the communication session established with the at least one measuring instrument;

[0042] The API interface layer performs preset parameter validation on the close request and passes the validated close request to the core logic layer.

[0043] The core logic layer releases the resources occupied by the communication session, returns the session structure of the communication session to the memory allocator, removes the session from the active session list, and notifies the hardware abstraction layer to close the communication session established with the at least one measuring instrument.

[0044] The hardware abstraction layer, based on the communication session closure request, calls an interface function to control the preset communication protocol controller to release the interface resources corresponding to the communication session and close the connection established with the at least one measuring instrument; and reduces the power consumption of the preset communication protocol controller by calling the interface function of the power management unit (PMU) or operating the clock gating register.

[0045] The driving layer executes low-level hardware operations to complete the physical process of disconnecting from the at least one measuring instrument; the clock signal of the preset communication protocol controller will be paused or its frequency reduced so that the preset communication protocol controller enters a low-power state.

[0046] In an optional implementation, the application layer is used to initiate a call request that conforms to the VISA standard;

[0047] The API interface layer, as the entry point of the VISA library, performs preset parameter validation on the call request and passes it to the core logic layer;

[0048] The core logic layer includes a resource manager for parsing resource strings and managing session lifecycles, a session and attribute manager for maintaining the state and attributes of each communication session, and an I / O and protocol engine for processing specific communication protocols and constructing and parsing messages.

[0049] The hardware abstraction layer is used to encapsulate the interaction between the corresponding hardware in the ARM platform and the driver layer.

[0050] The driver layer performs the lowest-level operations in the layered architecture for physical hardware and operating system / bare-metal drivers.

[0051] Secondly, the present invention provides a VISA library runtime device based on an ARM embedded platform, applied to an experimental box for running the VISA library. The experimental box is used to control at least one measuring instrument. The device includes:

[0052] The initialization module initializes the layered architecture of the VISA library; wherein the layered structure of the VISA library includes the application layer, API interface layer, core logic layer, hardware abstraction layer and driver layer.

[0053] The session connection module discovers and establishes a communication session connection with the at least one measuring instrument; wherein the session structure of the communication session includes session attributes and preset attributes for associated data reading operations;

[0054] The settings module sets at least one of the preset attributes for the VISA library;

[0055] The sending module sends at least one control command to the target measuring instrument; wherein the target measuring instrument includes at least one.

[0056] The read / write module reads response data for the control command from the target measuring instrument based on the preset attributes and writes it into the buffer.

[0057] Close the session module and close the communication session established with the at least one measuring instrument.

[0058] Thirdly, the present invention provides an electronic device including a memory, a processor, and a program stored in the memory and capable of running on the processor, wherein the processor executes the program to implement the method as described in any of the foregoing embodiments.

[0059] Fourthly, the present invention provides a computer-readable storage medium storing a computer program, which, when executed, implements the method described in any of the foregoing embodiments.

[0060] This invention provides a method and apparatus for running the VISA library on an ARM embedded platform. The VISA library employs a layered architecture including an application layer, API interface layer, core logic layer, hardware abstraction layer, and driver layer. It can be applied to an ARM board in an experimental box that controls at least one measuring instrument. By initializing each layer of the VISA library, establishing a communication session with the test instrument, and modifying settings related to the read performance of this communication session, the system can read the corresponding response data based on the control commands sent to the corresponding measuring instrument. After control is completed, the communication session is closed, enabling the VISA library to be applied to the ARM architecture and meeting the requirements for automated measurement and control of instruments.

[0061] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0062] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0063] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0064] Figure 1 A flowchart of a VISA library running method based on an ARM embedded platform is provided for an embodiment of the present invention;

[0065] Figure 2 A schematic diagram of a custom memory allocator provided in an embodiment of the present invention;

[0066] Figure 3 This is a schematic diagram of a network resource discovery process provided in an embodiment of the present invention;

[0067] Figure 4 This is a schematic diagram of an asynchronous read operation process provided in an embodiment of the present invention;

[0068] Figure 5 A functional module diagram of a VISA library runtime device based on an ARM embedded platform provided in an embodiment of the present invention;

[0069] Figure 6 This is a schematic diagram of the hardware architecture of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0070] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0071] Based on this, the present invention provides a VISA library running method and apparatus based on an ARM embedded platform, which can provide complete VISA core functions and fully utilize the characteristics of the ARM architecture for optimization to meet the needs of embedded test and measurement applications, and can be integrated into a high-efficiency VISA communication device.

[0072] To facilitate understanding of this embodiment, a detailed description of a VISA library operation method based on an ARM embedded platform disclosed in this embodiment of the invention will be provided first. This method is applied to the ARM embedded development board of the experimental box. The experimental box is connected to various measuring instruments outside the experimental box through a preset communication protocol interface (this embodiment of the invention uses a USB interface as an example). The measuring instruments include a digital multimeter. The experimental box can obtain the device information of the digital multimeter and the corresponding DC voltage and other measurement data by applying the method provided in this embodiment of the invention, so as to perform corresponding control on the measuring instruments.

[0073] Figure 1This is a flowchart of a VISA library running method based on an ARM embedded platform, provided as an embodiment of the present invention.

[0074] Reference Figure 1 The method includes:

[0075] Step S102: Initialize the layered architecture of the VISA library.

[0076] Specifically, for the ARM hardware / driver layer, it controls the ARM processor startup, RTOS (such as FreeRTOS) initialization, and USB host controller driver loading and preparation. For the Hardware Abstraction Layer (HAL), it controls the initialization of the HAL portion of the VISA library, which may probe for available hardware interfaces. For example, hal_usb_init() may be called to establish a connection with the underlying USB driver. For the core logic layer, it controls the initialization of the resource manager, preparing it for resource management. For the VISA API interface layer, it controls the preparation of API layer function pointers, etc., awaiting application calls. For the application layer, it controls the start of the user's test application.

[0077] As an optional implementation, a custom memory allocator can be designed for the core logic layer. In this case, a memory pool, such as a memory allocator (Slab allocator), will pre-allocate memory blocks for use by subsequent session objects, buffers, etc.

[0078] For example, during VISA library initialization, slab caches are created for several commonly used object sizes (such as Session structures and small buffers). Each slab cache contains a pre-allocated large block of memory (from system malloc or a static array), which is divided into multiple fixed-size object slots. During `visa_malloc`, the corresponding slab cache is looked up based on the requested size, and a free slot is retrieved. During `visa_free`, the slot is marked as free and returned to the slab cache. This is faster than general malloc and prevents fragmentation.

[0079] like Figure 2 As shown, the implementation of cache-aware data structures includes: when defining structures such as IO buffers, using `typedef struct __attribute__((aligned(L1_CACHE_LINE_SIZE))) { ...} io_buffer_t;` (where `L1_CACHE_LINE_SIZE` is a macro for the target ARM L1 cache line size, such as 32 or 64). When processing data within the buffer, access should be performed in memory order (usually line-first) to take advantage of CPU prefetching and cache spatial locality.

[0080] The VISA library's layered structure includes an application layer, a VISA API interface layer, a core logic layer, a hardware abstraction layer, and a driver layer. The application layer initiates VISA-compliant call requests. The API interface layer, as the entry point for the VISA library, provides C functions compatible with the VPP-4.3 specification, performs preset parameter validation on call requests, and converts API calls into internal core logic calls for transmission to the core logic layer. The core logic layer includes a resource manager for parsing resource strings and managing session lifecycles, a session and attribute manager for maintaining the state and attributes of each communication session, and an I / O and protocol engine for handling specific communication protocols and constructing and parsing messages. The hardware abstraction layer encapsulates the interaction between the corresponding hardware and the driver layer in the ARM platform. The driver layer, also known as the hardware / driver layer, executes the lowest-level operations in the layered architecture for physical hardware and operating system / bare-metal drivers.

[0081] Step S104: Discover and establish a communication session connection with at least one measuring instrument.

[0082] The communication session's session structure includes session attributes and preset attributes for associated data read operations. This step S104 can be achieved through the following steps:

[0083] Step 1.1, Application Layer: Using the initialized VISA library, a communication session request is sent to establish with at least one measuring instrument connected to the experimental box through a preset communication protocol interface.

[0084] First, the user application might call `viFindRsrc()` to locate the connected USBTMC device, or directly attempt to open a known resource. For simplicity, we assume the application attempts to open it directly. Second, it calls `ViStatus status = viOpen(defaultRM, "USB0::0x1234::0x5678::SN001::INSTR", VI_NULL, VI_NULL,&vi)`; where `defaultRM` is the default resource manager session; `"USB0::0x1234::0x5678::SN001::INSTR"` is the VISA resource string describing the DMM; and `&vi` is the session handle (ViSession) used to receive the returned session.

[0085] Step 1.2, API interface layer, performs preset parameter validation on communication session requests, and passes the valid communication session requests to the core logic layer.

[0086] Here, based on the aforementioned embodiments, the viOpen() function is called to perform basic parameter validation (e.g., whether the resource string format is roughly correct, whether the vi pointer is valid), and then the communication session request is passed to the core logic layer.

[0087] Step 1.3, Core Logic Layer: Parses the resource string in the verified communication session request to determine the interface type, enabling the Hardware Abstraction Layer to establish communication with at least one measuring instrument based on the interface type; Creates a communication session with at least one measuring instrument, stores the session structure of the communication session based on the memory allocated by the memory allocator, and initializes the preset attributes in the session structure; Based on the device information for the interface type returned by the Hardware Abstraction Layer, determines the preset communication protocol applied to at least one measuring instrument, and prepares the corresponding state of the protocol stack for the preset communication protocol.

[0088] The core logic layer includes the Resource Manager, the Session & Attribute Manager, and the I / O & Protocol Engine.

[0089] The resource manager receives a viOpen request and the resource string "USB0::0x1234::0x5678::SN001::INSTR"; it parses the resource string and identifies that the interface type is USB, the VID is 0x1234, the PID is 0x5678, the serial number is SN001, and it is an INSTR type device (meaning it may be USBTMC or USBRaw); it instructs the HAL layer to find and establish communication with USB devices that have these characteristics.

[0090] The Session & Attribute Manager creates a new session in response to a request from the Resource Manager; the Session & Attribute Manager uses its custom memory allocator, such as... Figure 2 Allocate a block of memory to store the new session structure; initialize the default attributes in the session structure (such as the timeout VI_ATTR_TIMEOUT, which defaults to 2000ms, and the terminator VI_ATTR_TERMCHAR_EN, which defaults to disabled).

[0091] The I / O and protocol engine determines whether the USB device uses the USBTMC protocol based on the resource string and the device information returned by HAL; and prepares the relevant states of the USBTMC protocol stack.

[0092] Step 1.4: The Hardware Abstraction Layer (HAL layer) interacts with the driver of the preset communication protocol of the driver layer; it searches for at least one measuring instrument corresponding to the interface type; if successfully found, it obtains the interface information and endpoint information, and returns the search success information and endpoint information to the core logic layer through the configured DMA controller.

[0093] In the aforementioned embodiments, the resource manager calls HAL functions like `hal_usb_find_device(0x1234, 0x5678, "SN001")` through the core logic layer. The HAL layer interacts with the USB driver in the ARM hardware / driver layer (e.g., in a Linux environment, this might be through libusb or direct communication with the kernel driver; in an RTOS environment, it's through the USB host driver API provided by the RTOS). The USB driver enumerates connected USB devices, searching for devices that match the VID / PID / SN. If a device is found, the HAL layer continues to call functions such as `hal_usb_open()` to open the device, `hal_usb_get_interface()` to obtain the USBTMC interface, `hal_usb_claim_interface()` to claim interface ownership, and `hal_usb_get_endpoints()` to obtain the Bulk-IN, Bulk-OUT, and optional Interrupt-IN endpoint information required for USBTMC communication. The HAL layer returns a success message and endpoint information to the core logic layer.

[0094] In practical applications, if the USB driver supports it, the HAL layer can configure a DMA controller (via interfaces such as hal_dma_configure()) for subsequent USB data transfers to reduce the CPU load. Data transfer is performed using the DMA controller (if the hardware supports it and is applicable), and the DMA transfer is configured and initiated through the HAL layer.

[0095] It's important to note that the HAL (Hardware Access Layer) is crucial for optimizing DMA transfers in ARM. Its implementation varies depending on the target ARM platform's operating environment (bare metal or operating system): 1) Bare metal environment: HAL functions directly access the ARM chip's memory-mapped registers. For example: `hal_serial_write(char c)`: Writes the character `c` to the target UART peripheral's data register (e.g., `UART_DR`). `hal_serial_set_baud(uint32_t baud)`: Calculates the prescaler corresponding to the baud rate and writes it to the UART's baud rate configuration register (e.g., `UART_BRR`). `hal_gpio_set(port, pin)`: Sets the output data register of the GPIO port, setting the specified pin high. Interrupt handling: The HAL layer configures the ARM's interrupt controller (e.g., NVIC), sets the interrupt priority, and registers interrupt service routines (ISRs). The ISR directly reads the hardware status register (e.g., the receive data ready flag RXNE in the UART status register) and performs fast processing (e.g., reading data from `UART_DR` and placing it into a circular buffer), then clears the interrupt flag. 2) Operating System Environment (e.g., Linux, RTOS): HAL functions typically call device driver interfaces provided by the operating system. For example: `hal_serial_write(char c)`: Calls the operating system's `write()` system call, with the target file descriptor pointing to the corresponding serial port device (e.g., ` / dev / ttyS0`). `hal_usb_bulk_write(handle, data, len)`: Calls functions provided by the USB driver library (e.g., libusb or kernel USB driver interfaces such as `ioctl` or `write`) to write data to the specified USB endpoint. `hal_tcp_connect(ip, port)`: Calls the `socket()` and `connect()` functions in the operating system's socket API. Interrupt / Event Handling: The HAL layer waits for event notifications from the underlying driver through mechanisms provided by the operating system (e.g., `select`, `poll`, or RTOS event flags, semaphores, message queues), and notifies the core logic layer of asynchronous events (e.g., data arrival, DMA completion).

[0096] The design goal of HAL is to shield underlying differences, making the core logic layer code as platform-independent as possible. ARM-specific optimizations are reflected in HAL, such as utilizing ARM's DMA controller for data transfer (configuring source and destination addresses and lengths and initiating transfers through interfaces like hal_dma_start_transfer) to reduce CPU load, or calling hal_pmu_request_sleep to enter specific low-power modes during idle periods.

[0097] The USBTMC protocol in the foregoing embodiments is implemented in the I / O and protocol engine of the core logic layer, including the following steps:

[0098] Initialization: When a USB INSTR resource is opened, the core logic layer interacts with the USB driver through the HAL layer (calling hal_usb_find_device, hal_usb_open, hal_usb_get_endpoints, etc.) to find the device that matches the VID / PID, configure the device, and obtain the Bulk-IN, Bulk-OUT and optional Interrupt-IN endpoint addresses and their attributes (such as maximum packet size).

[0099] Write operation (viWrite): The core logic layer receives a write request (command string) from the application layer. The protocol engine constructs a DEV_DEP_MSG_OUT message header according to the USBTMC specification, containing information such as the transfer size and incrementing bTag. The 12-byte message header and command data (which may need to be chunked to conform to the maximum packet size of the USB endpoint) are combined into one or more USB transfers. hal_usb_bulk_write is called to send the data block through the Bulk-OUT endpoint, handling possible timeouts and errors.

[0100] Read Operation (viRead): The core logic layer receives a read request from the application layer. The protocol engine constructs a REQUEST_DEV_DEP_MSG_IN header, including the expected read length, an incrementing bTag, etc. It calls hal_usb_bulk_write to send this 12-byte request header through the Bulk-OUT endpoint. It then calls hal_usb_bulk_read to attempt to read the DEV_DEP_MSG_IN response header (12 bytes) from the Bulk-IN endpoint. The protocol engine parses the received header, extracting TransferSize (actual returned data length) and status information (TermChar indication in bmTransferAttributes, etc.). Based on TransferSize, it continues to call hal_usb_bulk_read to read the actual instrument response data (this may require multiple reads). It handles the short packets and status checks required by the USBTMC protocol. It processes the terminator set in the VISA attributes. Finally, it returns the read data to the application layer.

[0101] Status check (via Interrupt-IN endpoint, optional): If the device supports and is configured with the Interrupt-IN endpoint, the protocol engine can receive the READ_STATUS_BYTE response from the device via hal_usb_interrupt_read (usually asynchronously) to obtain the status byte (corresponding to viReadSTB) or the SRQ indication.

[0102] The USBTMC protocol is just one example. Other protocols, such as VXI-11 (based on ONC RPC / XDR, implementing RPC calls such as create_link, device_write, and device_read) and HiSLIP (based on TCP, implementing initialization handshake, data / command messages, and synchronous / asynchronous channel management), are implemented in a similar way. They involve constructing, sending, receiving, and parsing messages according to their respective protocol specifications. This is also done in the protocol engine of the core logic layer and depends on the network or USB interface of the HAL layer.

[0103] Furthermore, the resource discovery process varies depending on the interface type, and is coordinated by the resource manager of the core logic layer and the HAL layer. The `viFindRsrc` function receives an expression parameter (expr). The resource manager filters the list of all resource strings returned by the HAL layer based on the expression (which may contain wildcards ?*). Finally, the matching list is returned to the application layer via the `findList` parameter (of type `ViFindList`, essentially a handle). The application layer then uses `viFindNext` to retrieve the resource strings one by one, such as... Figure 3 The diagram illustrates resource discovery.

[0104] The following interface types may be included in the resource discovery process:

[0105] (1) ASRL (Serial): The HAL layer scans the list of serial port devices provided by the operating system (such as / dev / ttyS*, / dev / ttyACM*, / dev / ttyUSB* under Linux, or COM ports under Windows) or predefined UART port hardware addresses in the bare-metal environment. The resource manager formats them as VISA resource strings (such as "ASRL1::INSTR", "ASRL / dev / ttyS0::INSTR").

[0106] (2) USB: The HAL layer calls the USB driver interface (such as libusb_get_device_list of libusb) to enumerate all connected USB devices. For each device, it obtains its device descriptor (VID, PID) and interface descriptor. It checks whether the interface descriptor conforms to the USBTMC class (Class=0xFE, SubClass=0x03, Protocol=0x00 / 0x01) or a specific vendor protocol. If it matches, it extracts the VID, PID, and optional serial number (obtained by reading the string descriptor), and formats it as a VISA resource string (such as "USB0::0x1234::0x5678::SN123::INSTR").

[0107] (3) TCPIP (VXI-11): The HAL layer broadcasts a PMAP_DUMP or PMAP_GETPORT request from SunRPC Portmapper to the local network (UDP port 111) to query which devices are registered for the VXI-11 core channel service (Program=0x0607AF). Upon receiving a response, it further sends a VXI-11 create_link RPC (which may include the intent to look up the device name) to the host IP address of the response, or directly attempts to connect to the standard VXI-11 port (TCP 111 + service port number), formatted as a VISA resource string (such as "TCPIP0::192.168.1.100::inst0::INSTR").

[0108] (4) TCPIP (HiSLIP): The HAL layer uses the mDNS / DNS-SD protocol library (such as Bonjour SDK, Avahi, or embedded mDNS implementation) to query the _hislip._tcp service type on the local network. After discovering the service, it parses the service's TXT record to obtain the device name, port number (usually 4880), and IP address, and formats it into a resource string (such as "TCPIP0::192.168.1.101::hislip0::INSTR").

[0109] (5) TCPIP (SOCKET): Usually, active discovery is not performed. viFindRsrc may directly return an error or an empty list for this type of expression. Users need to provide the complete resource string (such as "TCPIP0::192.168.1.102::5025::SOCKET") when viOpen is used.

[0110] (6) GPIB: The HAL layer interacts with the GPIB controller driver (e.g., via ibfind or a similar interface of linux-gpib) to query the bus interface name configured by the controller (e.g., "gpib0"). Then it may need to send a parallel polling or serial polling command to discover the active devices on the bus and their master addresses, formatted as resource strings (e.g., "GPIB0::12::INSTR").

[0111] Step 1.5, Driver layer: Based on the preset communication protocol, the driver processes the corresponding low-level details of the preset communication protocol and sends the device information and endpoint information of at least one measuring instrument that establishes a communication session to the hardware abstraction layer.

[0112] Here, the ARM processor's USB host controller hardware actually performs USB communication. The underlying USB driver (RTOS or bare-metal driver) handles the low-level details of the USB protocol, such as device enumeration, configuration, control transfers, and descriptor acquisition. The driver provides the discovered device and endpoint information to the HAL layer.

[0113] Based on this, the layered architecture execution return process includes: 1) The HAL layer returns the success status and endpoint information to the core logic layer. 2) The core logic layer's resource manager confirms that the device has been successfully opened, and the session and attribute manager prepares the allocated session handle vi (usually a pointer or index to a session structure). 3) The core logic layer returns the success status code VI_SUCCESS and the session handle vi to the VISA API interface layer. 4) The VISA API interface layer returns VI_SUCCESS and vi to the application layer.

[0114] Step S106: Set at least one preset attribute for the VISA library; specifically, this may include the following steps:

[0115] Step 2.1, Application Layer: Establish a setting request for at least one preset attribute of the VISA library.

[0116] Here, the preset attribute is, for example, setting a timeout viSetAttribute; the application layer can modify the default timeout: viSetAttribute(vi, VI_ATTR_TIMEOUT, 5000); (setting the timeout to 5 seconds).

[0117] Step 2.2, API interface layer, performs preset parameter validation on the setting request, and transmits the valid setting request to the core logic layer.

[0118] As can be seen from the aforementioned embodiments, viSetAttribute() is called to perform parameter validation before being passed to the core logic layer.

[0119] Step 2.3, Core Logic Layer: Based on the verified setting request, find the attribute value to be set and determine whether the attribute value meets the requirements; if it does, update the preset attribute in the session structure; determine whether there is a preset attribute for the hardware type; if so, unify the hardware type setting request into a standardized interface request.

[0120] Here, the session and attribute manager in the core logic layer, based on the passed-in vi handle, locates the corresponding session structure, finds the member variable corresponding to VI_ATTR_TIMEOUT, verifies whether the new value 5000 is within the allowed range, and updates the value of that attribute in the session structure. Because timeout is a software-managed attribute (affecting the behavior of subsequent I / O operations), it typically doesn't require immediate hardware interaction. However, if the attribute directly controls the hardware (such as VI_ATTR_ASRL_BAUD), then the hardware will be set through the HAL layer.

[0121] The core logic layer's session and attribute manager maintains the state of each active session (ViSession). This is typically implemented using a C structure containing all the standard attributes defined by VISA (VI_ATTR_TIMEOUT, VI_ATTR_TERMCHAR, VI_ATTR_TERMCHAR_EN) as well as interface-specific attributes (VI_ATTR_ASRL_BAUD, VI_ATTR_USB_INTFC_NUM, VI_ATTR_TCP_NODELAY).

[0122] The `viSetAttribute` call: Locates the corresponding session state structure based on the passed `ViSession` handle (usually a pointer or index to a session structure). Finds the corresponding member variable within the structure based on the attribute ID (the `Attribute` parameter). Verifies the type and range of the passed value (the `AttrState` parameter). Updates the value of that member variable. If the attribute needs to immediately affect the hardware or underlying driver (e.g., setting the serial port baud rate `VI_ATTR_ASRL_BAUD`, setting the TCP Nagle algorithm `VI_ATTR_TCP_NODELAY`, setting the timeout `VI_ATTR_TIMEOUT`), then calls the corresponding HAL layer function (e.g., `hal_serial_set_baud`, `hal_tcp_set_nodelay`, `hal_timer_set_timeout`) to apply the changes. Returns a success status code `VI_SUCCESS` or the corresponding error code.

[0123] The `viGetAttribute` call: Locates the session structure using the `ViSession` handle. Based on the attribute ID, it reads the value of the corresponding member variable from the structure. If the attribute is a dynamic state that needs to be read in real-time from the hardware or underlying driver (e.g., `VI_ATTR_ASRL_CTS_STATE` to get the CTS line state), it calls a HAL layer function (e.g., `hal_serial_get_cts`) to obtain the current value. The read value is then returned to the caller via a pointer (the `AttrState` parameter). A success status code `VI_SUCCESS` or the corresponding error code is returned.

[0124] For efficiency, most attribute values ​​are cached in the session structure. The HAL is only called when viSetAttribute is called and the attribute requires hardware interaction, or when viGetAttribute is called and the attribute is in a read-only dynamic state.

[0125] Step 2.4, Hardware Abstraction Layer, converts standardized interface requests into a preset format for parsing by the driver layer, and calls the driver function of the driver layer corresponding to the standardized interface request based on the hardware type.

[0126] When the timeout attribute VI_ATTR_TIMEOUT is set, the hardware abstraction layer and the driver layer typically do not directly participate, as the timeout is mainly monitored by the I / O engine of the core logic layer during read and write operations. However, for preset attributes with hardware types, the hardware abstraction layer and the driver layer perform the corresponding operations.

[0127] Step 2.5, Driver layer, based on driver functions, configure standardized interface requests.

[0128] Based on this, the core logic layer returns VI_SUCCESS to the API layer, which then returns it to the application layer.

[0129] Step S108 involves sending at least one control command to the target measuring instrument. The target measuring instrument includes at least one. Step S108 can also be implemented through the following steps:

[0130] Step 3.1, Application layer, send a write request for a control command of the first preset length.

[0131] The write request includes preset basic information about the target measuring instrument. Here, the application layer sends the *IDN? command: viWrite(vi, (ViBuf)"*IDN?", 5,&retCount); where "*IDN?" is the command string with a length of 5. &retCount is used to receive the number of bytes actually written.

[0132] Step 3.2, API interface layer, performs preset parameter validation on write requests, and passes the validated write requests to the core logic layer.

[0133] As can be seen from the aforementioned examples, viWrite() is called to perform parameter validation before being passed to the core logic layer.

[0134] Step 3.3, Core Logic Layer: Based on session attributes, encapsulate the write request for control commands into a standard data packet that can be parsed by the Hardware Abstraction Layer; based on preset transmission requirements, merge at least one standard data packet and send it to the Hardware Abstraction Layer.

[0135] Here, in the core logic layer, the session and attribute manager locates the session structure using `vi` and retrieves attributes related to the current I / O operation (such as timeout). The I / O & Protocol Engine in the core logic layer identifies the session as a USBTMC session through the USBTMC write operation described in the previous embodiment. It then constructs the USBTMC's `DEV_DEP_MSG_OUT` message header. This is typically a 12-byte header containing a message ID (e.g., 1), a unique transport identifier `bTag` (incrementing with each transfer), and the length of the data to be transferred (here, 5 bytes of `*IDN?`). This 12-byte header and the 5-byte command `*IDN?` are combined into a 17-byte data packet. The HAL layer's write function is called to send this 17-byte data to the previously acquired Bulk-OUT endpoint. If command batching is enabled and the command is small, it may be temporarily buffered, waiting to be merged with other small commands for transmission to improve network or bus efficiency. However, this optimization is not commonly used for short USB commands.

[0136] Implement a keep-alive probe packet mechanism in the network protocol engine; implement a send buffer and timer to merge multiple small commands within a short period into a batch for sending. Optimize the VXI-11 RPC implementation, such as by using pre-serialized XDR templates to reduce runtime overhead.

[0137] Step 3.4, the hardware abstraction layer parses the received standard data packets, and the DMA controller transmits the received standard data packets to the preset communication protocol controller to convert them into target data packets that can be executed by the driver layer and then transmits them to the driver layer.

[0138] For example, the Hardware Abstraction Layer (HAL) receives 17 bytes of data and target Bulk-OUT endpoint information from the core logic layer. It then calls `hal_usb_bulk_write(bulkOutEndpointHandle, data_pointer, 17)`. This controls the internal interaction between `hal_usb_bulk_write` and the USB driver in the ARM hardware / driver layer. If DMA is configured, the HAL layer sets the DMA controller to transfer these 17 bytes of data from memory to the USB controller's transmit FIFO, and then initiates the DMA transfer. The USB controller is responsible for packaging this data into USB packets for transmission. The HAL layer waits for the USB driver to acknowledge that the data has been sent (or partially sent, if an error occurs). Finally, it returns the actual number of bytes sent to the core logic layer.

[0139] Step 3.5, the driver layer, parses the target data packet according to the preset communication protocol and sends it to the target measuring instrument.

[0140] Here, the USB driver receives data and, through the USB host controller hardware, sends the data to the digital multimeter according to the USB protocol and USBTMC specification. This allows the USB interface on the digital multimeter (DMM) side to receive the USBTMC message. Its firmware parses the DEV_DEP_MSG_OUT message header and extracts the *IDN? command. The DMM executes this command and prepares its identity string (e.g., "MyDMM,ModelXYZ,SN001,FW1.0").

[0141] Based on this, the HAL layer returns the number of bytes successfully sent (e.g., 17) to the core logic layer. According to the USBTMC protocol, the core logic layer knows that 5 bytes of these 17 bytes are actually user data, so it updates retCount to 5. It then returns VI_SUCCESS and retCount to the API layer, which in turn returns them to the application layer.

[0142] Step S110 involves reading response data for the control command from the target measuring instrument based on preset attributes and writing it to a buffer. For example, step S110 includes:

[0143] Step 4.1, Application Layer: Prepare a buffer that meets the preset byte requirements, and send a read request for the response data of the target measuring instrument in response to the control command; wherein, the buffer may include a circular buffer; the circular buffer can efficiently manage the received data and reduce data copying.

[0144] Here, the application layer prepares a buffer for reading the response: ViByte buffer

[256] ; ViUInt32actualReadCount; viRead(vi, buffer, 256, &actualReadCount);

[0145] Step 4.2, API interface layer, performs preset parameter validation on the read request, and passes the validated read request to the core logic layer.

[0146] As can be seen from the aforementioned embodiments, viRead() is called to perform parameter validation before being passed to the core logic layer.

[0147] Step 4.3, the core logic layer, retrieves preset attributes from the session structure, calls the hardware abstraction layer based on the read request to send a message header of the second preset length to the corresponding endpoint of the target measuring instrument and reads the response data of the control command; determines whether the parsed response data is complete and valid based on the preset attributes; if so, copies the valid data to the buffer and records the number of bytes of valid data; if the number of bytes is greater than the preset byte threshold, uses the NEON SIMD instruction set to accelerate the format conversion, verification and calculation of the valid data.

[0148] The Session and Attribute Manager uses vi to locate the session structure and retrieve attributes such as timeout and terminator. The I / O and Protocol Engine needs to send a USBTMC REQUEST_DEV_DEP_MSG_IN message header to the DMM's Bulk-OUT endpoint to inform the DMM that it is ready to send data. This message header is also 12 bytes long and contains a message ID, a unique bTag, and the maximum expected read length, etc. The HAL layer is then called to send this 12-byte REQUEST_DEV_DEP_MSG_IN header. After sending, the HAL layer's read function is called to read data from the Bulk-IN endpoint; the HAL layer returns the data. The I / O engine first parses the received data packets. The USBTMC response also consists of a header (DEV_DEP_MSG_IN, but in the opposite direction) plus the actual data; the engine parses the header to obtain the length of the actual instrument data and bmTransferAttributes (which may contain terminator information); then it extracts the actual instrument response data (e.g., "MyDMM,ModelXYZ,SN001,FW1.0\n"); it checks if a terminator has been received (if VI_ATTR_TERMCHAR_EN is enabled and VI_ATTR_TERMCHAR is set); it copies the valid data to the buffer provided by the application layer and sets actualReadCount.

[0149] In some embodiments, if a large amount of numerical data is being read and format conversion or checksum calculations are required, the protocol engine here may use NEON instructions for acceleration. Utilizing ARM-specific hardware features:

[0150] Among them, the ARM NEON SIMD instruction set can be used to accelerate data-intensive operations at the core logic layer, such as parsing, formatting, or checksum calculation of large blocks of data, through C inline functions or assembly.

[0151] For NEON SIMD acceleration: In the core logic layer's protocol engine or data conversion functions, such as when processing large blocks of ASCII numerical data returned by SCPI commands, NEON intrinsics (e.g., vld1q_f32 for loading data, vcvtq_f32_s32 for type conversion, and vaddq_f32 for vector operations) can be used to process multiple data points in parallel, replacing the loop of parsing and converting character by character. This requires including the arm_neon.h header file and using compiler options that support NEON.

[0152] Step 4.4, Hardware Abstraction Layer: When the response data arrives at the preset communication protocol controller, the core logic layer is notified through the RTOS event mechanism, and the response data is transferred from the receive FIFO of the preset communication protocol controller to memory through the DMA controller.

[0153] Here, the hardware abstraction layer first calls `hal_usb_bulk_write(bulkOutEndpointHandle, request_header_data, 12)` to send a read request header. Then, it calls `hal_usb_bulk_read(bulkInEndpointHandle, internal_hal_buffer, max_packet_size_of_bulk_in)` to read data from the USB device. This may be a blocking call until data arrives or a timeout occurs (the timeout is implemented by the core logic layer or the HAL layer in conjunction with an RTOS timer).

[0154] In practical applications, if DMA is configured, the HAL layer will set up DMA to read data from the USB controller's receive FIFO into memory. Read operations (especially asynchronous reads, such as...) Figure 4 As shown, it heavily relies on interrupts. When the USB controller receives a data packet, it generates an interrupt. The HAL layer's Interrupt Service Routine (ISR) is triggered, which quickly reads the data (or notifies DMA completion) and then notifies the core logic layer's waiting task that the data is ready via the RTOS's event mechanism (such as semaphores or message queues). For synchronous viRead, it may wait for this event in a loop.

[0155] Efficiently utilize ARM's interrupt mechanism to handle asynchronous I / O completions, service requests (SRQs), and other events. Interrupt priorities are configured via NVIC, enabling rapid processing and notification of the core logic layer within the ISR. For example... Figure 2 As shown, the typical implementation flow of asynchronous read operation (viReadAsync) is as follows:

[0156] (1) API call: The application layer calls viReadAsync, providing parameters such as session handle, buffer pointer, and expected read length. (2) Core logic layer processing: 1) Verify parameters and assign a unique job ID. 2) Encapsulate the read request (including buffer, length, Job ID, session information, callback function pointer, or event object) into a request structure. 3) If the underlying hardware supports (e.g., DMA) and the HAL layer provides the corresponding interface (e.g., hal_serial_read_async or hal_usb_submit_urb), then call the HAL layer interface to start the hardware asynchronous operation. The HAL layer is responsible for configuring the hardware (e.g., DMA controller channel, USB URB) and registering the completion interrupt. 4) If the underlying layer does not support hardware asynchronous or the HAL layer is not encapsulated, the core logic layer may start a dedicated background task (RTOS Task) to perform blocking reads, or rely on the interrupt-driven receiving method (the ISR puts the data into the buffer, and the core logic layer's task processes it later). 5) viReadAsync returns immediately, returning the JobID to the application layer, indicating that the operation has been submitted but not completed. (2) Hardware / Driver Layer Operation: ARM hardware (such as UART, USB controller, DMA) performs data reception. (3) Interrupt / Event Notification: When data reception is completed (or specific conditions are met, such as DMA transfer completion, USB URB completion, serial port receive FIFO reaching threshold), a hardware interrupt is generated. (4) HAL / ISR Processing: 1) The interrupt service routine (ISR) or the callback function of the underlying driver is triggered. 2) The ISR performs minimization processing, such as reading data into the buffer, updating the status, and clearing the interrupt flag. For DMA or USB URB completion interrupts, the transfer status and the actual number of bytes transferred are obtained. 3) The completion information (including Job ID, status, and actual number of bytes) is notified to the processor registered in the core logic layer through the operating system event mechanism (such as sending messages to the queue, setting event flags, releasing semaphores) or by directly calling the pre-registered callback function. (5) Core Logic Layer Completion Processing: 1) The event processing task or callback function of the core logic layer is woken up / called. 2) The associated session and request information are found according to the Job ID. 3) The asynchronous operation is marked as completed and the result is recorded. 4) If the user has registered the VI_EVENT_IO_COMPLETION event via viEnableEvent, then an event object is constructed and placed in the event queue of the corresponding session. Application layer obtains the result: The application layer can wait for the VI_EVENT_IO_COMPLETION event by polling the Job ID status (if a corresponding API is provided) or by calling viWaitOnEvent. The operation result can be obtained after the event is triggered.5) The HAL layer passes the received raw data blocks (including the USBTMC header and instrument data) to the I / O and protocol engine of the core logic layer.

[0157] Step 4.5, the driver layer, based on the read request, transmits the response data of the target measuring instrument to the control command to the preset communication protocol controller through the preset communication protocol interface.

[0158] Here, the target measuring instrument—the digital multimeter (DMM)—sends response data via its USB interface. The experimental box's ARM processor's USB host controller receives the data. The USB driver processes the reception of the underlying USB packets and stores the data in a buffer specified by the HAL layer, notifying the HAL layer of data arrival via an interrupt.

[0159] Based on this, the return process includes: the HAL layer passes the data to the core logic layer; after processing, the core logic layer returns the read data length `actualReadCount` and `VI_SUCCESS` to the API layer; the API layer returns the data to the application layer. At this point, the buffer contains "MyDMM,ModelXYZ,SN001,FW1.0\n".

[0160] Step S112, closing the communication session established with at least one measuring instrument, specifically includes:

[0161] Step 5.1, Application Layer: Send a request to close the communication session established with at least one measuring instrument; that is, call viClose(vi).

[0162] Step 5.2, API interface layer, performs preset parameter validation on the close request, and passes the valid close request to the core logic layer.

[0163] In this process, viClose() is called to perform parameter validation before passing the data to the core logic layer.

[0164] Step 5.3, Core Logic Layer: Release the resources occupied by the communication session, return the session structure of the communication session to the memory allocator, remove the session from the active session list, and notify the hardware abstraction layer to close the communication session established with at least one measuring instrument.

[0165] The Session and Property Manager locates the session structure using vi, releases all resources occupied by the session (e.g., internal buffers), and returns the session structure itself to the custom memory allocator (such as the Slab allocator's visa_free()). The Resource Manager removes the session from the list of active sessions. The I / O & Protocol Engine notifies the HAL layer to close the connection with the USB device.

[0166] Step 5.4, Hardware Abstraction Layer: Based on the communication session closure request, call the interface function to control the preset communication protocol controller to release the interface resources corresponding to the communication session and close the connection established with at least one measuring instrument; reduce the power consumption of the preset communication protocol controller by calling the interface function of the power management unit (PMU) or operating the clock gating register.

[0167] Specifically, when the hardware abstraction layer receives a shutdown request, it calls functions such as `hal_usb_release_interface()` and `hal_usb_close(device_handle)`. These functions interact with the USB driver to release previously declared interfaces and close the connection with the USB device.

[0168] In some embodiments, if the USB interface is no longer used by any session, the HAL layer may reduce the power consumption of the USB controller by using hal_pmu_request_sleep() or by manipulating the clock gating register (via hal_disable_peripheral_clock()).

[0169] Dynamic power management can interact with the PMU through the HAL layer, calling interfaces such as hal_pmu_request_sleep() to request entry into WFI (Wait For Interrupt) or deeper sleep modes when the library is idle; or it can write relevant clock control registers through the HAL layer when the peripheral is powered off to implement clock gating of the peripheral.

[0170] (1) PMU Integration Implementation: The HAL layer implements hal_pmu_request_sleep(enum sleep_mode mode). The background task or timer in the core logic layer periodically checks the library activity status. If all sessions are idle for more than a threshold, hal_pmu_request_sleep(DEEP_SLEEP) is called. The HAL function internally executes the ARM's WFI (Wait For Interrupt) or WFE (Wait For Event) instructions, or calls the vTaskSuspend() or power management framework interface provided by the RTOS. When an interrupt occurs (such as a UART receive interrupt or a timer wake-up interrupt), the ISR or wake-up task calls hal_pmu_resume() to resume normal operation.

[0171] (2) Clock gating implementation: In the HAL layer's hal_serial_open() function, in addition to configuring the UART register, it is also necessary to write to the system clock controller to enable the clock of the corresponding UART peripheral. In hal_serial_close(), the clock is deenabled. For example, on STM32, this involves operating the relevant register bits of the RCC (Reset and Clock Control) peripheral.

[0172] Step 5.5, the driver layer, executes the underlying hardware operation to complete the physical process of disconnecting from at least one measuring instrument; the clock signal of the preset communication protocol controller will be paused or reduced in frequency so that the preset communication protocol controller enters a low-power state.

[0173] The USB driver performs low-level operations to shut down the device. If power management is triggered, the USB controller's clock may be gated or it may enter a low-power state.

[0174] Based on this, the return process includes: the HAL layer returning a success status to the core logic layer; the core logic layer returning VI_SUCCESS to the API layer; and the API layer returning the status to the application layer.

[0175] In a preferred embodiment of practical application, the VISA library, employing a layered architecture including an application layer, API interface layer, core logic layer, hardware abstraction layer, and driver layer, can be applied to an ARM board in an experimental box that controls at least one measuring instrument. By initializing each layer of the VISA library, establishing a communication session with the test instrument, and modifying the settings related to the read performance of the communication session, the corresponding response data of the control command can be read based on the control command sent to the corresponding measuring instrument. After the control is completed, the communication session is closed, enabling the VISA library to be applied to the ARM architecture and meeting the needs of automated measurement and control of the instrument.

[0176] In this embodiment of the invention, each layer performs its own function and works together to achieve efficient and standardized communication with the measuring instrument. Combined with the various ARM optimization technologies (such as NEON, advanced memory management, DMA, interrupts, power management, etc.) specifically embodied in the core logic layer and HAL layer, performance is improved and resource consumption and power consumption are reduced.

[0177] In some embodiments, such as Figure 5 As shown, this embodiment of the invention also provides a VISA library runtime device based on an ARM embedded platform, applied to an experimental box for running the VISA library. The experimental box is used to control at least one measuring instrument. The device includes:

[0178] The initialization module initializes the layered architecture of the VISA library; wherein the layered structure of the VISA library includes the application layer, API interface layer, core logic layer, hardware abstraction layer and driver layer.

[0179] The session connection module discovers and establishes a communication session connection with the at least one measuring instrument; wherein the session structure of the communication session includes session attributes and preset attributes for associated data reading operations;

[0180] The settings module sets at least one of the preset attributes for the VISA library;

[0181] The sending module sends at least one control command to the target measuring instrument; wherein the target measuring instrument includes at least one.

[0182] The read / write module reads response data for the control command from the target measuring instrument based on the preset attributes and writes it into the buffer.

[0183] Close the session module and close the communication session established with the at least one measuring instrument.

[0184] The present invention provides an embodiment of an electronic device. In this embodiment, the electronic device may be, but is not limited to, a personal computer (PC), a laptop computer, a monitoring device, a server, or other computer device with analysis and processing capabilities.

[0185] As an exemplary embodiment, see [reference]. Figure 6The electronic device 110 includes a communication interface 111, a processor 112, a memory 113, and a bus 114. The processor 112, the communication interface 111, and the memory 113 are connected via the bus 114. The memory 113 is used to store a computer program that supports the processor 112 in executing the above-described method. The processor 112 is configured to execute the program stored in the memory 113.

[0186] The machine-readable storage medium mentioned in this article can be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, etc. For example, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0187] Non-volatile media can be non-volatile memory, flash memory, storage drives (such as hard disk drives), any type of storage disk (such as optical discs, DVDs, etc.), or similar non-volatile storage media, or combinations thereof.

[0188] It is understood that the specific operation methods of each functional module in this embodiment can be referred to the detailed description of the corresponding steps in the above method embodiment, and will not be repeated here.

[0189] The computer-readable storage medium provided in the embodiments of the present invention stores a computer program. When the computer program code is executed, it can implement the method described in any of the above embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0190] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0191] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit them. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the scope of the technology disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention.

Claims

1. A method for running a VISA library based on an ARM embedded platform, characterized in that, An experimental setup for running a VISA library, the experimental setup for controlling at least one measuring instrument, the method comprising: The layered architecture of the VISA library is initialized; wherein the layered architecture of the VISA library includes: an application layer, used to initiate call requests conforming to the VISA standard; an API interface layer, serving as the entry point of the VISA library, performing preset parameter validation on the call requests and passing them to the core logic layer; a core logic layer, including a resource manager for parsing resource strings and managing session lifecycles, a session and attribute manager for maintaining the state and attributes of each communication session, and an I / O and protocol engine for handling specific communication protocols and constructing and parsing messages; a hardware abstraction layer, used to encapsulate the interaction between the corresponding hardware and the driver layer in the ARM platform; and a driver layer, for physical hardware and operating system / bare-metal drivers, executing the lowest-level operations in the layered architecture; Discover and establish a communication session connection with the at least one measuring instrument; wherein the session structure of the communication session includes session attributes and preset attributes for associated data reading operations; Set at least one of the preset attributes for the VISA library; Send at least one control command to the target measuring instrument; wherein the target measuring instrument includes at least one; Based on the preset attributes, the response data for the control command is read from the target measuring instrument and written to a buffer, including: the application layer, which prepares a buffer that meets the preset byte requirements and sends a read request for the response data for the control command from the target measuring instrument; wherein, the buffer includes a circular buffer; the API interface layer, which performs preset parameter verification on the read request and passes the verified read request to the core logic layer; the core logic layer, which obtains the preset attributes from the session structure, calls the hardware abstraction layer based on the read request to send a message header of a second preset length to the corresponding endpoint of the target measuring instrument and read the response data for the control command; and determines whether the parsed response data is complete and valid based on the preset attributes; if so, the valid data is copied to the buffer and the number of bytes of the valid data is recorded; if the number of bytes is greater than a preset byte threshold, then NEON is used. The SIMD instruction set accelerates the format conversion, verification, and calculation of the valid data; when the response data arrives at the preset communication protocol controller, the hardware abstraction layer notifies the core logic layer through the RTOS event mechanism and moves the response data from the receive FIFO of the preset communication protocol controller to memory through the DMA controller; based on the read request, the driver layer transmits the response data of the target measuring instrument to the preset communication protocol controller through the preset communication protocol interface for the control command. Close the communication session established with the at least one measuring instrument.

2. The method of claim 1, wherein, The step of discovering and establishing a communication session connection with the at least one measuring instrument includes: The application layer uses the initialized VISA library to send a communication session request to at least one measuring instrument connected to the experimental box through a preset communication protocol interface; The API interface layer performs preset parameter verification on the communication session request and passes the verified communication session request to the core logic layer. The core logic layer parses the resource string in the verified communication session request to determine the interface type, enabling the hardware abstraction layer to establish communication with the at least one measuring instrument based on the interface type; it creates a communication session with the at least one measuring instrument, stores the session structure of the communication session in memory allocated by the memory allocator, and initializes the preset attributes in the session structure; based on the device information for the interface type returned by the hardware abstraction layer, it determines the preset communication protocol applied by the at least one measuring instrument and prepares the corresponding state of the protocol stack for the preset communication protocol. The hardware abstraction layer interacts with the driver of the preset communication protocol of the driver layer; it searches for at least one measuring instrument corresponding to the interface type; if it is found successfully, it obtains the interface information and endpoint information, and returns the search success information and the endpoint information to the core logic layer through the configured DMA controller. The driver layer, based on the driver processing of the preset communication protocol, sends the device information and endpoint information of at least one measuring instrument establishing a communication session to the hardware abstraction layer.

3. The method of claim 1, wherein, The step of setting at least one of the preset attributes for the VISA library includes: The application layer establishes a setting request for at least one preset attribute of the VISA library; The API interface layer performs preset parameter verification on the setting request and transmits the setting request that passes the verification to the core logic layer. The core logic layer searches for the attribute value to be set based on the verified setting request, and determines whether the attribute value to be set meets the requirements; if it does, it updates the preset attribute in the session structure; it determines whether the preset attribute of the hardware type exists; if it does, it unifies the setting request of the hardware type into a standardized interface request. The hardware abstraction layer converts the standardized interface request into a preset format for parsing by the driver layer, and calls the driver function of the driver layer corresponding to the standardized interface request based on the hardware type. The driver layer configures the standardized interface request based on the driver function.

4. The method of claim 1, wherein, The step of sending at least one control command to the target measuring instrument includes: The application layer sends a write request for a control command of a first preset length; wherein the write request includes preset basic information of the target measuring instrument; The API interface layer performs preset parameter verification on the write request and passes the verified write request to the core logic layer. The core logic layer encapsulates the write request of the control command into a standard data packet that can be parsed by the hardware abstraction layer according to the session attributes; and sends at least one of the standard data packets to the hardware abstraction layer based on preset transmission requirements. The hardware abstraction layer parses the received standard data packets, and transmits the received standard data packets to the preset communication protocol controller via the DMA controller. The converted standard data packets are then converted into target data packets executable by the driver layer and transmitted to the driver layer. The driving layer parses the target data packet according to a preset communication protocol and sends it to the target measuring instrument.

5. The method of claim 1, wherein, The step of closing the communication session established with the at least one measuring instrument includes: The application layer sends a request to close the communication session established with the at least one measuring instrument; The API interface layer performs preset parameter validation on the close request and passes the validated close request to the core logic layer. The core logic layer releases the resources occupied by the communication session, returns the session structure of the communication session to the memory allocator, removes the session from the active session list, and notifies the hardware abstraction layer to close the communication session established with the at least one measuring instrument. The hardware abstraction layer, based on the communication session closure request, calls an interface function to control the preset communication protocol controller to release the interface resources corresponding to the communication session and close the connection established with the at least one measuring instrument; and reduces the power consumption of the preset communication protocol controller by calling the interface function of the power management unit (PMU) or operating the clock gating register. The driving layer executes low-level hardware operations to complete the physical process of disconnecting from the at least one measuring instrument; the clock signal of the preset communication protocol controller will be paused or its frequency reduced so that the preset communication protocol controller enters a low-power state.

6. A VISA library running device based on an ARM embedded platform, characterized in that, An experimental setup for running the VISA library, the setup being used to control at least one measuring instrument, the device comprising: The initialization module initializes the layered architecture of the VISA library; wherein the layered architecture of the VISA library includes: The application layer initiates VISA-compliant call requests; the API interface layer, as the entry point for the VISA library, performs preset parameter validation on the call requests and passes them to the core logic layer; the core logic layer includes a resource manager for parsing resource strings and managing session lifecycles, a session and attribute manager for maintaining the state and attributes of each communication session, and an I / O and protocol engine for handling specific communication protocols and constructing and parsing messages; the hardware abstraction layer encapsulates the interaction between the corresponding hardware and driver layer in the ARM platform; and the driver layer executes the lowest-level operations in the layered architecture for physical hardware and operating system / bare-metal drivers. The session connection module discovers and establishes a communication session connection with the at least one measuring instrument; wherein the session structure of the communication session includes session attributes and preset attributes for associated data reading operations; The settings module sets at least one of the preset attributes for the VISA library; The sending module sends at least one control command to the target measuring instrument; wherein the target measuring instrument includes at least one. The read / write module, based on the preset attributes, reads the response data for the control command from the target measuring instrument and writes it to a buffer. This includes: an application layer preparing a buffer that meets preset byte requirements and sending a read request for the response data for the control command from the target measuring instrument; wherein the buffer includes a circular buffer; an API interface layer performing preset parameter validation on the read request and passing the validated read request to the core logic layer; the core logic layer obtaining the preset attributes from the session structure, calling the hardware abstraction layer based on the read request to send a message header of a second preset length to the corresponding endpoint of the target measuring instrument and read the response data for the control command; determining whether the parsed response data is complete and valid based on the preset attributes; if so, copying the valid data to the buffer and recording the number of bytes of the valid data; if the number of bytes is greater than a preset byte threshold, then using NEON... The SIMD instruction set accelerates the format conversion, verification, and calculation of the valid data; when the response data arrives at the preset communication protocol controller, the hardware abstraction layer notifies the core logic layer through the RTOS event mechanism and moves the response data from the receive FIFO of the preset communication protocol controller to memory through the DMA controller; based on the read request, the driver layer transmits the response data of the target measuring instrument to the preset communication protocol controller through the preset communication protocol interface for the control command. Close the session module and close the communication session established with the at least one measuring instrument.

7. An electronic device, characterized in that, It includes a memory, a processor, and a program stored in the memory and capable of running on the processor, wherein the processor executes the program to implement the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The readable storage medium stores a computer program that, when executed, implements the method described in any one of claims 1-5.

Images