### Including CMSIS-Driver Validation Header in C Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DriverValidation.txt This snippet adds the necessary header file for the CMSIS-Driver Validation framework. It provides declarations and definitions required for integrating the validation tests into the application. This is a prerequisite for using the `cmsis_dv` thread. ```C #include "cmsis_dv.h" ``` -------------------------------- ### Connecting to TCP ECHO Server using Telnet Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SockServer/Embedded/MDK/Board/IMXRT1050-EVKB/Abstract.txt This command opens a telnet session to the test platform's ECHO server on port 7. After connecting, any characters entered will be echoed back by the server. ```Shell telnet 192.168.1.100 7 ``` -------------------------------- ### Compliant CMSIS-Driver SPI Test Report (Plain Text) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DriverValidation.txt This snippet presents the updated plain text test report for the CMSIS-Driver SPI after the identified issues have been fixed. It shows that TEST 03: SPI_Initialize_Uninitialize now PASSED, leading to an overall PASSED test result. This demonstrates the successful resolution of the driver compliance issues. ```Plain Text Report CMSIS-Driver SPI Test Report May 6 2020 11:15:30 TEST 01: SPI_GetVersion DV_SPI.c (1023): [INFO] Driver API version 2.3, Driver version 2.15 PASSED TEST 02: SPI_GetCapabilities PASSED TEST 03: SPI_Initialize_Uninitialize PASSED TEST 04: SPI_PowerControl DV_SPI.c (1314): [WARNING] PowerControl (ARM_POWER_LOW) is not supported PASSED ... Test Summary: 56 Tests, 25 Passed, 0 Failed. Test Result: PASSED ``` -------------------------------- ### Connecting to TCP DISCARD Server using Telnet Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SockServer/Embedded/MDK/Board/IMXRT1050-EVKB/Abstract.txt This command initiates a telnet session to the test platform's DISCARD server on port 9. Any data sent to this server will be silently discarded. ```Shell telnet 192.168.1.100 9 ``` -------------------------------- ### Creating CMSIS-Driver Validation Thread with CMSIS-RTOS2 in C Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DriverValidation.txt This code creates a new thread named `cmsis_dv` using the `osThreadNew` function from CMSIS-RTOS2. This thread is responsible for executing all the selected CMSIS-Driver validation tests. It should be called within the `app_main` function before the main application loop. ```C osThreadNew(cmsis_dv, NULL, NULL); ``` -------------------------------- ### Getting Receive Buffer Content - Custom Command Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/MCBSTM32F400/Abstract.txt This command retrieves a specified number of bytes from the receive (Rx) buffer. The example fetches 16 bytes, which might return '????????????????' if the buffer was previously set with '?'. ```Custom Command -> GET BUF RX,16 <- ``` -------------------------------- ### Getting SPI Server Receive Buffer Content (SPI Server Command) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/STM32F429I-DISC1/Abstract.txt Retrieves a specified number of bytes from the receive (Rx) buffer starting from a given offset. This command returns the requested bytes in binary format. ```SPI Server Command GET BUF RX,16 ``` -------------------------------- ### Getting Receive Buffer Content - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command retrieves content from the receive (Rx) buffer. It requires the buffer type (RX) and the number of bytes to retrieve (16 in this example). The server returns the specified number of bytes in binary format. ```Protocol Commands -> GET BUF RX,16 <- ``` -------------------------------- ### Connecting to TCP CHARGEN Server using Telnet Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SockServer/Embedded/MDK/Board/IMXRT1050-EVKB/Abstract.txt This command establishes a telnet connection to the test platform's CHARGEN server on port 19. Upon connection, the server will continuously stream a character generation pattern to the client. ```Shell telnet 192.168.1.100 19 ``` -------------------------------- ### Non-compliant CMSIS-Driver SPI Test Report (Plain Text) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DriverValidation.txt This snippet displays a plain text test report for a CMSIS-Driver SPI, indicating a non-compliant driver. It highlights a FAILED test (TEST 03: SPI_Initialize_Uninitialize) with multiple failed assertions, along with PASSED and WARNING statuses for other tests. The report concludes with an overall FAILED result. ```Plain Text Report CMSIS-Driver SPI Test Report May 6 2020 10:47:11 TEST 01: SPI_GetVersion DV_SPI.c (1023): [INFO] Driver API version 2.3, Driver version 2.15 PASSED TEST 02: SPI_GetCapabilities PASSED TEST 03: SPI_Initialize_Uninitialize DV_SPI.c (1106): [FAILED] DV_SPI.c (1109): [FAILED] DV_SPI.c (1112): [FAILED] FAILED TEST 04: SPI_PowerControl DV_SPI.c (1314): [WARNING] PowerControl (ARM_POWER_LOW) is not supported PASSED ... Test Summary: 56 Tests, 24 Passed, 1 Failed. Test Result: FAILED ``` -------------------------------- ### Getting SPI Server Capabilities - Custom Command Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/MCBSTM32F400/Abstract.txt This command fetches the capabilities of the SPI Server. It returns 32 bytes, providing information such as '03,1F,00008080,03,1000,10000'. ```Custom Command -> GET CAP <- ``` -------------------------------- ### Getting SPI Server Capabilities (SPI Server Command) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/STM32F429I-DISC1/Abstract.txt Fetches the capabilities of the SPI Server. This command returns 32 bytes, providing information such as supported modes, buffer sizes, or other feature flags. ```SPI Server Command GET CAP ``` -------------------------------- ### Performing Bidirectional SPI Transfer - Custom Command Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/MCBSTM32F400/Abstract.txt This command initiates a bidirectional SPI transfer. The example transfers 16 bytes in both directions, with specific timing parameters (10, 0, 100). ```Custom Command -> XFER 16,10,0,100 <-> ``` -------------------------------- ### Debugging CMSIS-Driver PowerControl Assertion (C) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DriverValidation.txt This C code snippet shows an assertion from DV_SPI.c at line 1106. It tests if drv->PowerControl(ARM_POWER_FULL) returns ARM_DRIVER_ERROR when the driver is uninitialized and peripheral is powered-off. This specific assertion is identified as failing in the initial test report, indicating an incorrect return status from the PowerControl function. ```C // Driver is uninitialized and peripheral is powered-off: // Call PowerControl(ARM_POWER_FULL) function and assert that it returned ARM_DRIVER_ERROR status TEST_ASSERT(drv->PowerControl (ARM_POWER_FULL) == ARM_DRIVER_ERROR); ``` -------------------------------- ### Getting Version - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command retrieves the version string of the USART Server. It returns 16 bytes containing the version in 'major.minor.patch' format. ```Protocol Commands -> GET VER <- ``` -------------------------------- ### Getting SPI Server Version (SPI Server Command) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/STM32F429I-DISC1/Abstract.txt Retrieves the current version of the SPI Server. The command returns 16 bytes, typically representing the version number in a string format. ```SPI Server Command GET VER ``` -------------------------------- ### Setting SPI Communication Parameters - Custom Command Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/MCBSTM32F400/Abstract.txt This command configures the SPI communication parameters. The example sets the mode to slave, clock phase 0, clock polarity 0, 8 data bits, MSB first, hardware monitored slave select, and a 2MBps baud rate. ```Custom Command -> SET COM 1,0,8,0,1,2000000 ``` -------------------------------- ### Setting Receive Buffer Content - Custom Command Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/MCBSTM32F400/Abstract.txt This command sets a specific byte in the receive (Rx) buffer. The example sets the byte at offset 0 to the ASCII value of '?' (hex 3F). ```Custom Command -> SET BUF RX,0,3F ``` -------------------------------- ### Getting Version Information - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command requests the version of the USART server. It returns 16 bytes containing a string representation of the version in 'major.minor.patch' format. ```USART Command Protocol -> GET VER <- ``` -------------------------------- ### Getting Counter Value - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command retrieves a counter value from the USART Server. It returns 16 bytes containing the value in decimal notation. ```Protocol Commands -> GET CNT <- ``` -------------------------------- ### Getting Capabilities - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command queries the USART Server for its capabilities. It returns 32 bytes detailing supported modes, data bits, parity, stop bits, flow control, modem lines, and baud rate ranges as a comma-separated string. ```Protocol Commands -> GET CAP <- ``` -------------------------------- ### Getting Transfer Count - Custom Command Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/MCBSTM32F400/Abstract.txt This command retrieves the current transfer count. It returns 16 bytes, typically a decimal representation of the count, such as '16'. ```Custom Command -> GET CNT <- ``` -------------------------------- ### Getting Capabilities - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command queries the USART server for its capabilities. It returns 32 bytes detailing supported modes, data bits, parity, stop bits, flow control, modem lines, and baud rate range. ```USART Command Protocol -> GET CAP <- ``` -------------------------------- ### Getting Count - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command retrieves a count value from the USART server. It returns 16 bytes containing the value in decimal notation. ```USART Command Protocol -> GET CNT <- ``` -------------------------------- ### Setting Receive Buffer Byte - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command sets a specific byte in the receive (Rx) buffer. It takes the buffer type (RX), an offset (0 in this example), and the byte value (3F hex for '?') as parameters. ```Protocol Commands -> SET BUF RX,0,3F ``` -------------------------------- ### Setting Transmit Buffer Content - Custom Command Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/MCBSTM32F400/Abstract.txt This command sets a specific byte in the transmit (Tx) buffer. The example sets the byte at offset 0 to the ASCII value of 'S' (hex 53). ```Custom Command -> SET BUF TX,0,53 ``` -------------------------------- ### Getting SPI Server Version - Custom Command Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/MCBSTM32F400/Abstract.txt This command retrieves the current version of the SPI Server. It returns 16 bytes, typically representing the version number in a format like '1.1.0'. ```Custom Command -> GET VER <- ``` -------------------------------- ### Getting Receive Buffer Content - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command retrieves a specified number of bytes from the receive buffer. It takes the buffer type (RX) and the number of bytes (16) as parameters, returning the content in binary format. ```USART Command Protocol -> GET BUF RX,16 <- ``` -------------------------------- ### Setting Transmit Buffer Byte - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command sets a specific byte in the transmit (Tx) buffer. It takes the buffer type (TX), an offset (0 in this example), and the byte value (53 hex for 'S') as parameters. ```Protocol Commands -> SET BUF TX,0,53 ``` -------------------------------- ### Getting SPI Server Transfer Count (SPI Server Command) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/STM32F429I-DISC1/Abstract.txt Retrieves a count value from the SPI Server, typically related to the number of transfers or a specific internal counter. The command returns 16 bytes. ```SPI Server Command GET CNT ``` -------------------------------- ### Getting Break Signal Status - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command queries the status of the break signal. It returns 1 byte (in hex) indicating the current break signal status (e.g., '1' for active). ```Protocol Commands -> GET BRK <- ``` -------------------------------- ### Getting Modem Line State - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command retrieves the current state of the modem lines. It returns 1 byte (in hex) where each bit represents the state of a specific modem line (e.g., bit 0 for CTS, bit 1 for DSR). ```Protocol Commands -> GET MDM <- ``` -------------------------------- ### Getting Break Status - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command queries the status of the break signal. It returns 1 byte in hexadecimal format indicating the break signal's current status. ```USART Command Protocol -> GET BRK <- ``` -------------------------------- ### Getting Modem Line State - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command retrieves the current state of the modem lines. It returns 1 byte in hexadecimal format, where bits represent the state of individual lines like CTS and DSR. ```USART Command Protocol -> GET MDM <- ``` -------------------------------- ### Connecting to ECHO Server via Telnet Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SockServer/Embedded/MDK/Board/MCB4300/Abstract.txt This command opens a telnet session to the test platform's ECHO server on port 7. Users can then type characters, which the server will echo back. ```Shell telnet 192.168.1.100 7 ``` -------------------------------- ### Initializing Network Services and Application Threads in C Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_WiFi.txt This C code snippet defines the `app_main` function, which serves as the application's main thread. It initializes the network stack, introduces a delay, and then creates new RTOS threads for a Datagram Server, Stream Server, and a Test Assistant, enabling concurrent network operations. ```C // Application main thread static void app_main (void *argument) { netInitialize (); osDelay (500); osThreadNew(DgramServer, NULL, NULL); osThreadNew(StreamServer, NULL, NULL); osThreadNew(TestAssistant, NULL, NULL); } ``` -------------------------------- ### Connecting to TCP CHARGEN Service via Telnet Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SockServer/Embedded/MDK/Board/MCBSTM32F400/Abstract.txt This command initiates a telnet session to the test platform's CHARGEN service on port 19. Upon connection, the server streams a continuous pattern of characters to the client, demonstrating the character generation functionality. ```Shell telnet 192.168.1.100 19 ``` -------------------------------- ### Connecting to DISCARD Server via Telnet Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SockServer/Embedded/MDK/Board/MCB4300/Abstract.txt This command initiates a telnet session to the test platform's DISCARD server on port 9. Any characters sent to this server will be silently discarded. ```Shell telnet 192.168.1.100 9 ``` -------------------------------- ### Connecting to CHARGEN Server via Telnet Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SockServer/Embedded/MDK/Board/MCB4300/Abstract.txt This command establishes a telnet connection to the test platform's CHARGEN server on port 19. The server will continuously stream a character pattern to the client. ```Shell telnet 192.168.1.100 19 ``` -------------------------------- ### Connecting to SockServer via Telnet (CMD) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_WiFi.txt This command initiates a Telnet connection from a Windows Command Prompt to the SockServer. It is used to monitor received and sent data, aiding in the diagnosis of driver problems related to socket communication. ```Shell c:\>telnet sockserver ``` -------------------------------- ### Connecting to TCP ECHO Service via Telnet Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SockServer/Embedded/MDK/Board/MCBSTM32F400/Abstract.txt This command opens a telnet session to the test platform's ECHO service on port 7. Users can type characters, and the server will echo them back, resulting in duplicate characters appearing in the telnet client. ```Shell telnet 192.168.1.100 7 ``` -------------------------------- ### Connecting to TCP DISCARD Service via Telnet Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SockServer/Embedded/MDK/Board/MCBSTM32F400/Abstract.txt This command establishes a telnet session to the test platform's DISCARD service on port 9. Any characters sent by the client to this service will be received and immediately discarded by the server, providing a simple sink for data. ```Shell telnet 192.168.1.100 9 ``` -------------------------------- ### Initializing SPI Server Application Main Thread (C) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_SPI.txt This C code snippet defines the `app_main` function, which serves as the application's main thread. It initializes the SPI Server by calling `SPI_Server_Start()` and then enters an infinite loop to keep the application running. This function is intended to replace the default `app_main` in a CMSIS-RTOS2 'main' function template when porting the SPI Server to a new target device. ```C #include "SPI_Server.h" /*---------------------------------------------------------------------------- * Application main thread *---------------------------------------------------------------------------*/ __NO_RETURN static void app_main (void *argument) { (void)argument; SPI_Server_Start(); for (;;) {} } ``` -------------------------------- ### Defining Global Stack and Heap Sizes in Assembly Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_WiFi.txt This assembly snippet defines the global stack and heap sizes for the embedded system. `Stack_Size` is set to 1024 bytes (0x400) and `Heap_Size` to 6144 bytes (0x1800). These definitions are typically located in the device's startup file and are essential for overall memory allocation. ```Assembly Stack_Size EQU 0x00000400 Heap_Size EQU 0x00001800 ``` -------------------------------- ### Configuring Network Core Hostname and Memory Pool (C) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_WiFi.txt This C code snippet defines the network host name as 'SockServer' and sets the memory pool size for the network stack. These configurations are typically found in Net_Config.c and are crucial for initializing the network core in embedded systems. ```C #define NET_HOST_NAME "SockServer" #define NET_MEM_POOL_SIZE 16384 ``` -------------------------------- ### Initializing CMSIS-RTOS2 USART Server Main Function (C) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_USART.txt This C code snippet defines the `app_main` function, which serves as the application's main thread in a CMSIS-RTOS2 environment. It initializes the USART Server by calling `USART_Server_Start()` and then enters an infinite loop, typical for embedded systems to keep the RTOS scheduler running. It requires the `USART_Server.h` header. ```C #include "USART_Server.h" /*---------------------------------------------------------------------------- * Application main thread *---------------------------------------------------------------------------*/ __NO_RETURN static void app_main (void *argument) { (void)argument; USART_Server_Start(); for (;;) {} } ``` -------------------------------- ### Configuring Ethernet MAC Address (C) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_WiFi.txt This C code snippet defines the MAC address for the Ethernet interface (ETH0). Setting a unique MAC address in Net_Config_ETH0.h is essential to prevent network collisions when deploying the SockServer application on different target devices. ```C #define ETH0_MAC_ADDR "1E-30-6C-A2-45-5A" ``` -------------------------------- ### Configuring TCP Socket Numbers (C) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_WiFi.txt This C code snippet defines the total number of TCP sockets (TCP_NUM_SOCKS) available for the embedded SockServer application. This configuration in Net_Config_TCP.h is critical for managing TCP-based communication. ```C #define TCP_NUM_SOCKS 9 ``` -------------------------------- ### Configuring BSD Socket Numbers (C) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_WiFi.txt This C code snippet configures the total number of BSD sockets (BSD_NUM_SOCKS) and the number of server-specific BSD sockets (BSD_SERVER_SOCKS). These definitions in Net_Config_BSD.h determine the maximum concurrent socket connections the embedded SockServer can handle. ```C #define BSD_NUM_SOCKS 8 #define BSD_SERVER_SOCKS 4 ``` -------------------------------- ### Configuring UDP Socket Numbers (C) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_WiFi.txt This C code snippet defines the total number of UDP sockets (UDP_NUM_SOCKS) available for the embedded SockServer application. This configuration in Net_Config_UDP.h is important for managing UDP-based communication. ```C #define UDP_NUM_SOCKS 10 ``` -------------------------------- ### Performing Bidirectional SPI Data Transfer (SPI Server Command) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/STM32F429I-DISC1/Abstract.txt Initiates a bidirectional data transfer over SPI. The command specifies the number of bytes to transfer, along with other transfer-specific parameters like timeout or delay. ```SPI Server Command XFER 16,10,0,100 ``` -------------------------------- ### HTML Comment with writeFooter JavaScript Call - HTML Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/templates/footer.html This HTML comment contains an embedded JavaScript function call, `writeFooter.call(this);`. It suggests a mechanism for dynamically injecting or executing client-side logic, possibly for rendering a page footer or other common UI elements. The use of `this` implies the function might be a method or expects a specific execution context. ```HTML ``` -------------------------------- ### Sending Data - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command initiates a data transfer operation specifically for sending data. It specifies the transfer direction (1 for send), the number of bytes to transfer (16), an offset (0), and a timeout (100 milliseconds). The client must provide the specified number of bytes to send. ```Protocol Commands -> XFER 1,16,0,100 -> ``` -------------------------------- ### Configuring SPI Communication Parameters (SPI Server Command) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/STM32F429I-DISC1/Abstract.txt Configures the SPI communication parameters including mode (slave/master), clock phase, clock polarity, data bits, bit order (MSB/LSB first), slave select behavior, and communication speed. ```SPI Server Command SET COM 1,0,8,0,1,2000000 ``` -------------------------------- ### Receiving Data - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command initiates a data transfer operation specifically for receiving data. It specifies the transfer direction (0 for receive), the number of bytes to transfer (16), an offset (0), and a timeout (100 milliseconds). The server returns the specified number of bytes. ```Protocol Commands -> XFER 0,16,0,100 <- ``` -------------------------------- ### Setting Communication Parameters - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command configures the USART communication parameters. It takes parameters for mode (0 for asynchronous), data bits (8), parity (0 for none), stop bits (0 for 1 stop bit), flow control (0 for none), and baud rate (115200). The two '0's before the baud rate are likely for modem line control or reserved fields. ```Protocol Commands -> SET COM 0,8,0,0,0,0,0,115200 ``` -------------------------------- ### Configuring RTX Thread Stack Size in C Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_WiFi.txt This C preprocessor directive sets the default stack size for RTOS threads to 400 bytes. This configuration is typically found in `RTX_Config.h` and is crucial for allocating sufficient memory for thread execution, preventing stack overflows. ```C #define OS_STACK_SIZE 400 ``` -------------------------------- ### Receiving Data - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command initiates a data reception operation. The parameters specify the transfer direction (0 for receive), the number of bytes (16), an offset (0), and a timeout (100 ms). It returns the received bytes. ```USART Command Protocol -> XFER 0,16,0,100 <- ``` -------------------------------- ### Controlling Modem Line State - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command controls the state of a modem line. It takes a modem line mask (01 for RTS), a delay before activation (10 ms), and a duration for activation (50 ms) as parameters. The line will be activated for the specified duration after the delay, then deactivated. ```Protocol Commands -> SET MDM 01,10,50 ``` -------------------------------- ### Sending Data - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command initiates a data transmission operation. The parameters specify the transfer direction (1 for send), the number of bytes (16), an offset (0), and a timeout (100 ms). It expects 16 bytes to be sent. ```USART Command Protocol -> XFER 1,16,0,100 -> ``` -------------------------------- ### Setting SPI Server Receive Buffer (SPI Server Command) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/STM32F429I-DISC1/Abstract.txt Sets a specific byte in the receive (Rx) buffer. The command takes the buffer type (RX), an offset, and the hexadecimal value of the byte to set (e.g., 3F for '?'). ```SPI Server Command SET BUF RX,0,3F ``` -------------------------------- ### Bidirectional Data Transfer - USART Server - Protocol Commands Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/MCBSTM32F400/Abstract.txt This command initiates a bidirectional data transfer, applicable only in synchronous mode. It specifies the transfer direction (2 for bidirectional), the number of bytes to transfer (16), an offset (0), and a timeout (100 milliseconds). Both client and server exchange the specified number of bytes. ```Protocol Commands -> XFER 2,16,0,100 <-> ``` -------------------------------- ### Setting Modem Line State - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command controls the state of a modem line, specifically activating RTS. The parameters specify the modem line mask (01 for RTS), activation delay (10 ms), and active duration (50 ms). ```USART Command Protocol -> SET MDM 01,10,50 ``` -------------------------------- ### Setting Communication Parameters - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command configures the USART communication parameters. The parameters specify asynchronous mode (0), 8 data bits (8), no parity (0), 1 stop bit (0), no flow control (0), and a baud rate of 115200. ```USART Command Protocol -> SET COM 0,8,0,0,0,0,0,115200 ``` -------------------------------- ### Disabling Telnet Server Authentication (C) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/DoxyGen/src/DV_WiFi.txt This C code snippet disables authentication for the Telnet server by setting TELNET_SERVER_AUTH_ENABLE to 0. This configuration in Net_Config_Telnet_Server.h allows direct access to the Telnet service without requiring credentials, useful for debugging. ```C #define TELNET_SERVER_AUTH_ENABLE 0 ``` -------------------------------- ### Setting SPI Server Transmit Buffer (SPI Server Command) Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/SPI_Server/Board/STM32F429I-DISC1/Abstract.txt Sets a specific byte in the transmit (Tx) buffer. The command takes the buffer type (TX), an offset, and the hexadecimal value of the byte to set (e.g., 53 for 'S'). ```SPI Server Command SET BUF TX,0,53 ``` -------------------------------- ### Transferring Data Bidirectionally - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command initiates a bidirectional data transfer, typically used in synchronous mode. The parameters specify the transfer direction (2 for bidirectional), the number of bytes (16), an offset (0), and a timeout (100 ms). It involves both sending and receiving 16 bytes. ```USART Command Protocol -> XFER 2,16,0,100 <-> ``` -------------------------------- ### Setting Receive Buffer Content - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command sets a specific byte in the receive buffer. The parameters specify the buffer type (RX), the offset (0), and the byte value in hexadecimal (3F for '?'). ```USART Command Protocol -> SET BUF RX,0,3F ``` -------------------------------- ### Setting Transmit Buffer Content - USART Command Protocol Source: https://github.com/arm-software/cmsis-driver_validation/blob/main/Tools/USART_Server/Board/STM32F429I-DISC1/Abstract.txt This command sets a specific byte in the transmit buffer. The parameters specify the buffer type (TX), the offset (0), and the byte value in hexadecimal (53 for 'S'). ```USART Command Protocol -> SET BUF TX,0,53 ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.