VISA library operation method and device based on ARM embedded platform

Abstract

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

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of testing and measurement, and in particular to a VISA library running method and device based on an ARM embedded platform. BACKGROUND

[0002] VISA (Virtual Instrument Software Architecture) is a standardized interface specification in the field of automated testing and measurement, and its core value lies in realizing the interoperability between test instruments across manufacturers and interface types. VISA provides a standard I / O function library for instrument programming, referred to as a VISA library.

[0003] The current mainstream VISA implementation scheme (such as NI-VISA, Keysight IO Libraries, etc.) has the following technical features: 1. Mainly designed for desktop operating systems (such as Windows, x86 architecture Linux systems); 2. Adopting a closed-source commercial software mode; 3. High system resource occupation; 4. Lack of optimization design for resource-limited ARM embedded platforms, making it difficult to meet the needs of high-performance embedded application scenarios. SUMMARY

[0004] The purpose of the present application is to provide a VISA library running method and device based on an ARM embedded platform to alleviate the technical problem that the VISA library is difficult to meet the requirements of embedded application scenarios with high performance.

[0005] In a first aspect, the present application provides a VISA library running method based on an ARM embedded platform, applied to a test box running a VISA library, the test box being used to control at least one measuring instrument, and the method comprising: initializing the layered architecture of the VISA library; wherein 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 the at least one measuring instrument; wherein the session structure of the communication session comprises session attributes and preset attributes associated with data reading operations; setting at least one of the preset attributes 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 attributes and writing into a buffer. closing a communication session established with the at least one measuring instrument.

[0006] In an optional embodiment, the step of discovering and establishing a communication session connection with the at least one measuring instrument comprises: the application layer, using the initialized VISA library, sends a communication session request for establishing a communication session with at least one measuring instrument connected through a preset communication protocol interface; the API interface layer, performing preset parameter verification on the communication session request, and passing the communication session request that passes the verification to the core logic layer; the core logic layer, parsing a resource string in the communication session request that passes the verification, determining an interface type, so that the hardware abstraction layer establishes communication with the at least one measuring instrument based on the interface type; creating a communication session established with the at least one measuring instrument, storing a session structure of the communication session based on memory allocated by a memory allocator, and initializing preset attributes in the session structure; determining a preset communication protocol applied by the at least one measuring instrument based on device information returned by the hardware abstraction layer for the interface type, and preparing a corresponding state of a protocol stack of the preset communication protocol; the hardware abstraction layer, interacting with a driver of a preset communication protocol of the driver layer; finding at least one measuring instrument corresponding to the interface type; if found successfully, obtaining interface information and endpoint information, and returning the found successfully information and the endpoint information to the core logic layer through a configured DMA controller; the driver layer, based on the driver of the preset communication protocol, processing corresponding underlying details of the preset communication protocol, and sending device information and endpoint information of at least one measuring instrument establishing a communication session to the hardware abstraction layer.

[0007] In an optional embodiment, the step of setting at least one preset attribute for the VISA library comprises: the application layer, establishing a setting request for at least one preset attribute of the VISA library; the API interface layer, performing preset parameter verification on the setting request, and transmitting the setting request that passes the verification to the core logic layer; the core logic layer, based on the setting request that passes the verification, finding a to-be-set attribute value, and judging whether the to-be-set attribute value meets the requirements; if yes, updating the preset attribute in the session structure; judging whether there is a preset attribute of a hardware type; if yes, unifying 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 analysis of the driver layer, calls a driver function of the driver layer corresponding to the standardized interface request based on a hardware type, and sends the control command to the target measuring instrument. The driver layer configures the standardized interface request based on the driver function.

[0008] In an optional embodiment, the step of sending at least one control command to the target measuring instrument comprises: The application layer sends a write request of 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 a write request that passes the verification 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 analyzed by the hardware abstraction layer according to the session attribute, and sends at least one standard data packet to the hardware abstraction layer based on a preset transmission requirement. The hardware abstraction layer analyzes the received standard data packet, transmits the received standard data packet to a preset communication protocol controller through a DMA controller, converts the standard data packet into a target data packet that can be executed by the driver layer, and transmits the target data packet to the driver layer. The driver layer analyzes and sends the target data packet to the target measuring instrument according to a preset communication protocol.

[0009] In an optional embodiment, the step of 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 comprises: The application layer prepares a buffer that meets a preset byte requirement and sends a read request of response data for the control command in the target measuring instrument, wherein the buffer includes a ring buffer. The API interface layer performs preset parameter verification on the read request and passes a read request that passes the verification to the core logic layer. The core logic layer obtains the preset attribute from the session structure, calls the hardware abstraction layer to send a message header of a second preset length to a corresponding endpoint of the target measuring instrument and read response data for the control command based on the read request, judges whether the analyzed response data is complete and valid data based on the preset attribute, copies the valid data to the buffer and records the byte number of the valid data if the response data is complete and valid data, and uses a NEON SIMD instruction set to accelerate the format conversion, checksum calculation, and the like of the valid data if the byte number is greater than a preset byte threshold. The hardware abstraction layer notifies the core logic layer through an RTOS event mechanism when the response data reaches a preset communication protocol controller, and carries the response data from a receiving FIFO of the preset communication protocol controller to the memory through a DMA controller; The driver layer transmits, based on the read request, response data sent by the target measuring instrument to the preset communication protocol controller to a preset communication protocol interface.

[0010] In an optional embodiment, the step of closing the communication session established with the at least one measuring instrument comprises: The application layer sends a closing request for the communication session established with the at least one measuring instrument; The API interface layer performs preset parameter verification on the closing request and passes the closing request that passes the verification to the core logic layer; The core logic layer releases resources occupied by the communication session, returns a session structure of the communication session to a memory allocator, removes the session from an 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 closing request for the communication session, calls an interface function to control the preset communication protocol controller to release interface resources corresponding to the communication session and close the connection established with the at least one measuring instrument, and calls an interface function of a power management unit (PMU) or operates a clock gate register to reduce power consumption of the preset communication protocol controller; The driver layer performs a bottom-layer hardware operation to complete a physical process of disconnecting from the at least one measuring instrument; a clock signal of the preset communication protocol controller will be paused or reduced in frequency to make the preset communication protocol controller enter a low-power consumption state.

[0011] In an optional embodiment, the application layer is configured to initiate a call request conforming to a VISA standard; The API interface layer, as an entrance of a VISA library, performs preset parameter verification on the call request and passes the call request to the core logic layer; The core logic layer comprises a resource manager configured to parse a resource string and manage a session life cycle, a session and attribute manager configured to maintain a state and attributes of each communication session, and an I / O and protocol engine configured to process a specific communication protocol and construct and parse a message; The hardware abstraction layer is configured to encapsulate interaction between corresponding hardware in an ARM platform and the driver layer; The driver layer is a physical hardware and an operating system / bare machine driver, and performs a bottommost operation in the layered architecture.

[0012] In a second aspect, the present application provides a VISA library running device based on an ARM embedded platform, applied to a test box running a VISA library, the test box being used for controlling at least one measuring instrument, and the device comprising: an initialization module, configured to initialize a layered architecture of the VISA library, wherein 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; a session connection module, configured to discover and establish a communication session connection with the at least one measuring instrument, wherein a session structure of the communication session comprises session attributes and preset attributes associated with data reading operations; a setting module, configured to set at least one of the preset attributes for the VISA library; a sending module, configured to send at least one control command to a target measuring instrument, wherein the target measuring instrument comprises at least one of the at least one measuring instrument; a read-write module, configured to read response data for the control command from the target measuring instrument based on the preset attributes and write the response data into a buffer; a session closing module, configured to close the communication session established with the at least one measuring instrument.

[0013] In a third aspect, the present application provides an electronic device, comprising a memory, a processor and a program stored in the memory and capable of running on the processor, wherein the processor implements the method according to any one of the preceding embodiments when executing the program.

[0014] In a fourth aspect, the present application provides a computer readable storage medium, wherein the readable storage medium stores a computer program, and the computer program implements the method according to any one of the preceding embodiments when executed.

[0015] The embodiments of the present application provide a VISA library running method and device based on an ARM embedded platform, the VISA library adopting a layered architecture comprising an application layer, an API interface layer, a core logic layer, a hardware abstraction layer and a driver layer, and capable of being applied to an ARM board in a test box for controlling at least one measuring instrument; by initializing each layer of the VISA library, establishing a communication session with a test instrument, and modifying attributes related to reading performance of the communication session, response data corresponding to a control command can be read based on the control command sent to the corresponding measuring instrument, and the communication session is closed after the control is completed, so that the VISA library can be applied to an ARM architecture, and the requirements of instrument automatic measurement and control are met.

[0016] Other features and advantages of the present application will be set forth in the descriptions that follow, and in part will be apparent from the description, or can be learned by practice of the application. The purposes and other advantages of the application will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

[0017] In order to make the above objectives, features and advantages of the present application more obvious and comprehensible, the following preferred embodiments are specifically described below, and the accompanying drawings are referred to for a detailed description. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the following will briefly introduce the drawings needed to be used in the specific embodiments or the prior art description. Obviously, the drawings described below are some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without any creative effort.

[0019] Figure 1 A VISA library running method flow chart based on an ARM embedded platform provided by an embodiment of the present application; Figure 2 A customized memory allocator schematic diagram provided by an embodiment of the present application; Figure 3 A network resource discovery flow schematic diagram provided by an embodiment of the present application; Figure 4 An asynchronous read operation flow schematic diagram provided by an embodiment of the present application; Figure 5 A functional module schematic diagram of a VISA library running device based on an ARM embedded platform provided by an embodiment of the present application; Figure 6 A hardware architecture schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0020] In order to make the objectives, technical solutions and advantages of the embodiments of the present application more clear, the technical solutions of the present application will be described clearly and completely below with reference to the drawings. Obviously, the described embodiments are some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without any creative effort belong to the protection scope of the present application.

[0021] Therefore, the VISA library running method and device based on an ARM embedded platform provided by the embodiments of the present application can provide complete VISA core functions, and can be optimized by fully utilizing the characteristics of the ARM architecture to meet the requirements of embedded test and measurement applications, and can be integrated into an efficient VISA communication device.

[0022] For the convenience of understanding the present embodiment, first, a VISA library running method based on an ARM embedded platform disclosed by the present embodiment is introduced in detail, which is applied to an ARM embedded development board of an experiment box, the experiment box is connected with various measuring instruments outside the experiment box through a preset communication protocol interface (a USB interface is taken as an example for illustration in the present embodiment); the measuring instruments include a digital multimeter, and the experiment box can obtain device information of the digital multimeter and corresponding measurement data such as direct current voltage by applying the method provided by the present embodiment, so as to perform corresponding control on the measuring instruments.

[0023] Figure 1 A flow chart of the VISA library running method based on the ARM embedded platform provided by the present embodiment.

[0024] With reference to Figure 1 , the method comprises: Step S102, initializing the layered architecture of the VISA library.

[0025] Among them, for the ARM hardware / driver layer, the ARM processor is started, the RTOS (such as FreeRTOS) is initialized, the USB host controller driver is loaded and is ready; for the hardware abstraction layer (HAL), the HAL part of the VISA library is initialized, and the available hardware interface can be detected. For example, hal_usb_init() can be called to establish a connection with the underlying USB driver; for the core logic layer, the resource manager is initialized to prepare for resource management; for the VISA API interface layer, the API layer function pointer is prepared, and waits for the application program to call; for the application layer, the user's test application program starts running.

[0026] As an optional embodiment, the memory allocator can also be customized for the core logic layer, at this time, the memory pool such as the memory allocator (Slab allocator) will pre-allocate memory blocks for subsequent session objects, buffers, etc.

[0027] Exemplarily, when the VISA library is initialized, slab caches are created for several commonly used sizes of objects (such as Session structure, small buffer). Each slab cache contains a pre-allocated large memory block (from system malloc or static array), which is divided into multiple fixed-size object slots. When visa_malloc, according to the request size, the corresponding slab cache is found, and an idle slot is taken out from it. When visa_free, the slot is marked as idle and returned to the slab cache. This is faster than the general malloc and can prevent fragmentation.

[0028] AsFigure 2 As shown, the cache-aware data structure implementation includes: when defining the IO buffer structure, using typedef struct __attribute__((aligned(L1_CACHE_LINE_SIZE))) {...} io_buffer_t; (where L1_CACHE_LINE_SIZE is a macro of the target ARM L1 cache line size, such as 32 or 64). When processing data in the buffer, try to access in memory order (usually row first) to take advantage of CPU prefetch and cache spatial locality.

[0029] The hierarchical structure of the VISA library includes an application layer, a VISA API interface layer, a core logic layer, a hardware abstraction layer, and a driver layer. The application layer is used to initiate a call request conforming to the VISA standard. The API interface layer, as an entrance of the VISA library, provides C functions compatible with the VPP-4.3 specification, performs preset parameter verification on the call request, and converts the API call into an internal core logic call to pass to the core logic layer. The core logic layer includes a resource manager for parsing resource strings and managing session life cycles, 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. The hardware abstraction layer is used to encapsulate the interaction between the corresponding hardware and the driver layer in the ARM platform. The driver layer, also known as the hardware / driver layer, is the physical hardware and operating system / bare-metal driver, and performs the lowest-level operations in the hierarchical architecture.

[0030] Step S104, discover and establish a communication session connection with at least one measurement instrument.

[0031] The session structure of the communication session includes session attributes and preset attributes associated with data reading operations. This step S104 can be implemented by the following steps: Step 1.1, the application layer uses the initialized VISA library to issue a communication session request established with at least one measurement instrument connected through a preset communication protocol interface.

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

[0033] Step 1.2, the API interface layer, performs preset parameter verification on the communication session request, and passes the communication session request that passes the verification to the core logic layer.

[0034] Here, based on the foregoing embodiment, it can be known that the viOpen() function is called to perform basic parameter verification (for example, whether the resource string format is roughly correct, and whether the vi pointer is valid), and then pass the communication session request to the core logic layer.

[0035] Step 1.3, the core logic layer, parses the resource string in the communication session request that passes the verification, determines the interface type, so that the hardware abstraction layer establishes communication with at least one measuring instrument based on the interface type; creates a communication session established with at least one measuring instrument, stores the session structure of the communication session in the memory allocated by the memory allocator, and initializes the preset attributes in the session structure; based on the device information returned by the hardware abstraction layer for the interface type, determines the preset communication protocol applied by at least one measuring instrument, and prepares the corresponding state of the protocol stack of the preset communication protocol.

[0036] The core logic layer includes a resource manager (Resource Manager), a session and attribute manager (Session & Attribute Manager), and an I / O and protocol engine (I / O & Protocol Engine); The resource manager receives the viOpen request and the resource string "USB0::0x1234::0x5678::SN001::INSTR"; parses the resource string, 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 could be USBTMC or USBRaw); instructs the HAL layer to look up and establish communication with the USB device with these characteristics.

[0037] The Session & Attribute Manager, in response to the resource manager request, creates a new session; the Session & Attribute Manager allocates a block of memory from its custom memory allocator, such as Figure 2 malloc(), for storing the new session structure (Session); initializes the default attributes in the session structure (such as the timeout time VI_ATTR_TIMEOUT defaulting to 2000 ms, the terminator VI_ATTR_TERMCHAR_EN defaulting to disabled, etc.).

[0038] The I / O & Protocol Engine, based on the resource string and the device information returned by the HAL, determines that the USB device uses the USBTMC protocol; prepares the relevant states of the USBTMC protocol stack.

[0039] Step 1.4, the Hardware Abstraction Layer (HAL layer), interacts with the driver of the preset communication protocol of the driver layer; looks up at least one measuring instrument corresponding to the interface type; if successful, obtains the interface information and endpoint information, and returns the lookup success information and endpoint information to the core logic layer through the configured DMA controller.

[0040] The resource manager in the foregoing embodiments calls a HAL function like hal_usb_find_device(0x1234, 0x5678, "SN001") through the core logic layer. The HAL layer interacts with the USB driver of the ARM hardware / driver layer (for example, in a Linux environment, it can be through libusb or directly communicate with the kernel driver; in an RTOS, through the USB host driver API provided by the RTOS). The USB driver enumerates the connected USB device, and finds the device matching the VID / PID / SN. If the device is found, the HAL layer continues to call, for example, hal_usb_open() to open the device, hal_usb_get_interface() to obtain the USB TMC interface, hal_usb_claim_interface() to claim the interface ownership, and hal_usb_get_endpoints() to obtain the Bulk-IN, Bulk-OUT, and optional Interrupt-IN endpoint information required for USB TMC communication. The HAL layer returns the operation success and the endpoint information to the core logic layer.

[0041] In actual applications, if the USB driver supports, the HAL layer can configure the DMA controller (through interfaces such as hal_dma_configure()) for subsequent USB data transmission, to reduce the CPU burden. Data transmission is performed by using the DMA controller (if the hardware supports and is applicable), the DMA transmission is configured and started through the HAL layer.

[0042] Note that HAL is the key to implement the DMA transfer optimization in ARM. Its implementation varies according to the target ARM platform running environment (bare metal or operating system): 1) Bare metal environment: HAL functions directly access the memory-mapped registers of ARM chip. For example: hal_serial_write(char c): write character c to the data register of target UART peripheral (e.g. UART_DR). hal_serial_set_baud(uint32_t baud): calculate the frequency division coefficient corresponding to the baud rate, and write it to the baud rate configuration register of UART (e.g. UART_BRR). hal_gpio_set(port, pin): set the output data register of GPIO port, and set the specified pin to high. Interrupt handling: HAL layer configures the ARM interrupt controller (e.g. NVIC), sets the interrupt priority, and registers the interrupt service routine (ISR). ISR directly reads the hardware status register (e.g. RXNE flag in UART status register indicating that data is ready to be received) and performs fast processing (e.g. read data from UART_DR and put it into the ring buffer), and then clear the interrupt flag bit. 2) Operating system environment (e.g. Linux, RTOS): HAL functions usually call the device driver interface provided by the operating system. For example: hal_serial_write(char c): call the write() system call provided by the operating system, and the target file descriptor points to the corresponding serial device (e.g. / dev / ttyS0). hal_usb_bulk_write(handle, data, len): call the function provided by the USB driver library (e.g. libusb or kernel USB driver interface such as ioctl or write) to write data to the specified USB endpoint. hal_tcp_connect(ip, port): call the socket(), connect() functions in the socket API of the operating system. Interrupt / event handling: HAL layer waits for event notification from the underlying driver through the mechanism provided by the operating system (e.g. select, poll, epoll, or RTOS event flag, semaphore, message queue), and notifies the core logic layer of asynchronous events (e.g. data arrival, DMA completion).

[0043] HAL is designed to shield the underlying differences so that the core logic layer code is as platform-independent as possible. Optimizations for ARM are reflected in the HAL, for example, using ARM's DMA controller for data transfers (configure source, destination address, length, and start the transfer through interfaces like hal_dma_start_transfer) to reduce CPU load, or invoking hal_pmu_request_sleep to enter a specific low-power mode when idle.

[0044] The USBTMC protocol in the preceding embodiments is implemented in the core logic layer's I / O and protocol engine, including the following steps: Initialization: When opening a USB INSTR resource, 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.), finds the device matching the VID / PID, configures the device, and gets the Bulk-IN, Bulk-OUT, and optional Interrupt-IN endpoint addresses and their properties (such as maximum packet size).

[0045] 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 transmission size, incrementing bTag, etc. Combine the 12-byte message header and command data (may need to be chunked to comply with the maximum packet size of the USB endpoint) into one or more USB transfers. Call hal_usb_bulk_write to send the data blocks through the Bulk-OUT endpoint, handle possible timeouts and errors.

[0046] 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 message header, containing the expected read length, an incremented bTag, etc. hal_usb_bulk_write is called to send this 12-byte request message header through the Bulk-OUT endpoint. hal_usb_bulk_read is called to attempt to read the DEV_DEP_MSG_IN response message header (12 bytes) from the Bulk-IN endpoint. The protocol engine parses the received message header, extracting the TransferSize (actual returned data length) and status information (TermChar indication in bmTransferAttributes, etc.). Based on the TransferSize, hal_usb_bulk_read is called to read the actual instrument response data (possibly multiple reads). Short Packet and status check are handled as required by the USBTMC protocol. The terminator set in the VISA attributes is handled. The read data is returned to the application layer.

[0047] Status check (through Interrupt-IN endpoint, optional): If the device supports and is configured with an Interrupt-IN endpoint, the protocol engine can receive a READ_STATUS_BYTE response from the device through hal_usb_interrupt_read (usually in an asynchronous manner), obtaining the status byte (corresponding to viReadSTB) or indicating an SRQ.

[0048] The USBTMC protocol is only an example, and other protocols such as VXI-11 (based on ONC RPC / XDR, implementing create_link, device_write, device_read, etc. RPC calls), HiSLIP (based on TCP, implementing initialization handshake, data / command messages, synchronous / asynchronous channel management) have similar implementations, involving message construction, sending, receiving, and parsing according to their respective protocol specifications, which are also completed in the protocol engine of the core logic layer and rely on the network or USB interface of the HAL layer.

[0049] In addition, the resource discovery process can vary according to the interface type, and is coordinated by the resource manager of the core logic layer and completed by the HAL layer; among them, the viFindRsrc function receives an expression parameter (expr), and the resource manager filters the list of all resource strings returned by the HAL layer according to the expression (which may contain the wildcard?*), and finally returns the matched list to the application layer through the findList parameter (ViFindList type, essentially a handle), and the application layer subsequently uses viFindNext to obtain the resource strings one by one, such asFigure 3 Resource discovery is implemented as shown; The following interface types can be included in the resource discovery process: (1) ASRL (Serial): HAL layer scans the list of serial devices provided by the operating system (e.g. / dev / ttyS*, / dev / ttyACM*, / dev / ttyUSB* on Linux, or COM ports on Windows) or pre-defined UART port hardware addresses in a bare-metal environment. The resource manager formats them into VISA resource strings (e.g. "ASRL1: :INSTR", "ASRL / dev / ttyS0: :INSTR").

[0050] (2) USB: HAL layer calls the USB driver interface (e.g. libusb's libusb_get_device_list) to enumerate all connected USB devices. For each device, its device descriptor (VID, PID) and interface descriptor are obtained. The interface descriptor is checked for compliance with the USBTMC class (Class=0xFE, SubClass=0x03, Protocol=0x00 / 0x01) or a specific vendor protocol. If matched, the VID, PID, and optionally the serial number (obtained by reading the string descriptor) are extracted, formatted into a VISA resource string (e.g. "USB0: :0x1234: :0x5678: :SN123: :INSTR").

[0051] (3) TCPIP (VXI-11): HAL layer broadcasts (UDP port 111) PMAP_DUMP or PMAP_GETPORT requests to the local network's SunRPC Portmapper, querying which devices have registered the VXI-11 core channel service (Program=0x0607AF). Upon receiving a response, the host IP address from the response is further sent a VXI-11 create_link RPC (optionally with the intent to find the device name), or directly attempts to connect to the standard VXI-11 port (TCP 111+service port number), formatted into a VISA resource string (e.g. "TCPIP0: :192.168.1.100: :inst0: :INSTR").

[0052] (4) TCPIP (HiSLIP): The HAL layer uses an mDNS / DNS-SD protocol library (e.g. Bonjour SDK, Avahi or an embedded mDNS implementation) to query for the _hislip._tcp service type on the local network. Upon discovery of the service, the TXT record of the service is resolved for the device name, port number (typically 4880) and IP address, formatted as a resource string (e.g. "TCPIP0::192.168.1.101::hislip0::INSTR").

[0053] (5) TCPIP (SOCKET): No active discovery is typically performed, and the viFindRsrc function might directly return an error or an empty list for this type of expression, leaving it to the user to provide the complete resource string (e.g. "TCPIP0::192.168.1.102::5025::SOCKET") at viOpen time.

[0054] (6) GPIB: The HAL layer interacts with the GPIB controller driver (e.g. ibfind of linux-gpib or similar interface) to query for the bus interface name (e.g. "gpib0") configured by the controller. It might then be necessary to send a Parallel Poll or Serial Poll command to discover the devices active on the bus and their master addresses, formatted as a resource string (e.g. "GPIB0::12::INSTR").

[0055] Step 1.5, Driver Layer, the driver handling the preset communication protocol 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 establishing a communication session to the hardware abstraction layer.

[0056] Here, the USB host controller hardware of the ARM processor actually performs the 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 transfer, descriptor retrieval, etc. The driver provides the discovered device information and endpoint information to the HAL layer.

[0057] On this basis, the layered architecture performs a return flow including: 1) the HAL layer returns a success status and endpoint information to the core logic layer. 2) The resource manager of the core logic layer confirms that the device has been successfully opened, and the session and attribute manager prepares the allocated session handle vi (usually a pointer to a session structure or an index). 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.

[0058] Step S106, setting at least one preset attribute for the VISA library; specifically, it can include the following steps: Step 2.1, the application layer, establishing a setting request for the at least one preset attribute of the VISA library.

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

[0060] Step 2.2, the API interface layer, performing preset parameter verification on the setting request, and transmitting the setting request that passes the verification to the core logic layer.

[0061] As known from the foregoing embodiment, viSetAttribute() is called, parameter verification is performed, and then it is passed to the core logic layer.

[0062] Step 2.3, the core logic layer, finding the attribute value to be set based on the setting request that passes the verification, and judging whether the attribute value to be set meets the requirements; if so, updating the preset attribute in the session structure; judging whether there is a preset attribute of the hardware type; if so, unifying the setting request of the hardware type into a standardized interface request.

[0063] Here, the session and attribute manager of the core logic layer finds the corresponding session structure according to the vi handle passed in, finds the member variable corresponding to VI_ATTR_TIMEOUT, and verifies whether the new value 5000 is within the allowed range, and updates the value of the attribute in the session structure. Because the timeout is a software layer attribute (affecting the behavior of subsequent I / O operations), it usually does not need to be immediately interacted with the hardware. However, if the attribute is directly used to control the hardware (such as VI_ATTR_ASRL_BAUD), the hardware will be set through the HAL layer.

[0064] The session and attribute manager of the core logic layer maintains the state of each active session (ViSession). This is usually implemented through a C structure, which includes all standard attributes defined by VISA (VI_ATTR_TIMEOUT, VI_ATTR_TERMCHAR, VI_ATTR_TERMCHAR_EN) and interface-specific attributes (VI_ATTR_ASRL_BAUD, VI_ATTR_USB_INTFC_NUM, VI_ATTR_TCP_NODELAY).

[0065] viSetAttribute call: Find the corresponding session state structure based on the incoming ViSession handle (usually a pointer or index to a session structure). Find the corresponding member variable in the structure based on the Attribute ID (Attribute parameter). Validate the type and range of the incoming value (AttrState parameter). Update the value of the member variable. If the attribute requires immediate effect on the hardware or underlying driver (such as setting serial port baud rate VI_ATTR_ASRL_BAUD, setting TCP Nagle algorithm VI_ATTR_TCP_NODELAY, setting timeout VI_ATTR_TIMEOUT), call the corresponding function in the HAL layer (such as hal_serial_set_baud, hal_tcp_set_nodelay, hal_timer_set_timeout) to apply the change. Return success status code VI_SUCCESS or corresponding error code.

[0066] viGetAttribute call: Find the session structure based on the ViSession handle. Read the value of the corresponding member variable in the structure based on the Attribute ID. If the attribute is a dynamic state that requires real-time reading from the hardware or underlying driver (such as VI_ATTR_ASRL_CTS_STATE to get the CTS line state), call the HAL layer function (such as hal_serial_get_cts) to get the current value. Return the read value to the caller through the pointer (AttrState parameter). Return success status code VI_SUCCESS or corresponding error code.

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

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

[0069] In the case of setting the timeout attribute VI_ATTR_TIMEOUT, the hardware abstraction layer and the driver layer are usually not directly involved, as the timeout is mainly monitored by the I / O engine of the core logic layer when performing read and write operations. However, for preset attributes that exist for hardware types, the hardware abstraction layer and the driver layer perform corresponding operations.

[0070] Step 2.5, Driver Layer, configures the standardized interface request based on the driver function.

[0071] On this basis, the core logic layer returns VI_SUCCESS to the API layer, and the API layer returns to the application layer.

[0072] Step S108, sending at least one control command to the target measuring instrument. The target measuring instrument includes at least one. The step S108 can also be achieved by the following steps, including: Step 3.1, the application layer, sending a write request of a first preset length of control command.

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

[0074] Step 3.2, the API interface layer, performing preset parameter verification on the write request, and passing the write request that passes the verification to the core logic layer.

[0075] As known from the foregoing embodiment, the viWrite() is called, parameter verification is performed, and then passed to the core logic layer.

[0076] Step 3.3, the core logic layer, encapsulating 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 attribute; and merging and sending at least one standard data packet to the hardware abstraction layer based on preset transmission requirements.

[0077] Here, the session and attribute manager in the core logic layer finds the session structure according to the vi, and obtains the attribute (such as the timeout time) related to the current I / O operation. The I / O and protocol engine (I / O&Protocol Engine) in the core logic layer identifies it as a USBTMC session through the USBTMC write operation in the foregoing embodiment, and then constructs the DEV_DEP_MSG_OUT message header of the USBTMC. This is usually a 12-byte header, including a message ID (for example, 1), a unique transmission identifier bTag (incremented each time transmission is performed), and the length of data to be transmitted (here, 5 bytes of *IDN?). The 12-byte header and the 5-byte command "*IDN?" are combined into a 17-byte data packet. The write function of the HAL layer is called to send the 17-byte data to the previously obtained Bulk-OUT endpoint. If command batch processing is enabled, and the command is small, it can be temporarily cached, waiting to be sent together with other small commands, to improve the network or bus efficiency. However, for the USB short command, this optimization is not commonly used.

[0078] Implement Keep-alive probe packet mechanism in network protocol engine; implement send buffer and timer to combine multiple small commands in short time into batch processing for sending. Optimize VXI-11 RPC implementation, such as using pre-serialized XDR templates to reduce runtime overhead.

[0079] Step 3.4, hardware abstraction layer, parses the received standard data packet, transmits the received standard data packet to the preset communication protocol controller through the DMA controller, converts the received standard data packet into a target data packet executable by the driver layer, and transmits the target data packet to the driver layer.

[0080] For example, the hardware abstraction layer receives 17 bytes of data and target Bulk-OUT endpoint information from the core logic layer. The hal_usb_bulk_write(bulkOutEndpointHandle, data_pointer, 17) is called. The hal_usb_bulk_write internally interacts with the USB driver of the ARM hardware / driver layer. If DMA is configured, the HAL layer sets the DMA controller to transmit the 17 bytes of data from the memory to the transmission FIFO of the USB controller, and then starts the DMA transmission. The USB controller is responsible for packaging and sending the data as a USB data packet. The USB driver waits for the confirmation that the data has been sent (or partially sent if an error occurs). The actual number of bytes sent is returned to the core logic layer.

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

[0082] Here, the USB driver receives the data, transmits the data to the digital multimeter according to the USB protocol and USBTMC specification through the USB host controller hardware. The USB interface on the digital multimeter (DMM) side receives the USBTMC message, and its firmware parses the DEV_DEP_MSG_OUT message header to extract the *IDN? command. The DMM executes the command and prepares its identity string (for example, "MyDMM,ModelXYZ,SN001,FW1.0").

[0083] On this basis, the HAL layer returns the number of successfully sent bytes (for example, 17) to the core logic layer. The core logic layer knows that the actual user data in the 17 bytes is 5 bytes according to the USBTMC protocol, so it updates the retCount to 5. VI_SUCCESS and retCount are returned to the API layer, and the API layer returns them to the application layer.

[0084] Step S110, reading response data for the control command from the target measurement instrument based on the preset attribute, and writing into the buffer. Illustratively, this step S110 includes: Step 4.1, application layer, preparing a buffer meeting the preset byte requirement, and sending a read request for the response data for the control command in the target measurement instrument; wherein the buffer can include a ring buffer; the ring buffer can efficiently manage the received data, and reduce data copying.

[0085] Here, the application layer prepares a buffer to read the response: ViByte buffer

[256] ; ViUInt32 actualReadCount; viRead(vi, buffer, 256, &actualReadCount); Step 4.2, API interface layer, performing preset parameter verification on the read request, and passing the read request that passes the verification to the core logic layer.

[0086] From the foregoing embodiments, it can be known that the viRead() is called, parameter verification is performed, and then the core logic layer is passed.

[0087] Step 4.3, core logic layer, obtaining the preset attribute from the session structure, and based on the read request, calling the hardware abstraction layer to send a message header of a second preset length to the corresponding endpoint of the target measurement instrument and read the response data for the control command; based on the preset attribute, judging whether the parsed response data is complete and valid data; if yes, copying the valid data to the buffer, and recording the byte number of the valid data; if the byte number is greater than the preset byte threshold, using the NEON SIMD instruction set to accelerate the implementation of format conversion, checksum calculation, and the like on the valid data.

[0088] The session and attribute manager finds the session structure according to the vi, and gets the timeout, terminator, and other attributes. The I / O and protocol engine needs to send a USBTMC REQUEST_DEV_DEP_MSG_IN message header to the Bulk-OUT endpoint of the DMM, to inform the DMM to prepare to send data. This message header is also 12 bytes, containing the message ID, a unique bTag, and the maximum length expected to read, etc. Then the HAL layer is called to send this 12-byte REQUEST_DEV_DEP_MSG_IN header. After sending is completed, 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 packet. The USBTMC response is also a header (DEV_DEP_MSG_IN, but in the opposite direction) plus the actual data; the engine parses the header to get the length of the actual instrument data and bmTransferAttributes (which may contain terminator information); then the actual instrument response data (such as "MyDMM,ModelXYZ,SN001,FW1.0\n") is extracted; it is checked whether the terminator has been received (if VI_ATTR_TERMCHAR_EN has been enabled and VI_ATTR_TERMCHAR has been set); the valid data is copied to the buffer provided by the application layer, and the actualReadCount is set.

[0089] In some embodiments, if a large amount of numerical data is read and needs to be converted or checksum calculated, the protocol engine here can use NEON instructions for acceleration. ARM-specific hardware features are used: Among them, the ARM NEON SIMD instruction set can be used to accelerate data-intensive operations such as large block data parsing, formatting, or checksum calculation in the core logic layer through C intrinsics or assembly.

[0090] For NEON SIMD acceleration: In the protocol engine or data conversion function in the core logic layer, when processing large blocks of ASCII numerical data returned by SCPI commands, NEON intrinsics (such as vld1q_f32 to load data, vcvtq_f32_s32 to convert types, and vaddq_f32 for vector operations) can be used to process multiple data points in parallel, instead of character-by-character parsing and conversion loops. This requires including the arm_neon.h header file and using NEON-supported compiler options.

[0091] Step 4.4, Hardware Abstraction Layer, when response data arrives at the pre-set communication protocol controller, notifies the core logic layer through the RTOS event mechanism, and moves the response data from the pre-set communication protocol controller's receive FIFO to the memory through the DMA controller; Here, the hardware abstraction layer first, the core logic layer calls hal_usb_bulk_write(bulkOutEndpointHandle, request_header_data, 12) to send the read request header. Then, call hal_usb_bulk_read(bulkInEndpointHandle, internal_hal_buffer, max_packet_size_of_bulk_in) to read data from the USB device. This can be a blocking call until data arrives or times out (the timeout is implemented by the core logic layer or the HAL layer in conjunction with the RTOS timer).

[0092] In practical applications, if DMA is configured, the HAL layer will set up DMA to read data from the USB controller's receive FIFO to the memory. The read operation (especially asynchronous read, such as Figure 4 As shown) will rely heavily on interrupts. When the USB controller receives a data packet, an interrupt will be generated. The HAL layer's interrupt service routine (ISR) will be triggered, which will quickly read the data (or notify the DMA of completion), and then notify the core logic layer's waiting task that the data is ready through the RTOS's event mechanism (such as semaphores, message queues). For synchronous viRead, it can wait for this event in a loop.

[0093] Efficiently use the ARM interrupt mechanism to handle asynchronous I / O completion, service requests (SRQ), and other events, configure the interrupt priority through the NVIC, quickly handle and notify the core logic layer in the ISR. As shown in Figure 2 The typical implementation flow of the asynchronous read operation (viReadAsync) is as follows: (1) API call: Application layer calls viReadAsync, providing session handle, buffer pointer, expected read length, etc. (2) Core logic layer processing: 1) Validate parameters, 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), call the HAL layer interface to start hardware asynchronous operation. The HAL layer is responsible for configuring hardware (e.g. DMA controller channel, USB URB) and registering completion interrupts. 4) If the underlying hardware does not support hardware asynchronous or HAL is not encapsulated, the core logic layer may start a dedicated background task (RTOS Task) to perform blocking read, or rely on interrupt-driven reception (ISR puts data into the buffer, and the core logic layer task processes it later). 5) viReadAsync immediately returns, returning JobID to the application layer, indicating that the operation has been submitted but not completed. (2) Hardware / drive layer operation: ARM hardware (e.g. UART, USB controller, DMA) performs data reception. (3) Interrupt / event notification: When data reception is complete (or certain conditions are met, such as DMA transfer completion, USB URB completion, serial port reception FIFO threshold), hardware interrupts are generated. (4) HAL / ISR processing: 1) Interrupt service routine (ISR) or bottom layer driver callback function is triggered. 2) ISR performs minimal processing, such as reading data into the buffer, updating status, and clearing interrupt flags. For DMA or USB URB completion interrupts, get the transfer status and actual transfer byte count. 3) Notify the core logic layer registered processor of completion information (including Job ID, status, actual byte count) through operating system event mechanisms (such as sending messages to queues, setting event flags, releasing semaphores) or directly calling pre-registered callback functions. (5) Core logic layer completion processing: 1) Core logic layer event processing task or callback function is awakened / called. 2) Look up the associated session and request information according to Job ID. 3) Mark the completion of this asynchronous operation and record the result. 4) If the user has registered the VI_EVENT_IO_COMPLETION event through viEnableEvent, construct the event object and put it into the event queue of the corresponding session. Application layer gets the result: The application layer can get the operation result by polling Job ID status (if the corresponding API is provided) or waiting for VI_EVENT_IO_COMPLETION event by calling viWaitOnEvent.5) The HAL layer passes the received raw data chunk (containing the USB TMC header and instrument data) to the I / O and protocol engine of the core logic layer.

[0094] Step 4.5, Driver layer, based on the read request, transmits the response data sent by the target measuring instrument to the control command to the preset communication protocol controller through the preset communication protocol interface.

[0095] Here, the target measuring instrument - digital multimeter DMM transmits response data through its USB interface. The USB host controller of the ARM processor of the experiment box receives the data. The USB driver processes the reception of the underlying USB packet and stores the data in the buffer specified by the HAL layer, notifying the HAL layer of the arrival of data through an interrupt.

[0096] On this basis, 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 to the application layer. At this time, the buffer contains "MyDMM,ModelXYZ,SN001,FW1.0\n".

[0097] Step S112, closing the communication session established with the at least one measuring instrument, specifically including: Step 5.1, application layer, sending a closing request for the communication session established with the at least one measuring instrument; that is, calling viClose(vi).

[0098] Step 5.2, API interface layer, performing preset parameter verification on the closing request, and passing the closing request that passes the verification to the core logic layer.

[0099] Among them, viClose() is called, and after parameter verification, it is passed to the core logic layer.

[0100] Step 5.3, core logic layer, releasing resources occupied by the communication session, returning the session structure of the communication session to the memory allocator, removing the session from the active session list, and notifying the hardware abstraction layer to close the communication session established with the at least one measuring instrument.

[0101] The session and attribute manager finds the session structure according to the vi, releases all resources (e.g., internal buffer) occupied by the session, returns the session structure itself to the custom memory allocator (e.g., visa_free() of the Slab allocator), and removes the session from the active session list. The I / O & Protocol Engine notifies the HAL layer to close the connection with the USB device.

[0102] Step 5.4, the hardware abstraction layer, based on the closing request of the communication session, calls interface functions 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 interface functions of a power management unit PMU or operating a clock gate register.

[0103] Specifically, the hardware abstraction layer receives the closing request and calls functions such as hal_usb_release_interface() and hal_usb_close(device_handle). Among them, these functions interact with the USB driver to release the previously declared interface and close the connection with the USB device.

[0104] In some embodiments, if the USB interface is no longer used by any session, the HAL layer can reduce the power consumption of the USB controller by hal_pmu_request_sleep() or operating the clock gate register (by hal_disable_peripheral_clock()).

[0105] Dynamic power management can interact with the PMU through the HAL layer, call interface functions such as hal_pmu_request_sleep() to request to enter the WFI (Wait For Interrupt) or deeper sleep mode when the library is idle; or write related clock control registers through the HAL layer when the peripheral is closed to realize the clock gating of the peripheral: (1) PMU integration: HAL layer implements hal_pmu_request_sleep (enum sleep_mode mode). The core logic layer's background task or timer periodically checks library activity status. If all sessions are idle for more than a threshold, hal_pmu_request_sleep (DEEP_SLEEP) is called. HAL function internally executes ARM's WFI (Wait For Interrupt) or WFE (Wait For Event) instructions, or calls RTOS-provided vTaskSuspend() or power management framework interface. When an interrupt occurs (such as UART receive interrupt, timer wake-up interrupt), ISR or wake-up task calls hal_pmu_resume() to resume normal running state.

[0106] (2) Clock gating: In hal_serial_open() of HAL layer, in addition to configuring UART registers, 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 disabled. For example, on STM32, this involves operating the relevant register bits of the RCC (Reset and Clock Control) peripheral.

[0107] Step 5.5, driver layer, performs underlying hardware operations to complete the physical process of disconnecting from at least one measuring instrument; the clock signal of the preset communication protocol controller will be suspended or reduced in frequency to make the preset communication protocol controller enter a low-power state.

[0108] Among them, the USB driver performs low-level operations to close the device. If power management is triggered, the clock of the USB controller can be gated or enter a low-power state.

[0109] On this basis, the return process includes: the HAL layer returns a success state to the core logic layer; the core logic layer returns VI_SUCCESS to the API layer; the API layer returns to the application layer.

[0110] In the preferred embodiment of practical application, the VISA library adopting the layered architecture including the application layer, the API interface layer, the core logic layer, the hardware abstraction layer and the driver layer can be applied in the ARM board in the experimental box for controlling at least one measuring instrument; by initializing each layer of the VISA library, a communication session with the test instrument is established, and properties related to the reading performance of the communication session are modified and set; at this time, based on the control command sent to the corresponding measuring instrument, the response data corresponding to the control command can be read, and after the control is completed, the communication session is closed, so that the VISA library can be applied in the ARM architecture to meet the needs of instrument automation measurement and control.

[0111] Each layer of the embodiment of the present application has its own function and works cooperatively to realize efficient and standardized communication with the measuring instrument, and in combination with the ARM optimization technologies (such as NEON, advanced memory management, DMA, interrupt, power management, etc.) embodied in the core logic layer and the HAL layer to improve performance, reduce resource occupation and power consumption.

[0112] In some embodiments, as shown in Figure 5 The embodiment of the present application also provides a VISA library running device based on an ARM embedded platform, which is applied to a test box running a VISA library, and the test box is used for controlling at least one measuring instrument, and the device comprises: An initialization module, which initializes the layered architecture of the VISA library; wherein 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; A session connection module, which discovers and establishes a communication session connection with the at least one measuring instrument; wherein the session structure of the communication session comprises session attributes and preset attributes associated with data reading operations; A setting module, which sets at least one preset attribute for the VISA library; A sending module, which sends at least one control command to a target measuring instrument; wherein the target measuring instrument comprises at least one; A reading and writing module, which reads response data for the control command from the target measuring instrument based on the preset attributes and writes the response data into a buffer; A session closing module, which closes the communication session established with the at least one measuring instrument.

[0113] The embodiment of the present application provides an electronic device, and in the embodiment, the electronic device can be, but is not limited to, a personal computer (PC), a notebook computer, a monitoring device, a server and other computer devices with analysis and processing capabilities.

[0114] As an exemplary embodiment, refer to Figure 6 The electronic device 110 comprises 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 through the bus 114; the memory 113 is used for storing a computer program supporting the processor 112 to execute the above method, and the processor 112 is configured to execute the program stored in the memory 113.

[0115] The machine-readable storage medium mentioned herein can be any electronic, magnetic, optical, or other physical storage apparatus, which can contain or store information, such as executable instructions, data, and the like. For example, the machine-readable storage medium can be a RAM (Random Access Memory), a volatile memory, a non-volatile memory, a flash memory, a storage drive (such as a hard disk drive), any type of storage disk (such as an optical disk, a DVD, and the like), or similar storage medium, or a combination thereof.

[0116] The non-volatile medium can be a non-volatile memory, a flash memory, a storage drive (such as a hard disk drive), any type of storage disk (such as an optical disk, a DVD, and the like), or similar non-volatile storage medium, or a combination thereof.

[0117] It can be understood that the specific operation methods of the functional modules in the embodiments can refer to the detailed descriptions of the corresponding steps in the above method embodiments, which will not be repeated here.

[0118] The computer-readable storage medium provided in the embodiments of the present application has a computer program stored therein, and the computer program code can implement the method described in any of the above embodiments when executed, and the specific implementation can refer to the method embodiments, which will not be repeated here.

[0119] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the above-described system and device can refer to the corresponding process in the foregoing method embodiments, which will not be repeated here.

[0120] Finally, it should be noted that: the above-described embodiments are only specific implementations of the present application, which are used to illustrate the technical solutions of the present application, but not to limit it, the protection scope of the present application is not limited thereto, although the foregoing embodiments of the present application have been described in detail, those skilled in the art should understand that: any person skilled in the art within the technical range disclosed by the present application, still can modify or easily think of changes to the technical solutions recorded in the foregoing embodiments, or make equivalent replacement to part of the technical features; and these modifications, changes or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and all should be covered in the protection scope of the present application.

Claims

1. A method for running a VISA library based on an ARM embedded platform, characterized in that, The application is applied to a test box running a VISA library, the test box being used to control at least one measuring instrument, and the method comprises: initializing a layered architecture of the VISA library; wherein 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; finding and establishing a communication session connection with the 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 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; closing the communication session established with the at least one measuring instrument.

2. The method of claim 1, wherein, The step of finding and establishing a communication session connection with the at least one measuring instrument comprises: the application layer, using the initialized VISA library, sends a communication session request for establishing a communication session with at least one measuring instrument connected to the test box through a preset communication protocol interface; the API interface layer performs preset parameter verification on the communication session request and passes the communication session request that passes the verification to the core logic layer; the core logic layer analyzes a resource string in the communication session request that passes the verification, determines an interface type, so that the hardware abstraction layer establishes communication with the at least one measuring instrument based on the interface type; creates a communication session established with the at least one measuring instrument, stores a session structure of the communication session in memory based on memory allocated by a memory allocator, and initializes preset attributes in the session structure; determines a preset communication protocol applied by the at least one measuring instrument based on device information returned by the hardware abstraction layer for the interface type, and prepares a corresponding state of a protocol stack of the preset communication protocol; the hardware abstraction layer interacts with a driver of a preset communication protocol of the driver layer; finds at least one measuring instrument corresponding to the interface type; if found successfully, acquires interface information and endpoint information, and returns the found successfully information and the endpoint information to the core logic layer through a configured DMA controller; the driver layer processes corresponding underlying details of a preset communication protocol based on the driver of the preset communication protocol, and sends 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 preset attribute for the VISA library comprises: 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 finds a to-be-set attribute value based on the passed setting request, and judges whether the to-be-set attribute value meets the requirements; if yes, the preset attribute in the session structure is updated; it is judged whether there is a hardware type preset attribute; if yes, the setting request of the hardware type is unified into a standardized interface request; The hardware abstraction layer converts the standardized interface request into a preset format for the driving layer to analyze, and calls a driving function of the driving layer corresponding to the standardized interface request based on the hardware type; The driving layer configures the standardized interface request based on the driving 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 of a first preset length control command; 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 write request that passes the verification 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 analyzed by the hardware abstraction layer according to the session attribute; and based on preset transmission requirements, at least one standard data packet is merged and sent to the hardware abstraction layer; The hardware abstraction layer analyzes the received standard data packet, transmits the received standard data packet to a preset communication protocol controller through a DMA controller, converts the standard data packet into a target data packet executable by the driving layer, and transmits the target data packet to the driving layer; The driving layer analyzes and sends the target data packet to the target measuring instrument according to a preset communication protocol.

5. The method of claim 1, wherein, The step of reading response data for the control command from the target measuring instrument based on the preset attribute and writing into a buffer includes: The application layer prepares a buffer that meets the preset byte requirement, and sends a read request of the response data for the control command in the target measuring instrument; wherein the buffer includes a ring buffer; The API interface layer performs preset parameter verification on the read request, and passes the read request that passes the verification to the core logic layer; The core logic layer obtains the preset attribute from the session structure, calls the hardware abstraction layer to send a second preset length message header to the corresponding endpoint of the target measuring instrument based on the read request and read the response data for the control command, judges whether the analyzed response data is complete and valid data based on the preset attribute; if yes, 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, the NEON SIMD instruction set is used to accelerate the format conversion, checksum calculation and verification of the valid data; The hardware abstraction layer notifies the core logic layer through an RTOS event mechanism when the response data reaches the preset communication protocol controller, and moves the response data from the receiving FIFO of the preset communication protocol controller to the memory through the DMA controller. The drive layer transmits, based on the read request, response data sent by the target measuring instrument for the control command to a preset communication protocol controller through a preset communication protocol interface.

6. The method of claim 1, wherein, The step of closing the communication session established with the at least one measuring instrument comprises: The application layer sends a closing request for the communication session established with the at least one measuring instrument; The API interface layer performs preset parameter verification on the closing request and passes the closing request that passes the verification to the core logic layer; The core logic layer releases resources occupied by the communication session, returns a session structure of the communication session to a memory allocator, removes the session from an active session list, and notifies a hardware abstraction layer to close the communication session established with the at least one measuring instrument; The hardware abstraction layer, based on the closing request for the communication session, calls an interface function to control the preset communication protocol controller to release interface resources corresponding to the communication session and close the connection established with the at least one measuring instrument, and reduces power consumption of the preset communication protocol controller by calling an interface function of a power management unit (PMU) or operating a clock gate register. The drive layer performs a bottom-layer hardware operation to complete a physical process of disconnecting from the at least one measuring instrument; a clock signal of the preset communication protocol controller is to be paused or reduced in frequency to enable the preset communication protocol controller to enter a low-power consumption state.

7. The method of claim 1, wherein, The application layer is configured to initiate a call request conforming to a VISA standard. The API interface layer, as an entrance of a VISA library, performs preset parameter verification on the call request and passes the call request to the core logic layer. The core logic layer comprises a resource manager configured to analyze a resource string and manage a session life cycle, a session and attribute manager configured to maintain a state and attributes of each communication session, and an I / O and protocol engine configured to process a specific communication protocol and construct and analyze a message. The hardware abstraction layer is configured to encapsulate interaction between corresponding hardware in an ARM platform and the drive layer. The drive layer is a physical hardware and an operating system / bare machine driver, and performs a bottommost operation in the layered architecture.

8. A VISA library running device based on an ARM embedded platform, characterized in that, The device is applied to an experimental box running a VISA library, and the experimental box is configured to control at least one measuring instrument. An initialization module is configured to initialize a layered architecture of the 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 drive layer. A session connection module is configured to discover and establish a communication session connection with the at least one measuring instrument; a session structure of the communication session comprises session attributes and preset attributes associated with data read operations. A setting module is configured to set at least one preset attribute for the VISA library. A sending module is configured to send at least one control command to a target measuring instrument; the target measuring instrument comprises at least one. A read-write module is configured to read, based on the preset attributes, response data for the control command from the target measuring instrument and write the response data into a buffer. closing the communication session established with the at least one measuring instrument.

9. An electronic device, comprising: A computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to perform a method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer program stored in the readable storage medium, which, when executed, implements the method according to any one of claims 1 to 7.

Images