[{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/app/","section":"Apps","summary":"","title":"Apps","type":"app"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/c/","section":"Tags","summary":"","title":"C","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/embedded-systems/","section":"Tags","summary":"","title":"Embedded Systems","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/networking/","section":"Tags","summary":"","title":"Networking","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/rtos/","section":"Tags","summary":"","title":"RTOS","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/socket-programming/","section":"Tags","summary":"","title":"Socket Programming","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/udp/","section":"Tags","summary":"","title":"UDP","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/vxworks/","section":"Tags","summary":"","title":"VxWorks","type":"tags"},{"content":" VxWorks UDP Socket Programming: Design, Pitfalls and Refactoring\nUDP (User Datagram Protocol) is a lightweight, connectionless transport protocol that operates directly above IP. Its minimal protocol overhead makes it well suited to real-time control, telemetry, diagnostics, and low-latency data exchange in embedded VxWorks systems.\nHowever, production-quality UDP code requires more than simply wrapping socket(), sendto(), and recvfrom(). Correct handling of datagram boundaries, socket ownership, timeout conversion, peer addresses, error paths, and API semantics is essential for predictable behavior.\nThis guide reviews a typical VxWorks UDP implementation, identifies its primary design problems, and presents a refactored implementation with clearer ownership and error semantics.\n🔌 UDP Socket Lifecycle and Execution Model # The fundamental UDP server and client lifecycles are similar, but binding behavior differs.\nLifecycle Phase UDP Server UDP Client Creation socket(AF_INET, SOCK_DGRAM, 0) socket(AF_INET, SOCK_DGRAM, 0) Binding Explicit bind() to local IP/port Usually optional Transfer recvfrom() / sendto() sendto() / recvfrom() Peer selection Per-datagram source/destination Destination supplied to sendto() Teardown close() close() A UDP socket does not establish a persistent transport connection. Each datagram is independently addressed, transmitted, and received.\nFor a server, bind() normally establishes the local endpoint. A client can often allow the kernel to select an ephemeral local port automatically when the first outbound datagram is transmitted.\n⚠️ Code Review: Critical Problems in the Original Design # Several issues in the original implementation can produce incorrect behavior or poor network performance.\nInverted net_bind() Success Test # The original net_bind() implementation returned 1 when bind() succeeded, while the application interpreted 0 as success.\nThat creates an inverted result:\nif (net_bind(...) == 0) { printf(\u0026#34;success\u0026#34;); } The application therefore reports success when the operation actually fails.\nA conventional C API should return 0 for success and a negative value for failure, or consistently use named status constants such as UDP_OK and UDP_ERROR.\nUDP Fragmentation Is Not TCP-Style Segmentation # A common mistake is to treat a large UDP payload like a TCP byte stream and split it into arbitrary chunks.\nThe original implementation attempted to transmit datagrams as large as 65,507 bytes. Although this is close to the theoretical maximum UDP payload over IPv4, it is unsuitable for normal Ethernet networks.\nWith a standard 1,500-byte Ethernet MTU, an IPv4 UDP datagram should normally be limited to:\n1500 - 20-byte IPv4 header - 8-byte UDP header = 1472 bytes A larger datagram can be fragmented at the IP layer. Fragmentation increases loss sensitivity because losing one fragment causes the complete UDP datagram to become unusable.\nFor latency-sensitive embedded systems, keeping application datagrams below the path MTU is generally preferable.\nIncorrect timeval Construction # A timeout implementation such as:\ntv.tv_usec = ms * 1000; can generate an invalid timeval when the supplied timeout is 1,000 ms or greater.\nThe correct conversion separates whole seconds from the remaining milliseconds:\ntv.tv_sec = timeout_ms / 1000; tv.tv_usec = (timeout_ms % 1000) * 1000; This guarantees that tv_usec remains below one million.\nOverwriting Socket Context with Peer Information # Using the same address field for both local/remote configuration and recvfrom() output creates hidden state mutation.\nThe address returned by recvfrom() describes the sender of the received datagram, not the configured destination of future transmissions.\nThe refactored implementation therefore keeps:\nlocal_addr for the socket\u0026rsquo;s local endpoint. remote_addr for the default transmission destination. src_addr as an explicit output parameter for the sender of an incoming datagram. This separation makes the API easier to reason about and safer for long-running tasks.\n🧱 Refactored UDP API # The following interface separates socket state from per-packet addressing and provides explicit status codes.\nudp.h # #ifndef _UDP_H #define _UDP_H #include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;sockLib.h\u0026gt; #include \u0026lt;inetLib.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;string.h\u0026gt; #include \u0026lt;selectLib.h\u0026gt; #define UDP_MAX_PAYLOAD 1472 #define UDP_OK 0 #define UDP_ERROR -1 #define UDP_TIMEOUT -2 typedef struct { int sd; struct sockaddr_in local_addr; struct sockaddr_in remote_addr; } UdpData; int udp_init(UdpData *data, const char *ipAddr, int port); int net_bind(UdpData *data, const char *ipAddr, int port); int udp_send(const UdpData *data, const void *buff, size_t len); int udp_recv(UdpData *data, void *buff, size_t max_len, int timeout_ms); int udp_sendto(const UdpData *data, const void *buff, size_t len, const struct sockaddr_in *dest_addr); int udp_recvfrom(const UdpData *data, void *buff, size_t max_len, struct sockaddr_in *src_addr, int timeout_ms); void udp_close(UdpData *data); #endif /* _UDP_H */ UDP_MAX_PAYLOAD is intentionally set to 1,472 bytes for a conventional Ethernet/IPv4 path. Applications operating across networks with different MTUs should derive the effective payload limit from the actual path rather than treating 1,472 bytes as a universal maximum.\n⚙️ UDP Socket Implementation # Socket Initialization # The initialization routine creates the socket, configures address reuse, and stores the default remote endpoint.\n#include \u0026#34;udp.h\u0026#34; int udp_init(UdpData *data, const char *ipAddr, int port) { int sd; int optval = 1; if (data == NULL) return UDP_ERROR; memset(data, 0, sizeof(UdpData)); data-\u0026gt;sd = -1; sd = socket(AF_INET, SOCK_DGRAM, 0); if (sd \u0026lt; 0) { perror(\u0026#34;udp_init: socket creation failed\u0026#34;); return UDP_ERROR; } if (setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, (char *)\u0026amp;optval, sizeof(optval)) \u0026lt; 0) { perror(\u0026#34;udp_init: setsockopt SO_REUSEADDR failed\u0026#34;); close(sd); return UDP_ERROR; } data-\u0026gt;sd = sd; memset(\u0026amp;data-\u0026gt;remote_addr, 0, sizeof(data-\u0026gt;remote_addr)); data-\u0026gt;remote_addr.sin_family = AF_INET; data-\u0026gt;remote_addr.sin_port = htons((u_short)port); if (ipAddr != NULL \u0026amp;\u0026amp; strlen(ipAddr) \u0026gt; 0) { data-\u0026gt;remote_addr.sin_addr.s_addr = inet_addr((char *)ipAddr); } else { data-\u0026gt;remote_addr.sin_addr.s_addr = htonl(INADDR_ANY); } return UDP_OK; } Initializing sd to -1 immediately after clearing the structure makes the socket lifecycle explicit and prevents accidental attempts to close or use descriptor zero as a valid socket.\nBinding the Local Endpoint # net_bind() configures the local address independently from the remote destination.\nint net_bind(UdpData *data, const char *ipAddr, int port) { if (data == NULL || data-\u0026gt;sd \u0026lt; 0) return UDP_ERROR; memset(\u0026amp;data-\u0026gt;local_addr, 0, sizeof(data-\u0026gt;local_addr)); data-\u0026gt;local_addr.sin_family = AF_INET; data-\u0026gt;local_addr.sin_port = htons((u_short)port); if (ipAddr == NULL || strlen(ipAddr) == 0) { data-\u0026gt;local_addr.sin_addr.s_addr = htonl(INADDR_ANY); } else { data-\u0026gt;local_addr.sin_addr.s_addr = inet_addr((char *)ipAddr); if (data-\u0026gt;local_addr.sin_addr.s_addr == INADDR_NONE) return UDP_ERROR; } if (bind(data-\u0026gt;sd, (struct sockaddr *)\u0026amp;data-\u0026gt;local_addr, sizeof(data-\u0026gt;local_addr)) \u0026lt; 0) { perror(\u0026#34;net_bind: bind failed\u0026#34;); return UDP_ERROR; } return UDP_OK; } The function now follows the conventional contract:\nUDP_OK = successful bind UDP_ERROR = failure This eliminates ambiguity at the application layer.\n📤 UDP Transmission # The convenience udp_send() function uses the configured remote_addr.\nint udp_send(const UdpData *data, const void *buff, size_t len) { if (data == NULL) return UDP_ERROR; return udp_sendto(data, buff, len, \u0026amp;data-\u0026gt;remote_addr); } The lower-level udp_sendto() function accepts an explicit destination.\nint udp_sendto(const UdpData *data, const void *buff, size_t len, const struct sockaddr_in *dest_addr) { int bytes_sent; if (data == NULL || data-\u0026gt;sd \u0026lt; 0 || buff == NULL || dest_addr == NULL) { return UDP_ERROR; } if (len \u0026gt; UDP_MAX_PAYLOAD) { printf(\u0026#34;udp_sendto warning: payload size (%g KB) \u0026#34; \u0026#34;exceeds recommended MTU payload (%d bytes)\\n\u0026#34;, (double)len / 1024.0, UDP_MAX_PAYLOAD); } bytes_sent = sendto( data-\u0026gt;sd, (const char *)buff, len, 0, (const struct sockaddr *)dest_addr, sizeof(struct sockaddr_in)); if (bytes_sent \u0026lt; 0) { perror(\u0026#34;udp_sendto: sendto failed\u0026#34;); return UDP_ERROR; } return bytes_sent; } The function deliberately does not fragment a large application buffer into multiple UDP datagrams.\nIf an application needs to transmit data larger than the safe datagram size, fragmentation should be implemented at the application protocol layer, where sequence numbers, message identifiers, lengths, and retransmission policy can be explicitly controlled.\n📥 UDP Reception and Timeout Handling # The receive path uses select() to implement an optional millisecond timeout before calling recvfrom().\nint udp_recvfrom(const UdpData *data, void *buff, size_t max_len, struct sockaddr_in *src_addr, int timeout_ms) { fd_set readfds; struct timeval tv; struct timeval *ptimeval = NULL; int select_ret; socklen_t addr_len = sizeof(struct sockaddr_in); int bytes_recvd; if (data == NULL || data-\u0026gt;sd \u0026lt; 0 || buff == NULL || src_addr == NULL) { return UDP_ERROR; } FD_ZERO(\u0026amp;readfds); FD_SET(data-\u0026gt;sd, \u0026amp;readfds); if (timeout_ms \u0026gt;= 0) { tv.tv_sec = timeout_ms / 1000; tv.tv_usec = (timeout_ms % 1000) * 1000; ptimeval = \u0026amp;tv; } select_ret = select( data-\u0026gt;sd + 1, \u0026amp;readfds, NULL, NULL, ptimeval); if (select_ret \u0026lt; 0) { perror(\u0026#34;udp_recvfrom: select error\u0026#34;); return UDP_ERROR; } if (select_ret == 0) return UDP_TIMEOUT; if (FD_ISSET(data-\u0026gt;sd, \u0026amp;readfds)) { bytes_recvd = recvfrom( data-\u0026gt;sd, (char *)buff, max_len, 0, (struct sockaddr *)src_addr, \u0026amp;addr_len); if (bytes_recvd \u0026lt; 0) { perror(\u0026#34;udp_recvfrom: recvfrom error\u0026#34;); return UDP_ERROR; } return bytes_recvd; } return UDP_ERROR; } The timeout semantics are straightforward:\ntimeout_ms Behavior \u0026lt; 0 Wait indefinitely 0 Poll without blocking \u0026gt; 0 Wait for the specified number of milliseconds No packet before timeout Return UDP_TIMEOUT The sender address is returned through src_addr, preventing the receive operation from modifying the persistent socket context.\nConvenience Receive Function # For applications that do not need the sender address, udp_recv() can hide that implementation detail.\nint udp_recv(UdpData *data, void *buff, size_t max_len, int timeout_ms) { struct sockaddr_in peer_addr; return udp_recvfrom( data, buff, max_len, \u0026amp;peer_addr, timeout_ms); } This preserves a simple API while maintaining the safer internal separation between socket configuration and per-packet metadata.\n🧹 Socket Cleanup # The close operation should be idempotent with respect to the socket descriptor state.\nvoid udp_close(UdpData *data) { if (data != NULL \u0026amp;\u0026amp; data-\u0026gt;sd \u0026gt;= 0) { close(data-\u0026gt;sd); data-\u0026gt;sd = -1; } } Resetting sd to -1 after close() prevents accidental reuse of a stale descriptor.\n🖥️ Corrected VxWorks Server Integration # The application layer should now test UDP_OK rather than relying on an inverted Boolean convention.\n#include \u0026#34;udp.h\u0026#34; void udp_server_task(void) { UdpData server_ctx; char rx_buffer[1024]; struct sockaddr_in client_addr; int status; int port = 2300; if (udp_init(\u0026amp;server_ctx, NULL, port) != UDP_OK) { printf(\u0026#34;Server init failed\\n\u0026#34;); return; } if (net_bind(\u0026amp;server_ctx, NULL, port) != UDP_OK) { printf(\u0026#34;Server bind failed\\n\u0026#34;); udp_close(\u0026amp;server_ctx); return; } printf(\u0026#34;UDP Server listening on port %d...\\n\u0026#34;, port); while (1) { status = udp_recvfrom( \u0026amp;server_ctx, rx_buffer, sizeof(rx_buffer) - 1, \u0026amp;client_addr, 1000); if (status \u0026gt; 0) { rx_buffer[status] = \u0026#39;\\0\u0026#39;; printf(\u0026#34;Received from %s:%d -\u0026gt; %s\\n\u0026#34;, inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port), rx_buffer); /* Echo reply */ udp_sendto( \u0026amp;server_ctx, \u0026#34;ACK\u0026#34;, 3, \u0026amp;client_addr); } else if (status == UDP_TIMEOUT) { /* Periodic task activity */ taskDelay(sysClkRateGet() / 10); } else { printf(\u0026#34;Receive error detected, \u0026#34; \u0026#34;exiting loop\\n\u0026#34;); break; } } udp_close(\u0026amp;server_ctx); } The resulting server has a clean lifecycle:\nudp_init() | v net_bind() | v udp_recvfrom() | +---- UDP_TIMEOUT ----\u0026gt; periodic processing | +---- packet ---------\u0026gt; application processing | | | v | udp_sendto() | +---- error ----------\u0026gt; cleanup | v udp_close() 📐 Production Design Considerations # Keep Datagram Size Explicit # The 1,472-byte recommendation assumes standard Ethernet MTU and IPv4 headers. It is not a universal UDP limit.\nIf the system operates over VLANs, tunnels, VPNs, jumbo frames, cellular links, or other encapsulations, the effective path MTU can differ.\nFor tightly controlled embedded networks, defining an application-specific maximum datagram size is often preferable to relying on IP fragmentation.\nTreat UDP Delivery as Unreliable # UDP provides no built-in guarantee of:\ndelivery, ordering, duplicate suppression, retransmission, congestion control, or end-to-end integrity beyond the UDP checksum mechanism. If an application requires reliability, those semantics must be implemented above UDP or supplied by another transport protocol.\nAvoid Hidden Mutable State # A reusable UDP context should contain relatively stable socket configuration. Per-message state should be supplied as function arguments or returned through output parameters.\nThis is particularly important when the same socket is accessed by multiple VxWorks tasks. If concurrent access is required, the application should also establish explicit ownership or synchronization rules around socket operations and shared buffers.\nValidate Application Payloads # For binary protocols, never treat received data as a C string unless the application protocol explicitly defines it as such.\nThe server example reserves one byte:\nsizeof(rx_buffer) - 1 and explicitly appends:\nrx_buffer[status] = \u0026#39;\\0\u0026#39;; This is appropriate for text payloads but should not be applied to arbitrary binary data.\n📝 Key Takeaways # A robust VxWorks UDP implementation should follow several core principles:\nReturn a consistent status convention such as UDP_OK == 0. Keep UDP datagrams within an appropriate path-MTU budget. Do not treat UDP like a TCP byte stream. Convert millisecond timeouts into valid timeval fields. Keep local, remote, and received-peer addresses separate. Avoid modifying persistent socket context inside recvfrom(). Return explicit timeout and error states to the application. Reset socket descriptors after close(). Implement application-level fragmentation and reliability only when the protocol requires them. Define task ownership and synchronization when sockets are shared across VxWorks tasks. The resulting design is simpler to test, easier to maintain, and substantially safer for long-running embedded networking workloads than a UDP wrapper that mixes socket state, peer state, packet handling, and application semantics.\n","date":"2026-08-25","externalUrl":null,"permalink":"/app/vxworks-udp-socket-programming-design-pitfalls-and-refactoring/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks UDP Socket Programming: Design, Pitfalls and Refactoring\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eUDP (User Datagram Protocol) is a lightweight, connectionless transport protocol that operates directly above IP. Its minimal protocol overhead makes it well suited to real-time control, telemetry, diagnostics, and low-latency data exchange in embedded VxWorks systems.\u003c/p\u003e","title":"VxWorks UDP Socket Programming: Design, Pitfalls and Refactoring","type":"app"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/arm/","section":"Tags","summary":"","title":"ARM","type":"tags"},{"content":" Boot VxWorks 7 with U-Boot: DTB, mkimage, XIP and Build Guide\nIntegrating VxWorks 7 with U-Boot requires careful coordination between the bootloader, VxWorks image format, Device Tree Blob (DTB) handling, target memory layout, and early CPU initialization.\nVxWorks 7 uses the Flattened Device Tree (FDT) model to separate hardware description from the kernel image. U-Boot can therefore boot VxWorks using either a standalone DTB or an embedded DTB, with important differences in how boot arguments, image generation, and execution commands are handled.\nThis guide covers the complete workflow for ARM and PowerPC targets, including mkimage header generation, compressed images, Execute-In-Place (XIP) Flash configurations, and Wind River project builds.\n🧩 VxWorks 7 and U-Boot DTB Architecture # VxWorks 7 uses FDT/DTB files compliant with the ePAPR specification to describe board hardware. In a U-Boot deployment, the DTB can either remain as a separate boot artifact or be incorporated directly into the VxWorks image.\nStandalone DTB vs. Embedded DTB # Parameter Standalone DTB (uVxWorks) Embedded DTB (vxWorks.bin) Build target prj build -target uVxWorks prj build -target vxWorks.bin U-Boot command bootm \u0026lt;kernel_addr\u0026gt; - \u0026lt;dtb_addr\u0026gt; go \u0026lt;kernel_addr\u0026gt; DTB location Separate RAM region Embedded in kernel image bootargs override Supported through U-Boot/DTB /chosen handling Not available through the U-Boot environment INCLUDE_STANDALONE_DTB Optional Required The standalone DTB model is generally more flexible during board bring-up because U-Boot can load and modify the DTB independently from the kernel image.\nThe embedded DTB model simplifies deployment by producing a self-contained image, but it removes the ability to dynamically override the DTB\u0026rsquo;s boot arguments through the U-Boot environment.\n🛠️ Building a U-Boot-Compatible VxWorks Image # U-Boot can consume VxWorks kernel binaries wrapped with its image header. The typical workflow is to convert the VxWorks ELF output into a raw binary and then encapsulate it with mkimage.\nConvert ELF to Raw Binary # The default VxWorks build produces an ELF image. Use the appropriate target cross-toolchain objcopy to generate a raw binary.\n# ARM objcopyarm -O binary vxWorks vxWorks.bin # PowerPC objcopyppc -O binary vxWorks vxWorks.bin The resulting vxWorks.bin contains the binary payload without the ELF container metadata.\nAdd the U-Boot Image Header # Use mkimage to generate the U-Boot-compatible image. The load address and entry point must match the target board\u0026rsquo;s VxWorks memory configuration, such as RAM_LOW_ADRS.\n# ARM mkimage -A arm -O vxworks -T kernel -C none \\ -a 0x80100000 -e 0x80100000 \\ -n vxworks -d vxWorks.bin vxWorks.uboot # PowerPC mkimage -A ppc -O vxworks -T kernel -C none \\ -a 0x00100000 -e 0x00100000 \\ -n vxworks -d vxWorks.bin vxWorks.uboot The generated image contains the VxWorks payload together with the U-Boot metadata required by bootm.\nCompressing the Kernel # For network boot or storage-constrained deployments, the raw VxWorks image can be compressed before being wrapped.\ngzip --best vxWorks.bin mkimage -A ppc -O vxworks -T kernel -C gzip \\ -a 0x00100000 -e 0x00100000 \\ -n vxworks -d vxWorks.bin.gz vxWorks.uboot With -C gzip, U-Boot knows that the payload requires decompression during the bootm process.\n⚡ Execute-In-Place from NOR Flash # VxWorks 7 can also execute directly from non-volatile NOR Flash rather than copying the entire kernel into RAM.\nTwo common approaches are available:\nUse go with an image containing an embedded DTB. Use bootm with a U-Boot header reserved in the early VxWorks image layout. XIP Using the go Command # With an embedded DTB, the VxWorks image can be placed at its Flash execution address and started directly:\nU-Boot# go 0x\u0026lt;flash_addr\u0026gt; This approach jumps directly to the image\u0026rsquo;s execution address rather than invoking the normal U-Boot image-loading and decompression flow.\nXIP Using bootm # When bootm is required for an XIP image, the U-Boot header occupies the beginning of the image. VxWorks early initialization must therefore reserve space for it.\nFor example, sysALib.s can reserve 64 bytes:\nFUNC_LABEL(_sysInit) FUNC_BEGIN(sysInit) #ifdef UBOOT_XIP .fill 16, 4, 0xff /* 16 x 4 bytes = 64-byte U-Boot header */ #endif The corresponding image can then be generated with the XIP option:\nmkimage -x -A arm -O vxworks -T kernel -C none \\ -a 0x80100000 -e 0x80100000 \\ -n vxworks -d vxWorks.bin vxWorks.uboot The image can subsequently be started from the U-Boot console:\nU-Boot# bootm 0x80100000 The exact address must match the board\u0026rsquo;s Flash mapping and VxWorks startup configuration.\n🔧 Building VxWorks Images with Wind River CLI # Wind River project tooling can generate images appropriate for either standalone or embedded DTB deployment.\nFirst add the required components:\nprj vip component add INCLUDE_STANDALONE_DTB prj vip component add INCLUDE_STANDALONE_SYM_TBL For a standalone DTB image:\nprj build -target uVxWorks For an embedded DTB binary:\nprj build -target vxWorks.bin The choice of target should match the intended U-Boot boot protocol. A standalone DTB deployment requires U-Boot to provide the DTB address separately, while an embedded configuration packages the hardware description with the VxWorks image.\n🌐 Configuring U-Boot Networking # For network-based deployment, configure the Ethernet and TFTP parameters in the U-Boot environment:\nU-Boot# setenv ethaddr 00:04:9f:ef:01:01 U-Boot# setenv ipaddr 192.168.10.5 U-Boot# setenv serverip 192.168.10.2 U-Boot# setenv netmask 255.255.255.0 U-Boot# setenv gatewayip 192.168.10.1 U-Boot# saveenv These parameters allow U-Boot to retrieve VxWorks images from a TFTP server before transferring control to the kernel.\n🚀 U-Boot Boot Protocols # Standalone DTB with bootm # Load the VxWorks image and DTB into separate RAM regions:\nU-Boot# tftp 0x80300000 uVxWorks U-Boot# tftp 0x80e00000 your-board.dtb If the VxWorks configuration supports U-Boot-provided boot arguments, the environment can be configured before boot:\nU-Boot# setenv bootargs \u0026#34;cpsw(0,0)host:vxWorks h=192.168.10.2 e=192.168.10.5:ffffff00 g=192.168.10.1 u=vxworks pw=vxworks f=0x0\u0026#34; Start VxWorks and pass the DTB address as the third bootm argument:\nU-Boot# bootm 0x80300000 - 0x80e00000 The resulting boot sequence separates the kernel and hardware description, allowing the DTB to be updated independently.\nEmbedded DTB with go # For an image containing the DTB internally:\nU-Boot# tftp 0x80300000 vxWorks.bin U-Boot# go 0x80300000 Because the DTB is already embedded, U-Boot does not provide a separate DTB address. Likewise, boot arguments configured through the U-Boot environment cannot be used to dynamically replace the embedded boot configuration.\n📋 Deployment Model Comparison # Deployment Model Image DTB Primary Command Boot Argument Flexibility Standalone DTB uVxWorks Separate bootm High Embedded DTB vxWorks.bin Embedded go Limited XIP Embedded Flash-resident image Embedded go Limited XIP U-Boot Image U-Boot-wrapped image Embedded/board-specific bootm Depends on image configuration The standalone DTB + bootm approach is generally preferable during board development because the kernel and hardware description can be updated independently.\nFor fixed production configurations where the image and hardware description are tightly coupled, an embedded DTB can simplify deployment and reduce the number of boot artifacts.\n🧠 Key Implementation Considerations # The most important integration points are the image format, memory addresses, DTB placement, and boot command.\nThe U-Boot load and entry addresses passed to mkimage must correspond to the VxWorks board configuration. Incorrect address selection can result in immediate boot failures or execution from an invalid memory region.\nDTB handling is equally important. With a standalone DTB, U-Boot can pass a dynamically loaded hardware description to VxWorks and potentially modify /chosen information. With an embedded DTB, that flexibility is intentionally removed.\nFor XIP deployments, the Flash execution address and early startup layout must also account for the U-Boot header when bootm is used. Reserving the header space in the VxWorks assembly startup path prevents the bootloader metadata from overwriting critical initialization code or vector data.\nIn practice, the cleanest architecture is to select the DTB strategy first, align the VxWorks build target with that strategy, verify the target memory map, and only then generate the final U-Boot image with mkimage.\n","date":"2026-08-25","externalUrl":null,"permalink":"/training/boot-vxworks-7-with-u-boot-dtb-mkimage-xip-and-build-guide/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eBoot VxWorks 7 with U-Boot: DTB, mkimage, XIP and Build Guide\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eIntegrating \u003cstrong\u003eVxWorks 7 with U-Boot\u003c/strong\u003e requires careful coordination between the bootloader, VxWorks image format, Device Tree Blob (DTB) handling, target memory layout, and early CPU initialization.\u003c/p\u003e","title":"Boot VxWorks 7 with U-Boot: DTB, mkimage, XIP and Build Guide","type":"training"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/device-tree/","section":"Tags","summary":"","title":"Device-Tree","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/dtb/","section":"Tags","summary":"","title":"DTB","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/mkimage/","section":"Tags","summary":"","title":"Mkimage","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/powerpc/","section":"Tags","summary":"","title":"Powerpc","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/training/","section":"Trainings","summary":"","title":"Trainings","type":"training"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/u-boot/","section":"Tags","summary":"","title":"U-Boot","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/vxworks-7/","section":"Tags","summary":"","title":"VxWorks 7","type":"tags"},{"content":"","date":"2026-08-25","externalUrl":null,"permalink":"/tags/xip/","section":"Tags","summary":"","title":"XIP","type":"tags"},{"content":"","date":"2026-08-23","externalUrl":null,"permalink":"/tags/cybersecurity/","section":"Tags","summary":"","title":"Cybersecurity","type":"tags"},{"content":"","date":"2026-08-23","externalUrl":null,"permalink":"/tags/embedded-security/","section":"Tags","summary":"","title":"Embedded Security","type":"tags"},{"content":"","date":"2026-08-23","externalUrl":null,"permalink":"/tags/firmware-security/","section":"Tags","summary":"","title":"Firmware Security","type":"tags"},{"content":"","date":"2026-08-23","externalUrl":null,"permalink":"/tags/iot-security/","section":"Tags","summary":"","title":"IoT Security","type":"tags"},{"content":"","date":"2026-08-23","externalUrl":null,"permalink":"/tags/reverse-engineering/","section":"Tags","summary":"","title":"Reverse Engineering","type":"tags"},{"content":"","date":"2026-08-23","externalUrl":null,"permalink":"/tags/vxworks-firmware/","section":"Tags","summary":"","title":"VxWorks Firmware","type":"tags"},{"content":" VxWorks OS and Firmware Security: A Deep Technical Analysis\nVxWorks is one of the most widely deployed real-time operating systems in embedded computing. Its use across networking equipment, industrial systems, aerospace platforms, telecommunications hardware, and other embedded applications makes its security model particularly important.\nA weakness in an embedded operating system can have consequences far beyond a single application. If an attacker gains sufficient privileges at the operating-system or firmware level, they may be able to access sensitive information, modify system behavior, install persistent code, or take control of the underlying device.\nThis article examines the architecture and security model of VxWorks, with particular attention to protection domains, fault management, virtualization, networking, debugging interfaces, firmware structure, configuration security, and common weaknesses found in older embedded deployments.\n🔍 Understanding the VxWorks Architecture # VxWorks is a portable real-time operating system developed by Wind River. It can be configured for different classes of embedded applications, ranging from conventional embedded systems to networking platforms and safety-critical real-time environments.\nHistorically, VxWorks has been deployed in aerospace systems, radar platforms, networking equipment, wireless routers, telecommunications devices, and other performance-sensitive products.\nVxWorks development has traditionally been supported by Wind River development environments such as Tornado and later Wind River Workbench. These tools provide capabilities for compiling, editing, analyzing, and debugging applications.\nThe operating system can be configured in several ways:\nClosed embedded systems with separation between kernel and application components. Networking platforms with routing, security, and networking functionality. Safety-critical and hard real-time systems requiring deterministic behavior and stringent reliability requirements. Because the operating system provides the foundation for applications and device services, vulnerabilities at the OS or firmware layer can have a disproportionate security impact.\n🏗️ Real-Time Kernel and System Architecture # VxWorks is built around a real-time kernel designed for deterministic and responsive execution.\nIts architecture supports multitasking and, in applicable configurations, symmetric multiprocessing across multiple CPU cores. Scheduling mechanisms include preemptive and round-robin scheduling, while synchronization primitives such as mutexes and semaphores coordinate access to shared resources.\nImportant architectural characteristics include:\nMultitasking and priority-based scheduling Fast interrupt handling Symmetric multiprocessing support POSIX real-time APIs Interprocess communication mechanisms Priority inheritance Memory protection mechanisms File-system support C and C++ development support System error detection and recovery facilities Protection mechanisms allow applications to operate within isolated address spaces in configurations that provide stronger process separation.\nVxWorks also supports interprocess communication and distributed-system functionality, including mechanisms associated with VxFusion and related networking architectures.\nThe application boot process forms an important part of the overall security model because weaknesses during initialization can potentially undermine protections established later in the operating system.\n🛡️ Fault Management and Isolation # VxWorks provides mechanisms for centralized fault handling. Rather than allowing individual failures to propagate unpredictably throughout the system, dedicated components can monitor system state and initiate predefined recovery procedures.\nThis approach is particularly important in real-time and high-availability environments where uncontrolled failures can affect critical applications.\nProtection Domains # One of the important concepts in VxWorks security architecture is the protection domain.\nProtection domains establish hardware-enforced boundaries around software resources. Depending on system configuration, applications, shared libraries, shared data, and system software can be separated into different protection regions.\nMemory Management Unit (MMU) support can enforce these boundaries by validating memory accesses.\nThe general objective is to prevent one software component from freely accessing resources belonging to another component.\nHowever, the effectiveness of this model depends heavily on how system developers configure execution boundaries and privileged interfaces. Excessive privileges or poorly designed kernel entry points can weaken otherwise strong isolation mechanisms.\nOMS and AMS # Older VxWorks environments also included high-availability frameworks incorporating components such as the Object Management System (OMS) and Alarm Management System (AMS).\nOMS represents hardware and software objects through an abstract hierarchical model. Relationships between objects can be used to describe dependencies throughout the system.\nAMS manages alarms and fault conditions.\nA simplified fault-management flow can be represented as:\nA component detects an abnormal condition. The component generates an alarm. AMS receives the alarm through the appropriate interface. The alarm propagates through the configured object relationship hierarchy. An associated handler performs the predefined recovery action. Objects capable of detecting failures and generating alarms can be designed with standardized timeout, exit, and error-handling behavior. Device drivers are one example of components that may be treated as hardened objects.\nThe overall objective is to prevent localized failures from locking up the entire system.\n🖥️ Virtualization and Embedded Hypervisors # Virtualization allows VxWorks to operate as a guest operating system under a hypervisor.\nThis architecture can consolidate workloads that would traditionally require multiple physical CPU boards onto a single hardware platform.\nA simplified architecture consists of:\nPhysical Hardware │ ▼ Hypervisor ┌────┴────┐ │ │ ▼ ▼ VxWorks Other Guest Guest OS │ ▼ Applications While virtualization can improve resource utilization and system consolidation, it also introduces another security boundary.\nVirtual Board Security # Older VxWorks virtualization environments included utilities such as wrload for loading executable images onto virtual boards.\nBecause such utilities can perform privileged operations, access controls become critical.\nIf debug privileges are unnecessarily enabled or virtualization parameters are incorrectly configured, an attacker who gains access to the debugging environment may be able to manipulate virtual machines or virtual boards.\nThis demonstrates an important security principle for embedded hypervisors: debugging and management interfaces must be treated as privileged attack surfaces rather than ordinary development conveniences.\n⚠️ VxWorks Security Model and Potential Weaknesses # VxWorks protection domains can provide strong isolation when correctly configured, but flexibility can also introduce security risks.\nThe operating system allows developers to define execution boundaries and privileged object entry points according to application requirements.\nThis flexibility is useful for embedded development, but excessive privileges can undermine the protection model.\nA secure design therefore depends on:\nCarefully defined privilege boundaries Strict MMU configuration Minimal kernel exposure Controlled object entry points Restricted debugging access Proper authentication Secure firmware configuration Security mechanisms provided by the RTOS cannot compensate for insecure application or firmware configuration.\n🧱 Stack Overflow Detection and Protection # VxWorks historically used stack-filling techniques to help identify excessive task stack consumption.\nWhen tasks are created, their stack regions can be initialized with a recognizable pattern. Runtime functions can then inspect the remaining unused stack space.\nFor example, a stack-monitoring function can identify tasks that are approaching their allocated limits.\nIn configurations supporting guard pages, the MMU can provide an additional layer of protection. If a task attempts to access a protected guard region beyond its valid stack, a memory exception can be generated.\nHowever, the effectiveness of this mechanism depends on configuration.\nGuard-page size and placement matter, and additional configuration options can be used to increase the protected region where appropriate.\nStack protection should therefore be considered one component of a broader memory-safety strategy rather than a complete defense against memory corruption.\n🌐 VxWorks Networking and Packet Hooks # VxWorks has historically included a BSD-derived TCP/IP networking stack and routing capabilities.\nThe networking architecture separates protocol processing from device-driver functionality through interfaces such as the MUX layer.\nApplications can access network services through socket APIs, while specialized buffer mechanisms can support efficient movement of network data between software components.\nVxWorks also provides packet-processing hooks that can be used for traffic inspection or filtering.\nExamples of relevant interfaces include:\nSTATUS etherInputHookAdd(); STATUS ipFilterHookAdd(); STATUS etherOutputHookAdd(); These interfaces can be used to build packet-monitoring or filtering functionality around the network stack.\nFrom a security perspective, such hooks are valuable because they provide opportunities to inspect traffic before or after normal protocol processing.\nThey can also introduce additional attack surface if custom packet-processing code is poorly implemented.\n🔐 SSL and Cryptographic Support # Embedded systems often operate under strict memory and storage constraints. This can make integrating large cryptographic libraries more complicated than on conventional desktop or server platforms.\nOlder VxWorks deployments sometimes required customized builds of OpenSSL or alternative cryptographic libraries to accommodate platform limitations.\nA typical integration process could involve:\nSelecting the required cryptographic algorithms Removing unnecessary components Adapting build configurations Modifying platform-specific makefiles Linking the resulting libraries with the VxWorks application Libraries such as Cryptlib were also used in some embedded environments to provide cryptographic functionality.\nThe key security requirement is not simply whether SSL/TLS exists, but whether the implementation uses current cryptographic protocols, secure certificates, appropriate key management, and properly maintained libraries.\n🧱 Firewalling VxWorks Systems # Historically, VxWorks did not necessarily provide a complete firewall solution as part of the core operating system.\nThird-party packet-filtering solutions could be integrated to provide stateful traffic inspection.\nNetwork hooks could also be used to implement custom filtering and even functionality such as network address translation.\nSecurity certification and network robustness testing have historically been important aspects of VxWorks networking deployments, particularly where malformed packets or hostile traffic could affect real-time operation.\nNevertheless, secure networking requires more than a robust protocol stack. Services must also be minimized, authenticated, patched, and isolated appropriately.\n🐞 The VxWorks Debugging Interface # One of the most significant security concerns in older VxWorks deployments was exposure of the WDB debugging interface.\nThe WDB agent historically operated over UDP port 17185 and provided system-level debugging capabilities.\nBecause debugging interfaces are designed to interact closely with the operating system, they can expose highly privileged functionality, including access to memory and system information.\nA system exposing an unauthenticated or insufficiently protected debugging service to an untrusted network can therefore create a serious security risk.\nOlder research demonstrated that exposed WDB services could reveal information such as:\nVxWorks version information Bootline configuration System architecture Memory contents Runtime system information A representative legacy scan might identify:\n17185/udp open filtered wdbrpc The critical lesson is not the port number itself, but the security principle behind it:\nDevelopment and debugging interfaces should never be exposed to untrusted networks in production systems.\nDebugging functionality should be disabled, filtered, authenticated, or isolated whenever it is not explicitly required.\n🔑 Weak Password Protection in Legacy VxWorks # Some older VxWorks environments used a proprietary password-obfuscation mechanism associated with the vxencrypt utility.\nLegacy implementations relied on relatively simple transformations rather than modern password hashing mechanisms.\nSuch designs are problematic because password protection should rely on modern password-derived key or hash functions designed to resist offline guessing.\nAdditional weaknesses become especially serious when combined with:\nNo account lockout Weak credentials Exposed Telnet or FTP services Network-accessible authentication Factory-default passwords Modern embedded security architectures should use strong password hashing, rate limiting, secure authentication protocols, and unique credentials.\n🌍 IPv6 Neighbor Discovery Risks # Neighbor Discovery Protocol (NDP) is an important component of IPv6 networking.\nOlder VxWorks implementations were reported to have weaknesses in the handling of certain NDP information, potentially allowing spoofed information to influence neighbor or forwarding state.\nIn vulnerable configurations, manipulated neighbor information could potentially cause traffic to be redirected toward an attacker on the same network.\nThe broader security lesson is that network-control protocols require strong validation because attackers who can influence routing or neighbor information may gain opportunities for:\nTraffic interception Traffic redirection Denial-of-service conditions Network reconnaissance Legacy embedded systems are particularly challenging because vulnerabilities can remain in deployed devices long after their original software versions have become obsolete.\n📦 Understanding VxWorks 5.x Firmware Structure # Firmware is the core software image that controls an embedded device.\nAnalyzing its structure can reveal:\nBoot components Operating-system images Configuration data Web interfaces Firmware metadata Checksums Persistent settings Older VxWorks 5.x-based router firmware could contain multiple primary and trailing data sections.\nA representative Linksys firmware image analysis might reveal metadata such as:\nFirmware file size: 1769384 bytes Code pattern: 5SGW Vendor name: Linksys Device name: WRT54GS Checksum: CORRECT The primary files could include components such as:\nvxworks.bin igwhtm.dat langpak_en.dat Additional trailer records could contain supporting metadata required by the firmware image format.\nUnderstanding these structures is useful during legitimate firmware auditing because it allows researchers to identify where executable code, configuration information, and integrity mechanisms reside.\n🔬 Firmware Security Analysis # A security assessment of a VxWorks-based embedded device should examine both the operating system and the firmware surrounding it.\nLegacy VxWorks deployments can contain several important security considerations:\nBootloader security Firmware integrity Configuration protection Debug interfaces Management services Default credentials Cryptographic key storage Web interfaces Firmware update mechanisms These areas often determine whether an attacker can move from a remotely accessible application-layer weakness to deeper system compromise.\n⚙️ Boot Sequence and BSP Security # The Board Support Package (BSP) is a critical component of VxWorks firmware because it connects the operating system to the underlying hardware.\nFrom a security perspective, the boot process deserves careful analysis because it determines:\nWhich image is loaded Where the image is loaded How hardware is initialized Which configuration parameters are applied How firmware integrity is checked Legacy router research demonstrated that modifying boot components could enable alternative firmware to be installed on devices designed around proprietary VxWorks images.\nFor authorized security research, examining the BSP can reveal the firmware\u0026rsquo;s structural format and identify weaknesses in its integrity-validation process.\nA secure modern design should instead incorporate mechanisms such as:\nCryptographic firmware signatures Secure boot Protected bootloader configuration Rollback protection Hardware-backed keys Verified firmware updates 🧰 Firmware Replacement and Recovery Mechanisms # Older Linksys devices based on VxWorks could be converted to alternative firmware through specialized recovery and flashing procedures.\nFirmware images could contain boot components such as a Common Firmware Environment (CFE) image.\nConfiguration variables stored in nonvolatile memory could influence boot behavior, networking parameters, hardware configuration, and recovery settings.\nFor example, a legacy configuration dump might contain values describing:\nboardflags boardnum boardrev sdram configuration MAC addresses LAN configuration boot_wait watchdog GPIO settings These parameters illustrate why nonvolatile configuration storage is security-sensitive.\nIf an attacker can modify boot parameters or firmware configuration without authorization, they may be able to alter the device\u0026rsquo;s startup behavior or weaken recovery protections.\n🌐 Services and Network Exposure # Legacy embedded firmware frequently exposes fewer services than a general-purpose operating system, but every exposed service remains part of the attack surface.\nA representative VxWorks-based router configuration could expose HTTP management and PPTP while leaving FTP and Telnet unavailable.\nA legacy network scan might report:\nPORT STATE SERVICE 21/tcp closed ftp 23/tcp closed telnet 80/tcp open http 1723/tcp open pptp Restricting unnecessary services is beneficial, but insecure protocols or outdated management interfaces can still create significant risk.\nModern embedded systems should prefer:\nHTTPS instead of HTTP SSH instead of Telnet Strong authentication Network-level access controls Management-plane isolation Disabled legacy protocols 🔑 Factory-Default Credentials # Factory-default credentials remain a recurring embedded-device security problem.\nOlder VxWorks-based devices could ship with predictable username and password combinations.\nThe problem is particularly dangerous when:\nThe device is connected directly to an untrusted network. Administrative services are remotely accessible. Users are not forced to change default credentials. There is no effective login rate limiting. Secure device deployment should require unique credentials during initial configuration and should prevent predictable default authentication from remaining active in production.\n📄 Configuration Files and Sensitive Information # Firmware backup files such as config.bin can contain important device configuration data.\nA file that appears binary or obfuscated is not necessarily cryptographically protected.\nLegacy embedded configuration formats may contain readable strings or recoverable sensitive values, including:\nAdministrative credentials Wireless network names Wireless security keys Network configuration Device-specific settings This illustrates an important distinction between encoding, obfuscation, compression, and encryption.\nSecurity-sensitive configuration should be protected with real cryptographic mechanisms rather than relying on a format that merely makes the contents difficult to read casually.\n🔐 Embedded Private Keys and HTTPS # Embedded devices commonly provide web-based administration interfaces.\nOne historical security problem is embedding the same private cryptographic key directly into firmware images.\nIf a private key is included in a publicly obtainable firmware image, an attacker who extracts it may be able to undermine the confidentiality or authenticity expected from HTTPS.\nA more secure architecture should provide device-specific credentials and private keys that are:\nUnique per device Protected from unauthorized extraction Generated securely Stored in protected hardware or secure storage when possible Replaceable through a secure lifecycle mechanism Hard-coded shared private keys should be avoided.\n🧮 Firmware Checksums Are Not Cryptographic Signatures # Firmware images often contain checksums to detect accidental corruption.\nHowever, a checksum is not equivalent to a cryptographic signature.\nA checksum can establish that data has not changed accidentally, but a properly designed digital-signature system provides authentication and integrity against deliberate modification.\nA secure firmware-update architecture should therefore use cryptographic verification rather than relying solely on simple checksums or reversible obfuscation.\nImportant mechanisms include:\nSHA-2 or SHA-3-based integrity measurements Digital signatures Trusted public-key storage Secure boot Version validation Anti-rollback mechanisms 🌐 Insecure Embedded Web Interfaces # Web interfaces are one of the most important attack surfaces in embedded devices.\nOlder firmware often stores HTML and related resources inside compressed firmware packages. After boot, these resources are exposed through the device\u0026rsquo;s web server.\nSecurity weaknesses in these interfaces can include:\nAuthentication bypass Command injection Cross-site scripting Cross-site request forgery Buffer overflows Unsafe input handling Insecure session management Privilege-escalation flaws The OWASP application-security guidance provides a useful framework for evaluating web interfaces, although embedded systems often require additional testing because they interact directly with hardware and privileged system services.\nA vulnerability in an embedded web interface can therefore become a gateway to the underlying operating system.\n🕰️ Unpatched and Obsolete Firmware # One of the biggest long-term problems in embedded security is firmware aging.\nUnlike desktop and server operating systems, embedded devices may remain deployed for many years with little or no software maintenance.\nCommon problems include:\nOutdated operating-system versions Unsupported third-party libraries Unpatched network services Legacy cryptographic algorithms Known vulnerabilities Weak firmware-update mechanisms Inability to upgrade deployed devices Security must therefore be considered throughout the entire device lifecycle, from initial development through deployment and eventual retirement.\n🧠 Key Security Lessons from VxWorks # The VxWorks security model demonstrates that embedded security is not determined by the operating system alone.\nA secure device requires multiple layers working together:\n┌──────────────────────────────┐ │ Applications │ ├──────────────────────────────┤ │ Web / Network APIs │ ├──────────────────────────────┤ │ Security Services │ ├──────────────────────────────┤ │ VxWorks RTOS │ ├──────────────────────────────┤ │ Protection / MMU │ ├──────────────────────────────┤ │ Bootloader / BSP │ ├──────────────────────────────┤ │ Firmware Integrity │ ├──────────────────────────────┤ │ Hardware │ └──────────────────────────────┘ A weakness at any layer can undermine protections elsewhere.\nThe most important security principles include:\nMinimize privileged interfaces. Disable debugging services in production. Use strong authentication. Remove factory-default credentials. Encrypt sensitive configuration data. Protect private keys. Use cryptographic firmware signatures. Secure the boot process. Keep firmware and libraries patched. Segment management interfaces from untrusted networks. Apply least-privilege principles to applications and services. 🔮 Future Directions for Embedded VxWorks Security # Modern embedded security increasingly depends on hardware-assisted trust rather than software isolation alone.\nFuture-proof embedded architectures should combine RTOS-level protection with:\nSecure boot Trusted execution environments Hardware security modules Device-unique cryptographic identities Signed firmware updates Runtime integrity monitoring Memory protection Strong network authentication Automated vulnerability management These mechanisms can significantly reduce the impact of vulnerabilities in individual applications or services.\nAt the same time, security research remains important because legacy embedded devices often remain operational long after their original security assumptions have become obsolete.\n🧾 Conclusion # VxWorks provides a powerful real-time operating-system foundation for embedded applications, with mechanisms for multitasking, memory protection, fault management, networking, virtualization, and high-availability operation.\nHowever, the security of a VxWorks-based device ultimately depends on how those capabilities are configured and combined with the surrounding firmware.\nHistorical research into VxWorks systems has highlighted several recurring weaknesses, including exposed debugging interfaces, weak legacy password protection, insecure configuration storage, predictable credentials, insufficient firmware integrity controls, hard-coded cryptographic keys, vulnerable web interfaces, and outdated firmware.\nThe central lesson is straightforward: a robust RTOS does not automatically produce a secure embedded device.\nEffective embedded security requires protection across the entire stack—from hardware and secure boot through the RTOS, firmware, network services, authentication mechanisms, configuration storage, and update infrastructure.\nFor security engineers and firmware researchers, VxWorks provides a valuable case study in how operating-system architecture, firmware design, debugging facilities, and deployment practices interact to determine the real security posture of an embedded platform.\n","date":"2026-08-23","externalUrl":null,"permalink":"/training/vxworks-os-and-firmware-security-a-deep-technical-analysis/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks OS and Firmware Security: A Deep Technical Analysis\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eVxWorks is one of the most widely deployed real-time operating systems in embedded computing. Its use across networking equipment, industrial systems, aerospace platforms, telecommunications hardware, and other embedded applications makes its security model particularly important.\u003c/p\u003e","title":"VxWorks OS and Firmware Security: A Deep Technical Analysis","type":"training"},{"content":"","date":"2026-08-20","externalUrl":null,"permalink":"/tags/aerospace/","section":"Tags","summary":"","title":"Aerospace","type":"tags"},{"content":"","date":"2026-08-20","externalUrl":null,"permalink":"/tags/ai/","section":"Tags","summary":"","title":"AI","type":"tags"},{"content":"","date":"2026-08-20","externalUrl":null,"permalink":"/tags/edge-computing/","section":"Tags","summary":"","title":"Edge Computing","type":"tags"},{"content":"","date":"2026-08-20","externalUrl":null,"permalink":"/tags/hpsc/","section":"Tags","summary":"","title":"HPSC","type":"tags"},{"content":"","date":"2026-08-20","externalUrl":null,"permalink":"/industries/","section":"Industries","summary":"","title":"Industries","type":"industries"},{"content":"","date":"2026-08-20","externalUrl":null,"permalink":"/tags/nasa/","section":"Tags","summary":"","title":"NASA","type":"tags"},{"content":" NASA HPSC: The Space Processor Powering Autonomous Exploration\nSpacecraft computing has traditionally been defined by a difficult compromise: survive first, perform second.\nRadiation, extreme temperatures, vibration, limited power budgets, and missions lasting years or decades make conventional commercial processors unsuitable for many space applications. Radiation can corrupt memory and calculations, while hardware failures can be effectively impossible to repair once a spacecraft leaves Earth.\nThat model is beginning to change.\nIn May 2026, NASA announced testing of its next-generation space processor at the Jet Propulsion Laboratory (JPL) in Southern California. The processor is part of NASA\u0026rsquo;s High Performance Spaceflight Computing (HPSC) initiative, a program designed to dramatically increase spacecraft computing capability while maintaining the reliability required for spaceflight.\nDeveloped with Microchip Technology, the HPSC platform combines multi-core 64-bit processing, radiation protection, fault tolerance, high-speed networking, security, and AI-oriented computing capabilities.\nNASA expects HPSC to provide more than a hundredfold improvement in performance per watt compared with current space-qualified computing systems.\nThat improvement is important because spacecraft power is one of their most constrained resources. Every watt saved by the computing subsystem can potentially be redirected toward scientific instruments, communications, propulsion, sensors, or other mission-critical systems.\nMore importantly, HPSC is not simply a faster processor. It provides the computational foundation for a different class of spacecraft—systems capable of analyzing their environments, making decisions locally, and operating with substantially less dependence on Earth.\n🚀 Why Spacecraft Need a New Computing Architecture # Space is an exceptionally hostile environment for electronics.\nEnergetic particles from the Sun and cosmic rays can cause single-event upsets, corrupt memory, alter processor state, or permanently damage semiconductor structures. Extreme temperatures, mechanical stress, and long mission lifetimes add further constraints.\nTraditional space-qualified processors therefore prioritize reliability and radiation tolerance, often at the expense of raw performance.\nThat trade-off worked well for many previous generations of spacecraft. However, modern exploration missions are producing increasingly complex workloads.\nAdvanced instruments generate larger datasets. Autonomous navigation requires continuous sensor processing. AI-based science applications require substantial compute resources. Deep-space missions also need to make decisions without waiting for instructions from Earth.\nHPSC is intended to address these requirements by bringing significantly greater computational capability to the spacecraft itself.\n🧠 What Is NASA\u0026rsquo;s HPSC? # The High Performance Spaceflight Computing architecture is a 64-bit, multi-core system-on-chip designed specifically for spaceflight applications.\nIts architecture combines several capabilities that are traditionally implemented across separate spacecraft subsystems:\nCache-coherent multi-core processing Radiation-hardened and radiation-tolerant implementations Fault-tolerant computing High-speed networking AI and machine-learning acceleration support Virtualization PCIe connectivity Compute Express Link (CXL) Ethernet and Time-Sensitive Networking (TSN) Cryptographic and security capabilities Dynamic power-management features The HPSC family is designed to support different levels of radiation protection depending on mission requirements. Processing functions that are not required at a particular moment can also be disabled or placed into lower-power states.\nHPSC becomes both a processor and networking platform # One of the architecture\u0026rsquo;s notable features is its integrated 240 Gb/s TSN Ethernet switch.\nThis allows large amounts of data to move between sensors, scientific instruments, storage, and compute resources without requiring the spacecraft to rely entirely on separate networking hardware.\nThe result is more than a conventional CPU upgrade. HPSC can serve as a central computing and data-movement platform for future spacecraft architectures.\nThat integration is particularly valuable for systems containing multiple high-bandwidth sensors and instruments whose data must be processed in real time.\n🌌 Communication Delays Make Onboard Computing Essential # As spacecraft travel farther from Earth, communication latency becomes one of the fundamental constraints on mission operations.\nA radio signal takes roughly 1.3 seconds to travel between Earth and the Moon, while communication with Mars can require approximately 4 to 24 minutes each way, depending on the relative positions of the planets.\nJupiter missions face even greater delays.\nThese latencies make conventional Earth-controlled operations impractical for time-critical events.\nDuring landing, autonomous navigation, collision avoidance, or rapidly changing scientific observations, waiting several minutes for an instruction from Earth could mean that the relevant event has already passed.\nHPSC enables more computation to occur directly on the spacecraft.\nInstead of continuously asking mission control what to do, an autonomous spacecraft can process sensor information locally, evaluate possible actions, and respond immediately.\nLocal decision-making changes mission architecture # This represents a fundamental shift in spacecraft design.\nTraditional spacecraft can be thought of as remote systems whose primary intelligence remains on Earth. More capable onboard computing allows the spacecraft itself to become an active decision-making component.\nA future autonomous system could:\nCollect data from multiple sensors. Process and correlate the information locally. Detect important events or hazards. Select an appropriate response. Execute the response without waiting for Earth. Transmit the resulting information when communications are available. That workflow reduces dependence on continuous communication and makes missions more resilient to long-distance latency.\n🤖 HPSC Brings AI and Edge Computing Into Space # Artificial intelligence is particularly well suited to the problems created by communication latency and limited bandwidth.\nMachine-learning models can process large quantities of sensor and imaging data directly on the spacecraft, allowing the system to identify useful information before transmission.\nAn HPSC-based spacecraft could potentially use AI for applications such as:\nGeological feature detection Terrain classification Hazard identification Autonomous navigation Landing-site assessment Scientific image analysis Sample-site prioritization Sensor-data classification Mission-planning assistance Rather than transmitting every observation to Earth, the spacecraft could determine which data deserves immediate attention.\nAutonomous landing and navigation # Landing is one of the clearest examples of why onboard computing matters.\nA spacecraft approaching the surface must process information from cameras, lidar, radar, inertial sensors, and other systems while operating under strict timing constraints.\nAn onboard compute platform can analyze these data streams simultaneously and support terrain-relative navigation and autonomous hazard avoidance.\nThis allows the spacecraft to react to dangerous terrain or unexpected conditions much faster than an architecture that depends on instructions from Earth.\n📡 Solving the Space Data Explosion # The growth of scientific instrumentation is creating another major challenge: spacecraft can generate more data than they can practically transmit.\nThe Deep Space Network and other communications infrastructure have finite bandwidth. As instruments become more capable, simply sending every raw observation back to Earth becomes increasingly inefficient.\nPowerful onboard computing changes the economics of that data pipeline.\nInstead of treating the spacecraft as a passive data collection device, the system can perform intelligent preprocessing before transmission.\nFor example, onboard software could:\nFilter redundant observations Compress scientific datasets Identify unusual features Prioritize high-value images Detect transient events Combine information from multiple sensors Discard low-value data The spacecraft effectively becomes an intelligent edge-computing node.\nComputing at the edge increases scientific return # This approach can increase the amount of useful science generated per unit of communications bandwidth.\nA Mars rover, for example, could identify scientifically interesting geological formations locally and prioritize those observations rather than transmitting every image with equal priority.\nA space telescope could analyze observations before sending them to Earth.\nA deep-space probe could detect an unexpected event and immediately adjust its observation strategy.\nThe farther a spacecraft travels from Earth, the more valuable this capability becomes.\n🛰️ HPSC as a Platform for Next-Generation Missions # The significance of HPSC ultimately extends beyond processor specifications.\nIts combination of computing performance, networking, fault tolerance, and AI capabilities creates a foundation for new spacecraft architectures.\nPotential applications include:\nDeep-space probes: Autonomous adjustment of scientific observations and mission operations. Mars rovers: More independent navigation and terrain analysis. Space telescopes: Local processing and prioritization of astronomical observations. Lunar vehicles: Reduced dependence on continuous Earth supervision. Distributed spacecraft: High-speed coordination between multiple autonomous vehicles. Scientific platforms: Real-time analysis of instrument data before transmission. The common theme is autonomy.\nFuture spacecraft may increasingly operate less like remotely controlled machines and more like distributed intelligent systems capable of sensing, analyzing, prioritizing, and responding to their environments.\n🧩 HPSC Requires a Software Ecosystem # Advanced hardware alone cannot deliver autonomous spacecraft.\nHPSC needs a software stack capable of taking advantage of multi-core processing, virtualization, AI acceleration, high-speed networking, and strict mission-assurance requirements.\nThe ecosystem is designed around widely used technologies and development environments. Developers can work with platforms such as Debian and Yocto Linux, along with toolchains and frameworks including LLVM, Python, OpenCL, OpenMP, and TensorFlow Lite.\nThis approach can reduce the software barrier for developers coming from terrestrial high-performance and embedded computing environments.\nFor missions with stringent certification, long-term maintenance, and reliability requirements, commercially supported operating systems and virtualization platforms can provide additional assurance.\nWhy real-time operating systems matter # Spacecraft software often combines workloads with radically different requirements.\nA navigation system may require deterministic real-time execution. A machine-learning application may require high computational throughput. Scientific processing may prioritize raw data bandwidth.\nRunning everything within a single undifferentiated software environment can make isolation and certification more difficult.\nA virtualization architecture can instead divide the processor into isolated execution environments.\nFor example, a future spacecraft could run:\nA safety-critical navigation system in one partition An AI-based terrain-classification workload in another Scientific instrument processing in a third This separation allows different workloads to coexist while reducing the risk that a failure in one software component compromises the entire system.\nWind River\u0026rsquo;s role in the HPSC ecosystem # Wind River has extensive experience with embedded, aerospace, and defense systems where deterministic execution, reliability, and long-term software support are critical.\nIts VxWorks real-time operating system, eLxr Linux distribution, and Helix Virtualization Platform provide software options for architectures that need to combine real-time processing, Linux workloads, and isolated applications on the same hardware.\nFor HPSC-class systems, virtualization can become particularly important because spacecraft developers increasingly need to integrate traditional safety-critical workloads with newer AI and high-performance computing applications.\nThe ability to isolate those workloads on a common multi-core platform can reduce hardware duplication while maintaining architectural separation between mission-critical functions.\n🔭 HPSC Could Redefine Spacecraft Computing # HPSC combines several capabilities that historically required substantial compromises: radiation tolerance, multi-core performance, fault tolerance, high-speed networking, AI readiness, and power efficiency.\nIts importance therefore extends beyond the performance of a single processor.\nThe larger objective is to move more intelligence onto the spacecraft itself.\nAs missions travel farther from Earth, communication delays increase. As scientific instruments become more capable, data volumes grow. As autonomous operations become more important, spacecraft need increasingly sophisticated local decision-making.\nHPSC addresses all three trends simultaneously.\nThe result could be a new generation of spacecraft capable of processing information in real time, adapting to changing conditions, prioritizing scientific discoveries, and continuing operations even when communication with Earth is delayed or temporarily unavailable.\nFor the future of deep-space exploration, that may be more important than simply making spacecraft faster. The real breakthrough is giving them enough computing power to understand their environment and act on that information independently.\n","date":"2026-08-20","externalUrl":null,"permalink":"/industries/nasa-hpsc-the-space-processor-powering-autonomous-exploration/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eNASA HPSC: The Space Processor Powering Autonomous Exploration\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eSpacecraft computing has traditionally been defined by a difficult compromise: \u003cstrong\u003esurvive first, perform second\u003c/strong\u003e.\u003c/p\u003e","title":"NASA HPSC: The Space Processor Powering Autonomous Exploration","type":"industries"},{"content":"","date":"2026-08-20","externalUrl":null,"permalink":"/tags/radiation-hardened-computing/","section":"Tags","summary":"","title":"Radiation-Hardened Computing","type":"tags"},{"content":"","date":"2026-08-20","externalUrl":null,"permalink":"/tags/space-computing/","section":"Tags","summary":"","title":"Space Computing","type":"tags"},{"content":"","date":"2026-08-20","externalUrl":null,"permalink":"/tags/space-exploration/","section":"Tags","summary":"","title":"Space Exploration","type":"tags"},{"content":"","date":"2026-08-14","externalUrl":null,"permalink":"/tags/airworthiness/","section":"Tags","summary":"","title":"Airworthiness","type":"tags"},{"content":"","date":"2026-08-14","externalUrl":null,"permalink":"/tags/aviation/","section":"Tags","summary":"","title":"Aviation","type":"tags"},{"content":"","date":"2026-08-14","externalUrl":null,"permalink":"/tags/avionics/","section":"Tags","summary":"","title":"Avionics","type":"tags"},{"content":"","date":"2026-08-14","externalUrl":null,"permalink":"/tags/do-178c/","section":"Tags","summary":"","title":"DO-178C","type":"tags"},{"content":"","date":"2026-08-14","externalUrl":null,"permalink":"/tags/evtol/","section":"Tags","summary":"","title":"EVTOL","type":"tags"},{"content":"","date":"2026-08-14","externalUrl":null,"permalink":"/tags/flying-cars/","section":"Tags","summary":"","title":"Flying Cars","type":"tags"},{"content":" How Close Are Flying Cars to Everyday Travel? Software Holds the Key\nElectric vertical takeoff and landing aircraft (eVTOLs) have moved rapidly from concept demonstrations to increasingly sophisticated flight-test programs. An aircraft can now demonstrate vertical takeoff, transition to wing-borne cruise, and return safely to the ground—bringing the idea of flying taxis closer to practical reality.\nBut successful flight testing is only one milestone on the path to commercial passenger operations.\nFor eVTOLs to become part of everyday transportation, manufacturers must demonstrate that their aircraft can maintain predictable and verifiable safety throughout long-term operation. That requires more than validating propulsion, aerodynamics, and flight controls. The underlying software architecture must also support deterministic execution, fault containment, traceability, verification, and airworthiness certification.\nThis is where aviation-grade real-time operating systems and development tools become critical. Wind River has accumulated experience in mission-critical systems for commercial aircraft and civil helicopters, including real-time scheduling, resource partitioning, software isolation, simulation, and certification support.\nThe remaining distance between today\u0026rsquo;s eVTOL flight tests and routine passenger service is therefore not measured solely in flight hours. It is also measured in the maturity and certifiability of the software ecosystem supporting every flight.\n✈️ Flight Testing Is Only the Beginning of Airworthiness # On July 1, 2026, the revised Civil Aviation Law of the People\u0026rsquo;s Republic of China came into effect. The revised law requires civil aircraft registered with Chinese nationality to obtain the applicable airworthiness certification before operating, while aircraft conducting production test flights must obtain special flight permits and remain within the permitted operational scope.\nThis distinction is fundamental to eVTOL commercialization.\nA successful flight test demonstrates that an aircraft can perform within a particular test scenario. It does not, by itself, establish that the complete aircraft is ready for commercial passenger operations.\nAn eVTOL must progress through a much broader certification process covering its design, hardware, software, systems, manufacturing, verification, and operational characteristics.\nCertification Becomes a Development Constraint # For conventional aircraft, obtaining certification for a new aircraft type can take many years. Estimates commonly place the process in the range of five to nine years, depending on aircraft complexity, regulatory requirements, development maturity, and certification strategy.\nFor eVTOL manufacturers, this creates a difficult engineering trade-off.\nThe technology is evolving rapidly, but every significant change can introduce additional verification and certification work. Manufacturers therefore need architectures that allow them to evolve aircraft functionality without unnecessarily repeating validation across unaffected portions of the system.\nSoftware architecture consequently becomes part of the commercialization strategy rather than simply an implementation detail.\n🧩 One Certificate Requires Evidence Across the Entire System # Although passenger eVTOLs typically operate at lower altitudes and over shorter ranges than commercial airliners, their safety-critical functions still require highly predictable behavior.\nDuring flight, systems responsible for flight control, navigation, displays, communications, vehicle management, and other functions may execute concurrently on shared computing resources.\nThese applications can have very different safety criticality levels.\nA failure in a non-critical application should not be able to disrupt a flight-critical function. Similarly, a high-priority control task must receive predictable access to processor time and memory regardless of what other applications are doing.\nThis creates several fundamental software requirements:\nDeterministic task execution Strong spatial and temporal isolation Controlled resource allocation Fault containment Traceability between requirements and implementation Repeatable verification Clearly defined interfaces between software components Software Changes Can Expand the Certification Workload # As eVTOL platforms evolve, software updates will inevitably introduce new functionality and modify existing behavior.\nThe engineering challenge is determining precisely which system components are affected by each change and proving that unaffected functions continue to satisfy their requirements.\nWithout a modular architecture, even a relatively localized software modification can trigger extensive regression testing.\nA partitioned architecture can reduce this burden by establishing clearer boundaries between applications and allowing engineering teams to focus verification on the components actually affected by a change.\nThis makes software architecture directly relevant to certification cost, development velocity, and aircraft lifecycle management.\n🛡️ Wind River VxWorks 653 Provides Partitioned Avionics Architecture # Wind River\u0026rsquo;s VxWorks 653 RTOS is designed for Integrated Modular Avionics (IMA) systems and follows the ARINC 653 architectural model.\nIts time and space partitioning capabilities allow applications with different safety-criticality levels to share a computing platform while maintaining controlled execution and resource boundaries.\nTemporal partitioning allocates defined execution windows to applications, while spatial partitioning isolates their memory environments.\nThis architecture is particularly relevant to eVTOL systems because multiple aircraft functions can potentially share consolidated computing hardware without allowing a fault in one application to propagate uncontrollably into another.\nCertification Evidence Supports Traceability # Wind River states that VxWorks 653 provides certification evidence up to DO-178C DAL A, the highest Design Assurance Level defined by the avionics software standard.\nCertification evidence does not eliminate the aircraft manufacturer\u0026rsquo;s certification responsibilities. Instead, it can provide reusable artifacts and a structured foundation that helps development teams establish traceable verification and certification processes.\nThis becomes increasingly valuable when an aircraft platform undergoes multiple software revisions.\nIf applications are appropriately separated, development teams can more clearly identify which partitions and interfaces are affected by a modification and target regression testing accordingly.\nThe resulting modularity can help control both the technical scope and the schedule impact of subsequent certification activities.\n🔒 Hypervisors and Simulation Extend the Development Environment # Mixed-criticality systems can require multiple operating environments to coexist on the same physical computing platform.\nWind River\u0026rsquo;s Hypervisor provides isolated execution environments that can accommodate different operating systems and application workloads while maintaining separation between them.\nThis approach can help eVTOL designers consolidate computing resources without necessarily forcing every software component into a single operating environment.\nThe development process can also benefit from system-level virtualization and simulation.\nSimics Enables Earlier System Validation # Wind River Simics provides full-system simulation capabilities that allow teams to develop and test software before all physical hardware is available.\nFor aerospace programs, this can be particularly valuable because hardware development and aircraft integration often progress over long schedules.\nA virtualized development environment allows software teams to begin integration and testing earlier, while hardware teams continue developing the physical platform.\nThis effectively shifts portions of the validation process to an earlier stage.\nPotential benefits include:\nEarlier discovery of integration defects Parallel hardware and software development Earlier software verification Reduced dependence on prototype hardware More efficient regression testing Lower integration risk later in the program For eVTOL programs operating under demanding certification schedules, moving verification activities earlier in the development lifecycle can reduce schedule pressure.\n🚁 Wind River Software Already Supports Certified Aircraft # The technologies being positioned for eVTOL applications are not entirely new to aviation.\nAirbus Helicopters\u0026rsquo; Helionix integrated modular avionics system uses Wind River VxWorks 653 RTOS. The platform supports functions including multi-function displays and flight-management control systems, while autopilot capabilities also operate within the architecture.\nThrough resource management and software partitioning, applications with different safety-criticality levels can share computing resources while maintaining controlled execution environments.\nHelionix is deployed on civil helicopter platforms including the H175 and H145.\nWind River technology is also used in aerospace programs such as the Boeing 787 and Airbus A400M. According to Wind River, technologies associated with VxWorks 653 have supported more than 100 civil and military aircraft and over 600 safety-critical projects.\nAviation Software Principles Remain Relevant to eVTOLs # eVTOLs introduce new aircraft configurations, propulsion architectures, and operational concepts. However, many of the fundamental principles governing aviation software safety remain unchanged.\nFlight-critical functions still need predictable execution.\nFailures still need to be contained.\nSoftware changes still need to be traceable.\nCertification authorities still require objective evidence that safety requirements have been satisfied.\nThe aircraft may look fundamentally different from a conventional helicopter or fixed-wing aircraft, but these software engineering requirements remain central to passenger safety.\n🌐 Aviation-Grade Software Is Part of the eVTOL Commercialization Path # The transition from experimental eVTOL flights to everyday passenger transportation requires more than demonstrating that an aircraft can fly.\nManufacturers must establish an engineering and certification framework capable of proving that every critical function behaves predictably throughout the aircraft lifecycle.\nThat means software must provide deterministic execution, isolation between applications, traceability, controlled updates, and evidence suitable for airworthiness review.\nWind River\u0026rsquo;s VxWorks 653, Hypervisor, and Simics technologies address different parts of this challenge, from partitioned real-time execution and mixed-criticality isolation to early full-system simulation and certification support.\nThe broader lesson is that eVTOL commercialization is as much a software-certification challenge as it is an aviation engineering challenge.\nAs low-altitude passenger transportation moves toward commercial deployment, the aircraft\u0026rsquo;s software foundation will determine how efficiently manufacturers can validate new capabilities, contain failures, manage system complexity, and produce the evidence required by regulators.\nWhen every flight-critical function has a defined execution boundary and every software change can be traced and verified, eVTOLs move another step closer to becoming a dependable part of everyday transportation.\n","date":"2026-08-14","externalUrl":null,"permalink":"/industries/how-close-are-flying-cars-to-everyday-travel-software-holds-the-key/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eHow Close Are Flying Cars to Everyday Travel? Software Holds the Key\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eElectric vertical takeoff and landing aircraft (eVTOLs) have moved rapidly from concept demonstrations to increasingly sophisticated flight-test programs. An aircraft can now demonstrate vertical takeoff, transition to wing-borne cruise, and return safely to the ground—bringing the idea of flying taxis closer to practical reality.\u003c/p\u003e","title":"How Close Are Flying Cars to Everyday Travel? Software Holds the Key","type":"industries"},{"content":"","date":"2026-08-14","externalUrl":null,"permalink":"/tags/sdv/","section":"Tags","summary":"","title":"SDV","type":"tags"},{"content":"","date":"2026-08-14","externalUrl":null,"permalink":"/tags/vxworks-653/","section":"Tags","summary":"","title":"VxWorks 653","type":"tags"},{"content":"","date":"2026-08-14","externalUrl":null,"permalink":"/tags/wind-river/","section":"Tags","summary":"","title":"Wind River","type":"tags"},{"content":"","date":"2026-08-11","externalUrl":null,"permalink":"/tags/device-driver/","section":"Tags","summary":"","title":"Device Driver","type":"tags"},{"content":"","date":"2026-08-11","externalUrl":null,"permalink":"/tags/dma/","section":"Tags","summary":"","title":"DMA","type":"tags"},{"content":"","date":"2026-08-11","externalUrl":null,"permalink":"/tags/industrial-embedded/","section":"Tags","summary":"","title":"Industrial Embedded","type":"tags"},{"content":"","date":"2026-08-11","externalUrl":null,"permalink":"/tags/pci-express/","section":"Tags","summary":"","title":"PCI Express","type":"tags"},{"content":"","date":"2026-08-11","externalUrl":null,"permalink":"/tags/pcie-driver/","section":"Tags","summary":"","title":"PCIe Driver","type":"tags"},{"content":"","date":"2026-08-11","externalUrl":null,"permalink":"/tags/vxbus-2.0/","section":"Tags","summary":"","title":"VxBus 2.0","type":"tags"},{"content":" VxWorks 7 PCIe Driver Development with VxBus 2.0\nPCI Express (PCIe) has become one of the most important high-speed interconnect technologies in embedded and industrial systems. FPGA accelerators, high-speed ADCs and DACs, network adapters, storage controllers, and specialized industrial I/O devices all rely on PCIe to exchange data with embedded processors.\nIn VxWorks 7, the preferred architecture for developing modern PCIe device drivers is the VxBus 2.0 framework. VxBus provides a structured driver model that simplifies hardware discovery, resource management, interrupt handling, and device lifecycle management while maintaining the deterministic behavior required by real-time applications.\nA well-designed VxBus PCIe driver typically provides:\nAutomatic device discovery and matching. Standardized BAR and interrupt resource management. Support for PCI configuration-space access. Flattened Device Tree (FDT) integration where applicable. SMP-aware driver behavior. Clean probe, attach, and detach lifecycles. Integration with DMA and interrupt subsystems. This guide presents a practical PCIe driver architecture using a PLX/Broadcom-style PCIe switch or bridge as an example.\n🧩 1. Define the Driver Control Structure # Every VxBus driver should maintain a private control structure containing the state associated with each device instance.\n/* plxPcieDrv.h */ #ifndef __PLX_PCIE_DRV_H__ #define __PLX_PCIE_DRV_H__ #include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;hwif/vxBus.h\u0026gt; #include \u0026lt;subsys/pci/vxbPciLib.h\u0026gt; #include \u0026lt;subsys/int/vxbIntLib.h\u0026gt; #define PLX_VENDOR_ID 0x10B5 /* PLX / Broadcom */ #define PLX_DEVICE_ID 0x8725 /* Example device */ typedef struct plxPcieDrvCtrl { VXB_DEV_ID pDev; /* VxBus device handle */ void * barBase; /* Virtual BAR0 address */ VXB_RESOURCE * pResMem; /* Memory BAR resource */ VXB_RESOURCE * pResIrq; /* Interrupt resource */ int irq; /* IRQ number */ SEM_ID isrSem; /* Optional ISR-to-task semaphore */ /* Additional driver state */ /* DMA channels, locks, statistics, etc. */ } PLX_PCIE_DRV_CTRL; #endif /* __PLX_PCIE_DRV_H__ */ The control structure serves as the driver\u0026rsquo;s central state container.\npDev identifies the VxBus device instance, while barBase stores the virtual address associated with a mapped PCIe BAR.\nThe resource pointers track resources allocated through VxBus and must be released during the driver\u0026rsquo;s cleanup path.\nA semaphore can optionally be used to allow the interrupt service routine to perform minimal work while delegating heavier processing to a dedicated task.\n🔍 2. Implement the Probe Function # The probe method determines whether the driver supports a particular PCIe device.\nA basic implementation can match the PCI Vendor ID and Device ID:\nLOCAL STATUS plxPcieProbe ( VXB_DEV_ID pDev ) { UINT16 vendorId = 0; UINT16 deviceId = 0; /* Read Vendor ID */ if (vxbPciConfigRead16 ( pDev, PCI_CFG_VENDOR_ID, \u0026amp;vendorId ) != OK) { return ERROR; } /* Read Device ID */ if (vxbPciConfigRead16 ( pDev, PCI_CFG_DEVICE_ID, \u0026amp;deviceId ) != OK) { return ERROR; } /* Match supported hardware */ if (vendorId == PLX_VENDOR_ID \u0026amp;\u0026amp; deviceId == PLX_DEVICE_ID) { return OK; } return ERROR; } The important point is to use the VxBus PCI configuration helpers rather than legacy PCI configuration APIs when developing a VxBus-based driver.\nReturning OK indicates that the driver recognizes the device and allows VxBus to continue with the attach phase.\nProduction drivers can make matching more selective by checking additional information such as:\nPCI revision ID. Subsystem Vendor ID. Subsystem Device ID. PCI class code. Device capabilities. Hardware-specific configuration. This becomes particularly useful when a single driver supports multiple related devices.\n🛠️ 3. Attach the Device and Allocate Resources # The attach method is the central initialization stage of a VxBus PCIe driver.\nIt typically allocates the private control structure, obtains BAR resources, acquires the interrupt resource, connects the ISR, initializes synchronization objects, and configures the hardware.\nLOCAL STATUS plxPcieAttach ( VXB_DEV_ID pDev ) { PLX_PCIE_DRV_CTRL * pCtrl; VXB_RESOURCE_ADR * pResAdr; int i; /* Allocate driver control structure */ pCtrl = (PLX_PCIE_DRV_CTRL *) vxbMemAlloc(sizeof(PLX_PCIE_DRV_CTRL)); if (pCtrl == NULL) return ERROR; bzero((char *)pCtrl, sizeof(PLX_PCIE_DRV_CTRL)); pCtrl-\u0026gt;pDev = pDev; /* * Allocate a usable memory BAR. */ for (i = 0; i \u0026lt; VXB_MAXBARS; i++) { pCtrl-\u0026gt;pResMem = vxbResourceAlloc(pDev, VXB_RES_MEMORY, i); if (pCtrl-\u0026gt;pResMem != NULL) { pResAdr = (VXB_RESOURCE_ADR *)pCtrl-\u0026gt;pResMem-\u0026gt;pRes; if (pResAdr != NULL) { pCtrl-\u0026gt;barBase = (void *)pResAdr-\u0026gt;virtual; /* * pResAdr-\u0026gt;start = physical address * pResAdr-\u0026gt;size = BAR size * pResAdr-\u0026gt;pHandle = bus access handle */ break; } vxbResourceFree(pDev, pCtrl-\u0026gt;pResMem); pCtrl-\u0026gt;pResMem = NULL; } } if (pCtrl-\u0026gt;barBase == NULL) { vxbMemFree(pCtrl); return ERROR; } /* * Allocate interrupt resource. */ pCtrl-\u0026gt;pResIrq = vxbResourceAlloc(pDev, VXB_RES_IRQ, 0); if (pCtrl-\u0026gt;pResIrq == NULL) { vxbResourceFree(pDev, pCtrl-\u0026gt;pResMem); vxbMemFree(pCtrl); return ERROR; } pCtrl-\u0026gt;irq = (int)(long)vxbResourceAdrsGet ( pDev, VXB_RES_IRQ, 0 ); /* * Store private data for later retrieval. */ vxbDevSoftcSet(pDev, pCtrl); /* * Connect interrupt handler. */ if (vxbIntConnect ( pDev, pCtrl-\u0026gt;pResIrq, plxPcieIsr, pCtrl ) != OK) { /* Cleanup omitted here for brevity. */ return ERROR; } /* * Enable interrupt. */ if (vxbIntEnable ( pDev, pCtrl-\u0026gt;pResIrq ) != OK) { vxbIntDisconnect ( pDev, pCtrl-\u0026gt;pResIrq ); /* Cleanup omitted here for brevity. */ return ERROR; } /* * Optional ISR-to-task synchronization. */ pCtrl-\u0026gt;isrSem = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY); /* * Device-specific initialization. */ plxPcieHwInit(pCtrl); return OK; } The BAR allocation loop asks VxBus for available memory resources. Once a valid resource is returned, VXB_RESOURCE_ADR provides information about the resource, including its virtual address, physical address, size, and access handle.\nOne important engineering principle is complete error-path cleanup. If interrupt allocation fails after a BAR has already been allocated, the BAR must be released before returning.\nThe same rule applies to every subsequent initialization stage.\n🧱 4. Understand PCIe BAR Mapping # PCIe Base Address Registers (BARs) describe the memory or I/O resources exposed by the endpoint.\nFor memory BARs, the VxBus resource layer provides the driver with a mapped address that can be used for device register access.\nConceptually, the mapping looks like:\nPCIe Device │ ├── BAR0 │ └── Physical device registers │ ▼ VxBus PCI resource manager │ ▼ Virtual address mapping │ ▼ Driver barBase │ ▼ Device register access The driver should not assume that BAR0 is always the correct resource. Real hardware may expose multiple BARs with different purposes.\nFor example:\nBAR0 → Control and status registers. BAR2 → Large DMA buffer window. BAR4 → Doorbell or queue registers. The hardware datasheet should always be used to determine which BAR corresponds to which function.\n⚡ 5. Design a Deterministic Interrupt Service Routine # The interrupt service routine should remain short and deterministic.\nA simple example is:\nLOCAL void plxPcieIsr ( void * pArg ) { PLX_PCIE_DRV_CTRL * pCtrl = (PLX_PCIE_DRV_CTRL *)pArg; UINT32 status; /* * Read interrupt status. * Offset is device-specific. */ status = *(volatile UINT32 *) ((char *)pCtrl-\u0026gt;barBase + 0x04); /* * Clear active interrupt bits. * Device-specific semantics. */ *(volatile UINT32 *) ((char *)pCtrl-\u0026gt;barBase + 0x04) = status; if (status != 0) { /* * Defer substantial processing to a task. */ if (pCtrl-\u0026gt;isrSem != NULL) semGive(pCtrl-\u0026gt;isrSem); } } A good real-time ISR generally performs only the minimum work necessary to acknowledge the hardware event and preserve its state.\nAvoid performing expensive processing, blocking operations, or complex library calls from interrupt context.\nA common architecture is:\nPCIe Interrupt │ ▼ ISR │ ├── Read status ├── Clear interrupt └── Signal semaphore │ ▼ High-priority task │ ├── Process event ├── Handle DMA └── Notify application This design improves determinism while keeping the interrupt response path short.\n🧮 6. Use VxBus Register Accessors # Register access should preferably use the VxBus accessor mechanisms because they account for bus-specific access attributes and endianness requirements.\nstatic inline UINT32 plxRead32 ( PLX_PCIE_DRV_CTRL * pCtrl, UINT32 offset ) { return vxbRead32 ( pCtrl-\u0026gt;pResMem-\u0026gt;pRes-\u0026gt;pHandle, (UINT32 *) ((char *)pCtrl-\u0026gt;barBase + offset) ); } static inline void plxWrite32 ( PLX_PCIE_DRV_CTRL * pCtrl, UINT32 offset, UINT32 value ) { vxbWrite32 ( pCtrl-\u0026gt;pResMem-\u0026gt;pRes-\u0026gt;pHandle, (UINT32 *) ((char *)pCtrl-\u0026gt;barBase + offset), value ); } For situations where the mapping and access requirements are completely understood, direct volatile access can also be used:\n#define PLX_REG_READ(pCtrl, off) \\ (*(volatile UINT32 *) \\ ((char *)(pCtrl)-\u0026gt;barBase + (off))) #define PLX_REG_WRITE(pCtrl, off, val) \\ (*(volatile UINT32 *) \\ ((char *)(pCtrl)-\u0026gt;barBase + (off)) = (val)) The preferred approach depends on the VxWorks BSP, processor architecture, device requirements, and bus-access semantics.\nFor production hardware, register accesses should always be verified against the device\u0026rsquo;s programming manual.\n🧩 7. Register the Driver with VxBus # The driver must expose its methods through a VxBus method table.\nLOCAL VXB_DRV_METHOD plxPcieMethods[] = { { VXB_DEVMETHOD_CALL(vxbDevProbe), (FUNCPTR)plxPcieProbe }, { VXB_DEVMETHOD_CALL(vxbDevAttach), (FUNCPTR)plxPcieAttach }, /* * Optional: * { * VXB_DEVMETHOD_CALL(vxbDevDetach), * (FUNCPTR)plxPcieDetach * } */ VXB_DEVMETHOD_END }; LOCAL VXB_DRV plxPcieDrv = { { NULL }, \u0026#34;plxPcie\u0026#34;, \u0026#34;PLX PCIe Switch/Bridge Driver\u0026#34;, VXB_BUSID_PCI, 0, 0, plxPcieMethods, NULL }; VXB_DRV_DEF(plxPcieDrv); A BSP or module initialization routine can register the driver with:\nSTATUS plxPcieDrvRegister(void) { return vxbDrvAdd(\u0026amp;plxPcieDrv); } Once registered, VxBus can match discovered PCIe devices against the driver\u0026rsquo;s probe method and invoke the attach method for supported hardware.\n🧹 8. Implement a Complete Detach Path # A production driver should provide a clean detach path whenever the deployment model requires device removal, hot-plug support, or module unloading.\nLOCAL STATUS plxPcieDetach ( VXB_DEV_ID pDev ) { PLX_PCIE_DRV_CTRL * pCtrl = vxbDevSoftcGet(pDev); if (pCtrl == NULL) return ERROR; /* * Stop interrupt generation first. */ if (pCtrl-\u0026gt;pResIrq != NULL) { vxbIntDisable ( pDev, pCtrl-\u0026gt;pResIrq ); vxbIntDisconnect ( pDev, pCtrl-\u0026gt;pResIrq ); } /* * Release resources. */ if (pCtrl-\u0026gt;pResMem != NULL) { vxbResourceFree ( pDev, pCtrl-\u0026gt;pResMem ); } if (pCtrl-\u0026gt;pResIrq != NULL) { vxbResourceFree ( pDev, pCtrl-\u0026gt;pResIrq ); } if (pCtrl-\u0026gt;isrSem != NULL) semDelete(pCtrl-\u0026gt;isrSem); vxbDevSoftcSet(pDev, NULL); vxbMemFree(pCtrl); return OK; } Cleanup should occur in the reverse order of initialization whenever possible.\nThis prevents resources from remaining active after the device has been removed or the driver has been unloaded.\n🚀 9. Add DMA for High-Bandwidth PCIe Devices # PCIe devices such as FPGA accelerators, storage controllers, and high-speed acquisition cards often depend heavily on DMA.\nRather than transferring large payloads through CPU-driven register accesses, a DMA engine can move data directly between the device and system memory.\nA typical data path looks like:\nPCIe Endpoint │ │ DMA ▼ System Memory │ ▼ Application / Processing Task For VxWorks 7, DMA implementation should use the appropriate VxBus DMA interfaces and account for the platform\u0026rsquo;s cache-coherency model.\nParticular attention should be paid to:\nDMA address width. Cache coherency. Memory alignment. Scatter/gather support. IOMMU configuration where applicable. DMA buffer lifetime. Synchronization between CPU and device. Interrupt completion handling. DMA implementation is highly dependent on the BSP, processor, PCIe controller, and endpoint hardware, so the device datasheet and platform documentation should be treated as authoritative.\n🐞 10. Debug the Driver from the VxWorks Shell # VxWorks provides useful shell commands for inspecting the VxBus and PCIe topology.\n-\u0026gt; vxbPciShow() -\u0026gt; vxbDevShow() -\u0026gt; vxbDevPathShow() During development, it is also useful to print the resources discovered during attachment:\nprintf ( \u0026#34;PLX PCIe: BAR0 virtual = %p, IRQ = %d\\n\u0026#34;, pCtrl-\u0026gt;barBase, pCtrl-\u0026gt;irq ); A useful debugging sequence is:\nConfirm the PCIe device is enumerated. Verify Vendor ID and Device ID. Confirm BAR sizes and addresses. Verify the driver probe succeeds. Confirm attach completes. Check interrupt allocation. Verify register reads and writes. Trigger a known hardware interrupt. Validate DMA transfers. Stress the device under SMP and high interrupt loads. This staged approach makes it easier to isolate enumeration, resource, interrupt, and data-path problems.\n🛡️ 11. Follow Real-Time PCIe Driver Best Practices # A robust VxWorks PCIe driver should follow several core engineering principles.\nKeep ISRs Short # Do the minimum amount of work required to acknowledge the interrupt and capture necessary state.\nProtect Shared State # Use appropriate synchronization primitives when data is accessed concurrently by ISRs and tasks.\nISR │ ├── Update minimal state │ └── Signal task │ ▼ Worker task │ └── Protected shared state The synchronization mechanism should be selected according to the execution context and real-time requirements.\nPrefer MSI or MSI-X # When supported by both the PCIe endpoint and BSP, MSI/MSI-X generally provides a cleaner interrupt architecture than legacy INTx.\nMultiple MSI-X vectors can also allow different device functions or queues to be assigned to different interrupt handlers.\nValidate Every Hardware Access # Register offsets, bit definitions, reset behavior, interrupt-clearing semantics, and DMA requirements should always be derived from the hardware reference manual.\nHandle Missing Hardware Gracefully # The driver should tolerate cases where:\nThe device is not present. BAR allocation fails. The device reports an unexpected revision. The endpoint is not fully initialized. Interrupt resources are unavailable. DMA initialization fails. Test Under Realistic Load # PCIe drivers should be tested under:\nHigh interrupt rates. Sustained DMA traffic. SMP operation. CPU contention. Repeated device resets. Error and recovery conditions. Long-duration stress tests. A driver that works during a simple functional test may still fail under sustained system load.\n🔄 12. Recommended VxBus PCIe Driver Architecture # A complete driver can be organized around the following lifecycle:\nVxBus Device Discovery │ ▼ probe() │ Device Supported? / \\ No Yes │ │ ▼ ▼ Exit attach() │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ Allocate BARs IRQ Softc Resources Setup │ │ │ └─────────────┼─────────────┘ ▼ Hardware Init │ ▼ Runtime State │ ┌──────────┴──────────┐ ▼ ▼ ISR DMA │ │ ▼ ▼ Worker Task Data Processing │ │ └──────────┬──────────┘ ▼ detach() │ ▼ Disable + Disconnect │ ▼ Free All Resources This separation keeps hardware discovery, initialization, runtime processing, and cleanup clearly defined.\n🎯 Conclusion # Developing a PCIe device driver for VxWorks 7 with VxBus 2.0 becomes significantly more manageable when the driver follows the framework\u0026rsquo;s intended lifecycle.\nThe fundamental sequence is straightforward:\nDefine a per-device control structure. Implement a precise probe method. Allocate and map PCIe BAR resources during attach. Acquire and configure interrupt resources. Connect a short, deterministic ISR. Move substantial processing into tasks. Use appropriate VxBus register-access and DMA interfaces. Register the driver through the VxBus framework. Implement complete error recovery and cleanup. Stress-test the driver under SMP, interrupt, and DMA workloads. The PLX/Broadcom-style implementation presented here provides a useful starting skeleton for PCIe endpoints, bridges, and accelerator devices. However, production deployment requires adapting BAR selection, register offsets, interrupt semantics, DMA handling, reset behavior, and synchronization to the exact hardware and BSP.\nWith a clean VxBus architecture, careful resource management, and disciplined real-time design, VxWorks 7 can provide a maintainable foundation for high-speed PCIe devices used in industrial automation, aerospace, networking, data acquisition, storage, and other mission-critical embedded systems.\n","date":"2026-08-11","externalUrl":null,"permalink":"/app/vxworks-7-pcie-driver-development-with-vxbus-2.0/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 7 PCIe Driver Development with VxBus 2.0\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003ePCI Express (PCIe) has become one of the most important high-speed interconnect technologies in embedded and industrial systems. FPGA accelerators, high-speed ADCs and DACs, network adapters, storage controllers, and specialized industrial I/O devices all rely on PCIe to exchange data with embedded processors.\u003c/p\u003e","title":"VxWorks 7 PCIe Driver Development with VxBus 2.0","type":"app"},{"content":"","date":"2026-08-10","externalUrl":null,"permalink":"/tags/edge-ai/","section":"Tags","summary":"","title":"Edge AI","type":"tags"},{"content":"","date":"2026-08-10","externalUrl":null,"permalink":"/tags/functional-safety/","section":"Tags","summary":"","title":"Functional Safety","type":"tags"},{"content":"","date":"2026-08-10","externalUrl":null,"permalink":"/tags/intelligent-edge/","section":"Tags","summary":"","title":"Intelligent Edge","type":"tags"},{"content":"","date":"2026-08-10","externalUrl":null,"permalink":"/tags/real-time-computing/","section":"Tags","summary":"","title":"Real-Time Computing","type":"tags"},{"content":"","date":"2026-08-10","externalUrl":null,"permalink":"/tags/tsn/","section":"Tags","summary":"","title":"TSN","type":"tags"},{"content":" VxWorks 7 in 2026: Powering Secure Intelligent Edge Systems\nFor decades, VxWorks has been one of the most widely deployed real-time operating systems (RTOS) for mission-critical embedded systems. Developed by Wind River since the late 1980s, the platform has continuously evolved alongside increasingly demanding requirements in aerospace, defense, automotive, industrial, medical, and other safety-critical industries.\nThe VxWorks 7 generation introduced a major architectural transformation with a modular, component-based design that separates the operating system kernel from middleware, applications, and optional components. That foundation has allowed Wind River to progressively add modern capabilities such as edge AI, containerization, deterministic networking, cloud-native development, and expanded hardware support without abandoning the deterministic behavior required by mission-critical applications.\nThe latest VxWorks 7 releases continue this evolution, positioning the platform as a bridge between traditional hard real-time systems and the increasingly software-defined intelligent edge.\n🧩 VxWorks 7 Evolution and Modular Architecture # VxWorks 7 represented a significant departure from earlier generations by introducing a highly modular architecture.\nInstead of treating the operating system as a single monolithic software package, VxWorks 7 separates core operating system functionality from middleware, applications, and optional components. This approach provides several advantages for embedded systems with long operational lifetimes.\nOrganizations can independently update selected components, reuse previously certified software elements, and maintain products across extended development and deployment cycles.\nThis is particularly important in aerospace, automotive, medical, and industrial systems, where products may remain operational for many years and software changes can require extensive validation.\nOver subsequent releases, Wind River has expanded the platform around several major technology areas:\nCloud-native and containerized applications. Artificial intelligence and machine learning at the edge. Modern programming languages and development tools. Deterministic networking and Time-Sensitive Networking (TSN). Functional safety and cybersecurity certifications. Expanded processor and architecture support. Virtualization and mixed-criticality computing. The result is an RTOS designed to combine hard real-time determinism with modern software development practices.\n📦 Containers and Kubernetes Reach the Real-Time Edge # One of VxWorks 7\u0026rsquo;s most notable differentiators is its support for containerized workloads.\nWind River has positioned VxWorks as an RTOS capable of supporting Open Container Initiative (OCI)-compliant containers, allowing developers to package applications using familiar container workflows.\nApplications can be built and deployed using established container ecosystems and registries, including Docker Hub, Amazon ECR, and Harbor.\nKubernetes-oriented capabilities further extend this approach to distributed edge environments. Kubelet support allows devices running VxWorks to participate in orchestration workflows, enabling remote application management and more portable software deployment models.\nFor embedded developers, this changes the traditional relationship between real-time systems and modern cloud-native development.\nInstead of choosing between deterministic execution and contemporary deployment practices, developers can increasingly combine both within the same edge architecture.\nThis is especially useful for fleets of industrial machines, vehicles, robotics platforms, and other connected devices that require frequent software updates while maintaining strict timing guarantees.\n🤖 AI and Machine Learning Move Closer to the Hardware # Artificial intelligence is another major area of VxWorks 7\u0026rsquo;s evolution.\nThe intelligent edge increasingly requires systems to process sensor and machine-learning data locally rather than continuously sending raw information to centralized cloud infrastructure.\nVxWorks supports technologies such as Python, Pandas, and TensorFlow Lite, enabling developers to integrate inference and analytics directly into embedded devices.\nLocal processing can reduce network latency, decrease bandwidth requirements, and allow systems to continue operating when cloud connectivity is unavailable.\nPotential applications include:\nPredictive maintenance. Machine vision. Advanced driver-assistance systems. Industrial automation. Autonomous robotics. Sensor analytics. Real-time anomaly detection. The combination of deterministic execution and local AI is particularly valuable in systems where an intelligent decision must be translated into a physical action within a predictable time window.\n🧑‍💻 Modern Languages and Development Toolchains # VxWorks 7 has also expanded beyond traditional embedded C development.\nCurrent capabilities include support for:\nC11 and C++17. Ongoing C++20 development. Rust-based development workflows. Python. Boost libraries. LLVM and Clang-based toolchains. GNU and Wind River Diab toolchains. Wind River Studio further extends the development environment into cloud-based workflows, incorporating capabilities such as remote builds, digital twins, DevSecOps processes, and lifecycle management.\nThis combination allows development teams to use more familiar modern software practices while retaining the deterministic characteristics expected from an RTOS.\nRust is particularly relevant to safety-conscious embedded development because of its focus on memory safety and prevention of common classes of software vulnerabilities.\n🌐 Deterministic Networking with TSN # Modern embedded systems increasingly depend on networks rather than isolated controllers.\nIndustrial machines, autonomous vehicles, aircraft, and robotic systems may contain numerous processing nodes that must exchange data with precise timing. Conventional Ethernet provides high bandwidth and reliability, but traditional best-effort networking does not inherently guarantee deterministic delivery.\nVxWorks addresses this requirement through its Time-Sensitive Networking (TSN) capabilities.\nThe platform supports key IEEE networking technologies including:\nIEEE 802.1AS. IEEE 802.1Qbv. IEEE 802.1Qbu. Precision Time Protocol (PTP). Deterministic traffic scheduling. Recent optimizations have also targeted interrupt response, kernel performance, OPC UA throughput, and overall networking efficiency.\nThis makes TSN particularly relevant for distributed control systems where synchronized communication between sensors, processors, and actuators is essential.\n🛡️ Safety and Security for Mission-Critical Systems # Real-time performance alone is not enough for systems responsible for human safety.\nVxWorks has built its reputation partly through its extensive functional-safety and certification history. Wind River reports participation in more than 600 safety certification programs across different industries.\nRelevant certification frameworks include:\nDO-178C DAL A / EUROCAE ED-12C for aerospace. ISO 26262 ASIL D for automotive systems. IEC 61508 SIL 3 for industrial applications. IEC 62304 for medical software. Security capabilities have evolved alongside the platform\u0026rsquo;s safety features.\nVxWorks includes technologies such as kernel address sanitization, stack-smashing protection, modern OpenSSL implementations, digital signatures, authentication mechanisms, CVE monitoring, and Software Bill of Materials (SBOM) support.\nFor connected embedded systems, this combination of functional safety and cybersecurity is increasingly important. A system must not only continue operating deterministically—it must also remain resilient against malicious software and supply-chain vulnerabilities.\n🧠 Virtualization Enables Mixed-Criticality Systems # Modern embedded platforms increasingly need to run workloads with very different requirements on the same processor.\nA single system may need to execute safety-critical control software alongside Linux applications, AI workloads, networking services, and other general-purpose software.\nVxWorks supports this model through virtualization technologies including the Wind River Helix Virtualization Platform and virtio-based interfaces.\nThis enables mixed-criticality architectures in which workloads can be isolated while sharing the same underlying hardware.\nThe approach can reduce the number of physical processors and circuit boards required by a system while allowing different operating environments to coexist.\nSupport for modern processor platforms, including Arm, x86/x86-64, PowerPC, RISC-V, and cloud-oriented processors such as AWS Graviton, further broadens the potential deployment range.\n🚀 Artemis II Demonstrates Real-World Mission-Critical Deployment # One of the most visible examples of VxWorks\u0026rsquo; mission-critical heritage is its involvement in NASA programs.\nIn 2026, Wind River and its parent company Aptiv highlighted VxWorks\u0026rsquo; role in NASA\u0026rsquo;s Artemis II mission, the first crewed lunar flyby in more than five decades.\nVxWorks provided deterministic software infrastructure for critical functions associated with the Space Launch System and Orion spacecraft, including components of NASA\u0026rsquo;s core Flight System and the independent Orion Backup Flight System.\nThe broader NASA heritage of VxWorks extends across numerous high-profile missions and spacecraft, including the Curiosity and Perseverance Mars rovers and the James Webb Space Telescope.\nDigital-twin and simulation technologies have also enabled extensive software validation before physical hardware becomes available, reducing development risk for complex aerospace systems.\nBeyond NASA, VxWorks has been deployed across commercial aircraft, industrial robots, automotive platforms, unmanned systems, and medical devices.\n🏭 Why VxWorks 7 Matters for the Intelligent Edge # The modern intelligent edge requires more than raw computing performance.\nSystems increasingly need to combine:\nHard real-time responsiveness. Functional safety. Cybersecurity. AI inference. Deterministic networking. Containerized applications. Cloud connectivity. Long-term maintainability. Multi-OS and mixed-criticality operation. VxWorks 7 occupies a distinctive position because it attempts to combine these traditionally separate requirements within a single embedded software platform.\nFor organizations maintaining long-lived products, its modular architecture can simplify upgrades and help reuse previously validated components.\nFor new systems, capabilities such as TSN, edge AI, virtualization, and containerization allow developers to build architectures that are considerably more sophisticated than traditional standalone RTOS designs.\n🔮 The Future of VxWorks 7 # Wind River\u0026rsquo;s ongoing development continues to expand VxWorks toward emerging embedded computing requirements.\nFuture areas of interest include deeper RISC-V support, exploration of CHERI-based memory-safety technologies, expanded AI tooling, and tighter integration between cloud development environments and edge deployment.\nAt the same time, the growth of software-defined vehicles, autonomous machines, industrial robotics, aerospace platforms, and distributed control systems is increasing demand for operating systems that can combine intelligence with deterministic execution.\nThat is ultimately where VxWorks 7 remains relevant.\nThe platform is no longer simply a traditional RTOS for isolated embedded controllers. It is evolving into a foundation for secure, connected, AI-enabled, mixed-criticality edge systems where software must remain predictable even as system complexity continues to increase.\nFor organizations migrating legacy VxWorks deployments, developing new safety-critical products, or exploring AI and containerization at the edge, the current VxWorks 7 generation offers a mature foundation built around decades of real-world embedded experience.\n","date":"2026-08-10","externalUrl":null,"permalink":"/industries/vxworks-7-in-2026-powering-secure-intelligent-edge-systems/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 7 in 2026: Powering Secure Intelligent Edge Systems\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eFor decades, \u003cstrong\u003eVxWorks\u003c/strong\u003e has been one of the most widely deployed real-time operating systems (RTOS) for mission-critical embedded systems. Developed by Wind River since the late 1980s, the platform has continuously evolved alongside increasingly demanding requirements in aerospace, defense, automotive, industrial, medical, and other safety-critical industries.\u003c/p\u003e","title":"VxWorks 7 in 2026: Powering Secure Intelligent Edge Systems","type":"industries"},{"content":" Brain-Cerebellum Fusion for Mission-Critical Robotics\nModern robots are becoming increasingly autonomous, but greater intelligence introduces a fundamental systems-engineering problem: how can highly dynamic AI workloads coexist with deterministic, safety-critical motion control on the same computing platform?\nConsider an autonomous mobile robot or industrial robotic arm performing precision manipulation. A perception or path-planning workload running on the upper-level computing stack may experience a short scheduling delay because of changing environmental conditions, increased model complexity, or a sudden computational load. If that delay propagates into the motion-control path, servo timing can become unpredictable, potentially causing jitter, synchronization errors, or unsafe physical movement.\nThis is the central challenge of mission-critical robotics.\nThe software responsible for perception, planning, AI inference, and cloud connectivity benefits from an open and flexible ecosystem. The software controlling motors, safety mechanisms, timing, and deterministic communications requires the opposite: strict temporal behavior, isolation, and predictable execution.\nA modern robotics platform therefore needs to accommodate both.\nWind River\u0026rsquo;s Mixed-Criticality Systems (MCS) approach addresses this requirement by combining Linux, Wind River VxWorks RTOS, and Wind River Hypervisor on a common multi-core computing platform. The resulting architecture separates high-level intelligence from safety-critical control while allowing both domains to participate in a coordinated robotic system.\n🤖 Robotics Is Moving Toward Complete Autonomous Loops # Robotics is evolving from fixed-function automation toward systems capable of continuously sensing their environment, reasoning about changes, executing physical actions, and adapting their behavior.\nCollaborative robots, autonomous mobile robots, industrial manipulators, and other intelligent machines increasingly combine:\nComputer vision Sensor fusion AI inference Path planning Motion planning Multi-axis servo control Industrial networking Safety monitoring Cloud and fleet connectivity These capabilities create a much more complex software architecture than traditional automation systems.\nFrom automation to autonomy # A useful way to model the architecture is through a four-stage loop:\nSense → Think → Act → Optimize\nThe sensing layer collects information from cameras, lidar, radar, force sensors, encoders, and other inputs.\nThe thinking layer interprets that information, evaluates possible actions, and generates decisions through algorithms and AI models.\nThe execution layer converts those decisions into physical movement through deterministic motor and actuator control.\nThe optimization layer continuously improves system behavior using operational data, diagnostics, and feedback.\nFor mission-critical robots, the challenge is not simply completing this loop. Each stage must interact without allowing unpredictable behavior in one layer to compromise the timing or safety requirements of another.\n🧠 Open AI Workloads and Hard Real-Time Control # The software requirements of an autonomous robot are inherently heterogeneous.\nUpper-level applications often benefit from Linux because of its extensive ecosystem, development tools, middleware support, and compatibility with modern AI frameworks.\nRobotics developers may use Linux distributions such as Ubuntu or Wind River Linux to run perception pipelines, ROS 2 applications, machine-learning frameworks, path-planning algorithms, databases, networking services, and cloud interfaces.\nThe motion-control layer has fundamentally different requirements.\nThe real-time control problem # Servo loops and safety functions may need tightly bounded execution times rather than merely high average performance.\nA general-purpose operating system can provide excellent throughput while still allowing scheduling latency, interrupt contention, memory pressure, driver behavior, or other system activity to introduce timing variation.\nFor non-critical workloads, such variation may be acceptable.\nFor a safety-critical control loop, it can be unacceptable.\nThis creates a fundamental architectural tension:\nThe same platform must remain open enough to run rapidly evolving AI software while keeping the critical control path deterministic and isolated.\n🔒 Mixed-Criticality Systems on a Single Platform # Wind River\u0026rsquo;s Mixed-Criticality Systems approach addresses this tension by assigning different workloads to operating environments with different characteristics.\nLinux provides the open application environment, while Wind River VxWorks RTOS provides the deterministic real-time environment.\nRather than forcing both workloads into the same operating-system domain, the architecture establishes clear separation between them.\nLinux: the robotic \u0026ldquo;brain\u0026rdquo; # The Linux environment can host compute-intensive and rapidly evolving workloads such as:\nEnvironmental perception Computer vision 3D reconstruction AI inference Path planning Task planning ROS 2 middleware Cloud communication Fleet management This environment benefits from the broad Linux software ecosystem and the ability to integrate third-party frameworks and applications.\nVxWorks: the robotic \u0026ldquo;cerebellum\u0026rdquo; # The VxWorks real-time partition is responsible for workloads where deterministic timing and predictable execution are critical.\nThese can include:\nInverse kinematics Multi-axis servo control Motor synchronization Safety monitoring Real-time I/O Deterministic networking Emergency braking System reset and recovery logic The distinction is architectural rather than simply functional.\nLinux determines what the robot should do, while the real-time control domain ensures that physical actions are executed according to tightly controlled timing and safety constraints.\n🛡️ Wind River Hypervisor Provides the Isolation Layer # The architecture becomes particularly powerful when Wind River Hypervisor is introduced as the isolation mechanism between the two environments.\nA hypervisor can divide a multi-core processor into isolated execution domains, allowing multiple guest operating systems to run on the same physical hardware.\nFor mission-critical robotics, this provides a mechanism for establishing spatial and temporal separation between workloads with different criticality levels.\nSpatial isolation # Spatial isolation prevents software in one partition from freely accessing the memory or resources assigned to another partition.\nIf a Linux application experiences a memory fault, runaway process, or software failure, the problem can be contained within the Linux domain rather than automatically propagating into the real-time control environment.\nTemporal isolation # Temporal isolation addresses another critical failure mode: resource contention.\nA high-level AI workload may suddenly consume substantial CPU resources, generate heavy memory traffic, or experience an unexpected computational spike.\nThe real-time control partition must retain its allocated execution resources regardless of what happens elsewhere on the platform.\nThis separation helps prevent non-critical workloads from introducing unpredictable latency into safety-critical control loops.\n🧩 The Brain-Cerebellum Fusion Architecture # The resulting architecture can be viewed as three tightly coordinated layers:\n+-----------------------------------------------------------------------+ | MISSION-CRITICAL ROBOT PLATFORM | +-----------------------------------------------------------------------+ | | | \u0026#34;BRAIN\u0026#34; — Linux Partition | | --------------------------------------------------------------- | | AI Inference | Vision | ROS 2 | Path Planning | Cloud/Fleet | | Sensor Fusion | 3D Processing | Task Planning | | | +-----------------------------------------------------------------------+ | WIND RIVER HYPERVISOR | | --------------------------------------------------------------- | | Spatial Isolation | Temporal Isolation | Resource Partitioning | | Fault Containment | Hardware Access Control | +-----------------------------------------------------------------------+ | | | \u0026#34;CEREBELLUM\u0026#34; — VxWorks RTOS Partition | | --------------------------------------------------------------- | | Servo Control | Inverse Kinematics | Safety Logic | TSN | EtherCAT | | Real-Time I/O | Motor Synchronization | Braking | Recovery | | | +-----------------------------------------------------------------------+ | HARDWARE | | Multi-Core SoC | Memory | Ethernet | Sensors | Motors | I/O | +-----------------------------------------------------------------------+ The key principle is that the brain and cerebellum share hardware without sharing the same failure domain.\nA failure in the Linux environment should not automatically compromise the VxWorks control partition.\nFault containment # Suppose an AI perception process encounters a software defect, consumes excessive memory, or becomes the target of a cyberattack.\nThe hypervisor maintains the separation between the Linux and VxWorks environments.\nThe real-time partition can continue executing its control and safety logic independently, allowing the robot to perform predefined actions such as controlled braking, safe-state transitions, or system resets.\nThis is fundamentally different from relying on application-level software isolation alone.\n⚙️ Core Engineering Benefits # The architecture provides several benefits for robotics developers and system integrators.\n1. Freedom From Interference # Freedom From Interference (FFI) is a fundamental requirement when software with different safety or criticality levels shares a physical platform.\nA mixed-criticality architecture establishes explicit boundaries between general-purpose applications and safety-related control functions.\nThis reduces the risk that non-critical software activity will affect the execution timing or resource availability of safety-critical workloads.\n2. Hardware Consolidation # Without virtualization and strong workload isolation, robotics platforms may require separate processors or boards for AI workloads and deterministic control.\nConsolidating these functions onto a multi-core SoC can reduce:\nHardware BOM cost Board count Physical footprint Power consumption Inter-board communication complexity System integration effort This is especially valuable for mobile robots and embedded platforms where physical space and power budgets are tightly constrained.\n3. Deterministic Networking # The architecture can also incorporate deterministic networking technologies such as Time-Sensitive Networking (TSN) and EtherCAT.\nTSN can provide predictable Ethernet communication for distributed control and sensor traffic, while EtherCAT remains widely used for high-performance industrial motion-control applications.\nCombining deterministic networking with deterministic operating-system execution creates a more coherent real-time path from sensor acquisition through computation and communication to actuator control.\n🔗 ROS 2 and Mixed-Criticality Robotics # ROS 2 provides an important bridge between modern robotics software and the underlying computing architecture.\nIts ecosystem supports distributed nodes, middleware-based communication, sensor integration, perception pipelines, and increasingly sophisticated robotic applications.\nHowever, not every ROS 2 workload has the same criticality requirements.\nA perception node processing camera data can tolerate different timing characteristics from a servo-control function responsible for synchronizing multiple motors.\nSeparating ROS 2 workloads by criticality # A mixed Linux/VxWorks deployment allows system architects to assign workloads according to their requirements.\nLinux can host high-level ROS 2 applications and AI processing, while critical control components can execute within the VxWorks environment.\nThe result is a clearer division between rapidly evolving application software and tightly controlled real-time functions.\nThis separation also improves organizational scalability because AI, application, controls, and safety engineering teams can work within defined architectural boundaries rather than competing for the same system resources.\n🏭 Long-Term Validation and Functional Safety # Architecture alone is not sufficient for mission-critical deployment.\nWhen robots move into regulated or safety-sensitive environments, the underlying operating system and platform technologies must also support the applicable functional-safety and certification requirements.\nThis becomes particularly important in applications such as:\nIndustrial automation Medical robotics Transportation Aerospace Critical infrastructure Autonomous machinery VxWorks certification experience # Wind River positions VxWorks as a platform with extensive deployment experience in regulated industries.\nThe company reports more than 25 years of experience in regulated markets and more than 600 successful safety certification projects across multiple industries.\nFor robotics manufacturers, an established safety-oriented RTOS can reduce some of the platform-level engineering and qualification burden associated with bringing products into high-assurance markets.\nThe specific certification requirements still depend on the target application, system architecture, safety classification, and applicable standards.\n🏗️ From Separate Controllers to Integrated Platforms # Traditional robotic systems often divide computing responsibilities across multiple controllers.\nOne board may run Linux and AI applications, another may run an RTOS for motion control, while dedicated hardware manages networking and safety functions.\nThis approach provides clear separation but introduces additional hardware, communication paths, synchronization requirements, and maintenance overhead.\nA mixed-criticality platform offers another option: consolidate workloads onto a common multi-core computing platform while maintaining strict software and resource isolation.\nThe trade-off # Consolidation does not mean that all workloads should share the same execution environment.\nThe architectural advantage comes from sharing physical hardware while preserving logical and temporal independence.\nThis distinction is crucial.\nThe objective is not to turn a safety-critical servo loop into another Linux process. It is to allow Linux and a deterministic RTOS to coexist on the same hardware without allowing the flexibility of one environment to undermine the guarantees required by the other.\n🚦 Toward Safer Autonomous Machines # The evolution of robotics is shifting the primary engineering challenge from isolated component performance toward system-level integration.\nHigher-quality sensors are making perception more capable. Larger AI models are improving planning and decision-making. More sophisticated middleware is enabling distributed applications.\nBut these advances also increase the amount of software running on the robot.\nThe more complex the \u0026ldquo;brain\u0026rdquo; becomes, the more important it is to protect the \u0026ldquo;cerebellum.\u0026rdquo;\nA robot that can make sophisticated decisions but cannot guarantee deterministic physical execution remains fundamentally constrained in mission-critical environments.\nThe combination of Linux, VxWorks RTOS, and Wind River Hypervisor provides an architectural model for addressing that problem: keep the high-level software ecosystem open and extensible while isolating the control and safety functions that require deterministic behavior.\n🚀 The Path Toward Mission-Critical Robot Autonomy # The next generation of autonomous robots will require more than advanced AI models.\nThey will need architectures capable of combining perception, decision-making, deterministic control, safety, networking, and continuous software evolution without allowing one subsystem to compromise another.\nThe Brain-Cerebellum Fusion model addresses this requirement by treating intelligence and physical execution as separate but coordinated computing domains.\nLinux and ROS 2 provide an extensible environment for AI-driven perception and planning. VxWorks provides the deterministic execution environment for motion control and safety-critical functions. Wind River Hypervisor provides the isolation boundary that allows both domains to coexist on the same processor platform.\nCombined with TSN and industrial Ethernet technologies such as EtherCAT, this architecture creates a path toward highly integrated robotic systems that can simultaneously support AI openness, hard real-time behavior, fault containment, and functional-safety requirements.\nAs autonomous machines move into increasingly demanding industrial, medical, transportation, and infrastructure applications, this separation of intelligence from deterministic execution may become one of the defining architectural patterns for mission-critical robotics.\n","date":"2026-08-08","externalUrl":null,"permalink":"/industries/brain-cerebellum-fusion-for-mission-critical-robotics/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eBrain-Cerebellum Fusion for Mission-Critical Robotics\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eModern robots are becoming increasingly autonomous, but greater intelligence introduces a fundamental systems-engineering problem: \u003cstrong\u003ehow can highly dynamic AI workloads coexist with deterministic, safety-critical motion control on the same computing platform?\u003c/strong\u003e\u003c/p\u003e","title":"Brain-Cerebellum Fusion for Mission-Critical Robotics","type":"industries"},{"content":"","date":"2026-08-08","externalUrl":null,"permalink":"/tags/mission-critical-robotics/","section":"Tags","summary":"","title":"Mission-Critical Robotics","type":"tags"},{"content":"","date":"2026-08-08","externalUrl":null,"permalink":"/tags/real-time-systems/","section":"Tags","summary":"","title":"Real-Time-Systems","type":"tags"},{"content":"","date":"2026-08-08","externalUrl":null,"permalink":"/tags/robotics/","section":"Tags","summary":"","title":"Robotics","type":"tags"},{"content":"","date":"2026-08-08","externalUrl":null,"permalink":"/tags/ros-2/","section":"Tags","summary":"","title":"ROS 2","type":"tags"},{"content":"","date":"2026-08-08","externalUrl":null,"permalink":"/tags/wind-river-hypervisor/","section":"Tags","summary":"","title":"Wind River Hypervisor","type":"tags"},{"content":" Can ROS 2 Bridge the Gap from Open Source to Commercial Robotics?\nThe rapid commercialization of robotics has shifted industry priorities from prototype development to scalable deployment. At the 2026 World Artificial Intelligence Conference (WAIC), more than 1,100 companies participated, with over 200 exhibitors dedicated to Embodied AI. Companies such as Unitree Robotics demonstrated fully automated manufacturing facilities, while Agibot showcased deployment across multiple industrial scenarios. Together, these presentations reflected a broader industry transition: robotics is moving beyond proof-of-concept demonstrations toward real-world production.\nThis transformation also places new demands on robotics software. While ROS 2 has become the industry\u0026rsquo;s de facto framework for robot application development, deploying robots in commercial environments requires much more than application logic. Real-time execution, deterministic behavior, long-term maintenance, and reproducible software delivery are now equally critical.\nTo address these production challenges, Wind River introduced the ROS 2 for Wind River Kaiwu RTOS development project, providing an integration framework that combines the flexibility of ROS 2 with a commercial-grade real-time operating system (RTOS) designed for embedded deployments.\n🤖 Robotics Is Entering the Production Era # China\u0026rsquo;s robotics industry has experienced rapid expansion in recent years.\nAccording to data released by the Ministry of Industry and Information Technology (MIIT), China accounted for more than half of global industrial robot installations during the country\u0026rsquo;s 14th Five-Year Plan period.\nAs robots increasingly move into factories, logistics centers, warehouses, and service environments, software requirements are evolving alongside hardware capabilities.\nRather than focusing solely on feature implementation, development teams must now ensure that robotics software can:\nOperate continuously over extended periods Meet deterministic timing requirements Execute reliably on embedded hardware Support long-term software maintenance Scale across commercial deployments The transition from research platforms to production systems fundamentally changes how robotics software is engineered.\n⚙️ ROS 2 Expands Beyond Research Applications # ROS 2 has become one of the most widely adopted open-source robotics middleware platforms.\nIt provides developers with a comprehensive ecosystem that includes:\nCommunication middleware Hardware abstraction Device drivers Software libraries Development tools Compared with the original ROS framework, ROS 2 introduces significant improvements aimed at commercial robotics, including:\nMulti-robot communication Embedded platform support Improved real-time capabilities Distributed system architecture Enhanced security and reliability These capabilities have enabled ROS 2 to move well beyond academic research into industrial robotics applications.\nHowever, ROS 2 itself primarily serves as an application framework.\nAchieving predictable runtime performance depends heavily on the underlying operating system and system architecture.\n⏱️ Commercial Robots Require Deterministic Execution # Production robots operate under strict timing constraints.\nA typical robotics control loop involves:\nCollecting sensor data Processing perception algorithms Planning motion Sending commands to actuators Each stage must complete within precisely defined execution windows.\nIf scheduling latency varies significantly, robots may experience:\nReduced control accuracy Motion instability Longer system tuning cycles Lower operational reliability Although ROS 2 supports real-time communication mechanisms, deterministic execution ultimately depends on the operating system responsible for task scheduling and hardware resource management.\nThis is where commercial RTOS platforms become increasingly important.\n🛠️ Wind River Integrates ROS 2 with Kaiwu RTOS # To simplify commercial deployment, Wind River developed the ROS 2 for Wind River Kaiwu RTOS project.\nRather than replacing ROS 2, the project integrates the existing ROS 2 software stack into the Kaiwu RTOS runtime environment through customized adaptations and automated build tooling.\nWithin this architecture:\nROS 2 provides the robotics middleware and application framework. Wind River Kaiwu RTOS delivers deterministic real-time execution. ROS 2 for Wind River Kaiwu RTOS supplies the integration layer required for commercial deployment. This approach enables developers to retain familiar ROS 2 development workflows while targeting an operating system optimized for production environments.\n🔧 Flexible Development and Build Options # The project supports multiple development models depending on deployment requirements.\nDevelopment teams can use:\nThe Wind River Kaiwu RTOS SDK available through Wind River Labs under a non-commercial license Commercial Kaiwu RTOS releases for production software development For engineering teams preparing commercial products, the project integrates with system image generation workflows, allowing robotics applications to become part of complete production firmware builds.\nTo improve reproducibility, the project also includes:\nRequired ROS 2 dependencies Automated build scripts Docker-based build environments Containerized development helps ensure consistent software builds regardless of individual developer environments, reducing integration issues during collaborative development.\n☁️ Streamlining the Engineering Workflow # Commercial robotics products require ongoing software updates throughout their operational lifecycle.\nManaging version consistency and deployment pipelines therefore becomes as important as developing application features.\nWind River addresses this through a development ecosystem that supports:\nKaiwu RTOS SDKs Visual Studio Code integration Real-time container workflows Automated software builds The project is also available as a Gallery Technology within Wind River Studio, extending development workflows into cloud-based embedded DevSecOps processes.\nThis allows engineering teams to manage:\nSoftware integration Continuous builds System validation Deployment preparation from a unified platform.\n📈 Commercial Deployment Is Becoming the Industry Focus # The growing importance of production-ready software was also reflected during WAIC 2026.\nThe conference announced:\n212 procurement opportunities Approximately RMB 20.36 billion in intended purchasing value A 25% year-over-year increase These figures illustrate that robotics is rapidly shifting from technology demonstrations toward large-scale commercial adoption.\nAs procurement increasingly replaces prototype showcases, software engineering practices become a decisive competitive factor.\nReliable deployment pipelines, reproducible builds, and long-term maintainability are now essential capabilities for robotics vendors.\n🌐 Bridging Open Source and Commercial Robotics # The value of the ROS 2 for Wind River Kaiwu RTOS project lies in connecting open-source innovation with production-grade engineering.\nEach component addresses a different stage of the software lifecycle:\nComponent Primary Role ROS 2 Robotics middleware and application development Wind River Kaiwu RTOS Deterministic real-time operating environment ROS 2 for Wind River Kaiwu RTOS Integration, build automation, and deployment support Together, they provide a clearer path from prototype development to commercially deployed robotics systems.\n🔮 Outlook # As robotics applications continue expanding across manufacturing, logistics, healthcare, and service industries, software platforms must evolve beyond rapid prototyping toward long-term operational reliability.\nROS 2 has already established itself as the leading open-source robotics framework, but commercial deployment requires additional layers of engineering discipline, including deterministic execution, reproducible builds, lifecycle management, and integrated deployment workflows.\nBy combining ROS 2 with the Kaiwu RTOS and modern DevSecOps tooling, Wind River is addressing one of the industry\u0026rsquo;s most persistent challenges: transforming successful open-source robotics projects into production-ready systems capable of operating reliably at scale. As commercial robotics adoption accelerates, development platforms that bridge this gap are likely to play an increasingly important role in the next generation of intelligent automation.\n","date":"2026-08-05","externalUrl":null,"permalink":"/industries/can-ros-2-bridge-the-gap-from-open-source-to-commercial-robotics/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eCan ROS 2 Bridge the Gap from Open Source to Commercial Robotics?\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eThe rapid commercialization of robotics has shifted industry priorities from prototype development to scalable deployment. At the \u003cstrong\u003e2026 World Artificial Intelligence Conference (WAIC)\u003c/strong\u003e, more than \u003cstrong\u003e1,100 companies\u003c/strong\u003e participated, with over \u003cstrong\u003e200 exhibitors dedicated to Embodied AI\u003c/strong\u003e. Companies such as \u003cstrong\u003eUnitree Robotics\u003c/strong\u003e demonstrated fully automated manufacturing facilities, while \u003cstrong\u003eAgibot\u003c/strong\u003e showcased deployment across multiple industrial scenarios. Together, these presentations reflected a broader industry transition: robotics is moving beyond proof-of-concept demonstrations toward real-world production.\u003c/p\u003e","title":"Can ROS 2 Bridge the Gap from Open Source to Commercial Robotics?","type":"industries"},{"content":"","date":"2026-08-05","externalUrl":null,"permalink":"/tags/embodied-ai/","section":"Tags","summary":"","title":"Embodied AI","type":"tags"},{"content":"","date":"2026-08-05","externalUrl":null,"permalink":"/tags/kaiwu-rtos/","section":"Tags","summary":"","title":"Kaiwu RTOS","type":"tags"},{"content":"","date":"2026-08-05","externalUrl":null,"permalink":"/tags/real-time-operating-systems/","section":"Tags","summary":"","title":"Real-Time Operating Systems","type":"tags"},{"content":"","date":"2026-08-05","externalUrl":null,"permalink":"/tags/waic-2026/","section":"Tags","summary":"","title":"WAIC 2026","type":"tags"},{"content":"","date":"2026-07-20","externalUrl":null,"permalink":"/tags/force-feedback/","section":"Tags","summary":"","title":"Force Feedback","type":"tags"},{"content":"","date":"2026-07-20","externalUrl":null,"permalink":"/tags/healthcare-technology/","section":"Tags","summary":"","title":"Healthcare Technology","type":"tags"},{"content":" How Real-Time Software Powers Force Feedback in Modern Surgical Robots\nMinimally invasive surgical robots are redefining modern surgery by enabling complex procedures through smaller incisions, reducing patient trauma, shortening recovery times, and improving surgical precision. While robotic arms, high-definition imaging, and advanced instrumentation have become standard features, the next frontier in surgical robotics extends beyond mechanical design.\nIncreasingly, attention is shifting toward force feedback—the ability for a robotic system to reproduce the tactile sensation of tissue interaction and transmit it back to the surgeon in real time. Achieving this capability requires far more than sophisticated hardware. It depends on a software platform capable of deterministic control, ultra-low latency, and uncompromising reliability.\nAs surgical robots evolve from research prototypes into widely deployed clinical systems, software has become a defining factor in performance, safety, and long-term innovation.\n📈 Surgical Robotics Enters a New Stage # The surgical robotics market is experiencing rapid growth, particularly in China, where adoption is accelerating across multiple medical specialties.\nAccording to industry forecasts, China\u0026rsquo;s surgical robot market is projected to expand from US$496.7 million in 2025 to US$1.77 billion by 2033, representing a compound annual growth rate (CAGR) of approximately 17.1% between 2026 and 2033.\nDespite this momentum, several challenges continue to shape the industry\u0026rsquo;s development:\nHigh manufacturing costs driven by critical hardware components such as precision reducers, servo systems, and motion controllers. Continued dependence on imported technologies for key subsystems. Increasing demand for enhanced surgeon experience through realistic haptic interaction. Growing expectations for functional safety, cybersecurity, and software reliability. Among these challenges, the absence of effective force feedback remains one of the most significant technical limitations affecting minimally invasive surgical systems.\nConsequently, competitive differentiation is increasingly determined not only by mechanical engineering but also by the quality of the underlying software architecture.\n🏥 Why Force Feedback Matters # Traditional minimally invasive robotic surgery relies heavily on visual information.\nAlthough surgeons benefit from magnified three-dimensional imaging and exceptionally stable robotic manipulation, they lose the tactile sensations naturally available during open surgery. Subtle differences in tissue resistance, gripping force, and instrument contact must instead be inferred visually.\nForce feedback aims to restore this missing sensory channel.\nBy reproducing forces experienced at the instrument tip and transmitting them to the surgeon\u0026rsquo;s controls, the system enables more intuitive manipulation and more precise judgment during delicate procedures.\nPotential benefits include:\nImproved tissue handling More precise force application Reduced risk of accidental tissue damage Enhanced surgeon confidence during complex operations A surgical experience that more closely resembles conventional manual techniques Delivering this experience, however, requires an exceptionally capable real-time software foundation.\n⚙️ Real-Time Software as the Foundation # Every interaction between a surgical instrument and human tissue generates a continuous stream of sensor data.\nTo reproduce force feedback accurately, the control system must repeatedly execute a deterministic sequence of operations within extremely tight timing constraints:\nAcquire force and position measurements. Process sensor data. Execute motion control algorithms. Compute force compensation. Drive robotic actuators. Return tactile feedback to the surgeon. These operations must occur with predictable latency and minimal jitter.\nAny unexpected delay can degrade control fidelity and potentially affect surgical performance. Consequently, the operating system becomes a critical component responsible for ensuring deterministic scheduling, reliable communication, and consistent execution.\nFor life-critical medical equipment, software is no longer simply an implementation detail—it is a core element of overall system safety.\n🖥️ Wind River Kaiwu for Medical Devices # Wind River Kaiwu provides a software platform designed specifically for mission-critical intelligent systems, including medical equipment that requires deterministic real-time performance.\nIts portfolio includes several complementary technologies.\nWind River Kaiwu RTOS # Wind River Kaiwu RTOS targets applications requiring predictable timing and high reliability.\nIn medical environments, it supports equipment such as:\nSurgical robots Medical imaging systems Endoscopy platforms Motion control equipment Precision automation systems Its deterministic scheduling enables consistent execution of time-sensitive control loops required by advanced robotic systems.\nWind River Kaiwu Linux # For applications requiring richer software ecosystems, networking capabilities, and edge intelligence, Wind River Kaiwu Linux provides an open operating environment that supports application expansion and connected medical devices.\nVirtualization Platform # Modern medical systems increasingly consolidate multiple software environments onto shared hardware.\nWind River\u0026rsquo;s virtualization technology enables safety-critical workloads and general-purpose applications to execute independently on a single computing platform, improving system integration while simplifying long-term maintenance.\n🤖 Saroa: Bringing Force Feedback into Clinical Practice # One of the most notable demonstrations of force feedback technology is the Saroa Surgical System, developed by Riverfield, a medical technology company specializing in robotic surgical equipment.\nSaroa is recognized as the first minimally invasive surgical robot to successfully commercialize force feedback technology.\nThe system received manufacturing and commercial approval in Japan during 2023 and entered clinical use shortly thereafter.\nIts significance extends beyond introducing a new surgical feature. It demonstrates that force feedback can transition from laboratory research into practical clinical deployment when supported by an appropriate real-time software architecture.\n🎯 Pneumatic Force Feedback and Deterministic Control # Unlike many robotic systems that rely solely on electromechanical actuation, Saroa reproduces tactile sensations using a precision pneumatic control system.\nBy carefully regulating air pressure, the robot recreates forces encountered during:\nGrasping Clamping Pulling Tissue manipulation The result is a more natural operational feel that allows surgeons to perceive instrument-tissue interaction with greater accuracy.\nAlthough pneumatic systems offer advantages such as lightweight construction, compact packaging, and lower mechanical complexity, they also introduce demanding real-time control requirements.\nThe software platform must continuously regulate multiple feedback loops with millisecond-level precision while maintaining stable performance under varying operating conditions.\n⏱️ Millisecond-Level Response # Riverfield selected Wind River Kaiwu RTOS to satisfy these stringent timing requirements.\nAccording to the company\u0026rsquo;s software engineering team, the platform enabled millisecond-level hardware response necessary for precise pneumatic control while also meeting demanding requirements for reliability, functional safety, and system security.\nDeterministic execution is particularly important in surgical robotics because every movement follows a closed-loop control cycle.\nA simplified control sequence includes:\nSurgeon\u0026#39;s Input │ ▼ Force \u0026amp; Position Sensors │ ▼ Real-Time Control Loop (Wind River Kaiwu RTOS) │ ▼ Motion \u0026amp; Pneumatic Control │ ▼ Robotic Instrument │ ▼ Force Feedback to Surgeon Throughout this loop, the operating system must guarantee predictable scheduling and bounded execution latency.\nEven small variations in response time can reduce force feedback fidelity or negatively affect robotic precision during surgical procedures.\n🔒 Beyond an RTOS: A Complete Software Platform # The Saroa system also demonstrates how software has become central to overall medical device architecture.\nCompared with many traditional surgical robots, Saroa features:\nA significantly smaller physical footprint Reduced system weight Fewer robotic arms Greater mobility between operating rooms Improved collaboration between surgeons and assistants These hardware innovations are supported by a software platform capable of coordinating increasingly sophisticated system functions.\nRather than serving solely as a real-time operating system, Wind River Kaiwu provides multiple layers of functionality:\nDeterministic motion control through Kaiwu RTOS Intelligent applications through Kaiwu Linux Consolidated computing through virtualization Support for scalable software architectures Long-term maintainability for connected medical platforms Together, these capabilities allow manufacturers to build increasingly modular and software-defined medical devices.\n🩺 The Future of Medical Robotics # As surgical robots continue to evolve, expectations will extend far beyond mechanical precision.\nFuture systems will increasingly rely on software to deliver:\nRicher haptic interaction AI-assisted surgical guidance Connected operating environments Predictive diagnostics Continuous software updates Enhanced cybersecurity Greater system integration Meeting these demands requires software platforms that combine deterministic execution, functional safety, security, and scalability within a unified architecture.\n📖 Conclusion # Force feedback represents one of the most significant advances in minimally invasive surgical robotics because it restores an essential sensory dimension that conventional robotic systems have long lacked. Delivering this capability, however, depends on far more than sophisticated mechanical engineering.\nBehind every precise robotic movement lies a deterministic software platform responsible for coordinating sensing, control, communication, and safety in real time.\nBy combining real-time operating system technology, Linux-based application support, and virtualization capabilities, Wind River Kaiwu provides the software foundation required for next-generation surgical robots. As medical devices become increasingly intelligent, connected, and software-defined, trusted real-time software platforms will continue to play a pivotal role in transforming innovative robotic technologies into dependable clinical solutions.\n","date":"2026-07-20","externalUrl":null,"permalink":"/industries/how-real-time-software-powers-force-feedback-in-modern-surgical-robots/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eHow Real-Time Software Powers Force Feedback in Modern Surgical Robots\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eMinimally invasive surgical robots are redefining modern surgery by enabling complex procedures through smaller incisions, reducing patient trauma, shortening recovery times, and improving surgical precision. While robotic arms, high-definition imaging, and advanced instrumentation have become standard features, the next frontier in surgical robotics extends beyond mechanical design.\u003c/p\u003e","title":"How Real-Time Software Powers Force Feedback in Modern Surgical Robots","type":"industries"},{"content":"","date":"2026-07-20","externalUrl":null,"permalink":"/tags/medical-devices/","section":"Tags","summary":"","title":"Medical Devices","type":"tags"},{"content":"","date":"2026-07-20","externalUrl":null,"permalink":"/tags/medical-robotics/","section":"Tags","summary":"","title":"Medical Robotics","type":"tags"},{"content":"","date":"2026-07-20","externalUrl":null,"permalink":"/tags/real-time-operating-system/","section":"Tags","summary":"","title":"Real-Time-Operating-System","type":"tags"},{"content":"","date":"2026-07-20","externalUrl":null,"permalink":"/tags/surgical-robots/","section":"Tags","summary":"","title":"Surgical Robots","type":"tags"},{"content":"","date":"2026-07-04","externalUrl":null,"permalink":"/tags/artificial-intelligence/","section":"Tags","summary":"","title":"Artificial Intelligence","type":"tags"},{"content":"","date":"2026-07-04","externalUrl":null,"permalink":"/tags/cloud-computing/","section":"Tags","summary":"","title":"Cloud Computing","type":"tags"},{"content":"","date":"2026-07-04","externalUrl":null,"permalink":"/tags/enterprise-ai/","section":"Tags","summary":"","title":"Enterprise AI","type":"tags"},{"content":"","date":"2026-07-04","externalUrl":null,"permalink":"/tags/industrial-iot/","section":"Tags","summary":"","title":"Industrial IoT","type":"tags"},{"content":"","date":"2026-07-04","externalUrl":null,"permalink":"/tags/lifecycle-management/","section":"Tags","summary":"","title":"Lifecycle Management","type":"tags"},{"content":" The Continuous Edge AI Lifecycle: Why Intelligence Belongs Beyond the Cloud\nFor more than a decade, enterprise IT strategies have centered on consolidating workloads into hyperscale cloud infrastructure. Compute, storage, and applications migrated away from physical hardware toward virtualized and containerized environments, enabling unprecedented scalability and operational efficiency.\nToday, however, artificial intelligence is driving the next major architectural evolution. Rather than centralizing every workload, organizations are increasingly moving intelligence closer to where data is generated and decisions must be made. This shift has given rise to Edge AI—a computing model where AI inference executes directly on distributed devices while cloud infrastructure continues to provide centralized training, orchestration, and lifecycle management.\nEdge AI is not simply machine learning deployed on embedded hardware. It represents a continuous intelligence loop that connects edge devices, cloud infrastructure, and enterprise operations into a unified system capable of learning, adapting, and improving throughout its operational lifetime.\n☁️ Why Intelligence Cannot Live Only in the Cloud # Cloud computing transformed enterprise software by delivering elastic infrastructure, programmable services, and accelerated development cycles. While these advantages remain indispensable for large-scale AI training, they are insufficient for many real-world applications where decisions must occur within milliseconds.\nIndustries including robotics, automotive, aerospace, industrial automation, telecommunications, and critical infrastructure require deterministic execution that centralized cloud platforms alone cannot provide.\nThree primary factors are driving the adoption of Edge AI.\nLatency-Sensitive Decision Making # Many physical systems cannot afford the delays introduced by transmitting sensor data to remote data centers before executing a response.\nApplications such as autonomous driving, robotic motion control, machine automation, and energy distribution require local inference capable of making decisions in real time. While cloud environments remain ideal for training sophisticated AI models, execution must occur where actions happen.\nOperational Resilience # Mission-critical systems frequently operate under unreliable, intermittent, or intentionally isolated network conditions.\nManufacturing facilities, aircraft, offshore installations, defense platforms, and remote industrial sites cannot depend on constant cloud connectivity. Edge AI enables these systems to continue operating autonomously while synchronizing with centralized infrastructure whenever connectivity becomes available.\nCost Efficiency # Streaming raw telemetry from thousands—or even millions—of connected devices quickly becomes prohibitively expensive.\nBy processing sensor data locally, organizations significantly reduce:\nNetwork bandwidth consumption Cloud storage requirements Continuous compute costs Data transfer expenses Instead of transmitting every data point, edge systems forward only actionable information, anomalies, and operational insights.\nThe future of enterprise AI is therefore not a choice between cloud or edge. It is a coordinated architecture where each environment performs the tasks for which it is best suited.\n🔄 Understanding the Continuous Edge AI Lifecycle # Traditional software deployments followed a straightforward pattern: build, deploy, maintain, and eventually replace. AI-powered systems require a fundamentally different operating model because intelligence must continuously evolve.\nEdge AI establishes a closed-loop lifecycle where learning never stops.\nData Collection at the Edge # The lifecycle begins where data naturally originates.\nConnected devices—including industrial machines, autonomous vehicles, robotics platforms, sensors, and intelligent infrastructure—continuously observe the physical world.\nRather than functioning solely as execution platforms, these systems become valuable producers of operational intelligence by capturing:\nEnvironmental conditions Equipment behavior Usage patterns Performance anomalies Failure scenarios This real-world data provides the foundation for ongoing model improvement.\nCentralized Training and Model Optimization # Cloud infrastructure remains indispensable for computationally intensive AI development.\nUsing aggregated field data, engineering teams can:\nRetrain machine learning models Improve prediction accuracy Validate algorithm performance Simulate production environments Prepare updated software releases The cloud continues to serve as the centralized intelligence hub, while edge devices become distributed execution environments.\nContinuous Deployment to the Edge # Once updated models or applications are validated, they are safely distributed back to deployed devices.\nModern lifecycle management platforms extend cloud-native CI/CD principles into operational technology by enabling organizations to:\nRoll out updates incrementally Perform staged deployments Monitor rollout health Roll back failed releases Manage software versions across global fleets This continuous deployment capability allows thousands—or even millions—of distributed systems to evolve without requiring physical maintenance.\nThe cycle then repeats.\nEach deployment generates new operational data, enabling further refinement and increasingly capable AI systems over time.\n📈 The Edge AI Flywheel # Continuous learning creates a compounding effect that fundamentally changes how software generates value.\nThe cycle is straightforward:\nEdge devices generate operational data. Cloud platforms analyze and improve AI models. Updated intelligence is deployed back to production systems. Improved systems generate higher-quality data. Each iteration strengthens the entire ecosystem.\nUnlike traditional software, whose value gradually declines after deployment, Edge AI systems become increasingly capable as they accumulate operational experience.\nThis creates a self-reinforcing innovation flywheel where every deployment contributes to future improvements.\n💼 Business Value Beyond Technology # Organizations invest in Edge AI because it transforms business outcomes—not simply because it introduces new technology.\nContinuous Revenue Generation # Products equipped with continuously improving intelligence evolve from static assets into software-defined platforms.\nRather than relying solely on one-time hardware sales, organizations can introduce:\nSubscription services Premium software features AI-powered upgrades Outcome-based service contracts This creates recurring revenue throughout the product lifecycle.\nPredictive Operational Efficiency # Real-time inference enables organizations to anticipate problems before they occur.\nCommon applications include:\nPredictive maintenance Automated process optimization Energy management Quality inspection Operational anomaly detection These capabilities reduce downtime while improving asset utilization and operational efficiency.\nPlatform Ecosystems # Continuous Edge AI transforms standalone products into extensible platforms.\nDeployed systems increasingly integrate with:\nEnterprise analytics platforms Digital twins Fleet management solutions Business intelligence tools Third-party developer ecosystems This expands opportunities for innovation, customer engagement, and long-term monetization.\n⚙️ Architectural Requirements for Modern Edge AI # Many embedded systems currently in operation were designed for stability rather than continuous evolution.\nSupporting AI at the edge requires a modern architecture capable of balancing deterministic execution with ongoing software innovation.\nIntelligent Execution Platforms # Edge operating systems must efficiently support AI inference while meeting application-specific requirements.\nDepending on workload characteristics, organizations may require:\nReal-time operating systems (RTOS) for deterministic control Embedded Linux distributions for feature-rich environments Hybrid architectures combining both operating models These platforms should also support containerization, hardware acceleration, and integration with modern AI frameworks.\nSecure Data Movement # Continuous learning depends upon securely transferring operational insights from edge devices back to centralized infrastructure.\nEffective data pipelines prioritize:\nSelective data collection Bandwidth optimization Privacy protection Secure communications Rather than transmitting every sensor reading, organizations collect only information necessary for improving future intelligence.\nObservability # Operational visibility becomes an integral component of AI development.\nComprehensive observability allows organizations to monitor:\nModel performance System health Device behavior Runtime anomalies Operational trends This information feeds directly into future model refinement.\nEnterprise-Scale Lifecycle Management # Without automated software lifecycle management, Edge AI cannot scale.\nProduction platforms must support:\nContinuous software delivery Fleet-wide orchestration Incremental deployments Rollback capabilities Version governance Multi-platform hardware management These capabilities enable organizations to evolve deployed intelligence while maintaining operational stability.\n📊 Why Executives Should Pay Attention # For technology leaders, Edge AI represents more than another infrastructure investment.\nIt fundamentally changes how organizations create long-term competitive advantage.\nInstead of delivering products whose value gradually depreciates after deployment, companies can build intelligent systems that improve continuously throughout their operational lifespan.\nThis transition enables organizations to:\nAccelerate innovation cycles Differentiate through software capabilities Extend product lifecycles Improve customer retention Generate recurring revenue Build data-driven competitive advantages As AI becomes increasingly embedded within physical products, organizations capable of operating continuous learning loops will outperform competitors relying on traditional static software deployments.\n🔗 Closing the Loop: From Edge Intelligence to Continuous Innovation # Realizing the full potential of Edge AI requires more than deploying machine learning models to embedded devices. Success depends on an integrated ecosystem that connects execution, observability, analytics, and lifecycle management into a seamless operational platform.\nModern Edge AI environments combine intelligent operating systems capable of deterministic execution, cloud-native infrastructure for orchestration, analytics platforms that transform telemetry into actionable insights, and lifecycle management solutions that safely deliver software, firmware, and AI model updates across distributed fleets.\nTogether, these components complete the continuous learning loop:\nIntelligence is deployed to edge devices. Operational data flows back to centralized platforms. AI models are retrained and validated. Updated intelligence is securely redeployed. Each iteration increases system performance, operational efficiency, and business value.\nEdge AI is no longer a standalone technology trend—it is a foundational shift in enterprise computing. Organizations that embrace continuous learning architectures will transform connected devices into evolving intelligent systems, convert operational data into strategic assets, and deliver products that become more capable long after they leave the factory.\n","date":"2026-07-04","externalUrl":null,"permalink":"/industries/the-continuous-edge-ai-lifecycle-why-intelligence-belongs-beyond-the-cloud/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eThe Continuous Edge AI Lifecycle: Why Intelligence Belongs Beyond the Cloud\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eFor more than a decade, enterprise IT strategies have centered on consolidating workloads into hyperscale cloud infrastructure. Compute, storage, and applications migrated away from physical hardware toward virtualized and containerized environments, enabling unprecedented scalability and operational efficiency.\u003c/p\u003e","title":"The Continuous Edge AI Lifecycle: Why Intelligence Belongs Beyond the Cloud","type":"industries"},{"content":" Edge AI in the Real World: Building Scalable, Reliable AI Systems\nArtificial intelligence is rapidly moving beyond centralized cloud infrastructure into physical environments where decisions must be made in real time. From industrial automation and robotics to aerospace and autonomous systems, Edge AI is reshaping how enterprises deploy intelligent applications.\nHowever, deploying AI outside the data center is far more than relocating inference workloads closer to devices. It introduces new architectural, operational, and lifecycle challenges that traditional cloud-native strategies were never designed to address. Organizations that recognize Edge AI as a distinct computing paradigm are better positioned to build scalable, resilient, and continuously evolving intelligent systems.\n🚀 Why Edge AI Requires a Different Architectural Approach # The evolution from centralized AI to Edge AI closely resembles previous transitions in enterprise computing. Just as cloud adoption demanded new operational models, Edge AI introduces an entirely new discipline that combines:\nArtificial intelligence Real-time embedded computing Distributed infrastructure Fleet lifecycle management Operational observability Treating Edge AI as simply an extension of cloud infrastructure often leads to deployment bottlenecks and scalability issues. Successful implementations instead embrace the unique characteristics of edge environments, including limited connectivity, heterogeneous hardware, deterministic execution, and long operational lifecycles.\n⚙️ Real-Time Embedded Systems Remain the Foundation # Many Edge AI deployments operate in environments where latency and deterministic behavior are non-negotiable.\nApplications such as:\nIndustrial automation Robotics Aerospace systems Autonomous vehicles Mission-critical infrastructure require AI inference to coexist with safety-critical control loops.\nUnlike traditional cloud workloads, these systems cannot tolerate unpredictable execution delays. AI must enhance decision-making without compromising deterministic system behavior, making real-time embedded operating systems an essential foundation for production deployments.\n🔄 Lifecycle Management Is Critical for Long-Term Success # Deploying an AI model is only the beginning of an Edge AI system\u0026rsquo;s lifecycle.\nProduction environments continuously evolve as:\nMachine learning models improve Applications receive new features Security vulnerabilities are patched Hardware platforms expand New devices join existing fleets Managing these changes across geographically distributed and intermittently connected devices requires a comprehensive lifecycle management framework.\nBy extending Continuous Integration and Continuous Deployment (CI/CD) principles beyond the cloud, organizations can safely:\nDeploy new AI models Roll back problematic releases Track software versions Monitor system health Maintain observability across distributed fleets This approach enables enterprises to continuously improve deployed intelligence without disrupting mission-critical operations.\n🌐 Building a Unified Cloud-to-Edge Infrastructure # Modern Edge AI architectures span multiple computing layers rather than relying on a single execution environment.\nA well-designed infrastructure typically includes:\nCentralized AI data centers for model training Regional edge clusters for coordination and aggregation Embedded edge devices for low-latency inference and control Each layer serves a distinct purpose:\nLayer Primary Role Central Cloud Model training, large-scale analytics, orchestration Regional Edge Data aggregation, localized intelligence, workload coordination Embedded Devices Real-time inference, deterministic control, sensor interaction This distributed architecture allows organizations to place compute, storage, and AI inference where they deliver the greatest operational value while minimizing unnecessary data movement and latency.\n🏗️ Designing Edge AI for Continuous Change # The most significant challenges in Edge AI are rarely caused by machine learning algorithms themselves.\nInstead, enterprises encounter difficulties at the intersection of:\nSoftware and physical systems Autonomous decision-making and operational accountability Continuous learning and production stability Distributed infrastructure and lifecycle governance Organizations that acknowledge these structural challenges early can build platforms that:\nScale efficiently Adapt safely Improve continuously Support long operational lifecycles Conversely, organizations that overlook these architectural considerations often struggle to move beyond pilot projects into full-scale production deployments.\n📊 A Complete Edge AI Architecture # Successful enterprise Edge AI platforms integrate several complementary capabilities into a unified architecture.\nReal-Time Execution # Provides deterministic behavior for latency-sensitive applications operating in physical environments.\nDistributed Infrastructure # Connects cloud platforms, regional edge resources, and embedded devices into a cohesive computing ecosystem.\nData Collection and Observability # Captures operational insights that enable continuous optimization, model improvement, and predictive maintenance.\nLifecycle Management # Ensures software, AI models, and system configurations remain secure, consistent, and up to date across distributed device fleets.\nTogether, these capabilities create sustainable Edge AI systems that remain operational, maintainable, and adaptable throughout years of deployment.\n🌍 From AI Experiments to Operational Reality # The industry has already crossed the threshold where AI is leaving centralized data centers and becoming embedded within physical systems.\nThe remaining challenge is no longer whether Edge AI is technically feasible, but whether enterprise architectures are prepared to support its operational complexity.\nOrganizations deploying intelligent systems at the edge must account for:\nReal-time execution constraints Long-lived embedded deployments Distributed fleet management Heterogeneous hardware platforms Continuous software and AI model evolution Addressing these requirements demands an architectural strategy that spans the full software lifecycle—from centralized cloud environments to resource-constrained embedded devices.\nEnterprises that invest in this foundation can confidently transition from isolated AI demonstrations to production-scale intelligent systems capable of operating reliably in real-world environments.\n","date":"2026-07-04","externalUrl":null,"permalink":"/industries/edge-ai-in-the-real-world-building-scalable-reliable-ai-systems/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eEdge AI in the Real World: Building Scalable, Reliable AI Systems\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eArtificial intelligence is rapidly moving beyond centralized cloud infrastructure into physical environments where decisions must be made in real time. From industrial automation and robotics to aerospace and autonomous systems, Edge AI is reshaping how enterprises deploy intelligent applications.\u003c/p\u003e","title":"Edge AI in the Real World: Building Scalable, Reliable AI Systems","type":"industries"},{"content":"","date":"2026-07-04","externalUrl":null,"permalink":"/tags/industrial-automation/","section":"Tags","summary":"","title":"Industrial Automation","type":"tags"},{"content":"","date":"2026-07-03","externalUrl":null,"permalink":"/tags/linux/","section":"Tags","summary":"","title":"Linux","type":"tags"},{"content":" Why Wind River Leads Functional Safety RTOS for Next-Generation Robotics\nIndustrial robotics is undergoing a profound transformation. Traditional automation systems built around deterministic motion control are rapidly evolving into intelligent platforms capable of perception, reasoning, and autonomous decision-making. As this transition accelerates, the software stack beneath modern robots has become just as important as the hardware itself.\nReal-time operating systems (RTOSs) now serve as the foundation for functional safety, deterministic control, AI integration, and long-term system reliability. Rather than simply scheduling tasks, today\u0026rsquo;s robotics operating systems must support mixed-criticality workloads, safety certification, edge computing, and cloud-connected applications simultaneously.\nThis evolution helps explain why Wind River was recently recognized by ABI Research as a leader in its Commercial Robotic Functional Safety RTOS competitive assessment. According to the report, Wind River achieved the highest implementation score, reflecting the company\u0026rsquo;s mature deployment capabilities, extensive safety certifications, and broad industry adoption.\nThe recognition highlights a broader industry trend: as robots become increasingly intelligent, the operating system is evolving from a software component into strategic infrastructure.\n🤖 Functional Safety Is Becoming a Core Robotics Requirement # Historically, many industrial robots operated inside highly controlled environments.\nCharacteristics of conventional industrial automation included:\nFixed production workflows Predictable operating conditions Deterministic control logic Minimal environmental variation Modern robotics presents a very different challenge.\nToday\u0026rsquo;s systems increasingly operate in environments that require:\nDynamic perception AI-assisted decision-making Autonomous adaptation Human-robot collaboration Cloud and edge connectivity These capabilities introduce significant complexity while simultaneously increasing safety requirements.\nAs robot manufacturers and system integrators pursue higher levels of autonomy, regulatory compliance and functional safety certification have become essential parts of system architecture rather than optional additions.\nAccording to ABI Research, modern robotic operating systems must simultaneously provide:\nDeterministic real-time performance Functional safety certification support Reliable software architecture Mature hardware compatibility Mixed-criticality execution environments Meeting all of these requirements consistently is a considerable engineering challenge.\n⚙️ Wind River\u0026rsquo;s Strength Lies in Engineering Maturity # Rather than focusing solely on theoretical performance, ABI Research emphasized Wind River\u0026rsquo;s implementation capabilities.\nSeveral factors contributed to this assessment.\nExtensive Production Deployment # Wind River Helix RTOS has accumulated decades of deployment across mission-critical industries including:\nIndustrial automation Aerospace Defense Automotive Medical systems Telecommunications Large production deployments provide practical validation that laboratory benchmarks alone cannot offer.\nDeep Functional Safety Expertise # Industrial robotics increasingly relies on internationally recognized safety standards throughout system development.\nWind River has invested heavily in supporting safety-certified environments that simplify:\nFunctional safety planning Certification workflows System validation Regulatory compliance This reduces engineering complexity for manufacturers building safety-critical robotic systems.\nMature Hardware Ecosystem # A robotics operating system must integrate with a wide range of processors, controllers, sensors, accelerators, and development platforms.\nWind River\u0026rsquo;s broad ecosystem support enables developers to shorten integration cycles while reducing platform risk throughout the product lifecycle.\n🧠 Building a Software Foundation for Intelligent Robots # The growing complexity of robotics workloads has created demand for software platforms capable of supporting both deterministic control and AI-driven applications.\nWind River addresses this through two complementary operating systems.\nWind River Helix RTOS # Helix RTOS targets workloads where predictability and certification are critical.\nTypical applications include:\nMotion control Safety-critical control loops Industrial controllers Functional safety systems Hard real-time scheduling Its emphasis remains deterministic execution with minimal latency variation.\nWind River Helix Linux # For higher-level software, Wind River provides Helix Linux.\nThis platform focuses on:\nEdge AI deployment Cloud-native development Containerized applications AI frameworks Open-source ecosystems Rather than replacing the RTOS, Helix Linux complements it by providing a scalable environment for intelligent applications.\nSupporting Mixed-Criticality Systems # Modern robots increasingly execute multiple workload types simultaneously.\nExamples include:\nSafety-critical motion control Computer vision Machine learning inference Fleet communication Predictive maintenance Human-machine interfaces Each workload carries different timing, reliability, and safety requirements.\nSupporting these heterogeneous applications within a unified architecture has become a defining capability for next-generation robotics software platforms.\n🚀 Case Study: Yaskawa\u0026rsquo;s MOTOMAN NEXT # Wind River\u0026rsquo;s role in industrial robotics extends beyond theory into commercial deployment.\nOne notable example is Yaskawa Electric, a global leader in industrial robots, servo motors, and motion control systems.\nDeveloping an AI-Native Industrial Robot # Yaskawa designed its MOTOMAN NEXT platform to move beyond conventional automation.\nThe objective was to develop robots capable of:\nEnvironmental awareness Autonomous decision-making Adaptive task execution AI-driven operational intelligence Achieving these goals required significantly greater software flexibility than previous industrial robot generations.\nWind River Helix Linux Meets NVIDIA Jetson # Within MOTOMAN NEXT, Wind River Helix Linux serves as the software foundation for the robot\u0026rsquo;s autonomous control system.\nThe platform operates alongside NVIDIA Jetson hardware, providing:\nEdge AI acceleration Embedded computing AI software frameworks ROS support Scalable deployment Together, the hardware and software stack enables robots to process perception data locally while maintaining industrial-grade reliability.\nExpanding Industrial Automation # The resulting platform allows robots to tackle tasks that previously depended heavily on human judgment.\nExamples include:\nDynamic object handling Environmental adaptation Intelligent workflow optimization Complex scene understanding Rather than following predefined sequences, robots can respond more effectively to changing operating conditions.\n🏭 From Operating System to Robotics Infrastructure # As industrial robotics evolves, the underlying operating system is no longer simply a scheduling layer.\nInstead, it increasingly functions as core infrastructure connecting multiple system domains.\nModern robotics software must support:\nReal-time control Functional safety AI workloads Edge computing Cloud integration Long-term maintainability Continuous software updates This broader responsibility explains why software architecture has become a strategic consideration for robotics manufacturers.\nCompanies are increasingly evaluating operating systems not only by performance, but also by ecosystem maturity, deployment experience, certification support, and lifecycle management.\n🔒 Why Functional Safety and AI Must Evolve Together # Artificial intelligence significantly expands what robots can accomplish.\nHowever, greater autonomy also increases system complexity.\nEvery additional perception model, planning algorithm, or AI service introduces new interactions with safety-critical control systems.\nConsequently, future robotics platforms must balance two competing priorities:\nMaximum intelligence and adaptability Guaranteed deterministic safety behavior Mixed-criticality architectures provide one practical solution by allowing safety-certified control functions and AI applications to coexist while maintaining strict isolation where necessary.\nThis approach enables continuous innovation without compromising operational reliability.\n📈 Looking Ahead # The next generation of industrial robots will operate in increasingly complex environments that demand both intelligent decision-making and uncompromising safety.\nAs these systems evolve, the operating system becomes a foundational technology that connects deterministic control, AI workloads, edge computing, and functional safety into a cohesive software platform.\nWind River\u0026rsquo;s recognition by ABI Research, combined with commercial deployments such as Yaskawa\u0026rsquo;s MOTOMAN NEXT, illustrates this broader industry direction. Rather than serving solely as an RTOS vendor, Wind River is positioning its software portfolio as the infrastructure underpinning intelligent, software-defined robotics.\nWith robotics continuing to expand into autonomous manufacturing, logistics, healthcare, and other safety-critical industries, operating systems capable of supporting certified real-time control alongside modern AI applications will play an increasingly central role in enabling reliable, scalable, and future-ready robotic systems.\n","date":"2026-07-03","externalUrl":null,"permalink":"/industries/why-wind-river-leads-functional-safety-rtos-for-next-gen-robotics/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eWhy Wind River Leads Functional Safety RTOS for Next-Generation Robotics\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eIndustrial robotics is undergoing a profound transformation. Traditional automation systems built around deterministic motion control are rapidly evolving into intelligent platforms capable of perception, reasoning, and autonomous decision-making. As this transition accelerates, the software stack beneath modern robots has become just as important as the hardware itself.\u003c/p\u003e","title":"Why Wind River Leads Functional Safety RTOS for Next-Generation Robotics","type":"industries"},{"content":"","date":"2026-06-30","externalUrl":null,"permalink":"/tags/cloud-native/","section":"Tags","summary":"","title":"Cloud-Native","type":"tags"},{"content":"","date":"2026-06-30","externalUrl":null,"permalink":"/tags/safety-critical/","section":"Tags","summary":"","title":"Safety-Critical","type":"tags"},{"content":" Why Upgrade to VxWorks 7 for Intelligent Edge Computing\nThe embedded computing landscape has changed dramatically over the past decade. Modern edge devices are no longer limited to collecting and forwarding data—they are expected to perform complex analytics, execute AI inference, communicate securely, and operate autonomously in real time.\nTo meet these evolving requirements, embedded software platforms must deliver deterministic performance while embracing modern technologies such as containers, cloud-native workflows, and machine learning. VxWorks 7 represents Wind River\u0026rsquo;s response to these demands, combining the reliability of a proven commercial RTOS with capabilities designed for the intelligent edge.\nThis article explores why organizations are upgrading to VxWorks 7, highlights its major innovations, and outlines key considerations when migrating from legacy VxWorks platforms.\n🌐 The Rise of the Intelligent Edge # Traditional edge devices primarily collected sensor data before transmitting it to centralized servers or cloud infrastructure for processing.\nToday\u0026rsquo;s intelligent edge takes a different approach by processing data directly on the device. This architecture enables systems to react immediately without depending on network latency or cloud connectivity.\nCommon intelligent edge applications include:\nSmart manufacturing and production automation Autonomous and connected vehicles Healthcare monitoring and medical devices Aerospace and defense systems Industrial robotics Intelligent transportation infrastructure As organizations deploy millions of IoT sensors across manufacturing, mining, utilities, and logistics, the amount of generated data continues to grow exponentially.\nProcessing data locally provides several important advantages:\nReduced latency Lower network bandwidth consumption Improved reliability during intermittent connectivity Enhanced privacy and data sovereignty Faster decision-making for safety-critical applications These benefits make intelligent edge computing a fundamental requirement for modern embedded systems.\n🚀 Challenges Facing Modern Edge Platforms # Building intelligent edge solutions extends beyond simply deploying an operating system.\nEngineering teams must address several technical challenges simultaneously, including:\nAI and machine learning execution on constrained hardware Deterministic real-time performance Continuous software updates throughout long product lifecycles Secure software supply chains and Software Bill of Materials (SBOM) management Regulatory compliance and functional safety certification Multi-vendor hardware portability Remote provisioning, monitoring, and lifecycle management Scalable testing and validation across distributed deployments A modern RTOS must provide the infrastructure necessary to address these requirements without sacrificing determinism or reliability.\n📈 VxWorks 7: Continuous Innovation # For nearly three decades, VxWorks has remained one of the industry\u0026rsquo;s most widely deployed commercial real-time operating systems for mission-critical applications.\nSince the introduction of VxWorks 7 in 2014, Wind River has continuously expanded the platform to support cloud-native development, AI workloads, and increasingly sophisticated embedded systems.\n2021 Milestones # Major additions included:\nAI and machine learning framework integration Python 3.9 support Pandas libraries TensorFlow Lite OCI-compliant container runtime Microsoft OCI Embedded SDK integration Performance and safety enhancements A particularly significant milestone was becoming the first commercial RTOS to support the Open Container Initiative (OCI), enabling containerized workloads on deterministic embedded systems.\n2022 Enhancements # The platform continued evolving with improvements focused on cloud deployment and development tooling.\nHighlights included:\nAWS Graviton EC2 support Expanded OCI container capabilities Kubernetes integration improvements LLVM/Clang 12.0.1 toolchain Enhanced Gigabit Ethernet performance Expanded Software Bill of Materials (SBOM) capabilities 2023 Advancements # Recent releases introduced additional functionality for safety-critical and industrial environments.\nKey additions included:\nKubernetes kubelet support for edge orchestration DO-178C DAL-A certification support ISO 26262 ASIL-D capabilities OpenSSL 3.1 integration AI/ML feedback loop improvements TSN networking optimizations OPC UA performance enhancements These enhancements position VxWorks 7 as a modern platform for connected, intelligent, and safety-certified edge devices.\n🤖 AI and Machine Learning at the Edge # Artificial intelligence is rapidly becoming a core requirement across embedded industries.\nVxWorks 7 enables AI and machine learning models to execute directly on embedded devices, eliminating the need to transmit every inference request to centralized infrastructure.\nRunning inference locally provides several advantages:\nDeterministic response times Lower communication costs Reduced cloud dependency Improved privacy Operation in disconnected environments These capabilities enable applications such as predictive maintenance, machine vision, autonomous navigation, and real-time anomaly detection.\n📦 Cloud-Native and Containerized Applications # One of the most transformative additions in VxWorks 7 is support for containerized application deployment.\nOCI compliance allows developers to package software consistently across development, testing, and production environments while simplifying deployment and lifecycle management.\nBenefits include:\nPortable application packaging Smaller deployment footprints Simplified software updates Kubernetes-based orchestration Remote application deployment Independent application lifecycle management VxWorks 7 also supports major container registries, including:\nAmazon Elastic Container Registry (ECR) Docker Hub Harbor Containerization enables organizations to extend the capabilities of deployed devices without replacing existing hardware.\n💻 Broad Hardware and Software Support # Modern embedded products often span multiple processor architectures throughout their lifecycle.\nVxWorks 7 supports a broad range of hardware platforms, including:\nArm PowerPC x86 RISC-V Additional embedded processor families This portability simplifies long-term product evolution and reduces vendor lock-in.\nExpanded Software Bill of Materials (SBOM) support also improves software transparency across complex embedded supply chains.\n🔒 Security and Functional Safety # Security and certification remain fundamental requirements for mission-critical embedded systems.\nVxWorks 7 incorporates numerous technologies designed to strengthen system resilience and simplify compliance.\nFunctional Safety # The platform supports stringent industry standards, including:\nDO-178C DAL-A ISO 26262 ASIL-D Collectively, Wind River technologies have supported hundreds of safety certification programs across aerospace, automotive, industrial, and medical industries.\nSecurity Enhancements # Built-in security capabilities include:\nContinuous CVE monitoring Kernel sanitizer support Stack-smashing protection Improved authentication mechanisms Hardened runtime environment These features help developers reduce attack surfaces while maintaining deterministic system behavior.\n🛠️ Modern Development Experience # Embedded software development continues to evolve alongside cloud infrastructure and modern programming languages.\nVxWorks 7 embraces these trends with support for:\nC++17 Rust LLVM/Clang toolchains Wind River Studio Developer Cloud-based development workflows Improved debugging and deployment tooling These capabilities enable teams to adopt contemporary software engineering practices while continuing to develop deterministic real-time applications.\n⚡ Performance Optimizations # Performance improvements remain a major focus of every VxWorks release.\nAreas receiving continuous optimization include:\nTime-Sensitive Networking (TSN) OPC UA communication Kernel scheduling Networking stack performance Storage subsystems Driver framework improvements These enhancements allow developers to build increasingly capable edge platforms without compromising real-time responsiveness.\n🔄 Migration Considerations # Although upgrading to VxWorks 7 offers substantial benefits, migration projects require careful planning.\nVxBus Generation 2 # VxWorks 7 introduces VxBus Gen 2, providing a more flexible and efficient driver framework.\nHowever, Gen 2 is not backward compatible with legacy VxWorks 5.x VxBus Gen 1 drivers.\nExisting drivers may require refactoring or replacement during migration.\nAPI and Toolchain Updates # Applications developed for older VxWorks releases may require:\nAPI updates Compiler compatibility changes Build system modifications Evaluating these changes early helps reduce migration risk.\nDevelopment Environment # Wind River Studio Developer introduces cloud-connected workflows and modern tooling.\nFor organizations migrating from VxWorks 6.x, Wind River Workbench remains available for many existing development environments, providing a gradual transition path.\nAuthentication Improvements # User authentication has been modernized and no longer depends on the network stack, improving security while simplifying deployment.\nCertification Reuse # Projects requiring regulatory certification can benefit from reusable modular software components, reducing recertification effort during system modernization.\nBefore beginning migration, developers should consult Wind River\u0026rsquo;s BSP Query Tool and official migration documentation to verify hardware compatibility and identify platform-specific considerations.\n🚀 Extending the Life of Embedded Systems # Modernization does not always require replacing deployed hardware.\nVxWorks 7 enables organizations to introduce new capabilities into long-lived embedded products through software updates and containerized applications.\nPotential use cases include:\nRemote feature activation Subscription-based functionality Predictive maintenance AI-enhanced vision systems Advanced driver assistance Industrial automation Edge analytics This approach helps maximize the value of existing hardware investments while enabling continuous software innovation.\n🏆 Why Choose Wind River? # Wind River continues to be a leading provider of commercial embedded software platforms, backed by decades of experience supporting mission-critical industries.\nOrganizations benefit from:\nMore than 40 years of embedded systems expertise Global 24/7 technical support Professional migration and consulting services Comprehensive training programs Long-term product lifecycle support For organizations modernizing existing embedded systems or designing next-generation intelligent edge platforms, VxWorks 7 provides a mature RTOS that combines deterministic real-time performance with cloud-native technologies, AI readiness, advanced security, and functional safety certifications. Its continuous evolution ensures developers can build scalable, secure, and maintainable edge solutions capable of meeting today\u0026rsquo;s demanding workloads while remaining adaptable for future innovations.\n","date":"2026-06-30","externalUrl":null,"permalink":"/industries/why-upgrade-to-vxworks-7-for-intelligent-edge-computing/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eWhy Upgrade to VxWorks 7 for Intelligent Edge Computing\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eThe embedded computing landscape has changed dramatically over the past decade. Modern edge devices are no longer limited to collecting and forwarding data—they are expected to perform complex analytics, execute AI inference, communicate securely, and operate autonomously in real time.\u003c/p\u003e","title":"Why Upgrade to VxWorks 7 for Intelligent Edge Computing","type":"industries"},{"content":"","date":"2026-06-30","externalUrl":null,"permalink":"/tags/ace/","section":"Tags","summary":"","title":"ACE","type":"tags"},{"content":"","date":"2026-06-30","externalUrl":null,"permalink":"/tags/dds/","section":"Tags","summary":"","title":"DDS","type":"tags"},{"content":" Getting Started with ACE, TAO, and OpenDDS on VxWorks 7\nBuilding distributed real-time applications on VxWorks often requires a reliable middleware stack that provides portability, deterministic behavior, and standards-based communication. Object Computing, Inc. (OCI), a Wind River partner, provides pre-built packages for ACE, TAO, and OpenDDS, making it significantly easier to integrate these technologies into VxWorks 7 development environments.\nThis guide covers installation methods, VxWorks Source Build (VSB) configuration, optional DDS Security dependencies, Xerces-C++ integration, and application build workflows using MPC.\n🚀 Overview # OCI distributes free Marketplace packages for the following components:\nACE (ADAPTIVE Communication Environment) — A mature C++ framework that provides cross-platform networking, concurrency, and operating system abstractions. TAO (The ACE ORB) — A CORBA implementation built on top of ACE for high-performance distributed applications. OpenDDS — An open-source implementation of the OMG Data Distribution Service (DDS) standard for real-time publish-subscribe communication. OpenDDS leverages ACE for portability while delivering enterprise-grade DDS functionality, including:\nStrongly typed publish-subscribe communication Comprehensive DDS Quality of Service (QoS) RTPS (Real-Time Publish-Subscribe) interoperability DDS Security support High-performance middleware for embedded and distributed systems OCI also offers professional consulting, training, and commercial support for these technologies.\n📦 Additional Dependencies # Depending on your host operating system and required features, additional software may be necessary.\nWindows Hosts # Install ActiveState Perl, which is required by several build scripts.\nDDS Security Support # DDS Security requires the following components:\nWind River Cryptography Libraries Apache Xerces-C++ 3.2.1 (this exact version) CMake Later versions of Xerces are not officially supported for this workflow.\n🛒 Installing Through the VxWorks Marketplace # ACE, TAO, and OpenDDS are distributed as independent Marketplace packages. Always ensure the installed package versions match the versions documented for your project.\nPackage Dependencies # Understanding the package hierarchy helps avoid unnecessary installations:\nTAO already includes ACE. OpenDDS includes both ACE and TAO. For most projects, installing only the OpenDDS package is sufficient.\nRPM Package Overview # RPM Package Version Included with ACE Included with TAO Included with OpenDDS oci_ace 6.2.15.0 ✓ ✓ ✓ oci_tao_host_linux 2.2.15.0 ✓ ✓ oci_tao_host_windows 2.2.15.0 ✓ ✓ oci_tao 2.2.15.0 ✓ ✓ oci_opendds_host_linux 3.13.0.0 ✓ oci_opendds_host_windows 3.13.0.0 ✓ oci_opendds 3.13.0.0 ✓ When using the Marketplace installer, all required package dependencies are resolved automatically.\n⚙️ Manual RPM Installation # If Marketplace is unavailable, packages can be installed manually using the command-line package manager described in the Wind River Product Installation and Licensing Developer\u0026rsquo;s Guide.\nTo prevent dependency issues, install all related RPM packages together rather than individually.\n🏗️ Configuring the VxWorks Source Build (VSB) # After installing the required packages, configure your VSB to include the OCI middleware layers.\nRequired Configuration Steps # Create a new VSB or modify an existing one. Disable: LANG_LIB_CPLUSPLUS_USER_2011 This layer should be disabled because GCC 4.8.x shipped with VxWorks 7 does not fully implement the required C++11 features.\nEnable the following networking layers: OCI_ACE OCI_TAO OCI_OPENDDS Using Add with Dependencies is recommended because enabling OpenDDS automatically selects the required ACE and TAO layers.\nACE Configuration Options # The ACE layer exposes several build options that also affect TAO and OpenDDS:\nKernel configuration POSIX thread support Static or shared libraries Debug builds Optimization levels Xerces integration Configure these options according to your project\u0026rsquo;s deployment requirements.\n🔐 Enabling DDS Security # DDS Security requires additional middleware and runtime components.\nRequired Components # Enable the following before building OpenDDS Security:\nUNIX compatibility layer OpenSSL layer Xerces-C++ 3.2.1 The recommended workflow is:\nBuild a minimal VSB without ACE, TAO, or OpenDDS. Build and install Xerces. Enable: OCI_ACE_RTP_XERCES Specify the Xerces installation directory. Enable DDS Security inside the OpenDDS configuration menu. Build Recommendation # Disable parallel builds during VSB generation because layer dependencies can produce inconsistent build results.\n🛠️ Building Xerces-C++ 3.2.1 # DDS Security depends on Apache Xerces-C++ 3.2.1.\nBuild Procedure # Download and extract Xerces-C++ 3.2.1. Install CMake and ensure it is available on your system PATH. Create a CMake Shared User Library project in Wind River Workbench. Associate the project with your VSB. Remove the Diab compiler build specification and retain only the GNU build specification. Configure the installation directory: -DCMAKE_INSTALL_PREFIX=/path/to/installed/xerces (Optional) Build a static library by duplicating the build specification and adding: -DBUILD_SHARED_LIBS=OFF Run the OCI preparation script. Windows\ncd xerces_rtp perl %WIND_BASE%\\pkgs\\net\\oci_ace-6.2.15.0\\misc\\xerces_vxworks.pl Linux\ncd xerces_rtp perl $WIND_BASE/pkgs/net/oci_ace-6.2.15.0/misc/xerces_vxworks.pl Build the project using the install target. 🧩 Building Applications # After the middleware has been integrated into the VSB, applications can be compiled using the generated libraries.\nInclude Directories # Kernel applications:\n{VSB_DIR}/krnl/h/public RTP applications:\n{VSB_DIR}/usr/h/public Library Directories # Kernel:\n{VSB_DIR}/krnl/{CPU}/gnu RTP:\n{VSB_DIR}/usr/lib/gnu Host Tools # IDL compilers and other code-generation tools are located in:\n{WIND_HOME}/partners/oci_tao-{VERSION}/{HOST_OS}/bin and the equivalent OpenDDS host tools directory.\n⚡ Generating Build Files with MPC # MPC (Makefile, Project, and Workspace Creator) is included with the ACE distribution and generates project files for supported build systems.\nRequired Environment Variables # Typical Linux configuration:\nVSB_DIR MPC_ROOT ACE_ROOT TAO_ROOT DDS_ROOT TAO_HOST_TOOLS OPENDDS_HOST_TOOLS XERCESCROOT (DDS Security only) Sample MPC Project # project: dcps_exe, dcps_rtps_udp { TypeSupport_Files { Messenger.idl } // RTP: // libpaths += $(VSB_DIR)/usr/lib/gnu // Kernel: // libpaths += $(VSB_DIR)/krnl/$(CPU)/gnu } Generate GNU makefiles with:\n$ACE_ROOT/bin/mwc.pl -type gnuace Building with DDS Security # Generate projects with DDS Security enabled:\n$ACE_ROOT/bin/mwc.pl \\ -type gnuace \\ -features no_opendds_security=0 \\ -features openssl=0,no_vxworks_openssl=0 ⚙️ Build Variables # The following variables should match your VSB configuration.\nConfiguration Variable Value Notes Kernel build rtp 0 Kernel application Kernel pthread support pthread 1 Enable POSIX threads Static libraries staticlibs_only 1 Required for static builds Debug disabled debug 0 Default is 1 Optimization disabled optimize 0 Default is 1 Compiler TOOL gnu GNU toolchain For DDS Security builds, also specify:\nOPENDDS_SECURITY_MACRO=OPENDDS_SECURITY no_opendds_security=0 📚 Resources # The following documentation provides additional implementation details and reference material:\nOCI ACE documentation OCI TAO documentation and Developer\u0026rsquo;s Guide OpenDDS project website OpenDDS Developer\u0026rsquo;s Guide DDS Security for OpenDDS documentation MPC project repository OCI professional support and training resources These references cover advanced configuration topics, middleware architecture, deployment strategies, and API documentation for production VxWorks environments.\n","date":"2026-06-30","externalUrl":null,"permalink":"/app/getting-started-with-ace-tao-and-opendds-on-vxworks-7/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eGetting Started with ACE, TAO, and OpenDDS on VxWorks 7\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eBuilding distributed real-time applications on VxWorks often requires a reliable middleware stack that provides portability, deterministic behavior, and standards-based communication. Object Computing, Inc. (OCI), a Wind River partner, provides pre-built packages for \u003cstrong\u003eACE\u003c/strong\u003e, \u003cstrong\u003eTAO\u003c/strong\u003e, and \u003cstrong\u003eOpenDDS\u003c/strong\u003e, making it significantly easier to integrate these technologies into VxWorks 7 development environments.\u003c/p\u003e","title":"Getting Started with ACE, TAO, and OpenDDS on VxWorks 7","type":"app"},{"content":"","date":"2026-06-30","externalUrl":null,"permalink":"/tags/middleware/","section":"Tags","summary":"","title":"Middleware","type":"tags"},{"content":"","date":"2026-06-30","externalUrl":null,"permalink":"/tags/opendds/","section":"Tags","summary":"","title":"OpenDDS","type":"tags"},{"content":"","date":"2026-06-30","externalUrl":null,"permalink":"/tags/tao/","section":"Tags","summary":"","title":"TAO","type":"tags"},{"content":"","date":"2026-06-29","externalUrl":null,"permalink":"/tags/digital-china/","section":"Tags","summary":"","title":"Digital China","type":"tags"},{"content":" Digital China and Wind River Expand Strategic Partnership for Industrial Digitalization\nDigital China and Wind River have strengthened their strategic partnership to accelerate the adoption of industrial digital technologies, marking a significant step toward deeper collaboration in industrial software, embedded systems, virtualization, and enterprise digital transformation.\nDuring a recent executive-level meeting, Jay Bellissimo, Global President of Wind River, led a senior leadership delegation to Digital China\u0026rsquo;s headquarters to discuss the next phase of cooperation. Building upon a previously signed strategic agreement, both companies focused on transforming their partnership into concrete business initiatives spanning technology integration, solution development, and market expansion.\nThe meeting signals a transition from strategic alignment to execution, with both organizations aiming to jointly advance the localization and deployment of next-generation industrial technologies.\n🤝 Strengthening Strategic Collaboration # The visit began with a tour of the Digital China Innovation Center, where Wind River\u0026rsquo;s executive team explored Digital China\u0026rsquo;s latest achievements in:\nDigital infrastructure Industry-specific intelligent solutions Technology innovation ecosystems Enterprise digital transformation platforms The visit provided Wind River with a comprehensive view of Digital China\u0026rsquo;s capabilities in delivering large-scale digital transformation projects across multiple industries while leveraging its extensive domestic service network.\nThis shared understanding establishes a stronger foundation for long-term collaboration in China\u0026rsquo;s rapidly evolving industrial technology market.\n🏭 Expanding Cooperation Across Industrial Technologies # During the executive symposium, both companies held in-depth discussions on several strategic technology areas critical to modern industrial computing.\nKey Areas of Collaboration # The partnership will focus on:\nIndustrial software platforms Embedded operating systems Industrial virtualization technologies Operational Technology (OT) and Information Technology (IT) convergence Enterprise digital infrastructure Intelligent industry solutions These technologies are increasingly becoming foundational components of Industry 4.0 initiatives, enabling manufacturers and enterprises to modernize operations while improving system flexibility, reliability, and efficiency.\n🚀 Digital China Sees Strong Growth Opportunities # According to Zhao Lin, Commissar of Digital China\u0026rsquo;s Enterprise Business Group (EBG), China\u0026rsquo;s digital economy continues to accelerate, creating growing demand for advanced industrial software and digital infrastructure.\nHe emphasized that industrial software has become one of the key building blocks supporting industrial modernization and digital transformation.\nZhao also highlighted Wind River\u0026rsquo;s decades of technological expertise and expressed confidence that deeper collaboration would enable both organizations to better address the evolving needs of China\u0026rsquo;s industrial market.\nDigital China plans to leverage its:\nNationwide service capabilities Extensive enterprise customer base Rich implementation experience Broad ecosystem partnerships to help accelerate the deployment of advanced industrial technologies across multiple sectors.\n💻 Wind River Accelerates Beyond Traditional Embedded Systems # Jay Bellissimo outlined Wind River\u0026rsquo;s ongoing strategic transformation during the meeting.\nHaving spent more than four decades developing embedded software technologies, Wind River has established itself as one of the industry\u0026rsquo;s leading providers of real-time operating systems, embedded platforms, and mission-critical software solutions.\nAccording to Bellissimo, the company is now expanding beyond its traditional Operational Technology (OT) focus into broader enterprise Information Technology (IT) environments.\nThis strategic evolution includes:\nAI-powered software platforms Enterprise infrastructure solutions Intelligent edge computing Expanded virtualization technologies Integrated OT-IT architectures Bellissimo also noted that Wind River\u0026rsquo;s AI-enabled products have successfully replaced several mainstream competing solutions in overseas markets, demonstrating strong technical competitiveness.\n⚙️ Why OT-IT Convergence Matters # One of the central themes of the discussion was the integration of Operational Technology (OT) and Information Technology (IT).\nHistorically, OT systems—including factory equipment, industrial controllers, and manufacturing infrastructure—have operated independently from enterprise IT systems.\nModern industrial environments increasingly require these domains to work together, enabling:\nReal-time operational visibility AI-assisted decision making Predictive maintenance Centralized management Cloud-native industrial applications Intelligent automation Virtualization technologies and modern embedded platforms are expected to play an essential role in enabling this convergence while improving system reliability and deployment flexibility.\n🌐 Building a Broader Industrial Technology Ecosystem # Beyond technology integration, both companies intend to deepen collaboration across three strategic pillars:\nTechnology Co-Innovation # Joint development of industrial software, embedded platforms, and virtualization technologies tailored to evolving enterprise requirements.\nSolution Co-Development # Creating integrated solutions that combine Digital China\u0026rsquo;s implementation expertise with Wind River\u0026rsquo;s industrial software portfolio.\nMarket Expansion # Working together to accelerate adoption across manufacturing, industrial automation, critical infrastructure, and enterprise digital transformation projects.\nBy combining global technology leadership with strong local delivery capabilities, both organizations aim to strengthen China\u0026rsquo;s industrial software ecosystem while supporting long-term digital modernization initiatives.\n📈 Outlook # The latest executive meeting represents an important milestone in the evolving partnership between Digital China and Wind River.\nRather than remaining a framework agreement, the collaboration is now entering an execution phase centered on technology deployment, ecosystem development, and commercial expansion.\nAs industrial digitalization continues to accelerate, the combination of Wind River\u0026rsquo;s expertise in embedded and virtualization technologies with Digital China\u0026rsquo;s extensive implementation capabilities positions both companies to play a growing role in the modernization of industrial infrastructure and enterprise computing across China.\n","date":"2026-06-29","externalUrl":null,"permalink":"/news/digital-china-and-wind-river-expand-strategic-partnership-for-industrial-digitalization/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eDigital China and Wind River Expand Strategic Partnership for Industrial Digitalization\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eDigital China and Wind River have strengthened their strategic partnership to accelerate the adoption of industrial digital technologies, marking a significant step toward deeper collaboration in industrial software, embedded systems, virtualization, and enterprise digital transformation.\u003c/p\u003e","title":"Digital China and Wind River Expand Strategic Partnership for Industrial Digitalization","type":"news"},{"content":"","date":"2026-06-29","externalUrl":null,"permalink":"/tags/digital-transformation/","section":"Tags","summary":"","title":"Digital Transformation","type":"tags"},{"content":"","date":"2026-06-29","externalUrl":null,"permalink":"/tags/industrial-software/","section":"Tags","summary":"","title":"Industrial Software","type":"tags"},{"content":"","date":"2026-06-29","externalUrl":null,"permalink":"/tags/it/","section":"Tags","summary":"","title":"IT","type":"tags"},{"content":"","date":"2026-06-29","externalUrl":null,"permalink":"/news/","section":"News","summary":"","title":"News","type":"news"},{"content":"","date":"2026-06-29","externalUrl":null,"permalink":"/tags/ot/","section":"Tags","summary":"","title":"OT","type":"tags"},{"content":"","date":"2026-06-29","externalUrl":null,"permalink":"/tags/virtualization/","section":"Tags","summary":"","title":"Virtualization","type":"tags"},{"content":"","date":"2026-06-24","externalUrl":null,"permalink":"/tags/embedded-linux/","section":"Tags","summary":"","title":"Embedded Linux","type":"tags"},{"content":"","date":"2026-06-24","externalUrl":null,"permalink":"/tags/iot/","section":"Tags","summary":"","title":"IoT","type":"tags"},{"content":"","date":"2026-06-24","externalUrl":null,"permalink":"/tags/software-defined-systems/","section":"Tags","summary":"","title":"Software Defined Systems","type":"tags"},{"content":" Wind River Leads Global RTOS and Embedded Linux Markets in 2026\nWind River has reinforced its leadership in the embedded software industry, securing the top position across multiple operating system categories in the latest market research published by VDC Strategy. The company ranked first in the global Real-Time Operating System (RTOS) market, Commercial Embedded Linux, and the broader IoT \u0026amp; Embedded Operating Systems segment.\nThe report, IoT \u0026amp; Embedded Operating Systems, Containers, and Virtualization Solutions, highlights the continued adoption of Wind River\u0026rsquo;s flagship technologies—including VxWorks®, Wind River Linux®, and the Helix™ Virtualization Platform—across industries that demand deterministic performance, functional safety, cybersecurity, and long-term reliability.\nIn addition to its operating system leadership, Wind River was also recognized as one of the top three vendors in VDC Strategy\u0026rsquo;s Edge AI Development Solutions report, reflecting its expanding role in AI-powered edge computing.\n📊 Market Share Leadership Across Embedded Operating Systems # According to VDC Strategy, Wind River maintains a substantial revenue advantage over competing embedded operating system vendors across every major category.\nMarket Segment Wind River Second Largest Vendor Market Lead Global RTOS 31.9% 19.8% +12.1% Commercial Embedded Linux 36.7% 16.6% +20.1% IoT \u0026amp; Embedded Operating Systems 21.1% 14.2% +6.9% These figures demonstrate Wind River\u0026rsquo;s continued strength across both proprietary real-time operating systems and commercial Linux platforms, serving a broad spectrum of embedded applications.\nRTOS Leadership Continues # VxWorks remains one of the industry\u0026rsquo;s most widely deployed commercial RTOS platforms, particularly in environments where deterministic execution, low latency, and certified safety are essential.\nTypical deployment sectors include:\nAerospace and space systems Defense platforms Industrial automation Medical devices Robotics Railway and transportation systems Its mature ecosystem and long certification history continue to make it a preferred platform for mission-critical embedded applications.\nCommercial Embedded Linux Leadership # Wind River also leads the commercial Embedded Linux market with more than one-third of global revenue.\nEnterprise customers increasingly deploy commercial Linux distributions for applications requiring:\nLong-term maintenance Security patch management Containerized workloads Edge computing platforms Software-defined infrastructure Compared to community distributions, commercial embedded Linux platforms typically provide extended support lifecycles, validated hardware compatibility, and enterprise-grade security updates.\nGrowing Presence in Edge AI # Beyond operating systems, Wind River has expanded into software platforms supporting edge AI deployments.\nRecognition among the top three vendors in VDC Strategy\u0026rsquo;s Edge AI Development Solutions landscape reflects growing demand for software capable of supporting:\nAI inference at the edge Real-time analytics Intelligent industrial automation Autonomous systems Distributed machine learning workloads As AI increasingly moves closer to connected devices, operating systems must efficiently coordinate real-time workloads alongside AI frameworks while maintaining deterministic system behavior.\n🚀 Core Technologies Behind Wind River\u0026rsquo;s Portfolio # Wind River\u0026rsquo;s market position is built upon a software portfolio covering operating systems, virtualization, and edge infrastructure.\nVxWorks RTOS # VxWorks is a deterministic real-time operating system designed for applications requiring predictable scheduling and extremely high reliability.\nKey capabilities include:\nDeterministic task scheduling Low interrupt latency Functional safety certification support Secure boot and cybersecurity features Multi-core processor optimization Long-term platform stability These capabilities make it suitable for systems where downtime or unpredictable execution is unacceptable.\nWind River Linux # Wind River Linux provides an enterprise-grade embedded Linux distribution optimized for connected devices and intelligent edge deployments.\nKey features include:\nLong-term maintenance Secure software updates Container support Open-source ecosystem compatibility Broad processor architecture support Cloud-native deployment capabilities The platform is increasingly used in software-defined infrastructure spanning industrial, networking, and telecommunications environments.\nHelix Virtualization Platform # The Helix Virtualization Platform enables multiple operating systems to run securely on a single hardware platform.\nTypical configurations include:\nSafety-critical RTOS workloads General-purpose Linux environments Legacy operating systems Mixed-criticality applications Hardware virtualization allows developers to consolidate computing resources while maintaining isolation between workloads with different safety or security requirements.\n🤖 Driving the Intelligent Edge # Modern intelligent edge systems require significantly more than traditional embedded operating systems.\nToday\u0026rsquo;s platforms must support:\nAI inference Container orchestration Virtualization Cybersecurity Real-time processing Cloud connectivity Wind River\u0026rsquo;s software ecosystem has evolved to address these converging requirements, enabling organizations to deploy increasingly sophisticated distributed edge architectures.\n🛰️ Mission-Critical Deployments Across Industries # For more than four decades, Wind River technologies have powered embedded systems where reliability and availability are essential.\nAerospace and Defense # Wind River software continues to support aerospace programs requiring deterministic operation under extreme environmental conditions.\nIts technologies have been selected for high-profile space exploration initiatives, including support for NASA\u0026rsquo;s upcoming Artemis II lunar mission.\nTelecommunications # The telecommunications industry increasingly relies on software-defined infrastructure to modernize network architectures.\nWind River platforms contribute to deployments involving:\nOpen RAN AI-enhanced radio access networks (AI-RAN) Virtualized network infrastructure Edge cloud computing These technologies help operators improve scalability while reducing infrastructure complexity.\nAutomotive and Industrial Systems # Automotive manufacturers and industrial automation vendors continue to adopt software-defined architectures for next-generation systems.\nTypical deployment scenarios include:\nAutonomous driving platforms Industrial robotics Smart manufacturing Functional safety systems Industrial IoT gateways The combination of deterministic scheduling, virtualization, and cybersecurity allows these systems to safely execute mixed-criticality workloads.\n💬 Industry Perspectives # According to Wind River leadership, the company\u0026rsquo;s continued market leadership reflects growing customer demand for secure, software-defined edge platforms capable of supporting increasingly complex AI and real-time applications.\nVDC Strategy likewise attributes Wind River\u0026rsquo;s sustained success to its continued investment in functional safety, cybersecurity, virtualization, and intelligent edge software—areas that have become central requirements for modern embedded computing platforms.\n📈 Outlook # The latest VDC Strategy research reinforces Wind River\u0026rsquo;s position as one of the most influential vendors in the embedded software ecosystem.\nBy maintaining leadership across RTOS, commercial Embedded Linux, and IoT operating systems while expanding into Edge AI software, the company continues to strengthen its role in enabling next-generation intelligent edge infrastructure.\nAs industries accelerate adoption of AI, cloud-native architectures, and software-defined systems, demand for secure, deterministic, and scalable embedded platforms is expected to remain a key driver of future growth.\n","date":"2026-06-24","externalUrl":null,"permalink":"/news/wind-river-leads-global-rtos-and-embedded-linux-markets-in-2026/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eWind River Leads Global RTOS and Embedded Linux Markets in 2026\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eWind River has reinforced its leadership in the embedded software industry, securing the top position across multiple operating system categories in the latest market research published by VDC Strategy. The company ranked first in the global \u003cstrong\u003eReal-Time Operating System (RTOS)\u003c/strong\u003e market, \u003cstrong\u003eCommercial Embedded Linux\u003c/strong\u003e, and the broader \u003cstrong\u003eIoT \u0026amp; Embedded Operating Systems\u003c/strong\u003e segment.\u003c/p\u003e","title":"Wind River Leads Global RTOS and Embedded Linux Markets in 2026","type":"news"},{"content":"","date":"2026-06-17","externalUrl":null,"permalink":"/tags/ai-deployment/","section":"Tags","summary":"","title":"AI Deployment","type":"tags"},{"content":"","date":"2026-06-17","externalUrl":null,"permalink":"/tags/aptiv/","section":"Tags","summary":"","title":"Aptiv","type":"tags"},{"content":" Aptiv and NVIDIA Expand Edge AI Partnership for Production Deployment\n🚀 Overview # Global technology leader Aptiv PLC has announced an expansion of its strategic partnership with NVIDIA to accelerate the adoption of production-grade Edge AI across industries. The collaboration focuses on enhancing the NVIDIA Jetson platform—including future platforms such as Jetson Thor—into a commercially supported, mass-production-ready foundation for intelligent edge systems.\nThe initiative addresses one of the most significant challenges facing enterprise AI adoption: transitioning from successful prototypes to secure, scalable, and maintainable production deployments that can operate reliably for years in mission-critical environments.\n\u0026ldquo;Our AI models are designed to solve complex real-world problems. Wind River\u0026rsquo;s technology provides us with the performance, reliability, and security necessary to run these highly demanding workloads in mission-critical environments. Together, we will help organizations fully harness their data potential and unleash unprecedented levels of innovation.\u0026rdquo;\n— Jay Bellissimo\nSenior Vice President, Aptiv\nPresident, Smart Systems Software and Services\n🌐 Accelerating Enterprise-Scale Edge AI Adoption # As Edge AI deployments expand across distributed environments, organizations increasingly require more than high-performance hardware. Long-term operational success depends on robust lifecycle management, security maintenance, regulatory compliance, and reliable software support.\nMany enterprises face challenges such as:\nContinuous vulnerability monitoring and remediation Long-term security patch management Compliance with emerging regulations such as the Cyber Resilience Act (CRA) Stable Linux runtime environments for production systems Sustainable maintenance strategies for long-lifecycle deployments To address these requirements, Aptiv and NVIDIA are strengthening collaboration across engineering, product development, and go-to-market initiatives. The goal is to ensure Jetson-based platforms remain secure, maintainable, and production-ready throughout their operational lifecycle.\n⚙️ Building a Production-Grade Jetson Ecosystem # The expanded partnership extends support across the entire NVIDIA Jetson ecosystem, including existing deployments and next-generation platforms such as Jetson Thor.\nTarget industries include:\nIndustrial automation Robotics Aerospace and defense Automotive systems Telecommunications infrastructure Intelligent edge computing platforms By combining NVIDIA\u0026rsquo;s AI computing technologies with Aptiv\u0026rsquo;s software expertise and lifecycle services, the collaboration aims to accelerate large-scale commercial adoption of Edge AI solutions.\n🔧 Key Areas of Collaboration # Long-Term Support for Yocto-Based Platforms # Aptiv will provide commercial-grade lifecycle support for the widely used meta-tegra Board Support Package (BSP) ecosystem built on the Yocto Project.\nKey focus areas include:\nSecurity monitoring and vulnerability management Long-term maintenance and updates Production lifecycle support Enterprise deployment readiness Cyber Resilience Act (CRA) Compliance # The collaboration includes the development of a CRA-compliant Yocto platform designed to simplify regulatory compliance efforts.\nBenefits include:\nReduced compliance complexity Lower legal and financial risk Improved security governance Faster deployment approval processes Alignment Between Yocto and Wind River Linux # Aptiv and NVIDIA are working to improve alignment between upstream Yocto Project development and Wind River Linux.\nThis effort aims to:\nReduce ecosystem fragmentation Simplify software maintenance Improve platform consistency Enable scalable long-term support models Production Foundation for Jetson Thor # The partnership also focuses on creating a secure, production-ready software foundation for Jetson Thor, NVIDIA\u0026rsquo;s next-generation edge AI platform.\nObjectives include:\nLong-term software support Secure deployment architecture Simplified maintenance workflows Smooth transition from development to production Accelerated Commercial Adoption # The companies are jointly investing in go-to-market initiatives that help organizations move from proof-of-concept projects to large-scale deployments more efficiently.\n🧩 Simplifying Edge AI Development # Another important aspect of the collaboration is improving integration among key software components within the Jetson ecosystem.\nAreas of optimization include:\nNVIDIA CUDA acceleration stack Yocto-based runtime environments meta-tegra integration layers Production software deployment workflows These improvements reduce development complexity while helping engineering teams shorten the path from product design to commercial deployment.\n🏭 Impact on Long-Lifecycle Embedded Systems # Many embedded systems operate for years or even decades after deployment. Industries such as aerospace, industrial automation, transportation, and telecommunications require software platforms that remain secure and maintainable throughout extended operational lifecycles.\nThe Aptiv-NVIDIA partnership directly addresses these requirements by providing:\nLong-term platform stability Security-first software maintenance Regulatory compliance support Enterprise-grade lifecycle management Scalable deployment strategies This approach enables organizations to deploy AI-powered systems with greater confidence while reducing long-term operational risk.\n🏢 About Wind River # Wind River is a leading provider of intelligent edge software and has supported mission-critical systems for more than four decades.\nIts technologies power billions of devices across industries that require high levels of:\nSafety Security Reliability Real-time performance Wind River\u0026rsquo;s software portfolio supports digital transformation initiatives across sectors including automotive, aerospace, industrial automation, healthcare, and telecommunications. The company complements its technology offerings with global engineering services, technical support, and a broad ecosystem of strategic partners.\n📌 Conclusion # The expanded collaboration between Aptiv and NVIDIA represents a significant step toward making Edge AI deployment more practical and sustainable at scale. By combining advanced AI computing platforms with commercial-grade lifecycle management, security support, and regulatory compliance capabilities, the partnership aims to bridge the gap between AI innovation and real-world production deployment.\nAs Edge AI continues to move from experimentation to mission-critical operations, long-term support, security, and maintainability will become just as important as raw compute performance. This initiative positions the NVIDIA Jetson ecosystem as a stronger foundation for next-generation intelligent systems operating at the edge.\n","date":"2026-06-17","externalUrl":null,"permalink":"/news/aptiv-and-nvidia-expand-edge-ai-partnership-for-production-deployment/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eAptiv and NVIDIA Expand Edge AI Partnership for Production Deployment\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🚀 Overview \n    \u003cdiv id=\"-overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eGlobal technology leader Aptiv PLC has announced an expansion of its strategic partnership with NVIDIA to accelerate the adoption of production-grade Edge AI across industries. The collaboration focuses on enhancing the NVIDIA Jetson platform—including future platforms such as Jetson Thor—into a commercially supported, mass-production-ready foundation for intelligent edge systems.\u003c/p\u003e","title":"Aptiv and NVIDIA Expand Edge AI Partnership for Production Deployment","type":"news"},{"content":"","date":"2026-06-17","externalUrl":null,"permalink":"/tags/jetson/","section":"Tags","summary":"","title":"Jetson","type":"tags"},{"content":"","date":"2026-06-17","externalUrl":null,"permalink":"/tags/nvidia/","section":"Tags","summary":"","title":"NVIDIA","type":"tags"},{"content":"","date":"2026-06-17","externalUrl":null,"permalink":"/tags/yocto/","section":"Tags","summary":"","title":"Yocto","type":"tags"},{"content":"","date":"2026-06-06","externalUrl":null,"permalink":"/tags/bsd-sockets/","section":"Tags","summary":"","title":"BSD Sockets","type":"tags"},{"content":"","date":"2026-06-06","externalUrl":null,"permalink":"/tags/embedded-networking/","section":"Tags","summary":"","title":"Embedded Networking","type":"tags"},{"content":"","date":"2026-06-06","externalUrl":null,"permalink":"/tags/industrial-control/","section":"Tags","summary":"","title":"Industrial Control","type":"tags"},{"content":" Multi-Task Network Communication Design in VxWorks Using BSD Sockets\n🚀 Abstract # Network connectivity has become a fundamental requirement for modern embedded systems, enabling remote monitoring, configuration, debugging, and real-time data exchange. VxWorks, one of the most widely deployed real-time operating systems (RTOS), provides a mature TCP/IP stack and full BSD Socket compatibility, making it well suited for network-enabled embedded applications.\nThis article presents a practical approach to implementing network communication in VxWorks using a multi-task architecture. It first reviews VxWorks task management and socket programming interfaces, then explains the standard client-server communication model, and finally details the design of a robust multi-task socket server. By leveraging VxWorks\u0026rsquo; real-time scheduling and networking capabilities, developers can build scalable and reliable communication systems for industrial control, scientific instrumentation, communications equipment, and other embedded applications.\nKeywords: Network Communication, Multi-tasking, Socket Programming, VxWorks, Embedded Real-Time Systems, Client-Server Architecture\n🌐 Introduction # The rapid advancement of embedded processors has significantly increased the demand for sophisticated operating systems capable of handling complex real-time workloads. Today, embedded systems are widely deployed across numerous industries, including:\nIndustrial automation Telecommunications Aerospace and defense Medical equipment Scientific instrumentation Transportation systems Among the available embedded operating systems, VxWorks has established itself as a leading RTOS due to its deterministic scheduling, modular architecture, and comprehensive networking support.\nOne of its most valuable features is the integration of a full TCP/IP protocol stack combined with BSD Socket APIs. This allows developers familiar with UNIX networking to quickly implement communication services on embedded targets.\nBeyond simple connectivity, network communication enables:\nRemote configuration Online diagnostics Real-time data visualization Distributed control Host-target debugging When combined with VxWorks\u0026rsquo; powerful multi-tasking capabilities, highly responsive and fault-tolerant network applications can be developed with minimal overhead.\n⚙️ VxWorks Task Management Fundamentals # VxWorks applications are primarily developed in standard C, with optional C++ support.\nUnlike conventional desktop operating systems, VxWorks organizes execution through lightweight tasks that are managed by the kernel scheduler.\nTask Scheduling Model # VxWorks provides:\n256 priority levels Preemptive scheduling Deterministic task switching Optional round-robin scheduling for equal-priority tasks Priority values range from:\n0 → Highest priority 255 → Lowest priority To improve fairness among tasks with identical priorities, developers typically enable time slicing during system initialization:\nkernelTimeSlice(1); This allows tasks at the same priority level to share CPU resources efficiently.\nCommon Task Management APIs # The following functions form the foundation of task management in VxWorks:\nFunction Description taskSpawn() Create and start a task taskDelete() Delete a running task taskNameToId() Retrieve task ID from task name taskIdVerify() Verify whether a task exists taskPrioritySet() Modify task priority taskPriorityGet() Retrieve task priority These APIs provide developers with fine-grained control over execution behavior, enabling highly deterministic real-time systems.\n🔌 BSD Socket Support in VxWorks # One of VxWorks\u0026rsquo; major strengths is its compatibility with the BSD Socket programming model.\nThe operating system includes support for a wide range of network interface hardware and automatically initializes networking components when enabled through system configuration files such as config.h.\nSupported network adapters commonly include:\nNE2000 3Com EtherLink III Intel PRO100 AMD 79C972 Other Ethernet-compatible devices Because the networking APIs closely mirror UNIX implementations, existing network applications can often be ported with minimal modification.\nCore Socket APIs # The primary socket functions available in VxWorks include:\nFunction Purpose socket() Create a socket bind() Associate a socket with a local address listen() Enable connection listening connect() Establish a connection to a server accept() Accept incoming client connections send() / sendto() Transmit data recv() / recvfrom() Receive data close() Release socket resources These APIs support both:\nTCP communication UDP communication allowing developers to select the protocol best suited to their application requirements.\n🖧 Client-Server Communication Model # Most network applications in embedded environments follow the client-server architecture.\nThis model separates responsibilities between service providers and service consumers, simplifying system design and improving scalability.\nServer Workflow # The server performs the following operations:\nCreate a socket using socket(). Bind the socket to a local IP address and port. Enter listening mode using listen(). Accept incoming client connections via accept(). Exchange data with connected clients. Close sockets when communication is complete. Client Workflow # The client follows a simpler sequence:\nCreate a socket. Connect to the server using connect(). Exchange data through send() and recv(). Close the connection when finished. Data Exchange # Once the connection is established:\nClient \u0026lt;---- TCP/UDP ----\u0026gt; Server Both endpoints can transmit and receive data according to application-specific protocols.\nThis architecture forms the foundation for virtually all network-enabled embedded systems.\n🏗️ Multi-Task Socket Server Architecture # Although a single-threaded server may be sufficient for simple applications, real-time embedded systems typically require a more robust architecture capable of handling concurrent events and maintaining responsiveness.\nVxWorks makes this possible through task-based parallelism.\nThe proposed server design employs multiple cooperating tasks, each responsible for a specific subsystem.\nServer Task Structure # The architecture consists of the following tasks:\nTask Responsibility Init Task System initialization Accept Task Connection acceptance tAcpWatch Task Acceptor monitoring Send Task Message transmission rRecv Task Message reception SendTimer Task Timer management SendOnTime Task Periodic heartbeat transmission tNetWatch Task Network fault and shutdown handling This separation improves maintainability, reliability, and scalability.\n🔄 Task Responsibilities # Init Task # The initialization task is responsible for:\nRe-entrancy protection Variable initialization Socket creation Launching the acceptor task After initialization is complete, the task exits.\nAccept Task # The acceptor serves as the central connection manager.\nIts responsibilities include:\nListening for incoming clients Accepting new connections Creating dedicated communication tasks Launching monitoring services For every successful client connection, a new set of worker tasks is spawned.\nThis design allows multiple clients to be serviced independently.\ntAcpWatch Task # This task supervises the acceptor.\nTypical functions include:\nMonitoring user shutdown requests Handling keyboard events Triggering graceful termination procedures Send Task # The send task handles outbound communication.\nResponsibilities include:\nReading local input Packaging messages Transmitting data to clients Handling user-triggered exits This task can also be extended to support application-generated data streams.\nrRecv Task # The receive task continuously monitors incoming data.\nKey functions include:\nReceiving client messages Displaying communication results Processing control commands Detecting disconnect events Special commands such as:\nquit can be interpreted as requests to terminate the connection gracefully.\nSendTimer and SendOnTime Tasks # Reliable network communication often requires heartbeat mechanisms.\nThese tasks work together to:\nSchedule periodic transmissions Send heartbeat packets Verify remote endpoint responsiveness Detect stale connections Heartbeat monitoring is particularly valuable in industrial and mission-critical environments where silent failures must be detected quickly.\ntNetWatch Task # The network watchdog acts as the system\u0026rsquo;s fault-management center.\nIt handles:\nClient disconnections Communication failures Socket errors Task termination events Server shutdown procedures When a fault occurs, the watchdog:\nCloses sockets. Deletes related tasks. Releases resources. Restarts listening services if necessary. This centralized cleanup strategy significantly improves overall system reliability.\n⌨️ Special Considerations for Keyboard Input # Interactive network servers frequently require direct keyboard access.\nHowever, VxWorks normally runs the interactive shell (iShell) as a dedicated task, which can interfere with application-level keyboard processing.\nSeveral approaches can be used:\nLower Shell Priority # The shell task priority can be reduced, allowing application tasks to receive keyboard events more readily.\nDisable Interactive Shell # In dedicated embedded deployments, the shell may be excluded entirely during system configuration.\nThis enables direct use of standard I/O functions such as:\nread(); write(); for user interaction and command processing.\nThe optimal solution depends on the intended deployment environment.\n🚀 Advantages of the Multi-Task Approach # Implementing network communication through multiple coordinated tasks offers several important benefits.\nReal-Time Responsiveness # Priority-based scheduling ensures that critical communication events receive immediate attention.\nThis minimizes latency and improves deterministic behavior.\nImproved Reliability # The architecture incorporates:\nWatchdog timers Resource cleanup mechanisms Fault monitoring Re-entrancy protection Together, these features help prevent:\nResource leaks Task deadlocks Socket exhaustion Uncontrolled failures Greater Flexibility # Network services can be integrated seamlessly with:\nData acquisition tasks Control loops Monitoring systems Diagnostic applications without disrupting existing functionality.\nScalability # By spawning dedicated worker tasks for each connection, the system can support multiple simultaneous clients while maintaining responsiveness.\nThis makes the architecture suitable for both small embedded controllers and large distributed systems.\n📊 Practical Applications # The proposed architecture has been successfully applied in various embedded environments requiring reliable host-target communication.\nTypical use cases include:\nHigh-speed data acquisition systems Industrial control platforms Remote monitoring systems Scientific instruments Embedded debugging tools Communication gateways In these applications, network communication serves as a critical bridge between embedded targets and external management systems.\n📌 Conclusion # VxWorks combines deterministic real-time scheduling with a mature BSD Socket implementation, making it an excellent platform for embedded network applications.\nThis article presented a practical multi-task communication architecture that leverages these capabilities to build robust and scalable socket servers. By separating networking functions into specialized tasks and incorporating monitoring, watchdog, and recovery mechanisms, developers can achieve reliable communication even in demanding real-time environments.\nThe techniques described provide a proven foundation for implementing networked embedded systems that require remote configuration, monitoring, data exchange, and debugging. As embedded devices continue to become more connected, multi-task socket architectures such as this will remain a valuable design pattern for high-performance VxWorks applications.\n","date":"2026-06-06","externalUrl":null,"permalink":"/app/multi-task-network-communication-design-in-vxworks-using-bsd-sockets/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eMulti-Task Network Communication Design in VxWorks Using BSD Sockets\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🚀 Abstract \n    \u003cdiv id=\"-abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eNetwork connectivity has become a fundamental requirement for modern embedded systems, enabling remote monitoring, configuration, debugging, and real-time data exchange. VxWorks, one of the most widely deployed real-time operating systems (RTOS), provides a mature TCP/IP stack and full BSD Socket compatibility, making it well suited for network-enabled embedded applications.\u003c/p\u003e","title":"Multi-Task Network Communication Design in VxWorks Using BSD Sockets","type":"app"},{"content":"","date":"2026-06-06","externalUrl":null,"permalink":"/tags/multi-tasking/","section":"Tags","summary":"","title":"Multi-Tasking","type":"tags"},{"content":"","date":"2026-06-06","externalUrl":null,"permalink":"/tags/network-programming/","section":"Tags","summary":"","title":"Network Programming","type":"tags"},{"content":"","date":"2026-06-06","externalUrl":null,"permalink":"/tags/tcp/","section":"Tags","summary":"","title":"TCP","type":"tags"},{"content":"","date":"2026-06-06","externalUrl":null,"permalink":"/tags/tcp/ip/","section":"Tags","summary":"","title":"TCP/IP","type":"tags"},{"content":" Building a Lightweight WWW Browser on VxWorks Embedded Systems\nAs embedded devices become increasingly connected, users expect the same intuitive interfaces found on desktop and mobile platforms. Web technologies offer a compelling solution, providing platform-independent access to system information, configuration interfaces, and remote control capabilities.\nHowever, developing a browser for embedded systems presents unique challenges. Limited memory, constrained processing power, real-time requirements, and compact storage footprints make conventional browser architectures unsuitable.\nThis article explores the design and implementation of a lightweight WWW browser built specifically for VxWorks-based embedded systems. By combining VxWorks networking capabilities, ARM processor architecture, Socket programming, multithreading techniques, and WindML graphics, the project demonstrates that practical web browsing functionality can be achieved within extremely tight resource constraints.\n🌐 Why Embedded Systems Need Web Browsers # The rapid growth of embedded computing has expanded the demand for user-friendly interfaces across industries such as:\nIndustrial automation Telecommunications Defense systems Medical devices Consumer electronics Transportation systems Web technologies provide several advantages for embedded platforms:\nPlatform-independent interfaces Remote accessibility Simplified device management Reduced deployment complexity Familiar user experience While commercial embedded browsers already exist, including solutions for Windows CE, Linux, and VxWorks, many embedded applications require highly customized implementations optimized for specific hardware and operational requirements.\nThe goal of this project was to develop a browser that could deliver practical functionality while maintaining a minimal software footprint.\n⚙️ Embedded Operating System Requirements # Unlike desktop environments, embedded systems operate under strict resource limitations.\nTypical constraints include:\nLimited RAM Reduced CPU performance Restricted storage capacity Deterministic timing requirements Low power consumption These limitations favor lightweight operating systems built around compact kernel architectures.\nWhy VxWorks? # VxWorks is widely adopted in embedded environments because it offers:\nDeterministic real-time performance Priority-based preemptive scheduling Fast interrupt response Efficient memory management Mature networking capabilities Small runtime footprint These characteristics make VxWorks particularly suitable for applications that combine networking, graphical interfaces, and real-time processing.\n🔧 ARM-Based Embedded Hardware Platform # The browser was designed for ARM-based embedded systems.\nARM processors have become dominant in embedded computing due to their:\nHigh performance-per-watt efficiency Compact instruction set architecture Scalable performance profiles Broad ecosystem support Developing software for ARM platforms requires attention to:\nInterrupt handling mechanisms Memory architecture Peripheral interfaces Serial communication subsystems These hardware considerations directly influence browser performance and responsiveness.\n🌍 Browser Networking Architecture # The browser follows the traditional Client-Server model used by modern web applications.\nHTTP Communication # Communication between the browser and web servers relies on the HyperText Transfer Protocol (HTTP).\nThe browser can interact with:\nRemote web servers Embedded web servers Local device-hosted content This architecture enables several practical embedded use cases:\nRemote device monitoring Configuration management Status visualization Operational control Diagnostics and maintenance Embedded devices can also generate dynamic pages that reflect real-time system conditions, allowing operators to interact with hardware through standard web interfaces.\n🏗️ Core Browser Architecture # The browser was designed around three primary functional components.\nController # The controller serves as the central coordination module.\nIts responsibilities include:\nProcessing keyboard input Handling mouse events Managing navigation operations Coordinating rendering activities Dispatching actions to subsystems The controller acts as the browser\u0026rsquo;s command center.\nContent Interpreters # Interpreters process and decode various content formats.\nThe primary focus of this implementation is HTML parsing and rendering.\nResponsibilities include:\nHTML interpretation Content tokenization Document structure analysis Layout preparation Additional content formats could be added through future extensions.\nNetwork Clients # The client subsystem manages communication with web servers.\nFunctions include:\nHTTP request generation Socket management Data reception Connection handling Resource retrieval Separating networking from rendering improves modularity and maintainability.\n🛠️ Development Environment with Tornado and VxSim # Developing embedded software often requires specialized hardware, making testing and debugging difficult.\nTo address this challenge, the project utilized Tornado II and VxSim.\nTornado Integrated Development Environment # Tornado provides a complete cross-development platform including:\nSource code editing Compilation tools Debugging facilities Target management Performance analysis This environment significantly simplifies embedded software development.\nVxSim Simulator # One of the most valuable tools in the project was VxSim.\nVxSim provides a software simulation of the VxWorks runtime environment, enabling developers to:\nBuild applications without target hardware Test multitasking behavior Validate inter-task communication Debug networking functionality Verify synchronization mechanisms Only hardware-specific BSP functionality remains outside the simulator\u0026rsquo;s scope.\nThis capability substantially reduces development costs and accelerates iteration cycles.\n📖 Efficient HTML Lexical Analysis # The browser begins processing web content through lexical analysis.\nResponsibilities of the Lexer # The lexical analyzer performs several critical tasks:\nExtracting text content Identifying HTML elements Capturing layout information Gathering page statistics Supporting content editing Saving modified documents Efficiency was a primary design objective because parsing overhead directly impacts browser responsiveness.\nError Tolerance # Web content is often imperfect.\nThe lexer was designed to tolerate malformed input while continuing processing whenever possible, improving overall robustness.\n🔍 High-Performance Parsing Through Segmented Processing # Traditional browser architectures often process entire documents before rendering begins.\nSuch approaches are inefficient in embedded environments.\nIncremental Parsing Strategy # The browser adopts segmented processing, dividing documents into manageable chunks.\nTypical segment size:\n1024 bytes Rather than waiting for an entire page to load, the system processes content incrementally.\nBenefits include:\nLower memory consumption Faster initial rendering Improved responsiveness Reduced processing overhead Testing showed that segmented processing could improve performance by up to 30 times compared to processing entire documents in a single pass.\nBoundary Handling # A key challenge of segmented parsing is preventing HTML elements from being split across chunk boundaries.\nTo address this issue, a backtracking mechanism ensures that each segment contains complete HTML structures before processing begins.\nThis guarantees parsing correctness while preserving performance advantages.\n📐 Layout Engine Design # After parsing, the browser generates visual layout information.\nThe layout engine traverses the token list and determines:\nPositioning Formatting Text flow Display attributes A simplified implementation appears below:\npTokenList = global_cx-\u0026gt;tokenList; while (pTokenList != NULL) { switch (pTokenList-\u0026gt;token-\u0026gt;type) { case HTML_TITLE: /* Process page title */ break; case HTML_TEXT: /* Process text content */ break; default: break; } pTokenList = pTokenList-\u0026gt;next; } This integrated parsing and layout approach minimizes memory overhead while maintaining acceptable rendering performance.\n🖼️ Graphical Rendering with WindML # Graphical rendering is one of the most resource-intensive components of any browser.\nTo support embedded graphics efficiently, the project utilizes WindML (Wind River Media Library).\nWindML Capabilities # WindML provides:\n2D graphics rendering Video support Audio support Keyboard handling Mouse handling Display management These capabilities form the foundation of the browser\u0026rsquo;s graphical subsystem.\nUser Interface Components # The browser interface includes standard GUI elements such as:\nMain windows Menus Toolbars Scrollbars Status indicators In addition, custom rendering components display parsed HTML content inside the browsing area.\nThis approach delivers flexibility while minimizing runtime overhead.\n📊 Performance Results # The browser was extensively tested within the VxSim simulation environment running on a standard PC.\nFunctional Performance # Testing demonstrated:\nSuccessful HTTP communication Reliable HTML parsing Stable rendering performance Practical usability for simple web content For lightweight pages, the browser delivered results comparable to contemporary embedded browsers.\nResource Consumption # One of the most impressive outcomes was the compact implementation size.\nMetric Result Source Code Size ~2,100 lines Memory Footprint ~2.9 MB Platform VxWorks + ARM Development Environment Tornado + VxSim These figures align closely with the requirements of resource-constrained embedded platforms.\nCurrent Limitations # While effective for basic content, the browser still lacks support for many advanced web technologies.\nAreas requiring further development include:\nRich multimedia content Animation rendering CSS support JavaScript execution Advanced HTML features These capabilities would require additional optimization and architectural enhancements.\n🚀 Design Advantages # Several architectural decisions contributed to the success of the implementation.\nLightweight Architecture # The browser maintains a small footprint while preserving essential functionality.\nModular Design # Independent subsystems simplify maintenance and future expansion.\nPlatform Portability # The implementation is written in standard C, making it adaptable to:\nOther VxWorks platforms Windows environments Alternative embedded operating systems Real-Time Compatibility # The architecture respects the deterministic requirements of real-time systems and integrates naturally with VxWorks scheduling mechanisms.\n🎯 Conclusion # The successful implementation of a lightweight WWW browser on VxWorks demonstrates that practical web technologies can be deployed effectively within embedded environments. By combining efficient HTML processing, segmented parsing, multithreaded communication, and WindML-based rendering, the project achieves an impressive balance between functionality and resource efficiency.\nWith only approximately 2,100 lines of code and a memory footprint of roughly 2.9 MB, the browser satisfies many of the fundamental requirements of embedded software design: compact size, predictable performance, and low resource consumption.\nAlthough advanced web technologies remain future work, the project establishes a solid architectural foundation for embedded browser development. More importantly, it highlights the strengths of VxWorks, Tornado, and ARM-based platforms in delivering sophisticated networking and graphical applications within constrained real-time environments.\n","date":"2026-06-01","externalUrl":null,"permalink":"/app/building-a-lightweight-www-browser-on-vxworks-embedded-systems/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eBuilding a Lightweight WWW Browser on VxWorks Embedded Systems\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eAs embedded devices become increasingly connected, users expect the same intuitive interfaces found on desktop and mobile platforms. Web technologies offer a compelling solution, providing platform-independent access to system information, configuration interfaces, and remote control capabilities.\u003c/p\u003e","title":"Building a Lightweight WWW Browser on VxWorks Embedded Systems","type":"app"},{"content":"","date":"2026-06-01","externalUrl":null,"permalink":"/tags/gui-development/","section":"Tags","summary":"","title":"GUI Development","type":"tags"},{"content":"","date":"2026-06-01","externalUrl":null,"permalink":"/tags/http/","section":"Tags","summary":"","title":"HTTP","type":"tags"},{"content":"","date":"2026-06-01","externalUrl":null,"permalink":"/tags/tornado-ide/","section":"Tags","summary":"","title":"Tornado IDE","type":"tags"},{"content":"","date":"2026-06-01","externalUrl":null,"permalink":"/tags/web-browser/","section":"Tags","summary":"","title":"Web Browser","type":"tags"},{"content":"","date":"2026-06-01","externalUrl":null,"permalink":"/tags/windml/","section":"Tags","summary":"","title":"WindML","type":"tags"},{"content":"","date":"2026-05-30","externalUrl":null,"permalink":"/tags/afdx/","section":"Tags","summary":"","title":"AFDX","type":"tags"},{"content":"","date":"2026-05-30","externalUrl":null,"permalink":"/tags/arinc664/","section":"Tags","summary":"","title":"ARINC664","type":"tags"},{"content":"","date":"2026-05-30","externalUrl":null,"permalink":"/tags/deterministic-ethernet/","section":"Tags","summary":"","title":"Deterministic Ethernet","type":"tags"},{"content":" Developing AFDX Applications on VxWorks for Avionics Systems\nModern avionics systems demand deterministic, low-latency, and fault-tolerant communication infrastructures capable of supporting increasingly complex airborne subsystems.\nVxWorks, developed by Wind River, remains one of the most widely deployed real-time operating systems (RTOS) in aerospace and defense environments due to its:\nDeterministic scheduling Efficient interrupt handling Stable resource management Mature networking stack High reliability under real-time workloads At the same time, Avionics Full-Duplex Switched Ethernet (AFDX), standardized under ARINC 664 Part 7, has become the dominant deterministic Ethernet architecture for modern aircraft communication systems.\nCompared with traditional avionics buses such as ARINC 429, AFDX delivers:\nHigher bandwidth Deterministic latency Redundant communication paths Improved scalability Better subsystem integration This article explores the implementation and development of AFDX applications on VxWorks platforms, focusing on:\nPCI device configuration AFDX system architecture Virtual Link configuration Real-time communication mechanisms Deterministic avionics networking ✈️ Introduction to AFDX Development on VxWorks # The system platform discussed in this implementation is based on:\nFreescale PowerPC (PPC) processors VxWorks RTOS Commercial off-the-shelf (COTS) AFDX interface boards The AFDX module communicates with the PowerPC processor through the PCI bus.\nThis architecture enables:\nPPC CPU ↔ PCI Bus ↔ AFDX Interface Module Because VxWorks provides mature PCI subsystem support, developers can efficiently integrate AFDX hardware into real-time avionics applications.\nHowever, successful deployment depends heavily on:\nCorrect PCI configuration BSP integration Memory mapping Deterministic networking setup Virtual Link planning ⚙️ PCI Configuration in VxWorks # PCI configuration forms the foundation of AFDX hardware integration.\nVxWorks includes extensive support for:\nPCI device discovery Configuration-space access BAR mapping Interrupt handling MMU-assisted address translation Proper PCI initialization ensures that the AFDX hardware can communicate reliably with the processor and networking stack.\n🧩 PCI Device Addressing # Every PCI device is uniquely identified using three parameters:\nParameter Description Bus Number Identifies the PCI bus hierarchy Device Number Identifies the device on the bus Function Number Identifies functions within multi-function devices Together, the tuple:\n(Bus, Device, Function) uniquely identifies a PCI device.\nBus Number # Bus numbering begins at:\n0 and expands hierarchically through PCI bridges.\nDevice Number # Each bus can contain multiple devices assigned unique device IDs.\nFunction Number # Multi-function devices support up to:\n8 functions (0–7) although many devices only expose Function 0.\n🧠 PCI Configuration Space # Every PCI device exposes a standardized:\n256-byte PCI Configuration Space This region contains critical hardware metadata and resource mappings.\nImportant PCI Registers # Register Purpose Vendor ID Manufacturer identifier Device ID Device identifier Revision ID Hardware revision Class Code Functional classification BARs Memory or I/O mapping definitions The Base Address Registers (BARs) are especially important because they determine:\nDevice memory regions I/O address ranges DMA-accessible buffers These mappings must align correctly with BSP memory layouts.\n🔧 VxWorks PCI Support Functions # VxWorks provides a rich PCI API for device management.\nCommon PCI Functions # Function Description pciFindDevice Locate device by Vendor ID and Device ID pciFindClass Locate device by Class Code pciConfigBdfPack Pack Bus/Device/Function tuple pciConfigInLong Read 32-bit configuration value pciConfigOutLong Write 32-bit configuration value These APIs allow developers to:\nEnumerate PCI devices Configure hardware resources Access device registers Initialize AFDX hardware drivers MMU and BSP Considerations # During system boot, VxWorks performs PCI address-space mapping.\nWith full MMU support enabled:\nAddress translation and memory mapping are handled automatically. Without MMU support, developers may need to manually modify:\nBSP configuration Memory mapping tables PCI initialization routines This is especially important in deterministic avionics systems where incorrect mappings can lead to unstable behavior.\n🌐 AFDX System Architecture # AFDX introduces deterministic Ethernet communication into avionics systems while preserving compatibility with standard IEEE 802.3 Ethernet physical layers.\nAn AFDX system typically consists of three primary components.\n🛰️ Avionics Subsystems # These include traditional aircraft systems such as:\nFlight control computers GPS/navigation modules Health monitoring systems Cockpit displays Sensor fusion systems Each subsystem generates or consumes deterministic communication traffic.\n🔌 AFDX End Systems # AFDX End Systems serve as secure gateways between avionics subsystems and the AFDX network.\nTheir responsibilities include:\nFrame encapsulation Traffic shaping Virtual Link management Bandwidth enforcement Redundancy handling Each End System ensures that subsystem traffic complies with ARINC 664 deterministic constraints.\n🔀 AFDX Switches # AFDX switches are full-duplex Ethernet switches optimized for deterministic forwarding.\nUnlike traditional Ethernet switches, AFDX switches enforce:\nBounded latency Controlled jitter Virtual Link isolation Predictable queue behavior This architecture eliminates collision domains and significantly improves reliability.\n🛣️ Virtual Links in AFDX # The core communication abstraction in AFDX is the:\nVirtual Link (VL) A Virtual Link defines a:\nUnidirectional logical communication channel from one source End System to one or more destination End Systems. Although multiple VLs share the same physical Ethernet infrastructure, each VL behaves as an isolated deterministic communication path.\n📦 Key AFDX Network Configuration Parameters # Each Virtual Link requires strict configuration.\nCore Configuration Elements # Parameter Description Virtual Link ID Logical channel identifier BAG Bandwidth Allocation Gap Source IP Sender IP address Destination IP Receiver IP address UDP Ports Application-level routing MAC Addresses Ethernet-level routing Port Type Sampling or queuing behavior These parameters collectively define:\nTransmission frequency Bandwidth allocation Routing behavior Deterministic timing guarantees 📊 Example AFDX Message Mapping # An example End System configuration may look like:\nMessage ID AFDX Port Source UDP Source IP Source MAC Destination MAC (VL) Destination IP Destination UDP 1 1 UDP1 IP5 MAC5 VL1 IP1 UDP1 2 2 UDP2 IP5 MAC5 VL1 IP1 UDP2 Multiple messages can share the same Virtual Link while still maintaining:\nBandwidth guarantees Timing constraints Deterministic delivery Equivalent routing tables are configured for additional End Systems such as:\nESA ESB ESC ensuring proper traffic isolation and deterministic communication.\n⏱️ Real-Time Determinism in AFDX # AFDX achieves deterministic behavior through several mechanisms:\nFull-duplex Ethernet Virtual Link isolation BAG timing enforcement Traffic shaping Bounded switch latency Bandwidth Allocation Gap (BAG) # BAG defines:\nThe minimum interval between two consecutive frames on a VL. This guarantees controlled transmission rates and prevents uncontrolled bursts.\nTraffic Shaping # End Systems use traffic-shaping algorithms to smooth frame transmission and prevent congestion.\nThis ensures:\nPredictable latency Bounded jitter Stable queue behavior These mechanisms are critical for safety-certified avionics systems.\n🧵 VxWorks and Real-Time AFDX Integration # VxWorks is particularly well-suited for AFDX development because of its deterministic kernel behavior.\nKey Advantages # Feature Benefit Deterministic scheduling Predictable task execution Fast interrupt handling Low-latency frame processing Efficient IPC Reliable subsystem coordination Mature driver model Stable hardware integration PCI support Simplified AFDX device management This combination enables reliable implementation of:\nReal-time data transmission Status monitoring Deterministic control loops Flight-critical messaging 🔒 Reliability and Stability Considerations # Safety-critical avionics systems impose extremely strict reliability requirements.\nDevelopers must carefully validate:\nPCI mappings Interrupt behavior VL scheduling Queue depth Redundancy switching Worst-case latency Improper configuration may result in:\nExcessive jitter Packet delays Queue congestion Deterministic violations Therefore, extensive offline timing analysis and runtime monitoring are mandatory.\nUpper-layer monitoring systems are commonly used to observe:\nCommunication health Network performance Latency stability Fault conditions 🚀 Final Thoughts # AFDX represents one of the most important advances in deterministic avionics networking, enabling Ethernet to satisfy the strict timing and reliability demands of modern airborne systems.\nCombined with the real-time capabilities of VxWorks, developers can build highly stable and deterministic communication platforms suitable for:\nFlight control systems Navigation systems Aerospace monitoring platforms Mission-critical embedded infrastructure Successful implementation depends on:\nCorrect PCI configuration Proper BSP integration Accurate Virtual Link planning Deterministic traffic engineering By leveraging VxWorks’ mature PCI subsystem and ARINC 664-compliant AFDX architectures, engineers can construct scalable, certifiable, and highly reliable avionics communication systems capable of meeting the stringent requirements of modern aerospace environments.\nReference: Developing AFDX Applications on VxWorks for Avionics Systems\n","date":"2026-05-30","externalUrl":null,"permalink":"/app/developing-afdx-applications-on-vxworks-for-avionics-systems/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eDeveloping AFDX Applications on VxWorks for Avionics Systems\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eModern avionics systems demand deterministic, low-latency, and fault-tolerant communication infrastructures capable of supporting increasingly complex airborne subsystems.\u003c/p\u003e","title":"Developing AFDX Applications on VxWorks for Avionics Systems","type":"app"},{"content":"","date":"2026-05-30","externalUrl":null,"permalink":"/tags/pci/","section":"Tags","summary":"","title":"PCI","type":"tags"},{"content":"","date":"2026-05-27","externalUrl":null,"permalink":"/bsp/","section":"Bsps","summary":"","title":"Bsps","type":"bsp"},{"content":"","date":"2026-05-27","externalUrl":null,"permalink":"/tags/device-drivers/","section":"Tags","summary":"","title":"Device Drivers","type":"tags"},{"content":"","date":"2026-05-27","externalUrl":null,"permalink":"/tags/fpga/","section":"Tags","summary":"","title":"FPGA","type":"tags"},{"content":"","date":"2026-05-27","externalUrl":null,"permalink":"/tags/interrupt-handling/","section":"Tags","summary":"","title":"Interrupt Handling","type":"tags"},{"content":"","date":"2026-05-27","externalUrl":null,"permalink":"/tags/pcie/","section":"Tags","summary":"","title":"PCIe","type":"tags"},{"content":" PCIe Device Driver Development on VxWorks 7\nPCIe device driver development is a core requirement in modern embedded systems used in aerospace, defense, industrial automation, medical instrumentation, FPGA acceleration, and high-speed networking.\nWith VxWorks 7, Wind River modernized driver development through the introduction of the VxBus 2.0 framework, improved SMP support, Device Tree integration, and enhanced DMA infrastructure. These improvements significantly simplify scalable and portable PCIe driver implementation.\nThis guide provides a comprehensive walkthrough of PCIe driver development on VxWorks 7, including:\nPCIe architecture fundamentals VxBus driver architecture PCIe enumeration BAR mapping Interrupt handling DMA operations MSI/MSI-X Device Tree integration SMP-safe synchronization User-space access patterns Performance optimization Complete code examples 🧩 PCIe Architecture Fundamentals # Before implementing a PCIe driver, understanding the hardware architecture is essential.\nA PCIe endpoint device commonly contains the following components:\nComponent Description Vendor ID Manufacturer identifier Device ID Device model identifier BARs Base Address Registers for MMIO Configuration Space PCIe configuration registers MSI/MSI-X Interrupt delivery mechanisms DMA Engine High-speed memory transfer engine PCIe Capabilities Advanced PCIe feature support Typical PCIe topology:\nCPU └── Root Complex └── PCIe Switch ├── Endpoint Device A ├── Endpoint Device B └── FPGA Endpoint PCIe communication is memory-mapped, packet-based, and highly optimized for low-latency data transfer. High-performance applications almost always rely on DMA rather than programmed I/O (PIO).\n🏗️ VxWorks 7 Driver Architecture # VxWorks 7 uses the VxBus framework for driver development.\nLegacy VxWorks BSP-coupled drivers were difficult to scale and maintain. VxBus introduces a cleaner abstraction model with:\nDynamic device probing Portable driver architecture SMP-safe initialization Device Tree support Unified resource management Standardized driver registration A typical VxBus PCIe driver lifecycle includes:\nProbe() Attach() Interrupt Service Routine() DMA Handling Detach() The VxBus model enables reusable drivers across multiple BSPs and hardware platforms.\n📁 PCIe Driver Source Layout # A common VxWorks PCIe driver directory structure:\nmyPcieDrv/ ├── myPcieDrv.c ├── myPcieDrv.h ├── Makefile ├── component.cdf └── hwconf.c For larger projects, it is common to separate:\nDMA handling ISR management Register access User APIs Device Tree parsing into dedicated modules.\n📚 Required Header Files # Typical PCIe drivers require the following headers:\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;stdlib.h\u0026gt; #include \u0026lt;string.h\u0026gt; #include \u0026lt;hwif/vxBus.h\u0026gt; #include \u0026lt;hwif/vxBusLib.h\u0026gt; #include \u0026lt;hwif/buslib/vxbPciLib.h\u0026gt; #include \u0026lt;semLib.h\u0026gt; #include \u0026lt;intLib.h\u0026gt; #include \u0026lt;cacheLib.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; #include \u0026lt;sysLib.h\u0026gt; #include \u0026lt;logLib.h\u0026gt; These headers provide access to:\nVxBus infrastructure PCIe configuration APIs Synchronization primitives Interrupt management DMA cache operations 🧠 Device Context Structure # Each PCIe device instance requires a software context structure.\ntypedef struct { VXB_DEV_ID pDev; void * bar0Base; void * bar1Base; VXB_RESOURCE * pResBar0; VXB_RESOURCE * pResBar1; VXB_RESOURCE * pResIrq; UINT32 irq; SEM_ID dmaSem; SEM_ID devSem; void * dmaBuffer; PHYS_ADDR dmaPhys; UINT32 dmaSize; } MY_PCIE_CTRL; This structure maintains:\nBAR mappings IRQ resources DMA buffers synchronization objects device-specific runtime state The software context is typically stored using:\nvxbDevSoftcSet(pDev, pCtrl); 🔍 PCIe Device Identification # Assume the FPGA endpoint uses the following PCIe identifiers:\n#define MY_VENDOR_ID 0x1234 #define MY_DEVICE_ID 0x5678 The probe routine uses these values to determine whether the driver matches the hardware.\n⚙️ Probe Function Implementation # The probe function validates PCIe configuration space information.\nLOCAL STATUS myPcieProbe ( VXB_DEV_ID pDev ) { UINT16 vendorId; UINT16 deviceId; vxbPciConfigRead16(pDev, PCI_CFG_VENDOR_ID, \u0026amp;vendorId); vxbPciConfigRead16(pDev, PCI_CFG_DEVICE_ID, \u0026amp;deviceId); if ((vendorId == MY_VENDOR_ID) \u0026amp;\u0026amp; (deviceId == MY_DEVICE_ID)) { printf(\u0026#34;PCIe device matched\\n\u0026#34;); return OK; } return ERROR; } Probe routines should remain lightweight and avoid resource allocation.\n🗂️ BAR Mapping and MMIO Access # PCIe BARs expose memory-mapped hardware regions.\nExample BAR usage:\nBAR Purpose BAR0 Control registers BAR1 DMA engine BAR2 Shared memory BAR mapping example:\nLOCAL STATUS myMapBars ( MY_PCIE_CTRL * pCtrl ) { pCtrl-\u0026gt;pResBar0 = vxbResourceAlloc(pCtrl-\u0026gt;pDev, VXB_RES_MEMORY, 0); if (pCtrl-\u0026gt;pResBar0 == NULL) return ERROR; pCtrl-\u0026gt;bar0Base = (void *)vxbResourceVirtAdrsGet( pCtrl-\u0026gt;pResBar0); printf(\u0026#34;BAR0 = %p\\n\u0026#34;, pCtrl-\u0026gt;bar0Base); return OK; } Failure to correctly map BARs commonly results in:\n0xFFFFFFFF reads from registers.\n🧾 Register Access Macros # Register access macros simplify MMIO operations:\n#define REG_READ32(base, offset) \\ (*(volatile UINT32 *)((UINT8 *)(base) + (offset))) #define REG_WRITE32(base, offset, value) \\ (*(volatile UINT32 *)((UINT8 *)(base) + (offset)) = (value)) Example register map:\n#define REG_STATUS 0x00 #define REG_CONTROL 0x04 #define REG_DMA_SRC 0x08 #define REG_DMA_DST 0x0C #define REG_DMA_SIZE 0x10 #define REG_DMA_START 0x14 #define REG_INT_STATUS 0x18 #define REG_INT_ENABLE 0x1C Keeping register definitions centralized improves maintainability and hardware portability.\n🚀 Device Initialization # Device initialization configures hardware state after BAR mapping and interrupt setup.\nLOCAL STATUS myDeviceInit ( MY_PCIE_CTRL * pCtrl ) { REG_WRITE32(pCtrl-\u0026gt;bar0Base, REG_CONTROL, 0x1); REG_WRITE32(pCtrl-\u0026gt;bar0Base, REG_INT_ENABLE, 0x1); return OK; } Initialization commonly includes:\nReset control DMA engine initialization Interrupt enabling FIFO clearing Link validation ⚡ Interrupt Handling # PCIe devices support several interrupt models:\nLegacy INTx MSI MSI-X MSI and MSI-X are strongly preferred in modern SMP systems because they avoid interrupt-sharing limitations.\nISR example:\nLOCAL void myPcieIsr ( void * arg ) { MY_PCIE_CTRL * pCtrl = (MY_PCIE_CTRL *)arg; UINT32 status; status = REG_READ32(pCtrl-\u0026gt;bar0Base, REG_INT_STATUS); REG_WRITE32(pCtrl-\u0026gt;bar0Base, REG_INT_STATUS, status); if (status \u0026amp; 0x1) { semGive(pCtrl-\u0026gt;dmaSem); } } ISRs should remain minimal and defer heavy processing to worker tasks.\n🔌 Interrupt Registration # Interrupt resources are allocated through VxBus APIs.\nLOCAL STATUS mySetupInterrupt ( MY_PCIE_CTRL * pCtrl ) { pCtrl-\u0026gt;pResIrq = vxbResourceAlloc(pCtrl-\u0026gt;pDev, VXB_RES_IRQ, 0); if (pCtrl-\u0026gt;pResIrq == NULL) return ERROR; vxbIntConnect(pCtrl-\u0026gt;pDev, pCtrl-\u0026gt;pResIrq, myPcieIsr, pCtrl); vxbIntEnable(pCtrl-\u0026gt;pDev, pCtrl-\u0026gt;pResIrq); return OK; } Proper interrupt cleanup is equally important during detach and hot-plug removal.\n📦 DMA Fundamentals # PIO-based transfers become a bottleneck in high-bandwidth systems.\nPCIe DMA workflow:\nCPU allocates buffer ↓ Physical address sent to FPGA ↓ FPGA performs DMA ↓ Interrupt generated ↓ Driver wakes task DMA is mandatory for:\nFPGA acceleration high-speed networking video pipelines storage systems data acquisition platforms 🧮 DMA Buffer Allocation # DMA buffers must be cache-safe and physically accessible.\nLOCAL STATUS myAllocDma ( MY_PCIE_CTRL * pCtrl ) { pCtrl-\u0026gt;dmaSize = 0x10000; pCtrl-\u0026gt;dmaBuffer = cacheDmaMalloc(pCtrl-\u0026gt;dmaSize); if (pCtrl-\u0026gt;dmaBuffer == NULL) return ERROR; pCtrl-\u0026gt;dmaPhys = CACHE_DMA_VIRT_TO_PHYS( pCtrl-\u0026gt;dmaBuffer); printf(\u0026#34;DMA virt=%p phys=0x%llx\\n\u0026#34;, pCtrl-\u0026gt;dmaBuffer, (unsigned long long)pCtrl-\u0026gt;dmaPhys); return OK; } DMA buffers should typically be:\ncache-line aligned page aligned preallocated reused when possible 🔄 Starting DMA Transfers # DMA transfer example:\nLOCAL STATUS myStartDma ( MY_PCIE_CTRL * pCtrl ) { cacheFlush(DATA_CACHE, pCtrl-\u0026gt;dmaBuffer, pCtrl-\u0026gt;dmaSize); REG_WRITE32(pCtrl-\u0026gt;bar0Base, REG_DMA_DST, (UINT32)pCtrl-\u0026gt;dmaPhys); REG_WRITE32(pCtrl-\u0026gt;bar0Base, REG_DMA_SIZE, pCtrl-\u0026gt;dmaSize); REG_WRITE32(pCtrl-\u0026gt;bar0Base, REG_DMA_START, 1); return OK; } Before outbound DMA:\ncacheFlush() must be used to ensure memory coherency.\n⏳ Waiting for DMA Completion # DMA completion typically relies on interrupt-driven synchronization.\nLOCAL STATUS myWaitDma ( MY_PCIE_CTRL * pCtrl ) { if (semTake(pCtrl-\u0026gt;dmaSem, sysClkRateGet() * 5) == ERROR) { printf(\u0026#34;DMA timeout\\n\u0026#34;); return ERROR; } cacheInvalidate(DATA_CACHE, pCtrl-\u0026gt;dmaBuffer, pCtrl-\u0026gt;dmaSize); return OK; } After inbound DMA:\ncacheInvalidate() ensures stale cache lines are discarded.\n🧱 Complete Attach Routine # The attach routine initializes all driver resources.\nLOCAL STATUS myPcieAttach ( VXB_DEV_ID pDev ) { MY_PCIE_CTRL * pCtrl; pCtrl = vxbMemAlloc(sizeof(MY_PCIE_CTRL)); if (pCtrl == NULL) return ERROR; memset(pCtrl, 0, sizeof(*pCtrl)); pCtrl-\u0026gt;pDev = pDev; vxbDevSoftcSet(pDev, pCtrl); pCtrl-\u0026gt;dmaSem = semBCreate(SEM_Q_FIFO, SEM_EMPTY); pCtrl-\u0026gt;devSem = semMCreate(SEM_Q_PRIORITY | SEM_INVERSION_SAFE); if (myMapBars(pCtrl) != OK) return ERROR; if (myAllocDma(pCtrl) != OK) return ERROR; if (mySetupInterrupt(pCtrl) != OK) return ERROR; if (myDeviceInit(pCtrl) != OK) return ERROR; printf(\u0026#34;PCIe driver attached\\n\u0026#34;); return OK; } Production-grade drivers should also include robust cleanup paths for failure handling.\n🛠️ Driver Registration # VxBus drivers register methods through the driver table.\nLOCAL VXB_DRV_METHOD myMethods[] = { { VXB_DEVMETHOD_CALL(vxbDevProbe), (FUNCPTR)myPcieProbe }, { VXB_DEVMETHOD_CALL(vxbDevAttach), (FUNCPTR)myPcieAttach }, VXB_DEVMETHOD_END }; LOCAL VXB_DRV myPcieDrv = { { NULL }, \u0026#34;myPcieDrv\u0026#34;, \u0026#34;Custom PCIe Driver\u0026#34;, VXB_BUSID_PCI, 0, 0, myMethods, NULL }; VXB_DRV_DEF(myPcieDrv) This structure enables automatic driver discovery during PCIe enumeration.\n🌲 Device Tree Integration # VxWorks 7 supports Flattened Device Tree (FDT)-based hardware configuration.\nExample DTS node:\npcie@0x80000000 { compatible = \u0026#34;vendor,my-pcie\u0026#34;; reg = \u0026lt;0x80000000 0x1000\u0026gt;; interrupts = \u0026lt;32\u0026gt;; }; Device Tree integration simplifies:\nhardware portability BSP maintenance multi-platform support 🔒 SMP Synchronization # Modern embedded systems are commonly multicore.\nPotential SMP issues include:\nconcurrent register access interrupt races DMA ownership conflicts shared buffer corruption Mutex example:\nsemTake(pCtrl-\u0026gt;devSem, WAIT_FOREVER); /* critical section */ semGive(pCtrl-\u0026gt;devSem); VxBus was specifically designed to support SMP-safe driver development.\n🧭 PCIe Configuration Space Access # Drivers frequently need direct access to PCIe configuration space.\nUINT16 command; vxbPciConfigRead16(pDev, PCI_CFG_COMMAND, \u0026amp;command); command |= PCI_CMD_MASTER_ENABLE; vxbPciConfigWrite16(pDev, PCI_CFG_COMMAND, command); Typical configuration enables:\nBus mastering Memory decoding Interrupt delivery 📡 MSI Enable Verification # Basic PCIe status inspection example:\nUINT16 status; vxbPciConfigRead16(pDev, PCI_CFG_STATUS, \u0026amp;status); printf(\u0026#34;PCI status = 0x%x\\n\u0026#34;, status); When debugging MSI issues, verify:\nMSI capability presence interrupt vector assignment PCIe command register configuration interrupt masking state 🖥️ User-Space Access Interfaces # Applications often require controlled access to device registers or DMA buffers.\nExample helper API:\nSTATUS myReadReg ( MY_PCIE_CTRL * pCtrl, UINT32 offset, UINT32 * value ) { *value = REG_READ32(pCtrl-\u0026gt;bar0Base, offset); return OK; } Production systems commonly expose:\nIOCTL interfaces shared memory channels zero-copy buffers message queues 🐞 PCIe Driver Debugging # Useful VxWorks shell commands:\n-\u0026gt; vxbDevShow -\u0026gt; vxbPciShow -\u0026gt; devs -\u0026gt; i Debug logging example:\nprintf(\u0026#34;BAR0=%p IRQ=%d\\n\u0026#34;, pCtrl-\u0026gt;bar0Base, pCtrl-\u0026gt;irq); WindView can help analyze:\nISR latency scheduling behavior DMA timing SMP contention interrupt storms ⚠️ Common PCIe Driver Issues # Problem Typical Cause BAR reads return 0xFFFFFFFF BAR not mapped DMA corruption Cache coherency issue ISR never fires MSI not enabled System hangs Invalid DMA address Enumeration failure Incorrect Vendor/Device ID SMP race conditions Missing synchronization Most PCIe driver failures are related to synchronization, DMA coherency, or resource initialization order.\n🚄 PCIe Performance Optimization # Use DMA # PIO transfers severely limit throughput.\nPrefer MSI-X # MSI-X provides better scalability across multicore systems.\nAlign DMA Buffers # memalign(64, size); Batch DMA Transfers # Large DMA blocks significantly improve throughput efficiency.\nReduce Interrupt Frequency # Interrupt coalescing can improve CPU utilization in high-throughput systems.\n🧬 FPGA PCIe System Architecture # Typical FPGA PCIe integration:\nVxWorks CPU ↓ PCIe Root Complex ↓ FPGA Endpoint ├── DMA Engine ├── Control Registers ├── DDR Buffer └── Interrupt Generator High-performance FPGA systems can achieve multi-hundred MB/s or multi-GB/s throughput using optimized DMA architectures.\n🧵 Recommended Driver Design Pattern # Recommended architecture:\nISR ↓ Semaphore ↓ Worker Task ↓ DMA Completion ↓ Application Notification This model minimizes ISR latency while maintaining deterministic behavior.\n👷 Worker Task Example # LOCAL void myWorkerTask ( MY_PCIE_CTRL * pCtrl ) { while (1) { semTake(pCtrl-\u0026gt;dmaSem, WAIT_FOREVER); printf(\u0026#34;DMA completed\\n\u0026#34;); /* process data */ } } Worker tasks should handle:\nDMA post-processing buffer management application notification retry handling 🧠 Cache Coherency Management # DMA and CPU caches must remain synchronized.\nBefore DMA OUT:\ncacheFlush(DATA_CACHE, buffer, size); After DMA IN:\ncacheInvalidate(DATA_CACHE, buffer, size); Cache coherency bugs are among the most difficult PCIe driver problems to diagnose.\n🔌 Hot-Plug Support # PCIe supports runtime device insertion and removal.\nDrivers should properly handle:\ndevice disappearance interrupt teardown DMA shutdown resource release task termination Incomplete cleanup often causes kernel instability.\n🛡️ PCIe Security Considerations # PCIe devices have direct memory access capability.\nDrivers should validate:\nDMA sizes DMA address ranges user requests interrupt sources register accesses Never assume endpoint hardware is trustworthy.\n🧪 Advanced PCIe Topics # Advanced VxWorks PCIe features include:\nSR-IOV Scatter-gather DMA MSI-X vector tables NUMA-aware DMA IOMMU integration Zero-copy networking Peer-to-peer PCIe Shared memory transport These capabilities become increasingly important in high-performance multicore systems.\n🧰 Example Makefile # CPU=ARMARCH8 TOOL=gnu OBJS = myPcieDrv.o all: $(CC) -c myPcieDrv.c Larger projects typically integrate with the VxWorks build system and component framework.\n📌 Conclusion # PCIe device driver development on VxWorks 7 combines multiple disciplines:\nreal-time systems engineering hardware/software integration interrupt architecture DMA optimization SMP synchronization low-level memory management VxBus 2.0 provides a significantly cleaner and more scalable architecture compared to legacy BSP-coupled driver models.\nFor high-performance FPGA, networking, storage, and industrial systems, mastering DMA, interrupt handling, and synchronization is essential for building production-grade PCIe solutions.\nA recommended learning progression is:\nBAR access Interrupt handling DMA transfers MSI/MSI-X SMP synchronization Scatter-gather DMA Zero-copy architectures Multi-device scaling Once these concepts are mastered, developers can build deterministic, low-latency PCIe systems capable of sustaining extremely high throughput on modern embedded platforms.\n","date":"2026-05-27","externalUrl":null,"permalink":"/bsp/pcie-device-driver-development-on-vxworks-7/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003ePCIe Device Driver Development on VxWorks 7\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003ePCIe device driver development is a core requirement in modern embedded systems used in aerospace, defense, industrial automation, medical instrumentation, FPGA acceleration, and high-speed networking.\u003c/p\u003e","title":"PCIe Device Driver Development on VxWorks 7","type":"bsp"},{"content":"","date":"2026-05-27","externalUrl":null,"permalink":"/tags/smp/","section":"Tags","summary":"","title":"SMP","type":"tags"},{"content":"","date":"2026-05-27","externalUrl":null,"permalink":"/tags/vxbus/","section":"Tags","summary":"","title":"VxBus","type":"tags"},{"content":"","date":"2026-05-25","externalUrl":null,"permalink":"/tags/dds-security/","section":"Tags","summary":"","title":"DDS Security","type":"tags"},{"content":"","date":"2026-05-25","externalUrl":null,"permalink":"/tags/iiot/","section":"Tags","summary":"","title":"IIoT","type":"tags"},{"content":" Integrating Secure OpenDDS in VxWorks 7 With VSB Layers\n🚀 Introduction # As modern embedded systems become increasingly interconnected, the demand for secure, deterministic, and scalable real-time communication continues to grow across industries such as:\nIndustrial IoT (IIoT) Aerospace Defense Autonomous systems Transportation Industrial automation Traditional request-response communication models often struggle to meet the latency, scalability, and fault-tolerance requirements of these distributed real-time environments.\nTo address these challenges, many high-assurance systems are adopting:\nDDS (Data Distribution Service) Publish-subscribe communication models Decentralized middleware architectures Within the embedded RTOS ecosystem, the combination of:\nVxWorks 7 OpenDDS 3.13 DDS Security VSB Layers provides a production-grade framework for building secure, real-time distributed systems.\nThis article explores how OpenDDS integrates into VxWorks 7 using the VxWorks Source Build (VSB) Layer system, while leveraging DDS Security and Real-Time Processes (RTPs) to deliver high-performance, fault-isolated communication architectures suitable for mission-critical environments.\n🏗️ Understanding the VxWorks 7 VSB Layer Architecture # Historically, integrating large third-party middleware stacks into RTOS environments was notoriously difficult.\nDevelopers often faced challenges including:\nManual source tree merging Custom makefile modifications Dependency conflicts Fragile path configurations Non-reproducible builds VxWorks 7 significantly modernized this workflow through the introduction of the:\nVxWorks Source Build (VSB) Layer system ⚙️ What Is a VSB Layer? # A VSB Layer is a modular packaging structure that encapsulates:\nSource files Build rules Configuration metadata Dependencies Compiler integration Platform settings VSB Layers integrate directly into the VxWorks build pipeline, allowing middleware components to be added in a clean and maintainable way.\nBenefits of the VSB Layer Model # The VSB approach provides several major advantages:\nModular dependency management Cleaner build integration Reusable middleware packaging Simplified upgrades Improved portability Reduced configuration complexity This architecture is especially valuable for large middleware frameworks such as DDS stacks.\n🧩 OpenDDS Ecosystem Components # OpenDDS relies on several foundational technologies provided through dedicated VSB Layers.\nACE (Adaptive Communication Environment) # ACE provides:\nObject-oriented networking abstractions Event handling Concurrency primitives Socket frameworks Portable communication infrastructure It serves as the foundational runtime layer beneath TAO and OpenDDS.\nTAO (The ACE ORB) # TAO is a real-time CORBA implementation optimized for deterministic embedded systems.\nKey capabilities include:\nReal-time scheduling support Predictable communication latency Efficient object request brokering CORBA-compliant middleware services OpenDDS # OpenDDS is an open-source implementation of the OMG DDS specification.\nIt provides:\nPublish-subscribe messaging Real-time QoS control Decentralized discovery Data-centric communication Secure DDS extensions Together, ACE, TAO, and OpenDDS form a highly capable middleware stack for distributed embedded systems.\n🖥️ OpenDDS 3.13 Architecture on VxWorks 7 # OpenDDS 3.13 targets:\nVxWorks Real-Time Processes (RTPs) rather than kernel-space execution.\nThis is a major architectural advantage for reliability and fault isolation.\n🔒 Why RTP-Based DDS Deployment Matters # Running DDS applications inside RTPs provides:\nProcess isolation Protected address spaces Fault containment Safer middleware execution If an application crashes or encounters memory corruption, the VxWorks kernel remains protected and operational.\nThis is particularly important in:\nSafety-critical systems Mission-critical aerospace applications Industrial control environments where kernel integrity must remain uncompromised.\n🏛️ Host-to-Target Build Architecture # The OpenDDS build pipeline follows a split host/target architecture.\nDevelopment and Deployment Flow # +------------------------------------------------------------------------+ | DEVELOPMENT HOST (Linux / Windows) | | | | [ IDL Files (.idl) ] ---\u0026gt; (tao_idl / opendds_idl) ---\u0026gt; [ C++ Code ] | +------------------------------------------------------------------------+ | v (Cross-Compile) +------------------------------------------------------------------------+ | TARGET HW / SIMULATOR (VxWorks 7 RTP) | | | | +----------------------------------------------------------------+ | | | Secure OpenDDS App | | | +----------------------------------------------------------------+ | | | OpenDDS 3.13 Layer (Security Plugins) | | | +----------------------------------------------------------------+ | | | ACE / TAO Layers | | | +----------------------------------------------------------------+ | | | VxWorks 7 Kernel | | | +----------------------------------------------------------------+ | +------------------------------------------------------------------------+ This workflow separates:\nHost-side code generation Cross-compilation Target runtime execution into clean development stages.\n🧠 IDL-Based Data Modeling # DDS communication begins with Interface Definition Language (IDL) files.\nIDL files define:\nData structures Topics Interfaces Serialization rules in a platform-independent format.\n⚙️ Host-Side Code Generation Tools # OpenDDS provides specialized code generation utilities.\ntao_idl # tao_idl parses standard IDL files and generates:\nCORBA stubs Skeletons Serialization interfaces opendds_idl # opendds_idl generates DDS-specific support code including:\nDataWriter support DataReader support Type registration logic Topic serialization infrastructure These generated files become part of the final application build.\n🔨 Cross-Compilation Against the VSB # After code generation, the application is cross-compiled using:\nLLVM GCC Wind River toolchains depending on the target BSP and architecture.\nThe build links against pre-integrated VSB Layer libraries including:\nACE TAO OpenDDS This dramatically simplifies middleware integration compared to traditional manual approaches.\n🔐 DDS Security in OpenDDS 3.13 # Traditional DDS deployments often rely on network perimeter defenses such as:\nFirewalls VPNs Network segmentation However, modern distributed systems increasingly require:\nZero-trust communication Fine-grained authorization End-to-end encryption Identity validation OpenDDS 3.13 addresses these requirements through support for the:\nOMG DDS Security Specification 🛡️ DDS Security Plugin Architecture # DDS Security introduces modular, pluggable security services directly into the middleware layer.\nSecurity Components Overview # Security Plugin Functionality Authentication Verifies participant identities using PKI certificates Access Control Enforces signed topic-level permissions Cryptographic Encrypts and authenticates DDS traffic Logging Tracks security events and violations Data Tagging Applies metadata-based data classification This architecture provides decentralized, topic-level security enforcement.\n🔑 Authentication # Authentication validates DDS participants using:\nX.509 certificates PKI infrastructure Identity handshakes Only trusted participants may join the DDS domain.\nThis prevents:\nRogue node participation Unauthorized discovery Identity spoofing 📜 Access Control # Access control policies are defined using signed XML configuration files.\nThese policies determine:\nWhich topics a participant may publish Which topics may be subscribed to Allowed QoS configurations Domain-level permissions This enables highly granular communication control.\n🔒 Cryptographic Protection # The cryptographic plugin provides:\nAES-GCM encryption Integrity validation Anti-tampering protection Secure payload transmission DDS traffic remains protected even when traversing untrusted networks.\n📋 Secure Logging # The logging subsystem records:\nAuthentication attempts Policy violations Connection activity Security events This provides valuable auditability for regulated or mission-critical systems.\n🏷️ Data Tagging # Data tagging enables metadata classification of DDS samples.\nPotential use cases include:\nSecurity domains Priority routing Information labeling Multi-level security architectures 🌐 Security Benefits in Embedded Systems # By combining DDS Security with VxWorks RTP isolation, embedded systems gain several critical protections.\nEncrypted Communications # Data remains protected against:\nPacket sniffing Traffic interception Unauthorized observation Controlled Discovery # Unauthorized nodes cannot:\nDiscover DDS topology Enumerate topics Join the communication domain Injection Protection # Malicious actors are prevented from:\nInjecting fake messages Publishing unauthorized data Corrupting system state This is particularly important in:\nDefense systems Autonomous platforms Industrial control infrastructure ⚡ Real-Time Advantages of DDS on VxWorks # DDS was specifically designed for real-time distributed systems.\nCombined with VxWorks, it enables:\nDeterministic communication Low-latency messaging Decentralized architectures Scalable data distribution Key Real-Time Features # OpenDDS supports:\nQoS policy tuning Deadline guarantees Priority-based transport Reliable multicast Asynchronous publishing These capabilities are essential for high-performance embedded applications.\n🏭 Typical Embedded Use Cases # The VxWorks + OpenDDS architecture is well suited for:\nAerospace Systems # Mission data distribution Sensor fusion Avionics communication Flight control coordination Defense Platforms # Tactical communication Multi-node command systems Distributed situational awareness Industrial IoT # Factory automation Predictive maintenance Real-time telemetry Distributed sensor networks Autonomous Systems # Vehicle coordination Robotics communication Edge analytics Real-time control loops 🛠️ Operational Advantages of VSB-Based Middleware Integration # Using VSB Layers significantly reduces integration complexity.\nSimplified Build Management # Developers avoid:\nManual dependency resolution Custom linker scripts Middleware source tree patching Cleaner Upgrades # Middleware stacks can be updated more predictably without destabilizing the overall BSP.\nImproved Reusability # The same VSB Layers can be reused across:\nMultiple projects Different target platforms Various hardware architectures 🚀 Future Scalability and Extensibility # The modular architecture of OpenDDS and VSB Layers provides a strong foundation for future expansion.\nPotential enhancements include:\nTSN (Time-Sensitive Networking) DDS over shared memory transports Edge-cloud integration Multi-domain federation Advanced QoS orchestration As distributed embedded systems continue evolving, DDS-based architectures are likely to become increasingly central to high-assurance real-time communication.\n🏁 Conclusion # The integration of OpenDDS 3.13 with VxWorks 7 through standardized VSB Layers provides a modern, scalable, and secure middleware architecture for real-time embedded systems.\nBy leveraging:\nRTP isolation DDS Security ACE/TAO middleware VSB modular integration developers can deploy highly reliable publish-subscribe communication systems suitable for demanding environments including:\nAerospace Defense Industrial automation IIoT infrastructure Compared to traditional RTOS middleware integration approaches, the VSB Layer model dramatically simplifies deployment, dependency management, and long-term maintainability.\nThe result is a production-ready foundation for building secure, distributed, real-time embedded platforms capable of operating safely across complex and potentially untrusted network environments.\n","date":"2026-05-25","externalUrl":null,"permalink":"/training/integrating-secure-opendds-in-vxworks-7-with-vsb-layers/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eIntegrating Secure OpenDDS in VxWorks 7 With VSB Layers\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🚀 Introduction \n    \u003cdiv id=\"-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eAs modern embedded systems become increasingly interconnected, the demand for secure, deterministic, and scalable real-time communication continues to grow across industries such as:\u003c/p\u003e","title":"Integrating Secure OpenDDS in VxWorks 7 With VSB Layers","type":"training"},{"content":" Mastering UART Programming in VxWorks 7 With VxBus and POSIX I/O\n🚀 Introduction # The Universal Asynchronous Receiver-Transmitter (UART) remains one of the most fundamental communication interfaces in embedded systems. Despite the rise of high-speed buses and networked protocols, UART continues to play a critical role in:\nBoard bring-up Debugging consoles Sensor communication Industrial control Bootloaders Device management Low-level diagnostics In VxWorks 7, UART access is built on top of the modern VxBus driver framework, which abstracts hardware details behind a standardized device model and integrates seamlessly with the POSIX I/O subsystem.\nRather than manipulating UART registers directly, developers interact with serial devices using familiar system calls such as:\nopen() read() write() ioctl() close() This article provides a comprehensive technical guide to UART programming in VxWorks 7, including:\nVxBus architecture UART device interaction POSIX serial I/O Runtime configuration using ioctl() Concurrent read/write task design Production-ready C implementation Kernel component requirements Build and deployment workflow The examples and explanations target experienced embedded and RTOS developers building production-grade serial communication systems.\n🏗️ VxWorks 7 UART Architecture # VxWorks 7 uses the VxBus framework to standardize hardware driver integration across architectures and BSPs.\nInstead of binding applications directly to hardware-specific implementations, VxBus introduces a layered abstraction model.\nVxWorks UART Software Stack # +--------------------------------------------------+ | VxWorks Application | +--------------------------------------------------+ | v (POSIX: open, read, write, ioctl) +--------------------------------------------------+ | I/O System (iosLib) | +--------------------------------------------------+ | v (ttyDrv / sioLib) +--------------------------------------------------+ | VxBus Serial Driver | +--------------------------------------------------+ | v (Hardware Registers) +--------------------------------------------------+ | Physical UART | +--------------------------------------------------+ Core Architectural Components # VxBus # Provides:\nDriver registration Device discovery Resource management Hardware abstraction BSP integration iosLib # The VxWorks I/O subsystem responsible for:\nFile descriptor management Device lookup POSIX API routing ttyDrv / sioLib # These layers provide terminal and serial abstractions:\nTTY device handling Buffer management UART configuration interfaces Hardware option controls Physical UART Driver # The lowest layer interacts directly with:\nUART registers FIFOs Interrupts DMA engines Clock configuration Applications remain isolated from hardware-specific implementation details.\n⚙️ UART Device Registration in VxWorks # When a VxBus serial driver initializes, it registers one or more UART devices into the VxWorks I/O device table.\nTypical device names include:\n/tyCo/0 /tyCo/1 /tyCo/2 Applications open these device nodes using standard POSIX APIs.\nExample:\nfd = open(\u0026#34;/tyCo/1\u0026#34;, O_RDWR, 0); The returned file descriptor becomes the primary interface for:\nReading incoming serial data Writing outgoing data Runtime UART configuration 💻 Complete UART Programming Example # The following implementation demonstrates a production-style UART communication module for VxWorks 7.\nKey Features # The example includes:\nUART initialization Baud rate configuration Hardware option configuration Raw mode operation Concurrent asynchronous reading Blocking I/O handling Buffer flushing Graceful task management 📄 Full Source Code # #include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;ioLib.h\u0026gt; #include \u0026lt;sioLib.h\u0026gt; #include \u0026lt;fcntl.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;stdlib.h\u0026gt; #include \u0026lt;string.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; #define UART_DEV_NAME \u0026#34;/tyCo/1\u0026#34; #define BUFFER_SIZE 128 STATUS uart_configure(int fd, int baudRate); void uart_read_task(int fd); /******************************************************************************* * * uart_example_main - Main UART demonstration entry point * * RETURNS: OK or ERROR */ STATUS uart_example_main(void) { int fd; const char *tx_msg = \u0026#34;Hello from VxWorks 7 UART!\\r\\n\u0026#34;; printf(\u0026#34;[UART_MAIN] Opening device: %s...\\n\u0026#34;, UART_DEV_NAME); fd = open(UART_DEV_NAME, O_RDWR, 0); if (fd == ERROR) { perror(\u0026#34;[UART_MAIN] Error opening UART device\u0026#34;); return ERROR; } if (uart_configure(fd, 115200) != OK) { printf(\u0026#34;[UART_MAIN] UART configuration failed.\\n\u0026#34;); close(fd); return ERROR; } printf(\u0026#34;[UART_MAIN] Transmitting data...\\n\u0026#34;); ssize_t bytesWritten = write(fd, tx_msg, strlen(tx_msg)); if (bytesWritten == ERROR) { perror(\u0026#34;[UART_MAIN] Write error\u0026#34;); close(fd); return ERROR; } printf(\u0026#34;[UART_MAIN] Successfully wrote %zd bytes.\\n\u0026#34;, bytesWritten); TASK_ID readTaskId = taskSpawn( \u0026#34;tUartRead\u0026#34;, 100, VX_FP_TASK, 4096, (FUNCPTR)uart_read_task, fd, 0, 0, 0, 0, 0, 0, 0, 0, 0); if (readTaskId == TASK_ID_ERROR) { perror(\u0026#34;[UART_MAIN] Failed to spawn read task\u0026#34;); close(fd); return ERROR; } return OK; } /******************************************************************************* * * uart_configure - Configure UART parameters * * RETURNS: OK or ERROR */ STATUS uart_configure(int fd, int baudRate) { if (ioctl(fd, FIOBAUDRATE, baudRate) == ERROR) { perror(\u0026#34;[UART_CONF] Failed to set Baud Rate\u0026#34;); return ERROR; } if (ioctl(fd, FIOSETOPTIONS, OPT_RAW) == ERROR) { perror(\u0026#34;[UART_CONF] Failed to enable RAW mode\u0026#34;); return ERROR; } int hwOptions = CS8 | STOPB; if (ioctl(fd, SIO_HW_OPTS_SET, hwOptions) == ERROR) { perror(\u0026#34;[UART_CONF] Failed to configure hardware options\u0026#34;); return ERROR; } if (ioctl(fd, FIOFLUSH, 0) == ERROR) { perror(\u0026#34;[UART_CONF] Failed to flush buffers\u0026#34;); return ERROR; } printf(\u0026#34;[UART_CONF] UART configured successfully (8N1).\\n\u0026#34;); return OK; } /******************************************************************************* * * uart_read_task - UART receive task */ void uart_read_task(int fd) { char rxBuffer[BUFFER_SIZE]; ssize_t bytesRead; printf(\u0026#34;[UART_READ] Read task started.\\n\u0026#34;); while (1) { memset(rxBuffer, 0, sizeof(rxBuffer)); bytesRead = read(fd, rxBuffer, sizeof(rxBuffer) - 1); if (bytesRead \u0026gt; 0) { rxBuffer[bytesRead] = \u0026#39;\\0\u0026#39;; printf( \u0026#34;[UART_READ] Received %zd bytes: %s\\n\u0026#34;, bytesRead, rxBuffer); if (strncmp(rxBuffer, \u0026#34;QUIT\u0026#34;, 4) == 0) { printf(\u0026#34;[UART_READ] Quit command received.\\n\u0026#34;); break; } } else if (bytesRead == ERROR) { perror(\u0026#34;[UART_READ] Read error\u0026#34;); break; } } close(fd); } 🔍 Understanding the VxWorks I/O Subsystem # The open() call interacts with the VxWorks I/O system managed by:\niosLib Internally, VxWorks performs:\nDevice table lookup Driver resolution File descriptor allocation Driver instance binding When opening:\n\u0026#34;/tyCo/1\u0026#34; the I/O subsystem maps the path to the appropriate VxBus serial driver instance.\nThis design provides:\nHardware abstraction Portability across BSPs Unified driver interfaces POSIX compatibility ⚡ UART Configuration Using ioctl() # Most UART runtime configuration occurs through:\nioctl() This API forwards device-specific control requests to the underlying serial driver.\n🧠 Baud Rate Configuration # ioctl(fd, FIOBAUDRATE, baudRate); This request instructs the driver to:\nCalculate UART clock divisors Program baud rate generator registers Update internal timing configuration Typical supported rates include:\n9600 19200 38400 57600 115200 Higher custom rates depending on hardware 🧵 RAW Mode vs Line Mode # By default, some VxWorks serial channels initialize in:\nOPT_LINE mode.\nLine mode may perform:\nLine buffering Echo handling Backspace processing Newline translation This behavior is unsuitable for most embedded binary protocols.\nEnabling raw mode:\nioctl(fd, FIOSETOPTIONS, OPT_RAW); disables all line processing.\nIn raw mode:\nBytes are delivered immediately No newline interpretation occurs Binary payloads remain unmodified This is essential for:\nProtocol parsers Binary communication Sensor interfaces Industrial serial devices 🔧 Hardware Option Configuration # Hardware framing parameters are configured using:\nioctl(fd, SIO_HW_OPTS_SET, hwOptions); Example Configuration # int hwOptions = CS8 | STOPB; This configures:\n8 data bits 1 stop bit No parity Common UART Framing Options # Option Meaning CS5–CS8 Character width STOPB Stop bit configuration PARENB Enable parity PARODD Odd parity Actual behavior may vary slightly depending on the BSP and UART controller implementation.\n🔄 Buffer Flushing # UART FIFOs and software ring buffers may contain stale data during startup.\nThe following call clears both receive and transmit buffers:\nioctl(fd, FIOFLUSH, 0); This helps avoid:\nGarbage data Partial frames Initialization artifacts during startup sequences.\n🧵 Task-Based UART Concurrency # VxWorks is a deterministic multitasking RTOS.\nBlocking Read Behavior # In raw mode:\nread() typically blocks until data becomes available.\nIf UART reading occurs in the main task, the application could stall indefinitely waiting for input.\n🚦 Using taskSpawn() for Asynchronous Reading # To avoid blocking the primary application flow, UART reading is delegated to a dedicated task.\nExample:\ntaskSpawn(...) This creates an independent execution context:\ntUartRead Advantages of Dedicated UART Tasks # This design enables:\nAsynchronous serial reception Concurrent transmit/receive operation Better responsiveness Deterministic scheduling Simplified protocol parsing Since VxWorks tasks share the same address space, the file descriptor can safely be shared across tasks.\n📦 Required Kernel Components # To successfully build and run the UART example, several VxWorks kernel components must be included in the VIP configuration.\nRequired Components # Component Purpose COMPONENT_VXBUS Core VxBus infrastructure INCLUDE_SIO Serial I/O framework INCLUDE_TTY_DEV /tyCo/ device abstraction INCLUDE_IO_SYSTEM POSIX I/O subsystem Without these components, serial devices may not initialize correctly.\n🛠️ Compilation Workflow # The code can be compiled using:\nWind River Workbench Command-line cross compiler Example ARM Build Command # ccarm \\ -march=armv7-a \\ -mfloat-abi=hard \\ -O2 \\ -I$WIND_BASE/target/h \\ -D_WRS_KERNEL \\ -c uart_example.c \\ -o uart_example.o Compiler flags vary depending on:\nArchitecture BSP Toolchain Floating-point configuration 🚀 Loading and Executing on Target # After compilation, the object module can be loaded into the target system.\nLoad Module # -\u0026gt; ld \u0026lt; uart_example.o Execute Entry Function # -\u0026gt; uart_example_main Successful execution should:\nOpen the UART device Configure serial parameters Transmit startup data Spawn asynchronous receive task Begin continuous UART listening 🛡️ Production Considerations # Production UART systems often require additional robustness features.\nRecommended Enhancements # Timeouts # Consider using:\nselect() Non-blocking I/O Timer watchdogs to prevent indefinite blocking.\nRing Buffers # High-throughput systems should implement:\nCircular buffers Lock-free queues DMA-assisted reception for improved scalability.\nSynchronization # Shared UART resources may require:\nSemaphores Mutexes Message queues to coordinate concurrent access safely.\nError Handling # Production code should monitor:\nFraming errors Overrun conditions Parity errors Disconnect events through driver-specific status interfaces.\n🏁 Conclusion # UART programming in VxWorks 7 combines the determinism of a real-time operating system with the flexibility of a modern POSIX-style I/O framework.\nThrough the VxBus infrastructure, developers gain:\nHardware abstraction Portability Standardized APIs Driver modularity while retaining full access to low-level serial configuration and high-performance communication.\nBy leveraging:\nopen() read() write() ioctl() taskSpawn() developers can build reliable and scalable UART communication systems suitable for:\nIndustrial automation Aerospace platforms Embedded Linux migration projects Board support package development High-reliability RTOS applications Mastering the interaction between VxBus, the VxWorks I/O subsystem, and UART device drivers is essential for building production-grade embedded communication software on VxWorks 7.\n","date":"2026-05-25","externalUrl":null,"permalink":"/app/mastering-uart-programming-in-vxworks-7-with-vxbus-and-posix-io/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eMastering UART Programming in VxWorks 7 With VxBus and POSIX I/O\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🚀 Introduction \n    \u003cdiv id=\"-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThe Universal Asynchronous Receiver-Transmitter (UART) remains one of the most fundamental communication interfaces in embedded systems. Despite the rise of high-speed buses and networked protocols, UART continues to play a critical role in:\u003c/p\u003e","title":"Mastering UART Programming in VxWorks 7 With VxBus and POSIX I/O","type":"app"},{"content":"","date":"2026-05-25","externalUrl":null,"permalink":"/tags/posix/","section":"Tags","summary":"","title":"POSIX","type":"tags"},{"content":"","date":"2026-05-25","externalUrl":null,"permalink":"/tags/serial-communication/","section":"Tags","summary":"","title":"Serial Communication","type":"tags"},{"content":"","date":"2026-05-25","externalUrl":null,"permalink":"/tags/uart/","section":"Tags","summary":"","title":"UART","type":"tags"},{"content":"","date":"2026-05-25","externalUrl":null,"permalink":"/tags/dynamic-loading/","section":"Tags","summary":"","title":"Dynamic Loading","type":"tags"},{"content":" Extending VxWorks With Automatic Module Loading Management\n⚙️ Abstract # VxWorks is a widely deployed real-time operating system used in aerospace, industrial control, networking, and mission-critical embedded systems. Although the platform supports dynamic module loading, the native implementation is primarily intended for development and debugging scenarios rather than long-term operational deployment.\nThe default mechanism lacks several features required by production-grade embedded systems, including:\nReliable dependency management Duplicate module protection Strict unresolved symbol handling Safe unloading validation Automatic module restoration after reboot This article presents the design and implementation of a dynamic loading management system that extends the native VxWorks loading framework. The system introduces dependency tracking, configurable auto-loading, persistent module configuration storage, and enhanced runtime validation.\nThe resulting architecture significantly improves system maintainability, configurability, reliability, and fault recovery capability in complex embedded environments.\n🛰️ Introduction # Modern embedded systems increasingly operate in dynamic and mission-critical environments where runtime flexibility and rapid fault recovery are essential.\nIn traditional desktop operating systems such as Windows, startup applications and services can automatically launch after boot. Similar capabilities are becoming increasingly important in embedded domains including:\nAerospace systems Satellite platforms Communication infrastructure Industrial automation Command and control systems Dynamic Operational Requirements # Many embedded systems must support runtime behavioral changes without requiring complete firmware reflashing or hardware replacement.\nFor example, satellite systems may need to:\nAdjust orbital attitude Switch operational modes Update mission parameters Deploy new algorithms Recover from runtime failures In these scenarios, rapid reboot recovery and reliable module restoration become critical operational requirements.\nVxWorks already provides dynamic loading support, making it a strong foundation for such systems. However, its default implementation lacks several safeguards needed for robust production deployment.\nThis article explores how a dynamic loading management system can extend VxWorks to provide:\nManaged runtime module loading Dependency-aware unloading Persistent auto-load configuration Automatic reboot recovery 🧩 Native VxWorks Dynamic Loading Mechanism # VxWorks supports dynamic loading to simplify application development and debugging workflows.\nPurpose of Native Dynamic Loading # Developers can:\nLoad modules dynamically Test applications without rebuilding the OS image Reload updated binaries during development Reduce deployment iteration time This mechanism is highly effective during debugging and integration phases.\nRuntime Limitations # Although convenient for development, the default implementation introduces several risks in production systems.\n⚠️ Limitations of the Native Loading Mechanism # Duplicate Module Name Handling # When loading a module with the same name as an existing module, VxWorks automatically disables the previous version.\nWhile useful during development, this behavior is dangerous in operational systems because it can unintentionally replace active functionality.\nUnresolved Symbol Handling # If unresolved symbols are detected during loading, VxWorks typically issues warnings but still permits the module to load.\nThis can later cause:\nInvalid function calls Memory access violations Undefined behavior System crashes Unsafe Module Unloading # The default unload process removes module memory and registration information but does not verify whether other modules still reference the unloaded symbols.\nThis creates the risk of:\nDangling references Invalid pointers Runtime instability System-wide failures To address these shortcomings, a dedicated dynamic loading management framework was designed.\n🏗️ Dynamic Loading Management System Architecture # The proposed management system adopts a layered architecture consisting of:\nUser layer Management layer System layer This separation improves modularity, maintainability, and extensibility.\n🧠 System Layer Design # The system layer interfaces directly with the VxWorks kernel and internal runtime structures.\nModule Information Extraction # The framework uses MODULE_ID structures to access low-level module metadata managed internally by VxWorks.\nThis enables extraction of:\nModule names Memory locations Symbol information Runtime status Load parameters Dependency Relationship Analysis # Dependency relationships are identified during symbol relocation using the system symbol table:\nsysSymTbl Each symbol contains a group field indicating the originating module.\nUsing this information, the system constructs:\nDependency graphs Reverse-dependency graphs These structures enable accurate validation of loading and unloading operations.\n⚙️ Management Layer Design # The management layer serves as the core logic engine of the system.\nModule Information Table # The system maintains a module information table containing:\nModule name Load parameters Auto-load status Linked-list references Configuration metadata This table acts as the primary runtime management database.\nDependency Tables # Two dependency structures are maintained:\nDependency table Reverse-dependency table These structures combine:\nArrays Linked lists to efficiently validate module relationships.\nCore Management Functions # The management layer enforces several critical runtime rules.\nDuplicate Name Prevention # Modules with duplicate names are rejected rather than silently replacing existing modules.\nStrict Symbol Validation # Modules containing unresolved symbols are blocked from loading.\nThis prevents unstable runtime behavior caused by invalid references.\nSafe Unload Protection # The framework prevents unloading of modules currently referenced by dependent modules.\nThis eliminates dangling symbol references and improves runtime stability.\nPersistent Auto-Load Configuration # The management system stores:\nModule paths Load parameters Auto-load flags inside a persistent configuration file.\nThis enables automatic module restoration after reboot.\n💻 User Layer and Shell Interface # The user layer exposes management functionality through custom VxWorks shell commands.\nCustom Shell Commands # The system introduces several management commands.\nCommand Function Description mld Load module Loads module and updates management data munld Unload module Performs dependency-aware unloading mdshow Show dependencies Displays dependency relationships mshowall Show modules Lists loaded modules and auto-load state autoset Configure auto-load Enables or disables reboot auto-loading autoshow Display auto-load list Shows module loading sequence help Help information Displays command usage These commands provide operators with direct runtime control over module behavior.\n🔄 Automatic Module Loading After Reboot # One of the most important enhancements introduced by the framework is automatic module restoration after system restart.\nStartup Workflow # The reboot loading process follows several stages.\nConfiguration File Loading # During system startup, the framework reads the persistent auto-load configuration file.\nDependency-Aware Module Restoration # Modules are loaded according to dependency order to ensure all required symbols are available before dependent modules initialize.\nAuto-Load State Restoration # Successfully restored modules are marked as active auto-load entries.\nRuntime Initialization Completion # After restoration completes, the full management interface becomes available for normal operation.\n📂 First-Boot Behavior # If the system detects that no auto-load configuration file exists:\nA new configuration file is automatically created Initialization status is displayed through the shell interface The user is notified of the new configuration state This simplifies initial deployment and improves usability.\n🧪 Development and Validation Environment # The implementation was developed using:\nVxWorks 6.6 Testing and validation were performed using the:\nWorkbench simpc simulator Validation Objectives # The testing process verified:\nDynamic loading correctness Dependency analysis accuracy Safe unload protection Auto-load persistence Reboot recovery behavior Observed Results # The framework successfully demonstrated:\nStable runtime operation Accurate dependency enforcement Reliable reboot restoration Improved fault recovery capability compared with the native VxWorks loading mechanism.\n🛡️ Reliability and Fault Recovery Improvements # The enhanced framework significantly improves operational robustness in embedded systems.\nImproved Runtime Stability # Strict validation rules prevent:\nInvalid module replacement Unresolved symbol execution Unsafe module unloading These protections reduce runtime instability and unexpected crashes.\nFaster Recovery After Reboot # Automatic module restoration enables systems to quickly recover operational state after:\nUnexpected resets Fault recovery Software updates Watchdog-triggered reboots This capability is especially valuable in unattended or remote embedded deployments.\nBetter Maintainability # The layered architecture and shell-based management tools improve:\nDiagnostics Configuration management Runtime visibility System administration 🚀 Future Enhancement Opportunities # Several future extensions could further improve the framework.\nModule Version Management # Potential enhancements include:\nVersion tracking Rollback support Upgrade management Compatibility validation These features would simplify field upgrades and long-term maintenance.\nTask-Level Integration # Future work may integrate module management with:\nDynamic task scheduling Runtime service injection Adaptive workload distribution This would enable more advanced runtime reconfiguration capabilities.\nDistributed Embedded Systems Support # The framework could also evolve toward:\nNetwork-distributed module management Remote deployment Clustered embedded coordination for large-scale embedded platforms.\n🏁 Conclusion # This article presented a practical extension to the VxWorks dynamic loading mechanism through the design of a dedicated module management framework.\nBy introducing:\nDependency tracking Strict validation rules Persistent auto-load configuration Safe unloading protection Automatic reboot restoration the system significantly improves the reliability and maintainability of complex embedded applications.\nCompared with the native VxWorks loading implementation, the enhanced framework provides:\nSafer runtime behavior Better configurability Stronger fault recovery capability Improved operational flexibility These capabilities are particularly valuable in mission-critical environments such as aerospace, industrial control, and communication systems where uptime, stability, and rapid recovery are essential.\n","date":"2026-05-25","externalUrl":null,"permalink":"/training/extending-vxworks-with-automatic-module-loading-management/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eExtending VxWorks With Automatic Module Loading Management\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e⚙️ Abstract \n    \u003cdiv id=\"-abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eVxWorks is a widely deployed real-time operating system used in aerospace, industrial control, networking, and mission-critical embedded systems. Although the platform supports dynamic module loading, the native implementation is primarily intended for development and debugging scenarios rather than long-term operational deployment.\u003c/p\u003e","title":"Extending VxWorks With Automatic Module Loading Management","type":"training"},{"content":"","date":"2026-05-25","externalUrl":null,"permalink":"/tags/kernel-development/","section":"Tags","summary":"","title":"Kernel Development","type":"tags"},{"content":"","date":"2026-05-25","externalUrl":null,"permalink":"/tags/module-management/","section":"Tags","summary":"","title":"Module Management","type":"tags"},{"content":"","date":"2026-05-25","externalUrl":null,"permalink":"/tags/system-reliability/","section":"Tags","summary":"","title":"System Reliability","type":"tags"},{"content":" ARM and VxWorks-Based Microcomputer Excitation Regulator\n⚙️ Abstract # Traditional generator excitation regulators built on 16-bit processors and foreground/background software architectures face growing limitations in computational capability, scalability, reliability, and networking support. As excitation control algorithms become more advanced, legacy platforms struggle to satisfy modern real-time and functional requirements.\nThis article presents a new microcomputer excitation regulator architecture based on the 32-bit AT91RM9200 processor featuring the ARM920T core and the VxWorks real-time operating system. The design integrates a CPLD-based phase-shifted triggering subsystem to ensure highly reliable thyristor pulse generation and eliminate excitation-loss risks caused by software failures.\nThe platform also incorporates high-speed Ethernet communication for networked control and industrial integration. Combined with a modular VxWorks software architecture and comprehensive anti-interference strategies, the system significantly improves real-time responsiveness, reliability, maintainability, and extensibility compared with conventional excitation regulators.\n🔌 Limitations of Traditional Excitation Regulators # Since the 1980s, microcomputer-based excitation regulators have been widely deployed in power generation systems. Most conventional solutions are based on 16-bit processors such as Intel 80C196 or TI DSP2407 and rely on foreground/background software architectures.\nAlthough these systems achieved acceptable performance in earlier deployments, several architectural limitations have become increasingly apparent.\nInsufficient Computing Performance # Modern excitation control increasingly depends on advanced algorithms such as:\nFuzzy control Nonlinear optimal control Adaptive control Robust control strategies These computationally intensive algorithms exceed the practical performance limits of traditional 16-bit processors, particularly under strict real-time constraints.\nLimited Reliability and Expandability # Conventional trigger and sampling circuits often depend on CPU timers and external comparator logic, introducing several reliability concerns:\nVulnerability to software runaway Reduced fault tolerance Limited communication capability Difficult integration with distributed control systems (DCS) In addition, older architectures typically lack standardized high-speed networking interfaces.\nIncreasing Software Complexity # As functionality expands, traditional foreground/background software models become difficult to maintain and scale. Common issues include:\nPoor modularity Complex interrupt coordination Reduced portability Difficult debugging and maintenance To address these challenges, a new excitation regulator platform based on ARM9 and VxWorks was developed.\n🖥️ Hardware Architecture # The hardware platform consists of multiple functional modules:\nAC/DC signal processing Analog-to-digital conversion RM9200 + CPLD control subsystem Memory interface Synchronization voltage shaping Phase-shifted trigger generation Digital I/O Human-machine interface Ethernet communication Power management The architecture emphasizes deterministic real-time control, hardware reliability, and system scalability.\nAT91RM9200 ARM Processor # The controller core uses the AT91RM9200 industrial-grade ARM9 processor based on the ARM920T architecture.\nKey features include:\nUp to 200 MIPS processing performance 60 MHz peripheral bus Instruction and data cache DMA support 122 multiplexed I/O pins 32 interrupt sources 6 timers 5 serial communication interfaces Integrated 10/100 Mbps Ethernet MAC USB 2.0, SPI, and TWI support Compared with legacy 16-bit solutions, the ARM9 platform significantly improves:\nReal-time processing capability Peripheral integration System reliability Communication performance Future scalability The high integration level also simplifies peripheral circuit design and reduces hardware complexity.\n🔁 CPLD-Based Phase-Shifted Trigger Design # Traditional excitation trigger circuits often rely directly on CPU timers and comparators. Under abnormal software conditions such as program crashes or watchdog resets, trigger generation may fail, potentially causing generator excitation loss.\nTo eliminate this risk, the new design introduces an XC95144 CPLD-based trigger subsystem.\nCPLD Trigger Advantages # The CPLD interfaces with the RM9200 through a 16-bit data bus operating at up to 60 MHz. The processor calculates the firing angle and transfers it to the CPLD, which independently performs:\nFrequency measurement Phase-shift computation Six-pulse thyristor trigger generation The trigger subsystem supports:\nPhase-shift range from 0° to 180° Theoretical resolution of approximately 0.0027° Most importantly, pulse generation remains operational even if the main CPU software becomes unstable. This hardware-level independence dramatically improves excitation reliability and system safety.\nReliability Improvements # The CPLD-based approach offers several practical benefits:\nReduced CPU timing overhead Deterministic pulse generation Improved electromagnetic immunity Elimination of trigger jitter caused by software scheduling Prevention of excitation loss during processor faults This architecture is particularly valuable in high-power synchronous generator applications where excitation continuity is critical.\n📡 High-Speed Data Acquisition System # The excitation regulator supports 16 analog acquisition channels designed for synchronized high-speed sampling.\nADC Architecture # The acquisition subsystem uses:\nMAX291 active filters for front-end signal conditioning Four AD7865 14-bit ADCs Simultaneous sampling across all 16 channels Each AD7865 integrates four sample-and-hold circuits, eliminating the need for additional external multiplexers or sampling hardware.\nKey performance metrics include:\nTotal conversion time: approximately 10 μs Sampling rate: 1800 Hz 36 sampling points per power-frequency cycle Interrupt-Driven Sampling # The RM9200 timer subsystem generates synchronized PWM trigger signals and captures system frequency information.\nAfter conversion completes:\nADC completion signals are combined through the CPLD The CPLD asserts external interrupt IRQ0 The ARM processor services the acquisition interrupt This approach minimizes CPU overhead while maintaining deterministic sampling timing and high acquisition precision.\n🌐 Ethernet Communication Architecture # Modern excitation systems increasingly require networked monitoring and remote integration with plant automation infrastructure.\nTo satisfy these requirements, the design uses the RM9200 integrated Ethernet MAC controller with:\nDMA support FIFO buffering 10/100 Mbps Ethernet capability Compared with traditional fieldbus communication methods, Ethernet provides:\nHigher bandwidth Standardized networking Easier integration with DCS platforms Improved scalability Lower communication latency The architecture enables reliable real-time communication between the excitation regulator, supervisory control systems, and industrial monitoring platforms.\n🧠 VxWorks-Based Software Architecture # Why VxWorks? # As embedded excitation control systems grow more complex, traditional foreground/background software models become increasingly difficult to maintain.\nVxWorks was selected due to several advantages:\nDeterministic real-time scheduling High system reliability Compact kernel footprint Rich synchronization primitives Mature networking stack Excellent modularity and portability The operating system supports:\n256-level priority-based preemptive scheduling Sub-millisecond response latency Minimal kernel footprint of approximately 8 KB These characteristics make VxWorks highly suitable for industrial real-time control systems.\n🧵 Interrupt and Task Partitioning # The software architecture divides functionality into dedicated interrupts and tasks following real-time scheduling principles.\nInterrupt Subsystem # The design includes four high-priority interrupt sources:\nA/D conversion interrupt Sampling frequency capture interrupt Host computer communication interrupt DCS communication interrupt Interrupt service routines (ISRs) remain intentionally lightweight and primarily perform:\nFast data acquisition Event acknowledgement Semaphore posting The intConnect() interface is used to register interrupt handlers.\nTask Scheduling Structure # The system defines seven major tasks ordered by execution priority:\nControl law computation Limit checking Fault detection Host data upload DCS data upload Human-machine interaction Fault recording The highest-priority control task executes PID and Power System Stabilizer (PSS) algorithms.\nDuring critical calculations, the scheduler is temporarily locked using taskLock() to prevent unwanted task switching and ensure deterministic execution timing.\nInter-Task Communication # The system uses multiple VxWorks synchronization mechanisms:\nSemaphores Mutexes Message queues Shared memory Mutex protection is specifically applied to prevent priority inversion problems in shared resources.\nThis modular task-based architecture significantly improves:\nSoftware maintainability Scalability Debugging efficiency Fault isolation 🛡️ Anti-Interference Design # Generator excitation regulators operate in environments with strong electromagnetic interference. Both hardware and software protection mechanisms are therefore essential.\nHardware Protection Measures # The hardware design incorporates:\nOptical isolation for communication interfaces Transformer isolation Isolated DC/DC power supplies Buffer drivers for pulse outputs Separate analog and digital grounding Multi-layer PCB routing Enhanced capacitor filtering Single-point grounding is implemented at the A/D subsystem to reduce ground-loop interference.\nSoftware Reliability Measures # Software-level protection includes:\nDigital filtering of sampled signals Watchdog monitoring through VxWorks Fault recovery mechanisms Robust task synchronization These combined measures substantially improve long-term operational stability in industrial power environments.\n📈 System Benefits and Engineering Value # Compared with traditional 16-bit excitation regulators, the ARM9 and VxWorks-based architecture delivers major improvements across multiple dimensions.\nCore Advantages # The new platform provides:\nHigher computational performance Improved real-time responsiveness Better electromagnetic robustness Reliable trigger generation High-speed Ethernet networking Simplified software maintenance Stronger system scalability The CPLD trigger subsystem is especially important because it guarantees excitation continuity even during CPU instability.\nPractical Deployment Potential # Prototype testing demonstrates that the regulator is suitable for medium and large synchronous generator applications requiring:\nHigh reliability Networked supervision Advanced control algorithms Industrial-grade real-time performance The architecture also establishes a strong foundation for future integration of:\nNonlinear robust control Intelligent excitation algorithms Fuzzy control Adaptive regulation techniques 🏁 Conclusion # The ARM and VxWorks-based microcomputer excitation regulator represents a significant advancement over traditional 16-bit excitation control systems.\nBy combining:\nThe AT91RM9200 ARM9 processor VxWorks real-time operating system CPLD-based trigger logic High-speed Ethernet communication the design achieves substantial gains in reliability, deterministic control, software maintainability, and industrial scalability.\nThe modular hardware/software architecture not only improves present-day excitation performance but also provides a future-ready platform for next-generation intelligent generator control systems.\n","date":"2026-05-24","externalUrl":null,"permalink":"/app/arm-and-vxworks-based-microcomputer-excitation-regulator/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eARM and VxWorks-Based Microcomputer Excitation Regulator\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e⚙️ Abstract \n    \u003cdiv id=\"-abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eTraditional generator excitation regulators built on 16-bit processors and foreground/background software architectures face growing limitations in computational capability, scalability, reliability, and networking support. As excitation control algorithms become more advanced, legacy platforms struggle to satisfy modern real-time and functional requirements.\u003c/p\u003e","title":"ARM and VxWorks-Based Microcomputer Excitation Regulator","type":"app"},{"content":"","date":"2026-05-24","externalUrl":null,"permalink":"/tags/cpld/","section":"Tags","summary":"","title":"CPLD","type":"tags"},{"content":"","date":"2026-05-24","externalUrl":null,"permalink":"/tags/generator-control/","section":"Tags","summary":"","title":"Generator Control","type":"tags"},{"content":"","date":"2026-05-24","externalUrl":null,"permalink":"/tags/power-systems/","section":"Tags","summary":"","title":"Power Systems","type":"tags"},{"content":"","date":"2026-05-24","externalUrl":null,"permalink":"/tags/build-systems/","section":"Tags","summary":"","title":"Build Systems","type":"tags"},{"content":"","date":"2026-05-24","externalUrl":null,"permalink":"/tags/gnu-make/","section":"Tags","summary":"","title":"GNU Make","type":"tags"},{"content":" Integrating Legacy Builds with VxWorks 7 Subprojects\nModern embedded systems often combine vendor-provided RTOS infrastructure with large existing middleware, driver, and application codebases developed independently over many years. In practice, many of these software stacks rely on custom GNU Make environments, proprietary build systems, or platform-agnostic compilation frameworks that predate modern VxWorks tooling.\nIntegrating these existing build environments into the VxWorks 7 ecosystem can be challenging, particularly when preserving portability across multiple target boards and CPU architectures.\nOne effective approach is the use of VxWorks 7 subprojects, a lesser-known but powerful feature within the VxWorks layer and package management system. Subprojects allow teams to integrate large external software trees into VxWorks builds without fully restructuring the original source organization.\nThis article explores how VxWorks 7 layers, packages, VSB/VIP projects, and subprojects work together to support scalable embedded software integration.\n⚙️ Understanding the VxWorks 7 Build Architecture # VxWorks 7 uses a modular operating system architecture composed of discrete components, libraries, and packages.\nThe build process revolves around two major project types:\nVxWorks Source Build (VSB) VxWorks Image Project (VIP) VxWorks Source Build (VSB) # The VSB project compiles operating system components and libraries into reusable binary artifacts.\nResponsibilities include:\nBuilding kernel libraries Compiling middleware Managing package dependencies Generating reusable OS components The VSB acts as the foundational operating system build layer.\nVxWorks Image Project (VIP) # The VIP consumes the VSB outputs and generates the final bootable kernel image for a specific hardware target.\nResponsibilities include:\nBoard-specific configuration Kernel image generation Component selection BSP integration Final image linking This separation allows developers to reuse a single VSB across multiple target configurations.\n🧩 VxWorks Application Project Types # Wind River Workbench also supports application development projects layered on top of the operating system.\nThe two primary application models are:\nDownloadable Kernel Modules (DKMs) # DKMs execute inside kernel address space.\nCharacteristics include:\nShared kernel memory access High performance Minimal isolation Direct kernel integration DKMs are commonly used for:\nDevice drivers Performance-critical services Low-level middleware Real-Time Processes (RTPs) # RTPs execute in isolated user-space environments.\nCharacteristics include:\nProcess isolation Memory protection Independent address spaces Improved fault containment RTPs are typically preferred for:\nUser applications Network services Higher-level middleware Safer modular deployments These project types work well for software designed specifically around the Workbench ecosystem. However, legacy or cross-platform software often requires a different integration strategy.\n📦 VxWorks 7 Package and Layer Management # One of the major architectural improvements introduced in VxWorks 7 was the RPM-based package management system.\nThe system borrows concepts from enterprise Linux distributions while adapting them for embedded real-time systems.\nKey capabilities include:\nStrict package versioning Dependency management Modular OS composition Layer-based architecture Simplified updates and maintenance Each software module is distributed as an RPM package containing:\nSource code Metadata Dependency definitions Layer configuration Each package defines a VxWorks layer that becomes part of the VSB build process.\nThis modular architecture significantly reduces dependency management complexity compared to older monolithic RTOS workflows.\n🔧 The Challenge of Legacy Build Systems # Many embedded software teams maintain substantial codebases built around custom Make systems or proprietary build frameworks.\nThese environments often include:\nPortable middleware Shared cross-platform libraries Existing CI/CD pipelines Vendor-independent build rules Multi-target compilation logic Migrating these codebases directly into standard Workbench project structures is frequently impractical.\nTraditional integration approaches include:\nConverting Software into Native VxWorks Layers # This approach builds the software directly into VSB-managed libraries.\nAdvantages:\nFull integration Standardized dependency handling Native Workbench compatibility Disadvantages:\nRequires significant restructuring Large migration effort Complex refactoring Using DKM Projects # This produces partially linked kernel modules integrated during VIP builds.\nAdvantages:\nKernel-level execution Flexible deployment Disadvantages:\nRequires adaptation to Workbench project structures Limited portability from existing build systems Using RTP Projects # This produces standalone ELF binaries loaded during runtime.\nAdvantages:\nProcess isolation Cleaner modularity Disadvantages:\nStill requires Workbench-oriented project organization For large legacy environments, all three approaches may involve excessive disruption.\n🏗️ VxWorks 7 Subprojects # VxWorks 7 subprojects provide an alternative integration strategy designed specifically for external software trees.\nA subproject allows existing software to remain largely unchanged while still integrating into the VxWorks build pipeline.\nSubprojects provide several important characteristics:\nDefined as VxWorks layers Integrated into VIP builds Compatible with existing Makefiles Support dependency metadata Enable board-specific configuration integration This makes subprojects particularly useful for:\nThird-party middleware Legacy drivers Shared cross-platform libraries Existing GNU Make build systems 🚀 How Subprojects Work # The subproject mechanism effectively bridges the gap between external build systems and VxWorks layer management.\nThe workflow typically looks like this:\nDefine a VxWorks layer Register package metadata Define component dependencies Import the external software tree Invoke the original Makefiles during VIP builds Unlike standard Workbench projects, the source tree itself does not need to be reorganized into VxWorks-native structures.\nThis provides several operational advantages.\nExisting Software Organization Remains Intact # Teams can preserve:\nDirectory layouts Build scripts Internal tooling Existing automation without major restructuring.\nNative Makefiles Continue to Build the Software # The original build logic remains authoritative.\nThis is especially important for mature embedded codebases that already support:\nMultiple architectures Multiple RTOS platforms Cross-compilation toolchains Vendor-specific optimizations Board-Specific Assets Can Be Included # Subprojects are copied into the VIP project space, allowing direct integration of:\nBoard configuration files BSP-specific settings Device initialization assets Platform-dependent resources 🛠️ Additional Work Still Required # Although subprojects simplify integration, they do not eliminate the work required to adapt software for VxWorks 7.\nDevelopers must still:\nCreate VxWorks layer definitions Ensure compatibility with the VxWorks compiler toolchain Define Component Definition Files (CDFs) Implement VxWorks configlettes Handle initialization sequencing Component Definition Files (CDFs) # CDFs define:\nAvailable software modules Dependencies Kernel integration options Initialization order These definitions allow components to be selected inside the VIP configuration process.\nConfiglettes # Configlettes are initialization routines executed during system startup.\nThey are responsible for:\nDriver initialization Middleware startup Service registration Runtime configuration Even when preserving external Make systems, VxWorks runtime integration still requires these platform-native mechanisms.\n🧪 Debugging Challenges # One downside of the subproject mechanism is build complexity.\nThe VxWorks build system contains:\nMultiple generated make layers Package dependency resolution Dynamic build rules Layer integration logic As a result, debugging subproject integration issues can become difficult.\nCommon challenges include:\nBuild ordering issues Missing layer dependencies Symbol visibility problems CDF configuration errors Toolchain incompatibilities The internal build rules controlling subprojects are also sparsely documented compared to standard Workbench workflows.\nFor large integrations, understanding the underlying VSB/VIP build mechanics becomes essential.\n📈 When to Use VxWorks Subprojects # Subprojects are particularly valuable when:\nLarge legacy codebases already exist Existing Make-based workflows must be preserved Multi-platform portability is important Extensive source reorganization is undesirable Teams rely on external build automation However, for greenfield development or smaller projects, the standard VxWorks development model often remains the cleaner long-term solution.\nNative Workbench integration generally provides:\nSimpler debugging Better tooling support Cleaner dependency handling Easier maintenance Subprojects are best viewed as an integration strategy rather than a replacement for standard VxWorks application models.\n🧠 Modern Embedded Software Integration # Modern embedded platforms increasingly combine:\nRTOS infrastructure Vendor middleware Open-source frameworks AI and edge workloads Multi-platform software stacks As these systems grow in complexity, preserving existing build environments while integrating into modern RTOS ecosystems becomes increasingly important.\nVxWorks 7 subprojects provide a practical mechanism for bridging legacy embedded software architectures with contemporary layer-based RTOS development workflows.\nFor organizations maintaining large cross-platform embedded codebases, this flexibility can significantly reduce migration cost while preserving long-established engineering processes.\n📚 References # VxWorks 7 Layers and Package Management Guide Wind River Workbench Documentation VxWorks Source Build (VSB) Documentation VxWorks Image Project (VIP) Documentation Wind River Component Definition File (CDF) Reference ","date":"2026-05-24","externalUrl":null,"permalink":"/training/integrating-legacy-builds-with-vxworks-7-subprojects/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eIntegrating Legacy Builds with VxWorks 7 Subprojects\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eModern embedded systems often combine vendor-provided RTOS infrastructure with large existing middleware, driver, and application codebases developed independently over many years. In practice, many of these software stacks rely on custom GNU Make environments, proprietary build systems, or platform-agnostic compilation frameworks that predate modern VxWorks tooling.\u003c/p\u003e","title":"Integrating Legacy Builds with VxWorks 7 Subprojects","type":"training"},{"content":"","date":"2026-05-24","externalUrl":null,"permalink":"/tags/software-integration/","section":"Tags","summary":"","title":"Software Integration","type":"tags"},{"content":"","date":"2026-05-24","externalUrl":null,"permalink":"/tags/vip/","section":"Tags","summary":"","title":"VIP","type":"tags"},{"content":"","date":"2026-05-24","externalUrl":null,"permalink":"/tags/vsb/","section":"Tags","summary":"","title":"VSB","type":"tags"},{"content":"","date":"2026-05-24","externalUrl":null,"permalink":"/tags/workbench/","section":"Tags","summary":"","title":"Workbench","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/autonomous-systems/","section":"Tags","summary":"","title":"Autonomous Systems","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/ros2/","section":"Tags","summary":"","title":"ROS2","type":"tags"},{"content":" Running ROS 2 on VxWorks 7 for Deterministic Robotics\nThe robotics industry is rapidly shifting from experimental platforms toward deterministic, safety-certified autonomous systems. As robots move into aerospace, industrial automation, defense, medical systems, and intelligent edge computing, traditional Linux-based robotics stacks increasingly face limitations around latency predictability, certification, and real-time guarantees.\nTo address these constraints, Wind River introduced official ROS 2 support for VxWorks 7 through the vxworks7-ros2-build project. The integration enables developers to run modern ROS 2 applications directly on the VxWorks real-time operating system while preserving deterministic scheduling, bounded latency, and safety-oriented runtime isolation.\nThis combination merges the modular robotics ecosystem of ROS 2 with the execution guarantees of a hard real-time operating system.\n⚙️ VxWorks 7 as a Deterministic Robotics Platform # Unlike general-purpose Linux distributions, VxWorks 7 is engineered specifically for deterministic embedded execution. The platform provides predictable runtime behavior required by safety-critical robotic workloads.\nCore capabilities include:\nDeterministic preemptive scheduling Bounded interrupt latency SMP and multi-core scalability Memory protection and process isolation Functional safety certification support Secure boot and hardened runtime security VxWorks certification support targets standards including:\nDO-178C ISO 26262 IEC 61508 These characteristics are particularly important for:\nIndustrial automation systems Autonomous vehicles Aerospace and defense platforms Surgical and medical robotics Real-time edge AI devices ROS 2 complements this architecture by providing:\nDDS-based distributed communication Publish/subscribe messaging Hardware abstraction layers Robotics tooling and visualization Modular package ecosystems Together, ROS 2 and VxWorks create a deterministic robotics stack suitable for latency-sensitive autonomous systems.\n🏗️ ROS 2 Build Architecture on VxWorks # Wind River’s vxworks7-ros2-build project automates cross-compilation of ROS 2 and its dependencies against the VxWorks SDK.\nSupported ROS 2 distributions include:\nHumble Hawksbill Jazzy Jalisco Rolling Ridley Currently supported targets include:\nQEMU x86_64 Raspberry Pi 4 The build system relies on:\nDocker-based reproducible environments colcon build tooling Clang-based VxWorks cross-compilation Custom compatibility patches for ROS 2 packages The repository structure includes middleware, dependencies, and robotics packages:\npkg/ ├── ros2 ├── turtlebot3 ├── asio ├── tinyxml2 ├── python ├── eigen └── unixextra Generated runtime artifacts are exported into deployable filesystem trees:\noutput/export/ ├── deploy/ └── root/ The deployable runtime contains:\nROS 2 binaries Shared libraries Python runtime components CLI tooling Example ROS 2 applications This architecture simplifies deployment to both virtualized and physical VxWorks targets.\n🔧 Cross-Compilation Workflow # The recommended workflow uses Docker containers to ensure reproducible builds across development environments.\nBuild Environment Initialization # First, developers build a Docker image for the desired ROS 2 distribution:\ndocker build --no-cache -t vxros2build:jazzy Docker/24.04/vxros2build/. The VxWorks SDK is then mounted into the container environment:\ndocker run -ti \\ -v ~/Downloads/wrsdk:/wrsdk \\ -v $PWD:/work \\ vxros2build:jazzy Inside the container:\nsource /wrsdk/sdkenv.sh make The build pipeline automatically:\nDownloads ROS 2 dependencies Applies VxWorks compatibility patches Cross-compiles middleware Builds ROS 2 packages Exports deployable runtime images The environment uses Wind River’s Clang-based toolchain:\nwr-cc wr-c++ CMake integration is handled through a dedicated toolchain file:\n-DCMAKE_TOOLCHAIN_FILE=/work/buildspecs/cmake/toolchain.cmake This allows many Linux-oriented CMake projects to compile under VxWorks with minimal modification.\n🖥️ Running ROS 2 on QEMU-Based VxWorks # One of the most practical advantages of the platform is the ability to prototype full robotics systems using QEMU before deploying to physical hardware.\nA bootable image containing ROS 2 runtime artifacts is generated with:\nmake image QEMU can then boot the VxWorks kernel directly:\nqemu-system-x86_64 \\ -machine q35 \\ -cpu Nehalem \\ -kernel vxWorks Networking is typically configured using TAP interfaces, enabling DDS communication between VxWorks-based ROS 2 nodes and Linux hosts.\nInside the VxWorks shell:\n-\u0026gt; ls \u0026#34;/usr\u0026#34; developers can verify the deployed ROS 2 runtime filesystem.\nThis approach significantly accelerates development, validation, and middleware testing before hardware integration.\n🚀 Executing ROS 2 Applications on VxWorks # ROS 2 C++ applications run directly as VxWorks RTPs (Real-Time Processes).\nExample:\n/usr/lib/examples_rclcpp_minimal_timer/timer_lambda Expected output:\n[INFO] [minimal_timer]: Hello, world! Python-based ROS 2 nodes are also supported:\npython3 ros2 run demo_nodes_py talker This demonstrates that VxWorks can successfully host:\nDDS middleware Python interpreters ROS 2 CLI tooling Distributed robotics applications while maintaining deterministic RTOS scheduling behavior.\n🔐 ROS 2 Security and SROS2 Integration # Security is increasingly critical for connected autonomous systems.\nThe platform supports:\nSROS2 DDS Security Certificate-based authentication Encrypted node communication Example runtime configuration:\nset env \u0026#34;ROS_SECURITY_ENABLE=true\u0026#34; Applications can launch with enclave isolation:\npython3 ros2 run demo_nodes_cpp talker \\ --ros-args --enclave /talker_listener/talker These capabilities align with VxWorks 7 security features including:\nSecure boot Process isolation Memory separation Hardened networking stacks For defense, aerospace, and industrial robotics, combining deterministic execution with secure middleware communication is increasingly mandatory.\n📈 Why VxWorks Matters for Real-Time Robotics # Most ROS 2 deployments on Linux depend on PREEMPT_RT kernels to approximate soft real-time behavior. While effective for many robotics workloads, Linux-based systems still experience:\nScheduler jitter Shared kernel contention Non-deterministic interrupt handling Latency variation under load VxWorks addresses these issues through:\nDeterministic scheduling Fixed interrupt response times Strict priority enforcement Partitioned runtime environments These guarantees are essential for:\nFlight-control robotics Autonomous drones Industrial motion control Surgical robotics Defense-grade autonomous systems In these environments, bounded latency is not optional.\n🤖 Edge AI and Embedded Robotics Convergence # The integration of ROS 2 with VxWorks reflects a broader architectural shift in robotics and edge computing.\nModern autonomous systems increasingly combine:\nReal-time control loops AI inference pipelines Sensor fusion Distributed middleware Functional safety Cybersecurity Within this architecture:\nVxWorks provides deterministic execution infrastructure ROS 2 supplies modular robotics middleware DDS enables distributed coordination AI accelerators handle inference workloads This model is increasingly relevant for:\nAutonomous mobile robots (AMRs) Industrial cobots Space robotics Autonomous defense systems Intelligent edge platforms As edge AI systems continue to evolve, the separation between embedded RTOS infrastructure and robotics middleware is becoming increasingly narrow.\n🧠 The 2026 Robotics Architecture Model # By 2026, heterogeneous robotics architectures have become the dominant deployment model across industrial and autonomous systems.\nA common pattern now includes:\nLinux for orchestration and high-level services RTOS platforms for deterministic control paths AI accelerators for machine learning inference DDS middleware for distributed communication Within this stack, VxWorks 7 operates as the deterministic execution layer beneath modern robotics middleware rather than as a direct Linux replacement.\nThis approach is especially valuable in environments requiring:\nFunctional safety certification Predictable timing behavior Long lifecycle maintenance Security hardening High operational reliability The significance of ROS 2 support on VxWorks extends beyond middleware compatibility. It demonstrates that modern robotics frameworks can now operate directly atop a certified hard real-time operating system without abandoning the broader ROS ecosystem.\n📚 References # Wind River VxWorks ROS 2 Build Repository Wind River Labs SDK Downloads ROS 2 Documentation Wind River Official Website ","date":"2026-05-23","externalUrl":null,"permalink":"/app/running-ros-2-on-vxworks-7-for-deterministic-robotics/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eRunning ROS 2 on VxWorks 7 for Deterministic Robotics\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eThe robotics industry is rapidly shifting from experimental platforms toward deterministic, safety-certified autonomous systems. As robots move into aerospace, industrial automation, defense, medical systems, and intelligent edge computing, traditional Linux-based robotics stacks increasingly face limitations around latency predictability, certification, and real-time guarantees.\u003c/p\u003e","title":"Running ROS 2 on VxWorks 7 for Deterministic Robotics","type":"app"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/multicore/","section":"Tags","summary":"","title":"Multicore","type":"tags"},{"content":" VxWorks 7: Modular RTOS Architecture for the Modern IoT Era\nThe Internet of Things fundamentally changed the requirements for embedded software platforms. Traditional embedded systems were often isolated, purpose-built, and deployed with relatively static functionality. Modern connected systems operate under a completely different set of constraints.\nToday’s embedded platforms must simultaneously provide:\nDeterministic real-time performance High connectivity Strong security guarantees Long-term maintainability Multi-core scalability Certification readiness Flexible deployment architectures VxWorks 7 was designed specifically for this new generation of connected embedded systems.\nAs the latest major evolution of Wind River’s long-running real-time operating system family, VxWorks 7 introduces a significantly more modular and scalable architecture while preserving the deterministic behavior and reliability that made earlier versions dominant in aerospace, defense, industrial automation, and telecommunications.\nThe result is a modern RTOS platform capable of scaling from lightweight edge devices to highly complex safety-critical systems.\n🌐 Why IoT Changed Embedded Operating System Design # Earlier generations of embedded devices were typically:\nSingle-purpose Offline or isolated Hardware-constrained Infrequently updated The IoT era introduced fundamentally different requirements.\nModern devices are expected to support:\nContinuous network connectivity Remote management OTA updates Secure communications Cloud integration Edge intelligence Long operational lifecycles At the same time, many industries still require strict real-time guarantees and certification compliance.\nThis combination creates a difficult engineering challenge:\nDeliver cloud-era flexibility without sacrificing deterministic real-time behavior.\nVxWorks 7 addresses this challenge through architectural modularity and improved isolation mechanisms.\n🧩 Modular Architecture and Scalability # One of the defining characteristics of VxWorks 7 is its highly modular system architecture.\nUnlike older monolithic RTOS designs, VxWorks 7 cleanly separates:\nCore kernel functionality Middleware packages Protocol stacks Drivers Security modules User applications This design enables developers to tailor system footprints precisely to application requirements.\nBenefits of a Modular RTOS # The modular approach provides several important engineering advantages:\nAdvantage Impact Reduced Footprint Smaller runtime memory usage Faster Integration Easier feature composition Lower Certification Scope Smaller recertification boundaries Simplified Maintenance Independent package updates Better Scalability Support for both low-end and high-end systems This flexibility is particularly valuable for organizations maintaining broad product portfolios across multiple hardware tiers.\n⚙️ Microkernel Flexibility and Unified Development # VxWorks 7 supports both:\nTraditional high-performance RTOS deployments Small-profile microkernel configurations Importantly, both operate within the same broader platform ecosystem.\nThis allows teams to standardize on a single operating system environment across:\nConstrained edge devices Intelligent gateways Industrial controllers High-performance embedded systems Why This Matters # Historically, companies often maintained multiple operating systems for different product classes, creating problems involving:\nFragmented tooling Duplicate development effort Inconsistent APIs Separate certification paths A unified platform significantly reduces long-term engineering complexity.\n🔐 Security as a Core Architectural Requirement # Security has become one of the defining challenges of modern embedded systems.\nConnected devices dramatically increase attack surfaces through:\nNetwork exposure Remote management interfaces Wireless protocols OTA update mechanisms Third-party integrations VxWorks 7 addresses this through a layered security architecture spanning the full device lifecycle.\nSecurity Areas Covered # The platform includes mechanisms supporting:\nSecure boot Runtime protection Memory isolation Access control Secure communications Lifecycle management Trusted execution environments This is especially important in industries where compromise can affect:\nHuman safety Critical infrastructure Defense systems Industrial operations 🧠 Memory Protection and Process Isolation # A major advancement in VxWorks 7 is expanded support for MMU-based memory protection and user-mode execution.\nEarlier RTOS deployments often operated entirely in kernel space for performance simplicity. While efficient, this approach increased system-wide failure risk because a fault in one application could potentially compromise the entire system.\nVxWorks 7 introduces stronger process isolation models.\nKey Reliability Improvements # The platform now supports:\nUser-space applications Process-based execution Protected memory domains Fault containment Controlled privilege separation This improves:\nSystem robustness Fault isolation Security hardening Certification support Particularly in complex IoT systems running multiple software components simultaneously, process isolation becomes critical for maintaining long-term reliability.\n⏱️ Deterministic Real-Time Scheduling # Despite its modern architectural improvements, VxWorks 7 remains fundamentally a hard real-time operating system.\nDeterministic execution continues to be one of its defining characteristics.\nCore Real-Time Features # VxWorks 7 maintains support for:\nPriority-based preemptive scheduling Fast interrupt handling Low context-switch latency Time partitioning Deterministic task execution Time partitioning is especially important in mixed-criticality systems where lower-priority workloads must never interfere with safety-critical operations.\nThis capability is essential in environments such as:\nAvionics Automotive systems Medical devices Industrial automation Defense platforms 🖥️ Multi-Core Support and System Consolidation # Modern embedded processors increasingly rely on multi-core architectures to balance performance and power efficiency.\nVxWorks 7 includes advanced support for:\nSymmetric multiprocessing (SMP) Asymmetric multiprocessing (AMP) Multi-core scheduling Core affinity management Why Multi-Core Matters in Embedded Systems # Multi-core support enables system consolidation, allowing multiple workloads to operate on fewer physical hardware platforms.\nBenefits include:\nReduced SWaP requirements Lower hardware complexity Improved power efficiency Better thermal characteristics Simplified deployment architectures This is particularly important in aerospace, automotive, and industrial systems where physical space and power budgets remain constrained.\n🌍 Broad Connectivity for Industrial IoT # Connectivity is central to modern embedded infrastructure.\nVxWorks 7 includes extensive support for networking and peripheral communication standards commonly used in industrial and IoT environments.\nSupported Connectivity Technologies # Examples include:\nTCP/IP networking USB CAN bus Bluetooth Industrial communication protocols Legacy integration interfaces This enables organizations to modernize older embedded systems while maintaining compatibility with existing operational environments.\nThe modular networking architecture also allows selective inclusion of protocol stacks to optimize system footprint and certification boundaries.\n🏭 Certification and Safety-Critical Deployment # One of VxWorks’ strongest competitive advantages remains its history in certified environments.\nVxWorks 7 continues supporting industries requiring compliance with rigorous standards such as:\nDO-178C (Aerospace) ISO 26262 (Automotive) IEC 61508 (Industrial Safety) Medical device certification frameworks Why Certification Support Matters # In safety-critical industries, operating system selection is not based solely on technical capability.\nCertification readiness affects:\nDevelopment timelines Regulatory approval System architecture decisions Long-term maintenance costs A mature RTOS with established certification artifacts significantly reduces project risk.\n🔄 Backward Compatibility and Investment Protection # Embedded systems often remain deployed for decades.\nAs a result, backward compatibility is critically important.\nVxWorks 7 was designed to preserve customer investment by maintaining strong compatibility with previous VxWorks generations.\nCompatibility Advantages # The platform supports:\nLegacy APIs Existing BSPs Prior drivers Older application codebases Many systems developed for:\nVxWorks 5.5 VxWorks 6.x Earlier Wind River ecosystems can migrate with relatively limited modification effort.\nThis reduces:\nRewrite costs Validation overhead Certification disruption Operational risk 🛠️ Development Environment and Tooling # VxWorks 7 integrates with Wind River Workbench, an Eclipse-based embedded development environment.\nWorkbench provides:\nC/C++ development tooling System visualization Performance tracing Remote debugging Multi-core analysis Target communication frameworks Advanced debugging and tracing tools are especially valuable in real-time environments where timing behavior and concurrency issues can be difficult to reproduce.\n📊 Supported Architectures and Hardware Scalability # VxWorks 7 supports a broad range of processor architectures commonly used in embedded systems.\nSupported Architectures Include # ARM x86 / Intel 64-bit PowerPC QorIQ platforms This flexibility enables deployment across:\nLightweight IoT devices Industrial controllers Telecom systems Aerospace hardware Defense platforms Intelligent edge infrastructure 🚀 Why VxWorks 7 Remains Relevant # Despite growing competition from embedded Linux and open-source RTOS platforms, VxWorks remains highly relevant in environments requiring:\nHard real-time guarantees Safety certification Deterministic scheduling Long-term reliability Strong vendor support The shift toward connected edge computing actually increases the importance of these capabilities.\nAs embedded systems become more intelligent and interconnected, balancing:\nConnectivity Security Isolation Real-time performance becomes increasingly difficult.\nVxWorks 7 was architected specifically around that convergence.\n📌 Conclusion # VxWorks 7 represents a substantial evolution of the traditional real-time operating system model for the modern IoT and edge computing era.\nIts combination of:\nModular architecture Deterministic scheduling Multi-core scalability Advanced security Process isolation Certification readiness positions it as a strong platform for modern embedded development.\nThe platform’s flexibility allows organizations to deploy a unified RTOS strategy across a wide range of device classes while preserving long-term maintainability and backward compatibility.\nFor industries where reliability, predictability, and safety remain non-negotiable, VxWorks 7 continues to provide one of the most mature and capable commercial RTOS environments available.\n","date":"2026-05-23","externalUrl":null,"permalink":"/training/vxworks-7-modular-rtos-architecture-for-the-modern-iot-era/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 7: Modular RTOS Architecture for the Modern IoT Era\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eThe Internet of Things fundamentally changed the requirements for embedded software platforms. Traditional embedded systems were often isolated, purpose-built, and deployed with relatively static functionality. Modern connected systems operate under a completely different set of constraints.\u003c/p\u003e","title":"VxWorks 7: Modular RTOS Architecture for the Modern IoT Era","type":"training"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/dosfs/","section":"Tags","summary":"","title":"DosFs","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/file-system/","section":"Tags","summary":"","title":"File System","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/hrfs/","section":"Tags","summary":"","title":"HRFS","type":"tags"},{"content":" VxWorks File Systems: Architecture, Features, and Best Practices\n📖 Introduction # Reliable and efficient storage management is a core requirement for modern embedded and real-time systems. Whether handling persistent configuration data, event logging, firmware updates, or mission-critical telemetry, the underlying file system architecture directly impacts system stability, determinism, and long-term maintainability.\nAs a leading real-time operating system developed by Wind River, VxWorks provides a modular, high-performance I/O subsystem capable of supporting multiple local and network file systems simultaneously. Its architecture is designed around abstraction, portability, and real-time responsiveness, enabling developers to integrate storage technologies ranging from RAM disks and flash devices to distributed network file systems.\nThis article explores the architecture of the VxWorks file system framework, major supported file systems, configuration methods, implementation mechanisms, and best practices for embedded applications.\n🏗️ Overview of the VxWorks I/O System # The VxWorks I/O system is device-independent and built around a layered architecture that cleanly separates applications from hardware-specific implementations.\nAt a high level, the I/O subsystem consists of three primary elements:\nComponent Description Drivers Hardware-specific or file-system-specific implementations Devices Named I/O entities such as /ata0, /ram0, or /ttyS0 Files Accessed using POSIX-like file descriptors Applications interact with storage through familiar APIs such as:\nopen() read() write() close() ioctl() This POSIX-like abstraction allows application software to remain portable regardless of the underlying storage technology.\nDevice Categories # VxWorks divides devices into two primary classes:\nDevice Type Characteristics Block Devices Random-access storage using fixed-size blocks Character Devices Stream-oriented devices such as serial ports File systems operate primarily on top of block devices.\n🧩 File System Framework Architecture # The VxWorks file system framework acts as an intermediary between block device drivers and application-level APIs.\nTypical architecture:\n+--------------------------------+ | Application Layer | | open/read/write/close APIs | +--------------------------------+ | File System Layer | | dosFs / HRFS / rawFs / ROMFS | +--------------------------------+ | Block Device Layer | | ATA / SATA / Flash / RAM Disk | +--------------------------------+ | Device Drivers | +--------------------------------+ | Hardware | +--------------------------------+ This modular architecture provides several important advantages:\nMultiple file systems can coexist simultaneously Storage hardware can be swapped without modifying applications Different file systems can target different reliability or performance goals Network and local storage use a unified programming model 💾 Major File Systems in VxWorks # 📁 1. dosFs — FAT-Compatible File System # dosFs is the most widely used file system in VxWorks environments. It provides compatibility with Microsoft FAT file systems, including FAT12, FAT16, and FAT32.\nBecause of its interoperability with desktop operating systems, dosFs is commonly used for removable storage and data exchange.\nKey Features # Hierarchical directories FAT12/FAT16/FAT32 support Long filename support Unicode filename support in modern releases Removable media support Write-through caching options Fast consistency checking using clean-bit optimization Typical Use Cases # USB storage devices CompactFlash cards SD cards General-purpose embedded storage Interoperability with Windows/Linux systems Example: Creating a dosFs Volume # #include \u0026lt;dosFsLib.h\u0026gt; BLK_DEV *pBlkDev = ...; DOS_VOL_DESC *pVolDesc = dosFsMkfs(\u0026#34;/ata0\u0026#34;, pBlkDev); Advantages # Strength Description Compatibility Easily readable on desktop systems Simplicity Straightforward deployment Broad Support Widely used across embedded devices Limitations # Limited fault tolerance Vulnerable to corruption during power failures Less suitable for safety-critical applications 🚀 2. HRFS — Highly Reliable File System # HRFS (Highly Reliable File System) was introduced to address the reliability limitations of FAT-based storage systems.\nIt is a transaction-based journaling file system optimized for embedded and mission-critical applications.\nKey Features # Transactional integrity Power-failure resilience Journaling support Fast recovery Configurable commit policies Deterministic behavior Certification-friendly architecture Why HRFS Matters # Traditional FAT systems can become corrupted if power is lost during metadata updates. HRFS dramatically reduces this risk through atomic transaction mechanisms.\nThis makes HRFS especially valuable in:\nAerospace systems Industrial controllers Medical devices Defense electronics Autonomous platforms Reliability Model # HRFS maintains consistency by:\nLogging metadata transactions Committing updates atomically Recovering incomplete transactions during reboot This minimizes filesystem corruption and drastically shortens recovery times.\nAdvantages Compared to dosFs # Feature dosFs HRFS Journaling No Yes Power-Fail Protection Limited Strong Recovery Speed Moderate Fast Safety Certification Difficult Easier Reliability Moderate High ⚡ 3. rawFs — Raw File Access # rawFs provides direct access to an entire block device as a single continuous file.\nIt does not implement:\nDirectories File allocation tables Metadata management This eliminates filesystem overhead entirely.\nTypical Use Cases # High-speed data logging Firmware storage Custom binary formats Boot images Deterministic streaming applications Initialization Example # rawFsInit(); Advantages # Benefit Description Maximum Performance Minimal overhead Deterministic Timing No metadata operations Simplicity Direct block-level access Limitations # No directory hierarchy No multi-file management No interoperability with desktop systems 📦 4. ROMFS — Read-Only Memory File System # ROMFS enables files to be embedded directly into the VxWorks image.\nThe filesystem is stored entirely in ROM or flash and mounted as read-only.\nCommon Uses # Static configuration files Embedded web content Default scripts System assets Immutable resources Advantages # Benefit Description Extremely Lightweight Minimal runtime overhead Secure Files cannot be modified Fast Boot No initialization complexity ROMFS is ideal for deeply embedded systems with limited writable storage.\n🌐 5. Network File Systems # VxWorks also supports remote file access mechanisms.\nNFS (Network File System) # NFS is widely used during development for:\nRemote executable loading Shared development resources Log collection Centralized storage Benefits # Simplified development workflow Easy host-target integration Shared storage across multiple systems 🔌 Removable Media and Hot-Plug Support # Modern VxWorks releases include a unified filesystem framework with advanced media management capabilities.\nFeatures # Automatic filesystem detection Hot-plug support Dynamic mount/unmount handling Multiple concurrent file systems Unified APIs across storage types This significantly simplifies removable storage handling in embedded devices.\n⚙️ File System Configuration # File systems are typically integrated through kernel configuration tools such as:\nWorkbench vxprj Example Configuration # vxprj component add INCLUDE_DOSFS vxprj component add INCLUDE_HRFS 📂 Mounting File Systems # Typical mounting example:\n#include \u0026lt;mountLib.h\u0026gt; mount(\u0026#34;/ata0\u0026#34;, \u0026#34;/disk\u0026#34;, \u0026#34;dosFs\u0026#34;, 0, NULL); Applications can then access files normally:\nfd = open(\u0026#34;/disk/config.txt\u0026#34;, O_RDONLY, 0); 🧠 Caching and Performance Considerations # Caching plays a major role in filesystem performance.\nWrite-Back Cache # Higher performance Delayed writes Increased power-failure risk Write-Through Cache # Safer operation Immediate persistence Lower performance Mission-critical systems often prefer write-through behavior for critical data.\n🛡️ Reliability and Power-Failure Protection # Embedded systems frequently operate in unstable power environments.\nBest Practices # Recommendation Reason Use HRFS for critical storage Journaling protection Enable transactional boundaries Predictable recovery Avoid filesystem operations in ISR context Prevent deadlocks Use UPS or capacitor backup Prevent sudden shutdowns Periodically sync data Reduce data loss windows ⚡ Real-Time Considerations # Real-time systems must minimize nondeterministic storage latency.\nRecommended Practices # Avoid blocking filesystem operations in high-priority tasks Use RAM disks for temporary data Offload logging to lower-priority threads Use rawFs for ultra-low-latency streaming 🔒 Security Features # Modern VxWorks versions integrate storage with broader platform security features.\nSecurity Capabilities # Filesystem permissions Secure boot integration Signed firmware validation Encrypted storage support Access control frameworks These features are increasingly important for:\nIndustrial IoT Aerospace Medical systems Defense platforms 🧪 Debugging and Monitoring # VxWorks provides multiple tools for diagnosing filesystem issues.\nUseful Capabilities # Tool/Feature Purpose I/O statistics Performance analysis Volume monitoring Capacity tracking File descriptor inspection Leak detection Shell commands Runtime diagnostics Monitoring storage health is especially important in long-running embedded deployments.\n📊 Choosing the Right File System # File System Best For Reliability Performance dosFs General compatibility Moderate Good HRFS Mission-critical systems Excellent Good rawFs Deterministic logging High Excellent ROMFS Static embedded content Excellent Excellent NFS Development environments Network-dependent Moderate 🧭 Best Practices for Embedded Developers # ✅ Reliability # Use HRFS whenever data integrity is critical.\n✅ Determinism # Avoid unpredictable storage operations in time-critical tasks.\n✅ Scalability # Separate application logic from hardware-specific storage assumptions.\n✅ Maintainability # Use standardized APIs and modular filesystem configurations.\n✅ Testing # Perform repeated power-cycle and fault-injection testing.\n🏁 Conclusion # VxWorks provides one of the most mature and flexible filesystem architectures available in the RTOS ecosystem. Its modular I/O subsystem enables seamless integration of multiple storage technologies while maintaining strong real-time characteristics and application portability.\nFrom the widely compatible dosFs to the transaction-based reliability of HRFS, the lightweight simplicity of ROMFS, and the deterministic performance of rawFs, developers can choose the optimal storage solution for virtually any embedded workload.\nAs embedded systems continue evolving toward higher reliability, stronger security, and longer deployment lifecycles, the VxWorks filesystem framework remains a foundational technology enabling robust mission-critical computing.\n📚 References # Wind River Official Documentation VxWorks Programmer\u0026rsquo;s Guide VxWorks Kernel API Documentation Wind River File System Documentation POSIX Filesystem Standards Documentation ","date":"2026-05-23","externalUrl":null,"permalink":"/training/vxworks-file-systems-architecture-features-and-best-practices/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks File Systems: Architecture, Features, and Best Practices\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e📖 Introduction \n    \u003cdiv id=\"-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eReliable and efficient storage management is a core requirement for modern embedded and real-time systems. Whether handling persistent configuration data, event logging, firmware updates, or mission-critical telemetry, the underlying file system architecture directly impacts system stability, determinism, and long-term maintainability.\u003c/p\u003e","title":"VxWorks File Systems: Architecture, Features, and Best Practices","type":"training"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/automotive/","section":"Tags","summary":"","title":"Automotive","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/mission-critical-systems/","section":"Tags","summary":"","title":"Mission-Critical Systems","type":"tags"},{"content":" Mission-Critical Systems: Why Failure Is Not an Option\nSince the launch of the VxWorks RTOS in 1987, Wind River has remained deeply rooted in the world of embedded and edge computing. Over decades of deployment across aerospace, telecommunications, medical systems, automotive platforms, and industrial infrastructure, one truth has become increasingly clear:\nNot all computing systems are built with the same assumptions.\nFor most consumer applications, failures are frustrating. For mission-critical systems, failures can become catastrophic.\nA crashed social media app is inconvenient. A frozen cockpit controller, failed ventilator, or dropped emergency communication link can cost lives.\nThis distinction fundamentally changes how mission-critical systems are designed, validated, deployed, and maintained.\n🚨 What Truly Defines a Mission-Critical System? # The phrase \u0026ldquo;mission-critical\u0026rdquo; is often overused in marketing.\nMany organizations describe their applications as critical because downtime affects revenue or operations. A retail POS outage, a cloud service interruption, or a project management system crash can indeed create enormous business disruption.\nHowever, mission-critical computing exists in a completely different category.\nMission-critical systems are environments where:\nfailure is unacceptable, deterministic behavior is mandatory, recovery opportunities may not exist, and human safety frequently depends on continuous operation. These systems demand engineering philosophies that go far beyond standard software development practices.\nThe principle is simple:\nThe system must continue operating correctly even under worst-case conditions.\nThis requirement reshapes every architectural decision.\n✈️ Aerospace: Flight Systems Cannot Fail # If you have flown on a modern commercial aircraft during the past two decades, there is a high probability that some part of the avionics stack was powered by Wind River technology.\nAircraft systems operate under one of the strictest reliability environments ever created.\nAviation engineers must assume:\nhardware failures, transient faults, software defects, electromagnetic interference, and unpredictable environmental conditions can all occur during active flight.\nThe solution is not simply \u0026ldquo;better testing.\u0026rdquo;\nThe solution is architectural isolation.\n🧩 Isolation Is the Foundation of Aviation Safety # Modern avionics increasingly rely on Integrated Modular Avionics (IMA) architectures, where multiple applications execute on shared hardware platforms.\nFor example:\nflight controls, navigation, cockpit displays, communication systems, and maintenance tools may all coexist on the same multicore processor.\nWithout strong isolation, one faulty application could compromise the entire aircraft.\nMission-critical avionics therefore depend on:\nhypervisor partitioning, memory isolation, temporal partitioning, and hardware-enforced separation. Even if two systems execute on the exact same silicon, they must behave as though they are physically independent.\nThis is one reason standards like ARINC 653 became foundational in modern aerospace computing.\n🏥 Medical Systems: Life Support Devices Cannot Reboot # One of the most striking examples of mission-critical computing comes from ventilator systems.\nA patient relying continuously on a medical ventilator may depend on that device every second for years.\nUnder these conditions:\nrebooting is unacceptable, downtime is unacceptable, undefined states are unacceptable. A temporary software crash is not merely a bug. It becomes a direct threat to human survival.\n🔄 The Challenge of Continuous Operation # Designing systems that operate continuously for years introduces extraordinary engineering challenges:\nResource Stability # The system cannot:\nleak memory, fragment resources, accumulate unrecoverable state corruption, or gradually degrade over time. Deterministic State Management # Incoming data streams must be processed continuously without destabilizing the system.\nSecurity Maintenance # Security vulnerabilities still require patching, yet updates cannot interrupt operation.\nThis creates a major challenge:\nHow do you safely update a device that is never allowed to stop running?\nMission-critical medical systems therefore require:\nhot patching, fail-safe update strategies, rollback protection, and extensive validation pipelines. 🚀 Space Exploration: There Are No Technicians on Mars # The Mars rover Curiosity runs on the VxWorks RTOS.\nFrom a software engineering perspective, space systems represent one of the harshest deployment environments imaginable.\nUnlike terrestrial systems:\nphysical repair is impossible, recovery access may not exist, and communication delays complicate intervention. 📡 OTA Updates in Deep Space # Modern vehicles commonly receive OTA updates overnight while parked.\nMars rovers do not have that luxury.\nIf an OTA update fails on Earth:\na technician can recover the vehicle, restore firmware, or replace hardware. If a Mars rover fails after an update:\nthe mission may be permanently lost. This means update systems themselves must become mission-critical infrastructure.\nSpace-grade update systems therefore require:\natomic updates, rollback partitions, redundancy, transactional firmware deployment, and exhaustive validation. The rover must remain recoverable even if:\ncommunication drops mid-update, power fluctuates, or unexpected software faults occur. 🚗 Automotive Systems: ADAS Decisions Happen in Milliseconds # Advanced Driver Assistance Systems (ADAS) and autonomous driving systems push real-time computing into extremely demanding territory.\nConsider a vehicle approaching an intersection when a runaway truck suddenly appears.\nThe system must:\ndetect the threat, classify the object, predict trajectories, determine avoidance strategies, and execute commands within milliseconds.\nAny hesitation may become fatal.\n⚡ Determinism Matters More Than Raw Performance # Mission-critical automotive systems prioritize:\npredictability, deterministic latency, and guaranteed response timing over peak benchmark numbers.\nThe system cannot:\nfreeze, enter undefined states, stall under heavy load, or miss scheduling deadlines. In many cases, the software must even override its own default operating constraints if doing so increases passenger survival probability.\nThis requires:\nreal-time scheduling, hardware acceleration, isolated execution domains, and microsecond-level timing guarantees. 📡 Telecommunications: Emergency Networks Must Stay Alive # During large-scale disasters, telecommunications infrastructure becomes life-saving infrastructure.\nDuring the Eaton Fire in Southern California, emergency communication reliability became a matter of survival.\nWhen someone calls emergency services:\nthe call cannot drop, the network cannot collapse, and congestion cannot prevent connectivity. 🏗️ Reliability Through Isolation # To achieve carrier-grade reliability, telecom infrastructure increasingly relies on:\nsoftware-defined networking, virtualized infrastructure, and commercial off-the-shelf hardware. However, achieving reliability at scale requires strict isolation strategies.\nOperators must carefully determine:\nwhich components may share hardware, where software boundaries exist, how workloads are isolated, and how failures are contained. This directly influences:\nabstraction layers, hypervisor design, failover architecture, and redundancy planning. 🧠 Mission-Critical Development Requires a Completely Different Mindset # Mission-critical engineering fundamentally rejects the philosophy of:\n\u0026ldquo;Move fast and break things.\u0026rdquo;\nBecause when systems control:\naircraft, medical devices, emergency networks, or autonomous vehicles, breaking things is not acceptable.\n⏳ Long Lifecycles Change Everything # Mission-critical systems often remain operational for decades.\nThat means engineers must consider:\nhardware obsolescence, long-term software maintenance, certification continuity, supply chain stability, and future upgrade paths from the very beginning.\nA consumer laptop may be replaced every few years. An aerospace or industrial platform may remain active for 20 years or longer.\n🧪 Verification Becomes Central # Mission-critical systems require:\nexhaustive validation, deterministic testing, fault injection, formal verification, compliance certification, and continuous regression testing. The testing burden becomes enormous because:\nevery update, every patch, and every configuration change must maintain the same safety guarantees as the original release.\n🔗 Cross-Industry Knowledge Sharing Is Becoming Increasingly Important # One major trend in mission-critical engineering is the growing collaboration across industries.\nTechnologies originally developed for:\naerospace, telecommunications, automotive, and industrial systems are increasingly influencing one another.\nExamples include:\nvirtualization, OTA safety frameworks, real-time Linux improvements, hypervisor isolation, and edge AI inference. Organizations such as:\nIEEE, OpenInfra, Linux Foundation projects, and embedded systems consortiums are helping accelerate this knowledge transfer.\nAs industries converge around edge computing and AI-enabled systems, mission-critical engineering is becoming less siloed and more interconnected.\n🌍 The Future of Mission-Critical Computing # The next generation of mission-critical systems will become even more complex due to:\nAI integration, autonomous systems, distributed edge computing, software-defined infrastructure, and increasing cyber threats. Future systems will need to simultaneously achieve:\ndeterministic behavior, adaptive intelligence, remote manageability, and continuous security updates. This raises the engineering bar dramatically.\nYet the core principle remains unchanged:\nReliability is not a feature added at the end. It is the foundation upon which the entire system is built.\nMission-critical systems are not defined by marketing language or enterprise importance. They are defined by the consequences of failure.\nWhether in the skies, hospitals, highways, deep space, or emergency networks, these systems form the invisible lifelines of the digital age—and engineering them requires a level of rigor far beyond ordinary software development.\n","date":"2026-05-23","externalUrl":null,"permalink":"/industries/mission-critical-systems-why-failure-is-not-an-option/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eMission-Critical Systems: Why Failure Is Not an Option\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eSince the launch of the VxWorks RTOS in 1987, Wind River has remained deeply rooted in the world of embedded and edge computing. Over decades of deployment across aerospace, telecommunications, medical systems, automotive platforms, and industrial infrastructure, one truth has become increasingly clear:\u003c/p\u003e","title":"Mission-Critical Systems: Why Failure Is Not an Option","type":"industries"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/telecommunications/","section":"Tags","summary":"","title":"Telecommunications","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/arinc-653/","section":"Tags","summary":"","title":"ARINC 653","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/ima/","section":"Tags","summary":"","title":"IMA","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/low-altitude-economy/","section":"Tags","summary":"","title":"Low-Altitude Economy","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/safety-critical-systems/","section":"Tags","summary":"","title":"Safety-Critical Systems","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/uav/","section":"Tags","summary":"","title":"UAV","type":"tags"},{"content":" Why ARINC 653 Matters for the Future of Low-Altitude Avionics\nDriven by a new wave of technological innovation, industrial upgrading, and regulatory support, the low-altitude economy is rapidly emerging as a major strategic industry. As application scenarios expand and aircraft platforms diversify, the development of low-altitude aircraft is shifting from isolated technical breakthroughs toward full-system engineering evolution.\nAt the center of this transformation lies the avionics system.\nWhether for UAVs, eVTOL aircraft, or traditional general aviation platforms, avionics software now determines not only flight capability, but also safety, scalability, maintainability, and long-term certification viability. As flight control, communication, navigation, surveillance, and mission systems continue to integrate into increasingly compact computing platforms, software architecture becomes the true foundation of next-generation low-altitude aviation.\nFor solving these architectural challenges, the commercial aviation industry already possesses a mature and battle-tested solution: ARINC 653.\nOriginally developed for Integrated Modular Avionics (IMA) architectures in modern airliners such as the Airbus A380, Boeing 787, and COMAC C919, ARINC 653 provides standardized mechanisms for software isolation, deterministic scheduling, fault containment, and hardware abstraction.\nToday, the low-altitude aviation industry stands at a crossroads: continue relying on fragmented custom architectures, or adopt standardized avionics frameworks capable of supporting long-term safety and scalability.\nThis article explores why ARINC 653 is increasingly becoming a necessary foundation for low-altitude avionics systems.\n✈️ The Architectural Challenges Facing Low-Altitude Aircraft # Compared to traditional large commercial aircraft, low-altitude aviation platforms evolve much faster and exhibit significantly greater diversity:\nUAVs prioritize lightweight deployment and rapid iteration eVTOL platforms demand extreme SWaP optimization General aviation aircraft often mix legacy and modern avionics Autonomous systems require increasingly complex software stacks Multi-vendor integration is becoming unavoidable This diversity creates several core engineering problems:\nChallenge Impact Heterogeneous hardware Difficult software portability Mixed safety-critical workloads Increased integration risk Rapid platform iteration High redevelopment costs Multi-core complexity Hard real-time scheduling issues Fault isolation requirements Risk of cascading failures Certification pressure Longer development cycles Without a standardized avionics architecture, each new aircraft platform effectively becomes a complete software redesign project.\nThat approach may work during early experimentation phases, but it becomes economically and technically unsustainable as the industry scales.\n🧩 The Core Goals of ARINC 653 # The primary objective of ARINC 653 is to standardize the interface between avionics application software and core system software through the APEX (APplication/EXecutive) API specification.\nIts design philosophy revolves around four major objectives:\n1. Portability # Applications developed against the APEX interface are largely decoupled from specific hardware platforms and operating systems.\nThis enables:\nEasier migration across hardware generations Reduced recertification workload Faster product evolution For low-altitude aircraft manufacturers, portability becomes critical once product lines begin scaling across multiple vehicle classes.\n2. Reusability # Certified avionics software is extremely expensive to develop.\nARINC 653 allows:\nFlight control modules Navigation systems Communication stacks Monitoring applications to be reused across multiple aircraft platforms with minimal modifications.\nThis dramatically reduces lifecycle development costs.\n🛡️ 3. Modularity # ARINC 653 eliminates tight coupling between applications and hardware through a layered architecture:\nApplication Software ↓ APEX Interface ↓ Core Software / RTOS / Hypervisor ↓ Hardware Platform As long as the APEX interface remains stable, underlying hardware changes have minimal impact on upper-level avionics software.\nThis is especially valuable in low-altitude aviation, where:\nsuppliers frequently change, hardware evolves rapidly, and long-term platform maintenance is unavoidable. 🔒 4. Mixed-Criticality Integration # One of ARINC 653\u0026rsquo;s most important capabilities is safely integrating applications with different safety levels on the same computing hardware.\nFor example:\nApplication Safety Criticality Flight control DAL A Navigation DAL B Cabin display DAL C Entertainment / telemetry DAL D Without strict isolation, lower-criticality software can jeopardize safety-critical functions.\nARINC 653 solves this through deterministic partitioning.\n⚙️ Core Technical Mechanisms of ARINC 653 # 🧠 1. Partitioning Mechanism # Partitioning is the foundation of ARINC 653.\nIt consists of two forms of isolation:\nPartition Type Purpose Spatial partitioning Memory isolation Temporal partitioning CPU time isolation Together, they ensure applications cannot interfere with one another.\nSingle-Core Systems # Traditional implementations rely on the MMU (Memory Management Unit):\nEach partition receives isolated virtual memory regions Unauthorized memory access triggers exceptions Applications cannot corrupt neighboring partitions Multi-Core Systems and Virtualization # Modern avionics increasingly use multi-core SoCs.\nCurrent mainstream implementations introduce a Type-1 Hypervisor architecture.\nExample:\nHardware ↓ Hypervisor (EL2) ↓ Partition OS ↓ Applications Platforms such as:\nWind River Helix LynxSecure PikeOS use hardware-assisted virtualization technologies:\nARM EL2 Intel VT-x AMD-V SMMU/IOMMU to achieve robust hardware-level isolation.\nThis approach provides:\nextremely fast context switching, strong fault containment, and scalable multi-core scheduling. ⏱️ 2. Deterministic Scheduling # ARINC 653 defines two independent scheduling layers.\nPartition Scheduling # Partition scheduling is fully deterministic.\nThe system executes partitions according to a predefined cyclic scheduling table:\nTime Frame: | Partition A | Partition B | Partition C | Characteristics:\nFixed execution windows No dynamic competition between partitions Predictable timing behavior Strong real-time guarantees This is critical for flight certification.\nProcess Scheduling Within Partitions # Inside each partition, processes are scheduled independently using:\npreemptive priority scheduling, processor affinity, POSIX-like mechanisms. This gives developers familiar programming semantics while preserving global determinism.\n🚨 3. Health Monitor (HM) # The Health Monitor is ARINC 653\u0026rsquo;s fault management framework.\nIts purpose is preventing localized failures from escalating into system-wide catastrophes.\nThe HM defines three levels of fault handling:\nError Level Scope Typical Actions Module Level Entire avionics module Reset module / shutdown Partition Level Single partition Restart partition Process Level Individual task Kill or restart process Examples # Process-Level Errors # Stack overflow Illegal memory access Invalid system call Possible recovery:\nRestart task Reinitialize process Escalate to partition-level recovery Partition-Level Errors # Partition initialization failure Configuration corruption Possible recovery:\nCold restart Warm restart Isolation into idle state Module-Level Errors # Hypervisor faults Power anomalies Scheduling failures Possible recovery:\nFull module reset System-wide recovery procedures This hierarchical design forms an extremely powerful safety net for fault isolation.\n🚁 Why ARINC 653 Is Especially Valuable for Low-Altitude Aviation # 🔐 1. Strong Safety Isolation # Low-altitude aircraft increasingly combine:\nautonomy, AI workloads, communications, navigation, vision processing, and flight control on shared computing hardware.\nWithout deterministic partitioning:\na software bug, memory leak, or deadlock can jeopardize the entire aircraft.\nARINC 653 prevents cascading failures by design.\n⚡ 2. High Availability and Fast Recovery # Through Health Monitor mechanisms:\nfaults can be detected rapidly, isolated immediately, and recovered independently. Instead of rebooting an entire aircraft computer, only the affected partition may need restarting.\nThis greatly improves operational reliability.\n📦 3. SWaP Optimization # SWaP (Size, Weight, and Power) is one of the most important constraints in:\neVTOLs, UAVs, battery-powered aircraft. Traditional federated avionics architectures require many separate computing boxes.\nIMA architectures enabled by ARINC 653 consolidate:\nflight control, mission systems, displays, communication modules onto shared computing hardware.\nBenefits include:\nreduced weight, lower power consumption, simplified wiring, lower maintenance complexity. This is especially important for electric aircraft with tight battery budgets.\n💰 4. Lower Lifecycle Costs # Standardized interfaces allow:\nsoftware reuse, easier certification reuse, hardware migration, supplier flexibility. Over time, this dramatically reduces:\nengineering costs, maintenance costs, recertification burden. As low-altitude aviation transitions from prototypes to mass deployment, lifecycle economics become decisive.\n🧭 ARINC 653 and the Future of the Low-Altitude Economy # The low-altitude economy is entering a phase where:\nscale, safety, certification, and operational reliability matter more than raw experimentation speed.\nEventually, the winners in this industry will not simply be those who innovate fastest, but those capable of building:\nscalable systems, certifiable architectures, and sustainable engineering ecosystems. ARINC 653 offers precisely this kind of foundation.\nIt transforms avionics development from:\ntightly coupled custom integration into:\nmodular, deterministic, reusable, safety-oriented system engineering. For low-altitude aircraft seeking long-term commercial viability, adopting aviation-grade architectural standards is no longer optional—it is becoming inevitable.\nARINC 653 may not solve every challenge in low-altitude aviation, but it provides one of the few mature and proven frameworks capable of supporting the industry\u0026rsquo;s transition from experimental platforms to truly large-scale, safety-critical aerospace systems.\n","date":"2026-05-23","externalUrl":null,"permalink":"/industries/why-arinc-653-matters-for-low-altitude-avionics-systems/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eWhy ARINC 653 Matters for the Future of Low-Altitude Avionics\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eDriven by a new wave of technological innovation, industrial upgrading, and regulatory support, the low-altitude economy is rapidly emerging as a major strategic industry. As application scenarios expand and aircraft platforms diversify, the development of low-altitude aircraft is shifting from isolated technical breakthroughs toward full-system engineering evolution.\u003c/p\u003e","title":"Why ARINC 653 Matters for Low-Altitude Avionics Systems","type":"industries"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/bootrom/","section":"Tags","summary":"","title":"Bootrom","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/bsp/","section":"Tags","summary":"","title":"BSP","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/kernel/","section":"Tags","summary":"","title":"Kernel","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/task-scheduling/","section":"Tags","summary":"","title":"Task-Scheduling","type":"tags"},{"content":"","date":"2026-05-23","externalUrl":null,"permalink":"/tags/tornado/","section":"Tags","summary":"","title":"Tornado","type":"tags"},{"content":" VxWorks RTOS Architecture and Embedded System Implementation Guide\nAs embedded systems evolved from simple microcontroller-based designs into complex communication and industrial computing platforms, the demand for deterministic real-time operating systems increased dramatically.\nModern embedded applications require:\nPredictable scheduling Low interrupt latency Efficient multitasking Reliable inter-process communication Modular hardware abstraction Scalable networking support Among commercial real-time operating systems, VxWorks became one of the most widely adopted solutions across telecommunications, aerospace, industrial automation, military systems, and networking infrastructure.\nThis article explores the architecture, scheduling mechanisms, communication models, and engineering implementation workflow of VxWorks, including:\nWind Kernel architecture Task scheduling mechanisms Inter-task communication BSP development BootROM image generation Tornado development workflow Embedded deployment strategies ⚙️ Overview of VxWorks # VxWorks is a high-performance embedded real-time operating system developed by Wind River Systems.\nIt gained widespread adoption because of its:\nDeterministic kernel behavior Extremely low interrupt latency High reliability Small memory footprint Scalable modular architecture Mature development ecosystem VxWorks was especially popular in communication systems where real-time responsiveness and system stability were critical.\n🧠 Wind Kernel Architecture # At the core of VxWorks is the Wind Kernel, a lightweight real-time kernel optimized for deterministic multitasking.\nCore Kernel Features # The Wind Kernel provides:\nFeature Description Preemptive scheduling Immediate response to high-priority tasks Fast context switching Minimal scheduling overhead Low interrupt latency Rapid ISR handling Efficient multitasking Scalable concurrent execution High networking throughput Optimized protocol stack interaction The kernel was specifically designed for environments where response predictability matters more than general-purpose throughput.\n🔄 Task Scheduling Mechanism # VxWorks uses a priority-driven multitasking model.\nScheduling Policies # The RTOS supports two primary scheduling mechanisms:\nScheduling Type Purpose Priority-based preemptive scheduling Primary scheduler Round-robin time slicing Equal-priority fairness Priority Levels # VxWorks supports:\n256 priority levels 0 = highest priority 255 = lowest priority Whenever a higher-priority task becomes ready, the kernel immediately preempts the currently running lower-priority task.\nThis deterministic behavior is one of the defining characteristics of VxWorks.\n🧩 Task Context and Task Control Blocks # Every executing program in VxWorks is represented as a task.\nEach task maintains its execution state within a:\nTask Control Block (TCB) Information Stored in the TCB # The TCB contains:\nContext Information Purpose Program counter Current execution position CPU registers Execution state Floating-point registers Numeric processing state Stack information Function calls and variables Delay parameters Sleep and timeout handling Signal information Event handling Debug information Runtime analysis This architecture allows extremely fast task switching while maintaining task isolation.\n🚦 Task States in VxWorks # Tasks transition between multiple execution states during runtime.\nMajor Task States # State Description READY Waiting for CPU execution PEND Waiting for resources DELAY Sleeping for a specified duration SUSPEND Suspended manually or by debugger Example Transition # taskActivate(); This system call transitions a task from:\nSUSPEND → READY The scheduler then determines when the task receives CPU time.\n⚡ Interrupt Handling Design # Interrupt responsiveness is one of VxWorks’ strongest features.\nDedicated Interrupt Stack # VxWorks separates:\nInterrupt stack Task stack This reduces task-switch overhead during interrupt handling.\nISR Optimization Strategy # When an interrupt occurs:\nOnly critical registers are saved ISR performs minimal work Deferred processing is delegated to tasks This approach minimizes latency while preserving deterministic scheduling behavior.\nDeferred Processing Model # Typical ISR workflow:\nISR → Signal semaphore/message → Worker task processes data This design remains common in modern RTOS architectures.\n🔗 Inter-Task Communication Mechanisms # Efficient communication between tasks is critical in real-time systems.\nVxWorks provides several IPC mechanisms optimized for different workloads.\n🧵 Shared Memory # Shared memory is the simplest communication model.\nAdvantages # Extremely fast Minimal overhead Efficient for bulk data exchange Challenges # Requires synchronization Risk of race conditions Shared memory is often paired with semaphores for protection.\n🔒 Semaphores # Semaphores are widely used for:\nSynchronization Mutual exclusion ISR-to-task signaling Binary Semaphore Example # SEM_ID semId; semId = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY); ISR Signaling # semGive(semId); Task Synchronization # semTake(semId, WAIT_FOREVER); Semaphores are among the fastest synchronization primitives in VxWorks.\n📬 Message Queues # Message queues are the preferred mechanism for structured task communication.\nQueue Creation # MSG_Q_ID msgQId; msgQId = msgQCreate( 32, 128, MSG_Q_PRIORITY ); Sending Messages # msgQSend(...); Receiving Messages # msgQReceive(...); Queue Ordering Modes # Mode Behavior FIFO First-in, first-out PRIORITY Priority-sorted messages Message queues support:\nTask-to-task communication ISR-to-task communication Timeout handling 🛠️ Tornado Development Environment # VxWorks development traditionally relied on the Tornado integrated development environment.\nTornado Capabilities # The IDE provided:\nCross-compilation tools Remote debugging Kernel configuration Symbol inspection Target management Runtime analysis Supported Host Platforms # Tornado could run on:\nWindows NT Unix Linux workstations 🧩 Board Support Package (BSP) Development # The BSP adapts VxWorks to a specific hardware platform.\nResponsibilities of the BSP # The BSP handles:\nCPU initialization Memory setup Interrupt configuration Cache control Device initialization Bootloader integration Without a BSP, VxWorks cannot interact with the target hardware.\n📁 Key BSP Files # Several files form the core of a VxWorks BSP.\nFile Purpose Makefile Build configuration romInit.s Low-level assembly startup config.h Kernel configuration macros bootConfig.c Boot hardware initialization bootInit.c FLASH-to-RAM image copying 🚀 Boot Initialization Process # The boot sequence typically follows this order:\nPower On ↓ romInit.s ↓ bootInit.c ↓ bootConfig.c ↓ VxWorks Kernel Startup Responsibilities of romInit.s # The assembly startup code typically:\nDisables interrupts Initializes CPU registers Disables cache temporarily Configures memory Prepares execution environment Because assembly debugging is difficult during early boot, developers often use:\nLEDs GPIO toggles Serial output for low-level debugging visibility.\n💾 VxWorks Image Types # VxWorks supports several image formats optimized for different deployment scenarios.\nImage Type Execution Method Typical Usage VxWorks Downloaded into RAM Debugging VxWorks-rom Copied from FLASH to RAM Production systems VxWorks-romRes Executes directly from ROM Memory-constrained devices 🔍 Development and Debugging Workflow # A common engineering workflow follows these stages:\nStage 1: RAM-Based Debugging # Developers initially use:\nEthernet RS232 serial connection to download RAM-based images.\nAdvantages include:\nFast iteration Breakpoint support Runtime inspection Stage 2: System Validation # Using Tornado tools, developers can:\nMonitor tasks Inspect memory Analyze scheduling Set breakpoints Trace execution flow Stage 3: Production Deployment # After validation:\nBuild VxWorks-rom Burn image into FLASH Boot directly from onboard storage Programming tools commonly included:\nBDM interfaces visionClick FLASH utilities 📡 POSIX and ANSI C Compliance # VxWorks was among the earliest RTOS platforms supporting:\nPOSIX 1003.1b ANSI C compatibility This improved:\nSoftware portability API consistency Third-party integration Standards compliance helped accelerate adoption in commercial and defense applications.\n🚀 Real-Time Advantages of VxWorks # Several characteristics made VxWorks particularly suitable for mission-critical embedded systems.\nDeterministic Scheduling # High-priority tasks receive immediate CPU access.\nLow Interrupt Latency # Minimal ISR overhead improves responsiveness.\nModular Architecture # Components can be selectively included or removed.\nEfficient IPC # Fast semaphores and queues reduce synchronization overhead.\nStrong Scalability # The same RTOS architecture could scale from small controllers to complex communication platforms.\n🌍 Modern Perspective on VxWorks # Although modern embedded systems increasingly incorporate Linux-based solutions, VxWorks remains widely used in:\nAerospace Defense systems Industrial control Avionics Satellite systems High-reliability networking equipment Contemporary versions such as:\nVxWorks 7 Wind River Helix introduce:\nMulti-core scheduling Security hardening Container support TSN networking Advanced tracing tools OTA update systems However, the foundational concepts explored in classic VxWorks systems remain central to real-time operating system design today.\n📌 Conclusion # VxWorks established itself as one of the most influential embedded real-time operating systems because of its deterministic scheduling, efficient interrupt handling, modular architecture, and mature development ecosystem.\nIts engineering workflow — including BSP development, BootROM generation, and Tornado-based debugging — provided developers with a complete framework for building reliable embedded systems across a wide range of industries.\nThe principles discussed in this article remain highly relevant for modern embedded engineering, especially in systems where predictability, low latency, and reliability are non-negotiable requirements.\n","date":"2026-05-23","externalUrl":null,"permalink":"/training/vxworks-rtos-architecture-and-embedded-system-implementation-guide/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks RTOS Architecture and Embedded System Implementation Guide\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eAs embedded systems evolved from simple microcontroller-based designs into complex communication and industrial computing platforms, the demand for deterministic real-time operating systems increased dramatically.\u003c/p\u003e","title":"VxWorks RTOS Architecture and Embedded System Implementation Guide","type":"training"},{"content":"","date":"2026-05-22","externalUrl":null,"permalink":"/tags/end-driver/","section":"Tags","summary":"","title":"End-Driver","type":"tags"},{"content":"","date":"2026-05-22","externalUrl":null,"permalink":"/tags/ethernet/","section":"Tags","summary":"","title":"Ethernet","type":"tags"},{"content":" Implementing Multi-Port Ethernet in VxWorks Using END and MUX\nReliable networking is a foundational requirement for modern embedded systems. As industrial controllers, communication gateways, and edge computing devices evolved toward Ethernet-based architectures, embedded real-time operating systems needed scalable and modular networking frameworks capable of supporting multiple interfaces simultaneously.\nThis article explores the implementation of dual Ethernet interfaces in VxWorks running on the Motorola MPC860T processor. The design leverages the END (Enhanced Network Driver) architecture and the MUX networking layer to support:\nMultiple Ethernet controllers Flexible protocol integration Independent network interfaces Modular TCP/IP communication The implementation demonstrates how VxWorks can efficiently manage both a traditional 10 Mbps Ethernet interface and a 10/100 Mbps adaptive Fast Ethernet interface within the same embedded platform.\n🌐 Why Ethernet and TCP/IP Dominate Embedded Networking # TCP/IP and Ethernet became dominant in embedded communication systems for several reasons:\nLow deployment cost Standardized interoperability Scalable network topology Mature software ecosystem Broad hardware availability Strong protocol extensibility Compared with proprietary fieldbus or serial communication systems, Ethernet provides significantly greater flexibility for:\nIndustrial automation Networked control systems Remote diagnostics Embedded gateways Distributed processing systems As embedded platforms grew more sophisticated, RTOS environments such as VxWorks became critical for maintaining deterministic network behavior under real-time workloads.\n⚙️ Why VxWorks Was Used # VxWorks has historically been a preferred RTOS in networking and telecommunications infrastructure because it combines:\nDeterministic scheduling High interrupt responsiveness Small kernel footprint Mature TCP/IP stack Modular driver architecture Strong BSP portability The implementation described here was developed using:\nTornado 2.0 VxWorks networking stack MPC860T Board Support Package (BSP) 🧠 Hardware Platform: Motorola MPC860T # The Motorola MPC860T PowerPC processor integrates several communication-oriented peripherals directly into the SoC.\nIntegrated Ethernet Capabilities # The processor provides:\nController Type Capability SCC (Serial Communication Controllers) Up to four 10 Mbps Ethernet interfaces FEC (Fast Ethernet Controller) One 10/100 Mbps adaptive interface This architecture allows flexible multi-port Ethernet configurations using relatively minimal external hardware.\nImplemented Ethernet Configuration # The project successfully implemented:\nInterface Type CPM/SCC Port 10 Mbps Ethernet FEC Port 10/100 Mbps adaptive Ethernet The actual number of usable Ethernet interfaces depends on:\nCPU frequency Packet throughput Interrupt load Overall task scheduling pressure The system described operated at:\n50 MHz CPU clock frequency 🏗️ VxWorks Networking Architecture # VxWorks includes a complete TCP/IP networking stack with BSD-compatible socket APIs.\nApplications interact with networking services using familiar interfaces such as:\nsocket() bind() send() recv() Driver Integration Models # VxWorks supports two major networking driver architectures:\nDriver Model Characteristics BSD 4.4 Driver Tightly coupled to TCP/IP stack END Driver Modular and protocol-independent The project selected the END driver model because it provides better scalability and supports multiple interfaces cleanly.\n🔀 The END Driver and MUX Architecture # The END architecture separates network drivers from protocol implementations through the MUX layer.\nRole of the MUX Layer # The MUX layer acts as an intermediary between:\nData link layer drivers Network protocol stacks This decoupling provides several advantages:\nMulti-protocol support Cleaner modularity Better extensibility Multicast support Polling-mode capability Receive Path # Hardware → END Driver → MUX → TCP/IP Stack Transmit Path # TCP/IP Stack → MUX → END Driver → Hardware This architecture became the standard networking framework for modern VxWorks deployments.\n🚀 END Driver Initialization Flow # During system startup, VxWorks initializes the networking subsystem in stages.\nInitialization Sequence # usrRoot() → usrNetworkInit() → usrNetProtoInit() → muxLibInit() → usrEndLibInit() Driver Loading Process # The following functions are central to END driver activation:\nFunction Purpose muxDevLoad() Load END driver muxDevStart() Start driver sysIntConnect() Register ISR handlers netJobAdd() Schedule deferred network processing Interrupt Processing Strategy # To reduce interrupt latency:\nISRs perform minimal work Packet processing is deferred Heavy workloads run inside NetTask This approach improves determinism and system responsiveness.\n🧩 Enabling Multiple Network Interfaces # Most VxWorks BSPs initially support only one network interface.\nSupporting multiple Ethernet ports requires BSP-level modifications.\nKey Configuration Files # File Purpose config.h Hardware feature definitions configNet.h Network interface configuration ⚙️ Modifying config.h # The CPM-based Ethernet controller must be explicitly enabled.\nExample Modification # #define INCLUDE_CPM The FADS_860T macro controls which interface becomes the default network interface:\nmotfec0 → 10/100 Mbps FEC cpm0 → 10 Mbps SCC 🌐 Expanding Interface Support in configNet.h # By default:\nIP_MAX_UNITS = 1 This must be increased.\nExample Modification # #undef IP_MAX_UNITS #define IP_MAX_UNITS 2 This allows the TCP/IP stack to manage multiple interfaces simultaneously.\n🔧 Starting Additional Ethernet Interfaces # Additional interfaces are initialized manually during network startup.\nExample Addition # usrCPMEndDevStart( \u0026#34;cpm\u0026#34;, 1, lpInfo[0].target_name, lpInfo[0].ip_address, lpInfo[0].netmask ); routeAdd(...); Interface Naming Convention # Interface Unit Number Primary FEC motfec0 Secondary CPM cpm1 The second interface typically uses unit number 1.\n📦 Network Configuration Structures # Custom interface configuration structures simplify interface initialization.\nExample Structure # struct cpmlpInfo { char *target_name; char *ip_address; char *network; int netmask; char *gateway; }; Example Interface Table # struct cpmlpInfo lpInfo[] = { {\u0026#34;baby\u0026#34;, \u0026#34;128.10.1.60\u0026#34;, \u0026#34;128.10.1.0\u0026#34;, 0xffffffff, \u0026#34;128.10.1.60\u0026#34;}, {NULL, NULL, NULL, 0, NULL} }; This structure stores per-interface networking parameters.\n🛠️ Core Implementation of usrCPMEndDevStart() # The initialization routine performs several critical tasks:\nLocate the END device Retrieve MIB-II information Attach the IP stack Configure the interface Activate routing Example Implementation # void usrCPMEndDevStart( char *pDevName, int unitNum, char *pTgtName, char *pAddrString, int netmask ) { END_OBJ* pEnd; M2_INTERFACE_TBL endM2Tbl; pEnd = endFindByName(pDevName, unitNum); if (pEnd == NULL) { printf(\u0026#34;Could not find %s%d\\n\u0026#34;, pDevName, unitNum); return; } if (ipAttach(unitNum, pDevName) != OK) { printf(\u0026#34;Failed to attach device\\n\u0026#34;); return; } if (usrNetIfConfig( pDevName, unitNum, pAddrString, pTgtName, netmask) != OK) { printf(\u0026#34;Configuration failed\\n\u0026#34;); return; } printf(\u0026#34;Attached TCP/IP interface\\n\u0026#34;); } ⚠️ Important Multi-Interface Considerations # Use Separate Network Segments # Each Ethernet interface should operate on a distinct subnet.\nExample:\nInterface Network motfec0 192.168.1.x cpm1 10.0.0.x This avoids routing ambiguity and improves network isolation.\nBootline Configuration # VxWorks boot parameters define:\nIP address Netmask Gateway Hostname These values are typically configured via:\nDEFAULT_BOOT_LINE inside config.h.\nMultiple IP Addresses # Each interface may also support multiple IP addresses if required by the application.\n🔍 END Driver Advantages in Embedded Systems # Compared with legacy BSD drivers, END drivers provide:\nCapability Benefit Protocol independence Easier future expansion MUX abstraction Cleaner architecture Multiple interfaces Native multi-port support Multicast support Improved network flexibility Polling support Deterministic operation under load This architecture became essential for increasingly network-centric embedded systems.\n🚀 Real-Time Networking Considerations # Multi-interface embedded systems introduce additional real-time challenges:\nPacket interrupt storms Context-switch overhead Buffer management complexity Shared memory contention Optimization Techniques # Typical optimizations include:\nDeferred interrupt handling DMA-based packet movement Prioritized networking tasks Buffer pool tuning Reduced ISR workload VxWorks’ deterministic scheduler makes these optimizations easier to manage under constrained hardware conditions.\n📌 Conclusion # This implementation demonstrates how VxWorks can efficiently support multiple Ethernet interfaces using the END driver framework and MUX networking layer on the Motorola MPC860T platform.\nThrough targeted BSP modifications and custom interface startup logic, the system successfully achieved:\nDual-port Ethernet communication Flexible TCP/IP networking Modular driver integration Scalable architecture for future expansion The END/MUX model remains one of the most important architectural improvements in VxWorks networking, providing a clean and extensible foundation for complex embedded communication systems.\nAlthough the original implementation targeted legacy PowerPC hardware and Tornado-era VxWorks environments, the same architectural principles continue to influence modern RTOS networking stacks today.\n","date":"2026-05-22","externalUrl":null,"permalink":"/training/implementing-multi-port-ethernet-in-vxworks-using-end-and-mux/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eImplementing Multi-Port Ethernet in VxWorks Using END and MUX\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eReliable networking is a foundational requirement for modern embedded systems. As industrial controllers, communication gateways, and edge computing devices evolved toward Ethernet-based architectures, embedded real-time operating systems needed scalable and modular networking frameworks capable of supporting multiple interfaces simultaneously.\u003c/p\u003e","title":"Implementing Multi-Port Ethernet in VxWorks Using END and MUX","type":"training"},{"content":"","date":"2026-05-22","externalUrl":null,"permalink":"/tags/mux/","section":"Tags","summary":"","title":"Mux","type":"tags"},{"content":"","date":"2026-05-22","externalUrl":null,"permalink":"/tags/tcp-ip/","section":"Tags","summary":"","title":"Tcp-Ip","type":"tags"},{"content":"","date":"2026-05-22","externalUrl":null,"permalink":"/tags/h323/","section":"Tags","summary":"","title":"H323","type":"tags"},{"content":"","date":"2026-05-22","externalUrl":null,"permalink":"/tags/voip/","section":"Tags","summary":"","title":"Voip","type":"tags"},{"content":" VxWorks in VoIP Gateways: BSP, Drivers, and H.323 Integration\nAs telecommunications infrastructure evolved from circuit-switched networks toward packet-based IP communications, embedded real-time operating systems became critical to ensuring deterministic voice processing, signaling reliability, and carrier-grade availability.\nAmong the most influential embedded operating systems in telecom infrastructure was VxWorks, the commercial RTOS developed by Wind River Systems. Known for its deterministic scheduling, modular architecture, and robust networking stack, VxWorks became widely adopted in networking, aerospace, industrial automation, and telecommunications platforms.\nThis article examines how VxWorks was applied in an Internet Telephone (VoIP) Gateway built around the Intel 80960RD processor, covering:\nReal-time operating system architecture Tornado development workflow Board Support Package (BSP) implementation Device driver development H.323 protocol stack integration Real-time optimization strategies It also explores how these architectural principles continue influencing modern carrier-grade VoIP and edge communication systems.\n📡 Internet Telephone Gateway Architecture # An Internet Telephone Gateway bridges traditional PSTN infrastructure with IP-based communication networks.\nCore responsibilities include:\nVoice encoding and decoding RTP packetization Echo cancellation Call signaling Media stream management Real-time transport handling Typical Hardware Composition # The gateway platform described in this implementation included:\nComponent Function Intel 80960RD CPU Main control processor DSP Subboard Voice codec processing and echo cancellation Switching Chip Voice timeslot switching Ethernet Interface IP connectivity E1/T1 Interfaces PSTN integration Serial Port Debug and maintenance The system required strict real-time guarantees for voice latency, making VxWorks a strong fit for the platform.\n⚙️ Why VxWorks Was Selected # VxWorks offered several advantages particularly valuable in telecom systems:\nDeterministic real-time scheduling Extremely low interrupt latency Small memory footprint Modular architecture Mature networking stack Reliable inter-task communication primitives Strong hardware portability via BSPs In VoIP gateways, latency consistency matters more than raw throughput. Packet jitter, scheduling delays, and interrupt unpredictability directly impact voice quality.\nVxWorks was specifically engineered for these constraints.\n🧠 VxWorks RTOS Architecture # Wind Kernel # The core of VxWorks is the Wind Kernel, which provides:\nPriority-based preemptive scheduling 256 task priority levels Round-robin scheduling support Fast context switching Microsecond-scale interrupt handling Inter-Task Synchronization # Synchronization primitives include:\nMechanism Purpose Binary semaphores Event signaling Counting semaphores Resource counting Mutex semaphores Mutual exclusion with priority inheritance Priority inheritance was particularly important in preventing priority inversion during high-priority RTP processing.\nIPC Mechanisms # VxWorks supported several lightweight IPC models:\nMessage queues Pipes Signals BSD sockets These mechanisms enabled modular separation between signaling, media processing, and hardware control tasks.\n🛠️ Tornado Development Environment # The project used the Tornado IDE and cross-development environment from Wind River.\nTornado provided:\nCross-compilation tools Remote debugging Real-time tracing System introspection Target management Major Tornado Components # Tool Function CrossWind Source-level debugger WindSh Interactive shell WindView Real-time performance analyzer Browser Object inspection StethoScope System monitoring Debugging Modes # Tornado supported two debugging approaches:\nMode Description System Mode Full system halt debugging Task Mode Dynamic task-level debugging Task-mode debugging was especially useful for observing live voice-processing tasks without stopping the entire system.\n🧩 Board Support Package (BSP) Design # The BSP layer adapts VxWorks to custom hardware.\nFor the Intel 80960RD platform, the BSP included critical initialization logic for:\nCPU startup Interrupt configuration Clock systems PCI interfaces Memory mapping Peripheral initialization Key BSP Files # File Purpose romInit.s Assembly startup code sysLib.c Hardware abstraction layer usrConfig.c Kernel and application configuration BSP Initialization Sequence # romInit: /* Disable interrupts */ /* Hardware low-level initialization */ /* Jump to romStart */ void romStart(void) { /* Copy sections into RAM */ userInit(); } void userInit(void) { sysHwInit(); kernelInit(); } void userRoot(void) { /* Install drivers */ /* Initialize networking */ /* Start application tasks */ } This staged startup model ensured deterministic initialization and reliable subsystem ordering.\n🔌 Hardware Initialization and System Clocks # The BSP initialized low-level hardware resources before kernel scheduling began.\nExample:\nvoid sysHwInit(void) { sysClkInit(1000); /* 1ms system tick */ sysAuxClkInit(100); pciConfigOutLong( PCI_BUS, PCI_DEV, PCI_FUNC, PCI_COMMAND, 0x00000006 ); sysBusToLocalAdrs(...); } Key Responsibilities # The initialization layer handled:\nTimer setup Interrupt controller configuration PCI bridge initialization Shared memory mapping DSP communication interfaces Accurate timer configuration was especially critical for RTP packet timing and jitter control.\n🧱 Device Driver Architecture # VxWorks device drivers integrated through the RTOS I/O subsystem.\nExample Driver Registration # STATUS pciDrvInstall(void) { return iosDrvInstall( pciOpen, pciClose, pciRead, pciWrite, pciIoctl, NULL, NULL ); } Interrupt Handling Workflow # Interrupt service routines remained intentionally lightweight:\nvoid pciIsr(void) { if (pciInterruptPending()) { pciClearInterrupt(); semGive(intSem); } } Actual processing occurred inside dedicated handler tasks:\nvoid pciIntHandler(void) { while (1) { semTake(intSem, WAIT_FOREVER); processDspData(); handleSwitchingEvents(); } } This separation minimized ISR latency while maintaining deterministic scheduling behavior.\n🌐 Ethernet and Networking Integration # The Ethernet subsystem integrated with the VxWorks MUX networking layer.\nThis enabled:\nTCP/IP communication RTP media transport H.323 signaling Remote management services VxWorks provided a BSD-compatible socket API, simplifying integration with networking middleware.\nRTP Socket Example # SOCKET s = socket(AF_INET, SOCK_DGRAM, 0); bind(s, ...); sendto(s, rtpPacket, len, 0, ...); The lightweight networking stack was critical for sustaining real-time voice traffic under constrained hardware conditions.\n☎️ H.323 Protocol Stack Integration # The gateway utilized a third-party H.323 protocol stack running atop VxWorks.\nResponsibilities of the H.323 Stack # The stack handled:\nCall establishment Capability negotiation Media session setup RTP coordination Signaling state management Lower-Layer Integration Modules # The stack interfaced with VxWorks through several abstraction layers:\nModule Function LAN Interface Socket communication Timer Module Watchdog and timing services Message Module Queue-based IPC Memory Module Custom memory pools PDLRAW Protocol description handling Timer Services # Timing services leveraged native VxWorks APIs:\nwdCreate(); wdStart(); taskDelay(); Deterministic timer handling was essential for retransmissions, session management, and RTP scheduling.\n🎛️ Task Scheduling Strategy # Voice workloads were prioritized aggressively.\nTypical task priority allocation:\nTask Type Priority RTP Voice Processing Highest H.225/H.245 Signaling Medium Management Tasks Lower This ensured that real-time media handling remained unaffected by background management operations.\nReal-Time Optimization Techniques # Several optimization techniques improved system stability:\nPriority inheritance semaphores DMA transfers between CPU and DSP Reduced ISR complexity WindView performance profiling Dedicated RTP processing tasks The design target maintained:\nSub-10 ms voice packet processing latency This was critical for maintaining acceptable conversational voice quality.\n🚀 Modern Perspective: VxWorks in 2026 # Although H.323 has largely been replaced by SIP and WebRTC, the underlying real-time principles remain highly relevant.\nModern carrier-grade communication systems still rely on:\nDeterministic scheduling Priority-aware processing Efficient IPC Low-latency networking Hardware abstraction layers Modern VxWorks Deployments # Contemporary systems increasingly utilize:\nVxWorks 7 Wind River Helix Multi-core ARM and x86 SoCs TSN networking Secure RTP (SRTP) Zero-trust security architectures OTA update frameworks Containerized media services Evolution of Telecom Infrastructure # Today’s VoIP gateways and Session Border Controllers commonly support:\nSIP WebRTC Cloud-native orchestration NFV architectures AI-assisted traffic management However, the core engineering disciplines established in early VxWorks telecom systems continue to influence modern embedded networking design.\n📌 Conclusion # VxWorks demonstrated exceptional suitability for real-time VoIP gateway systems built on the Intel 80960RD platform.\nIts deterministic scheduler, modular BSP architecture, robust networking stack, and mature IPC mechanisms enabled reliable integration of:\nDSP-based media processing H.323 signaling RTP transport Hardware switching systems Real-time communication workloads The project highlighted how carefully engineered RTOS architecture can deliver carrier-grade reliability even on resource-constrained embedded hardware.\nWhile telecom infrastructure has evolved significantly since the early H.323 era, the foundational concepts pioneered in these systems remain central to modern real-time communication platforms.\nReference: VxWorks in VoIP Gateways: BSP, Drivers, and H.323 Integration\n","date":"2026-05-22","externalUrl":null,"permalink":"/bsp/vxworks-in-voip-gateways-bsp-drivers-and-h.323-integration/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks in VoIP Gateways: BSP, Drivers, and H.323 Integration\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eAs telecommunications infrastructure evolved from circuit-switched networks toward packet-based IP communications, embedded real-time operating systems became critical to ensuring deterministic voice processing, signaling reliability, and carrier-grade availability.\u003c/p\u003e","title":"VxWorks in VoIP Gateways: BSP, Drivers, and H.323 Integration","type":"bsp"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/tags/cpci/","section":"Tags","summary":"","title":"CPCI","type":"tags"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/tags/dsp/","section":"Tags","summary":"","title":"DSP","type":"tags"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/tags/fiber-communication/","section":"Tags","summary":"","title":"Fiber Communication","type":"tags"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/tags/pci-bus/","section":"Tags","summary":"","title":"PCI Bus","type":"tags"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/tags/pci9030/","section":"Tags","summary":"","title":"PCI9030","type":"tags"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/tags/tms320f2812/","section":"Tags","summary":"","title":"TMS320F2812","type":"tags"},{"content":" VxWorks CPCI Fiber Communication Card Design and Driver Development\nHigh-speed and reliable communication is critical in modern platform inertial navigation systems. Traditional RS422 serial interfaces often become bottlenecks due to limited bandwidth and susceptibility to electromagnetic interference. To address these limitations, this article presents the design and implementation of a 6U CPCI fiber optic communication card based on the PCI9030 bridge chip and the VxWorks real-time operating system.\nThe solution combines a high-speed optical transmission channel, DSP-based protocol processing, dual-port RAM communication, and a deterministic VxWorks device driver architecture. The result is a robust embedded communication platform suitable for aerospace, industrial, and mission-critical navigation systems.\n🚀 Introduction # Inertial navigation platforms require deterministic, low-latency, and noise-resistant communication between the navigation computer and the inertial stabilization subsystem. Conventional electrical serial interfaces such as RS422 provide simplicity but suffer from:\nLimited communication throughput Susceptibility to electromagnetic interference (EMI) Reduced scalability for modern sensor fusion systems Higher latency under heavy data exchange To overcome these issues, a fiber optic communication architecture was introduced using a CompactPCI (CPCI) platform combined with the VxWorks hard real-time operating system.\nWhy CPCI and VxWorks? # CPCI Advantages # CompactPCI provides:\nRugged Eurocard mechanical structure Hot-swappable industrial design High PCI bus bandwidth Excellent vibration resistance Long lifecycle support for military and industrial applications VxWorks Advantages # VxWorks provides:\nDeterministic scheduling Low interrupt latency Fast context switching Mature PCI and driver frameworks Strong support for embedded multi-tasking systems The combination makes the platform ideal for high-reliability embedded communication systems.\n🧩 Overall Hardware Architecture # The communication card is implemented as a 6U CPCI extension board. The overall architecture consists of several tightly integrated subsystems.\nCore Components # Component Function PCI9030 PCI-to-local bus bridge TMS320F2812 DSP Protocol processing and control CY7B923 / CY7B933 Optical serializer/deserializer Dual-Port RAM Shared memory communication CPLD Timing and bus control logic FIFO Buffers Data buffering for optical transfer The architecture separates host-side PCI communication from DSP-side real-time optical processing, significantly simplifying system integration.\n🔌 PCI9030 Bridge Design # The PLX PCI9030 acts as the bridge between the CPCI bus and the local embedded subsystem.\nKey PCI9030 Features # PCI 2.2 compliant Local bus interface DMA engine Interrupt support EEPROM-based configuration Memory-mapped local address spaces PCI Configuration Space # The EEPROM stores all PCI configuration information, including:\nVendor ID Device ID Class Code Interrupt routing BAR address mapping Local bus timing parameters Local Space Mapping # The design uses Local Space 0:\nParameter Value Address Space 64 KB Bus Width 16-bit Base Address 0x00200000 Descriptor 0x00400022 This allows transparent host access to local bus peripherals and shared memory.\n🌐 Fiber Optic Communication Channel # The optical communication subsystem operates at 155 Mbps using 8B/10B encoding compliant with ANSI X3.230.\nOptical Components # Device Function CY7B923 Parallel-to-serial transmitter CY7B933 Serial-to-parallel receiver Optical Transceiver Fiber interface FIFO Buffering and clock decoupling Transmission Workflow # Send Path # DSP writes packet into FIFO DSP asserts ENA CY7B923 generates FIFO read pulses Data is encoded using 8B/10B Serialized data transmitted optically When no payload exists, synchronization idle characters are automatically inserted.\nReceive Path # Optical stream enters CY7B933 Data is decoded and written into FIFO FIFO \u0026ldquo;not empty\u0026rdquo; signal triggers DSP interrupt DSP ISR reads received data This architecture minimizes CPU overhead while maintaining deterministic throughput.\n🧠 DSP and Dual-Port RAM Communication # The TMS320F2812 DSP handles:\nCommunication protocol processing Packet parsing Interrupt management Peripheral coordination Fiber channel control Dual-Port RAM Mechanism # Dual-port RAM enables low-latency communication between:\nCPCI host CPU DSP local subsystem Mailbox registers provide interrupt signaling:\nAddress Direction 0x1FFE Host → DSP 0x1FFF DSP → Host This mechanism avoids expensive polling and enables efficient asynchronous communication.\n⚙️ CPLD Logic Design # A CPLD generates all major timing and control signals, including:\nFIFO control Address decoding Interrupt routing Local bus arbitration DSP handshake logic Benefits include:\nReduced glue logic Deterministic timing Simplified PCB routing Easier future upgrades 🖥 VxWorks Device Driver Architecture # The driver follows the standard VxWorks I/O system model.\nDriver Responsibilities # PCI device discovery Memory mapping Interrupt handling DMA/local bus access Synchronization Device abstraction Main Driver Components # Function Purpose pci9030init() PCI device initialization pci9030drv() Install driver into VxWorks I/O system pci9030create() Create device node pci9030open() Open device pci9030close() Close device pci9030read() Read local memory pci9030write() Write local memory pci9030ioctl() Device control operations pci9030isr() Interrupt service routine pci9030inthandle() Deferred interrupt processing task 🔄 Interrupt Handling Design # The driver uses the standard ISR + semaphore + worker task architecture recommended in VxWorks.\nInterrupt Service Routine # The ISR performs only minimal work:\nvoid pci9030isr(void) { if (is_our_interrupt()) { clear_interrupt(); semGive(intSem); } } Dedicated Interrupt Handling Task # void pci9030inthandle(void) { while(1) { semTake(intSem, WAIT_FOREVER); process_data(); } } Why This Design Matters # This architecture provides:\nMinimal ISR latency Deterministic interrupt response Reduced interrupt lock time Better system scalability Safer synchronization It is considered best practice for VxWorks real-time drivers.\n📦 Communication Protocol Design # Data is transferred using fixed-length 16-byte packets.\nPacket Structure # Field Size Data Count 1 byte Identifier 3 bytes Data Payload Up to 10 bytes Checksum 1 byte Identifier Examples # Identifier Function GJR Fiber read GWJ Fiber write GWA~GWD Digital outputs Checksum Mechanism # The checksum is generated using the low byte of the cumulative sum of all preceding bytes.\nAdvantages:\nSimple implementation Fast DSP calculation Minimal overhead Adequate for controlled optical links 📊 System Performance and Validation # Testing confirmed:\nReliable high-speed data transmission Stable PCI bus operation Correct interrupt handling Deterministic DSP communication Strong EMI resistance Improved navigation communication accuracy Measured Benefits Over RS422 # Feature RS422 Fiber Design Bandwidth Low High EMI Immunity Moderate Excellent Isolation Limited Complete Scalability Limited Excellent Latency Higher Lower The optical solution significantly improved overall system robustness.\n🛡 Reliability and Real-Time Considerations # Several design choices enhance reliability:\nHardware # Optical isolation FIFO buffering CPLD deterministic timing Dual-port RAM synchronization CPCI industrial backplane Software # VxWorks deterministic scheduler Deferred interrupt handling Binary semaphore synchronization Dedicated processing tasks Modular driver architecture Together, these provide a highly reliable embedded communication platform.\n🔮 Modern Perspective (2026) # While the original architecture remains technically sound, modern embedded systems would likely adopt newer technologies.\nModern Hardware Alternatives # PCIe instead of CPCI PCI FPGA-integrated PCIe endpoints 10G/25G optical Ethernet RapidIO or Aurora serial links TSN-enabled deterministic Ethernet Modern Software Enhancements # VxWorks 7 / Helix SMP support Real-Time Processes (RTPs) Driver Framework integration Device Tree-style hardware configuration Improved tracing and observability Modern Aerospace Networking # Contemporary avionics and navigation systems increasingly combine:\nFiber optics TSN (Time-Sensitive Networking) ARINC 664 / AFDX Deterministic Ethernet Redundant switched fabrics These technologies provide higher bandwidth, fault tolerance, and synchronization precision.\n✅ Conclusion # The CPCI fiber optic communication card based on the PCI9030 bridge and VxWorks successfully addresses the bandwidth and reliability limitations of traditional RS422 communication in inertial navigation systems.\nKey achievements include:\nHigh-speed 155 Mbps optical communication Deterministic VxWorks device driver architecture Efficient DSP-host communication via dual-port RAM Excellent anti-interference capability Scalable and maintainable embedded design The combination of fiber optics, CPCI architecture, DSP processing, and VxWorks real-time software provides a powerful communication platform suitable for aerospace, industrial control, and mission-critical embedded applications.\nReferences # VxWorks Device Driver Developer’s Guide PLX PCI9030 Data Sheet and Programmer Manual Cypress CY7B923/CY7B933 Documentation TMS320F2812 Technical Reference Manual CompactPCI Specification Documentation ANSI X3.230 8B/10B Encoding Standard Reference: VxWorks CPCI Fiber Communication Card Design and Driver Development\n","date":"2026-05-19","externalUrl":null,"permalink":"/bsp/vxworks-cpci-fiber-communication-card-design-and-driver-development/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks CPCI Fiber Communication Card Design and Driver Development\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eHigh-speed and reliable communication is critical in modern platform inertial navigation systems. Traditional RS422 serial interfaces often become bottlenecks due to limited bandwidth and susceptibility to electromagnetic interference. To address these limitations, this article presents the design and implementation of a \u003cstrong\u003e6U CPCI fiber optic communication card\u003c/strong\u003e based on the \u003cstrong\u003ePCI9030 bridge chip\u003c/strong\u003e and the \u003cstrong\u003eVxWorks real-time operating system\u003c/strong\u003e.\u003c/p\u003e","title":"VxWorks CPCI Fiber Communication Card Design and Driver Development","type":"bsp"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/ethernet-multicast/","section":"Tags","summary":"","title":"Ethernet Multicast","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/fast-communication-interface/","section":"Tags","summary":"","title":"Fast Communication Interface","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/fmts/","section":"Tags","summary":"","title":"FMTS","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/goose/","section":"Tags","summary":"","title":"GOOSE","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/iec-61850/","section":"Tags","summary":"","title":"IEC 61850","type":"tags"},{"content":" Real-Time IEC 61850 Fast Message Services Implementation in VxWorks\nThis paper presents the design and realization of IEC 61850 Fast Message Transmission Services (FMTS) — specifically Sampled Value Messages (SV/SMM) and GOOSE messages — on the VxWorks real-time operating system. A Fast Communication Interface (FCI) is implemented to bypass the standard TCP/IP stack, enabling deterministic, low-latency communication directly over Ethernet.\n⚡ Introduction # IEC 61850 defines high-performance communication for substation automation systems. SMM/SV and GOOSE messages demand sub-millisecond latency, which the standard VxWorks TCP/IP stack cannot satisfy. The FMTS implementation requires:\nDirect mapping from application/presentation layers to Ethernet data link. Efficient real-time task scheduling. Minimal processing overhead to meet \u0026lt;3 ms transmission requirements. This work focuses on designing a Fast Communication Interface (FCI), implementing subscriber/publisher tasks, and optimizing real-time performance.\n🛠 Analysis of Fast Message Transmission Services (FMTS) # 1.1 Abstract Communication Service Interface (ACSI) # ACSI provides protocol-independent service definitions. FMTS messages use a publisher/subscriber model:\nSMM (SV): Periodic, fixed datasets, high-frequency sampled values. GOOSE (SGM): Event-driven with richer control parameters, fast retransmission upon events. 1.2 Specific Communication Service Mapping (SCSM) # FMTS maps messages directly to Ethernet frames:\nUses dedicated multicast addresses and VLAN priority tagging. APDUs/ASDUs encoded via ASN.1 BER. Supports IEC 61850-9-1 simplified or 9-2 full sampled values. GOOSE messages include control block references (GoCBRef), sequence numbers (StNum, SqNum), and Time Allowed to Live (TAL). 🖥 VxWorks Implementation # 2.1 Network Stack and MUX Layer # VxWorks uses MUX/END driver model. Standard applications access TCP/IP via sockets. FMTS bypasses TCP/IP using a high-priority MUX protocol for deterministic delivery. 2.2 Fast Communication Interface (FCI) # FCI provides direct Ethernet access for SMM/GOOSE:\nfciOpen() / muxBind() — Registers interface in MUX with MUX_PROTO_SNARF. fciMCastAddrSet() — Configures multicast addresses. fciSend() — Builds and sends Ethernet frames (EtherType 0x88B8/0x88BA). fciRcvRtn() — Receive callback for APDU validation and shared memory updates. High task priorities and minimal FCI processing ensure low-latency delivery. 2.3 Application Tasks # SRT (tSavReceiveTask) — SV subscriber decoding APDUs, updating shared memory. GRT (tGooseReceiveTask) — GOOSE subscriber managing sequence numbers, TAL timeouts, and retransmissions. GST / GSF (tGooseSendTask + fGooseSend) — GOOSE publisher with periodic and fast retransmission strategies. Example pseudocode (GOOSE receive):\nvoid GRT_Task() { while(1) { wait_for_signal(); decode_GoCBRef_TAL_StNum_SqNum(...); if (isValidNewEvent()) { decode_AllData(); write_to_shared_memory(); release_semaphore_to_protection_app(); } else if (isRetransmission_or_Test()) { update_SqNum_and_timing(); } else { handle_counter_error(); } } } 📈 Real-Time Optimization Techniques # Bind FCI to MUX_PROTO_SNARF for top priority. Assign high task priorities (e.g., GST=38, GRT=39, SRT=40). Shared memory + binary semaphores for low-latency data exchange. Pre-encode static APDU fields, updating only dynamic content. Configure END drivers in DMA mode. Test Results:\nScenario Max (μs) Min (μs) Avg (μs) Baseline GOOSE 425 425 425 + Report 450 425 425 + Model Browsing 575 425 550 + FTP 450 425 425 Lower Priority Load 1600 775 1050 All measured times remain well below 3 ms requirement. No packet loss observed.\n✅ Conclusion # The FCI + task-based architecture enables real-time SMM/GOOSE messaging on VxWorks:\nDeterministic Ethernet-based communication bypassing TCP/IP. High-priority tasks ensure low-latency handling. Shared memory provides fast data exchange to protection applications. Validated under realistic substation loads. This design supports protection, interlocking, and merging unit communication within IEC 61850-compliant digital substations.\n🔮 Modern Perspective (2026) # VxWorks 7 / Helix with TSN support for sub-microsecond synchronization. Containerized RTPs for modular deployment. Integrated OPC UA and PTP (IEEE 1588) time synchronization. Advanced debugging with Wind River Workbench + System Viewer. Support for IEC 61850-9-2 LE profiles in process bus applications. References\nIEC 61850 Series Standards. Research on GOOSE/SV real-time implementations. VxWorks Network and Driver Development Documentation. Real-Time IEC 61850 Fast Message Services Implementation in VxWorks ","date":"2026-05-16","externalUrl":null,"permalink":"/industries/real-time-iec-61850-fast-message-services-implementation-in-vxworks/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eReal-Time IEC 61850 Fast Message Services Implementation in VxWorks\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eThis paper presents the design and realization of \u003cstrong\u003eIEC 61850 Fast Message Transmission Services (FMTS)\u003c/strong\u003e — specifically Sampled Value Messages (SV/SMM) and GOOSE messages — on the \u003cstrong\u003eVxWorks\u003c/strong\u003e real-time operating system. A \u003cstrong\u003eFast Communication Interface (FCI)\u003c/strong\u003e is implemented to bypass the standard TCP/IP stack, enabling deterministic, low-latency communication directly over Ethernet.\u003c/p\u003e","title":"Real-Time IEC 61850 Fast Message Services Implementation in VxWorks","type":"industries"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/sampled-values/","section":"Tags","summary":"","title":"Sampled Values","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/scsm/","section":"Tags","summary":"","title":"SCSM","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/substation-automation/","section":"Tags","summary":"","title":"Substation Automation","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/abnormal-restart/","section":"Tags","summary":"","title":"Abnormal Restart","type":"tags"},{"content":" Advanced VxWorks 7 / Helix Abnormal Restart Troubleshooting and Recovery\nAbnormal restarts in VxWorks systems pose serious challenges to the availability of safety-critical applications, including railway signaling, industrial automation, and aerospace control systems. Combining field-tested troubleshooting techniques with modern features in VxWorks 7 and Helix, this guide provides a systematic methodology for detecting, diagnosing, and preventing unexpected system resets while enhancing post-mortem analysis and long-term system reliability.\n🛠 Classic Troubleshooting Techniques # Application-Level Persistent Tracing # Insert persistent logging at critical points in tasks and ISRs to record runtime behavior. Using non-volatile storage ensures data survives reboots, enabling root-cause analysis.\nExample Case: A rarely executed branch with an uninitialized variable caused memory corruption, detectable only via persistent logs.\nTask Exception Tracing # Capture detailed call stacks and register states during task exceptions:\nvoid excSysHandler(int tid, int vecNum, ESF1 *pESf) { REG_SET regSet; if (taskRegsGet(tid, \u0026amp;regSet) != ERROR) { trcStack(\u0026amp;regSet, (FUNCPTR)dbgPrintFun, tid); taskRegsShow(tid); } } void traceInit(void) { int fd = open(\u0026#34;/ata0/exclog.txt\u0026#34;, O_RDWR | O_CREAT, 0644); ioGlobalStdSet(2, fd); excHookAdd((FUNCPTR)excSysHandler); } Interrupt Exception Tracing # Redirect sysExcMsg to persistent memory, then analyze after reboot using shell commands (d) and objdump to identify interrupt-driven faults.\nStack Monitoring and Overflow Prevention # Utilize checkStack() to detect stack overflows Tune ROOT_STACK_SIZE and ISR_STACK_SIZE Enable dedicated interrupt stacks via intStackEnable(1) for critical ISRs Differential and Stress Testing # Create minimal-difference builds and run accelerated soak tests to isolate intermittent bugs, such as floating-point precision errors or scheduler anomalies.\n⚡ Modern Techniques in VxWorks 7 / Helix # Unified Logging and Event Tracing # logLib for centralized, configurable logging Helix Event Tracing captures system events with precise timestamps RTP logging allows user-mode applications to participate in centralized trace collection Persistent logging ensures crash data retention for root-cause analysis Post-Mortem Core Dumps and Offline Analysis # Core dumps capture system state at failure time, including task states, memory partitions, and symbol information:\n#define INCLUDE_CORE_DUMP #define CORE_DUMP_COMPRESS #define CORE_DUMP_TO_FLASH #define CORE_DUMP_MAX_SIZE (16*1024*1024) Analyze dumps offline with Wind River Workbench or Helix Debug Tools for advanced post-mortem diagnostics.\nSystem Viewer and Real-Time Runtime Analysis # Visualize tasks, memory usage, CPU load, and object states in real-time Trace execution paths leading to exceptions Health Monitor tracks deadlines, resource utilization, and anomalous task behavior Memory Protection and Partitioning # Enable MMU write-protection for program text and vector tables Deploy applications in protected RTPs Use ARINC 653-style safety partitions to isolate faults and prevent cascading failures #define INCLUDE_MMU_BASIC #define INCLUDE_MMU_FULL #define VM_PAGE_SIZE 4096 #define USER_TEXT_PROTECT TRUE #define VECTOR_TABLE_PROTECT TRUE Advanced Watchdog and Supervision Strategies # Combine hardware watchdogs with software-based wdLib timers Monitor task responsiveness and system health Integrate Helix supervision frameworks for multi-level fault detection Use heartbeat signals and supervisor tasks to automatically reset stalled components 📊 Comparison: Classic VxWorks vs VxWorks 7 / Helix # Feature Classic VxWorks (5.5/6.x) VxWorks 7 / Helix Exception Handling excHookAdd(), sysExcMsg Enhanced + Core Dumps + Event Tracing Debugging Tornado + Shell Workbench + System Viewer + Helix Trace Memory Protection Basic MMU Full MMU + RTP Protection + Safety Partitioning Logging Custom + logLib Unified Framework + Persistent Logging Post-Mortem Analysis Limited Rich Core Dumps + Symbol Resolution Observability i, tt, checkStack Real-time System Viewer + Health Monitor Isolation Kernel-mode heavy Strong Kernel/User + Partitioning Recovery Manual or ad-hoc resets Automated with Hardware + Software Watchdogs ✅ Recommended Best Practices # Enable MMU protection and run applications in RTPs for strong isolation Configure persistent core dumps and offload to flash or network storage Implement unified, persistent logging integrated with Health Monitor Apply static analysis tools (Coverity, Polyspace) in CI/CD pipelines Combine hardware and multi-level software watchdogs for proactive recovery Perform regular soak testing with differential builds to detect subtle bugs Document and version-control all exception handlers and trace utilities 🖥 Ready-to-Use Exception Logging Template # #include \u0026lt;excLib.h\u0026gt; #include \u0026lt;coreDumpLib.h\u0026gt; #include \u0026lt;logLib.h\u0026gt; void advancedExcHandler(int tid, int vecNum, ESF1 *pESf) { REG_SET regSet; if (taskRegsGet(tid, \u0026amp;regSet) != ERROR) { logMsg(\u0026#34;=== EXCEPTION === TID=%d, Vector=0x%x\\n\u0026#34;, tid, vecNum); trcStack(\u0026amp;regSet, (FUNCPTR)logMsg, tid); taskRegsShow(tid); } coreDumpGenerate(CORE_DUMP_USER, CORE_DUMP_OPTION_COMPRESS); } void exceptionInit(void) { excHookAdd((FUNCPTR)advancedExcHandler); coreDumpInit(); coreDumpPathSet(\u0026#34;/flash/core/\u0026#34;); logMsg(\u0026#34;Exception handler and core dump initialized.\\n\u0026#34;); } Call exceptionInit() during system startup to enable advanced exception handling, persistent logging, and automated post-mortem recovery.\nBy combining classic field-tested approaches with modern VxWorks 7 / Helix capabilities, engineers can systematically diagnose, prevent, and recover from abnormal restarts, ensuring maximum availability and reliability in safety-critical embedded systems.\n","date":"2026-05-16","externalUrl":null,"permalink":"/training/advanced-vxworks-7-helix-abnormal-restart-troubleshooting-and-recovery/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eAdvanced VxWorks 7 / Helix Abnormal Restart Troubleshooting and Recovery\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eAbnormal restarts in \u003cstrong\u003eVxWorks systems\u003c/strong\u003e pose serious challenges to the availability of safety-critical applications, including railway signaling, industrial automation, and aerospace control systems. Combining field-tested troubleshooting techniques with modern features in \u003cstrong\u003eVxWorks 7 and Helix\u003c/strong\u003e, this guide provides a systematic methodology for detecting, diagnosing, and preventing unexpected system resets while enhancing post-mortem analysis and long-term system reliability.\u003c/p\u003e","title":"Advanced VxWorks 7 / Helix Abnormal Restart Troubleshooting and Recovery","type":"training"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/core-dump/","section":"Tags","summary":"","title":"Core Dump","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/debugging-tools/","section":"Tags","summary":"","title":"Debugging Tools","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/exception-handling/","section":"Tags","summary":"","title":"Exception Handling","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/helix/","section":"Tags","summary":"","title":"Helix","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/memory-protection/","section":"Tags","summary":"","title":"Memory Protection","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/real-time-os/","section":"Tags","summary":"","title":"Real-Time OS","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/watchdog/","section":"Tags","summary":"","title":"Watchdog","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/16c554/","section":"Tags","summary":"","title":"16C554","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/mpc860/","section":"Tags","summary":"","title":"MPC860","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/qoriq/","section":"Tags","summary":"","title":"QorIQ","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/scc/","section":"Tags","summary":"","title":"SCC","type":"tags"},{"content":" Serial Bus Design for MPC860 Processor under VxWorks with Modern Comparison\nThis article presents a detailed serial bus design for the MPC860 (PowerPC860) processor under VxWorks, including native SCC/SMC channels, multi-port expansion using the TI 16C554 UART, and a robust hardware watchdog solution. A comparison with modern Power Architecture designs (QorIQ) is included to highlight evolution in embedded serial communication systems.\n🛠 MPC860 Communication Capabilities # The MPC860 integrates a Communication Processor Module (CPM) with:\n2 SMC channels — supporting UART, SPI, I2C 4 SCC channels — high-performance UART/HDLC/Ethernet support Built-in Baud Rate Generators Dual-Port RAM (DPRAM) for buffer management CPM-driven interrupt handling These features enable scalable and flexible serial communication for aerospace, industrial, and telecom applications.\n⚡ Watchdog Circuit Design for Boot Monitoring # The MPC860 boot under VxWorks typically takes ~4 seconds, exceeding the 1.6s default of common watchdogs like MAX691. A crystal-derived hardware solution ensures reliable monitoring:\nCrystal oscillator generates base clock Frequency divider produces ~6s period square wave High phase outputs crystal clock to WDI Low phase outputs SCC activity signal to WDI Watchdog triggers system reset via PRORESET if activity ceases Programmable Logic Implementation (Verilog):\nmodule DIV_FREQ ( input 5MHZ, output reg SWITCH_NODE ); always @(posedge 5MHZ) begin // Frequency division logic to create ~6s period end always @(SWITCH_NODE) begin if (SWITCH_NODE == 1\u0026#39;b1) WDI \u0026lt;= 5MHZ; // Crystal clock during high phase else WDI \u0026lt;= SCC_ENABLE; // SCC activity signal during low phase end endmodule This approach provides long-term stability without CPU intervention.\n🔧 Native SCC/SMC Software Design in VxWorks # VxWorks BSP and SIO framework provide structured support for MPC860 serial channels.\nKey Data Structure: PPC860SCC_CHAN # typedef struct ppc860Scc_chan { SIO_DRV_FUNCS *pDrvFuncs; void *getTxArg; void *putRcvArg; VINT16 int_vec; VINT16 channelMode; int baudRate; int clockRate; int bgrNum; SCC_UART_DEV uart; } PPC860SCC_CHAN; SCC3 Hardware Initialization Example # void SerialScc3HwInit(void) { PPC860SCC_CHAN ppc860SccChan; ppc860SccChan.clockRate = 40000000; // 40 MHz ppc860SccChan.bgrNum = 3; // BRG3 ppc860SccChan.uart.txBufBase = (UINT8*)(MPC860_DPRAM_BASE + TX_BUFFER_SCC3); ppc860SccChan.uart.rxBufBase = (UINT8*)(MPC860_DPRAM_BASE + RX_BUFFER_SCC3); ppc860SccChan.uart.pSccReg = (SCC_REG*)MPC860_GSMR_L3(...); ppc860SccDevInit(\u0026amp;ppc860SccChan); intConnect(INT_VEC_SCC3, (VOIDFUNCPTR)ppc860SccInt, (int)\u0026amp;ppc860SccChan); sprintf(devName, \u0026#34;%s%d\u0026#34;, \u0026#34;/yCo/\u0026#34;, 3); ttyDevCreate(devName, (SIO_CHAN*)\u0026amp;ppc860SccChan, 512, 512); } ⚙ Multi-Port Expansion with TI 16C554 # For systems needing more than six serial ports, the TI 16C554 quad UART is used:\nConnected via MPC860 lower data bus (little-endian) CS5 as base chip select, address lines A25/A26 for channel decoding Interrupts INTA-INTD mapped to IRQ4-IRQ7 Example Initialization (Channel A):\n#define 16554A_BASE_ADDR CS5_BASE_ADDRESS + 0x00 void SerialPort_initA(void) { UCHAR *addr = (UCHAR*)16554A_BASE_ADDR; *(addr + 3) = 0x0B; // 8N1, odd parity *(addr + 2) = 0x87; // FIFO enable *(addr + 3) = 0x8B; // Baudrate 38400 intEnable(4); // Enable IRQ4 } Other channels follow similar configuration with offset addresses.\n📈 Modern Comparison: QorIQ and Advanced Power Architecture # Modern Power Architecture processors (e.g., NXP QorIQ) provide:\nIntegrated multi-UART modules supporting higher speeds and more channels Flexible interrupt routing and DMA-based serial transfers Native PCIe and Ethernet connectivity reducing reliance on discrete UART expansion Hardware watchdogs integrated in SoC for robust boot monitoring Software frameworks (Linux RT, VxWorks, or QNX) for rapid serial port configuration Key Advantages over MPC860 Design:\nFeature MPC860 + 16C554 Modern QorIQ / SoC UART Channels 6 native + 4 per TI chip 8–16 integrated Expansion Complexity Discrete hardware \u0026amp; IRQ On-chip DMA \u0026amp; IRQ mux Watchdog Integration External MAX691 On-chip, flexible timers Bus Bandwidth 32-bit local bus PCIe/Ethernet high-speed Software Initialization BSP + SIO framework RTOS drivers \u0026amp; HAL This evolution reduces board complexity, improves reliability, and supports higher throughput.\n✅ Conclusion # The MPC860 provides a solid foundation for multi-channel serial communication under VxWorks, enhanced by TI 16C554 expansion and robust hardware watchdogs. Modern Power Architecture platforms like QorIQ integrate many of these functions on-chip, simplifying design while maintaining reliability and scalability in industrial and aerospace embedded systems.\nDesign principles from MPC860 remain relevant for engineers handling legacy systems or designing robust serial communication frameworks.\nReference: Serial Bus Design for MPC860 Processor under VxWorks with Modern Comparison\n","date":"2026-05-16","externalUrl":null,"permalink":"/training/serial-bus-design-for-mpc860-processor-under-vxworks-with-modern-comparison/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eSerial Bus Design for MPC860 Processor under VxWorks with Modern Comparison\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eThis article presents a detailed \u003cstrong\u003eserial bus design\u003c/strong\u003e for the \u003cstrong\u003eMPC860 (PowerPC860)\u003c/strong\u003e processor under \u003cstrong\u003eVxWorks\u003c/strong\u003e, including native SCC/SMC channels, multi-port expansion using the \u003cstrong\u003eTI 16C554 UART\u003c/strong\u003e, and a robust hardware watchdog solution. A comparison with modern Power Architecture designs (QorIQ) is included to highlight evolution in embedded serial communication systems.\u003c/p\u003e","title":"Serial Bus Design for MPC860 Processor under VxWorks with Modern Comparison","type":"training"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/smc/","section":"Tags","summary":"","title":"SMC","type":"tags"},{"content":" Preventing the Year 2038 Problem in Embedded Systems with VxWorks\nIn Back to the Future, time travel is thrilling—but for embedded systems, rolling the clock back to 1901 is anything but fun.\nOn January 19, 2038, systems relying on 32-bit time will encounter the Year 2038 Problem, where clocks overflow and revert to a negative counter. Without mitigation, this can cause data corruption, system crashes, and unpredictable failures in satellites, industrial robots, or medical devices.\nFortunately, VxWorks® addresses this issue, providing long-term stability for mission-critical applications.\n⏱ What Is the Year 2038 Problem? # Many embedded systems store time as a 32-bit signed integer, counting seconds since January 1, 1970 (Unix Epoch):\nMaximum value: 2,147,483,647 seconds → 3:14:07 UTC on Jan 19, 2038. Overflow: the counter flips negative, making the system “think” it’s 1901. Similar to the Y2K problem, which required global fixes due to two-digit year formats, the 2038 issue demands proactive solutions.\n⚠️ Why Embedded Systems Are Vulnerable # Embedded systems often operate for decades with minimal updates and depend on precise timing. At-risk platforms include:\nSatellites and aerospace systems Industrial automation and robotics Medical devices and healthcare equipment For these systems, time reliability is non-negotiable.\n✅ VxWorks Solutions for the 2038 Problem # VxWorks 7 # Wind River built full 64-bit timestamp support into VxWorks 7:\nKernel and user space use 64-bit time_t. Maintains backward compatibility with legacy APIs. Supports both 32-bit and 64-bit hardware seamlessly. Prevents overflow, enabling safe operation well beyond 2038. VxWorks 6.x Updates # For those still on 6.x, RCPL8 for VxWorks 6.9.4.12 adds:\n2038 fixes for critical components. Migration guides for transitioning to VxWorks 7. 🛠 Developer Checklist # To ensure systems remain future-proof:\n✅ Check code → Are any 32-bit time_t types still in use?\n✅ Verify system version → Upgrade to VxWorks 7 or apply 6.x patches.\n✅ Plan for long-term support → Critical for decades-long deployments.\n✅ Consult Wind River → Utilize migration tools and expert guidance.\n🔮 Future-Proof Embedded Reliability # The Year 2038 Problem is real, but with VxWorks, it is fully manageable. By adopting Wind River’s updates, developers can ensure systems remain stable, secure, and reliable well into the future.\nTime moves forward—but with VxWorks, your embedded system will never fall behind.\nReference: Solving the Year 2038 Problem in Embedded Systems with VxWorks\n","date":"2026-05-16","externalUrl":null,"permalink":"/app/solving-the-year-2038-problem-in-embedded-systems-with-vxworks/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003ePreventing the Year 2038 Problem in Embedded Systems with VxWorks\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eIn \u003cem\u003eBack to the Future\u003c/em\u003e, time travel is thrilling—but for embedded systems, rolling the clock back to \u003cstrong\u003e1901\u003c/strong\u003e is anything but fun.\u003c/p\u003e","title":"Solving the Year 2038 Problem in Embedded Systems with VxWorks","type":"app"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/time-overflow-bug/","section":"Tags","summary":"","title":"Time Overflow Bug","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"permalink":"/tags/year-2038-problem/","section":"Tags","summary":"","title":"Year 2038 Problem","type":"tags"},{"content":"","date":"2026-05-15","externalUrl":null,"permalink":"/tags/firmware-update/","section":"Tags","summary":"","title":"Firmware Update","type":"tags"},{"content":"","date":"2026-05-15","externalUrl":null,"permalink":"/tags/flash-management/","section":"Tags","summary":"","title":"Flash Management","type":"tags"},{"content":"","date":"2026-05-15","externalUrl":null,"permalink":"/tags/industrial-systems/","section":"Tags","summary":"","title":"Industrial Systems","type":"tags"},{"content":"","date":"2026-05-15","externalUrl":null,"permalink":"/tags/network-boot/","section":"Tags","summary":"","title":"Network Boot","type":"tags"},{"content":"","date":"2026-05-15","externalUrl":null,"permalink":"/tags/railway-systems/","section":"Tags","summary":"","title":"Railway Systems","type":"tags"},{"content":"","date":"2026-05-15","externalUrl":null,"permalink":"/tags/remote-upgrade/","section":"Tags","summary":"","title":"Remote Upgrade","type":"tags"},{"content":" VxWorks Remote Firmware Replacement System Design Guide\nModern industrial control platforms increasingly rely on distributed embedded architectures composed of multiple network-connected processing modules. In railway and locomotive systems, these modules are commonly deployed inside modular card-cage platforms where each plug-in board independently executes real-time workloads under the VxWorks operating system.\nTraditional firmware maintenance methods for these systems are expensive, labor-intensive, and operationally disruptive. Replacing software often requires physical disassembly, specialized emulators, and direct access to each individual board.\nThis article explores the design of a practical remote program replacement system for VxWorks-based embedded platforms. By leveraging Ethernet communication, UDP socket programming, custom transfer protocols, and dual-bank FLASH layouts, the solution enables secure and efficient network-based firmware upgrades across multiple plug-ins simultaneously.\n🚆 Embedded Card-Cage Architecture # The target system is designed around a modular locomotive control platform composed of several Ethernet-connected plug-in boards.\nEach plug-in contains its own processor, memory subsystem, and dedicated VxWorks runtime environment.\nHardware Platform # The reference implementation uses the following hardware configuration:\nCPU: Freescale MPC5125 (Power Architecture) Memory: 128 MB RAM FLASH: 16 MB external FLASH Interfaces: Multiple UART controllers CAN bus Dual Ethernet FEC controllers The overall system architecture consists of:\nOne switch plug-in responsible for external network connectivity Four to five application plug-ins Internal Ethernet switching between all modules External wired or wireless maintenance access The resulting topology allows a maintenance workstation to remotely communicate with every board inside the chassis through a single network entry point.\n🌐 Network-Based Firmware Replacement Workflow # The firmware replacement system is divided into three major software components:\nPC-side management application VxWorks network communication module Application loading and boot management module This separation simplifies maintenance and improves portability across different embedded hardware platforms.\nSystem Communication Flow # The upgrade process follows a staged workflow:\nMaintenance PC discovers all plug-ins through UDP broadcast Devices authenticate incoming requests Firmware image is packetized and transmitted Missing packets are retransmitted if necessary Entire image integrity is validated using CRC Verified image is programmed into FLASH System configuration is updated Target device reboots into the new application Because the process operates entirely over Ethernet, technicians can update multiple modules simultaneously without physically opening the equipment enclosure.\n💾 Dual-Bank FLASH Architecture # One of the most important reliability features in the design is the dual-application FLASH layout.\nInstead of overwriting the currently running application directly, the system maintains independent execution regions to guarantee recovery capability in case of failed updates.\nFLASH Partition Layout # The FLASH memory is divided into several logical regions:\nFLASH Region Purpose Bootloader Area Initial startup and hardware initialization Application A Area Recovery or maintenance firmware Application B Area Primary operational firmware File Area Temporary storage for downloaded images Configuration Area Boot parameters and metadata This structure provides robust fault tolerance while minimizing the risk of rendering devices unbootable during upgrades.\nBoot Sequence Logic # During power-up, the bootloader performs several validation checks before transferring execution control.\nThe sequence operates as follows:\nBootloader initializes hardware and networking Application B integrity is validated If validation succeeds, boot into Application B If validation fails, boot into Application A recovery firmware Maintenance firmware accepts new image downloads Verified image is copied into Application B region Boot configuration is updated Device reboots into the new operational image This recovery-oriented design significantly improves field reliability in harsh industrial environments where power interruptions and unstable network conditions are common.\n📡 UDP-Based Communication Design # The remote update mechanism uses UDP sockets combined with a lightweight custom application-layer protocol.\nAlthough TCP provides built-in reliability, UDP was selected because of its lower overhead, simpler implementation characteristics, and predictable behavior inside closed industrial Ethernet environments.\nDevice Discovery # The discovery mechanism uses UDP broadcast packets.\nThe maintenance workstation broadcasts a discovery request, and all plug-ins respond with:\nDevice identifiers Firmware versions Board information Status metadata Heartbeat packets are periodically exchanged to monitor connection health. If several heartbeat intervals are missed consecutively, the session is considered disconnected.\nAuthentication Mechanism # Before accepting firmware downloads, the target board performs authentication verification.\nThe process includes:\nEncrypted key transmission Target-side credential validation Authorization gating before upgrade initiation This prevents unauthorized firmware replacement attempts on operational equipment.\nReliable File Transfer # Because UDP does not inherently guarantee delivery, reliability is implemented at the application layer.\nThe firmware image is divided into fixed-size packets, typically no larger than 1 KB.\nEach packet contains:\nSequence number Packet length CRC checksum Payload data The receiver tracks missing packets and explicitly requests retransmission when gaps are detected.\nAfter all packets are received:\nFull-image CRC validation is performed FLASH programming begins only after successful verification Invalid images are discarded safely This approach balances performance and reliability while avoiding the complexity of full TCP session management.\n⚙️ VxWorks Socket Programming Design # The target-side communication module is implemented using the standard VxWorks socket API.\nCore responsibilities include:\nUDP socket initialization Broadcast reception Packet parsing Retransmission handling CRC verification FLASH write coordination The modular architecture allows the communication layer to remain largely independent from the application runtime itself.\nAdvantages of UDP in Embedded VxWorks Systems # UDP remains particularly effective in embedded industrial systems because it offers:\nMinimal protocol overhead Low memory consumption Predictable timing behavior Easier integration into RTOS task models Reduced connection-management complexity For localized Ethernet environments with controlled network topology, UDP-based protocols often outperform heavier transport-layer alternatives.\n🖥️ PC-Side Management Application # The host-side application is designed using an object-oriented architecture, typically implemented in C++.\nIts responsibilities include:\nDevice discovery Authentication handling Firmware image conversion Packet transmission Status monitoring User interface management Core Software Modules # The application is divided into several major classes.\nFile Conversion Module # Responsible for:\nConverting HEX images into BIN format Appending integrity metadata Preparing packetized transfer data Encryption and Authentication Module # Handles:\nKey generation Encryption logic Authentication session management Network Communication Module # Implements dual-threaded communication:\nDedicated sender thread Dedicated receiver thread This prevents UI blocking and improves transfer responsiveness.\nPacketization Module # Responsible for:\nSplitting firmware into packets Sequence tracking Retransmission coordination CRC generation User Interface Layer # Provides:\nDevice management Upgrade status monitoring Error reporting Batch upgrade operations The result is a practical one-click firmware replacement workflow capable of upgrading multiple plug-ins simultaneously.\n🔒 Reliability and Safety Features # Compared with traditional emulator-based maintenance methods, the network replacement system dramatically improves operational efficiency and deployment flexibility.\nFeature Traditional Method Network Replacement System Hardware Cost High Low Field Maintenance Requires disassembly Fully remote Upgrade Scope Single board only Multi-board simultaneous updates Reliability Limited rollback capability Dual-bank recovery architecture Security Minimal Authentication + CRC verification Maintenance Efficiency Slow Rapid deployment The dual-bank architecture combined with application-level reliability checks substantially reduces upgrade risk in mission-critical systems.\n🏭 Industrial Applicability # Although originally designed for locomotive equipment, the architecture generalizes well to many embedded domains.\nTypical deployment scenarios include:\nRailway control systems Industrial automation Energy infrastructure Rugged edge computing Distributed embedded gateways Harsh-environment control systems The lightweight UDP-based design is especially useful in systems with constrained bandwidth, deterministic timing requirements, or legacy RTOS environments.\n🔮 Modernization Opportunities # While the original architecture remains highly effective, modern embedded Linux and RTOS ecosystems provide additional upgrade strategies that can further improve maintainability and security.\nPotential enhancements include:\nSecure boot with signed firmware validation HTTPS-based firmware distribution WebSocket management interfaces MQTT telemetry integration RAUC-style atomic update frameworks Containerized application deployment Yocto or Buildroot integration pipelines However, many industrial VxWorks systems continue to favor lightweight custom protocols because of their deterministic behavior, low resource consumption, and long-term maintainability.\n📘 Conclusion # The VxWorks-based remote program replacement system demonstrates how careful protocol design and robust FLASH management can dramatically improve embedded maintenance workflows.\nBy combining UDP communication, application-layer reliability mechanisms, authentication validation, and dual-bank recovery architecture, the system achieves:\nSafe remote firmware deployment Reduced maintenance cost Faster field servicing Improved operational reliability Simplified multi-board management For embedded engineers working with distributed VxWorks platforms, the design remains a strong reference architecture for building practical and resilient network-based firmware update systems in industrial and real-time environments.\nReference: VxWorks Remote Firmware Replacement System Design Guide\n","date":"2026-05-15","externalUrl":null,"permalink":"/app/vxworks-remote-firmware-replacement-system-design-guide/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Remote Firmware Replacement System Design Guide\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eModern industrial control platforms increasingly rely on distributed embedded architectures composed of multiple network-connected processing modules. In railway and locomotive systems, these modules are commonly deployed inside modular card-cage platforms where each plug-in board independently executes real-time workloads under the VxWorks operating system.\u003c/p\u003e","title":"VxWorks Remote Firmware Replacement System Design Guide","type":"app"},{"content":" Building an MVB Monitoring and Early-Warning Terminal with VxWorks and FPGA\nModern rail transit systems increasingly rely on highly interconnected communication networks for control, diagnostics, and safety-critical coordination. As railway systems become more intelligent and network-centric, cybersecurity risks targeting train communication infrastructure continue to grow.\nThis article presents the design and implementation of a Multifunction Vehicle Bus (MVB) Monitoring and Early-Warning Terminal based on VxWorks 5.5 and FPGA hardware acceleration. The system performs passive, real-time monitoring of MVB traffic, detects abnormal behavior, and generates early warnings without interfering with normal train operation.\nThe design combines:\nFPGA-based high-speed frame decoding Deterministic real-time processing using VxWorks Multi-layer anomaly detection Industrial-grade reliability suitable for rail environments 🚄 Introduction to MVB and Train Communication Security # The Train Communication Network (TCN), standardized under IEC 61375, forms the communication backbone of many modern railway systems.\nTCN consists of two major buses:\nBus Purpose WTB (Wire Train Bus) Inter-vehicle communication MVB (Multifunction Vehicle Bus) Intra-vehicle real-time control MVB is widely used for:\nTraction control Door systems Braking systems Diagnostic communication Sensor and actuator coordination Because MVB was originally designed for deterministic control rather than cybersecurity, it lacks many modern protection mechanisms.\n⚠️ Security Challenges in MVB Networks # The MVB protocol contains several inherent weaknesses.\nKey Security Limitations # Weakness Impact No encryption Traffic can be intercepted No authentication Devices can be spoofed No handshake mechanism Easy replay attacks Plaintext Manchester encoding Traffic analysis possible Deterministic timing Predictable communication patterns These limitations expose railway control systems to threats including:\nEavesdropping Frame injection Replay attacks Bus flooding Device impersonation Denial-of-service attacks The monitoring terminal described here addresses these risks through passive monitoring and anomaly analysis.\n🧠 MVB Protocol Overview # MVB is a deterministic fieldbus optimized for real-time process control.\nCore Characteristics # Feature Specification Data Rate 1.5 Mbps Encoding Manchester II Communication Model Master-slave Standard IEC 61375 Timing Deterministic Supported Physical Media # Medium Description ESD Electrical Short Distance (RS485-based) EMD Electrical Medium Distance OGF Optical Fiber Frame Structure # MVB communication uses:\nMaster Frames Slave Frames Start Delimiters End Delimiters CRC/checksum fields The start delimiters intentionally violate Manchester encoding rules to assist synchronization.\n🏗️ System Architecture Overview # The monitoring terminal is connected passively to the MVB network, typically at a bus segment endpoint.\nThe architecture separates low-level frame decoding from high-level protocol analysis.\n⚙️ Hardware Architecture # Major Hardware Components # Component Function Xilinx XC6SLX100 FPGA Real-time MVB decoding Freescale P2020 Protocol analysis and detection DDR3 Memory Runtime buffering Flash Storage Firmware and configuration Ethernet Interface Alarm reporting RS485 Interface External communication Conceptual Data Flow # MVB Bus │ ▼ FPGA Decoder │ ├── Manchester Decoding ├── Delimiter Detection ├── Error Checking └── FIFO Buffering │ ▼ Local Bus Interface │ ▼ P2020 Processor (VxWorks) │ ├── Protocol Parsing ├── Traffic Analysis ├── Anomaly Detection └── Alert Generation │ ▼ Ethernet / RS485 Monitoring System This division significantly reduces CPU overhead while maintaining deterministic behavior.\n🔌 FPGA-Based MVB Decoding Engine # The FPGA performs all timing-critical operations at line rate.\n⚡ Why FPGA Acceleration Matters # At 1.5 Mbps Manchester-encoded signaling, precise timing is essential.\nFPGA implementation provides:\nParallel frame processing Deterministic timing Hardware-level synchronization Minimal interrupt latency Reduced CPU utilization The CPU is therefore free to focus on higher-level analysis tasks.\n🧩 FPGA Decoder Modules # The decoder was implemented using Verilog HDL and consists of several major blocks.\nDecoder Functional Units # Module Function Delimiter Detector Identifies frame boundaries Manchester Decoder Converts encoded bitstream Synchronization Timer Maintains timing alignment Error Detector Detects malformed frames FIFO Buffer Stores decoded frames Error Conditions Detected # The FPGA performs early filtering for:\nManchester violations Invalid delimiters Length mismatches CRC/checksum failures Synchronization errors This reduces unnecessary software processing overhead.\n🖥️ Main Control Unit Based on VxWorks # The upper-layer analysis system runs on a Freescale P2020 dual-core PowerPC processor using VxWorks 5.5.\nWhy VxWorks Was Chosen # VxWorks provides:\nDeterministic scheduling Low interrupt latency Mature BSP support Reliable multitasking Industrial-grade stability These characteristics are especially important in safety-critical transportation environments.\n🔄 FPGA-to-CPU Communication # Decoded frames are transferred from FPGA FIFO buffers to the P2020 over a local bus interface.\nCommunication Workflow # FPGA decodes incoming frame Frame stored in FIFO FPGA triggers interrupt VxWorks ISR activates Driver copies frame into ring buffer Parsing tasks process the data This interrupt-driven architecture minimizes polling overhead and improves responsiveness.\n🛠️ VxWorks Software Architecture # The software stack follows a layered modular design.\n📦 BSP and Driver Layer # The Board Support Package includes:\nMVB driver Interrupt handlers Ring buffer management FIFO communication APIs Core BSP APIs # Function Purpose MVBRecvBufSet() Configure interrupt trigger depth MVBBufRead() Read decoded frames MVBBufSize() Query buffered data size Example Ring Buffer Structure # typedef struct { UINT8 *buffer; UINT32 head; UINT32 tail; UINT32 size; } MVB_RING_BUFFER; Efficient buffering is critical during traffic bursts or attack scenarios.\n🧵 Task-Based Application Architecture # The VxWorks application layer uses multiple cooperative tasks.\nMajor Software Tasks # Task Responsibility Acquisition Task Reads FPGA FIFO Parser Task Decodes MVB frames Detection Task Analyzes anomalies Alarm Task Sends notifications Logging Task Stores historical events This separation improves maintainability and scheduling flexibility.\n📡 Protocol Parsing Module # The parser identifies frame types and extracts operational data.\nProtocol Parsing Example # void ProtocolParseTask() { while (1) { MVB_Frame frame; frame = MVBBufRead(); if (isMasterFrame(frame)) { parseMasterFrame(frame); } else { parseSlaveFrame(frame); } updateDeviceStatus(frame.source); } } Parsing Responsibilities # Frame Type Processing Master Frame Extract F-code and address Slave Frame Extract payload data Error Frame Trigger diagnostics Parsed data is forwarded to the anomaly detection subsystem.\n🔍 Anomaly Detection and Early Warning # The anomaly detection engine continuously analyzes traffic patterns and device behavior.\n🚨 Types of Abnormal Behavior Detected # Device-Level Anomalies # Detection Description Unknown device Unregistered address appears Device offline Missing heartbeat or timeout Address conflict Duplicate device activity Unexpected topology Invalid bus relationships Protocol-Level Anomalies # Detection Description Invalid F-codes Unsupported commands Malformed frames Corrupted packet structures Replay patterns Repeated identical traffic Traffic spikes Possible DoS conditions Timing-Based Detection # The system tracks:\nLast-seen timestamps Frame frequency Burst rates Synchronization irregularities ⏱️ Example Offline Detection Logic # void CheckDeviceTimeout(DeviceInfo *dev) { if ((currentTime - dev-\u0026gt;lastSeen) \u0026gt; DEVICE_TIMEOUT) { RaiseAlarm(ALARM_DEVICE_OFFLINE, dev-\u0026gt;address); } } This simple mechanism provides effective detection of disappearing or malfunctioning devices.\n📢 Monitoring and Alerting System # When anomalies are detected, the system generates alarms locally and remotely.\nAlarm Mechanisms # Method Purpose LEDs Local visual alert Buzzer Audible warning Ethernet Centralized reporting RS485 Industrial integration Alerts may include:\nDevice identity Event timestamp Alarm severity Captured frame data Traffic statistics 🌐 Integration with Central Monitoring Platforms # The terminal can integrate into larger rail cybersecurity systems.\nPotential Integration Features # Centralized SIEM correlation Historical traffic analysis Distributed anomaly monitoring Multi-vehicle aggregation Remote firmware management This enables deployment across entire train fleets.\n✅ Advantages of the FPGA + VxWorks Architecture # The hybrid architecture provides several major advantages.\nDeterministic Real-Time Performance # FPGA hardware acceleration ensures:\nZero packet loss Precise timing Low processing latency VxWorks ensures predictable scheduling and interrupt handling.\nNon-Intrusive Monitoring # The terminal operates passively and does not interfere with:\nExisting MVB timing Bus arbitration Control traffic This is essential for safety-critical train systems.\nHigh Reliability # Industrial-grade components and RTOS architecture support:\nLong-term stability Harsh environmental operation Deterministic fault handling Scalability # The architecture can be extended to support:\nWTB monitoring Ethernet Train Backbone (ETB) IEC 61375 extensions Future rail communication standards 🚆 Modern Perspective and Future Evolution # Although originally implemented using VxWorks 5.5 and Spartan-6 FPGA hardware, the architectural principles remain highly relevant today.\n🔮 Modernized 2026 Equivalent Architecture # A contemporary implementation might use:\nComponent Modern Alternative Freescale P2020 NXP Layerscape Spartan-6 FPGA Xilinx Zynq UltraScale+ VxWorks 5.5 PREEMPT_RT Linux or modern VxWorks Static rule engine ML-assisted anomaly detection Modern systems may also incorporate:\nAI-based traffic analysis Edge analytics Secure boot Hardware root of trust Encrypted telemetry upload However, the core design principle remains unchanged:\nHardware acceleration for deterministic low-level processing combined with a real-time operating system for intelligent upper-layer analysis.\n🏁 Conclusion # The MVB Monitoring and Early-Warning Terminal demonstrates an effective architecture for protecting train communication networks against emerging cybersecurity threats.\nBy combining:\nFPGA-based high-speed decoding VxWorks deterministic multitasking Real-time anomaly detection Passive monitoring techniques the system provides a reliable and scalable security solution for railway communication infrastructure.\nAs rail systems continue evolving toward increasingly connected and IP-enabled architectures, embedded cybersecurity platforms like this will become essential components of future intelligent transportation systems.\nReference: Building an MVB Monitoring and Early-Warning Terminal with VxWorks and FPGA\n","date":"2026-05-13","externalUrl":null,"permalink":"/industries/building-an-mvb-monitoring-and-early-warning-terminal-with-vxworks-and-fpga/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eBuilding an MVB Monitoring and Early-Warning Terminal with VxWorks and FPGA\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eModern rail transit systems increasingly rely on highly interconnected communication networks for control, diagnostics, and safety-critical coordination. As railway systems become more intelligent and network-centric, cybersecurity risks targeting train communication infrastructure continue to grow.\u003c/p\u003e","title":"Building an MVB Monitoring and Early-Warning Terminal with VxWorks and FPGA","type":"industries"},{"content":"","date":"2026-05-13","externalUrl":null,"permalink":"/tags/industrial-cybersecurity/","section":"Tags","summary":"","title":"Industrial Cybersecurity","type":"tags"},{"content":"","date":"2026-05-13","externalUrl":null,"permalink":"/tags/mvb/","section":"Tags","summary":"","title":"MVB","type":"tags"},{"content":"","date":"2026-05-13","externalUrl":null,"permalink":"/tags/rail-transit/","section":"Tags","summary":"","title":"Rail Transit","type":"tags"},{"content":"","date":"2026-05-13","externalUrl":null,"permalink":"/tags/train-communication-network/","section":"Tags","summary":"","title":"Train Communication Network","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/arinc429/","section":"Tags","summary":"","title":"ARINC429","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/bit-testing/","section":"Tags","summary":"","title":"BIT Testing","type":"tags"},{"content":" Enhanced VxWorks BIT Testing Using Dual-Loop Socket Diagnostics\nBuilt-In Test (BIT) functionality is essential in aerospace, avionics, defense, and safety-critical embedded systems. Conventional loopback testing methods for interfaces such as RS422, ARINC 429, Discrete I/O, and AFDX (ARINC 664) often fail to isolate faults accurately because the same signal path is reused for both transmission and reception verification.\nThis article presents an improved socket-based dual-loop BIT architecture implemented on VxWorks, enabling precise separation of input-path faults and output-path faults through Ethernet-assisted diagnostics.\n⚠️ Limitations of Traditional Loopback BIT Methods # Traditional self-loopback testing introduces several diagnostic limitations:\nInput and output verification share the same physical path Faults cannot be isolated to transmitter, receiver, cable, or connector Debugging becomes time-consuming and maintenance-intensive False positives may occur when multiple failure points exist simultaneously In mission-critical systems, ambiguous BIT results significantly increase troubleshooting complexity and lifecycle maintenance costs.\nTo address these issues, the proposed architecture uses VxWorks socket programming and Ethernet as an independent verification channel.\n🖥️ System Architecture Overview # The system consists of a VxWorks target board connected to a universal automated test platform over Ethernet.\nHardware Components # Component Description Embedded Target PowerPC-based board using e2v PC7410 CPU RTOS VxWorks with BSD socket networking support Test Platform HP-compatible Windows XP automated test equipment Interfaces Under Test RS422, ARINC 429, Discrete I/O, AFDX Network 100 Mbps Ethernet verification channel The Ethernet network acts as a trusted out-of-band diagnostic path, completely isolated from the physical I/O interface under test.\n🔄 Dual-Loop Diagnostic Architecture # The key innovation is the creation of two fully isolated diagnostic loops.\nInput Path Verification Loop # In this mode:\nTest equipment sends known patterns through the physical input interface Target receives the signal through the hardware under test VxWorks forwards received data over Ethernet using TCP sockets Test station compares received Ethernet data against original patterns This verifies:\nPhysical input circuitry Receiver logic Connectors and cables Driver and protocol stack integrity Output Path Verification Loop # In this mode:\nTest station sends commands over Ethernet VxWorks generates output test patterns Target transmits patterns through the physical output interface Test equipment validates received signals independently This verifies:\nOutput driver circuitry Protocol transmit logic Timing correctness Physical transmission integrity Unlike conventional loopback tests, the two paths are completely independent.\n🌐 VxWorks Socket Server Implementation # VxWorks provides a mature BSD-compatible socket API, making TCP communication straightforward and highly portable.\n⚙️ Socket Initialization and Configuration # The following helper routine configures the socket for reliable diagnostic communication.\nint initialize_socket(int sock) { int opt = 1; struct timeval timeout; // Enable port reuse setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *)\u0026amp;opt, sizeof(opt)); // Configure send/receive timeout timeout.tv_sec = 5; timeout.tv_usec = 0; setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, (char *)\u0026amp;timeout, sizeof(timeout)); setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *)\u0026amp;timeout, sizeof(timeout)); // Detect broken peer connections setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, (char *)\u0026amp;opt, sizeof(opt)); return OK; } Why These Socket Options Matter # Option Purpose SO_REUSEADDR Allows rapid socket rebinding after restart SO_RCVTIMEO Prevents indefinite blocking during diagnostics SO_SNDTIMEO Ensures deterministic transmission behavior SO_KEEPALIVE Detects disconnected test equipment automatically These settings improve reliability during long-duration automated testing.\n🛠️ TCP Server Implementation on VxWorks # The following server routine initializes the TCP listener and waits for a diagnostic client connection.\nint start_svr(short listen_port) { int cmd_sock; int cmd_sock_des; struct sockaddr_in svr_adrs; struct sockaddr_in client_adrs; int client_len; bzero((char *)\u0026amp;svr_adrs, sizeof(svr_adrs)); bzero((char *)\u0026amp;client_adrs, sizeof(client_adrs)); // Create TCP socket cmd_sock = socket(AF_INET, SOCK_STREAM, 0); if (cmd_sock == -1) return -1; // Apply socket configuration if (initialize_socket(cmd_sock) != OK) { close(cmd_sock); return -2; } // Configure server address svr_adrs.sin_family = AF_INET; svr_adrs.sin_addr.s_addr = htonl(INADDR_ANY); svr_adrs.sin_port = htons(listen_port); // Bind socket if (bind(cmd_sock, (struct sockaddr *)\u0026amp;svr_adrs, sizeof(svr_adrs)) \u0026lt; 0) { close(cmd_sock); return -3; } // Enter listening state if (listen(cmd_sock, 1) == -1) { close(cmd_sock); return -4; } // Wait for diagnostic client client_len = sizeof(client_adrs); cmd_sock_des = accept(cmd_sock, (struct sockaddr *)\u0026amp;client_adrs, \u0026amp;client_len); if (cmd_sock_des == -1) { close(cmd_sock); return -5; } // Connected client socket return cmd_sock_des; } Implementation Notes # SOCK_STREAM ensures reliable TCP delivery Blocking accept() behavior is suitable for dedicated BIT tasks Error codes simplify automated fault analysis Server logic can be wrapped inside a dedicated taskSpawn() task 📦 Diagnostic Command Protocol Design # A lightweight binary protocol minimizes CPU overhead and network bandwidth.\nCommand Structure # #define MAX_PACKET 256 struct operation_cmd { unsigned short cmd; // Command ID unsigned char data_len; // Payload size unsigned char checksum; // Integrity verification unsigned char data[MAX_PACKET]; }; Typical Command Types # Command Purpose TEST_RS422_IN Verify RS422 receiver path TEST_RS422_OUT Verify RS422 transmitter path TEST_ARINC429_IN Validate ARINC429 input TEST_ARINC429_OUT Validate ARINC429 output TEST_AFDX_IN Verify AFDX receive logic TEST_AFDX_OUT Verify AFDX transmit logic The checksum provides lightweight packet integrity verification without introducing unnecessary processing overhead.\n🧵 Multi-Tasked Diagnostic Execution # VxWorks multitasking allows each interface test to run independently.\nExample Diagnostic Tasks # taskSpawn(\u0026#34;tRs422Recv\u0026#34;, 100, 0, 8192, (FUNCPTR)rs422Recvatp, 0,0,0,0,0,0,0,0,0,0); taskSpawn(\u0026#34;tRs422Send\u0026#34;, 100, 0, 8192, (FUNCPTR)rs422Sendatp, 0,0,0,0,0,0,0,0,0,0); Additional tasks may include:\ndiscInState discOutControl arinc429Recvatp arinc429Sendatp AfdxInTest AfdxOutTest This architecture enables scalable concurrent testing across multiple avionics interfaces.\n🔍 Detailed Test Execution Flow # Input Path Test Sequence # Test platform sends known physical-interface pattern Target receives signal through hardware interface VxWorks stores captured data Data forwarded to test station via TCP socket Test software performs byte-level comparison PASS/FAIL result generated Output Path Test Sequence # Test platform issues Ethernet command VxWorks generates transmit pattern Physical interface sends output signal Test equipment captures signal Captured data compared against expected values Output channel integrity validated The isolation between verification path and tested interface enables precise fault localization.\n✅ Advantages of the Dual-Loop BIT Architecture # Accurate Fault Isolation # The system can distinguish between:\nReceiver failures Transmitter failures Cable faults Connector issues Interface logic errors High Reliability # TCP guarantees:\nOrdered delivery Error-checked transmission Reliable retransmission Connection integrity monitoring Excellent Portability # The implementation relies entirely on:\nStandard BSD sockets Portable VxWorks APIs Minimal hardware dependencies The same architecture can be adapted to:\nOther PowerPC boards ARM-based VxWorks targets Alternative RTOS platforms Minimal Real-Time Impact # BIT tasks execute independently using VxWorks scheduling mechanisms, allowing diagnostics to coexist with operational software.\nReduced Maintenance Costs # Fast and deterministic fault isolation dramatically decreases:\nTroubleshooting time Maintenance labor System downtime Lifecycle support cost ✈️ Applications in Aerospace and Defense # This diagnostic method is especially valuable for:\nFlight control computers Mission computers Radar processors Weapons management systems Avionics gateways Industrial safety controllers Any system requiring high diagnostic coverage can benefit from this approach.\n🏁 Conclusion # The socket-based dual-loop BIT method represents a major improvement over traditional loopback diagnostics in VxWorks embedded systems.\nBy using Ethernet as an isolated verification channel, the architecture enables:\nPrecise I/O fault localization Reliable automated diagnostics Reduced troubleshooting complexity Scalable multi-interface testing The design demonstrates how VxWorks networking capabilities can be leveraged beyond ordinary communication tasks to implement advanced, production-grade Built-In Test infrastructure for mission-critical embedded platforms.\nReference: Enhanced VxWorks BIT Testing Using Dual-Loop Socket Diagnostics\n","date":"2026-05-11","externalUrl":null,"permalink":"/app/enhanced-vxworks-bit-testing-using-dual-loop-socket-diagnostics/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eEnhanced VxWorks BIT Testing Using Dual-Loop Socket Diagnostics\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eBuilt-In Test (BIT) functionality is essential in aerospace, avionics, defense, and safety-critical embedded systems. Conventional loopback testing methods for interfaces such as \u003cstrong\u003eRS422\u003c/strong\u003e, \u003cstrong\u003eARINC 429\u003c/strong\u003e, \u003cstrong\u003eDiscrete I/O\u003c/strong\u003e, and \u003cstrong\u003eAFDX (ARINC 664)\u003c/strong\u003e often fail to isolate faults accurately because the same signal path is reused for both transmission and reception verification.\u003c/p\u003e","title":"Enhanced VxWorks BIT Testing Using Dual-Loop Socket Diagnostics","type":"app"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/rs422/","section":"Tags","summary":"","title":"RS422","type":"tags"},{"content":" Building a Remote Real-Time Graphical Control System with VxWorks\nIn industrial, military, and marine embedded systems, providing remote real-time monitoring and control is essential. This article presents a practical implementation of a remote graphical display and control system on VxWorks 5.5, leveraging an embedded web server and Java Applets for efficient, low-latency operation.\n🖥️ Architecture Overview and Key Benefits # Traditional web technologies struggle with real-time performance due to full-page refresh cycles. By integrating VxWorks\u0026rsquo; deterministic real-time capabilities with a lightweight embedded web server and client-side Java Applets, we achieve:\nRemote accessibility via standard browsers Real-time telemetry visualization Low-latency bidirectional control Minimal resource usage on embedded hardware The system targets a PC104 single-board computer with a CompactFlash (CF) card as persistent storage, serving HTML and Java Applets directly from the embedded web server.\nCore Components # Component Role VxWorks 5.5 Real-time OS ensuring determinism and low-latency task scheduling GoAhead WebServer Lightweight embedded web server supporting CGI, ASP, and custom APIs Java Applet Browser-based client for real-time graphics and remote control UDP Sockets High-performance bidirectional communication protocol PC104 SBC Embedded hardware platform with CF storage ⚙️ Hardware and Software Stack # Hardware:\nPC104 embedded board with CF card Ethernet interface for network connectivity Software:\nVxWorks 5.5 kernel GoAhead WebServer Custom C/C++ tasks for data acquisition and control Java Applet client (requires JRE 1.6+) This stack balances real-time determinism on the server side with rich, responsive graphics on the client.\n🛠️ Implementing the Embedded Web Server on VxWorks # The GoAhead WebServer was selected for its small footprint, high performance (\u0026gt;50 HTTP requests/sec), and seamless VxWorks integration.\nWeb Server Initialization Example # #include \u0026#34;webs.h\u0026#34; int main(int argc, char **argv) { // Initialize the web server core websInit(); // Set document root to CF card directory websSetDefaultDir(\u0026#34;/cf0/www\u0026#34;); // Register custom URL handlers for control websUrlHandlerDefine(\u0026#34;/control\u0026#34;, NULL, controlHandler, NULL, 0); // Listen on standard HTTP port websListen(80); // Launch web server in a separate VxWorks task taskSpawn(\u0026#34;tWebServer\u0026#34;, 100, 0, 5000, (FUNCPTR)websRun, 0,0,0,0,0,0,0,0,0,0); } Build Configuration (Tornado IDE):\nCompile flags: -DWEBS -DUEMF -DOS=\u0026quot;VXWORKS\u0026quot; -DVXWORKS -DUSER_MANAGEMENT_SUPPORT Include all server source files Copy HTML, .class (Applet), and assets to /www on CF card This approach ensures the embedded target functions as a full web server without compromising real-time control.\n📊 Real-Time Graphical Display with Java Applets # HTML alone cannot provide smooth, real-time updates. Java Applets offer a full graphical client capable of rendering dynamic telemetry data.\nApplet Architecture # Auto-downloads with the web page Opens a local UDP socket Receives structured telemetry data Renders waveforms, gauges, or 3D models using Java 2D/3D graphics Java Applet Example # public class RealTimeDisplayApplet extends Applet implements Runnable { private DatagramSocket socket; private byte[] buffer = new byte[4096]; public void init() { try { socket = new DatagramSocket(5000); // UDP port new Thread(this).start(); } catch (Exception e) { e.printStackTrace(); } } public void run() { while (true) { try { DatagramPacket packet = new DatagramPacket(buffer, buffer.length); socket.receive(packet); // Process telemetry data DataProcessor.processData(buffer); // Update graphics repaint(); } catch (Exception e) { e.printStackTrace(); } } } public void paint(Graphics g) { Graphics2D g2d = (Graphics2D) g; // Example: render real-time waveform g2d.drawLine(lastX, lastY, currentX, currentY); // Update additional dynamic elements } } By offloading rendering to the client, network bandwidth is minimized and system responsiveness improves significantly.\n🔄 Bidirectional Remote Control via UDP # The embedded target listens for user commands over UDP, enabling immediate execution within the real-time task context.\nUDP Command Listener Example (VxWorks) # void udpCommandTask(void) { int sock = socket(AF_INET, SOCK_DGRAM, 0); struct sockaddr_in addr; // Bind to command port 5001 while (1) { char cmdBuffer[512]; int len = recvfrom(sock, cmdBuffer, sizeof(cmdBuffer), 0, ...); // Parse and execute commands processRemoteCommand(cmdBuffer); // Return acknowledgment or telemetry updates sendto(sock, responseData, responseLen, 0, \u0026amp;clientAddr, ...); } } Commands are packaged as binary structures or JSON-like payloads and immediately acted upon by the embedded system, maintaining real-time responsiveness.\n🔄 System Workflow # User accesses http://target-ip Web server delivers HTML and Java Applet Applet initializes UDP socket VxWorks streams telemetry → Applet renders graphics User interacts with Applet UI → commands sent over UDP Target executes commands and returns status updates ✅ Advantages of This Architecture # No additional client installation beyond Java Runtime Deterministic real-time performance leveraging VxWorks Cross-platform browser compatibility Minimal embedded resource usage Easy maintenance via web page or Applet updates 🌐 Applications and Extensions 🌟 # This architecture is well-suited for:\nIndustrial SCADA systems Marine or weapons console monitoring Distributed cluster control Multi-channel video surveillance While modern technologies like WebSockets, HTML5 Canvas, Node.js, or REST + MQTT exist, this method remains valuable for legacy VxWorks systems requiring determinism and minimal client footprint.\n🏁 Conclusion and Future Directions # By combining VxWorks, GoAhead WebServer, and Java Applets, developers can implement robust, real-time, remote graphical control systems. This approach balances high-performance embedded control with rich, browser-based visualization, making it ideal for mission-critical applications in industrial and defense environments.\nReference: Building a Remote Real-Time Graphical Control System with VxWorks\n","date":"2026-05-11","externalUrl":null,"permalink":"/app/building-a-remote-real-time-graphical-control-system-with-vxworks/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eBuilding a Remote Real-Time Graphical Control System with VxWorks\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eIn industrial, military, and marine embedded systems, providing \u003cstrong\u003eremote real-time monitoring and control\u003c/strong\u003e is essential. This article presents a practical implementation of a \u003cstrong\u003eremote graphical display and control system\u003c/strong\u003e on \u003cstrong\u003eVxWorks 5.5\u003c/strong\u003e, leveraging an embedded web server and Java Applets for efficient, low-latency operation.\u003c/p\u003e","title":"Building a Remote Real-Time Graphical Control System with VxWorks","type":"app"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/goahead-webserver/","section":"Tags","summary":"","title":"GoAhead WebServer","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/java-applets/","section":"Tags","summary":"","title":"Java Applets","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/pc104/","section":"Tags","summary":"","title":"PC104","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/real-time-control/","section":"Tags","summary":"","title":"Real-Time Control","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/remote-monitoring/","section":"Tags","summary":"","title":"Remote Monitoring","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/udp-communication/","section":"Tags","summary":"","title":"UDP Communication","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/c/c++-development/","section":"Tags","summary":"","title":"C/C++ Development","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/fire-control-console/","section":"Tags","summary":"","title":"Fire Control Console","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"permalink":"/tags/mode-switching/","section":"Tags","summary":"","title":"Mode Switching","type":"tags"},{"content":" Task Scheduling Application for VxWorks Fire Control Consoles\nThis guide details the design and implementation of a task scheduling application component for weapon fire control consoles under the VxWorks 5.5 embedded operating system. The component enables automatic mode switching, supports concurrent execution of multiple application modules, and enhances software flexibility and standardization.\n⚡ Introduction # Modern military platforms may deploy multiple fire control devices on a single carrier. Dedicated consoles per model lead to duplicated design effort, wasted resources, and limited extensibility.\nSolution Overview:\nGeneralized design scheme for fire control consoles Standardized hardware platform and reusable application components Dynamic deployment of mode-specific functionality The approach consolidates common functionality across models and allows downward compatibility for multiple device types.\n🛠 System Overview # Terminology # Application Component: A software module implementing a specific function. Mode: A configuration organizing related components to satisfy a specific device model\u0026rsquo;s functionality. Deployment Scheme: Rules for dynamically configuring the console to achieve specified functions using available modes. Functional Description # The task scheduling component provides:\nDynamic loading/unloading of user components Task management (load, unload, suspend, resume) Real-time monitoring of task execution Tasks are scheduled according to pre-configured deployment schemes. Users can switch modes dynamically, prompting the scheduler to load/unload components and recombine functionality seamlessly.\nDevelopment Environment:\nC/C++ with Tornado 2.2.1 on VxWorks 5.5\n🔧 Component Architecture # The task scheduler consists of four modules:\nDeployment Scheme Dynamic Parsing\nReads and parses deployment scheme files to map modes to components.\nUser Component Dynamic Loading\nLoads components into memory during initialization to ensure rapid task response.\nMode Switching Module\nHandles user-triggered mode changes:\nUnloads previous mode tasks Loads new mode tasks Task Monitoring Module\nTracks task states in real time and provides user interfaces for inspection.\n⚙️ Data Flow and File Structure # Key files and relationships:\nDeployment Scheme File: Lists all modes and corresponding configuration files. Mode Configuration Files: Define which user components belong to each mode. User Component Files: Executables implementing specific functions, each exposing standardized interfaces: Task load Task unload Task suspend Task resume This structure ensures dynamic reconfiguration based on mode selection.\n💻 Program Flow Analysis # Initialization:\nLoad deployment scheme and mode configuration files Load all user components into memory Start mode switching and monitoring tasks Activate default mode Mode Switching:\nListens for commands in real time Verifies target mode components Unloads current mode tasks, then loads new mode tasks Task Monitoring:\nAuxiliary clock ISR collects CPU usage data Computes occupancy rates and task states Provides monitoring interfaces for users ✅ Conclusion # The generalized task scheduling design for VxWorks-based fire control consoles:\nEnables dynamic mode switching and component recombination Achieves hardware platform standardization Reduces development costs Improves operational flexibility and software extensibility Testing confirms compatibility across multiple fire control device models and operational efficiency gains.\nReference: Task Scheduling Application for VxWorks Fire Control Consoles\n","date":"2026-05-11","externalUrl":null,"permalink":"/app/task-scheduling-application-for-vxworks-fire-control-consoles/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eTask Scheduling Application for VxWorks Fire Control Consoles\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eThis guide details the design and implementation of a \u003cstrong\u003etask scheduling application component\u003c/strong\u003e for weapon fire control consoles under the \u003cstrong\u003eVxWorks 5.5\u003c/strong\u003e embedded operating system. The component enables automatic mode switching, supports concurrent execution of multiple application modules, and enhances software flexibility and standardization.\u003c/p\u003e","title":"Task Scheduling Application for VxWorks Fire Control Consoles","type":"app"},{"content":"","date":"2026-05-04","externalUrl":null,"permalink":"/tags/cmake/","section":"Tags","summary":"","title":"CMake","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"permalink":"/tags/cross-compilation/","section":"Tags","summary":"","title":"Cross Compilation","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"permalink":"/tags/eglfs/","section":"Tags","summary":"","title":"EGLFS","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"permalink":"/tags/qt/","section":"Tags","summary":"","title":"Qt","type":"tags"},{"content":" Qt for VxWorks: Build, Configure, and Deployment Guide\nQt for VxWorks enables modern GUI development on real-time embedded systems using the Qt 6 framework. This guide provides a structured overview of supported platforms, system requirements, build workflow, and deployment practices for production-grade environments.\n📦 Licensing and Availability # Qt for VxWorks is distributed under the Qt for Device Creation Professional (DCP) license. This commercial offering includes long-term support, tooling, and access to Qt professional services.\n🧩 Supported Platforms # Verified Configuration # Qt Version: 6.10 VxWorks Version: 25.03 Supported Architectures # ARMv7\nDevice: BD-SL-i.MX6 BSP: fsl_imx6 x86_64\nDevice: Intel NUC6i3SYH BSP: itl_generic Support for newer Qt versions may require engagement with Qt professional services.\n⚙️ System Requirements # Qt Widgets Applications # POSIX support C++17 support Qt Quick 2 Applications # In addition to Widgets requirements:\nGPU device (GPUDEV) OpenGL ES 2.0 support 📚 Supported Qt Modules # Essential Modules # Qt Core (limitations apply: no QProcess, restricted socket support) Qt GUI Qt Network Qt QML / Quick stack Qt Widgets Add-On Modules # Qt Concurrent Qt GRPC / Protobuf Qt Multimedia Qt OpenGL Qt Quick 3D Qt SQL Qt SVG Qt Virtual Keyboard Qt Graphs Modules can be excluded during build using:\n-skip \u0026lt;module\u0026gt; 🧠 Platform Constraints # Runtime Model # Only RTP (Real-Time Process) is supported DKM (Downloadable Kernel Modules) are not supported Windowing System # Qt no longer includes QWS Uses Qt Platform Abstraction (QPA) Only supported platform plugin: EGLFS 🏗️ Build Environment Setup # Prerequisites # VxWorks SDK installation Valid Wind River license Qt 6 host build (required for tools like moc, rcc, qmlcachegen) Toolchain and sysroot Environment Initialization # Linux # cd \u0026lt;VxWorks install dir\u0026gt; ./wrenv.sh -p vxworks export WIND_CC_SYSROOT=\u0026lt;path to VSB\u0026gt; Windows # cd \u0026lt;VxWorks install dir\u0026gt; wrenv -p vxworks set WIND_CC_SYSROOT=\u0026lt;path to VSB\u0026gt; 🔧 VxWorks Image Requirements # Qt requires specific VSB and VIP configurations.\nKey VSB Features # Networking: IPNET_COREIP, SOCKET\nStorage: SDMMC_*\nInput: EVDEV, USB_*\nSecurity: OPENSSL, HASH\nGraphics:\nGPUDEV_FSLVIVGPU (ARM) DRM, MESA, ITLI915 (x86) Required Config Variables # _WRS_CONFIG_RTP_SSP=y _WRS_CONFIG_RTP_STACK_PROTECTOR=y _WRS_CONFIG_EVDEV_COMPATIBLE_MODE=y VIP Bundles # BUNDLE_POSIX (mandatory) RTP deployment and development bundles Critical Components # INCLUDE_TMP_DIR (for QTemporaryFile) INCLUDE_IO_REALPATH (for QFileInfo) Input, storage, networking, and GPU drivers depending on BSP 🛠️ Building Qt 6 # Host Build # ./configure \\ -cmake-generator \u0026#34;Ninja\u0026#34; \\ -extprefix \u0026lt;host_install_dir\u0026gt; \\ -submodules qtbase,qtdeclarative,qtquick3d,qtshadertools \\ -nomake tests -nomake examples cmake --build . --parallel cmake --install . Target Build Configuration # ./configure \\ -cmake-generator \u0026#34;Ninja\u0026#34; \\ -eglfs \\ -qpa eglfs \\ -submodules \u0026#34;qtbase,qtdeclarative,qtmultimedia,qtquick3d\u0026#34; \\ -- \\ -DQT_QMAKE_TARGET_MKSPEC=vxworks-clang \\ -DQT_HOST_PATH=\u0026lt;host_qt_path\u0026gt; \\ -DCMAKE_TOOLCHAIN_FILE=\u0026lt;graphics_toolchain.cmake\u0026gt; Notes # Use shadow builds Add -static for static builds If RTP_MEM_FILL=false, define: -DCMAKE_CXX_FLAGS=\u0026#34;-DQT_RTP_MEM_FILL=1\u0026#34; 🎮 Graphics and EGLFS # Qt uses EGLFS for rendering:\nRequires BSP-specific EGL/OpenGL libraries\nToolchain file must include graphics paths and libraries\nSupports integrations like:\neglfs_viv (i.MX6) eglfs_kms (Intel) 📱 Building Applications # Example build:\nqt-cmake -G Ninja \\ -S \u0026lt;Qt example path\u0026gt; \\ -B \u0026lt;build dir\u0026gt; cmake --build . --parallel Required Environment Variables # QT_QPA_FONTDIR QT_QPA_EGLFS_FB LD_LIBRARY_PATH ICU_DATA QT_QPA_EGLFS_INTEGRATION Disable QML disk cache:\nQML_DISABLE_DISK_CACHE=1 🚀 Running Applications # Launch via RTP:\nrtpSp(\u0026#34;\u0026lt;app\u0026gt;\u0026#34;, 200, 0x100000, 0, 0x01000000); 🐞 Debugging # Enable Debug Support # VSB:\n_WRS_CONFIG_TCF_GDB_RSP=y VIP:\nINCLUDE_DEBUG_AGENT INCLUDE_STANDALONE_SYM_TBL GDB Workflow # vxgdb \u0026lt;binary\u0026gt; monitor ps attach \u0026lt;pid\u0026gt; 🎛️ Input Handling # Qt provides VxWorks-specific input plugins:\nVxMouse VxKeyboard VxTouch Differences from Linux evdev:\nCustom environment variables\nAdditional touchscreen parameters:\nrangex rangey ⚠️ Limitations # Video Memory Constraints # Qt Quick and OpenGL-based components require sufficient GPU memory:\nMinimum recommended: 128 MB Insufficient memory may cause rendering failures Other Limitations # No QML disk cache support Limited POSIX feature coverage No DKM support 📌 Conclusion # Qt for VxWorks provides a robust foundation for building modern embedded GUIs in real-time environments. However, successful deployment requires careful alignment between BSP configuration, graphics stack, and Qt build settings.\nFor production systems, focus on:\nCorrect VSB/VIP configuration Verified toolchain integration GPU and EGL readiness Controlled module selection When properly configured, Qt enables high-performance, hardware-accelerated interfaces on VxWorks with predictable real-time behavior.\n","date":"2026-05-04","externalUrl":null,"permalink":"/app/qt-for-vxworks-build-configure-and-deployment-guide/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eQt for VxWorks: Build, Configure, and Deployment Guide\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eQt for VxWorks enables modern GUI development on real-time embedded systems using the Qt 6 framework. This guide provides a structured overview of supported platforms, system requirements, build workflow, and deployment practices for production-grade environments.\u003c/p\u003e","title":"Qt for VxWorks: Build, Configure, and Deployment Guide","type":"app"},{"content":"","date":"2026-05-04","externalUrl":null,"permalink":"/tags/rtp/","section":"Tags","summary":"","title":"RTP","type":"tags"},{"content":"","date":"2026-05-03","externalUrl":null,"permalink":"/tags/real-time/","section":"Tags","summary":"","title":"Real-Time","type":"tags"},{"content":" VxWorks Serial Communication Design and Implementation Guide\nSerial communication remains a fundamental mechanism for data exchange in embedded systems, especially in environments requiring reliability and deterministic behavior. VxWorks provides a robust and flexible framework for implementing serial interfaces through its I/O subsystem and driver model.\nThis article presents the design principles, system configuration, and practical implementation of serial communication in VxWorks, based on real-world embedded applications.\n⚙️ VxWorks Architecture for Serial Communication # VxWorks implements serial communication through a layered driver architecture:\nCore Components # Serial Communication Controller (SCC)\nHardware-level interface supporting multiple serial channels\nSCC Driver\nHandles low-level hardware operations and interrupt management\ntty Driver\nProvides a unified character device interface for applications\nI/O System\nAbstracts device access using standard file operations (open, read, write)\nThis separation enables portability and simplifies application-level development.\n🔌 Serial Device Model in VxWorks # Serial ports are exposed as character devices, typically in the form:\n/tyCo/x Where:\ntyCo represents the tty device class x is the channel index (e.g., /tyCo/0 for COM1) tty Driver Modes # RAW Mode (default)\nDirect byte stream No buffering or line editing LINE Mode\nLine-based input processing Includes editing and buffering RAW mode is preferred for real-time embedded communication due to minimal overhead.\n🧠 Communication Modes and Considerations # Interrupt vs Polling # Interrupt-driven mode\nEfficient for high-throughput or asynchronous communication Lower CPU usage Polling mode\nSimpler but less efficient Suitable for low-frequency communication Non-Blocking I/O # To avoid blocking on slow devices, VxWorks supports:\nselect() for I/O multiplexing Asynchronous I/O (AIO) Timeout-based reads These mechanisms are critical in real-time systems where blocking can violate timing constraints.\n🛠️ System Configuration # BSP Configuration # To enable serial communication and debugging:\nModify config.h in the BSP Enable serial-based debugging (WDB) if required Build and Deployment # Typical steps include:\nBuild Boot ROM and VxWorks image Generate boot media (e.g., via mkboot) Boot target hardware and load the RTOS This setup ensures the serial interface is initialized during system startup.\n💻 Serial Communication Example # Include Required Headers # #include \u0026lt;VxWorks.h\u0026gt; #include \u0026lt;ioLib.h\u0026gt; #include \u0026lt;fioLib.h\u0026gt; #include \u0026lt;tyLib.h\u0026gt; #include \u0026lt;selectLib.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;ioctl.h\u0026gt; Open Serial Port # int sfd = open(\u0026#34;/tyCo/0\u0026#34;, O_RDWR, 0); Configure Serial Parameters # ioctl(sfd, FIOSETOPTIONS, OPT_RAW); // RAW mode ioctl(sfd, FIOBAUDRATE, 9600); // Baud rate ioctl(sfd, FIOFLUSH, 0); // Clear buffers Receive Data (Non-Blocking with select) # fd_set fds; while (1) { FD_ZERO(\u0026amp;fds); FD_SET(sfd, \u0026amp;fds); if (select(sfd + 1, \u0026amp;fds, NULL, NULL, NULL) == ERROR) return ERROR; read(sfd, recv_buf, sizeof(recv_buf)); } Send Data # fd_set fds_write; FD_SET(sfd, \u0026amp;fds_write); if (select(sfd + 1, NULL, \u0026amp;fds_write, NULL, NULL) == ERROR) return ERROR; write(sfd, send_buf, sizeof(send_buf)); Close Serial Port # close(sfd); ⏱️ Real-Time Design Considerations # When implementing serial communication in VxWorks:\nAvoid Blocking Calls Use select() or timeouts to maintain responsiveness\nMinimize ISR Workload Keep interrupt handlers short and defer processing to tasks\nBuffer Management Ensure sufficient buffering for burst data\nError Handling Detect and recover from communication faults (timeouts, framing errors)\n🧾 Conclusion # VxWorks provides a mature and efficient framework for serial communication through its layered driver model and flexible I/O system. By leveraging tty devices, ioctl-based configuration, and non-blocking I/O mechanisms, developers can implement reliable and deterministic serial interfaces.\nThis approach is well-suited for embedded applications such as industrial control and defense systems, where stable communication and real-time performance are essential.\nReference: https://www.rtos.club/vxworks/vxworks-serial-communication-design-and-implementation-guide/\n","date":"2026-05-03","externalUrl":null,"permalink":"/app/vxworks-serial-communication-design-and-implementation-guide/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Serial Communication Design and Implementation Guide\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eSerial communication remains a fundamental mechanism for data exchange in embedded systems, especially in environments requiring reliability and deterministic behavior. VxWorks provides a robust and flexible framework for implementing serial interfaces through its I/O subsystem and driver model.\u003c/p\u003e","title":"VxWorks Serial Communication Design and Implementation Guide","type":"app"},{"content":"","date":"2026-04-27","externalUrl":null,"permalink":"/tags/concurrency/","section":"Tags","summary":"","title":"Concurrency","type":"tags"},{"content":"","date":"2026-04-27","externalUrl":null,"permalink":"/tags/real-time-development/","section":"Tags","summary":"","title":"Real-Time Development","type":"tags"},{"content":" VxWorks 7 Beginner Guide: Step-by-Step RTOS Tutorial\nVxWorks 7 is widely used in mission-critical embedded systems, but getting started can feel opaque if you\u0026rsquo;re coming from Linux or bare-metal development.\nThis guide provides a practical, developer-focused walkthrough of VxWorks 7—from environment setup to writing real-time tasks and understanding core RTOS concepts like scheduling and synchronization.\nUnlike superficial tutorials, this guide emphasizes how things actually work under the hood, so you build transferable RTOS expertise.\n🌍 What is VxWorks 7? # VxWorks 7 is a deterministic real-time operating system designed for systems where timing correctness is as important as functional correctness.\nTypical deployment domains include:\nAerospace and avionics (flight control, satellites) Industrial automation and robotics Medical devices (life-critical systems) Defense and telecommunications infrastructure Unlike general-purpose OSes, VxWorks guarantees:\nBounded interrupt latency Preemptive priority-based scheduling Deterministic task execution ⚡ Key Capabilities of VxWorks 7 # From a systems perspective, VxWorks 7 introduces several architectural improvements over earlier versions:\nModular Kernel (VxWorks 7 Platform)\nComponent-based system configuration using a layered architecture\nUser/Kernel Space Separation (RTP Support)\nEnables process isolation for improved safety\nSMP and Multicore Scheduling\nEfficient scaling across modern CPUs\nPOSIX Compliance\nEasier portability of Linux/Unix applications\nAdvanced Networking Stack\nIPv4/IPv6, high-performance packet processing\nSecurity Features\nSecure boot, access control, and system hardening\n🛠️ Step 1: Install Wind River Workbench # Wind River Workbench is the primary IDE for VxWorks development.\nInstallation Overview # Install VxWorks 7 SDK (includes toolchains and BSPs) Launch Workbench Select a workspace directory What Gets Installed # Cross-compilers (GCC/LLVM-based toolchains) Board Support Packages (BSPs) Debugger and analysis tools VxWorks Simulator (VxSim) 🖥️ Step 2: Create a VxWorks Project # VxWorks supports multiple project types. For beginners, start with a Downloadable Kernel Module (DKM).\nSteps # File → New → VxWorks Downloadable Kernel Module Project Name: HelloVxWorks Select target architecture (e.g., x86, ARM64) Finish Why DKM? # Runs in kernel space Fast iteration cycle Ideal for learning core APIs (taskLib, semLib, msgQ) ⚙️ Step 3: Configure the Target (Simulator) # If hardware is unavailable, use VxSim.\nSetup Flow # Open Target Manager Add target → VxSim Launch and connect This creates a full RTOS runtime environment without physical hardware.\n👋 Step 4: First Program – Task Creation # In VxWorks, execution units are called tasks (not processes or threads in the traditional sense).\nHello World Example # #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; void helloTask(void) { printf(\u0026#34;Hello VxWorks 7!\\n\u0026#34;); } void usrAppInit(void) { taskSpawn(\u0026#34;tHello\u0026#34;, 100, /* priority (lower = higher priority) */ 0, /* options */ 8192, /* stack size */ (FUNCPTR)helloTask, 0,0,0,0,0,0,0,0,0,0); } Key Concepts # taskSpawn() creates a new schedulable entity Priority directly affects execution order Stack size must be explicitly defined ▶️ Step 5: Build, Load, and Execute # Build # Right-click project → Build Project Deploy # Connect to target (VxSim) Run as → VxWorks DKM Expected Output # Hello VxWorks 7! 🔄 Step 6: Task Synchronization with Semaphores # Concurrency is where RTOS systems become interesting—and complex.\nProducer-Consumer Example # #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; #include \u0026lt;semLib.h\u0026gt; SEM_ID sem; void producerTask(void) { while (1) { printf(\u0026#34;Producer: data ready\\n\u0026#34;); semGive(sem); taskDelay(100); } } void consumerTask(void) { while (1) { semTake(sem, WAIT_FOREVER); printf(\u0026#34;Consumer: processing data\\n\u0026#34;); } } void usrAppInit(void) { sem = semBCreate(SEM_Q_FIFO, SEM_EMPTY); taskSpawn(\u0026#34;tProducer\u0026#34;, 90, 0, 8192, (FUNCPTR)producerTask, 0,0,0,0,0,0,0,0,0,0); taskSpawn(\u0026#34;tConsumer\u0026#34;, 100, 0, 8192, (FUNCPTR)consumerTask, 0,0,0,0,0,0,0,0,0,0); } What This Demonstrates # Binary semaphore synchronization Task coordination without busy-waiting Priority-driven execution behavior 🧵 Understanding VxWorks Scheduling # VxWorks uses preemptive priority-based scheduling:\nLower number = higher priority Highest-priority READY task always runs No time slicing unless explicitly enabled Implications # Starvation is possible if priorities are misconfigured Priority inversion must be handled (via priority inheritance) 🧠 Memory and Execution Models # VxWorks supports two primary models:\nKernel Mode (DKM) # Fast, direct access No isolation Suitable for drivers and low-level components User Mode (RTP – Real-Time Process) # Memory protection enabled Safer execution Preferred for large applications 🔍 Debugging and Analysis Tools # Workbench provides powerful debugging capabilities:\nCore Tools # Task-level debugger Stack trace inspection Breakpoints and watchpoints Advanced Tools # System Viewer (trace scheduling events) Performance Profiler Memory analysis tools Understanding timing issues often requires trace-based debugging, not just breakpoints.\n🌐 Beyond Basics: Networking and IPC # VxWorks provides rich IPC and networking primitives:\nMessage queues (msgQ) Pipes and shared memory BSD sockets (POSIX networking) These are essential for:\nDistributed embedded systems Real-time data pipelines 🏗️ From Tutorial to Production Systems # Moving from examples to production requires:\nBSP customization Device driver integration System configuration (VSB/VPB projects) Deterministic performance tuning You will also need to consider:\nInterrupt latency tuning Cache and MMU configuration Multicore scheduling policies 🎯 Conclusion # VxWorks 7 is not just an RTOS—it is a full embedded platform designed for systems where failure is not an option.\nKey takeaways:\nTasks, priorities, and synchronization are the core primitives Determinism requires careful system design—not just API usage Tooling (Workbench, tracing) is essential for real-world debugging Scaling to production involves architecture decisions beyond code Once you understand these fundamentals, transitioning to advanced topics—device drivers, networking stacks, and system optimization—becomes significantly easier.\nVxWorks rewards engineers who think in terms of timing, concurrency, and system behavior, not just functionality.\n","date":"2026-04-27","externalUrl":null,"permalink":"/training/vxworks-7-beginner-guide-step-by-step-rtos-tutorial/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 7 Beginner Guide: Step-by-Step RTOS Tutorial\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e\u003ca href=\"https://www.vxworks7.com\" target=\"_blank\"\u003eVxWorks 7\u003c/a\u003e is widely used in \u003cstrong\u003emission-critical embedded systems\u003c/strong\u003e, but getting started can feel opaque if you\u0026rsquo;re coming from Linux or bare-metal development.\u003c/p\u003e","title":"VxWorks 7 Beginner Guide: Step-by-Step RTOS Tutorial","type":"training"},{"content":"","date":"2026-04-27","externalUrl":null,"permalink":"/tags/wind-river-workbench/","section":"Tags","summary":"","title":"Wind River Workbench","type":"tags"},{"content":"","date":"2026-04-27","externalUrl":null,"permalink":"/tags/freertos/","section":"Tags","summary":"","title":"FreeRTOS","type":"tags"},{"content":" How to Choose the Best RTOS for Embedded Systems\nChoosing the right Real-Time Operating System (RTOS) is a foundational architectural decision that directly impacts system determinism, fault isolation, scalability, and long-term maintainability.\nFor experienced developers, this is not just a feature comparison exercise—it is a trade-off analysis across latency guarantees, scheduling behavior, memory model, ecosystem maturity, and certification requirements.\nThis guide goes beyond basics and provides a structured, engineering-focused approach to selecting the most appropriate RTOS for your system.\n🧠 What Defines a Real-Time Operating System # An RTOS is fundamentally defined by its ability to provide deterministic timing guarantees.\nUnlike general-purpose systems, where latency is statistical, an RTOS must ensure:\nBounded interrupt latency Predictable task scheduling Deterministic inter-task communication The goal is not maximum throughput—but temporal correctness.\nRTOS vs General-Purpose OS (GPOS) # Dimension RTOS GPOS Scheduling Priority-based, deterministic Fairness/time-sliced Latency Bounded (analyzable) Variable/unbounded Memory Model Static or controlled dynamic Fully virtualized Failure Isolation Limited to strong (depends) Strong (process isolation) Use Case Control systems User-facing applications A critical nuance: modern RTOS (e.g., VxWorks, QNX) increasingly adopt process isolation and MMU support, blurring traditional boundaries with GPOS.\n⚙️ Core RTOS Architecture Components # A production-grade RTOS is defined by how well its internal subsystems cooperate under load.\nTask Scheduler # Typically preemptive priority-based May support: Fixed-priority scheduling Rate-monotonic scheduling (RMS) Earliest-deadline-first (EDF) Interrupt Handling # Fast ISR execution is critical Deferred work handled via: Bottom halves Task-level handlers Inter-Process Communication (IPC) # Message queues Pipes Shared memory Zero-copy mechanisms (high-performance systems) Synchronization # Mutexes (with priority inheritance) Semaphores Spinlocks (SMP systems) Memory Management # Static allocation (deterministic) Partitioned heaps MMU/MPU-based isolation (advanced RTOS) ⏱️ RTOS Timing Models Explained # Understanding timing guarantees is essential for correct system classification.\nHard Real-Time # Missing a deadline = system failure Requires: Worst-case execution time (WCET) analysis Formal verification in some domains Typical domains:\nFlight control systems Medical life-support devices Soft Real-Time # Occasional deadline misses are acceptable Focus on average latency and throughput Typical domains:\nMultimedia processing Smart devices Firm Real-Time # Missed deadlines invalidate results, but no catastrophic failure Common in economic/efficiency-sensitive systems Typical domains:\nTelecom switching Trading systems 📊 Advantages and Trade-Offs of RTOS # ✅ Advantages # Area Impact Determinism Enables predictable system behavior Low Latency Critical for control loops Efficiency Minimal overhead vs GPOS Fine-Grained Control Precise scheduling and resource tuning ❌ Trade-Offs # Area Challenge Complexity Requires deep system knowledge Debugging Difficulty Concurrency issues are harder to trace Feature Limitations Less rich than Linux/Unix ecosystems Cost Commercial RTOS licensing can be significant A key engineering trade-off: bare-metal vs RTOS vs Linux hybrid designs.\n🧩 Key Decision Criteria for RTOS Selection # 1. Determinism and Latency Budget # Define:\nMaximum interrupt latency Scheduling jitter tolerance Deadline constraints If you cannot quantify these, you cannot choose correctly.\n2. System Architecture (Monolithic vs Microkernel) # Monolithic RTOS (e.g., FreeRTOS)\nLower overhead Less isolation Microkernel RTOS (e.g., QNX)\nStrong isolation Higher IPC overhead Hybrid (e.g., VxWorks 6+)\nCombines kernel + user space flexibility 3. Memory Model and Safety # No MMU → faster, less safe MMU-enabled → safer, slightly higher overhead For safety-critical systems:\nMemory protection is often mandatory 4. SMP and Multicore Support # Modern systems require:\nSymmetric multiprocessing (SMP) CPU affinity control Load balancing Not all RTOS handle multicore equally well.\n5. Ecosystem and Toolchain # Evaluate:\nDebugging tools (trace, profiling) BSP availability Middleware (networking, file systems, security) Vendor support quality This often matters more than kernel features.\n6. Certification and Compliance # If your domain requires:\nISO 26262 (automotive) DO-178C (avionics) IEC 62304 (medical) Then your RTOS choice is heavily constrained.\n7. Total Cost of Ownership (TCO) # Consider:\nLicensing fees Maintenance costs Engineering effort Long-term support Open-source is not always cheaper in regulated environments.\n🔍 RTOS Comparison: Leading Platforms # FreeRTOS # Minimal footprint Widely used in IoT Limited isolation features Best for:\nResource-constrained devices VxWorks # High reliability and determinism Strong tooling and certification support Supports user/kernel separation Best for:\nAerospace, defense, industrial control QNX # True microkernel architecture Strong fault isolation POSIX-compliant Best for:\nAutomotive (ADAS), medical systems Zephyr # Modern, modular RTOS Strong security model Backed by Linux Foundation Best for:\nIoT and connected devices ThreadX (Azure RTOS) # Extremely small footprint Pre-certified in some domains Best for:\nMedical and industrial embedded systems 🌍 RTOS in Modern System Architectures # RTOS is no longer deployed in isolation.\nCommon modern patterns:\nRTOS + Linux Hybrid # RTOS handles real-time tasks Linux handles UI/networking Disaggregated Systems # RTOS nodes for control Cloud/edge systems for analytics AI + RTOS Integration # RTOS manages deterministic pipelines Accelerators handle inference workloads 🏭 Real-World Application Domains # Domain RTOS Role Industrial Automation Deterministic control loops Automotive ECU, ADAS, functional safety Medical Life-critical monitoring/control Aerospace Flight systems, avionics IoT Low-power, event-driven control 🚀 Conclusion # Selecting the right RTOS is a system-level decision, not just a software choice.\nThe optimal RTOS depends on:\nYour timing guarantees Your safety requirements Your hardware constraints Your team expertise Your long-term scalability needs In practice:\nChoose FreeRTOS or Zephyr for lightweight IoT systems Choose VxWorks or QNX for safety-critical, high-reliability systems Consider hybrid architectures when combining real-time control with rich applications Ultimately, the best RTOS is the one that delivers predictable behavior under worst-case conditions—not just good performance under ideal ones.\n","date":"2026-04-27","externalUrl":null,"permalink":"/training/how-to-choose-the-best-rtos-for-embedded-systems/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eHow to Choose the Best RTOS for Embedded Systems\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eChoosing the right \u003cstrong\u003eReal-Time Operating System (RTOS)\u003c/strong\u003e is a foundational architectural decision that directly impacts system determinism, fault isolation, scalability, and long-term maintainability.\u003c/p\u003e","title":"How to Choose the Best RTOS for Embedded Systems","type":"training"},{"content":"","date":"2026-04-27","externalUrl":null,"permalink":"/tags/qnx/","section":"Tags","summary":"","title":"QNX","type":"tags"},{"content":"","date":"2026-04-27","externalUrl":null,"permalink":"/tags/system-architecture/","section":"Tags","summary":"","title":"System Architecture","type":"tags"},{"content":"","date":"2026-04-27","externalUrl":null,"permalink":"/tags/zephyr/","section":"Tags","summary":"","title":"Zephyr","type":"tags"},{"content":"","date":"2026-04-26","externalUrl":null,"permalink":"/tags/adas/","section":"Tags","summary":"","title":"ADAS","type":"tags"},{"content":"","date":"2026-04-26","externalUrl":null,"permalink":"/tags/autonomous-driving/","section":"Tags","summary":"","title":"Autonomous-Driving","type":"tags"},{"content":"","date":"2026-04-26","externalUrl":null,"permalink":"/tags/iso-26262/","section":"Tags","summary":"","title":"ISO 26262","type":"tags"},{"content":" VxWorks for Automotive: RTOS for Safety-Critical Vehicle Systems\n🚗 Automotive Industry Evolution # The automotive industry is undergoing a fundamental transformation driven by connectivity, electrification, and autonomous driving. Vehicles are no longer isolated mechanical systems—they are now distributed computing platforms executing increasingly complex software workloads.\nThis shift introduces competing constraints:\nHigher compute density for AI and ADAS workloads Strict safety and determinism requirements Constraints on power, thermal footprint, and system cost Increasing cybersecurity exposure due to connectivity Modern automotive architectures must balance performance, safety, and scalability while maintaining strict isolation between system functions.\n⚠️ Core Automotive Challenges # System Complexity vs Reliability # As software-defined features grow, ensuring system integrity without introducing unintended interactions becomes significantly harder.\nCost, Weight, and Power Optimization # Electrification amplifies the importance of:\nReduced hardware footprint Lower power consumption Efficient thermal design Safety Certification Overhead # Meeting standards such as ISO 26262 (ASIL levels) adds significant development and validation costs.\nReal-Time Determinism # Safety-critical functions—such as braking or steering—require predictable, bounded latency.\nCybersecurity Requirements # Connected vehicles must defend against:\nRemote intrusion Data tampering Firmware compromise 🧠 Why VxWorks for Automotive Systems # VxWorks is a production-proven RTOS designed for deterministic, safety-critical environments. Its architecture directly addresses automotive system constraints.\nKey Capabilities # Strong time and space isolation Support for multi-core workload consolidation Pre-certified components for safety standards Built-in security mechanisms Broad CPU and BSP ecosystem 🛡️ Isolation for Mixed-Criticality Workloads # Time and Space Partitioning # VxWorks enforces strict separation between workloads:\nTime partitioning ensures guaranteed CPU allocation Space partitioning isolates memory regions Example: Time Partition Configuration # /* Conceptual scheduler configuration */ WIND_SCHED_PARTITION_CFG partitionCfg; partitionCfg.period = 10000; /* microseconds */ partitionCfg.slots[0].duration = 4000; /* Safety-critical task */ partitionCfg.slots[1].duration = 6000; /* Non-critical task */ schedPartitionCreate(\u0026amp;partitionCfg); This ensures compute-heavy workloads (e.g., AI inference) cannot starve safety-critical control loops.\n🔄 Workload Consolidation via Virtualization # Modern vehicles often deploy multiple ECUs for isolated functions. This approach is inefficient given the capabilities of modern multi-core SoCs.\nVxWorks enables consolidation using virtualization.\nExample Architecture # Safety-critical RTOS (VxWorks) General-purpose OS (Linux) Shared hardware platform Hypervisor-Based Deployment (Conceptual) # /* Pseudo configuration for partitioned guest systems */ guest0.os = VXWORKS; guest0.cores = \u0026#34;0-1\u0026#34;; guest1.os = LINUX; guest1.cores = \u0026#34;2-3\u0026#34;; hypervisorStart(); This reduces:\nHardware cost System weight Integration complexity 📜 Pre-Certified Safety for Faster Deployment # VxWorks is certified to:\nISO 26262 ASIL D This provides:\nReduced certification effort Pre-validated safety artifacts Faster time-to-market Developers can focus on application logic rather than re-validating the OS.\n⚡ Deterministic Real-Time Performance # Kernel-Level Predictability # VxWorks separates core kernel execution from optional subsystems, reducing jitter and improving determinism.\nExample: Real-Time Task Configuration # /* High-priority real-time task */ TASK_ID tid; tid = taskSpawn(\u0026#34;tControl\u0026#34;, 90, /* priority */ VX_FP_TASK, /* floating point support */ 4096, /* stack size */ controlTask, /* entry point */ 0,0,0,0,0,0,0,0,0,0); This ensures bounded execution latency for safety-critical control loops.\n🔐 Built-In Cybersecurity Capabilities # Connected vehicles require security across the entire lifecycle.\nVxWorks Security Features # Secure boot chain TPM integration Memory protection Kernel hardening Encrypted communication Example: Secure Boot Concept # /* Simplified secure boot verification flow */ if (verifySignature(kernelImage) != OK) { printf(\u0026#34;Kernel verification failed\\n\u0026#34;); reboot(); } Security enforcement begins at boot and continues through runtime.\n🧩 Processor Flexibility and BSP Support # Automotive platforms require flexibility across vehicle segments.\nVxWorks supports a wide range of architectures:\nArm PowerPC Intel x86 NXP, Renesas, Xilinx SoCs This enables:\nEarly prototyping Vendor flexibility Optimized cost-performance tradeoffs 🚀 Application Domains # VxWorks is deployed across multiple automotive systems:\nAutonomous driving platforms Advanced driver-assistance systems (ADAS) Digital instrument clusters Telematics control units In-vehicle infotainment (IVI) ✅ Conclusion # Automotive systems are transitioning toward highly integrated, software-defined platforms with mixed-criticality workloads. This evolution demands an RTOS that can deliver:\nDeterministic real-time performance Strong safety isolation Scalable multi-core utilization End-to-end security VxWorks meets these requirements through its mature architecture, certified safety foundation, and support for modern deployment models such as virtualization and workload consolidation.\nFor automotive developers building next-generation systems, VxWorks provides a proven and scalable platform for delivering safe, secure, and high-performance vehicle software.\n","date":"2026-04-26","externalUrl":null,"permalink":"/industries/vxworks-for-automotive-rtos-for-safety-critical-vehicle-systems/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks for Automotive: RTOS for Safety-Critical Vehicle Systems\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🚗 Automotive Industry Evolution \n    \u003cdiv id=\"-automotive-industry-evolution\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-automotive-industry-evolution\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThe automotive industry is undergoing a fundamental transformation driven by connectivity, electrification, and autonomous driving. Vehicles are no longer isolated mechanical systems—they are now distributed computing platforms executing increasingly complex software workloads.\u003c/p\u003e","title":"VxWorks for Automotive: RTOS for Safety-Critical Vehicle Systems","type":"industries"},{"content":"","date":"2026-04-26","externalUrl":null,"permalink":"/tags/archive-library/","section":"Tags","summary":"","title":"Archive Library","type":"tags"},{"content":" Build Self-Booting VxWorks Images with Archive Libraries (.a)\n🔍 Overview # Modern embedded systems increasingly require autonomous operation without manual intervention. A common production requirement is a self-booting VxWorks image that integrates both the operating system and user applications into a single binary, enabling automatic execution at power-on.\nThis article presents a practical and scalable approach for building self-booting VxWorks images. It compares traditional static linking methods with a more maintainable and optimized approach using archive libraries (.a), including concrete build examples and integration techniques.\n⚙️ VxWorks System Composition # A typical VxWorks-based system consists of three core components:\nbootrom: Initializes hardware and loads the OS VxWorks kernel: Provides RTOS services User applications: Implement system functionality Development vs Deployment Model # Phase Component Description Development bootrom Hardware-specific initialization, stored in ROM VxWorks Kernel image, downloaded or loaded User Programs Developed and debugged independently Deployment bootrom Fixed in ROM VxWorks + User Applications Integrated and stored in Flash A self-booting image combines VxWorks and user applications into a single executable that runs automatically after system startup.\n🚀 Self-Booting Image Creation Methods # Static Linking Overview # Static linking embeds user code directly into the VxWorks image. Two approaches are commonly used:\n🧩 Method 1: Linking Source Files (.c) # Integration Example # /* usrConfig.c */ #include \u0026#34;usrAPI/myApp.c\u0026#34; void usrRoot(char *pMemPoolStart, unsigned memPoolSize) { /* VxWorks initialization */ myAppInit(); /* Start user application */ } Characteristics # Simple integration Requires direct source inclusion Poor portability across BSPs Exposes source code 🧩 Method 2: Linking Object Files (.o) # Makefile Integration # # Makefile LIB_EXTRA = \\ usrAPI/app1.o \\ usrAPI/app2.o Header Declaration # /* usrAPI.h */ #ifndef __USR_API_H__ #define __USR_API_H__ void app1Init(void); void app2Init(void); #endif Usage in usrRoot # #include \u0026#34;usrAPI/usrAPI.h\u0026#34; void usrRoot(char *pMemPoolStart, unsigned memPoolSize) { app1Init(); app2Init(); } Characteristics # Keeps BSP and application code separate Protects source code (binary distribution) Maintains clean project structure 📦 Archive Library Method (.a) — Recommended # Why Use Archive Libraries # Using .a libraries provides:\nAutomatic inclusion of only referenced symbols Reduced final image size Clean separation of modules Simplified portability across BSPs 🛠️ Step 1: Create Archive Library # Build Script (makea.bat) # @echo off set WIND_HOST_TYPE=x86-win32 set WIND_BASE=C:\\Tornado set PATH=%WIND_BASE%\\host\\%WIND_HOST_TYPE%\\bin;%PATH% rem Create archive library for PowerPC arppc -crusv usrAPI.a app1.o app2.o utils.o 🛠️ Step 2: Integrate Library into VxWorks # Makefile Configuration # # Makefile LIB_EXTRA = usrAPI/usrAPI.a 🛠️ Step 3: Header Interface # /* usrAPI.h */ #ifndef __USR_API_H__ #define __USR_API_H__ void app1Init(void); void app2Init(void); void utilsInit(void); #endif 🛠️ Step 4: Application Entry Hook # #include \u0026#34;usrAPI/usrAPI.h\u0026#34; void usrRoot(char *pMemPoolStart, unsigned memPoolSize) { app1Init(); app2Init(); } 🛠️ Step 5: Full Build Process # makeclean makeall 🔄 Updating User Applications # To update application logic without restructuring:\nRecompile .o files Rebuild archive: arppc -crusv usrAPI.a *.o Force rebuild: makeclean makeall ⚖️ Method Comparison # Method Pros Cons .c Linking Simple, no Makefile changes Poor portability, exposes source .o Linking Clean structure, protects IP Includes all symbols .a Linking Optimized size, modular, portable Slightly more setup 🔧 BSP Integration Notes # Place usrAPI under BSP directory Modify config.h for feature inclusion Customize boot behavior via bootconfig.c Example: Auto-Boot Configuration # /* bootconfig.c */ void autoboot(void) { sysClkRateSet(100); printf(\u0026#34;Auto booting VxWorks with user app...\\n\u0026#34;); } ✅ Conclusion # Creating a self-booting VxWorks image is essential for production-grade embedded systems. While traditional static linking methods remain viable, the archive library (.a) approach offers clear advantages:\nSmaller and optimized binaries Better code organization Easier cross-platform portability Improved maintainability For modern embedded workflows, especially in large-scale or multi-platform deployments, the .a-based integration method provides the most robust and scalable solution.\n","date":"2026-04-26","externalUrl":null,"permalink":"/training/build-self-booting-vxworks-images-with-archive-libraries/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eBuild Self-Booting VxWorks Images with Archive Libraries (.a)\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🔍 Overview \n    \u003cdiv id=\"-overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eModern embedded systems increasingly require autonomous operation without manual intervention. A common production requirement is a \u003cstrong\u003eself-booting VxWorks image\u003c/strong\u003e that integrates both the operating system and user applications into a single binary, enabling automatic execution at power-on.\u003c/p\u003e","title":"Build Self-Booting VxWorks Images with Archive Libraries (.a)","type":"training"},{"content":"","date":"2026-04-26","externalUrl":null,"permalink":"/tags/static-linking/","section":"Tags","summary":"","title":"Static Linking","type":"tags"},{"content":"","date":"2026-04-26","externalUrl":null,"permalink":"/tags/t2080/","section":"Tags","summary":"","title":"T2080","type":"tags"},{"content":" VxWorks 7 on T2080: BSP, U-Boot, and Kernel Adaptation Guide\n🔍 Overview # VxWorks is a production-grade RTOS widely used in aerospace, defense, and industrial systems where deterministic performance is critical. VxWorks 7 introduces a modular architecture, Device Tree support, and an updated driver framework (VxBus GEN2), significantly improving portability and maintainability.\nThis guide walks through the full adaptation of VxWorks 7 on the NXP T2080 processor, including U-Boot porting, BSP development, kernel configuration, Device Tree integration, and driver implementation—with practical code examples.\n⚙️ T2080 Platform and System Context # The T2080 is a QorIQ-series PowerPC SoC with:\nQuad-core, 8-thread architecture High-performance SIMD (AltiVec) engine Designed for networking, radar, and signal processing workloads Its architecture makes it a strong candidate for high-throughput RTOS deployments.\n🚀 Bootloader Development with U-Boot # Bootloader Responsibilities # The bootloader initializes hardware and loads the kernel:\nDDR and clock initialization MMU setup Peripheral initialization Kernel loading (Flash, eMMC, or network) VxWorks 7 standardizes on U-Boot, replacing legacy bootrom.\n🧩 U-Boot Board Configuration Example # A custom board is typically derived from a reference design (e.g., t208xrdb).\nBoard Header Configuration (include/configs/t208xleihua.h) # #ifndef __T208X_LEIHUA_H #define __T208X_LEIHUA_H #define CONFIG_SYS_SDRAM_SIZE (2 * 1024 * 1024 * 1024ULL) /* 2GB DDR */ #define CONFIG_SYS_INIT_RAM_ADDR 0xfdd00000 #define CONFIG_SYS_INIT_RAM_SIZE 0x00004000 #define CONFIG_HOSTNAME \u0026#34;t2080_leihua\u0026#34; #define CONFIG_BOOTCOMMAND \u0026#34;bootm 0x1000000 - 0x2000000\u0026#34; #define CONFIG_PHY_ADDR 0x1 #define CONFIG_NETMASK 255.255.255.0 #define CONFIG_IPADDR 192.168.1.100 #endif 🔄 U-Boot Initialization Snippet # Early Boot Entry (start.S excerpt) # .globl _start _start: bl cpu_init_f /* early CPU init */ bl board_init_f /* board-specific init */ bl relocate_code /* relocate to DDR */ 🛠️ Build Example # export CROSS_COMPILE=powerpc-linux-gnuspe- make T2080RDB_defconfig make -j8 🧠 VxWorks 7 Kernel and BSP Development # VSB and VIP Workflow # VxWorks 7 separates build stages:\nVSB: builds core OS libraries VIP: assembles final image and integrates BSP + DTS ⚙️ VIP Kernel Configuration Example # Within Workbench or CLI:\nvxprj vip create -force -vsb my_vsb -bsp t2080 cd my_vip vxprj component add INCLUDE_NET_STACK vxprj component add INCLUDE_IPCOM vxprj build 🌳 Device Tree Integration # DTS Example for T2080 Board # / { model = \u0026#34;T2080 Leihua Board\u0026#34;; compatible = \u0026#34;fsl,t2080\u0026#34;; memory { device_type = \u0026#34;memory\u0026#34;; reg = \u0026lt;0x0 0x80000000\u0026gt;; /* 2GB */ }; soc { ethernet@24000 { compatible = \u0026#34;fsl,t2080-gemac\u0026#34;; reg = \u0026lt;0x24000 0x1000\u0026gt;; phy-handle = \u0026lt;\u0026amp;phy0\u0026gt;; }; phy0: ethernet-phy@1 { reg = \u0026lt;1\u0026gt;; }; }; }; Compile Device Tree # dtc -I dts -O dtb -o t2080.dtb t2080.dts Load DTB in U-Boot # tftp 0x1000000 vxWorks.bin tftp 0x2000000 t2080.dtb bootm 0x1000000 - 0x2000000 🔌 Driver Development with VxBus GEN2 # Basic Driver Skeleton # Driver Registration # LOCAL VXB_DRV myDrv; LOCAL STATUS myDrvProbe(VXB_DEV_ID pDev) { return OK; } LOCAL STATUS myDrvAttach(VXB_DEV_ID pDev) { printf(\u0026#34;My driver attached\\n\u0026#34;); return OK; } VXB_DRV myDrv = { {NULL}, \u0026#34;myDevice\u0026#34;, \u0026#34;My Custom Driver\u0026#34;, VXB_BUSID_FDT, 0, 0, myDrvProbe, myDrvAttach, NULL }; VXB_DRV_DEF(myDrv) Device Tree Binding Example # mydevice@30000 { compatible = \u0026#34;leihua,mydevice\u0026#34;; reg = \u0026lt;0x30000 0x1000\u0026gt;; }; Matching Table # LOCAL const VXB_FDT_DEV_MATCH_ENTRY myMatch[] = { { \u0026#34;leihua,mydevice\u0026#34;, NULL }, { NULL } }; DKM Build Example # CPU = PPC32 TOOL = gnu OBJS = myDriver.o all: $(CC) -c myDriver.c $(LD) -r -o myDriver.out $(OBJS) 🔧 Custom Hardware Example (SRIO Concept) # For shared-register hardware like SRIO:\nRepresent as a single device node Expose multiple logical ports Handle resource sharing in driver ✅ Conclusion # Porting VxWorks 7 to the T2080 platform involves coordinated development across bootloader, BSP, kernel, Device Tree, and drivers.\nKey takeaways:\nU-Boot simplifies early-stage bring-up Device Tree enables flexible hardware abstraction VxBus GEN2 improves driver portability VSB/VIP split enhances build modularity This workflow provides a reusable reference for adapting VxWorks 7 to other PowerPC-based embedded systems requiring high-performance real-time capabilities.\n","date":"2026-04-26","externalUrl":null,"permalink":"/bsp/vxworks-7-on-t2080-bsp-u-boot-and-kernel-adaptation-guide/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 7 on T2080: BSP, U-Boot, and Kernel Adaptation Guide\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🔍 Overview \n    \u003cdiv id=\"-overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eVxWorks is a production-grade RTOS widely used in aerospace, defense, and industrial systems where deterministic performance is critical. VxWorks 7 introduces a modular architecture, Device Tree support, and an updated driver framework (VxBus GEN2), significantly improving portability and maintainability.\u003c/p\u003e","title":"VxWorks 7 on T2080: BSP, U-Boot, and Kernel Adaptation Guide","type":"bsp"},{"content":"","date":"2026-04-25","externalUrl":null,"permalink":"/tags/m/m/1/","section":"Tags","summary":"","title":"M/M/1","type":"tags"},{"content":"","date":"2026-04-25","externalUrl":null,"permalink":"/tags/network-performance/","section":"Tags","summary":"","title":"Network Performance","type":"tags"},{"content":"","date":"2026-04-25","externalUrl":null,"permalink":"/tags/performance-modeling/","section":"Tags","summary":"","title":"Performance Modeling","type":"tags"},{"content":"","date":"2026-04-25","externalUrl":null,"permalink":"/tags/queueing-theory/","section":"Tags","summary":"","title":"Queueing Theory","type":"tags"},{"content":"","date":"2026-04-25","externalUrl":null,"permalink":"/tags/socket-communication/","section":"Tags","summary":"","title":"Socket Communication","type":"tags"},{"content":" VxWorks Network Performance Modeling Using M/M/1 Queue Theory\nIn real-time embedded systems, network communication latency and determinism are critical factors that directly affect system stability and responsiveness. For systems built on VxWorks, socket-based communication performance becomes a key bottleneck under high load.\nThis article presents a mathematical modeling approach using M/M/1 queueing theory to analyze and predict network performance in VxWorks environments, providing a foundation for systematic optimization.\n📡 Modeling Network Behavior in VxWorks # System Abstraction # The network subsystem is modeled as a single-server queue:\nIncoming packets → arrival process Network stack + processing → service mechanism Socket buffers → queue Modeling Assumptions # To construct a tractable model:\nPacket arrivals follow a Poisson process with rate λ Service time follows an exponential distribution with rate μ Single service channel (e.g., NIC or processing thread) Infinite or sufficiently large buffer First-Come-First-Served (FCFS) scheduling The system must satisfy the stability condition:\n$$ [ \\rho = \\frac{\\lambda}{\\mu} \u0026lt; 1 ] $$\nwhere ρ represents system utilization.\n📊 Core Performance Metrics # The M/M/1 model provides closed-form solutions for steady-state behavior.\nState Probability Distribution # $$ [ P_n = (1 - \\rho)\\rho^n ] $$\nAverage System Load # $$ [ L = \\frac{\\rho}{1 - \\rho} ] $$\nQueue Length # $$ [ L_q = \\frac{\\rho^2}{1 - \\rho} ] $$\nWaiting Time in Queue # $$ [ W_q = \\frac{\\rho}{\\mu(1 - \\rho)} ] $$\nTotal System Time # $$ [ W = \\frac{1}{\\mu(1 - \\rho)} ] $$\nIdle Probability # $$ [ P_0 = 1 - \\rho ] $$\nThese metrics quantify latency, congestion, and throughput behavior under varying load conditions.\n⚙️ Visualization of the Core Model # $$ [ L = ρ / (1 − ρ) ] $$\nThis expression highlights the nonlinear growth of system load as utilization approaches saturation.\n🧮 Cost Function and Optimization # To balance delay and resource usage, a cost function is introduced:\n$$ [ F(L) = c_1 L_q + c_2 L ] $$\nSubstituting model expressions:\n$$ [ F(L) = c_1 \\frac{\\rho^2}{1 - \\rho} + c_2 \\frac{\\rho}{1 - \\rho} ] $$\nOptimization Insight # Increasing ρ improves throughput but increases delay Lower ρ reduces latency but wastes resources The optimal utilization can be approximated as:\n$$ [ \\rho^* = \\frac{c_2}{c_1 + c_2} ] $$\nThis provides a practical guideline for tuning system load.\n🚀 Performance Implications in VxWorks # Sensitivity to Load # As λ approaches μ:\nQueue length grows exponentially Waiting time increases sharply Real-time guarantees degrade This is especially critical in:\nIndustrial control systems Aerospace embedded platforms High-frequency data acquisition System-Level Influencing Factors # Interrupt latency Network driver efficiency Socket buffer configuration Task scheduling priorities 🔧 Optimization Strategies # Based on the model, several improvements can be applied:\nIncrease Service Rate (μ) # Optimize network drivers Use zero-copy mechanisms Offload processing to hardware (DMA, NIC acceleration) Control Arrival Rate (λ) # Traffic shaping Rate limiting Load balancing across interfaces Buffer and Scheduling Tuning # Adjust socket buffer sizes Prioritize real-time tasks Reduce contention in interrupt handling 📈 Practical Engineering Insights # Avoid operating near ρ → 1; performance collapses nonlinearly Design for headroom (typically ρ \u0026lt; 0.7–0.8 in real-time systems) Use analytical models early in system design—not only post-deployment testing 🧾 Conclusion # The M/M/1 queueing model provides a concise and effective framework for analyzing network performance in VxWorks-based systems. By deriving closed-form expressions for latency, queue length, and utilization, developers gain predictive insight into system behavior under varying workloads.\nThis approach enables:\nQuantitative performance evaluation Informed system tuning Better real-time reliability Future extensions can incorporate multi-server models (M/M/c), priority queues, and bursty traffic models to better reflect modern multi-core and multi-interface embedded systems.\n","date":"2026-04-25","externalUrl":null,"permalink":"/app/vxworks-network-performance-modeling-using-m-m-1-queue-theory/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Network Performance Modeling Using M/M/1 Queue Theory\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eIn real-time embedded systems, network communication latency and determinism are critical factors that directly affect system stability and responsiveness. For systems built on VxWorks, socket-based communication performance becomes a key bottleneck under high load.\u003c/p\u003e","title":"VxWorks Network Performance Modeling Using M/M/1 Queue Theory","type":"app"},{"content":"","date":"2026-04-25","externalUrl":null,"permalink":"/tags/dkm/","section":"Tags","summary":"","title":"DKM","type":"tags"},{"content":"","date":"2026-04-25","externalUrl":null,"permalink":"/tags/google-test/","section":"Tags","summary":"","title":"Google Test","type":"tags"},{"content":" Google Test on VxWorks 7: DKM and RTP Integration Guide\nUnit testing in embedded systems is often overlooked due to tooling complexity and runtime constraints. However, integrating Google Test (gtest) into VxWorks 7 enables a modern, structured testing workflow across both kernel-space (DKM) and user-space (RTP) components.\nThis guide provides a practical, production-oriented approach to building and integrating Google Test into VxWorks projects.\n🚀 Overview # Google Test support for VxWorks is delivered as a static library layer, which can be linked into:\nDKM (Dynamic Kernel Modules) RTP (Real-Time Processes) The integration leverages VxWorks\u0026rsquo; layer mechanism and standard build system, allowing test execution directly within the target environment.\nKey Benefits # Consistent unit testing across kernel and user space Familiar C++ testing framework (fixtures, assertions, test runners) Improved code quality and regression detection ⚙️ Prerequisites # Before integration, ensure the following environment is ready:\nVxWorks 7 (SR0610 or later) Git installed and accessible Network access to retrieve source packages Required Package # Download the VxWorks-compatible Google Test layer:\nRepository: vxworks7-google-test (Wind River GitHub) 🧩 Environment Setup # Configure Layer Path # Set the WIND_LAYER_PATHS environment variable to include the downloaded package:\nexport WIND_LAYER_PATHS=/path/to/vxworks7-google-test Verify Layer Availability # Confirm that the Google Test layer is recognized:\nvxprj vsb listAll Expected entry:\nGTEST_1_8_0_0 🏗️ Building VSB and VIP # Google Test must be enabled at the VSB (source build) level and included in the runtime image (VIP).\nCreate and Configure VSB # export WIND_WRTOOL_WORKSPACE=$HOME/WindRiver/workspace cd $WIND_WRTOOL_WORKSPACE wrtool prj vsb create -force -bsp vxsim_linux myVSB -S cd myVSB wrtool prj vsb config -w -add _WRS_CONFIG_GTEST=y make -j$(nproc) cd .. Create VIP with Google Test # wrtool prj vip create -force -vsb myVSB -profile PROFILE_STANDALONE_DEVELOPMENT vxsim_linux llvm myVIP cd myVIP wrtool prj vip component add INCLUDE_GTEST cd .. This ensures the gtest runtime is available in the target image.\n🧪 Using Google Test in RTP Projects # RTPs provide user-space isolation, making them ideal for most unit testing scenarios.\nSteps # Create a .cc test file Write standard Google Test cases Link against the gtest static library Linker Configuration # -l ${VSB_DIR}/usr/*/common/libgtest.a Build # Compile the RTP project normally. The test entry point is automatically generated by gtest.\n🔧 Using Google Test in DKM Projects # DKMs run in kernel space, requiring explicit test initialization and cleanup.\nMinimal Test Entry # int main() { int argc = 1; char *argv = (char *)\u0026#34;dkm path\u0026#34;; ::testing::InitGoogleTest(\u0026amp;argc, \u0026amp;argv); return RUN_ALL_TESTS_AND_UNLOAD_SELF(); } Linker Configuration # -L $(VSB_DIR)/krnl/SIMLINUX/common -l gtest Key Constraints # Only one gtest instance can exist in kernel space Each DKM must be unloaded before running another test ⚠️ DKM-Specific Considerations # Namespace Limitations # Kernel space does not isolate symbols between modules Avoid multiple simultaneous test modules Unloading Strategy # Use helper macros:\nGTEST_UNLOAD_SELF RUN_ALL_TESTS_AND_UNLOAD_SELF Optional Result Handling # int main() { int argc = 1; char *argv = (char *)\u0026#34;dkm path\u0026#34;; ::testing::InitGoogleTest(\u0026amp;argc, \u0026amp;argv); int ret = RUN_ALL_TESTS(); if (ret \u0026gt; 0) { // Handle failures if needed } return GTEST_UNLOAD_SELF(); } 🔍 Best Practices # Test Placement # Use RTP for most unit tests (safer, isolated) Reserve DKM tests for kernel-specific logic Build Strategy # Integrate gtest at VSB level for consistency Maintain separate test targets from production builds Debugging # Use VxWorks shell and logging for runtime inspection Combine with system tools for deeper analysis Maintainability # Organize tests by module or feature Use fixtures for reusable setup/teardown logic ⚖️ Licensing Notes # Google Test is distributed under the BSD 3-Clause License, allowing flexible usage and redistribution. Some files may include additional license notices, which should be reviewed individually.\nThis VxWorks integration layer adapts Google Test for compatibility but is typically provided without official support, and should be validated within your development workflow.\n📌 Conclusion # Integrating Google Test into VxWorks 7 brings modern unit testing practices into embedded development. By supporting both RTP and DKM environments, developers gain flexibility in validating code across system boundaries.\nWith proper integration at the VSB level and disciplined test design, gtest can significantly improve code reliability, accelerate debugging, and enable scalable testing pipelines in VxWorks-based systems.\n","date":"2026-04-25","externalUrl":null,"permalink":"/app/google-test-on-vxworks-7-dkm-and-rtp-integration-guide/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eGoogle Test on VxWorks 7: DKM and RTP Integration Guide\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eUnit testing in embedded systems is often overlooked due to tooling complexity and runtime constraints. However, integrating \u003cstrong\u003eGoogle Test (gtest)\u003c/strong\u003e into VxWorks 7 enables a modern, structured testing workflow across both kernel-space (DKM) and user-space (RTP) components.\u003c/p\u003e","title":"Google Test on VxWorks 7: DKM and RTP Integration Guide","type":"app"},{"content":"","date":"2026-04-25","externalUrl":null,"permalink":"/tags/unit-testing/","section":"Tags","summary":"","title":"Unit Testing","type":"tags"},{"content":"","date":"2026-04-24","externalUrl":null,"permalink":"/tags/distributed-systems/","section":"Tags","summary":"","title":"Distributed Systems","type":"tags"},{"content":"","date":"2026-04-24","externalUrl":null,"permalink":"/tags/flight-simulation/","section":"Tags","summary":"","title":"Flight Simulation","type":"tags"},{"content":"","date":"2026-04-24","externalUrl":null,"permalink":"/tags/multiprocessor/","section":"Tags","summary":"","title":"Multiprocessor","type":"tags"},{"content":" VxWorks Flight Simulator RT System: Architecture and Design\nEngineering flight simulators demand strict real-time performance, deterministic execution, and reliable coordination across multiple subsystems. At the core of such systems lies a real-time management system, responsible for orchestrating computation, communication, and control.\nThis article presents the architecture and implementation of a VxWorks-based real-time management system designed for large-scale flight simulation platforms, with a focus on multitasking, multiprocessor coordination, and distributed data exchange.\n🚀 Introduction: Role of the Real-Time Management System # A flight simulation platform integrates multiple subsystems:\nSimulation computers Instructor control station Visual rendering system Motion platform Cockpit instruments and controls Audio and environmental modules The real-time management system acts as the central control layer, ensuring:\nDeterministic task scheduling Coordinated subsystem execution Real-time data consistency Fault detection and recovery Given the complexity and timing constraints, such systems are typically implemented using distributed multiprocessor architectures, requiring a robust RTOS foundation.\n⚙️ Why VxWorks for Flight Simulation # VxWorks is widely adopted in aerospace systems due to its deterministic behavior and modular design.\nCore Characteristics # Deterministic scheduling\nPriority-based preemptive scheduler with predictable latency\nMicrokernel architecture\nMinimal footprint with configurable components\nHigh reliability\nProven in mission-critical aerospace and defense systems\nMultiprocessor support\nSupports SMP and AMP configurations\nRich IPC mechanisms\nSemaphores, message queues, shared memory, and events\nDevelopment toolchain\nIntegrated debugging and analysis tools (e.g., WindView)\nThese features make VxWorks suitable for systems requiring strict timing guarantees and high system integrity.\n🧱 System Architecture: Distributed Multiprocessor Design # The flight simulation system is built on a distributed architecture, where computation is partitioned across multiple processors.\nCore Components # Simulation CPUs\nExecute real-time models such as flight dynamics, engines, and avionics\nManagement CPU (VxWorks)\nCoordinates scheduling, communication, and system control\nVME Bus Infrastructure\nProvides interconnection between processing units\nReflective Memory Network # To meet real-time communication requirements, the system uses reflective memory:\nDeterministic, low-latency data sharing Automatic memory replication across nodes Eliminates software overhead for synchronization This architecture ensures tight coupling between subsystems while maintaining scalability.\n🧩 Core Functions of the Management System # The real-time management layer implements several critical functions:\nSystem Initialization # Load simulation models Configure runtime parameters Activate subsystems in a controlled sequence Real-Time Scheduling # Manage periodic tasks (e.g., 20 ms simulation frames) Ensure deadline compliance across all subsystems Data Management # Handle real-time input/output streams Record and replay simulation data Support offline analysis Monitoring and Debugging # Provide graphical interfaces for operators Enable runtime parameter tuning Support fault injection and diagnostics Communication Control # Coordinate data exchange across processors Integrate shared memory, reflective memory, and network protocols 🔄 Multitasking and Scheduling Strategy # Efficient multitasking is essential to maintain deterministic behavior in real-time simulation.\nTask Management Techniques # Use taskSpawn, taskSuspend, and taskDelete for lifecycle control Assign priorities based on timing criticality Configure stack sizes to prevent overflow Real-Time Considerations # Avoid priority inversion using appropriate synchronization Minimize blocking operations in critical paths Apply CPU affinity in multiprocessor systems Performance Analysis # Use tools such as WindView to analyze: Task execution timelines Context switching behavior CPU utilization These techniques ensure predictable execution across all simulation tasks.\n🔗 Real-Time Data Communication # Data exchange is a critical factor in distributed simulation systems.\nReflective Memory Mechanism # Hardware-level memory synchronization Near-zero latency for shared data Suitable for tightly coupled simulation loops Network-Based Communication # Ethernet and TCP/IP for non-real-time data Used for supervisory control and external interfaces Optimization Strategies # Align data structures for efficient access Avoid redundant memory copies Synchronize communication cycles with simulation frames These optimizations reduce jitter and maintain timing consistency.\n🖥️ Human-Machine Interface Integration # The system includes graphical interfaces for monitoring and control:\nReal-time visualization of simulation parameters Interactive control panels for instructors Debugging tools for engineers Technologies such as X Window System or Motif are used to implement these interfaces, enabling efficient interaction with the simulation environment.\n📌 Conclusion # The VxWorks-based real-time management system described here demonstrates how deterministic scheduling, multiprocessor coordination, and efficient communication can be combined to support large-scale flight simulation.\nBy leveraging VxWorks’ strengths—predictability, modularity, and robust IPC—the system achieves:\nStable multitask execution Low-latency distributed communication High reliability under strict real-time constraints This architecture provides a proven blueprint for developing advanced simulation platforms and other mission-critical real-time systems in aerospace and beyond.\nReference: VxWorks Flight Simulator RT System: Architecture and Design\n","date":"2026-04-24","externalUrl":null,"permalink":"/app/vxworks-flight-simulator-real-time-system-architecture-and-design/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Flight Simulator RT System: Architecture and Design\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eEngineering flight simulators demand strict real-time performance, deterministic execution, and reliable coordination across multiple subsystems. At the core of such systems lies a \u003cstrong\u003ereal-time management system\u003c/strong\u003e, responsible for orchestrating computation, communication, and control.\u003c/p\u003e","title":"VxWorks Flight Simulator RT System: Architecture and Design","type":"app"},{"content":"","date":"2026-04-24","externalUrl":null,"permalink":"/tags/driver-development/","section":"Tags","summary":"","title":"Driver Development","type":"tags"},{"content":"","date":"2026-04-24","externalUrl":null,"permalink":"/tags/programming/","section":"Tags","summary":"","title":"Programming","type":"tags"},{"content":" VxWorks Device Driver Guide: Build a Simple Character Driver\nDevice drivers are the bridge between application code and hardware in VxWorks. While modern systems often rely on VxBus for complex hardware integration, the classic I/O system-based character driver remains a critical foundation—especially for understanding driver design, testing, and lightweight device abstractions.\nThis guide walks through a minimal yet practical implementation of a character device driver, showing how to integrate with the VxWorks I/O system and expose file-like interfaces to user tasks.\n🚀 Introduction to VxWorks Device Drivers # In VxWorks, device drivers provide a standardized interface for interacting with hardware or virtual devices.\nCore Characteristics # Integrated into the I/O system Expose file-like APIs (open, read, write, close) Allow user tasks to interact with devices using familiar POSIX-style calls This abstraction enables consistent interaction across real hardware and simulated devices.\n🧩 I/O System and Driver Model # The VxWorks I/O system manages device drivers through a registration mechanism.\nKey Components # Driver Table: Registered via iosDrvInstall() Device Node: Created using iosDevAdd() Driver Routines: Implement operations such as open, read, write Execution Flow # Driver is installed into the system Device node is registered (e.g., /myDev/) Applications open the device using standard APIs Driver routines handle the underlying operations This model is lightweight and ideal for simple drivers or early prototyping.\n💻 Example: Simple Character Device Driver # The following implementation creates a memory-backed character device /myDev/ that supports basic read and write operations.\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;iosLib.h\u0026gt; #include \u0026lt;errnoLib.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;string.h\u0026gt; #define BUFFER_SIZE 128 static char deviceBuffer[BUFFER_SIZE]; static int dataLength = 0; int myOpen(DEV_HDR *pDev, const char *name, int flags, int mode); int myClose(DEV_HDR *pDev); ssize_t myRead(DEV_HDR *pDev, char *buffer, size_t maxBytes); ssize_t myWrite(DEV_HDR *pDev, const char *buffer, size_t nBytes); typedef struct { DEV_HDR devHdr; } MY_DEV; MY_DEV myDevice; int myOpen(DEV_HDR *pDev, const char *name, int flags, int mode) { printf(\u0026#34;Device opened: %s\\n\u0026#34;, name); return (int)pDev; } int myClose(DEV_HDR *pDev) { printf(\u0026#34;Device closed\\n\u0026#34;); return 0; } ssize_t myRead(DEV_HDR *pDev, char *buffer, size_t maxBytes) { int bytesToCopy = (dataLength \u0026lt; maxBytes) ? dataLength : maxBytes; memcpy(buffer, deviceBuffer, bytesToCopy); printf(\u0026#34;Device read: %d bytes\\n\u0026#34;, bytesToCopy); return bytesToCopy; } ssize_t myWrite(DEV_HDR *pDev, const char *buffer, size_t nBytes) { int bytesToCopy = (nBytes \u0026lt; BUFFER_SIZE) ? nBytes : BUFFER_SIZE; memcpy(deviceBuffer, buffer, bytesToCopy); dataLength = bytesToCopy; printf(\u0026#34;Device write: %d bytes\\n\u0026#34;, bytesToCopy); return bytesToCopy; } void myDevCreate() { iosDrvInstall((FUNCPTR)myOpen, (FUNCPTR)myClose, (FUNCPTR)myOpen, (FUNCPTR)myClose, (FUNCPTR)myRead, (FUNCPTR)myWrite, NULL); iosDevAdd(\u0026amp;myDevice.devHdr, \u0026#34;/myDev/\u0026#34;, 0); printf(\u0026#34;Device /myDev/ created\\n\u0026#34;); } 📝 Code Breakdown # Driver Registration # iosDrvInstall() registers function pointers for driver operations Maps system calls to driver-specific implementations Device Creation # iosDevAdd() creates a device entry in the I/O system /myDev/ becomes accessible to user applications Core Operations # myWrite() copies user data into a kernel buffer myRead() retrieves stored data myOpen() and myClose() manage lifecycle hooks This pattern mirrors real hardware drivers, replacing memory buffers with actual device access.\n🔄 Using the Driver # Once initialized, the device behaves like a standard file:\nint fd = open(\u0026#34;/myDev/\u0026#34;, O_RDWR, 0); write(fd, \u0026#34;Hello Driver\u0026#34;, 12); char buffer[32]; read(fd, buffer, sizeof(buffer)); close(fd); Expected Output # Device /myDev/ created Device opened: /myDev/ Device write: 12 bytes Device read: 12 bytes Device closed ⚠️ Practical Considerations # Even for simple drivers, several factors should be addressed in production code:\nConcurrency # Protect shared buffers with semaphores or mutexes Prevent race conditions across tasks Error Handling # Validate input parameters Return appropriate error codes (errno) Scalability # Avoid static buffers for multi-instance devices Consider dynamic allocation per device instance ✅ Best Practices # Keep driver logic modular and maintainable Separate hardware access from interface logic Use consistent naming and clear API boundaries Design for extensibility (e.g., add ioctl support later) 📌 Conclusion # A simple character driver is the fastest way to understand how VxWorks bridges applications and devices. By integrating with the I/O system and exposing file-like operations, developers can quickly prototype and validate driver behavior.\nThis foundational model scales naturally into more advanced designs, including VxBus-based drivers and interrupt-driven architectures, making it an essential building block for embedded development in VxWorks.\nReference: VxWorks Device Driver Guide: Build a Simple Character Driver\n","date":"2026-04-24","externalUrl":null,"permalink":"/training/vxworks-device-driver-guide-build-a-simple-character-driver/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Device Driver Guide: Build a Simple Character Driver\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eDevice drivers are the bridge between application code and hardware in VxWorks. While modern systems often rely on VxBus for complex hardware integration, the classic \u003cstrong\u003eI/O system-based character driver\u003c/strong\u003e remains a critical foundation—especially for understanding driver design, testing, and lightweight device abstractions.\u003c/p\u003e","title":"VxWorks Device Driver Guide: Build a Simple Character Driver","type":"training"},{"content":"","date":"2026-04-24","externalUrl":null,"permalink":"/tags/vxworks-i/o-system/","section":"Tags","summary":"","title":"VxWorks I/O System","type":"tags"},{"content":"","date":"2026-04-24","externalUrl":null,"permalink":"/tags/i2c/","section":"Tags","summary":"","title":"I2C","type":"tags"},{"content":" VxWorks 7 I2C Driver Guide: Complete Example and Best Practices\nDeveloping device drivers in VxWorks 7 requires a solid understanding of the VxBus framework, hardware abstraction, and system configuration via the device tree. Among common peripheral interfaces, I2C (Inter-Integrated Circuit) remains one of the most widely used buses for connecting sensors, EEPROMs, PMICs, and other low-speed devices.\nThis guide provides a structured, production-oriented walkthrough of writing an I2C device driver in VxWorks 7, covering architecture, implementation, transactions, debugging, and best practices.\n🔌 Why I2C Matters in Embedded Systems # I2C continues to be a foundational interface in embedded platforms due to its simplicity and flexibility:\nTwo-wire interface (SDA, SCL) minimizes pin usage Address-based communication supports multiple devices on a single bus Broad ecosystem support across sensors and control devices Ideal for configuration, monitoring, and low-bandwidth data exchange In RTOS environments like VxWorks, I2C is frequently used for system bring-up, board management, and peripheral control.\n🧱 I2C Architecture in VxWorks 7 # VxWorks 7 implements a layered model for I2C support, separating responsibilities across components:\nController Driver # Manages the physical I2C bus hardware Handles timing, arbitration, and signaling (start/stop conditions) Typically SoC-specific Device Driver # Implements logic specific to a peripheral device Uses controller APIs to perform transactions Encapsulates register access and device behavior VxBus Framework # Provides standardized lifecycle methods (probe, attach, detach) Handles driver binding via device tree Ensures portability and modularity This separation allows reuse of controller drivers while developing multiple device drivers on top.\n🧾 Device Tree Configuration # Hardware description in VxWorks 7 relies on the device tree. A typical I2C configuration looks like:\n\u0026amp;i2c0 { status = \u0026#34;okay\u0026#34;; clock-frequency = \u0026lt;400000\u0026gt;; temperature-sensor@48 { compatible = \u0026#34;ti,tmp102\u0026#34;; reg = \u0026lt;0x48\u0026gt;; }; }; Key Elements # i2c0: I2C controller node clock-frequency: bus speed (e.g., 400 kHz Fast Mode) reg: device address compatible: used for driver matching Accurate device tree configuration is critical—mismatches here are a common source of driver issues.\n🧩 Driver Skeleton Implementation # A minimal VxBus I2C driver defines probe and attach routines along with a method table:\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;hwif/vxBus.h\u0026gt; #include \u0026lt;subsys/i2c/vxbI2cLib.h\u0026gt; LOCAL STATUS myI2cProbe(VXB_DEV_ID pDev) { return OK; } LOCAL STATUS myI2cAttach(VXB_DEV_ID pDev) { printf(\u0026#34;I2C device attached at address 0x%02x\\n\u0026#34;, vxbDevUnitGet(pDev)); return OK; } LOCAL VXB_DRV_METHOD myI2cMethods[] = { { VXB_DEVMETHOD_CALL(vxbDevProbe), (FUNCPTR)myI2cProbe }, { VXB_DEVMETHOD_CALL(vxbDevAttach), (FUNCPTR)myI2cAttach }, VXB_DEVMETHOD_END }; VXB_DRV myI2cDrv = { { NULL }, \u0026#34;myI2c\u0026#34;, \u0026#34;Example I2C Device\u0026#34;, VXB_BUSID_I2C, 0, 0, myI2cMethods, NULL, }; VXB_DRV_DEF(myI2cDrv) STATUS myI2cDrvRegister(void) { return vxbDrvAdd(\u0026amp;myI2cDrv); } This structure integrates the driver into the VxBus ecosystem and enables automatic binding via the device tree.\n🔄 I2C Transactions: Read and Write # Most I2C devices follow a register-based communication model. VxWorks provides vxbI2cDevXfer() for master transfers.\nRead Example # STATUS myI2cRead(VXB_DEV_ID pDev, UINT8 devAddr, UINT8 reg, UINT8 *buf, int len) { VXB_I2C_MSG msgs[2]; msgs[0].addr = devAddr; msgs[0].flags = 0; msgs[0].buf = \u0026amp;reg; msgs[0].len = 1; msgs[1].addr = devAddr; msgs[1].flags = I2C_M_RD; msgs[1].buf = buf; msgs[1].len = len; return vxbI2cDevXfer(pDev, msgs, 2); } Write Example # STATUS myI2cWrite(VXB_DEV_ID pDev, UINT8 devAddr, UINT8 reg, UINT8 *buf, int len) { UINT8 txBuf[1 + len]; txBuf[0] = reg; memcpy(\u0026amp;txBuf[1], buf, len); VXB_I2C_MSG msg = { .addr = devAddr, .flags = 0, .buf = txBuf, .len = sizeof(txBuf), }; return vxbI2cDevXfer(pDev, \u0026amp;msg, 1); } This pattern is widely applicable across EEPROMs, sensors, and control ICs.\n🐞 Debugging Techniques # Efficient debugging is essential when working with low-level drivers:\nUse -\u0026gt; devs in the kernel shell to verify device registration Add trace logs in probe and attach paths Validate compatible strings against the device tree Inspect bus activity using a logic analyzer or oscilloscope These steps help isolate issues across software configuration and hardware signaling.\n⚠️ Common Pitfalls # Clock Stretching Issues # Some controllers have limited support. Lowering bus frequency often resolves instability.\nAddressing Errors # Confusion between 7-bit and 8-bit addressing frequently leads to NACK failures.\nDriver Binding Conflicts # Multiple drivers may match the same compatible string—ensure uniqueness.\nConcurrency Problems # Use synchronization (mutexes) when multiple tasks access the same I2C bus.\n✅ Best Practices # Separate generic driver logic from device-specific functionality Use method tables for modular and extensible design Validate all device tree inputs before use Provide IOCTL interfaces for flexible user interaction Maintain clear documentation of register maps and behavior 📌 Conclusion # Writing an I2C driver in VxWorks 7 involves more than just implementing read/write routines—it requires proper integration with VxBus, accurate device tree configuration, and disciplined debugging.\nOnce these fundamentals are in place, the development of reusable, maintainable I2C drivers becomes straightforward and scalable across projects.\nReference: VxWorks 7 I2C Driver Guide: Complete Example and Best Practices\n","date":"2026-04-24","externalUrl":null,"permalink":"/training/vxworks-7-i2c-driver-guide-complete-example-and-best-practices/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 7 I2C Driver Guide: Complete Example and Best Practices\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eDeveloping device drivers in VxWorks 7 requires a solid understanding of the VxBus framework, hardware abstraction, and system configuration via the device tree. Among common peripheral interfaces, I2C (Inter-Integrated Circuit) remains one of the most widely used buses for connecting sensors, EEPROMs, PMICs, and other low-speed devices.\u003c/p\u003e","title":"VxWorks 7 I2C Driver Guide: Complete Example and Best Practices","type":"training"},{"content":"","date":"2026-04-23","externalUrl":null,"permalink":"/tags/hardware/","section":"Tags","summary":"","title":"Hardware","type":"tags"},{"content":" VxWorks Target Hardware Configuration: A Practical Guide\nConfiguring target hardware is a foundational step in every VxWorks project. Whether you\u0026rsquo;re developing embedded systems, real-time applications, or custom BSPs, a correct setup ensures reliable build, deployment, and debugging workflows.\n🚀 Learning Objectives # By the end of this guide, you will be able to:\nUnderstand the roles of host and target in a VxWorks environment Explain how a host-to-target connection works Configure and validate a target hardware setup 🧩 Why Target Configuration Matters # Every VxWorks system ultimately runs on real hardware. Without a properly configured target:\nApplications cannot be deployed Debugging becomes unreliable or impossible BSP-level issues remain hidden 👉 In short, hardware configuration is the bridge between development and execution.\n🔗 Host vs. Target: Core Concepts # Before configuring anything, clarify these roles:\nHost\nYour development machine (typically Linux or Windows) running:\nBuild tools VxWorks SDK Debugging utilities Target\nThe physical embedded board running:\nVxWorks kernel Your application How They Interact # The host communicates with the target via:\nEthernet (most common) Serial console (for boot/debug) JTAG (low-level debugging) ⚙️ How to Configure Target Hardware # At a high level, the workflow looks like this:\n1. Select the BSP # Choose a Board Support Package (BSP) that matches your hardware.\nDefines CPU architecture Initializes peripherals Configures boot process 2. Build the VxWorks Image # Using your host environment:\nConfigure kernel components Enable required drivers Generate the bootable image 3. Establish Host-to-Target Connection # Typical setup includes:\nAssigning IP addresses Connecting via Ethernet Verifying connectivity (e.g., ping, target shell access) 4. Download and Run # Load the image onto the target via:\nNetwork boot (TFTP) Flash programming Debug tools 5. Validate the Setup # Confirm:\nKernel boots successfully Console output is visible Network stack is operational 🧠 CPU and Board Compatibility # One of the most common failure points is mismatched CPU architecture and BSP.\nExample Combinations # Board CPU Architecture xlnx_zynqmp_3_0_0_1 ARMv8-A fsl_p1p2_4_0_0_1 PowerPC e500v2 ti_sitara_a15_3_0_0_1 Cortex-A15 What to Check # CPU architecture matches BSP Endianness (especially on PowerPC) Supported peripherals and drivers 👉 A mismatch here typically results in boot failure or unstable runtime behavior.\n🛠️ Practical Tips for Reliable Setup # Always start with a reference BSP before customizing Verify console output early (serial is your best friend) Keep networking simple during initial bring-up Use incremental changes when modifying BSPs 📌 Key Takeaways # Target configuration is essential for deployment and debugging A stable host-to-target connection is the backbone of development Correct CPU + BSP matching prevents most low-level issues 🧠 Final Thoughts # Mastering hardware target configuration is a critical milestone in VxWorks development.\nOnce your target is correctly set up, you unlock the ability to:\nDebug in real time Validate system behavior on actual hardware Build robust, production-ready embedded systems 👉 In VxWorks, everything starts with a working target.\nReference: VxWorks Target Hardware Configuration: A Practical Guide\n","date":"2026-04-23","externalUrl":null,"permalink":"/training/vxworks-target-hardware-configuration-a-practical-guide/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Target Hardware Configuration: A Practical Guide\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eConfiguring \u003cstrong\u003etarget hardware\u003c/strong\u003e is a foundational step in every VxWorks project. Whether you\u0026rsquo;re developing embedded systems, real-time applications, or custom BSPs, a correct setup ensures reliable build, deployment, and debugging workflows.\u003c/p\u003e","title":"VxWorks Target Hardware Configuration: A Practical Guide","type":"training"},{"content":"","date":"2026-04-23","externalUrl":null,"permalink":"/tags/multi-client/","section":"Tags","summary":"","title":"Multi-Client","type":"tags"},{"content":"","date":"2026-04-23","externalUrl":null,"permalink":"/tags/select/","section":"Tags","summary":"","title":"Select()","type":"tags"},{"content":"","date":"2026-04-23","externalUrl":null,"permalink":"/tags/sockets/","section":"Tags","summary":"","title":"Sockets","type":"tags"},{"content":" VxWorks select() Guide: Build a Multi-Client TCP Server\n🚀 Introduction # In the previous tutorial, you built a basic TCP client/server. But real systems rarely talk to just one client.\nSo how do you handle multiple simultaneous connections without spawning a task per client?\nThe answer is select().\nThis guide shows how to build a multi-client TCP server in VxWorks using a single task, keeping resource usage low while maintaining responsiveness.\n🧩 What is select()? # select() is a system call that allows you to monitor multiple sockets at once and determine which ones are ready for I/O.\nInstead of blocking on a single socket, your task can:\nWait for new connections Receive data from multiple clients React only when something actually happens Function Prototype # int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); Key Idea # You give select() a set of file descriptors, and it tells you:\nWhich sockets are ready to read Which are ready to write Which have errors This is the foundation of event-driven networking in embedded systems.\n⚙️ Why Use select() in VxWorks? # In resource-constrained environments, this matters a lot.\nWithout select() # One task per client High memory usage Context-switch overhead With select() # Single task handles all clients Lower memory footprint Deterministic behavior This makes it ideal for RTOS-based systems like VxWorks.\n💻 Example: Multi-Client TCP Echo Server # This example demonstrates a server that:\nListens on port 6000 Accepts multiple clients Echoes received data back to each client Code Example # #include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; #include \u0026lt;sockLib.h\u0026gt; #include \u0026lt;inetLib.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;string.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; #include \u0026lt;arpa/inet.h\u0026gt; #define SERVER_PORT 6000 #define MAX_CLIENTS 5 void multiClientServerTask() { int serverSock, clientSock, maxFd, activity, i; int clientSockets[MAX_CLIENTS]; struct sockaddr_in serverAddr, clientAddr; fd_set readFds; char buffer[256]; int addrLen = sizeof(clientAddr); // Initialize client sockets for (i = 0; i \u0026lt; MAX_CLIENTS; i++) clientSockets[i] = 0; // Create server socket serverSock = socket(AF_INET, SOCK_STREAM, 0); serverAddr.sin_family = AF_INET; serverAddr.sin_addr.s_addr = INADDR_ANY; serverAddr.sin_port = htons(SERVER_PORT); bind(serverSock, (struct sockaddr*)\u0026amp;serverAddr, sizeof(serverAddr)); listen(serverSock, 3); printf(\u0026#34;Server listening on port %d\\n\u0026#34;, SERVER_PORT); while (1) { FD_ZERO(\u0026amp;readFds); FD_SET(serverSock, \u0026amp;readFds); maxFd = serverSock; // Add client sockets for (i = 0; i \u0026lt; MAX_CLIENTS; i++) { if (clientSockets[i] \u0026gt; 0) FD_SET(clientSockets[i], \u0026amp;readFds); if (clientSockets[i] \u0026gt; maxFd) maxFd = clientSockets[i]; } // Wait for activity activity = select(maxFd + 1, \u0026amp;readFds, NULL, NULL, NULL); // New connection if (FD_ISSET(serverSock, \u0026amp;readFds)) { clientSock = accept(serverSock, (struct sockaddr*)\u0026amp;clientAddr, \u0026amp;addrLen); printf(\u0026#34;New client connected (fd=%d)\\n\u0026#34;, clientSock); for (i = 0; i \u0026lt; MAX_CLIENTS; i++) { if (clientSockets[i] == 0) { clientSockets[i] = clientSock; break; } } } // Handle client data for (i = 0; i \u0026lt; MAX_CLIENTS; i++) { int sd = clientSockets[i]; if (FD_ISSET(sd, \u0026amp;readFds)) { int bytes = recv(sd, buffer, sizeof(buffer) - 1, 0); if (bytes \u0026lt;= 0) { printf(\u0026#34;Client disconnected (fd=%d)\\n\u0026#34;, sd); close(sd); clientSockets[i] = 0; } else { buffer[bytes] = \u0026#39;\\0\u0026#39;; printf(\u0026#34;Client %d: %s\\n\u0026#34;, sd, buffer); send(sd, buffer, bytes, 0); } } } } } void usrAppInit(void) { taskSpawn(\u0026#34;tMultiServer\u0026#34;, 100, 0, 8000, (FUNCPTR)multiClientServerTask, 0,0,0,0,0,0,0,0,0,0); } 📝 Code Walkthrough # 1. Server Setup # Create socket using socket() Bind to port 6000 Start listening with listen() 2. File Descriptor Management # Each loop iteration:\nClear the set with FD_ZERO\nAdd:\nServer socket → for new connections Client sockets → for incoming data 3. Waiting for Events # select(maxFd + 1, \u0026amp;readFds, NULL, NULL, NULL); This blocks until:\nA new client connects A client sends data 4. Accepting Clients # If the server socket is ready:\nclientSock = accept(...) Add the new socket to the clientSockets[] array Track it for future reads 5. Handling Client Data # For each client:\nIf data is received → process it If connection closed → clean up ⚡ Example Output # Server listening on port 6000 New client connected (fd=4) Client 4: Hello New client connected (fd=5) Client 5: Hi Server Client 4: How are you? 🔍 Key Takeaways # select() enables event-driven networking in VxWorks One task can efficiently handle multiple clients Ideal for embedded systems with limited resources Avoids overhead of thread-per-connection models ⚠️ Practical Tips # Always track maxFd correctly Use timeouts if you need periodic processing Avoid large MAX_CLIENTS unless necessary For high scalability, consider poll() or advanced mechanisms (if available) ✅ Wrap-Up # You’ve now learned how to:\nUse select() in VxWorks Build a multi-client TCP server Efficiently manage multiple sockets in a single task This pattern is widely used in embedded networking and forms the basis of more advanced designs.\nReference: VxWorks select() Guide: Build a Multi-Client TCP Server\n","date":"2026-04-23","externalUrl":null,"permalink":"/training/vxworks-select-guide-build-a-multi-client-tcp-server/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks select() Guide: Build a Multi-Client TCP Server\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🚀 Introduction \n    \u003cdiv id=\"-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn the previous tutorial, you built a basic TCP client/server. But real systems rarely talk to just one client.\u003c/p\u003e","title":"VxWorks select() Guide: Build a Multi-Client TCP Server","type":"training"},{"content":"","date":"2026-04-22","externalUrl":null,"permalink":"/tags/tutorial/","section":"Tags","summary":"","title":"Tutorial","type":"tags"},{"content":" VxWorks Programming Guide: Hello World for Beginners\n🚀 Introduction # VxWorks is one of the most widely used real-time operating systems (RTOS), powering mission-critical systems across aerospace, industrial automation, automotive, and medical devices.\nThis beginner-friendly guide introduces the fundamentals of VxWorks programming, starting with a simple Hello World example.\nIn this tutorial, you will learn:\nWhat VxWorks is and why it matters How tasks work in a real-time system How to write and run your first VxWorks program A detailed breakdown of the code 🔎 What is VxWorks? # VxWorks is a deterministic RTOS developed by Wind River, designed for systems where timing, reliability, and performance are critical.\nKey Characteristics # Deterministic execution — predictable timing behavior High reliability — used in safety-critical systems Scalability — from small embedded devices to complex platforms Common Use Cases # Aerospace and defense systems Industrial controllers Automotive ECUs Medical devices 🧩 Core Concepts You Need to Know # Before writing code, it’s important to understand a few core RTOS concepts:\nTask # The basic unit of execution in VxWorks Similar to a thread in other operating systems Priority-Based Scheduling # Preemptive scheduler Lower numeric value = higher priority Inter-Task Communication # Mechanisms include: Semaphores Message queues BSP (Board Support Package) # Hardware abstraction layer Bridges the OS with your target hardware 💻 Your First VxWorks Program # Let’s write a simple program that prints:\nHello, VxWorks world! Code Example # #include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; // Define a simple task function void helloTask() { printf(\u0026#34;Hello, VxWorks world!\\n\u0026#34;); } // Entry point: called when the system boots void usrAppInit(void) { taskSpawn( \u0026#34;tHello\u0026#34;, // Task name 100, // Priority (lower = higher priority) 0, // Options (default) 2000, // Stack size (bytes) (FUNCPTR)helloTask, // Task entry function 0,0,0,0,0,0,0,0,0,0 // Arguments ); } 📝 Code Walkthrough # 1. Header Files # vxWorks.h → Core OS definitions taskLib.h → Task management APIs stdio.h → Standard I/O functions 2. Task Function # void helloTask() Defines the work executed by the task Prints a message to the console 3. Application Entry Point # void usrAppInit(void) Called automatically after system initialization Used to start application-level logic 4. Creating a Task with taskSpawn # Key parameters:\nName → \u0026quot;tHello\u0026quot; Priority → 100 Stack size → 2000 bytes Entry function → helloTask Important Rule # Lower priority number = higher execution priority\n⚡ How to Run the Program # Build the project using your VxWorks toolchain Download it to your target board or simulator Boot the system Expected Output # Hello, VxWorks world! ⚠️ Common Beginner Mistakes # Missing taskLib.h (required for taskSpawn) Using too small a stack size Misunderstanding priority values Forgetting that tasks run concurrently ✅ Summary # You’ve just completed your first VxWorks program.\nWhat You Learned # Basics of VxWorks and RTOS design How tasks are created and scheduled How to write and execute a simple program 🔜 What’s Next? # In the next tutorial, you’ll explore:\nCreating multiple tasks Task priorities in action Preemptive scheduling behavior Understanding these concepts is essential for building real-time, deterministic systems.\nReference: VxWorks Programming Guide: Hello World for Beginners\n","date":"2026-04-22","externalUrl":null,"permalink":"/training/vxworks-programming-guide-hello-world-for-beginners/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Programming Guide: Hello World for Beginners\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🚀 Introduction \n    \u003cdiv id=\"-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eVxWorks is one of the most widely used \u003cstrong\u003ereal-time operating systems (RTOS)\u003c/strong\u003e, powering mission-critical systems across aerospace, industrial automation, automotive, and medical devices.\u003c/p\u003e","title":"VxWorks Programming Guide: Hello World for Beginners","type":"training"},{"content":" QNX vs VxWorks: Key Differences for Real-Time Systems\nChoosing the right real-time operating system (RTOS) is a critical decision in embedded system design. Two of the most widely used RTOS platforms—QNX and VxWorks—offer distinct architectural philosophies and strengths.\nThis guide provides a clear, technical comparison to help you evaluate which platform best fits your requirements.\n🧩 Overview of QNX and VxWorks # QNX # QNX (originally “QNX is Not Unix”) is a Unix-like RTOS introduced in 1982 and now owned by BlackBerry Limited. It is widely used in:\nAutomotive systems Industrial control Medical devices Key Characteristics # Microkernel-based architecture Strong modularity Broad CPU support (ARM, x86, MIPS, PowerPC) Language support: C, C++, Ada VxWorks # VxWorks, introduced in 1987 by Wind River, is a high-performance RTOS designed for deterministic, mission-critical systems.\nKey Characteristics # Traditionally monolithic kernel (modern versions are more modular) Widely used in aerospace, defense, and industrial systems Proven deployment in: Mars rovers Avionics systems Telecommunications infrastructure ⚙️ Architecture: Microkernel vs Monolithic # QNX: Microkernel Design # Minimal core kernel Services run in user space High fault isolation Advantages\nBetter reliability Easier to update/replace components Trade-off\nPotential overhead due to inter-process communication (IPC) VxWorks: Monolithic (Evolving to Modular) # More functionality inside the kernel Optimized for performance and determinism Advantages\nLower latency High throughput Trade-off\nLarger kernel footprint Historically less isolation (improving in newer designs) 🔐 Safety and Certification # VxWorks # Widely adopted in safety-critical systems Certifications include: DO-178C (avionics) Strong presence in aerospace and defense QNX # Also supports safety-certified variants Common in: Automotive (ISO 26262) Medical systems Key Insight # Both platforms support safety, but:\nVxWorks dominates aerospace/defense QNX dominates automotive and embedded HMI systems 💻 Language and Development Ecosystem # Aspect QNX VxWorks Primary Languages C, C++, Ada, Java C, C++ POSIX Support Strong Strong Tooling Rich Unix-like environment Integrated embedded toolchains Developer Perspective # QNX feels closer to Unix/Linux workflows VxWorks is optimized for deep embedded control systems 📦 Licensing and Ecosystem # QNX → Proprietary licensing (BlackBerry ecosystem) VxWorks → Flexible licensing models via Wind River Both are commercial RTOS platforms with strong vendor support.\n🌍 Industry Adoption # QNX # Automotive infotainment systems Digital cockpits Industrial automation Medical devices VxWorks # Aerospace and defense Space exploration (e.g., Mars rovers) Industrial control Telecommunications 📊 Side-by-Side Comparison # Criteria QNX VxWorks Initial Release 1982 1987 Developer BlackBerry Limited Wind River Architecture Microkernel Monolithic (modular evolution) Design Focus Modularity \u0026amp; reliability Performance \u0026amp; determinism Performance Model IPC-driven Kernel-optimized Primary Domains Automotive, medical, industrial Aerospace, defense, industrial 🧠 Final Takeaway # Both QNX and VxWorks are highly capable RTOS platforms, but they reflect different design priorities:\nChoose QNX if you need:\nStrong modularity Fault isolation Unix-like development environment Choose VxWorks if you need:\nProven real-time determinism High-performance control systems Certification in aerospace/defense Bottom Line # The decision is not about which RTOS is “better”—it’s about which aligns best with your system’s performance, safety, and lifecycle requirements.\nReference: QNX vs VxWorks: Key Differences for Real-Time Systems\n","date":"2026-04-22","externalUrl":null,"permalink":"/training/qnx-vs-vxworks-key-differences-for-real-time-systems/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eQNX vs VxWorks: Key Differences for Real-Time Systems\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eChoosing the right real-time operating system (RTOS) is a critical decision in embedded system design. Two of the most widely used RTOS platforms—\u003cstrong\u003eQNX\u003c/strong\u003e and \u003cstrong\u003eVxWorks\u003c/strong\u003e—offer distinct architectural philosophies and strengths.\u003c/p\u003e","title":"QNX vs VxWorks: Key Differences for Real-Time Systems","type":"training"},{"content":"","date":"2026-04-22","externalUrl":null,"permalink":"/tags/containers/","section":"Tags","summary":"","title":"Containers","type":"tags"},{"content":" Deploying Containers in a VxWorks Environment: A Practical Guide\nContainers are traditionally associated with Linux and cloud-native environments—but their role in real-time operating systems (RTOS) like VxWorks is often misunderstood.\n🚀 Why Containers in VxWorks? # At first glance, containers may seem out of place in an RTOS ecosystem.\nThe Reality # Containers are not about running Linux apps on VxWorks They are about modernizing deployment workflows Key Motivation # Devices now require continuous updates throughout their lifecycle Enterprises need deployment models compatible with IT systems and CI/CD pipelines In short, containers bring DevOps discipline to embedded systems.\n🔐 Do Containers Improve Security? # Containers introduce a new security mechanism rather than replacing existing ones.\nKey Benefit: Image Signing # Container images can be cryptographically signed Ensures only trusted applications run on the device Practical Impact # If your system does not already enforce signed executables, containers provide a straightforward path to trusted software deployment.\n⚙️ Do You Need a Hypervisor? # No—containers do not require the Wind River Helix Virtualization Platform.\nDeployment Options # Standalone VxWorks → Containers run directly Mixed-criticality systems → Containers alongside Linux via hypervisor Containers are flexible and not tied to virtualization.\n⏱️ Real-Time Performance and Determinism # A critical concern: Do containers break real-time guarantees?\nShort Answer # No—if designed correctly.\nWhy? # VxWorks containers avoid heavy abstractions typical in Linux Real-time processes (RTPs) run with near-native performance Potential Overheads # Container startup time (initialization) File system access Security validation Once running, determinism remains intact.\n📡 Containers for Telemetry and Observability # One of the strongest use cases is non-critical workload isolation.\nExample # Collecting logs Running analytics agents Using Python or open-source libraries Why Containers Work Well Here # Keeps telemetry separate from safety-critical code Enables independent updates Avoids impacting certification boundaries This is a natural fit for modern observability pipelines.\n🔄 Can Linux Containers Run on VxWorks? # Not directly.\nKey Limitation # Linux containers rely on Linux system calls VxWorks uses a different execution model Practical Solution # Recompile source code for VxWorks Package as a VxWorks-compatible container Bonus # Container registries can serve different images per OS/architecture, enabling unified workflows.\n📦 OTA Updates and Service Deployment # Containers align closely with Application Over-the-Air (AOTA) updates.\nComparison # FOTA/SOTA → Firmware or OS updates AOTA → Application/service updates Containers focus on application-level delivery, similar to app store updates.\nIn Service-Oriented Architectures (SOA) # Containers package individual services Devices orchestrate: Stopping old versions Starting updated services safely 📏 Container Size and Footprint # VxWorks containers are lightweight.\nWhy? # They do not include the OS kernel Only contain: Application binaries Required libraries Result # Minimal footprint Scales from Hello World to complex frameworks like ROS2 🧠 Developer Experience # Required Knowledge # Familiarity with POSIX APIs is sufficient No deep VxWorks expertise required Impact # Lowers barrier for developers Enables broader ecosystem participation 💾 Resource Overhead # Containers introduce minimal compute overhead.\nConsiderations # Storage for container images Memory for multiple instances Optimization Strategy # Share common libraries Standardize dependencies across teams 📜 Certification and Safety Considerations # Containers must be evaluated carefully in safety-critical environments.\nKey Points # Real-time behavior remains consistent Certification depends on: Where containers are deployed Whether the container runtime itself is certified Deployment Options # Safety-critical partition → Requires certification Non-critical partition → Lower regulatory burden 🔧 Runtime Control and Orchestration # VxWorks provides fine-grained control over container lifecycle.\nFeatures # Custom startup sequencing via C APIs Resource control (CPU, memory) Flexible inter-process communication (IPC) Communication Options # Shared memory Message queues Network-based communication ☸️ Kubernetes Integration # VxWorks can integrate with Kubernetes ecosystems, but not as a full node.\nSupported Use Cases # Telemetry integration Container updates via custom workflows Limitations # Overlay networking requires additional design Full orchestration support is still evolving 🧠 Final Takeaway # Containers in VxWorks are not about replicating cloud-native Linux environments—they are about bringing modern deployment practices into real-time systems.\nWhat Changes # From static firmware updates → dynamic application delivery From monolithic systems → modular services From manual deployment → CI/CD pipelines What Stays the Same # Deterministic real-time performance Fine-grained system control Safety-first design principles Containers are not replacing traditional RTOS design—they are augmenting it with modern software delivery capabilities, enabling embedded systems to evolve alongside enterprise and cloud ecosystems.\nReference: Deploying Containers in a VxWorks Environment: A Practical Guide\n","date":"2026-04-22","externalUrl":null,"permalink":"/training/deploying-containers-in-a-vxworks-environment-a-practical-guide/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eDeploying Containers in a VxWorks Environment: A Practical Guide\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eContainers are traditionally associated with Linux and cloud-native environments—but their role in \u003cstrong\u003ereal-time operating systems (RTOS)\u003c/strong\u003e like VxWorks is often misunderstood.\u003c/p\u003e","title":"Deploying Containers in a VxWorks Environment: A Practical Guide","type":"training"},{"content":"","date":"2026-04-22","externalUrl":null,"permalink":"/tags/devops/","section":"Tags","summary":"","title":"DevOps","type":"tags"},{"content":" Aptiv Highlights VxWorks Role in Artemis II Astronaut Safety\nAptiv has highlighted the role of its VxWorks real-time operating system (RTOS) and safety-critical software technologies in NASA\u0026rsquo;s successful Artemis II lunar mission, which returned four astronauts safely to Earth.\nThe company contributed software infrastructure used for critical functions on the first stage of NASA\u0026rsquo;s Space Launch System (SLS) and within the Orion crew vehicle. VxWorks provided a deterministic execution environment for mission-critical workloads where predictable timing and reliable operation are fundamental requirements.\nAptiv\u0026rsquo;s involvement also extended beyond the flight software itself. The company used a digital-twin simulation environment to validate software against virtualized representations of the target hardware, allowing development and verification to proceed independently of physical hardware availability.\n🚀 VxWorks Supports Mission-Critical Artemis II Functions # VxWorks is a real-time operating system designed for systems that require deterministic behavior, reliability, and stringent safety requirements. Its use spans aerospace, defense, automotive, and other mission-critical environments.\nFor Artemis II, Aptiv deployed VxWorks as part of the software platform supporting critical functions on the SLS first stage and within the Orion spacecraft. The deterministic characteristics of an RTOS are particularly important in flight systems, where software must respond to sensor inputs, control operations, and other time-sensitive events within defined execution constraints.\nVxWorks also has a long history within NASA programs. The operating system has been used in missions and spacecraft systems including Mars rovers and the James Webb Space Telescope, as well as in elements associated with NASA\u0026rsquo;s core Flight System architecture.\n🛡️ Orion Backup Flight System Adds Independent Safety Layer # Aptiv identified the Orion Backup Flight System (BFS) as an important component of the spacecraft\u0026rsquo;s astronaut-safety architecture.\nThe BFS is designed as a Class A flight system and operates independently from the primary flight system. Its architecture was intentionally differentiated to reduce the possibility of common failure modes and shared vulnerabilities.\nThis type of architectural independence is particularly important in human-rated spacecraft. A backup system provides greater resilience when its hardware, software architecture, and failure characteristics are sufficiently separated from those of the primary system.\nRather than simply duplicating the same implementation, architectural diversity can help prevent a single design defect or common software failure from affecting both primary and backup systems simultaneously.\n🧪 Digital Twins Accelerate Flight Software Validation # Aptiv also used digital-twin simulation technology to validate flight software before deployment to physical hardware.\nThe approach allowed engineering teams to execute unmodified target software against a virtual representation of the target platform. This effectively decoupled portions of software development and verification from the availability of physical flight hardware.\nFor safety-critical aerospace software, this provides several advantages:\nEarlier software validation before physical hardware is available Repeatable testing against controlled virtual environments Faster identification of software defects and integration issues Reduced dependency on hardware-in-the-loop testing during early development Greater flexibility for regression testing and mission-specific scenarios Aptiv said that as much as 80–90% of its simulation models can potentially be reused for future missions. Reusable simulation assets can reduce the engineering effort required to establish comparable verification environments across subsequent spacecraft and flight programs.\n🛰️ Software Reliability Remains Central to Human Spaceflight # Artemis II demonstrates the increasingly important role of software architecture and verification in modern human spaceflight. Flight computers, RTOS platforms, backup systems, and simulation environments must work together under strict timing, reliability, and safety constraints.\nFor Aptiv, the mission also illustrates how technologies developed for mission-critical software can support increasingly complex spacecraft architectures. VxWorks provides the underlying deterministic execution environment, while independent backup architectures and digital-twin validation add additional layers of resilience and verification.\nThe successful return of the Artemis II crew underscores the importance of treating flight software as a core component of spacecraft safety rather than simply an enabling technology. In human-rated missions, predictable software behavior, architectural independence, and rigorous validation are integral to the overall reliability of the vehicle.\n","date":"2026-04-20","externalUrl":null,"permalink":"/news/aptiv-highlights-vxworks-role-in-artemis-ii-astronaut-safety/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eAptiv Highlights VxWorks Role in Artemis II Astronaut Safety\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eAptiv has highlighted the role of its VxWorks real-time operating system (RTOS) and safety-critical software technologies in NASA\u0026rsquo;s successful Artemis II lunar mission, which returned four astronauts safely to Earth.\u003c/p\u003e","title":"Aptiv Highlights VxWorks Role in Artemis II Astronaut Safety","type":"news"},{"content":"","date":"2026-04-20","externalUrl":null,"permalink":"/tags/artemis-ii/","section":"Tags","summary":"","title":"Artemis II","type":"tags"},{"content":"","date":"2026-04-20","externalUrl":null,"permalink":"/tags/digital-twin/","section":"Tags","summary":"","title":"Digital Twin","type":"tags"},{"content":"","date":"2026-04-20","externalUrl":null,"permalink":"/tags/flight-software/","section":"Tags","summary":"","title":"Flight Software","type":"tags"},{"content":"","date":"2026-04-20","externalUrl":null,"permalink":"/tags/space-software/","section":"Tags","summary":"","title":"Space Software","type":"tags"},{"content":"","date":"2026-04-20","externalUrl":null,"permalink":"/tags/ai-infrastructure/","section":"Tags","summary":"","title":"AI Infrastructure","type":"tags"},{"content":"","date":"2026-04-20","externalUrl":null,"permalink":"/tags/openstack/","section":"Tags","summary":"","title":"OpenStack","type":"tags"},{"content":"","date":"2026-04-20","externalUrl":null,"permalink":"/tags/private-cloud/","section":"Tags","summary":"","title":"Private Cloud","type":"tags"},{"content":"","date":"2026-04-20","externalUrl":null,"permalink":"/tags/telco/","section":"Tags","summary":"","title":"Telco","type":"tags"},{"content":" Wind River Private Cloud Suite 26.03 Enables Production-Ready AI Across Distributed Private Clouds\nArtificial intelligence is rapidly moving beyond centralized data centers. Enterprises across telecommunications, manufacturing, healthcare, government, and industrial automation are increasingly deploying AI where data is created—at the network edge, inside private clouds, and across geographically distributed infrastructure.\nThis evolution represents far more than experimental AI projects. Organizations are now focused on deploying production-grade AI services that operate reliably, securely, and at scale.\nMeeting these requirements demands infrastructure capable of delivering low latency, operational resilience, and centralized management without sacrificing flexibility or data sovereignty.\nWind River\u0026rsquo;s Private Cloud Suite 26.03 is designed to address these challenges by providing an enterprise-grade private cloud platform optimized for distributed AI and mission-critical workloads.\nAI Adoption Has Entered the Production Era # The conversation around enterprise AI has shifted dramatically.\nOrganizations are no longer asking whether AI has business value—they are determining how to deploy, operate, and scale AI across production environments.\nUnlike traditional cloud-native applications, AI workloads introduce unique infrastructure demands:\nMassive data processing Low-latency inference High-performance computing Distributed deployment Continuous lifecycle management Strict security and compliance requirements As AI moves closer to real-time operations, the underlying infrastructure must evolve accordingly.\nAI-RAN Demonstrates Real-World Deployment # One example of this transition is the collaboration between Wind River and Vodafone on AI-powered Radio Access Networks (AI-RAN).\nRather than treating AI as an isolated application, the project integrates AI directly into telecommunications infrastructure, allowing intelligent workloads to execute alongside traditional RAN functions.\nThis architecture enables:\nAI inference closer to users Real-time network optimization Shared infrastructure for multiple workloads Reduced operational latency Improved infrastructure utilization The project reflects a broader industry trend in which AI becomes an integrated component of operational infrastructure rather than a standalone computing task.\nEcosystem Collaboration Drives Enterprise AI # No single vendor can deliver a complete AI platform.\nSuccessful enterprise AI depends on a broad ecosystem spanning processors, cloud software, orchestration, automation, storage, networking, and security.\nPrivate Cloud Suite 26.03 expands its ecosystem through collaboration with several major technology partners.\nIntel # Intel provides the compute foundation for distributed AI using Xeon 6 processors, enabling organizations to consolidate AI, telecommunications, and enterprise applications onto shared infrastructure while maintaining predictable performance.\nKey benefits include:\nHigh core density Low-latency processing Optimized virtualization Edge-ready deployment AMD # AMD contributes additional platform flexibility through EPYC processor platforms.\nIts high-core-count architecture supports both AI inference and telecommunications workloads running simultaneously on shared infrastructure while offering customers broader hardware choices.\nThis multi-platform approach allows organizations to avoid vendor lock-in while selecting hardware optimized for their deployment requirements.\nServiceNow # Operational automation becomes increasingly important as AI deployments scale.\nServiceNow integration introduces AI-powered workflow automation into private cloud environments through AI Agents capable of assisting with operational processes while keeping data entirely within enterprise-controlled infrastructure.\nThis enables organizations to automate routine operational tasks without relying on public cloud services.\nPlatform Enhancements in Private Cloud Suite 26.03 # The latest release introduces numerous capabilities designed specifically for production AI deployments.\nPerformance for Mission-Critical Workloads # Latency-sensitive applications require deterministic performance rather than best-effort resource scheduling.\nPrivate Cloud Suite 26.03 focuses on delivering consistent execution for workloads with strict service-level objectives, making it suitable for telecommunications, industrial automation, and edge AI deployments.\nHardware Flexibility # Organizations can deploy workloads across both Intel and AMD platforms without redesigning their cloud architecture.\nThis flexibility improves procurement options while simplifying long-term infrastructure planning.\nZero Trust Security # Security remains a foundational requirement for distributed private cloud deployments.\nVersion 26.03 strengthens identity governance through:\nCentralized Identity and Access Management (IAM) OpenID Connect (OIDC) Multi-Factor Authentication (MFA) LDAP integration Active Directory support Together, these capabilities provide centralized authentication while supporting enterprise identity systems.\nClosed-Loop Automation # Operating distributed infrastructure manually quickly becomes impractical.\nPrivate Cloud Suite introduces policy-driven automation capable of managing application lifecycles while maintaining operational consistency across geographically distributed environments.\nAutomated workflows reduce operational complexity while improving reliability.\nStorage Resilience # AI applications depend heavily on storage availability.\nTo improve reliability, the platform adds:\nMultipath storage High-availability storage access Automatic failover capabilities External storage integration These enhancements strengthen storage resilience while allowing organizations to modernize storage independently from compute infrastructure.\nOperational Readiness for Enterprise AI # Infrastructure readiness alone is no longer sufficient.\nOrganizations must also achieve operational readiness by ensuring AI services remain continuously available throughout their lifecycle.\nPrivate Cloud Suite 26.03 supports this objective through integrated management capabilities covering deployment, monitoring, automation, and resilience.\nThe result is an infrastructure platform capable of supporting AI workloads from initial deployment through long-term production operations.\nProtecting the Three Operational Planes # Business continuity in distributed cloud environments depends on protecting three distinct operational layers.\nData Plane # The data plane executes applications and AI workloads.\nAny interruption directly affects running services and user-facing applications.\nPrivate Cloud Suite strengthens this layer through resilient compute infrastructure and enhanced storage availability.\nControl Plane # The control plane coordinates orchestration, scheduling, and system operations.\nIf disrupted, workloads may continue running temporarily but can no longer be managed effectively.\nCapabilities such as:\nClosed-loop automation Subcloud rehoming Policy-driven orchestration help maintain control-plane continuity across distributed environments.\nManagement Plane # The management plane provides visibility, governance, monitoring, and administrative control.\nPrivate Cloud Suite reinforces this layer through:\nCentralized IAM Zero Trust security Unified administration Enterprise authentication integration Maintaining all three operational planes simultaneously enables organizations to achieve high availability across distributed AI infrastructure.\nEdge-to-Core AI Infrastructure # Modern enterprise AI rarely operates within a single location.\nInstead, workloads span multiple environments:\nEdge devices Branch locations Telecommunications networks Regional data centers Core private cloud infrastructure Private Cloud Suite is designed to manage these distributed deployments as a unified platform while preserving operational consistency.\nThis allows organizations to deploy AI where it delivers the greatest business value without sacrificing centralized governance.\nWhy Distributed Private Clouds Matter for AI # Several long-term trends continue to drive demand for distributed private cloud infrastructure.\nGrowing Data Volumes # AI applications increasingly process massive datasets generated outside centralized data centers.\nProcessing data locally reduces latency while minimizing bandwidth consumption.\nData Sovereignty # Many industries must ensure sensitive information remains within specific geographic regions or organizational boundaries.\nPrivate cloud deployments allow organizations to meet these compliance requirements while still benefiting from AI.\nOperational Reliability # Mission-critical industries—including telecommunications, utilities, transportation, and manufacturing—cannot tolerate prolonged service interruptions.\nDistributed infrastructure improves resilience by reducing dependence on centralized cloud services.\nFlexible Infrastructure # Open architectures allow organizations to evolve compute, storage, and networking independently, extending infrastructure lifespan while avoiding proprietary lock-in.\nLooking Ahead # Enterprise AI is entering a phase defined by operational execution rather than experimentation.\nSuccess increasingly depends on infrastructure capable of delivering predictable performance, centralized management, strong security, and resilient distributed operations.\nWind River Private Cloud Suite 26.03 reflects this industry transition by combining production-ready cloud infrastructure with an expanding ecosystem of hardware and software partners.\nBy strengthening compute performance, storage resilience, Zero Trust security, automation, and lifecycle management, the platform provides organizations with a solid foundation for deploying AI workloads across edge, network, and private cloud environments.\nAs AI adoption continues to accelerate, distributed private cloud platforms like Private Cloud Suite will play an increasingly important role in enabling reliable, scalable, and secure enterprise AI from the edge to the core.\n","date":"2026-04-20","externalUrl":null,"permalink":"/news/wind-river-private-cloud-suite-26.03-enables-production-ready-ai-across-distributed-private-clouds/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eWind River Private Cloud Suite 26.03 Enables Production-Ready AI Across Distributed Private Clouds\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eArtificial intelligence is rapidly moving beyond centralized data centers. Enterprises across telecommunications, manufacturing, healthcare, government, and industrial automation are increasingly deploying AI where data is created—at the network edge, inside private clouds, and across geographically distributed infrastructure.\u003c/p\u003e","title":"Wind River Private Cloud Suite 26.03 Enables Production-Ready AI Across Distributed Private Clouds","type":"news"},{"content":" VxWorks Build Guide: VSB, VIP, RTP, and DKM Configuration\nBuilding and configuring VxWorks projects requires a clear understanding of its layered architecture—VSB, VIP, and application-level components. This guide focuses on practical workflows for configuring, building, and managing VxWorks projects using Workbench, with an emphasis on RTPs and DKMs.\n🎯 Learning Objectives # After working through this guide, you should be able to:\nConfigure VxWorks application projects effectively Import and export projects in Workbench Execute reliable and repeatable build workflows Platform development starts with VSB and VIP configuration. Once established, application development extends the system with user-space and kernel-level components.\n🧱 VxWorks Project Types and Build Models # VxWorks supports multiple application models depending on isolation, performance, and deployment requirements:\nReal-Time Processes (RTPs) — user-space applications with memory protection Shared libraries — reusable components linked dynamically Downloadable Kernel Modules (DKMs) — kernel-space extensions CMake-based RTPs/DKMs — customizable build pipelines CMake-based approaches provide full control over build structure, while default Workbench-managed builds rely on predefined specifications and static analysis settings.\n📁 Project Location Strategies # Workspace-Based Projects # Stored within the Workbench workspace Project configuration is self-contained Simpler setup, suitable for local development External Projects # Located outside the workspace Better suited for version-controlled environments Keeps workspace free from generated artifacts Choosing the right layout depends on your team’s source control and CI/CD strategy.\n⚙️ Creating RTP Projects # RTP projects must be associated with a base system configuration:\nVSB (VxWorks Source Build) VIP (VxWorks Image Project) Existing DKM project RTPs inherit build specifications—typically from the VSB—and generate executable outputs such as:\n.vxe binaries Executables linked against shared libraries This inheritance ensures consistency across system and application layers.\n🧩 Creating DKM Projects # DKMs follow a similar creation workflow as RTPs but operate in kernel space. Key characteristics:\nDirect interaction with kernel services Optional inheritance of build settings Customizable build commands DKMs are suited for low-level extensions where performance and direct hardware access are required.\n🎛️ Managing Build Targets # A single project can define multiple build targets, each producing a distinct binary.\nKey Capabilities # Customize source inclusion per target Use different toolchains or flags Isolate experimental builds If no build target is defined, the project will not produce output binaries by default.\n📂 File and Folder Management in Workbench # Efficient project organization improves maintainability and build clarity.\nAdding Files # Use Project Explorer → New Supported types include: Blank files Template-based files Headers and source files Files can be created locally or linked to external paths.\nAdding Folders # Standard folders for general organization Source folders for build inclusion This separation helps control compilation scope and dependency resolution.\nExcluding Files and Folders # Files can be excluded from specific build targets without deletion:\nRight-click → Edit Excludes Configure per build target This is useful for conditional builds or environment-specific configurations.\n📦 Importing and Exporting Projects # Workbench supports efficient project portability.\nExport # Package projects as .zip or .tar Includes settings, files, and breakpoints Ideal for backups and sharing Import # Import from archives or existing directories Supports team project sets Preserves project structure and debugging state This enables seamless collaboration across environments.\n🛠️ Building VxWorks Projects # Build Configuration Components # Each project build is defined by:\nBuild targets Toolchains and macros Makefiles and build commands Workbench provides sensible defaults based on project type, which can be customized in project properties.\nCore Build Commands # Build Project — incremental build Rebuild Project — clean + full rebuild Clean Project — removes generated artifacts Additional tools:\nDevelopment Shell for manual commands Refresh to sync filesystem changes Close Project to unload without deletion Advanced Build Controls # Build enabled specifications only Switch active build configurations Manage multiple build specs per project These features are critical for multi-target and cross-platform development.\n⚠️ Debugging Build Failures # When builds fail, Workbench provides detailed diagnostics:\nErrors appear in the Build Console Include file references and line numbers Linked directly to source code Double-clicking an error navigates to the exact location in the editor, enabling rapid issue resolution.\nCommon issues include syntax errors, missing dependencies, and incorrect build configurations.\n📌 Conclusion # VxWorks project configuration and build management revolve around a structured hierarchy—VSB, VIP, and application layers. Mastering RTP and DKM workflows, along with Workbench’s build system, enables efficient development of scalable, high-performance embedded applications.\nA disciplined approach to project organization, build targets, and validation ensures consistent and reproducible results across complex RTOS environments.\nReference: VxWorks Build Guide: VSB, VIP, RTP, and DKM Configuration\n","date":"2026-04-19","externalUrl":null,"permalink":"/training/vxworks-build-guide-vsb-vip-rtp-and-dkm-configuration/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Build Guide: VSB, VIP, RTP, and DKM Configuration\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eBuilding and configuring VxWorks projects requires a clear understanding of its layered architecture—VSB, VIP, and application-level components. This guide focuses on practical workflows for configuring, building, and managing VxWorks projects using Workbench, with an emphasis on RTPs and DKMs.\u003c/p\u003e","title":"VxWorks Build Guide: VSB, VIP, RTP, and DKM Configuration","type":"training"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/command-line/","section":"Tags","summary":"","title":"Command Line","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/emacs-mode/","section":"Tags","summary":"","title":"Emacs Mode","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/kernel-shell/","section":"Tags","summary":"","title":"Kernel Shell","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/object-module-loader/","section":"Tags","summary":"","title":"Object Module Loader","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/vi-editor/","section":"Tags","summary":"","title":"VI Editor","type":"tags"},{"content":" VxWorks Shell Editing and Object Module Loader Guide\n🧭 Overview # The VxWorks kernel shell provides powerful command-line editing capabilities and a dynamic object-module loader to streamline embedded development workflows. Together, these features enable faster iteration, improved productivity, and runtime extensibility without rebuilding or rebooting the system.\nThis guide covers advanced shell editing using VI and Emacs modes, as well as practical usage of the object-module loader with ld() and unld().\n⌨️ Command-Line Editing in VxWorks # The VxWorks shell includes built-in support for VI-style editing (default) and optional Emacs mode, along with command history and autocompletion.\nCommand History and Buffer # The shell maintains a history buffer of previously executed commands:\nDefault size: 20 commands Commands can be navigated and reused efficiently Buffer size can be adjusted dynamically To increase the history size:\nh 500 This expands the buffer to store up to 500 commands, which is useful in complex debugging or iterative workflows.\nVI Editing Mode (Default) # VI mode is optimized for low overhead and is the default editor in the VxWorks shell.\nTo enter editing mode, press:\nESC Navigation and Editing Commands # Key Action k Previous command in history j Next command in history h Move cursor left l Move cursor right i Insert before cursor I Insert at beginning of line a Append after cursor A Append at end of line x Delete character dd Delete entire line rc Replace character with c nG Jump to history entry or search This mode is efficient for experienced users familiar with modal editing.\n🔍 Command-Line Autocompletion # The shell supports symbol and file name completion:\nCTRL + D → List available symbols CTRL + D, then TAB → Autocomplete symbols or filenames Autocompletion relies on the symbol table, making it especially useful when working with dynamically loaded modules.\n✏️ Enabling Emacs Mode # Emacs mode provides a more familiar editing experience for users accustomed to GNU-style keybindings.\nEnable it with:\nshConfig \u0026#34;LINE_EDIT_MODE=emacs\u0026#34; Considerations # Offers richer editing features than VI Slightly higher runtime overhead Useful for developers not comfortable with modal editing 📦 Object-Module Loader in VxWorks # The object-module loader enables runtime loading and unloading of compiled object files, eliminating the need for full system rebuilds.\nBenefits # Rapid development and testing cycles Dynamic feature extension Reduced downtime during debugging ⚙️ Required Configuration # Ensure the following component is included in your VxWorks Image Project (VIP): INCLUDE_LOADER Additionally, the loader requires access to the symbol table to resolve references between modules and the kernel.\nCore Loader APIs # Loading Modules # ld() Loads an object module into the system Links symbols against the existing kernel image Allocates memory automatically or uses specified addresses Unloading Modules # unld() Removes a previously loaded module Frees associated memory Detaches symbols from the system ⚠️ Safety Considerations # Do not unload a module while its tasks are still executing Ensure all dependent resources are released before calling unld() Improper unloading can lead to undefined behavior or system instability 🧠 Memory Management Behavior # The loader supports two allocation strategies:\nDynamic allocation: Default behavior for downloaded modules Static placement: User-defined memory addresses for tighter control This flexibility is critical for constrained embedded systems where memory layout matters.\n✅ Conclusion # Mastering VxWorks shell command-line editing and the object-module loader significantly improves development efficiency in embedded systems. VI and Emacs modes provide flexible editing workflows, while ld() and unld() enable powerful runtime extensibility.\nThese capabilities allow developers to iterate quickly, debug effectively, and extend system functionality without costly rebuild cycles.\n","date":"2026-04-19","externalUrl":null,"permalink":"/training/vxworks-shell-editing-and-object-module-loader-guide/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Shell Editing and Object Module Loader Guide\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🧭 Overview \n    \u003cdiv id=\"-overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThe \u003cstrong\u003eVxWorks kernel shell\u003c/strong\u003e provides powerful command-line editing capabilities and a dynamic object-module loader to streamline embedded development workflows. Together, these features enable faster iteration, improved productivity, and runtime extensibility without rebuilding or rebooting the system.\u003c/p\u003e","title":"VxWorks Shell Editing and Object Module Loader Guide","type":"training"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/bootapp/","section":"Tags","summary":"","title":"Bootapp","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/bootloader/","section":"Tags","summary":"","title":"Bootloader","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/firmware/","section":"Tags","summary":"","title":"Firmware","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/kernel-boot/","section":"Tags","summary":"","title":"Kernel-Boot","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/vxbl/","section":"Tags","summary":"","title":"Vxbl","type":"tags"},{"content":" VxWorks Boot Process Explained: VxBL, BootApp and Two-Stage Boot\nBooting a VxWorks system on real hardware is a foundational step in embedded development. It defines how the kernel image is loaded, initialized, and transferred into execution on the target platform.\nThis guide explains the VxWorks boot process, focusing on the two-stage bootloader model, the roles of VxBL and BootApp, and how developers interact with the boot chain.\n🔍 Overview of the VxWorks Boot Process # When developing with VxWorks, applications are compiled into a kernel image that must be deployed to a hardware target. This requires a bootloader responsible for loading the image and initiating execution.\nKey Responsibilities of the Bootloader # Initialize hardware (CPU, memory, basic peripherals) Load the kernel image from storage or network Transfer control to the VxWorks kernel Provide configuration and debugging interfaces Boot behavior depends on the board support package (BSP) and target hardware configuration.\n⚙️ The Two-Stage Bootloader Architecture # VxWorks typically uses a two-stage bootloader design to balance minimal startup requirements with flexible runtime configuration.\nStage 1: VxBL (Bootstrap Loader) # Executes immediately after power-on Performs low-level hardware initialization Loads the second-stage bootloader into memory Typically stored in non-volatile memory (Flash, ROM) VxBL is intentionally lightweight to ensure reliable early boot under constrained conditions.\nStage 2: BootApp # Runs in system RAM with more resources available Provides advanced boot capabilities and user interaction Supports loading kernel images from local or network sources Handles configuration parameters and diagnostics BootApp acts as the primary interface for developers during system bring-up.\n🔄 Boot Sequence Flow # The complete boot process follows a deterministic sequence:\nPower-on reset triggers hardware initialization VxBL executes and prepares the system BootApp is loaded into memory and started BootApp loads the VxWorks kernel image Kernel initialization begins (romInit or sysInit) System transitions to multitasking runtime This staged approach ensures both reliability and flexibility across platforms.\n🌐 Kernel Loading Options # BootApp supports multiple methods for loading the kernel image:\nLocal storage (Flash, SD card, SSD, HDD) Network transfer via FTP or NFS Predefined boot scripts for automated startup This flexibility allows developers to optimize boot strategies for development and production environments.\n🛠️ Common VxBL Commands # The VxBL shell provides low-level control over the system.\nFrequently Used Commands # help – list available commands ls, cd, pwd – file system navigation env – manage environment variables load \u0026lt;file\u0026gt; \u0026lt;address\u0026gt; – load image into memory boot \u0026lt;addr\u0026gt; – execute kernel fdt – device tree operations d – display memory contents These commands are essential for early-stage debugging and system inspection.\n🧰 BootApp Command Interface # BootApp extends functionality with a richer command set.\nKey Commands # ? – display help @ – execute boot sequence p – print boot parameters c – modify boot configuration l – load boot file g \u0026lt;addr\u0026gt; – jump to address d, m, f, t – memory inspection and manipulation BootApp is commonly used for configuring boot parameters and testing kernel images.\n⚡ Initialization Paths: romInit vs sysInit # After the kernel is loaded, initialization proceeds through one of two paths:\nromInit: optimized for fast boot from ROM-based systems sysInit: standard initialization path for most configurations The choice depends on system design and deployment requirements.\n📁 BSP and Platform Considerations # Boot behavior is tightly coupled with the Board Support Package.\nKey Factors # CPU architecture and memory layout Storage interfaces and drivers Device tree configuration Vendor-specific initialization logic Developers should always review BSP documentation for platform-specific boot details.\n📌 Conclusion # The VxWorks boot process is built around a robust two-stage architecture that separates minimal hardware initialization from flexible system configuration. VxBL ensures reliable startup, while BootApp provides the tools needed to load, configure, and debug the system.\nUnderstanding this boot flow is essential for efficient bring-up, debugging, and deployment of VxWorks-based embedded systems.\nReference: VxWorks Boot Process Explained: VxBL, BootApp and Two-Stage Boot\n","date":"2026-04-19","externalUrl":null,"permalink":"/training/vxworks-boot-process-explained-vxbl-bootapp-and-two-stage-boot/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Boot Process Explained: VxBL, BootApp and Two-Stage Boot\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eBooting a VxWorks system on real hardware is a foundational step in embedded development. It defines how the kernel image is loaded, initialized, and transferred into execution on the target platform.\u003c/p\u003e","title":"VxWorks Boot Process Explained: VxBL, BootApp and Two-Stage Boot","type":"training"},{"content":" Essential VxWorks RTOS Functions: Kernel, Tasks and IPC\nVxWorks is a mature real-time operating system widely used in safety-critical and high-reliability embedded systems. Its architecture provides deterministic execution, modular design, and a comprehensive set of kernel services for multitasking and communication.\nThis article outlines the essential RTOS functions in VxWorks, focusing on kernel behavior, task management, inter-process communication (IPC), synchronization, and device abstraction.\n🔍 VxWorks Architecture Overview # VxWorks is designed around a modular and scalable architecture that allows systems to include only the required components.\nCore Design Principles # Real-time deterministic execution Modular kernel and service composition Host–target development workflow Hardware abstraction via processor-specific layers The processor abstraction layer enables portability across multiple architectures by isolating hardware-dependent components.\n⚙️ Kernel Capabilities and Scheduling # The VxWorks kernel provides preemptive multitasking with strict priority-based scheduling.\nScheduling Features # Fully preemptive priority-based scheduler Optional round-robin scheduling for equal-priority tasks Fast context switching with minimal latency Interrupt-driven execution model Tasks execute in kernel mode with dedicated contexts, while interrupt service routines share system resources efficiently.\n🔄 Task Management Model # Task management is central to VxWorks system design.\nTask Lifecycle # Creation and initialization Activation and execution Suspension and resumption Blocking and timeout handling Deletion and cleanup Tasks can be created and started in a single step using spawn operations.\nConcurrency Control # Priority inheritance prevents priority inversion Safe task deletion avoids inconsistent states Fine-grained control over task scheduling and execution 🔗 Inter-Process Communication and Synchronization # VxWorks provides multiple IPC mechanisms for deterministic communication.\nSemaphores # Binary and mutex semaphores for mutual exclusion Counting semaphores for resource tracking Configurable scheduling behavior (priority or FIFO) Message Queues and Pipes # Message queues store structured data Support for priority-based message insertion Pipes provide stream-oriented communication These mechanisms allow efficient synchronization and data exchange between tasks.\n📡 Signal Handling and Asynchronous Events # Signals provide a mechanism for asynchronous event handling within tasks.\nKey Characteristics # Act as software interrupts Allow registration of handler functions Enable event-driven execution models Signals are commonly used for exception handling and inter-task notifications.\n💾 Virtual Devices and I/O Abstraction # VxWorks abstracts hardware through a unified device model.\nSupported Device Types # Pipe devices for IPC Network sockets for communication RAM disks and storage drivers Hardware-specific drivers for peripherals This abstraction allows consistent APIs across different hardware platforms.\n⏱️ System Services and Timing Control # VxWorks includes system-level services for timing and resource management.\nCore Services # System clock configuration and timers Watchdog timers for fault detection Interrupt management primitives Power management interfaces These services support deterministic execution and system reliability.\n📊 VxWorks Naming Conventions # VxWorks uses consistent naming conventions for APIs and configuration.\nFunctions typically omit OS-specific prefixes (e.g., taskInit) Macros and configuration options use the VX_ prefix This consistency simplifies development and improves code readability.\n📌 Conclusion # Understanding the core RTOS functions in VxWorks is essential for building reliable embedded systems. The combination of deterministic scheduling, flexible task management, robust IPC mechanisms, and hardware abstraction provides a strong foundation for real-time applications.\nThese primitives enable developers to design systems that meet strict timing constraints while maintaining scalability and maintainability across diverse embedded platforms.\nReference: Essential VxWorks RTOS Functions: Kernel, Tasks and IPC\n","date":"2026-04-19","externalUrl":null,"permalink":"/training/essential-vxworks-rtos-functions-kernel-tasks-and-ipc/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eEssential VxWorks RTOS Functions: Kernel, Tasks and IPC\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eVxWorks is a mature real-time operating system widely used in safety-critical and high-reliability embedded systems. Its architecture provides deterministic execution, modular design, and a comprehensive set of kernel services for multitasking and communication.\u003c/p\u003e","title":"Essential VxWorks RTOS Functions: Kernel, Tasks and IPC","type":"training"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/ipc/","section":"Tags","summary":"","title":"Ipc","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/queues/","section":"Tags","summary":"","title":"Queues","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/semaphores/","section":"Tags","summary":"","title":"Semaphores","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/task-management/","section":"Tags","summary":"","title":"Task-Management","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/data-acquisition/","section":"Tags","summary":"","title":"Data-Acquisition","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/deterministic/","section":"Tags","summary":"","title":"Deterministic","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/hil-simulation/","section":"Tags","summary":"","title":"Hil-Simulation","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/reflective-memory/","section":"Tags","summary":"","title":"Reflective-Memory","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/rmn/","section":"Tags","summary":"","title":"Rmn","type":"tags"},{"content":"","date":"2026-04-19","externalUrl":null,"permalink":"/tags/synchronization/","section":"Tags","summary":"","title":"Synchronization","type":"tags"},{"content":" VxWorks RMN HIL: Real-Time Data Acquisition for Aircraft Simulation\nAircraft guidance hardware-in-the-loop (HIL) simulation demands deterministic timing, high-frequency sampling, and strict synchronization across distributed nodes. Any deviation in timing or data alignment can invalidate test results.\nThis article presents a production-proven architecture combining VxWorks 6.x and a Reflective Memory Network (RMN) to achieve 10 kHz acquisition rates with frame-level synchronization at 1 ms resolution.\n🔍 Real-Time Requirements in HIL Systems # HIL systems integrate real flight hardware with simulated environments, forming a closed-loop system that must operate under strict timing guarantees.\nCore Requirements # Fixed simulation frame cycle at 1 ms or faster High-frequency signal acquisition (up to 10 kHz) Deterministic timestamp alignment across nodes Low-latency communication without jitter Standard Ethernet-based approaches introduce variability and cannot guarantee deterministic behavior under load.\n🛠️ System Architecture # The system is composed of multiple distributed nodes connected via RMN:\nMain control system for supervision Target and environment simulators Motion simulation platform Data acquisition node with multi-channel I/O Simulation nodes executing dynamic models The data acquisition node acts as the global timing master.\n⏱️ Deterministic Timing with VxWorks # VxWorks provides the real-time scheduling and interrupt control required for precise acquisition timing.\nTiming Configuration # System clock configured for high-frequency interrupts Interrupt handler triggers acquisition events Semaphore-based task synchronization ensures deterministic execution Execution Model # Interrupt service routine signals acquisition task Acquisition task runs at fixed intervals aligned with hardware timer Sampling occurs exactly at defined time boundaries This approach eliminates software-induced jitter and ensures consistent sampling intervals.\n🔄 Synchronization via Reflective Memory Network # Reflective Memory Network enables hardware-level data sharing across nodes.\nKey Characteristics # Memory writes are automatically replicated to all nodes No CPU intervention required for data propagation Latency is bounded and consistent Synchronization Mechanism # Master node writes synchronization data to RMN Hardware propagates updates to all nodes Interrupt events notify receiving nodes immediately Each node processes data in lockstep with the global frame cycle.\n📈 Real-Time Data Flow # The system operates in a tightly controlled loop:\nTimer interrupt triggers acquisition cycle Data acquisition task reads all input channels Data is written to shared RMN memory At frame boundary, synchronization signal is broadcast Simulation nodes process inputs and update outputs Results are written back for the next cycle This pipeline ensures zero-copy data exchange and deterministic execution.\n✅ Validation Results # System validation confirms real-time performance under operational conditions:\nStable 10 kHz sampling without jitter Consistent 1 ms frame synchronization across all nodes No frame loss during extended operation Accurate alignment between simulation and motion systems The architecture has been successfully deployed in aircraft guidance HIL environments.\n⚙️ Design Advantages # Deterministic Behavior # Hardware-timed execution ensures predictable system response Low Latency Communication # RMN eliminates software stack overhead Scalability # Additional nodes can be integrated without redesigning communication logic Separation of Concerns # Real-time loop remains minimal Post-processing handled by separate systems 📌 Conclusion # Combining VxWorks 6.x with Reflective Memory Network provides a robust solution for distributed real-time data acquisition in HIL simulation. The architecture achieves precise timing, synchronized execution, and efficient data exchange without introducing software-induced latency.\nThis design serves as a reusable pattern for high-performance simulation systems requiring strict determinism and scalable multi-node coordination.\nReference: VxWorks RMN HIL: Real-Time Data Acquisition for Aircraft Simulation\n","date":"2026-04-19","externalUrl":null,"permalink":"/app/vxworks-rmn-hil-real-time-data-acquisition-for-aircraft-simulation/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks RMN HIL: Real-Time Data Acquisition for Aircraft Simulation\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eAircraft guidance hardware-in-the-loop (HIL) simulation demands deterministic timing, high-frequency sampling, and strict synchronization across distributed nodes. Any deviation in timing or data alignment can invalidate test results.\u003c/p\u003e","title":"VxWorks RMN HIL: Real-Time Data Acquisition for Aircraft Simulation","type":"app"},{"content":"","date":"2026-04-18","externalUrl":null,"permalink":"/tags/ccu/","section":"Tags","summary":"","title":"CCU","type":"tags"},{"content":"","date":"2026-04-18","externalUrl":null,"permalink":"/tags/dbr/","section":"Tags","summary":"","title":"Dbr","type":"tags"},{"content":"","date":"2026-04-18","externalUrl":null,"permalink":"/tags/dos-boot/","section":"Tags","summary":"","title":"Dos-Boot","type":"tags"},{"content":"","date":"2026-04-18","externalUrl":null,"permalink":"/tags/erm/","section":"Tags","summary":"","title":"Erm","type":"tags"},{"content":"","date":"2026-04-18","externalUrl":null,"permalink":"/tags/fat32/","section":"Tags","summary":"","title":"Fat32","type":"tags"},{"content":"","date":"2026-04-18","externalUrl":null,"permalink":"/tags/ftp/","section":"Tags","summary":"","title":"Ftp","type":"tags"},{"content":"","date":"2026-04-18","externalUrl":null,"permalink":"/tags/lba/","section":"Tags","summary":"","title":"Lba","type":"tags"},{"content":" VxWorks 6.x CCU/ERM Fixes: DOS Boot, UDP, FTP, DBR and LBA\nRail transit CCU and ERM systems running VxWorks 6.x often exhibit startup instability and version-specific I/O anomalies. A common field failure presents as a six-LED lockup during power-on, indicating that the system fails before reaching the VxWorks shell.\nThis article consolidates root-cause analysis and validated fixes for DOS-induced FAT32 corruption, UDP boot-time failures, FTP persistence issues, and DBR/LBA constraints in VxWorks 6.9.\n🔍 Platform and Failure Characteristics # The CCU/ERM hardware platform is based on an AMD LX800 PC/104-Plus board with IDE/EDOM storage and standard industrial I/O. Software typically includes VxWorks 6.x with application layers such as OpenPCS.\nObserved Failure Mode # All six front-panel LEDs remain permanently lit No VxWorks shell or network services available Failure reproducible under repeated power cycling The issue is consistently linked to early boot-stage failures.\n🛠️ Eliminating DOS-Induced FAT32 Corruption # Repeated power cycling reveals corruption in FAT32 directory entries, specifically affecting critical boot files such as io.sys and bootrom.bin.\nRoot Cause # DOS modifies directory entries during boot (e.g., updating bootlog.txt). If power is interrupted during these writes:\nDirectory metadata becomes inconsistent File cluster pointers are corrupted Bootloader fails to locate VxWorks image Solution: Direct FAT32 Boot via Custom DBR # Replace the standard DOS boot path with a custom DBR that directly loads bootrom.sys.\nKey Implementation Points # Custom DBR includes boot code and valid BPB File lookup logic directly locates bootrom.sys DOS layer is completely bypassed This approach removes dependency on DOS file operations and eliminates corruption risk. Field validation shows stable cold-start behavior with no recurrence of LED lockups.\n📡 UDP Unicast Boot-Time Failure # A network failure scenario occurs when the Ethernet cable is connected after system boot.\nSymptoms # Network services fail if cable is inserted after a delay sendto() returns error under active UDP task conditions Other services recover when UDP task is disabled Root Cause # This behavior is specific to VxWorks 6.5 and relates to network stack initialization under delayed link conditions.\nResolution # Upgrade to VxWorks 6.8 or 6.9 No reliable patch exists for 6.5 Later versions resolve the issue at the stack level.\n📤 FTP File Persistence and Directory Performance # Persistence Issue # Files transferred via FTP or standard I/O do not persist after reboot.\nRoot Cause # The dosFs cache flush mechanism is disabled by default, preventing buffered writes from committing to disk.\nFix # Enable background cache flushing:\nDos FS Cache Handler -\u0026gt; enable background flush task for dosFs cache = TRUE This ensures consistent data persistence across restarts.\nDirectory Performance Issue (VxWorks 6.8) # Large directories (\u0026gt;200 files) cause slow refresh Rapid operations may trigger kernel exceptions Resolution # Upgrade to VxWorks 6.9 Improved directory handling removes instability 🔧 DBR Validation and LBA Access in VxWorks 6.9 # DBR Recognition Issue # After deploying a custom DBR, VxWorks 6.9 may fail to detect the filesystem.\nRoot Cause # Strict validation of the OEM name field in the BPB.\nFix # Set a valid OEM identifier in DBR header Ensure compatibility with VxWorks parser expectations LBA Sector Access Limitation # Low-level disk access via ataRawio() is limited to early sectors.\nObserved Behavior # Sectors beyond a threshold cannot be accessed Same limitation exists across multiple VxWorks versions Practical Impact # Direct sector patching is not viable for field updates Recommended Approach # Perform full disk image updates Apply DBR fixes during image preparation 📌 Conclusion # VxWorks 6.x CCU/ERM issues are primarily caused by fragile boot dependencies and version-specific driver limitations. Removing DOS from the boot chain, enabling dosFs cache flushing, and upgrading to newer VxWorks versions resolve the majority of failures.\nThe most critical improvement is the adoption of a direct FAT32 boot mechanism, which eliminates directory corruption and restores deterministic startup behavior. Combined with proper system configuration and version alignment, these fixes provide a reliable and scalable foundation for long-term deployment in rail transit systems.\nReference: VxWorks 6.x CCU/ERM Fixes: DOS Boot, UDP, FTP, DBR and LBA\n","date":"2026-04-18","externalUrl":null,"permalink":"/app/vxworks-6.x-ccu-erm-fixes-dos-boot-udp-ftp-dbr-and-lba/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 6.x CCU/ERM Fixes: DOS Boot, UDP, FTP, DBR and LBA\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eRail transit CCU and ERM systems running VxWorks 6.x often exhibit startup instability and version-specific I/O anomalies. A common field failure presents as a six-LED lockup during power-on, indicating that the system fails before reaching the VxWorks shell.\u003c/p\u003e","title":"VxWorks 6.x CCU/ERM Fixes: DOS Boot, UDP, FTP, DBR and LBA","type":"app"},{"content":"","date":"2026-04-17","externalUrl":null,"permalink":"/tags/aerospace-software/","section":"Tags","summary":"","title":"Aerospace Software","type":"tags"},{"content":" How VxWorks Powered NASA’s Artemis II Crewed Lunar Mission\nNASA’s Artemis II marked the first crewed lunar mission in over five decades, successfully sending four astronauts around the Moon and back. Behind this milestone was a robust software foundation—Aptiv’s VxWorks real-time operating system (RTOS)—enabling deterministic execution, system reliability, and mission-critical safety across multiple subsystems.\n(Source: NASA/Bill Ingalls) 🚀 Role of VxWorks in Artemis II # VxWorks served as a core software platform for critical operations in both the Space Launch System (SLS) and the Orion crew vehicle. Its deterministic scheduling and real-time guarantees ensured predictable behavior under strict timing constraints—essential for aerospace systems where failure is not an option.\nThe RTOS powered key functions including:\nFirst-stage launch operations of the SLS Flight and control systems within Orion Core elements of NASA’s flight system architecture VxWorks has an extensive legacy in aerospace, having supported missions ranging from Mars rovers to the James Webb Space Telescope. Its continued use in Artemis reinforces its position as a de facto standard for mission-critical embedded systems.\n🛰️ Mission Overview and Validation Objectives # The Artemis II mission spanned 10 days, during which the Orion spacecraft traveled beyond low Earth orbit, orbited the Moon, and returned safely. The mission focused on validating:\nDeep-space system performance Life support systems for extended missions Crew operational readiness for future missions such as Artemis III This mission served as a full-scale integration test under real deep-space conditions, providing high-confidence validation for future lunar exploration.\n🛡️ Fault Tolerance and Safety Architecture # Backup Flight System (BFS) # A key component of mission safety was the Orion Backup Flight System (BFS). Designed as a fully independent and Class A certified system, the BFS operates with:\nNo shared components with the primary system No common failure modes Distinct architectural design to ensure redundancy This level of isolation significantly reduces systemic risk and ensures continued operation in the event of primary system failure.\nDeterministic Real-Time Guarantees # VxWorks enables strict timing guarantees through:\nPriority-based preemptive scheduling Low-latency interrupt handling Memory protection and partitioning These features are essential for maintaining system stability across critical mission phases such as launch, orbital maneuvers, and re-entry.\n🧪 Digital Twin Simulation and Validation # Aptiv employed a digital twin simulation strategy to validate all flight software prior to deployment. This approach allowed engineers to:\nExecute unmodified target software in a virtual environment Simulate real hardware behavior with high fidelity Decouple software development from hardware constraints A key advantage of this methodology is reusability—up to 80–90% of simulation models can be reused across future missions, significantly reducing development time and cost.\n🧩 Software as a Mission-Critical Enabler # Artemis II highlights the central role of software in modern aerospace systems. VxWorks functioned as a foundational layer enabling:\nReliable communication between subsystems Safe execution of life-critical operations Consistent performance under extreme conditions This level of reliability is the result of decades of engineering investment in safety-certified, high-assurance RTOS platforms.\n📌 Conclusion # The success of Artemis II underscores the importance of deterministic, mission-critical software in human spaceflight. VxWorks not only enabled real-time system performance across multiple spacecraft components but also contributed directly to crew safety and mission success.\nAs NASA advances toward more complex missions such as Artemis III and beyond, the role of proven RTOS platforms and scalable validation strategies like digital twins will only become more critical in ensuring reliability in deep space exploration.\nReference: How VxWorks Powered NASA’s Artemis II Crewed Lunar Mission\n","date":"2026-04-17","externalUrl":null,"permalink":"/industries/how-vxworks-powered-nasas-artemis-ii-crewed-lunar-mission/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eHow VxWorks Powered NASA’s Artemis II Crewed Lunar Mission\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eNASA’s Artemis II marked the first crewed lunar mission in over five decades, successfully sending four astronauts around the Moon and back. Behind this milestone was a robust software foundation—Aptiv’s VxWorks real-time operating system (RTOS)—enabling deterministic execution, system reliability, and mission-critical safety across multiple subsystems.\u003c/p\u003e","title":"How VxWorks Powered NASA’s Artemis II Crewed Lunar Mission","type":"industries"},{"content":"","date":"2026-04-17","externalUrl":null,"permalink":"/tags/5g/","section":"Tags","summary":"","title":"5G","type":"tags"},{"content":"","date":"2026-04-17","externalUrl":null,"permalink":"/tags/6g/","section":"Tags","summary":"","title":"6g","type":"tags"},{"content":"","date":"2026-04-17","externalUrl":null,"permalink":"/tags/ai-ran/","section":"Tags","summary":"","title":"AI-RAN","type":"tags"},{"content":" AI-RAN at MWC 2026: Wind River and Vodafone Open RAN Evolution\nThe collaboration between Wind River and Vodafone at MWC Barcelona 2026 signals a critical shift in telecom strategy—from building Open RAN infrastructure to operating it intelligently at scale. While Open RAN decouples hardware and software to increase flexibility and vendor diversity, it also introduces significant operational complexity driven by massive telemetry and distributed system behavior.\nAI-RAN addresses this challenge by applying real-time analytics and machine learning to network operations, transforming how large-scale 5G systems are managed.\n🔍 AI-RAN Technology Stack # The joint solution is built on a cloud-native architecture that integrates infrastructure, orchestration, and analytics layers.\nCore Components # Vodafone O-Cloud\nProvides the underlying 5G infrastructure, forming the distributed compute and networking foundation.\nWind River Cloud Platform\nDelivers a container-as-a-service (CaaS) environment for hosting network functions and applications with high reliability.\nWind River Analytics\nProcesses telemetry data from both the radio access network (RAN) and cloud layers, enabling real-time insights and decision-making.\nThis layered approach enables consistent orchestration across highly distributed network environments.\n🚀 From Reactive to Predictive Network Operations # Traditional operations support systems rely on reactive workflows, where issues are addressed only after service degradation occurs. AI-RAN introduces a predictive model.\nOperational Transformation # Continuous Learning\nMachine learning models analyze large-scale telemetry data to establish baseline system behavior.\nReal-Time Anomaly Detection\nDeviations such as latency spikes or abnormal resource usage are identified immediately.\nProactive Remediation\nPotential failures are predicted and addressed before impacting end users.\nThis transition significantly reduces downtime and improves service reliability.\n📊 Performance Improvements # The MWC 2026 demonstration highlights measurable gains in operational efficiency.\nMetric Traditional Operations AI-RAN Implementation Detection Time Hours Minutes Data Processing Batch analysis Real-time streaming Scalability Linear with staffing Autonomous scaling Root Cause Analysis Manual investigation Automated correlation The ability to process high-volume telemetry streams continuously enables faster and more accurate decision-making.\n⚙️ Open RAN and Vendor Interoperability # AI-RAN operates on top of Open RAN principles, which separate hardware and software layers.\nKey Advantages # Vendor Flexibility\nMultiple hardware vendors can be integrated without changing the management layer.\nUnified Control Plane\nCentralized intelligence simplifies orchestration across heterogeneous environments.\nReduced Lock-In\nOperators maintain control over software evolution and deployment strategies.\nThis architecture allows telecom operators to scale networks without being constrained by single-vendor ecosystems.\n🚀 Strategic Impact for 5G-Advanced and 6G # AI-driven operations are a foundational requirement for future network generations.\nLong-Term Implications # Autonomous Networks\nSelf-healing capabilities reduce the need for manual intervention.\nOperational Efficiency\nLower operational overhead enables better resource allocation.\n6G Readiness\nEstablishes the AI-native foundation expected in next-generation networks.\nAs network complexity increases, automation becomes essential rather than optional.\n📌 Conclusion # The Wind River and Vodafone AI-RAN demonstration at MWC 2026 represents a shift from infrastructure deployment to intelligent network operation. By combining Open RAN with real-time analytics and machine learning, the solution enables predictive maintenance, scalable operations, and improved service reliability.\nThis evolution positions AI as a core component of telecom infrastructure, defining how future 5G-Advanced and 6G networks will be managed at scale.\n","date":"2026-04-17","externalUrl":null,"permalink":"/news/ai-ran-at-mwc-2026-wind-river-and-vodafone-open-ran-evolution/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eAI-RAN at MWC 2026: Wind River and Vodafone Open RAN Evolution\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eThe collaboration between Wind River and Vodafone at MWC Barcelona 2026 signals a critical shift in telecom strategy—from building Open RAN infrastructure to operating it intelligently at scale. While Open RAN decouples hardware and software to increase flexibility and vendor diversity, it also introduces significant operational complexity driven by massive telemetry and distributed system behavior.\u003c/p\u003e","title":"AI-RAN at MWC 2026: Wind River and Vodafone Open RAN Evolution","type":"news"},{"content":"","date":"2026-04-17","externalUrl":null,"permalink":"/tags/network-automation/","section":"Tags","summary":"","title":"Network-Automation","type":"tags"},{"content":"","date":"2026-04-17","externalUrl":null,"permalink":"/tags/open-ran/","section":"Tags","summary":"","title":"Open Ran","type":"tags"},{"content":"","date":"2026-04-17","externalUrl":null,"permalink":"/tags/telecom/","section":"Tags","summary":"","title":"Telecom","type":"tags"},{"content":"","date":"2026-04-17","externalUrl":null,"permalink":"/tags/vodafone/","section":"Tags","summary":"","title":"Vodafone","type":"tags"},{"content":"","date":"2026-04-15","externalUrl":null,"permalink":"/tags/ipi/","section":"Tags","summary":"","title":"Ipi","type":"tags"},{"content":"","date":"2026-04-15","externalUrl":null,"permalink":"/tags/multi-core/","section":"Tags","summary":"","title":"Multi-Core","type":"tags"},{"content":"","date":"2026-04-15","externalUrl":null,"permalink":"/tags/p2020/","section":"Tags","summary":"","title":"P2020","type":"tags"},{"content":" PowerPC P2020 SMP on VxWorks: Boot, Scheduling, and IPI\nModern embedded signal-processing systems require deterministic real-time behavior, high throughput, and reliable parallel execution. Multi-core processors address these demands by enabling concurrent task execution with shared resources. This article presents a complete implementation of multi-core communication on a PowerPC P2020 dual-core SoC running VxWorks 6.9 in SMP mode, covering architecture selection, boot synchronization, scheduling strategy, and inter-core communication using IPI and shared memory.\n🔍 Multi-Core Architecture Models # Embedded multi-core systems typically adopt one of three models:\nAMP (Asymmetric Multi-Processing): Each core runs an independent OS instance. Provides strong isolation but limits flexibility and resource utilization. SMP (Symmetric Multi-Processing): A single OS instance manages all cores with a unified memory space. Enables dynamic load balancing and efficient communication. BMP (Bounded Multi-Processing): A hybrid approach combining shared and partitioned resources, increasing design complexity. This implementation uses SMP to maximize CPU utilization and minimize communication latency while maintaining real-time guarantees.\n🛠️ Hardware Platform Overview # The PowerPC P2020 integrates dual e500v2 cores (up to 1.2 GHz), a DDR2/3 memory controller, an OpenPIC interrupt controller, and a DMA engine. These components directly enable efficient multi-core operation:\nShared DDR memory supports high-bandwidth data exchange OpenPIC provides inter-processor interrupt (IPI) capability DMA offloads large data transfers from CPU cores 🚀 SMP System Architecture Design # The system operates under a single VxWorks 6.9 SMP instance. Logical roles are assigned for clarity:\nCore0: control plane (command handling, device management, scheduling coordination) Core1: data plane (signal processing, filtering, algorithm execution) Despite role separation, both cores share the same scheduler and memory space, allowing dynamic workload redistribution.\n🔄 Multi-Core Boot Flow # The boot process ensures synchronized initialization across both cores:\nBootloader initializes hardware resources, including clocks, memory, and interrupt controller Core0 boots as the primary core Core0 configures Core1 startup context and releases it from reset A shared-memory flag signals readiness between cores VxWorks kernel initializes SMP services, including scheduling and IPI handling Application tasks are created and scheduled Hardware semaphores and shared flags ensure deterministic startup, with inter-core synchronization latency maintained within microsecond scale.\n📋 Task Scheduling in VxWorks SMP # VxWorks 6.9 SMP uses a priority-based preemptive scheduler with support for multiple policies. The selected strategy combines affinity and load balancing:\nTasks with explicit affinity are bound to specific cores Unbound tasks are scheduled from a global queue The scheduler assigns tasks to the least-loaded core This model achieves high CPU utilization while maintaining predictable execution. Context-switch overhead remains minimal, supporting real-time constraints.\n🔗 Inter-Core Communication Using IPI and Shared Memory # Efficient inter-core communication is critical for high-frequency data exchange. The design combines:\nIPI (Inter-Processor Interrupt) for event notification Shared memory for data transfer Communication flow (Core0 → Core1):\nCore0 locks a mutex and checks buffer availability Data is written to shared memory and a flag is set Core0 triggers an IPI to Core1 Core1 ISR reads the data, clears the flag, and releases the lock Processing continues in task context Synchronization is implemented using VxWorks semaphores (semTake / semGive), ensuring mutual exclusion and data consistency. This approach minimizes latency compared to message-queue-based mechanisms.\n✅ Performance Evaluation # System performance was validated in a signal-processing workload:\nDual-core SMP reduced processing time significantly compared to single-core execution CPU utilization exceeded 90% under load Inter-core communication latency remained in the microsecond range Long-duration stability testing showed no deadlocks or scheduling anomalies Cache optimization techniques, including data alignment and prefetching, improved L2 cache efficiency and overall throughput.\n📌 Conclusion # The PowerPC P2020 implementation with VxWorks 6.9 SMP demonstrates how efficient boot coordination, adaptive scheduling, and low-latency inter-core communication can significantly improve system performance. The combination of IPI signaling and shared memory provides a scalable and deterministic communication model suitable for real-time embedded systems.\nThis design serves as a practical reference for extending SMP architectures to higher core counts while preserving performance, reliability, and real-time behavior.\nReference: PowerPC P2020 SMP on VxWorks: Boot, Scheduling, and IPI\n","date":"2026-04-15","externalUrl":null,"permalink":"/bsp/powerpc-p2020-smp-on-vxworks-boot-scheduling-and-ipi/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003ePowerPC P2020 SMP on VxWorks: Boot, Scheduling, and IPI\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eModern embedded signal-processing systems require deterministic real-time behavior, high throughput, and reliable parallel execution. Multi-core processors address these demands by enabling concurrent task execution with shared resources. This article presents a complete implementation of multi-core communication on a PowerPC P2020 dual-core SoC running VxWorks 6.9 in SMP mode, covering architecture selection, boot synchronization, scheduling strategy, and inter-core communication using IPI and shared memory.\u003c/p\u003e","title":"PowerPC P2020 SMP on VxWorks: Boot, Scheduling, and IPI","type":"bsp"},{"content":"","date":"2026-04-15","externalUrl":null,"permalink":"/tags/scheduler/","section":"Tags","summary":"","title":"Scheduler","type":"tags"},{"content":"","date":"2026-04-15","externalUrl":null,"permalink":"/tags/shared-memory/","section":"Tags","summary":"","title":"Shared-Memory","type":"tags"},{"content":"","date":"2026-04-13","externalUrl":null,"permalink":"/tags/embedded/","section":"Tags","summary":"","title":"Embedded","type":"tags"},{"content":"","date":"2026-04-13","externalUrl":null,"permalink":"/tags/emmc/","section":"Tags","summary":"","title":"EMMC","type":"tags"},{"content":"","date":"2026-04-13","externalUrl":null,"permalink":"/tags/fmql45t900/","section":"Tags","summary":"","title":"FMQL45T900","type":"tags"},{"content":"","date":"2026-04-13","externalUrl":null,"permalink":"/tags/storage/","section":"Tags","summary":"","title":"Storage","type":"tags"},{"content":" VxWorks DosFS on FMQL45T900: eMMC Storage with VxBus and XBD\nReducing reliance on external silicon while maintaining high reliability is a key goal in modern embedded systems. This article presents a production-grade eMMC file system implementation on the FMQL45T900 SoC using VxWorks, combining a VxBus-based block device driver, the XBD caching layer, and the DosFS file system.\nThe result is a modular, high-performance storage stack with full read/write capability and strong reusability.\n🔍 Platform Context: FMQL45T900 and VxWorks # The FMQL45T900 is a programmable SoC integrating:\nQuad-core ARM Cortex-A7 FPGA fabric for custom logic Rich peripheral interfaces SMP support With an available VxWorks BSP, it provides a solid foundation for building reliable storage subsystems.\nVxWorks Storage Stack Overview # VxWorks organizes storage into layered components:\nApplication Layer\nPOSIX APIs (open, read, write, close) File System Layer\nDosFS (FAT16/FAT32 support) Block Layer\nXBD (Extended Block Device) Driver Layer\nVxBus-based eMMC driver This separation ensures clean abstraction and portability.\n🛠️ eMMC Hardware Interface and Configuration # The system uses an eMMC 5.1 device configured in SDR mode.\nKey Characteristics # Bus Width: 4-bit Clock: 25 MHz Signals: EMMC_CLK, EMMC_CMD, EMMC_D[0:3] Power Domains: VCC (NAND array) VCCQ (controller I/O) Device Tree Configuration # mmc0: dwmmc@e0043000 { compatible = \u0026#34;fmsh,psoc-dw-mshc\u0026#34;; reg = \u0026lt;0xe0043000 0x1000\u0026gt;; clocks = \u0026lt;\u0026amp;clkc NCLK_AHB_SDIO0\u0026gt;, \u0026lt;\u0026amp;clkc NCLK_SDIO0\u0026gt;; clock-names = \u0026#34;biu\u0026#34;, \u0026#34;ciu\u0026#34;; bus-width = \u0026lt;4\u0026gt;; cap-mmc-highspeed; status = \u0026#34;okay\u0026#34;; }; This enables the controller and binds it to the VxWorks driver infrastructure.\n📐 Storage Architecture: DosFS + XBD + Driver # At system initialization, the storage stack is brought online through:\nusrDosfsInit() dosFsCacheLibInit() xbdInit() fsMonitorInit() Data Flow # Application issues file operation iosLib routes request DosFS translates to block operations XBD handles caching and queuing Driver executes hardware access Core Structures # struct xbd { struct device xbd_dev; struct xbd_funcs *xbd_funcs; unsigned xbd_blocksize; sector_t xbd_nblocks; }; struct bio { device_t bio_dev; sector_t bio_blkno; unsigned bio_bcount; void *bio_data; unsigned bio_resid; }; XBD abstracts block devices and optimizes I/O throughput.\n🔧 Block Device Driver Design # The eMMC driver follows VxWorks block device conventions and integrates via VxBus.\nInitialization Steps # Create device:\nblkXbdDevCreate() Attach to XBD:\nxbdAttach() Register strategy functions:\nmmcStorageBlkRead() mmcStorageBlkWrite() 🔄 Read/Write Execution Flow # Read Path (CMD17) # Configure block length (512 bytes) Issue single-block read Receive data + CRC Send stop command (CMD12) Validate CRC16 Write Path (CMD24) # Configure block length Issue write command Transmit data + CRC Wait for DATA0 busy release Send CMD12 Key Properties # Sector size: 512 bytes FAT compatibility: ensured Data integrity: CRC validation 🔌 VxBus Integration and System Registration # The driver is registered through hwconf.c with:\nBase address Interrupt configuration Required Components # INCLUDE_DOSFS INCLUDE_XBD INCLUDE_DEVICE_MANAGER INCLUDE_FS_MONITOR Verification # After boot:\nvxBusShow → confirms device binding devs → shows /mmc0:0 ✅ Validation and Testing # A full validation suite confirms functionality and stability.\nTest Scenarios # FTP file upload to mounted volume Application-level read() verification Direct driver read comparison Write tests with incremental patterns Results # Data consistency across all layers Stable repeated read/write cycles No observed corruption or mismatch This validates correctness, robustness, and performance.\n🚀 Performance and Reliability Considerations # Strengths # Modular architecture Efficient caching via XBD Low-latency block access Clean driver abstraction Optimization Opportunities # HS400 mode enablement DMA tuning for higher throughput Advanced wear-leveling strategies 🧠 Final Thoughts # This implementation demonstrates a complete and production-ready storage stack for VxWorks on FMQL45T900. By combining VxBus, XBD, and DosFS, it achieves a balance of performance, modularity, and maintainability.\nThe design serves as a strong reference for:\nEmbedded storage system development BSP-level driver integration High-reliability industrial platforms Future enhancements can extend performance and adaptability, but the current solution already provides a solid, deployable foundation for modern embedded systems.\nReference: VxWorks DosFS on FMQL45T900: eMMC Storage with VxBus and XBD\n","date":"2026-04-13","externalUrl":null,"permalink":"/bsp/vxworks-dosfs-on-fmql45t900-emmc-storage-with-vxbus-and-xbd/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks DosFS on FMQL45T900: eMMC Storage with VxBus and XBD\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eReducing reliance on external silicon while maintaining high reliability is a key goal in modern embedded systems. This article presents a production-grade eMMC file system implementation on the FMQL45T900 SoC using VxWorks, combining a VxBus-based block device driver, the XBD caching layer, and the DosFS file system.\u003c/p\u003e","title":"VxWorks DosFS on FMQL45T900: eMMC Storage with VxBus and XBD","type":"bsp"},{"content":"","date":"2026-04-13","externalUrl":null,"permalink":"/tags/xbd/","section":"Tags","summary":"","title":"XBD","type":"tags"},{"content":"","date":"2026-04-13","externalUrl":null,"permalink":"/tags/multitasking/","section":"Tags","summary":"","title":"Multitasking","type":"tags"},{"content":" VxWorks CCU Optimization: Task Load and Priority Tuning\nIn safety-critical rail systems, multitasking inefficiencies can escalate into system-wide failures. This guide presents a structured optimization of a VxWorks-based Central Control Unit (CCU), focusing on task scheduling, execution latency, and failover resilience.\nBy redesigning task periods, reassigning priorities, and introducing proactive failover logic, the system achieves deterministic execution and eliminates watchdog-triggered faults.\n🔍 CCU Architecture and Scheduling Model # The CCU coordinates key subsystems:\nTraction control Braking systems Door operations HVAC and auxiliary modules Communication is handled via:\nMVB (Multifunction Vehicle Bus) Ethernet Task Model Overview # The original system implemented eight periodic tasks:\nPeriod (ms) 10 32 64 128 256 512 1000 1024 These tasks executed nearly 100 functional modules, leading to contention under load.\nVxWorks Scheduling Behavior # Priority-based preemption Round-robin for equal priorities Time slice: 4 ms (KernelTimeSlice()) Key rule:\nHigher-priority tasks always preempt immediately Equal-priority tasks share CPU time ⚠️ Fault Analysis and Root Cause # Observed Failures # During operation:\nEmergency braking triggered unexpectedly Traction commands remained active Speed and control data froze System unable to recover in manual mode Watchdog Failure # 10 ms task exceeded 200 ms execution time Watchdog triggered → application halted Life-signal task continued → failover not triggered Root Cause Summary # Issue Impact Excessive task preemption Execution starvation Poor priority design Critical tasks delayed Time-slice fragmentation Accumulated latency Missing failover trigger System remained stuck 🧪 Test Environment and Baseline # A full simulation environment included:\nDual CCU redundancy setup MVB traffic generators Event recorder and monitoring Baseline Result # Task Period Max Execution 10 ms task 10 ms 203 ms This exceeded its deadline by 20×, confirming system instability.\n🔧 Optimization Strategy # 🧩 Task Redesign and Priority Tuning # Key changes:\nRemoved 10 ms and 16 ms tasks Reassigned functions to aligned cycles Enforced strict priority hierarchy Optimized Task Table # Task Name Period (ms) Priority Function T32ms_0 32 0 Failover + life-signal T32ms 32 1 Core train control T64ms 64 2 Diagnostics T100ms 100 3 Device management T256ms 256 4 Auxiliary systems T512ms 512 5 HMI communication T1000ms 1000 6 Ethernet communication Design Principles # Shorter tasks → higher priority Avoid excessive preemption chains Align tasks with I/O cycles Reserve priority 0 for system-critical logic 🔁 Proactive Failover Mechanism # A new active failover strategy was introduced:\nMonitor life signals from all tasks Immediately release master role if any task stalls Trigger standby CCU takeover instantly Benefits # Eliminates reliance on passive timeout (3 seconds) Ensures fast fault recovery Prevents system deadlock 📊 Post-Optimization Results # Measured Performance # Task Period Avg (ms) Max (ms) T32ms_0 32 \u0026lt;1.0 0.4 T32ms 32 1.2 2.0 T64ms 64 1.2 2.6 T100ms 100 1.4 2.0 T256ms 256 1.0 3.0 T512ms 512 2.5 4.5 T1000ms 1000 9.0 17 Key Improvements # All execution times below task periods No watchdog violations Stable and predictable scheduling Improved system responsiveness 📈 Optimization Checklist # For similar systems, apply:\nAnalyze worst-case execution time (WCET) Avoid ultra-short high-frequency tasks Enforce strict priority ordering Monitor runtime continuously Implement active failover logic ✅ Conclusion # By applying structured task load analysis and scheduling optimization, the CCU system achieves:\nDeterministic real-time behavior Elimination of watchdog faults Robust failover capability This approach provides a practical framework for optimizing VxWorks-based systems in safety-critical environments such as rail transportation.\nA disciplined combination of priority tuning, task restructuring, and proactive fault handling is essential for maintaining reliability under real-world operational stress.\nReference: VxWorks CCU Optimization: Task Load and Priority Tuning\n","date":"2026-04-13","externalUrl":null,"permalink":"/industries/vxworks-ccu-optimization-task-load-and-priority-tuning/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks CCU Optimization: Task Load and Priority Tuning\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eIn safety-critical rail systems, \u003cstrong\u003emultitasking inefficiencies\u003c/strong\u003e can escalate into system-wide failures. This guide presents a structured optimization of a VxWorks-based \u003cstrong\u003eCentral Control Unit (CCU)\u003c/strong\u003e, focusing on \u003cstrong\u003etask scheduling, execution latency, and failover resilience\u003c/strong\u003e.\u003c/p\u003e","title":"VxWorks CCU Optimization: Task Load and Priority Tuning","type":"industries"},{"content":"","date":"2026-04-12","externalUrl":null,"permalink":"/tags/s3c2410/","section":"Tags","summary":"","title":"S3C2410","type":"tags"},{"content":"","date":"2026-04-12","externalUrl":null,"permalink":"/tags/serial/","section":"Tags","summary":"","title":"Serial","type":"tags"},{"content":" VxWorks XR16L788 Driver: 16-Port UART on S3C2410\nExpanding serial interfaces in embedded systems often exceeds the capability of on-chip UARTs. This guide presents a production-grade VxWorks driver for dual XR16L788 UART devices, enabling 16 independent serial ports on an S3C2410 platform.\nThe implementation follows the VxWorks character device model, uses interrupt-driven FIFO handling, and supports scalable multi-channel operation suitable for industrial applications.\n🔍 VxWorks Serial Driver Model # In VxWorks, serial interfaces are implemented as character devices, providing byte-stream access via a unified I/O subsystem.\nKey Characteristics # Device abstraction via standard APIs Integration with SIO (Serial I/O) framework Support for both: Interrupt-driven mode Polled mode Each UART channel is exposed as a device node (e.g., /tyXR0) using:\nttyDevCreate() 🛠️ Hardware Architecture # The system integrates:\nCPU: S3C2410 (ARM9) UART Chips: 2 × XR16L788 Channels: 8 UARTs per chip → 16 total XR16L788 Features # 64-byte TX/RX FIFOs Programmable baud rate Interrupt-driven operation Interconnection # Shared address/data bus Dedicated chip-select logic Interrupt lines routed to CPU ⚙️ Driver Architecture # The driver uses a two-level structure:\nDevice Structure # typedef struct XR16L788_DEV { int devNum; int devRegBase; int oscFreq; int intNum; int intMask; char *devNamePrefix; void *pChanArray; } XR16L788_DEV; Channel Structure # typedef struct XR16L788_CHAN { SIO_CHAN sio; STATUS (*getTxChar)(); STATUS (*putRcvChar)(); void *getTxArg; void *putRcvArg; int chNum; int chRegBase; int baudRate; int options; int mode; XR_CH_REG *pXrChReg; struct XR16L788_DEV *pXrDev; } XR16L788_CHAN; This separation enables:\nClean device/channel abstraction Scalable multi-chip support Modular initialization 🚀 Initialization Flow # The driver uses a two-phase initialization model.\n🔧 Phase 1: Hardware and Channel Setup # void sysSerialHwInit_16788(void) { xr16788Init(); for (devNum = 0; devNum \u0026lt; MAX_XR16788_DEVS; devNum++) { pDev = \u0026amp;xr16788Dev[devNum]; pDev-\u0026gt;pChanArray = \u0026amp;xr16788Chan[devNum]; if (ERROR == xrInitDev(pDev)) continue; for (chanNum = 0; chanNum \u0026lt; MAX_XR16788_CHANS; chanNum++) { pChan = \u0026amp;xr16788Chan[devNum][chanNum]; pChan-\u0026gt;chNum = chanNum; pChan-\u0026gt;pXrDev = pDev; pChan-\u0026gt;baudRate = 19200; pChan-\u0026gt;chRegBase = pDev-\u0026gt;devRegBase + 0x10 * chanNum; pChan-\u0026gt;mode = SIO_MODE_INT; pChan-\u0026gt;options = CLOCK | CREAD | CS8; pChan-\u0026gt;getTxChar = xrDummyCallback; pChan-\u0026gt;putRcvChar = xrDummyCallback; xrInitChan(pChan); } } } Responsibilities # Initialize hardware registers Configure channel parameters Set default callbacks 🔁 Phase 2: Interrupts and Device Creation # void sysSerialHwInit2_16788(void) { for (devNum = 0; devNum \u0026lt; MAX_XR16788_DEVS; devNum++) { pDev = \u0026amp;xr16788Dev[devNum]; intConnect(INUM_TO_Ivec(pDev-\u0026gt;intNum), xr16l788_Interrupt, (int)pDev); intEnable(pDev-\u0026gt;intNum); } for (devNum = 0; devNum \u0026lt; MAX_XR16788_DEVS; devNum++) { pDev = \u0026amp;xr16788Dev[devNum]; for (chanNum = 0; chanNum \u0026lt; MAX_XR16788_CHANS; chanNum++) { sprintf(tyName, \u0026#34;%s%d\u0026#34;, pDev-\u0026gt;devNamePrefix, chanNum); if (OK != ttyDevCreate( tyName, sysXRSerialChanGet(devNum, chanNum), 512, 512)) { printf(\u0026#34;ttyDevCreate(%s) failed.\\n\u0026#34;, tyName); } } } } Responsibilities # Install interrupt service routines Enable hardware interrupts Create VxWorks device nodes 🔄 FIFO-Based Interrupt Handling # The XR16L788 operates using FIFO-driven interrupts for both transmission and reception.\nTransmit Flow # write() triggers TX startup TX interrupt fires when FIFO is ready ISR invokes TX callback Data is pushed into FIFO Process repeats until buffer is empty Receive Flow # Incoming data fills RX FIFO Interrupt triggers at threshold ISR invokes RX callback Data is drained into system buffers Key Advantages # Reduced CPU overhead High throughput Deterministic latency 📊 Validation Results # Test setup:\n4 external systems generating traffic All 16 ports active 19200 baud, continuous load Observed Performance # Stable bidirectional communication No data loss or corruption Consistent real-time response 📈 Design Benefits # Feature Benefit 16 ports High-density serial expansion Interrupt-driven FIFO Efficient data handling Two-phase init Clean system integration Modular design Easy reuse and scaling ✅ Conclusion # This XR16L788 driver provides a scalable and reliable solution for multi-port serial communication in VxWorks environments. By combining structured device abstraction, phased initialization, and efficient interrupt handling, it delivers high-performance operation suitable for industrial systems.\nThe design can be readily adapted to other ARM platforms and serves as a solid reference for multi-UART driver development in embedded systems.\nReference: VxWorks XR16L788 Driver: 16-Port UART on S3C2410\n","date":"2026-04-12","externalUrl":null,"permalink":"/bsp/vxworks-xr16l788-driver-16-port-uart-on-s3c2410/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks XR16L788 Driver: 16-Port UART on S3C2410\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eExpanding serial interfaces in embedded systems often exceeds the capability of on-chip UARTs. This guide presents a \u003cstrong\u003eproduction-grade VxWorks driver\u003c/strong\u003e for dual XR16L788 UART devices, enabling \u003cstrong\u003e16 independent serial ports\u003c/strong\u003e on an S3C2410 platform.\u003c/p\u003e","title":"VxWorks XR16L788 Driver: 16-Port UART on S3C2410","type":"bsp"},{"content":"","date":"2026-04-12","externalUrl":null,"permalink":"/tags/xr16l788/","section":"Tags","summary":"","title":"XR16L788","type":"tags"},{"content":"","date":"2026-04-12","externalUrl":null,"permalink":"/tags/debugging/","section":"Tags","summary":"","title":"Debugging","type":"tags"},{"content":"","date":"2026-04-12","externalUrl":null,"permalink":"/tags/jtag/","section":"Tags","summary":"","title":"JTAG","type":"tags"},{"content":"","date":"2026-04-12","externalUrl":null,"permalink":"/tags/ocd/","section":"Tags","summary":"","title":"OCD","type":"tags"},{"content":"","date":"2026-04-12","externalUrl":null,"permalink":"/tags/soc/","section":"Tags","summary":"","title":"SoC","type":"tags"},{"content":" Wind River OCD JTAG: Low-Level Debug Architecture Guide\nIn modern SoC-based systems, traditional software debugging tools are often ineffective—especially during early boot or critical fault conditions. When the OS is not yet available, or interrupts destabilize execution, visibility is lost.\nWind River On-Chip Debugging (OCD) addresses this limitation by providing a direct hardware interface to the CPU core via JTAG, enabling full system inspection without relying on software services.\nThis article examines OCD from a low-level architectural perspective, focusing on the interaction between:\nSilicon (TAP) Debug Hardware (ICE / Probe) Software Layer (Workbench) 🔌 JTAG Architecture and TAP Mechanics # Wind River OCD operates using IEEE 1149.1 (JTAG) and IEEE 1149.7 standards. At the core of this interface is the Test Access Port (TAP), which exposes internal processor state through a controlled state machine.\nJTAG Signal Interface # The physical interface consists of:\nTCK — clock signal TMS — state machine control TDI — input data stream TDO — output data stream These signals allow external hardware to drive the TAP controller deterministically.\nTAP State Machine and Run-Control # Debug hardware manipulates the TAP state machine to implement precise control over CPU execution:\nInstruction Register (IR) Access\nInjects debug opcodes to transition the CPU into debug state\nData Register (DR) Access\nEnables direct read/write of:\nSystem memory Memory-mapped I/O (MMIO) Execution Halt Control\nStops the core without requiring OS-level cooperation\nCache Coherency Considerations # Hardware debugging must maintain consistency between memory and cache:\nBreakpoints modify instructions in RAM Instruction cache may contain stale copies Wind River OCD ensures:\nCache invalidation or synchronization Correct execution of modified instruction streams 🧰 Debug Hardware Architecture # Wind River provides two primary debugging platforms: ICE 2 and Wind River Probe, each targeting different deployment scenarios.\nHardware Comparison # Feature ICE 2 Wind River Probe Use Case Multicore, high-performance systems Bring-up and field debugging JTAG Frequency Up to 100 MHz (configurable) Up to 100 MHz Host Interface Ethernet / USB USB Core Support Up to 128 cores Single-core focus Control Logic FPGA-based synchronized control Reconfigurable FPGA Multicore Run-Control and CTM # In SMP systems, debugging requires synchronized control across multiple cores.\nCross-Triggering Matrix (CTM)\nHardware mechanism for coordinated debug events\nSynchronized Halt\nWhen one core hits a breakpoint:\nAll related cores are halted within microseconds Consistent Snapshot\nEnables accurate analysis of race conditions and inter-core dependencies\n🧠 Workbench: OS-Aware Debug Intelligence # The Workbench IDE acts as the interpretation layer, converting raw JTAG data into structured system insights.\nOS Awareness # Despite using a bare-metal connection, Workbench reconstructs OS-level context by analyzing memory:\nTask and thread states Kernel objects (semaphores, queues) Stack usage and scheduling data This enables debugging of VxWorks or Linux systems without active agents.\nMMU Translation Handling # Workbench abstracts memory translation:\nConverts virtual addresses → physical addresses Allows developers to debug using logical memory spaces Aligns with how applications perceive memory Debugging Modes # Mode Behavior System Mode Halts entire SoC Task Mode Suspends a single thread System mode is essential for:\nInterrupt Service Routine (ISR) debugging BSP validation Early boot diagnostics 🔄 Debugging Across the System Lifecycle # Wind River OCD provides visibility across all development and deployment phases.\nPhase 1: Board Bring-Up # Before DRAM initialization:\nExecute Tcl/Python scripts via JTAG Configure CPU registers Initialize memory controllers Load boot code into SRAM Phase 2: Flash Programming # JTAG serves as a high-throughput data channel:\nTransfer data into RAM Execute flash programming agents Support storage types: NAND / NOR eMMC This enables efficient manufacturing workflows.\nPhase 3: Post-Mortem Debugging # For field failures:\nConnect to stalled or crashed systems Extract: CPU register states Trace buffers Exception context Used to diagnose:\nWatchdog resets Memory corruption Hardware faults 🧩 Broad Architecture Support # Wind River OCD supports a wide range of processor architectures:\nIntel Platforms\nUEFI/BIOS debugging Trace Hub integration ARM (Cortex-A/R/M)\nCoreSight debug infrastructure PowerPC / QorIQ\nComplex memory mapping and signaling This broad support enables consistent debugging workflows across heterogeneous systems.\n✅ Conclusion # Wind River OCD is a hardware-driven observability platform that enables deep inspection of system state independent of software availability.\nBy integrating:\nDeterministic JTAG/TAP control Advanced multicore synchronization Intelligent Workbench analysis it provides engineers with the tools required to debug complex embedded systems from early boot through production.\nIn environments where software visibility is limited or unavailable, OCD remains an essential capability for ensuring system correctness and reliability.\nReference: Wind River OCD JTAG: Low-Level Debug Architecture Guide\n","date":"2026-04-12","externalUrl":null,"permalink":"/training/wind-river-ocd-jtag-low-level-debug-architecture-guide/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eWind River OCD JTAG: Low-Level Debug Architecture Guide\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eIn modern SoC-based systems, traditional software debugging tools are often ineffective—especially during early boot or critical fault conditions. When the OS is not yet available, or interrupts destabilize execution, visibility is lost.\u003c/p\u003e","title":"Wind River OCD JTAG: Low-Level Debug Architecture Guide","type":"training"},{"content":"","date":"2026-04-12","externalUrl":null,"permalink":"/tags/arm9/","section":"Tags","summary":"","title":"ARM9","type":"tags"},{"content":"","date":"2026-04-12","externalUrl":null,"permalink":"/tags/nand/","section":"Tags","summary":"","title":"NAND","type":"tags"},{"content":"","date":"2026-04-12","externalUrl":null,"permalink":"/tags/s3c2440/","section":"Tags","summary":"","title":"S3C2440","type":"tags"},{"content":" S3C2440 VxWorks NAND Boot Using Stepping Stone SRAM\nFor embedded systems with strict cost and size constraints, removing NOR flash from the boot design can significantly simplify hardware. This guide explains how to boot VxWorks directly from NAND flash on the S3C2440 ARM9 processor by leveraging its built-in 4KB stepping stone SRAM.\nThis approach enables a reliable, production-ready boot process while reducing BOM cost and board complexity.\n🔍 Why NAND-Only Boot Matters # Traditional embedded designs often use:\nNOR flash for execute-in-place (XIP) NAND flash for storage However, NOR flash introduces several drawbacks:\nHigher cost per bit Lower storage density Slower write/erase performance Key Advantage of S3C2440 # The S3C2440 includes a 4KB internal SRAM (stepping stone) that:\nAutomatically loads the first 4KB from NAND on power-up Begins execution directly from SRAM This enables a pure NAND boot architecture, eliminating the need for NOR flash entirely.\n🧱 Hardware Platform Overview # Typical system configuration:\nCPU: S3C2440 (ARM9) NAND Flash: K9F2G08U0B SDRAM: K4S561632N Ethernet: DM9000 ⚙️ VxWorks Boot Process Overview # VxWorks startup consists of multiple stages:\nStage 1: Low-Level Initialization # romInit()\nDisable interrupts Initialize stack and CPU registers romStart()\nCopy code/data to RAM Decompress image if required Stage 2: System Initialization # usrInit()\nInitialize cache and hardware Call kernel initialization usrRoot()\nCreate system tasks Parse boot parameters Start image loading Stage 3: Kernel Startup # bootCmdLoop\nLoad VxWorks image _sysInit\nTransfer control to kernel 🚀 NAND Boot Implementation Strategy # The key modification is inserting a NAND-to-RAM copy routine early in the boot process.\nDesign Constraints # Must fit within 4KB stepping stone SRAM Must execute before standard romStart() logic Must reliably copy boot image into SDRAM 🔧 Step 1: Implement NAND Copy Function # Define the NAND read interface:\nvoid Nand2SRAM(unsigned char *to, unsigned long start_addr, int size); Example Implementation # for (i = (start_addr \u0026gt;\u0026gt; 11); size \u0026gt; 0; ) { NF_CE_L(); NF_CLEAR_RB(); NF_CMD(CMD_RESET); NF_DETECT_RB(); NF_CE_H(); NF_nFCE_L(); NF_CLEAR_RB(); NF_CMD(CMD_READ1); NF_ADDR(0x00); NF_ADDR(0x00); NF_ADDR((i) \u0026amp; 0xff); NF_ADDR((i \u0026gt;\u0026gt; 8) \u0026amp; 0xff); NF_ADDR((i \u0026gt;\u0026gt; 16) \u0026amp; 0xff); NF_CMD(CMD_READ2); NF_DETECT_RB(); for (j = 0; j \u0026lt; 2048; j++) { to[j] = NF_RDDATA8(); } NF_nFCE_H(); size -= 2048; to += 2048; i++; } This routine reads NAND pages and copies them into SDRAM.\n🧩 Step 2: Integrate into Build System # Add the NAND module:\nBOOT_EXTRA = nand.o Ensure early linking so it resides in the first 4KB:\nbootrom : depend.$(BSP_NAME) bootInit.o romInit.o bootrom.Z.o ... $(LD) ... romInit.o $(BOOT_EXTRA) bootInit.o ... 📌 Step 3: Memory Configuration # Use standard BSP memory definitions:\nROM_TEXT_ADRS ROM_LOW_ADRS RAM_HIGH_ADRS No major changes are required, as the boot flow remains compatible with existing layouts.\n🧪 System Verification # Deployment Steps # Build bootrom using Tornado Flash bootrom into NAND via JTAG Set hardware to NAND boot mode Power on system Runtime Behavior # First 4KB loads into stepping stone SRAM NAND copy routine loads remaining image into SDRAM Bootloader initializes system Network Boot Test # Configure bootline via serial console:\nTarget IP Host IP Image path Execute:\n@ The system downloads the VxWorks image via Ethernet and starts successfully.\n📊 Key Benefits # Feature Benefit No NOR flash Reduced cost and board complexity Reliable boot Hardware-assisted SRAM loading Flexible design Works with standard VxWorks flow Scalable Adaptable to similar ARM9 platforms ✅ Conclusion # Using the stepping stone SRAM on S3C2440 enables a robust NAND-only boot solution for VxWorks. By placing a minimal NAND copy routine within the initial 4KB and controlling link order, the system can reliably load and execute the full boot image from NAND.\nThis design removes the need for NOR flash, simplifies hardware, and maintains full compatibility with VxWorks BSP workflows—making it ideal for cost-sensitive and high-volume embedded applications.\nReference: S3C2440 VxWorks NAND Boot Using Stepping Stone SRAM\n","date":"2026-04-12","externalUrl":null,"permalink":"/bsp/s3c2440-vxworks-nand-boot-using-stepping-stone-sram/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eS3C2440 VxWorks NAND Boot Using Stepping Stone SRAM\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eFor embedded systems with strict cost and size constraints, removing \u003cstrong\u003eNOR flash\u003c/strong\u003e from the boot design can significantly simplify hardware. This guide explains how to boot \u003cstrong\u003eVxWorks directly from NAND flash\u003c/strong\u003e on the S3C2440 ARM9 processor by leveraging its built-in \u003cstrong\u003e4KB stepping stone SRAM\u003c/strong\u003e.\u003c/p\u003e","title":"S3C2440 VxWorks NAND Boot Using Stepping Stone SRAM","type":"bsp"},{"content":"","date":"2026-04-11","externalUrl":null,"permalink":"/tags/application-loading/","section":"Tags","summary":"","title":"Application-Loading","type":"tags"},{"content":"","date":"2026-04-11","externalUrl":null,"permalink":"/tags/multi-image/","section":"Tags","summary":"","title":"Multi-Image","type":"tags"},{"content":"","date":"2026-04-11","externalUrl":null,"permalink":"/tags/startup-script/","section":"Tags","summary":"","title":"Startup-Script","type":"tags"},{"content":" VxWorks Multi-Image Boot: Universal Startup Method\nIn embedded production environments, the ability to switch between multiple VxWorks kernel images and applications on a single storage device—without recompilation—is highly valuable.\nThis guide presents a universal load-type startup method that enables automatic selection and execution of different VxWorks configurations from one hard disk, while keeping boot components fully decoupled.\n🔍 VxWorks Startup Fundamentals # VxWorks supports two primary startup models:\nLoad-Type Startup # Uses bootrom + external kernel image Common in development environments Kernel is loaded from a file system (e.g., disk or network) Pros:\nFlexible image updates Easy to modify applications Limitations:\nRequires manual file management when handling multiple images Bootable-Type Startup # Kernel and application are combined into a single image Typically flashed into non-volatile storage Pros:\nSimple deployment No external dependencies Limitations:\nRequires full image rebuild and reflashing for updates Key Insight # The method in this article extends the load-type model to support:\nMultiple bootroms Multiple kernel images Multiple applications All coexisting on a single disk.\n⚙️ Boot Process Overview # The VxWorks startup sequence proceeds through several stages:\nromInit\nInitializes hardware (interrupts, memory, registers) romStart\nRelocates bootrom to RAM Transfers control to system initialization usrInit\nInitializes system components Spawns the boot task usrRoot\nSets up drivers and system services bootCmdLoop\nLoads the kernel image sysInit → Kernel Start\nTransfers control to the VxWorks OS Default Boot Line Configuration # Defined in config.h:\nNetwork Boot Example # #define DEFAULT_BOOT_LINE \u0026#34;fei(0,0) host:VxWorks h=192.168.0.33 e=192.168.0.18 u=user pw=123\u0026#34; Disk Boot Example # #define DEFAULT_BOOT_LINE \u0026#34;ata=0,0(0,0) host:/ata0/VxWorks h=192.168.0.33 e=192.168.0.18 u=user pw=123\u0026#34; 🚀 Universal Multi-Image Startup Method # This solution combines:\nLoad-type startup DOS 7.1 boot partition Batch-driven file switching It enables menu-based selection of different system configurations at boot time.\n🧩 Step 1: Prepare Bootrom, Image, and Startup Script # Each application configuration includes:\nA dedicated bootrom A kernel image A corresponding startup script Modify usrAppInit.c # Enable automatic script execution:\nint fd; if ((fd = open(\u0026#34;/ata0a/startup.txt\u0026#34;, O_RDWR, 0644)) != NULL) { usrStartupScript(\u0026#34;/ata0a/startup.txt\u0026#34;); close(fd); } Ensure the following component is included:\nINCLUDE_STARTUP_SCRIPT Example startup.txt # id 1,0,\u0026#34;/ata0a/APP/rt.out\u0026#34;; DualNetWork_Switch_OO(\u0026#34;198.1.108.1\u0026#34;, \u0026#34;198.1.108.253\u0026#34;, \u0026#34;255.255.255.0\u0026#34;, 66, 0, 0); id 1,0,\u0026#34;/ata1a/fei.out\u0026#34;; DualNetWorkSwitch(\u0026#34;191.8.200.1\u0026#34;, \u0026#34;255.255.255.0\u0026#34;, \u0026#34;191.8.200.1\u0026#34;, 0); id 1,0,\u0026#34;/ata1a/iiutest\u0026#34;; taskSpawn 0, 100, 0, 0x1000000, main; Each configuration can use its own version of:\nstartup.txt Executable binaries Bootrom 💾 Step 2: Format Disk with DOS 7.1 # Format the target disk using DOS 7.1 (FAT filesystem).\nThis ensures compatibility with:\nBoot loader utilities Configuration files Batch scripts 🖥️ Step 3: Configure Boot Menu (config.sys) # Define selectable boot entries:\n[MENU] MENUITEM=vxWorks.dbg, start the image MENUITEM=jk1, JK1 MENUITEM=jk2, JK2 MENUITEM=jk1test, JK1test MENUITEM=jk2test, JK2test MENUDEFAULT=vxWorks.dbg,3 [vxWorks.dbg] DEVICE=c:\\HIMEM.SYS DOS=HIGH,UMB SHELL=C:\\VXLOAD.COM C:\\bootrom.dbg [jk1] [jk2] [jk1test] [jk2test] 🔁 Step 4: Automate File Switching (AutoExec.bat) # Use batch logic to switch active files dynamically:\n@echo off goto %config% :jk1test del bootrom.dbg copy bootrom.ts1 bootrom.dbg del D:\\APP\\rt.out copy D:\\APP\\rt1.out D:\\APP\\rt.out del test.txt copy test1.txt test.txt del iiutest copy iiutest1 iiutest goto end :DOS goto end :end How It Works # User selects a configuration from the boot menu Script replaces: Bootrom Application binaries Startup scripts Bootloader launches the selected environment 🔄 Boot Flow Summary # BIOS completes POST DOS menu appears User selects configuration Batch script swaps required files VXLOAD.COM launches selected bootrom Bootrom loads kernel startup.txt launches application 📊 Key Advantages # Feature Benefit Multi-image support Run multiple configurations from one disk No recompilation Modify apps independently Full separation Bootrom, kernel, and apps are decoupled Scalability Add/remove configurations easily Compatibility Works with existing BSP and workflows ✅ Conclusion # This universal VxWorks startup method enables true multi-image flexibility using a single storage device. By combining load-type booting with DOS-based menu selection and script-driven file management, it eliminates the need for repeated builds or reflashing.\nThe result is a highly maintainable and scalable solution where bootroms, kernel images, and applications evolve independently, making it ideal for both development and production environments.\nReference: VxWorks Multi-Image Boot: Universal Startup Method\n","date":"2026-04-11","externalUrl":null,"permalink":"/app/vxworks-multi-image-boot-universal-startup-method/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Multi-Image Boot: Universal Startup Method\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eIn embedded production environments, the ability to switch between multiple \u003cstrong\u003eVxWorks kernel images and applications\u003c/strong\u003e on a single storage device—without recompilation—is highly valuable.\u003c/p\u003e","title":"VxWorks Multi-Image Boot: Universal Startup Method","type":"app"},{"content":" 5G V2X Edge Computing: Aptiv, Wind River, Verizon at MWC 2026\nThe V2X proof-of-concept demonstrated at MWC 2026 marks a transition from experimental deployments to scalable, carrier-grade automotive networking. By combining 5G edge computing (MEC) with software-defined vehicle (SDV) architectures, the solution enables real-time data sharing between vehicles, extending perception beyond physical sensor limits.\nThis approach transforms V2X from a hardware-constrained system into a software-defined, network-orchestrated platform.\n🔍 Integrated V2X Technology Stack # The demonstration integrates sensing, middleware, and network infrastructure into a unified architecture.\nRole Distribution # Aptiv\nProvides ADAS sensors, perception algorithms, and the LINC software platform. Responsible for local sensing and sensor fusion.\nWind River\nDelivers the V2X software stack and edge-to-cloud orchestration. Ensures deterministic execution and synchronization between vehicle and edge workloads.\nVerizon Business\nOperates the Edge Transportation Exchange (ETX) on top of its 5G and MEC infrastructure. Acts as the low-latency data exchange layer between vehicles.\nThis separation enables modular evolution while maintaining system-level coordination.\n🚗 Collaborative Perception Beyond Line-of-Sight # The core capability demonstrated is collaborative perception, where vehicles extend their sensing range through shared data.\nData Flow Model # A detecting vehicle captures radar and camera data Data is transmitted to the MEC platform The platform processes and redistributes relevant information A receiving vehicle integrates this data as a virtual sensor input System Behavior # External sensor data is treated as native input by the ADAS stack Hazards outside line-of-sight can trigger safety functions such as automatic emergency braking Processing occurs within milliseconds, maintaining real-time constraints This effectively creates a distributed sensing network across vehicles.\n⚙️ Interoperability Through Network Abstraction # Traditional V2X implementations rely on direct communication protocols and tightly coupled hardware ecosystems. The MEC-based approach introduces a service-layer abstraction.\nKey Improvements # API-Based Communication\nVehicles interact with edge services using standardized interfaces rather than direct peer-to-peer protocols.\nHardware Reuse\nExisting 5G modems and ADAS systems eliminate the need for dedicated V2X modules.\nVendor Neutrality\nData exchange occurs through the network, enabling interoperability across different OEM platforms.\nThis model removes a major barrier to large-scale V2X deployment.\n📊 Architecture Comparison # Feature Traditional V2X MEC-Based V2X Connectivity DSRC or direct C-V2X 5G cellular with MEC Latency Low but range-limited Ultra-low with edge processing Hardware Dedicated V2X modules Standard 5G and ADAS hardware Scalability Hardware-dependent Software-driven deployment The shift from device-centric to network-centric communication is the defining change.\n🚀 Implications for Software-Defined Vehicles # The demonstrated architecture aligns with SDV principles by decoupling functionality from hardware constraints.\nSystem-Level Benefits # Real-time coordination across vehicles and infrastructure Dynamic feature deployment via software updates Centralized optimization at the network edge Expanded Use Cases # Traffic flow optimization through coordinated vehicle behavior Enhanced safety for autonomous systems in complex environments Real-time environmental awareness integrated into cockpit systems These capabilities extend V2X beyond safety into system-wide intelligence.\n📌 Conclusion # The MWC 2026 V2X demonstration shows that 5G MEC can deliver scalable, low-latency vehicle communication without requiring specialized hardware. By moving coordination to the network edge and leveraging SDV architectures, the solution enables collaborative perception and cross-vendor interoperability.\nThis approach represents a practical path toward large-scale deployment of connected vehicle systems, where software-defined capabilities and edge infrastructure define the next phase of automotive innovation.\n","date":"2026-04-08","externalUrl":null,"permalink":"/news/5g-v2x-edge-computing-aptiv-wind-river-verizon-at-mwc-2026/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003e5G V2X Edge Computing: Aptiv, Wind River, Verizon at MWC 2026\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eThe V2X proof-of-concept demonstrated at MWC 2026 marks a transition from experimental deployments to scalable, carrier-grade automotive networking. By combining 5G edge computing (MEC) with software-defined vehicle (SDV) architectures, the solution enables real-time data sharing between vehicles, extending perception beyond physical sensor limits.\u003c/p\u003e","title":"5G V2X Edge Computing: Aptiv, Wind River, Verizon at MWC 2026","type":"news"},{"content":"","date":"2026-04-08","externalUrl":null,"permalink":"/tags/connected-vehicles/","section":"Tags","summary":"","title":"Connected-Vehicles","type":"tags"},{"content":"","date":"2026-04-08","externalUrl":null,"permalink":"/tags/mec/","section":"Tags","summary":"","title":"Mec","type":"tags"},{"content":"","date":"2026-04-08","externalUrl":null,"permalink":"/tags/v2x/","section":"Tags","summary":"","title":"V2x","type":"tags"},{"content":"","date":"2026-03-17","externalUrl":null,"permalink":"/tags/euv-lithography/","section":"Tags","summary":"","title":"EUV Lithography","type":"tags"},{"content":"","date":"2026-03-17","externalUrl":null,"permalink":"/tags/industrial-platforms/","section":"Tags","summary":"","title":"Industrial Platforms","type":"tags"},{"content":"","date":"2026-03-17","externalUrl":null,"permalink":"/tags/semiconductor-manufacturing/","section":"Tags","summary":"","title":"Semiconductor Manufacturing","type":"tags"},{"content":" Software-Defined Semiconductor Equipment: The Platform Shift in Advanced Manufacturing\nFor decades, the competitive advantage in semiconductor manufacturing was defined by physical assets—smaller process nodes, more precise machinery, and massive fabrication capacity. Today, that equation is changing. As the industry approaches 3nm and beyond, the complexity of manufacturing has pushed equipment architecture toward a new paradigm: software-defined semiconductor systems.\nIn this model, the underlying software platform—responsible for real-time control, workload isolation, and data-driven optimization—has become just as critical as mechanical precision.\n⚙️ Why Platforms Now Dictate Manufacturing Success # At advanced process nodes, manufacturing tolerances have reached atomic-scale boundaries. Achieving consistent production requires unprecedented levels of synchronization between sensors, actuators, and control algorithms.\nPrecision at the Physical Limit # Picometer Alignment\nExtreme ultraviolet lithography systems must maintain positioning accuracy at the picometer (pm) scale, requiring ultra-stable feedback loops.\nAtomic Layer Deposition Control\nIn 3nm fabrication, ALD processes involve hundreds of sequential dosing steps. A timing deviation of just 3 milliseconds in valve actuation can increase material dosage by roughly 6%, enough to affect device characteristics or damage an entire wafer.\nMillisecond Process Coordination\nEtching systems must coordinate gas flow, chamber pressure, and RF power with millisecond-level precision to avoid over-etching structures measured in atoms.\nThese requirements make purely mechanical control insufficient. Advanced semiconductor equipment must rely on deterministic software orchestration.\n🧠 Mixed-Criticality Architecture in Modern Equipment # Modern fabrication systems must simultaneously handle two fundamentally different computing workloads:\nHard real-time control loops governing physical processes. High-level analytics and AI workloads analyzing sensor data and predicting failures. To reconcile these demands on a single hardware platform, manufacturers increasingly deploy mixed-criticality architectures built around Type 1 hypervisors.\nRole of the Type 1 Hypervisor # A Type 1 hypervisor runs directly on hardware rather than on top of a host operating system. This approach allows strict partitioning of workloads with minimal performance overhead.\nKey benefits include:\nStrong System Isolation\nCritical control systems remain protected even if higher-level applications fail or become compromised.\nDirect Hardware Access\nHypervisors can leverage hardware virtualization features such as Intel VT-x or ARM virtualization extensions.\nNear-Native Performance\nDeterministic workloads maintain predictable timing characteristics without excessive latency or jitter.\nThis architecture allows multiple operating systems to coexist safely on the same system-on-chip.\nDeterminism and Latency in Advanced Nodes # In semiconductor fabrication, real-time does not simply mean “fast.” It means predictable and repeatable execution.\nDeterministic systems ensure that a command—such as terminating a plasma etch—occurs at precisely the same microsecond every time it is triggered.\nThis level of control is critical because:\nA delay measured in microseconds can alter material deposition. Variability in process timing can degrade transistor performance. Inconsistent process control directly reduces yield. Real-time schedulers prioritize high-criticality tasks, ensuring process control always preempts secondary workloads like data logging or monitoring.\n🏭 Platform Engineering in the Semiconductor Fab # To address the growing complexity of advanced manufacturing equipment, industrial software platforms now integrate multiple system layers within a unified architecture.\nPlatform Component Role in Advanced Manufacturing Equipment VxWorks RTOS Provides deterministic control for real-time subsystems such as robotic wafer handling and valve actuation. Wind River Linux Runs higher-level workloads including data analytics, machine learning, and predictive maintenance. Helix Virtualization Platform A Type 1 hypervisor that partitions real-time and general-purpose workloads on the same processor. Wind River Studio DevSecOps infrastructure for secure updates, monitoring, and lifecycle management of manufacturing systems. This layered architecture allows equipment vendors to consolidate previously separate controllers onto a single computing platform while maintaining strict safety and timing guarantees.\n🤖 Software as the Driver of Yield # As semiconductor fabs evolve toward autonomous manufacturing environments, software architecture is becoming a direct contributor to production yield.\nAdvanced platform designs enable:\nDeterministic real-time process control Secure isolation between critical and non-critical workloads Continuous system monitoring and predictive maintenance Secure remote updates and lifecycle management In next-generation fabs, software is no longer a supporting layer beneath hardware. It is the control fabric that orchestrates every physical process within the manufacturing pipeline.\nThe future of semiconductor manufacturing will therefore be shaped not only by lithography breakthroughs and materials science—but also by the sophistication of the software platforms that control them.\n","date":"2026-03-17","externalUrl":null,"permalink":"/industries/software-defined-semiconductor-equipment-the-platform-shift-in-advanced-manufacturing/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eSoftware-Defined Semiconductor Equipment: The Platform Shift in Advanced Manufacturing\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eFor decades, the competitive advantage in semiconductor manufacturing was defined by physical assets—smaller process nodes, more precise machinery, and massive fabrication capacity. Today, that equation is changing. As the industry approaches \u003cstrong\u003e3nm and beyond\u003c/strong\u003e, the complexity of manufacturing has pushed equipment architecture toward a new paradigm: \u003cstrong\u003esoftware-defined semiconductor systems\u003c/strong\u003e.\u003c/p\u003e","title":"Software-Defined Semiconductor Equipment: The Platform Shift in Advanced Manufacturing","type":"industries"},{"content":"","date":"2026-03-08","externalUrl":null,"permalink":"/tags/bsp-development/","section":"Tags","summary":"","title":"BSP Development","type":"tags"},{"content":" Comprehensive Guide to BSP Design for VxWorks 7\nIn real-time operating system (RTOS) environments, VxWorks 7 is widely used in mission-critical systems across aerospace, automotive, defense, and industrial automation. One of the key mechanisms enabling VxWorks to run on different hardware platforms is the Board Support Package (BSP).\nA BSP provides the hardware abstraction layer between the operating system and the target board. It contains initialization code, low-level drivers, and platform configuration that allow the VxWorks kernel to interact with CPU, memory, and peripherals.\nThis guide provides a practical overview of BSP design for VxWorks 7, including architecture, development workflow, driver integration, and debugging practices for embedded developers.\n🧱 Understanding BSP in VxWorks 7 # A Board Support Package (BSP) is a collection of hardware-specific software components that enable VxWorks to boot and operate on a target platform.\nTypical responsibilities of a BSP include:\nBoard hardware initialization during boot CPU and memory configuration Interrupt and timer setup Device driver initialization Providing interfaces between the OS and peripherals Without a properly implemented BSP, the VxWorks kernel cannot boot or access the hardware resources of a board.\nCompared with earlier releases, VxWorks 7 introduces a more modular architecture, primarily through two important frameworks:\nVxBus for device driver abstraction and device discovery Flattened Device Tree (FDT) for hardware description This modular design significantly simplifies BSP porting and hardware support.\n🏗️ VxWorks 7 BSP Architecture # The BSP architecture in VxWorks 7 is layered to improve portability and maintainability.\nTypical layers include:\nBoard Layer\nContains board-specific configuration such as:\nClock and PLL setup GPIO initialization Memory controller configuration Processor Support Library (PSL)\nProvides CPU-specific functionality including:\nCache management MMU configuration Exception handling Board Subsystem\nThis layer integrates peripheral devices using the VxBus framework, enabling device drivers to be registered and discovered dynamically.\nKernel Integration\nThe BSP connects hardware initialization routines to the VxWorks kernel boot sequence and startup tasks.\nTogether these layers form the platform abstraction that sits between hardware and the operating system.\n🔌 Core Driver Frameworks # Several driver frameworks are commonly used within VxWorks BSP implementations.\nVxBus\nThe primary device driver framework in VxWorks 7.\nIt provides:\nBus-independent device driver architecture Automatic device discovery Driver lifecycle management END (Enhanced Network Driver)\nThe END framework is used for Ethernet controller drivers and integrates with the VxWorks networking stack.\nI/O System\nThe VxWorks I/O subsystem manages character and block devices such as:\nSerial ports Storage devices Pseudo terminals These frameworks provide the standardized interfaces used by BSP developers.\n🧰 Setting Up the Development Environment # Before starting BSP development, several tools and resources are required.\nDevelopment Tools\nWind River Workbench 4 (or newer) VxWorks 7 source packages Reference BSP from Wind River BSP library Simulation Tools\nVirtual platforms such as Simics are often used to test early BSP implementations before hardware becomes available.\nHardware Documentation\nDevelopers must obtain detailed hardware documentation including:\nCPU architecture manuals Peripheral register maps Board schematics Memory layout specifications Prerequisites\nEffective BSP development requires:\nStrong C programming skills Assembly language knowledge Familiarity with RTOS concepts Experience with embedded debugging tools ⚙️ BSP Creation Workflow # Creating a BSP typically follows a structured process. The example below assumes an ARMv8-A platform such as the NXP i.MX8.\nCreate a VxWorks Source Build (VSB) # A VxWorks Source Build (VSB) compiles the OS source code for the target architecture.\nTypical steps include:\nCreate a new VxWorks Source Build project in Workbench. Select a reference BSP and CPU architecture. Enable features such as SMP if the platform is multicore. Build the project to generate kernel libraries. The VSB provides the base system components used by the BSP and image project.\nGenerate a BSP Skeleton # Workbench can generate a basic BSP template containing essential files.\nTypical generated files include:\nromInit.s sysLib.c sysALib.s config.h Makefile This skeleton provides the starting point for board initialization code.\n🚀 Boot and Hardware Initialization # Early boot code is responsible for bringing the hardware into a usable state before the kernel starts.\nBoot Assembly (romInit.s) # The romInit.s file contains the earliest execution code after reset.\n.section .text .globl romInit romInit: ldr x0, =_vector_table msr VBAR_EL1, x0 ldr x0, =__stack_top mov sp, x0 ldr x0, =0x40000000 ldr x1, =0x00001234 str x1, [x0] bl sysInit b . This stage typically performs:\nException vector setup Stack initialization Early clock configuration Transfer control to C initialization routines System Library Initialization # The sysLib.c file implements core board initialization functions.\n#include \u0026lt;vxWorks.h\u0026gt; LOCAL char *sysPhysMemTop = (char *)0x80000000; void sysHwInit(void) { *(volatile UINT32 *)0x40001000 = 0x00000101; } char *sysMemTop(void) { return sysPhysMemTop; } Common responsibilities include:\nMemory controller initialization Peripheral configuration Board-specific hardware setup Interrupt Controller Setup # Interrupt controllers must be initialized before enabling interrupts.\nvoid sysIntInit(void) { *(volatile UINT32 *)0xF9000000 = 0x1; } This typically involves configuring components such as ARM Generic Interrupt Controller (GIC) hardware.\n🔧 Device Driver Implementation # Device drivers are a central component of BSP development.\nUART Serial Driver # Serial drivers are usually implemented first because they provide console access for debugging.\n#define UART_BASE 0xF8000000 void uartInit(void) { *(volatile UINT32 *)(UART_BASE + 0x0C) = 0x83; } int uartPutChar(char c) { while (!(*(volatile UINT32 *)(UART_BASE + 0x14) \u0026amp; 0x20)); *(volatile UINT32 *)(UART_BASE + 0x00) = c; return 1; } These drivers typically integrate with:\nttyDrv tyLib to provide standard terminal interfaces.\nSystem Timer Driver # The system timer driver provides the periodic interrupt used by the kernel scheduler.\nResponsibilities include:\nHardware timer initialization Tick rate configuration Interrupt service routine implementation Typical tick rates are 1 ms or 10 ms, depending on system requirements.\nNetwork Driver (END Framework) # Ethernet drivers in VxWorks commonly use the END driver framework.\nExample device structure:\ntypedef struct { END_OBJ endObj; } MY_ENET_DEV; The driver typically implements:\nInitialization routines Packet transmission Packet reception Interrupt handling Devices are registered with the network stack using:\nmuxDevLoad() 🌳 Flattened Device Tree Integration # Modern VxWorks BSPs often use a Flattened Device Tree (FDT) to describe hardware components.\nA device tree source file (.dts) defines:\nCPU configuration Memory regions Peripheral devices Interrupt mappings This file is compiled into a .dtb binary and loaded during boot, allowing the kernel and drivers to discover hardware dynamically.\nUsing FDT significantly improves BSP portability across boards.\n🧪 Testing and Debugging # After implementation, the BSP must be validated through systematic testing.\nCommon debugging methods include:\nSerial console output JTAG debugging Wind River Workbench debugger System Viewer performance analysis Typical validation tests include:\nTest Area Commands or Tools Expected Result Boot Serial console VxWorks banner and shell prompt Serial putc 'A' Character output Network ifconfig, ping Successful network communication Timer sysClkRateGet Correct system tick rate Interrupts Custom ISR Interrupt handler execution Successful completion of these tests confirms correct BSP integration.\n🧠 BSP Design Best Practices # Developing a reliable BSP requires careful design and testing.\nRecommended practices include:\nUse VxBus for drivers\nThis ensures consistent device management and simplifies integration.\nEnable early debugging output\nEarly boot debug prints help diagnose failures before the kernel starts.\nDesign for scalability\nConsider SMP support and future hardware revisions.\nValidate hardware registers carefully\nIncorrect register addresses are a common source of BSP failures.\nStudy reference BSPs\nWind River reference implementations provide valuable design patterns.\n⚡ Advanced BSP Topics # As embedded platforms become more complex, BSP development may include additional capabilities:\nSecure boot integration Multicore CPU initialization Power management frameworks Virtualization support Containerized runtime environments These advanced features often require close integration between the BSP, kernel configuration, and middleware.\nA well-designed BSP is fundamental to building reliable embedded systems with VxWorks 7. By combining low-level hardware knowledge with VxWorks frameworks such as VxBus and FDT, developers can create robust platform support for modern embedded hardware.\n","date":"2026-03-08","externalUrl":null,"permalink":"/bsp/vxworks-7-bsp-design-guide-for-embedded-developers/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eComprehensive Guide to BSP Design for VxWorks 7\u003c/p\u003e\u003c/blockquote\u003e\n\u003cscript async src=\"https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1543398821442998\"\n     crossorigin=\"anonymous\"\u003e\u003c/script\u003e\n\u003c!-- vxworks6_ads_1 --\u003e\n\u003cp\u003e\u003cins class=\"adsbygoogle\"\nstyle=\"display:block\"\ndata-ad-client=\"ca-pub-1543398821442998\"\ndata-ad-slot=\"7693617958\"\ndata-ad-format=\"auto\"\ndata-full-width-responsive=\"true\"\u003e\u003c/ins\u003e\u003c/p\u003e\n\u003cscript\u003e\n     (adsbygoogle = window.adsbygoogle || []).push({});\n\u003c/script\u003e\n\u003cp\u003eIn real-time operating system (RTOS) environments, \u003cstrong\u003eVxWorks 7\u003c/strong\u003e is widely used in mission-critical systems across aerospace, automotive, defense, and industrial automation. One of the key mechanisms enabling VxWorks to run on different hardware platforms is the \u003cstrong\u003eBoard Support Package (BSP)\u003c/strong\u003e.\u003c/p\u003e","title":"VxWorks 7 BSP Design Guide for Embedded Developers","type":"bsp"},{"content":"","date":"2026-03-08","externalUrl":null,"permalink":"/tags/interconnects/","section":"Tags","summary":"","title":"Interconnects","type":"tags"},{"content":"","date":"2026-03-08","externalUrl":null,"permalink":"/tags/rapidio/","section":"Tags","summary":"","title":"RapidIO","type":"tags"},{"content":" Revisiting PCI–RapidIO Bridge Driver Design on VxWorks: A 2026 Perspective\nAbstract # RapidIO was introduced in the early 2000s as a high-performance packet-switched interconnect designed for embedded multiprocessor systems requiring low latency and deterministic communication. Although the broader industry has largely standardized on PCI Express for general-purpose computing, RapidIO remains widely deployed in aerospace, defense, and industrial control systems where deterministic behavior and long hardware lifecycles are critical.\nThis article revisits the 2010 paper Driver Design of PCI–RapidIO Bridge Based on VxWorks, originally developed at the East China Institute of Computer Technology. The work presented a PCI-to-RapidIO bridge driver implemented on the VxWorks real-time operating system using FPGA-based bridge logic. In this 2026 perspective, we review the original architecture, analyze the driver design principles, and explore how similar approaches can be adapted to modern hardware platforms, including ARM-based systems and contemporary FPGA architectures.\n1. Introduction # Despite the dominance of PCI Express in commercial computing systems, deterministic interconnect technologies continue to play a critical role in mission-critical embedded environments. Applications such as radar processing, avionics data fusion, and industrial automation require predictable communication latency, high reliability, and efficient processor-to-processor messaging.\nRapidIO was designed specifically to address these requirements. Its packet-based architecture supports:\nLow-latency memory transactions Hardware-level message passing Multicast communication Deterministic routing across switching fabrics Although RapidIO’s ecosystem has become smaller over time, many long-lifecycle systems deployed in aerospace and defense environments still rely on RapidIO fabrics.\nIn such systems, PCI–RapidIO bridge devices provide interoperability between legacy PCI devices and RapidIO networks. The 2010 design explored in this article implemented such a bridge using FPGA logic and a VxWorks device driver.\nRevisiting this design provides useful insight into the fundamental principles of embedded driver architecture, many of which remain applicable to modern heterogeneous interconnect systems.\n2. RapidIO Architecture Overview # RapidIO follows a three-layer architecture.\nPhysical Layer # Defines signaling, electrical interfaces, and link initialization. Early implementations used LVDS differential pairs supporting multi-lane configurations.\nTransport Layer # Handles packet routing and addressing across RapidIO switches. Transactions are identified using destination IDs and routing tables.\nLogical Layer # Defines higher-level transaction types including:\nConfiguration reads and writes Memory transactions Messaging Doorbell signaling Compared with early Ethernet-based interconnects, RapidIO provides lower protocol overhead and deterministic transaction latency, making it well suited for embedded multiprocessor systems.\n3. PCI–RapidIO Bridge Architecture # The bridge design used FPGA logic to interface a PCI bus with a RapidIO endpoint.\nHardware Components # The bridge consists of three major modules:\nPCI Interface Core\nImplemented using a Xilinx LogiCORE PCI IP core.\nRapidIO Endpoint Core\nImplemented using a RapidIO protocol IP core.\nBridge Logic Module\nCustom logic responsible for:\nProtocol adaptation Address translation Clock-domain crossing DMA coordination Architecture Overview # +-----------------------------+ | User Application | +-------------+---------------+ | v +-----------------------------+ | RapidIO Driver HAL | | (Nread, Nwrite, Doorbell) | +-------------+---------------+ | v +-----------------------------+ | VxWorks Device Driver | | Interrupts | DMA | Routing | +-------------+---------------+ | v +-----------------------------+ | PCI–RapidIO Bridge | | (Xilinx IP + Custom Logic) | +-------------+---------------+ | v +-----------------------------+ | RapidIO Fabric | | Switches + Endpoints | +-----------------------------+ This layered architecture isolates application software from low-level hardware implementation details.\n4. VxWorks Driver Initialization # Device discovery occurs during system initialization using standard VxWorks PCI APIs.\nif (pciFindDevice(0x0606, 0x8080, unit, \u0026amp;pciBus, \u0026amp;pciDev, \u0026amp;pciFunc) == ERROR) { return 0; } pciConfigInLong(pciBus, pciDev, pciFunc, PCI_CFG_BASE_ADDRESS_0, \u0026amp;membaseCsr); pciConfigInByte(pciBus, pciDev, pciFunc, PCI_CFG_DEV_INT_LINE, \u0026amp;irq); Baseaddr = membaseCsr \u0026amp; 0xffffffff; intConnect(INUM_TO_IVEC((int)irq), (VOIDFUNCPTR)intfunc, 0); intEnable(irq); The initialization routine performs several key tasks:\nLocates the PCI–RapidIO bridge device using Vendor and Device IDs. Retrieves the device memory base address. Obtains the assigned interrupt line. Registers the interrupt service routine (ISR). Enables hardware interrupts. Modern VxWorks BSPs extend this mechanism to support PCIe enumeration, advanced error reporting, and hot-plug detection.\n5. Interrupt Handling # RapidIO devices generate several classes of asynchronous events. Efficient interrupt handling is essential to maintain deterministic system behavior.\nThe ISR processes the following events:\nDMA Completion # Signals completion of memory transfers between PCI memory and RapidIO endpoints. The driver releases semaphores or wakes waiting tasks.\nLink State Changes # Detects RapidIO port status transitions when devices connect or disconnect from the fabric.\nDoorbell Interrupts # Doorbells provide lightweight signaling between devices using a 16-bit payload field.\nMessage Interrupts # Triggered when inbound RapidIO messages arrive. Larger messages may be processed by worker tasks outside the ISR context.\nResponse Interrupts # Generated when read transactions return data from remote devices.\n6. DMA Engine Design # Data movement between PCI memory and RapidIO devices is handled by a hardware DMA engine integrated into the bridge.\nThe DMA engine uses a descriptor-driven architecture. Each descriptor contains:\nLocal PCI memory address Remote RapidIO address Transfer size Transaction type (NREAD or NWRITE) The driver programs descriptors into hardware registers and triggers the DMA engine. Upon completion, an interrupt notifies the driver.\nDMA-based transfers enable efficient movement of large data blocks with minimal CPU overhead.\n7. RapidIO Driver API # The driver exposes a hardware abstraction layer that simplifies interaction with RapidIO devices.\nConfiguration Access # VSTATUS rioConfigurationRead( VINT8 localport, VINT16 destid, VINT8 hopcount, VINT32 offset, VINT32 *readdata ); Memory Transactions # VSTATUS rioNread( VINT8 localport, VINT16 destid, VINT32 pciaddr, VINT32 rioaddr, VINT32 bytcnt ); Doorbell Signaling # VSTATUS rioSendDoorbell( VINT8 localport, VINT16 destid, VINT16 dbinfo ); Message Passing # VSTATUS rioSendMessage( VINT8 localport, VINT16 destid, VINT32 pciaddr, VINT32 standardsize, VINT32 bytcnt ); Routing Table Configuration # VSTATUS rioRouteAddEntry( VINT8 localport, VINT16 destid, VINT8 hopcount, VINT8 tableidx, VINT16 routedestid, VINT8 routeportno ); System Enumeration # VSTATUS rioSystemEnumerate(VINT16 hostdevid); 8. Experimental Results # Performance testing was conducted using PowerPC 7447 boards connected through a Tundra Tsi578 RapidIO switch.\nOperation Payload Time (µs) Bandwidth Doorbell 2 B 7.04 — Config Read 4 B 10.58 — Config Write 4 B 3.77 — NREAD 2 KB 26.71 76.66 MB/s NREAD 64 KB 417.90 156.82 MB/s NWRITE 2 KB 16.08 — NWRITE 64 KB 414.18 158.23 MB/s Message 4096 B 170.50 — For hardware available in 2010, these results demonstrated efficient data movement across the RapidIO fabric.\n9. Modern Adaptations (2026) # If implemented today, several aspects of the design could be modernized.\nModern FPGA Platforms # Contemporary FPGA devices such as Xilinx Versal ACAP and Intel Agilex can integrate both PCIe and RapidIO endpoints directly into programmable logic, simplifying bridge implementations.\nARM-Based Embedded Systems # RapidIO endpoints can be connected to ARM-based SoCs used in modern edge computing environments.\nVirtualization Support # Modern VxWorks deployments often include hypervisor-based partitioning. RapidIO drivers may run as isolated real-time processes to improve safety and security.\nHybrid Interconnect Architectures # Future systems may combine multiple fabrics:\nPCIe for host communication RapidIO for deterministic device networks CXL for memory-coherent acceleration Bridge drivers similar to the original design enable interoperability across these heterogeneous environments.\n10. Conclusion # The PCI–RapidIO bridge driver presented in the 2010 work remains a valuable reference for embedded systems engineers. Although RapidIO is no longer a mainstream interconnect technology, it continues to serve specialized environments where deterministic communication and reliability are essential.\nRevisiting this design highlights several enduring driver development principles:\nModular hardware abstraction layers Efficient interrupt handling DMA-driven data movement Scalable system enumeration These principles remain directly applicable to modern heterogeneous computing systems where multiple interconnect technologies must coexist.\nAs embedded platforms evolve toward software-defined architectures and accelerator-rich designs, interoperability between legacy and emerging fabrics will continue to be an important engineering challenge.\n","date":"2026-03-08","externalUrl":null,"permalink":"/bsp/revisiting-pcirapidio-bridge-driver-design-on-vxworks-a-2026-perspective/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eRevisiting PCI–RapidIO Bridge Driver Design on VxWorks: A 2026 Perspective\u003c/p\u003e\u003c/blockquote\u003e\n\u003cscript async src=\"https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1543398821442998\"\n     crossorigin=\"anonymous\"\u003e\u003c/script\u003e\n\u003c!-- vxworks6_ads_1 --\u003e\n\u003cp\u003e\u003cins class=\"adsbygoogle\"\nstyle=\"display:block\"\ndata-ad-client=\"ca-pub-1543398821442998\"\ndata-ad-slot=\"7693617958\"\ndata-ad-format=\"auto\"\ndata-full-width-responsive=\"true\"\u003e\u003c/ins\u003e\u003c/p\u003e","title":"Revisiting PCI–RapidIO Bridge Driver Design on VxWorks: A 2026 Perspective","type":"bsp"},{"content":" Deploying VxWorks on Raspberry Pi 4: A Practical Guide\nVxWorks is a widely used real-time operating system (RTOS) developed by Wind River and deployed in mission-critical systems across aerospace, automotive, industrial automation, and networking infrastructure.\nWith modern versions of VxWorks 7, developers can experiment with the RTOS on affordable development platforms such as the Raspberry Pi 4. Powered by a quad-core ARM Cortex-A72 processor and up to 8 GB of RAM, the Raspberry Pi 4 provides a capable environment for evaluating VxWorks features including real-time scheduling, networking, device drivers, and Real-Time Processes (RTPs).\nThis guide walks through the process of deploying VxWorks on a Raspberry Pi 4, from preparing the development environment to booting the system and running applications.\n🧰 Prerequisites # Before starting, prepare the following hardware and software components.\nHardware # Raspberry Pi 4 Model B (4 GB or 8 GB recommended) MicroSD card (8 GB or larger, formatted as FAT32) USB-to-TTL serial adapter for UART console access Ethernet connection or Wi-Fi network Optional USB flash drive for testing storage features Software # Linux development host (Ubuntu or another Debian-based distribution recommended) VxWorks SDK for Raspberry Pi 4 from Wind River Labs Raspberry Pi firmware package U-Boot bootloader source ARM64 cross-compiler (gcc-aarch64-linux-gnu) Serial terminal software such as Minicom or PuTTY Install required development tools on the Linux host:\nsudo apt update sudo apt install build-essential libc6:i386 gcc-aarch64-linux-gnu python3-pip sudo pip install pyftpdlib These packages provide the compiler, build tools, and utilities required to build boot components and deploy applications.\n⚙️ Setting Up the Development Environment # After installing the required tools, the next step is to configure the VxWorks SDK and prepare the boot media.\nDownload and Initialize the SDK # Download the VxWorks SDK package for Raspberry Pi 4 and extract it.\ntar -xvf vxworks-sdk.tar.gz cd vxworks-sdk source sdkenv.sh The sdkenv.sh script configures environment variables required for cross-compilation and development tools.\nPrepare the SD Card # Format the MicroSD card using the FAT32 filesystem.\nDownload the Raspberry Pi firmware and extract it:\nwget https://github.com/raspberrypi/firmware/archive/1.20200212.tar.gz tar -xzf 1.20200212.tar.gz Copy the firmware boot files to the SD card:\ncp -r firmware-1.20200212/boot/* /path/to/sdcard/ Next, copy the VxWorks boot files included in the SDK:\ncp -r /path/to/vxsdk/sdcard/* /path/to/sdcard/ At this stage the SD card contains firmware, boot configuration files, and the VxWorks kernel image.\n🔧 Building the U-Boot Bootloader # VxWorks on the Raspberry Pi 4 uses U-Boot as the bootloader.\nClone the U-Boot repository:\ngit clone https://gitlab.denx.de/u-boot/u-boot.git cd u-boot Configure the build for Raspberry Pi 4:\nCROSS_COMPILE=aarch64-linux-gnu- make rpi_4_defconfig Compile the bootloader:\nCROSS_COMPILE=aarch64-linux-gnu- make After compilation completes, copy the bootloader to the SD card:\ncp u-boot.bin /path/to/sdcard/u-boot-64.bin Once the SD card contains firmware, U-Boot, and the VxWorks kernel image, it is ready for booting.\n🔌 Connecting the UART Console # Serial console access is important for monitoring the boot process and interacting with the VxWorks shell.\nConnect the USB-to-TTL adapter to the Raspberry Pi GPIO pins:\nAdapter Raspberry Pi Pin GND Pin 6 TXD Pin 10 (GPIO15 RX) RXD Pin 8 (GPIO14 TX) Launch a serial terminal:\nminicom -b 115200 -o -D /dev/ttyUSB0 Use the following settings:\nBaud rate: 115200 Data bits: 8 Parity: none Stop bits: 1 Flow control: disabled This console will display boot messages and provide access to the VxWorks shell.\n🚀 Booting VxWorks on Raspberry Pi 4 # Insert the prepared MicroSD card into the Raspberry Pi and power on the board.\nDuring startup, U-Boot initializes the hardware and loads the VxWorks kernel.\nTypical boot output looks similar to the following:\nU-Boot 2020.07 ## Booting kernel from Legacy Image at 00100000 ... Image Name: vxworks ... VxWorks 7 SMP 64-bit Board: Raspberry Pi 4 Model B Once the kernel initializes, the VxWorks shell becomes available.\nVerify the system using standard commands.\nDisplay version information:\n-\u0026gt; version List running tasks:\n-\u0026gt; i Typical tasks include system services such as:\ntShell0 tNet0 tLogTask At this point the system is fully operational.\n📦 Deploying Applications # Applications can be deployed to the VxWorks target using FTP or network file systems.\nStart a simple FTP server on the development host:\nsudo python -m pyftpdlib -p 21 -u target -P vxTarget -d $HOME \u0026amp; On the VxWorks target, create a network device:\n-\u0026gt; netDevCreate(\u0026#34;/wrs\u0026#34;, \u0026#34;192.168.10.191\u0026#34;, 1) Access the remote filesystem:\n-\u0026gt; cmd [vxWorks *]# cd /wrs You can then run executables stored on the host.\nExample:\n[vxWorks *]# hello This approach allows quick testing and deployment during development.\n📦 Running RTP Containers # Modern versions of VxWorks support containerized deployment for Real-Time Processes (RTPs).\nContainerization allows applications to run in isolated environments, simplifying deployment and updates.\nBuild VxWorks Projects # Using Wind River Workbench, create:\na VSB (VxWorks Source Build) a VIP (VxWorks Image Project) Enable container components such as:\nINCLUDE_CONTAINER_RUNTIME Build both projects to generate the runtime image.\nBuild the Container Image # Create a container build directory with a Dockerfile referencing the RTP executable.\nBuild the image using Buildah:\nbuildah bud --arch arm64 --os vxworks -f Dockerfile -t philosophers Push the OCI image to a container registry if needed.\nRun the Container on VxWorks # On the target system:\nSet the system date:\ndate 2026-03-01 Pull the container image:\nvxc pull \u0026lt;account\u0026gt;/philosophers.oci -k Create a container instance:\nvxc create --bundle /ram0/philosophers phil Start the container:\nvxc start phil Stop it when finished:\nvxc kill phil This workflow allows RTP applications to be deployed and managed in a modern container-based environment.\n🛠 Troubleshooting # If the system does not boot or behave as expected, check the following common issues.\nNo console output\nVerify UART wiring Confirm baud rate settings Ensure the SD card contains the correct firmware and boot files Networking issues\nVerify bootline parameters Confirm DHCP availability or correct IP configuration Unsupported BSP warning\nSome evaluation BSP builds may display warnings indicating unsupported status. These typically do not prevent normal development use.\nContainer runtime errors\nEnsure the target system has internet access and valid DNS configuration.\nYou can test connectivity with:\nping \u0026#34;www.google.com\u0026#34; 📊 Conclusion # Running VxWorks on the Raspberry Pi 4 provides an accessible platform for experimenting with real-time operating systems and modern embedded development techniques.\nFrom bootloader setup and kernel deployment to RTP containerization, the platform allows developers to explore key VxWorks capabilities on affordable hardware. This environment is particularly useful for prototyping, testing device drivers, and experimenting with networking or real-time control workloads.\nAs VxWorks continues to evolve with support for edge computing, AI workloads, and cloud-connected systems, platforms like the Raspberry Pi 4 offer a practical development sandbox for embedded engineers exploring these technologies.\n","date":"2026-03-08","externalUrl":null,"permalink":"/bsp/deploying-vxworks-7-on-raspberry-pi-4-a-practical-guide/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eDeploying VxWorks on Raspberry Pi 4: A Practical Guide\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eVxWorks is a widely used real-time operating system (RTOS) developed by Wind River and deployed in mission-critical systems across aerospace, automotive, industrial automation, and networking infrastructure.\u003c/p\u003e","title":"Deploying VxWorks 7 on Raspberry Pi 4: A Practical Guide","type":"bsp"},{"content":"","date":"2026-03-08","externalUrl":null,"permalink":"/tags/embedded-development/","section":"Tags","summary":"","title":"Embedded Development","type":"tags"},{"content":"","date":"2026-03-08","externalUrl":null,"permalink":"/tags/raspberry-pi/","section":"Tags","summary":"","title":"Raspberry Pi","type":"tags"},{"content":" Mixing Modern Multi-Core Processors with Open Architectures\n✈️ The Rise of Smart Avionics Display Systems # Modern aircraft cockpits have evolved dramatically over the past few decades. Early aviation systems relied on analog gauges and dedicated hardware instruments, each responsible for displaying a single function such as altitude, speed, or engine performance.\nWith advances in digital computing and display technology, these analog instruments gradually gave way to integrated digital cockpit displays, often referred to as glass cockpits. These systems present a consolidated and highly dynamic view of aircraft data, improving situational awareness and operational efficiency for pilots.\nToday’s avionics displays often take the form of multifunction displays (MFDs)—large digital panels capable of rendering navigation data, sensor outputs, aircraft status, and mission information on a single screen.\nRecent developments have accelerated this transformation even further:\nLarger and higher-resolution cockpit displays Increased integration of avionics subsystems Advanced features such as sensor fusion and synthetic vision Touchscreen control interfaces replacing physical buttons These trends have significantly increased the processing requirements of avionics platforms, pushing the industry toward more powerful computing architectures.\n🧠 Multi-Core Processors Transform Avionics Computing # The global semiconductor industry has largely transitioned from single-core processors to multi-core architectures. This shift is driven by the need for higher performance while maintaining acceptable power consumption.\nIn avionics systems, multi-core processors offer several advantages:\nIncreased computational throughput Improved performance for complex graphics workloads Reduced size, weight, and power (SWaP) Greater system integration However, adopting multi-core processors in safety-critical avionics systems introduces new challenges.\nCertification standards such as DO-178C for software and DO-254 for hardware require deterministic behavior. Multi-core processors introduce complexities such as:\nShared resources between cores Cache interference Scheduling unpredictability Cross-core timing synchronization Regulatory guidance such as CAST-32A and related certification frameworks has emerged to address these challenges and support safe multi-core avionics deployments.\n🧩 Open Architectures and Modular Avionics # Another major transformation in avionics development is the shift toward open system architectures.\nAircraft manufacturers increasingly demand:\nGreater design control Multi-vendor component sourcing Long-term sustainability Reduced dependency on proprietary technologies This approach aligns with the Modular Open Systems Approach (MOSA) promoted by defense organizations.\nOpen architecture systems rely on standardized interfaces and modular software frameworks that separate application logic from underlying hardware. This enables:\nImproved software portability Reduced integration risks Lower lifecycle costs Easier technology upgrades A key concept enabling this model is the hardware abstraction layer, which shields applications from hardware-specific details.\n🖥️ ARINC 653 and Portable Avionics Software # One of the most important standards supporting avionics software portability is ARINC 653.\nARINC 653 defines a partitioned real-time operating environment where multiple applications can run independently on shared hardware while maintaining strict isolation.\nKey benefits of ARINC 653 include:\nTime and space partitioning Predictable real-time scheduling Fault isolation between applications Support for mixed-criticality systems Using ARINC 653-compliant operating systems allows developers to create portable avionics applications that can be migrated across hardware platforms with minimal changes.\nFrameworks built around ARINC 653 enable the integration of:\nSafety-critical avionics software Mission-critical applications Non-critical user interfaces All while maintaining strict safety boundaries.\n🎮 GPU Acceleration in Modern Cockpit Displays # Graphics processing units (GPUs) have become essential components of modern avionics display platforms.\nOriginally used primarily for rendering graphics, GPUs are now capable of performing highly parallel computations, making them suitable for:\n3D visualization Synthetic vision systems Sensor fusion processing Video encoding and decoding AI-assisted decision support Historically, avionics graphics systems relied on OpenGL SC, a safety-critical variant of the OpenGL standard.\nHowever, newer systems are transitioning toward Vulkan SC, a modern graphics and compute API designed for high performance and greater control over GPU behavior.\nKey advantages of Vulkan-based graphics frameworks include:\nImproved performance on multi-core systems Lower driver overhead Better utilization of modern GPUs Greater control over graphics pipelines Benchmarks have demonstrated that Vulkan implementations can significantly outperform legacy OpenGL pipelines in GPU-intensive workloads.\n🔐 Managing Mixed-Criticality Systems # Modern avionics display systems often host applications with different levels of safety criticality on the same hardware platform.\nFor example:\nFlight control visualization may require the highest safety certification levels Mission or sensor applications may have lower safety requirements User interfaces may operate at even lower levels of assurance Supporting such environments requires careful isolation of system components.\nTechnologies used to enable mixed-criticality systems include:\nHypervisors and virtualization Partitioned operating systems Hardware monitoring and watchdog mechanisms Controlled inter-process communication (IPC) By isolating applications in partitions and controlling resource access, avionics platforms can safely run multiple workloads on shared hardware.\n⚙️ Practical Development Challenges # Building a next-generation avionics display platform involves addressing several technical risks.\nCommon challenges include:\nEnsuring deterministic execution on multi-core systems Managing shared hardware resources Handling GPU scheduling behavior Achieving certification compliance Integrating complex commercial software stacks System designers must carefully evaluate processor architectures, graphics capabilities, and operating system support to meet both performance and certification requirements.\nIn many cases, development teams adopt incremental strategies—initially using a limited subset of processor cores and gradually enabling more advanced capabilities as validation progresses.\n📈 Lessons Learned from Next-Generation Platforms # Experience from modern avionics development programs highlights several key lessons:\nAdopt open standards early\nOpen architectures significantly reduce long-term integration risks and protect software investments.\nPlan for hardware evolution\nProcessor architectures inevitably change over time, making portability a critical design goal.\nDesign for mixed-criticality environments\nFuture avionics systems will increasingly consolidate workloads onto shared computing platforms.\nMaintain fallback strategies\nComplex system development requires contingency planning in case chosen technologies encounter unexpected challenges.\n🚀 The Future of Smart Avionics Platforms # The transition toward multi-core processors, open architectures, and advanced GPU acceleration is reshaping avionics display computing.\nThese technologies enable:\nHigher processing performance Reduced system weight and power consumption Greater application flexibility Improved long-term sustainability While integrating these capabilities presents technical challenges, the benefits are substantial. Through careful system design, open standards, and collaboration across the aerospace ecosystem, next-generation avionics platforms are becoming more powerful, modular, and adaptable than ever before.\n","date":"2026-03-07","externalUrl":null,"permalink":"/industries/building-next-gen-avionics-displays-with-multi-core-open-architectures/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eMixing Modern Multi-Core Processors with Open Architectures\u003c/p\u003e\u003c/blockquote\u003e\n\u003cscript async src=\"https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1543398821442998\"\n     crossorigin=\"anonymous\"\u003e\u003c/script\u003e\n\u003c!-- vxworks6_ads_1 --\u003e\n\u003cp\u003e\u003cins class=\"adsbygoogle\"\nstyle=\"display:block\"\ndata-ad-client=\"ca-pub-1543398821442998\"\ndata-ad-slot=\"7693617958\"\ndata-ad-format=\"auto\"\ndata-full-width-responsive=\"true\"\u003e\u003c/ins\u003e\u003c/p\u003e\n\u003cscript\u003e\n     (adsbygoogle = window.adsbygoogle || []).push({});\n\u003c/script\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e✈️ The Rise of Smart Avionics Display Systems \n    \u003cdiv id=\"-the-rise-of-smart-avionics-display-systems\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-the-rise-of-smart-avionics-display-systems\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eModern aircraft cockpits have evolved dramatically over the past few decades. Early aviation systems relied on \u003cstrong\u003eanalog gauges and dedicated hardware instruments\u003c/strong\u003e, each responsible for displaying a single function such as altitude, speed, or engine performance.\u003c/p\u003e","title":"Building Next-Gen Avionics Displays with Multi-Core Open Architectures","type":"industries"},{"content":"","date":"2026-03-07","externalUrl":null,"permalink":"/tags/mosa/","section":"Tags","summary":"","title":"MOSA","type":"tags"},{"content":"","date":"2026-03-07","externalUrl":null,"permalink":"/tags/multi-core-processors/","section":"Tags","summary":"","title":"Multi-Core Processors","type":"tags"},{"content":"","date":"2026-03-07","externalUrl":null,"permalink":"/tags/vulkan-sc/","section":"Tags","summary":"","title":"Vulkan SC","type":"tags"},{"content":" Mastering VxWorks Programming: A Comprehensive Guide for Embedded Developers\nVxWorks is one of the most widely used real-time operating systems (RTOS) for mission-critical embedded systems. Developed by Wind River, it is known for its deterministic performance, reliability, and scalability in environments where timing guarantees and system stability are essential.\nVxWorks powers a vast range of systems across aerospace, defense, automotive, industrial automation, and medical devices. Developers working with VxWorks leverage its multitasking kernel, interprocess communication (IPC) mechanisms, and extensive APIs to build robust and predictable real-time software.\nThis guide introduces the core concepts of VxWorks programming, including development setup, task management, synchronization mechanisms, and debugging tools used to create high-performance embedded applications.\n🚀 History and Evolution of VxWorks # VxWorks was first released in 1987 by Wind River Systems as one of the earliest commercial RTOS platforms designed for embedded systems. Over time, it became the operating system behind numerous mission-critical systems, including spacecraft, military avionics, and industrial control systems.\nOne of the most significant architectural changes came with the release of VxWorks 7 in 2014, which introduced a modular design separating the core kernel from middleware components. This architecture allows developers to update individual system components without requiring full system recertification.\nModern VxWorks releases support:\nMulti-core processors Virtualization technologies Edge computing frameworks Safety certification standards such as DO-178C and ISO 26262 As embedded systems evolve toward connected and software-defined architectures, VxWorks continues to adapt with support for containerized workloads, cloud connectivity, and advanced security features.\n🛠️ Setting Up the VxWorks Development Environment # VxWorks development is typically performed using Wind River Workbench, an Eclipse-based integrated development environment (IDE).\nWorkbench provides a unified workflow for writing, building, debugging, and deploying VxWorks applications.\nCommon VxWorks project types include:\nVxWorks Image Projects (VIPs) – build custom kernel images Downloadable Kernel Modules (DKMs) – kernel-space applications Real-Time Processes (RTPs) – user-space applications with memory protection The development workflow typically includes:\nInstalling the VxWorks SDK and Workbench IDE Configuring a hardware target or simulator Creating a project (such as a DKM example) Booting the target system Downloading and executing the module VxWorks supports a wide range of processor architectures, including:\nArm Intel x86 PowerPC RISC-V Developers can also use VxSim, a built-in simulator that enables testing without physical hardware.\n⚙️ Tasks and Scheduling # Concurrency in VxWorks is implemented using tasks, which are lightweight threads managed by the kernel.\nTasks are created using functions such as taskSpawn() or taskInit().\nEach task specifies parameters including:\nPriority (0–255, lower values represent higher priority) Stack size Entry function Example task creation:\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; void helloTask(void) { printf(\u0026#34;Hello, VxWorks!\\n\u0026#34;); } void startHello() { taskSpawn(\u0026#34;helloTask\u0026#34;, 100, 0, 2000, (FUNCPTR)helloTask, 0,0,0,0,0,0,0,0,0,0); } The scheduler supports:\nPriority-based preemption Round-robin scheduling for equal-priority tasks Partitioned scheduling for safety-critical systems Tasks can be managed using APIs such as:\ntaskSuspend() taskResume() taskDelete() 🔄 Intertask Communication and Synchronization # Real-time applications require reliable mechanisms for communication and synchronization between tasks.\nVxWorks provides several IPC mechanisms.\nSemaphores # Semaphores provide synchronization and mutual exclusion.\nTypes include:\nBinary semaphores Counting semaphores Mutex semaphores Example mutex usage:\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;semLib.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; #include \u0026lt;logLib.h\u0026gt; SEM_ID semMtx; struct mem { int x; int y; int z; } data; void createM() { semMtx = semMCreate(SEM_Q_FIFO | SEM_DELETE_SAFE); } void SensorP(int protect) { for (int i = 0; i \u0026lt; 10; i++) { if (protect) semTake(semMtx, WAIT_FOREVER); data.x++; data.y++; data.z++; if (protect) semGive(semMtx); taskDelay(10); } } void SensorM(int protect) { for (int i = 0; i \u0026lt; 10; i++) { if (protect) semTake(semMtx, WAIT_FOREVER); data.x--; data.y--; data.z--; if (protect) semGive(semMtx); taskDelay(10); } } void mutexExample(int protect) { data.x = 0; data.y = 0; data.z = 0; taskSpawn(\u0026#34;tsp\u0026#34;, 95, 0, 2000, (FUNCPTR)SensorP, protect, 0, 0, 0, 0, 0, 0, 0, 0, 0); taskSpawn(\u0026#34;tsm\u0026#34;, 95, 0, 2000, (FUNCPTR)SensorM, protect, 0, 0, 0, 0, 0, 0, 0, 0, 0); } Mutex semaphores protect shared resources between tasks using semTake() and semGive().\nMessage Queues # Message queues allow tasks to exchange structured data.\nExample:\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;msgQLib.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; MSG_Q_ID msgQId; void msgQExample() { msgQId = msgQCreate(10, 100, MSG_Q_FIFO); // Max 10 msgs, each 100 bytes, FIFO char msg[100] = \u0026#34;Hello from sender!\u0026#34;; msgQSend(msgQId, msg, strlen(msg) + 1, WAIT_FOREVER, MSG_PRI_NORMAL); char recvBuf[100]; msgQReceive(msgQId, recvBuf, 100, WAIT_FOREVER); printf(\u0026#34;Received: %s\\n\u0026#34;, recvBuf); msgQDelete(msgQId); } Queues support:\nPriority messaging Blocking or timed operations Producer-consumer architectures Signals and Shared Memory # VxWorks also supports:\nPOSIX signals for asynchronous notifications Shared memory mechanisms for multiprocessor systems These features are often used in distributed or high-performance embedded systems.\n⚡ Interrupt Handling # Interrupts allow the system to respond immediately to hardware events.\nIn VxWorks, interrupt service routines (ISRs) are connected using intConnect().\nExample ISR registration:\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;intLib.h\u0026gt; #include \u0026lt;iv.h\u0026gt; // For INUM_TO_IVEC void myISR(int param) { printf(\u0026#34;Interrupt occurred with param: %d\\n\u0026#34;, param); } void setupInterrupt(int intNum, int param) { intConnect(INUM_TO_IVEC(intNum), myISR, param); } VxWorks supports:\nNested interrupts Deferred interrupt processing Custom exception handling through excLib Efficient interrupt design is critical to maintaining real-time determinism.\n🧠 Memory Management # VxWorks supports both static and dynamic memory management.\nDevelopers can allocate memory using standard C functions:\nmalloc() free() For embedded systems with strict reliability requirements, VxWorks provides memory partitions using memPartLib, allowing developers to isolate memory pools and reduce fragmentation.\nReal-Time Processes (RTPs) can also run in protected virtual memory environments, improving system stability.\n📂 File Systems and I/O # VxWorks includes several file systems optimized for embedded storage.\nCommon options include:\ndosFs – FAT-compatible file system HRFS – High-Reliability File System for critical data storage Example file operations:\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;ioLib.h\u0026gt; #include \u0026lt;fcntl.h\u0026gt; void fileIOExample() { int fd = open(\u0026#34;/ram0/test.txt\u0026#34;, O_CREAT | O_WRONLY, 0644); if (fd == ERROR) { printf(\u0026#34;Error opening file\\n\u0026#34;); return; } char *msg = \u0026#34;Hello, VxWorks File!\\n\u0026#34;; write(fd, msg, strlen(msg)); close(fd); fd = open(\u0026#34;/ram0/test.txt\u0026#34;, O_RDONLY, 0); char buf[50]; int bytes = read(fd, buf, sizeof(buf)); buf[bytes] = \u0026#39;\\0\u0026#39;; printf(\u0026#34;Read: %s\\n\u0026#34;, buf); close(fd); } The I/O architecture is POSIX-like and supports devices such as:\nSerial ports Network interfaces USB devices Flash storage 🌐 Networking in VxWorks # VxWorks includes a full networking stack supporting:\nIPv4 and IPv6 TCP and UDP Deterministic networking such as Time-Sensitive Networking (TSN) Applications use standard Berkeley socket APIs.\nExample TCP client:\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;sockLib.h\u0026gt; #include \u0026lt;inetLib.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;string.h\u0026gt; void tcpClientExample(char *serverIp, int port) { int sock = socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in serverAddr; bzero((char *)\u0026amp;serverAddr, sizeof(serverAddr)); serverAddr.sin_family = AF_INET; serverAddr.sin_port = htons(port); serverAddr.sin_addr.s_addr = inet_addr(serverIp); if (connect(sock, (struct sockaddr *)\u0026amp;serverAddr, sizeof(serverAddr)) == ERROR) { printf(\u0026#34;Connect failed\\n\u0026#34;); close(sock); return; } char *msg = \u0026#34;Hello from client!\u0026#34;; send(sock, msg, strlen(msg), 0); close(sock); } Networking features make VxWorks suitable for connected industrial and edge computing systems.\n🧪 Debugging and Testing Tools # Wind River Workbench includes powerful debugging tools for real-time systems.\nKey tools include:\nKernel debugger\nSupports breakpoints, stepping, and variable inspection.\nSystem Viewer\nVisualizes task execution timelines, interrupts, and scheduling behavior.\nWindView\nCaptures event logs for performance analysis.\nSimulator (VxSim)\nAllows developers to test applications without hardware targets.\nFor reliability, developers often monitor stack usage and integrate assertion checks throughout the system.\n🔐 Security in VxWorks Applications # Modern embedded systems must address security alongside real-time performance.\nVxWorks includes built-in security mechanisms such as:\nSecure boot Kernel hardening Encrypted storage Access control systems Cryptographic functionality is provided through OpenSSL libraries with support for FIPS-compliant encryption.\nSecure coding practices remain essential when building safety-critical systems.\n🏭 Real-World Applications # VxWorks is widely used in industries where system reliability and deterministic execution are essential.\nExamples include:\nAerospace and defense\nFlight control systems, satellite platforms, and avionics computers.\nAutomotive\nAdvanced driver-assistance systems (ADAS) and autonomous vehicle components.\nIndustrial automation\nRobotics, factory control systems, and real-time monitoring equipment.\nMedical devices\nPatient monitoring systems, imaging equipment, and surgical devices.\nThese applications rely on VxWorks to deliver predictable timing and long-term reliability.\n🔮 Future Trends in VxWorks Development # Recent VxWorks releases have expanded support for modern software architectures.\nEmerging capabilities include:\nOCI container support Kubernetes orchestration Edge-to-cloud integration AI and machine-learning frameworks These features enable developers to deploy real-time workloads within distributed edge computing environments.\nAs embedded systems become more connected and intelligent, VxWorks continues evolving to support modern development models while preserving the deterministic behavior required by safety-critical systems.\n🏁 Conclusion # VxWorks remains one of the most powerful platforms for developing mission-critical real-time systems. By mastering its task model, IPC mechanisms, interrupt handling, and debugging tools, developers can build highly reliable embedded software for demanding environments.\nWhether developing avionics software, industrial robotics controllers, or next-generation autonomous systems, understanding the core principles of VxWorks programming provides a strong foundation for building safe, deterministic, and high-performance embedded applications.\n","date":"2026-03-07","externalUrl":null,"permalink":"/app/mastering-vxworks-programming-for-real-time-embedded-systems/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eMastering VxWorks Programming: A Comprehensive Guide for Embedded Developers\u003c/p\u003e\u003c/blockquote\u003e\n\u003cscript async src=\"https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1543398821442998\"\n     crossorigin=\"anonymous\"\u003e\u003c/script\u003e\n\u003c!-- vxworks6_ads_1 --\u003e\n\u003cp\u003e\u003cins class=\"adsbygoogle\"\nstyle=\"display:block\"\ndata-ad-client=\"ca-pub-1543398821442998\"\ndata-ad-slot=\"7693617958\"\ndata-ad-format=\"auto\"\ndata-full-width-responsive=\"true\"\u003e\u003c/ins\u003e\u003c/p\u003e\n\u003cscript\u003e\n     (adsbygoogle = window.adsbygoogle || []).push({});\n\u003c/script\u003e\n\u003cp\u003eVxWorks is one of the most widely used real-time operating systems (RTOS) for mission-critical embedded systems. Developed by Wind River, it is known for its deterministic performance, reliability, and scalability in environments where timing guarantees and system stability are essential.\u003c/p\u003e","title":"Mastering VxWorks Programming for Real-Time Embedded Systems","type":"app"},{"content":"","date":"2026-03-07","externalUrl":null,"permalink":"/tags/software-development/","section":"Tags","summary":"","title":"Software Development","type":"tags"},{"content":"","date":"2026-03-06","externalUrl":null,"permalink":"/tags/cloud-infrastructure/","section":"Tags","summary":"","title":"Cloud Infrastructure","type":"tags"},{"content":" Wind River and AMD Strategic Partnership: Unified O-RAN and AI-RAN Platform\nWind River, an Aptiv company specializing in intelligent edge software, and AMD have announced a strategic collaboration to deliver what they describe as the industry\u0026rsquo;s first commercial platform capable of running Open RAN (O-RAN) and AI-driven RAN (AI-RAN) workloads on the same hardware infrastructure.\nThe joint solution aims to help telecom operators modernize network infrastructure while reducing cost and operational complexity.\n📡 Solving the Operator Infrastructure Challenge # Telecommunications operators have traditionally deployed separate systems to support radio access network workloads and artificial intelligence applications.\nThis separation creates several operational challenges:\nHigher Capital Expenditure (CAPEX) due to duplicate hardware deployments Increased infrastructure complexity from maintaining independent software stacks Operational overhead when integrating analytics and AI tools into live networks The new platform addresses these issues by allowing Virtualized RAN (vRAN) functions and AI inference workloads to run simultaneously on a unified distributed infrastructure.\nBy consolidating these capabilities onto a shared hardware platform, operators can significantly improve infrastructure utilization.\n🧠 Core Technology Stack # The joint solution combines high-performance processor technology with carrier-grade cloud software to create a flexible telecom computing platform.\nComponent Role in the Platform AMD EPYC™ CPUs Provide high-performance compute resources for real-time RAN processing and AI inference workloads Wind River Cloud Platform Supplies distributed cloud infrastructure with automation, orchestration, and high-availability capabilities Wind River Cloud Platform enables operators to deploy and manage workloads across distributed edge environments while maintaining telecom-grade reliability and lifecycle management.\nTogether, the technologies form a scalable foundation for next-generation telecom edge computing.\n🚀 Benefits for Telecom Operators # Running Open RAN and AI-RAN workloads on a unified infrastructure provides several key advantages.\nLower Infrastructure Costs # By consolidating workloads onto shared hardware, operators can reduce equipment requirements and lower both CAPEX and operational costs.\nImproved Edge Intelligence # AI workloads can be deployed directly alongside vRAN functions at the network edge, enabling faster decision-making and real-time analytics.\nReal-Time AI Applications # Edge-deployed AI capabilities enable new classes of network intelligence, including:\nTraffic Prediction for proactive capacity planning Anomaly Detection for improved network monitoring and security Energy Optimization through dynamic power management Flexible Network Evolution # Operators can introduce additional AI capabilities over time without replacing existing infrastructure, enabling a gradual transition toward more intelligent networks.\n🗣️ Leadership Perspectives # Industry leaders from both companies emphasized the importance of integrating AI capabilities directly into telecom infrastructure.\n\u0026ldquo;We are helping customers seamlessly integrate AI into their networks without duplicating infrastructure, providing the intelligence operators need without the burden of complexity.\u0026rdquo;\n— Javed Khan, EVP of Aptiv and President of Smart Systems\n\u0026ldquo;Our world-class AMD EPYC CPUs provide a powerful performance and scalability foundation for AI-driven RAN architectures.\u0026rdquo;\n— Philip Guido, Chief Commercial Officer at AMD\nThese perspectives highlight the growing importance of AI-enhanced network management in modern telecom infrastructure.\n🔮 Future Roadmap # The collaboration between Wind River and AMD will continue through several initiatives, including:\nJoint optimization of software and hardware stacks Expanded testing and validation for telecom workloads Proof-of-Concept (PoC) deployments with telecommunications operators As the telecom industry evolves toward 5G Advanced and 6G architectures, platforms capable of efficiently combining networking and AI workloads are expected to play a critical role in improving performance, automation, and energy efficiency.\n","date":"2026-03-06","externalUrl":null,"permalink":"/news/wind-river-and-amd-launch-unified-o-ran-and-ai-ran-platform/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eWind River and AMD Strategic Partnership: Unified O-RAN and AI-RAN Platform\u003c/p\u003e\u003c/blockquote\u003e\n\u003cscript async src=\"https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1543398821442998\"\n     crossorigin=\"anonymous\"\u003e\u003c/script\u003e\n\u003c!-- vxworks6_ads_1 --\u003e\n\u003cp\u003e\u003cins class=\"adsbygoogle\"\nstyle=\"display:block\"\ndata-ad-client=\"ca-pub-1543398821442998\"\ndata-ad-slot=\"7693617958\"\ndata-ad-format=\"auto\"\ndata-full-width-responsive=\"true\"\u003e\u003c/ins\u003e\u003c/p\u003e","title":"Wind River and AMD Launch Unified O-RAN and AI-RAN Platform","type":"news"},{"content":"","date":"2026-02-15","externalUrl":null,"permalink":"/tags/autonomous-networks/","section":"Tags","summary":"","title":"Autonomous Networks","type":"tags"},{"content":"","date":"2026-02-15","externalUrl":null,"permalink":"/tags/cloud-native-telecom/","section":"Tags","summary":"","title":"Cloud-Native Telecom","type":"tags"},{"content":"","date":"2026-02-15","externalUrl":null,"permalink":"/tags/digital-sovereignty/","section":"Tags","summary":"","title":"Digital Sovereignty","type":"tags"},{"content":"","date":"2026-02-15","externalUrl":null,"permalink":"/tags/elxr-pro-linux/","section":"Tags","summary":"","title":"ELxr Pro Linux","type":"tags"},{"content":"","date":"2026-02-15","externalUrl":null,"permalink":"/tags/mwc-2026/","section":"Tags","summary":"","title":"MWC 2026","type":"tags"},{"content":" Wind River at MWC 2026: Powering the Future of Edge AI and Autonomous Networks\nWind River, a subsidiary of Aptiv and a global leader in intelligent edge software, is set to showcase its latest Edge AI and autonomous infrastructure solutions at MWC Barcelona 2026 (March 2–5).\nLocated at Booth 2F25 (Hall 2), the company is positioning itself as the strategic bridge between 5G connectivity and real-time AI execution—where networking infrastructure becomes part of the compute stack.\n🤖 Convergence of AI and Real-Time Control # According to CTO Paul Miller, the next frontier is not just connectivity—it is distributed intelligence.\n“Intelligence does not live in one place but must sense, think, and act across a distributed system.”\nWind River’s 2026 roadmap focuses on infrastructure capable of:\nReal-time decision-making Deterministic latency Distributed AI inference Autonomous operational control This signals a transition from “connected systems” to autonomous systems operating at the edge.\n🚀 Technology Highlights at MWC 2026 # Wind River’s booth demonstrations emphasize the shift from centralized cloud computing to distributed, AI-ready edge platforms.\nAI-RAN Convergence # A live demo shows AI workloads and Radio Access Network (RAN) functions running on a single edge platform.\nBenefits include:\nReduced latency Lower hardware footprint Optimized resource utilization On-site data processing This architecture enables telecom operators to colocate AI inference with radio workloads, reducing dependency on centralized data centers.\nPhysical AI \u0026amp; Robotics # A robotic arm demonstration highlights sub-millisecond control loops, illustrating:\nDeterministic latency Ultra-fast feedback cycles Real-time motion precision This “embodied intelligence” use case is critical for industrial automation, smart manufacturing, and autonomous machinery.\nMassive Virtualization Migration # Wind River is showcasing its ability to migrate tens of thousands of telecom sites within weeks, marking one of the largest known VM transitions in the industry.\nThis demonstrates:\nCarrier-grade orchestration Large-scale automation Reduced downtime during transformation It reflects the telecom industry\u0026rsquo;s accelerating shift toward cloud-native network infrastructure.\n5G Connected Vehicles (C-V2X) # In collaboration demos, Wind River highlights C-V2X (Cellular Vehicle-to-Everything) integration.\nKey components:\nReal-time sensor fusion Edge AI decision engines 5G low-latency communication This architecture supports the evolution toward software-defined vehicles (SDVs) and autonomous driving ecosystems.\neLxr Pro Linux # Wind River introduces eLxr Pro Linux, a Debian-based enterprise distribution optimized for:\nEdge AI workloads Mission-critical applications Cloud-native orchestration Vendor-neutral deployment By avoiding vendor lock-in, Wind River appeals to telecom operators and regulated enterprises seeking long-term platform independence.\n🎤 Executive Sessions \u0026amp; Industry Dialogue # Wind River executives will lead two major discussions at MWC:\nSession Topic Time \u0026amp; Location Intelligent Edge: Convergence of AI, IoT, and 5G March 2, 4:30 PM — Hall 6 (Marconi Stage) AI-Driven Network Automation \u0026amp; Autonomous RAN March 3, 10:55 AM — Hall 8 (Theater 3, O-RAN Summit) These sessions focus on how AI transforms network automation from reactive management to predictive and autonomous orchestration.\n🛡️ Digital Sovereignty \u0026amp; the Sovereign Cloud # A major 2026 theme is Digital Sovereignty.\nWind River is presenting architectures that allow enterprises to:\nMaintain strict data residency Control operational boundaries Secure edge-to-core data pipelines Meet regulatory compliance requirements This is especially relevant for:\nTelecommunications Defense Healthcare Critical infrastructure Edge AI cannot scale globally without trust and control. Sovereign cloud frameworks provide that foundation.\n🧩 The Bigger Picture: Infrastructure for the IQ Era # Wind River’s presence at MWC 2026 reflects a broader shift:\nThe network is no longer just a transport layer—it is an intelligent compute fabric.\nSupporting:\nGPU-dense edge nodes Real-time AI inference Autonomous RAN Distributed orchestration In the emerging “IQ Era” of networking, infrastructure must do more than move packets. It must participate in decision-making.\nWind River is positioning itself at the center of that transformation.\nReference: Wind River Showcasing Edge AI for Intelligent Networks at MWC Barcelona\n","date":"2026-02-15","externalUrl":null,"permalink":"/news/wind-river-at-mwc-2026-advancing-edge-ai-and-autonomous-networks/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eWind River at MWC 2026: Powering the Future of Edge AI and Autonomous Networks\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eWind River, a subsidiary of Aptiv and a global leader in intelligent edge software, is set to showcase its latest Edge AI and autonomous infrastructure solutions at \u003cstrong\u003eMWC Barcelona 2026\u003c/strong\u003e (March 2–5).\u003c/p\u003e","title":"Wind River at MWC 2026: Advancing Edge AI and Autonomous Networks","type":"news"},{"content":" 🚁 Why Fast Booting Matters for UAV Flight Controllers # In unmanned aerial vehicles (UAVs), system reliability is inseparable from timing guarantees. A transient software fault, electromagnetic interference, or memory corruption can trigger a watchdog reset in the flight control computer. For medium-sized UAVs using single-redundancy architectures, recovery latency directly determines survivability.\nIf reboot time exceeds a few seconds, the aircraft may drift outside its controllable envelope before guidance logic resumes. While VxWorks is widely adopted for its deterministic scheduling and fault tolerance, its traditional multi-stage boot sequence can become a liability in airborne reset scenarios.\nA 2010 research study from Northwestern Polytechnical University proposed a fast-boot method that transforms reboot behavior from a liability into a recovery mechanism suitable for in-flight use.\n🧠 Standard VxWorks Boot Flow on x86 Platforms # On x86-based flight control computers using flash storage such as DiskOnChip (DOC), the VxWorks boot process is typically split into two distinct stages.\nConventional Two-Stage Boot # Bootrom Stage\nMinimal VxWorks image compiled from BSP sources Initializes CPU, memory controller, and basic devices Loads the full VxWorks kernel image from storage or network Kernel + Application Stage\nParses boot parameters (BOOT_LINE_ADRS) Initializes file systems and device drivers Starts the kernel and invokes user application entry points This design favors flexibility but introduces duplicated initialization and excessive I/O for time-critical systems.\n⏱️ Where the Time Is Lost # For DOC-based systems, boot latency typically accumulates from:\nFlash driver initialization (TrueFFS) File system mounting Secondary kernel image loading Repeated hardware probing In measured UAV deployments, these steps commonly result in 9–10 seconds of reboot time—far beyond acceptable limits for in-flight recovery.\n⚡ One-Step Fast Boot Architecture # The proposed optimization collapses the two-stage boot into a single, monolithic image containing:\nCPU and board initialization VxWorks kernel User flight-control applications Instead of loading a kernel from Bootrom, the system boots directly into the operational runtime.\n🧩 BSP-Level Implementation Details # 1. Integrating Applications into the Kernel Image # User applications are statically linked into the VxWorks image and initialized from usrAppInit().\n/* usrAppInit.c */ #include \u0026#34;vxWorks.h\u0026#34; #include \u0026#34;taskLib.h\u0026#34; #include \u0026#34;stdio.h\u0026#34; void flightControlTask (void) { while (1) { /* Core flight control loop */ printf(\u0026#34;Flight control running...\\n\u0026#34;); taskDelay(sysClkRateGet()); } } void usrAppInit (void) { taskSpawn( \u0026#34;tFlightCtrl\u0026#34;, 100, VX_FP_TASK, 8192, (FUNCPTR)flightControlTask, 0,0,0,0,0,0,0,0,0,0 ); } This eliminates the need to load applications after kernel startup.\n2. Building a ROM-Resident VxWorks Image # In the BSP or project configuration, the image is built as vxWorks_rom:\n# Makefile fragment VX_IMAGE_TYPE = vxWorks_rom This ensures the image is fully self-contained and directly executable from flash.\n3. Bootrom Replacement via Image Conversion # Instead of a minimal Bootrom, the full image is converted into Bootrom.sys:\nobjcopypentium vxWorks_rom \\ -O binary \\ Bootrom.sys Unlike a traditional Bootrom, this binary already includes:\nKernel Drivers Applications No secondary image loading is required.\n4. DiskOnChip Boot Configuration # DOC preparation follows standard tooling but becomes significantly simpler:\nFDISK /dev/doc0 DFORMAT /dev/doc0 vxsys Bootrom.sys The BIOS is configured to boot directly from DOC, bypassing unnecessary self-tests where possible.\n🚀 Eliminating DOC Driver Initialization # In a traditional setup, TrueFFS must be initialized during boot:\n/* Traditional approach */ #include \u0026#34;tffsDrv.h\u0026#34; STATUS usrTffsInit (void) { return tffsDrv(); } With the one-step fast boot approach, this entire path is removed, since no runtime access to DOC is required after boot.\n📉 Measured Performance Gains # The researchers validated the approach on a real UAV flight controller:\nPlatform: SBS PC/104 CPU: 486-class processor Storage: DiskOnChip 2000 Boot Time Comparison # Method Boot Time Traditional DOC Boot ≥ 9 s One-Step Fast Boot \u0026lt; 3 s This 3× reduction allows watchdog-triggered resets to occur during flight without loss of control.\n🛡️ Reliability Benefits in UAV Systems # Key advantages for airborne systems include:\nPredictable reboot latency Reduced software complexity Fewer failure points during recovery Improved watchdog effectiveness In practice, the reboot becomes a fault containment mechanism, not a catastrophic event.\n🔮 Broader Embedded-System Implications # While demonstrated on x86 UAV controllers, the same principles apply broadly:\nAerospace mission computers Robotics controllers Industrial real-time systems Any VxWorks-based system that prioritizes availability over flexibility can benefit from collapsing boot stages and integrating applications into the kernel image.\n","date":"2026-02-07","externalUrl":null,"permalink":"/bsp/fast-boot-techniques-for-vxworks-based-uav-flight-controllers/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003e🚁 Why Fast Booting Matters for UAV Flight Controllers \n    \u003cdiv id=\"-why-fast-booting-matters-for-uav-flight-controllers\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-why-fast-booting-matters-for-uav-flight-controllers\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn unmanned aerial vehicles (UAVs), system reliability is inseparable from timing guarantees. A transient software fault, electromagnetic interference, or memory corruption can trigger a watchdog reset in the flight control computer. For \u003cstrong\u003emedium-sized UAVs using single-redundancy architectures\u003c/strong\u003e, recovery latency directly determines survivability.\u003c/p\u003e","title":"Fast Boot Techniques for VxWorks-Based UAV Flight Controllers","type":"bsp"},{"content":"","date":"2026-02-04","externalUrl":null,"permalink":"/tags/airbus/","section":"Tags","summary":"","title":"Airbus","type":"tags"},{"content":" Airbus Certifies World\u0026rsquo;s First Automatic Air-to-Air Refueling System\nAirbus has reached a historic milestone in military aviation by achieving full certification for its Automatic Air-to-Air Refueling (A3R) system on the A330 Multi Role Tanker Transport (MRTT). The certification marks the first time an automated aerial refueling capability has been approved for operational use.\nThe certification was granted by the Spanish National Institute for Aerospace Technology (INTA) after a comprehensive qualification and flight-test campaign. The program was conducted in partnership with the Republic of Singapore Air Force (RSAF) and the Defence Science and Technology Agency (DSTA).\nThis breakthrough represents a major step toward autonomous aviation systems, improving safety, operational efficiency, and mission flexibility for modern air forces.\n✈️ A New Era of Automated Aerial Refueling # The A3R system is part of Airbus’s SMART MRTT vision, which focuses on enhancing tanker aircraft with advanced automation and digital capabilities.\nUsing computer vision and automated control algorithms, the system can:\nDetect and identify receiver aircraft Track the aircraft’s position during flight Automatically guide the refueling boom Execute fuel transfer operations All of these steps occur with minimal manual intervention from the boom operator.\nThe system supports both daytime and nighttime operations, significantly reducing operator workload while maintaining high levels of precision and safety during aerial refueling missions.\n🛫 Extensive Flight Testing and Certification # The certification program involved a rigorous series of flight tests and operational evaluations designed to validate the reliability and safety of the A3R system.\nKey elements of the testing campaign included:\nDay and night refueling operations Expanded flight envelope testing Compatibility with multiple receiver aircraft types Operational scenarios in different geographic environments Flight trials were conducted in both Spain and Singapore, demonstrating the system’s performance under a wide range of real-world conditions.\nDuring testing, the system successfully refueled several RSAF aircraft platforms, including:\nF-16 fighter jets F-15 fighter aircraft These tests confirmed the system’s ability to operate reliably with different aircraft profiles and flight characteristics.\n💻 Safety-Critical Software Powered by VxWorks 653 # At the core of the A3R system is the VxWorks 653 real-time operating system, which provides the certified software platform responsible for managing the system’s safety-critical functions.\nVxWorks 653 enables multiple applications to run simultaneously while maintaining strict isolation between safety-critical processes. The platform supports ARINC 653 partitioning, allowing software with different criticality levels to operate securely on the same hardware.\nThe system is certified to the highest safety assurance level:\nED-12C / DO-178C Design Assurance Level (DAL) A In addition, the certification addresses CAST-32A requirements for multicore processors. This achievement represents the first time such certification has been completed for airborne military equipment.\nBy meeting these rigorous standards, the platform ensures that the automated system can reliably:\nIdentify receiver aircraft shapes Detect refueling receptacles Control fuel delivery at high altitudes Maintain deterministic system behavior 🤝 International Collaboration Driving Innovation # The development of the A3R capability began in 2020 through a collaboration between Airbus, the RSAF, and Singapore’s DSTA.\nThe program aimed to accelerate innovation in automated aerial refueling while ensuring the technology met the operational needs of modern air forces.\nWith certification complete, RSAF’s 112 Squadron becomes the first military unit in the world to operationally deploy the A3R system on its A330 MRTT fleet.\nThis capability offers several strategic advantages:\nIncreased operational efficiency Reduced pilot and operator workload Improved refueling precision Extended mission range for combat aircraft 🌍 Leadership Perspectives # Airbus Defence and Space CEO Mike Schoellhorn highlighted the importance of the collaboration:\n\u0026ldquo;The certification of A3R with Singapore is a significant achievement and a clear demonstration of what long-term partnership can deliver. Singapore has consistently led the adoption and co-development of next-generation aerospace technologies.\u0026rdquo;\nNg Chad-son, Chief Executive of DSTA, emphasized the technical milestone:\n\u0026ldquo;Achieving full certification of A3R is a significant achievement as Singapore’s A330 MRTTs can now perform automatic refuelling both in daytime and at night.\u0026rdquo;\nMajor-General Kelvin Fan, Chief of Air Force for the RSAF, also underscored the operational benefits:\n\u0026ldquo;The RSAF is pleased to have partnered with DSTA and Airbus in pioneering the world’s first A3R capability. This development enhances our aerial refuelling operations and reflects our commitment to technological innovation.\u0026rdquo;\n🔧 The Future of Autonomous Aviation Systems # The certification of the A3R system demonstrates how automation is reshaping modern aviation systems.\nAutonomous capabilities such as automated refueling can:\nImprove mission safety Reduce crew workload Enable more complex multi-aircraft operations Increase operational efficiency in combat environments As air forces continue modernizing their fleets, technologies like the A330 MRTT’s A3R capability are expected to influence future tanker aircraft designs and potentially pave the way for further automation in military aviation.\nThis milestone represents not just a technical achievement but a preview of how automation, advanced avionics, and safety-critical software will shape the next generation of aerospace systems.\n","date":"2026-02-04","externalUrl":null,"permalink":"/industries/airbus-certifies-worlds-first-automatic-air-to-air-refueling-system/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eAirbus Certifies World\u0026rsquo;s First Automatic Air-to-Air Refueling System\u003c/p\u003e\u003c/blockquote\u003e\n\u003cscript async src=\"https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1543398821442998\"\n     crossorigin=\"anonymous\"\u003e\u003c/script\u003e\n\u003c!-- vxworks6_ads_1 --\u003e\n\u003cp\u003e\u003cins class=\"adsbygoogle\"\nstyle=\"display:block\"\ndata-ad-client=\"ca-pub-1543398821442998\"\ndata-ad-slot=\"7693617958\"\ndata-ad-format=\"auto\"\ndata-full-width-responsive=\"true\"\u003e\u003c/ins\u003e\u003c/p\u003e\n\u003cscript\u003e\n     (adsbygoogle = window.adsbygoogle || []).push({});\n\u003c/script\u003e\n\u003cp\u003eAirbus has reached a historic milestone in military aviation by achieving full certification for its \u003cstrong\u003eAutomatic Air-to-Air Refueling (A3R)\u003c/strong\u003e system on the A330 Multi Role Tanker Transport (MRTT). The certification marks the first time an automated aerial refueling capability has been approved for operational use.\u003c/p\u003e","title":"Airbus Certifies World's First Automatic Air-to-Air Refueling System","type":"industries"},{"content":"","date":"2026-02-04","externalUrl":null,"permalink":"/tags/automation/","section":"Tags","summary":"","title":"Automation","type":"tags"},{"content":"","date":"2026-02-04","externalUrl":null,"permalink":"/tags/defense-technology/","section":"Tags","summary":"","title":"Defense Technology","type":"tags"},{"content":"","date":"2026-02-01","externalUrl":null,"permalink":"/tags/fault-tolerance/","section":"Tags","summary":"","title":"Fault Tolerance","type":"tags"},{"content":" Stateful Recovery on VxWorks 7 RTPs: Checkpointing, Certification, and Partition-Aware Design\nIn safety-critical embedded systems, restart is easy.\nRecovery is hard.\nVxWorks 7 fundamentally improved robustness with Real-Time Processes (RTPs), MMU isolation, and certification-ready kernels. Yet one gap remains unchanged since VxWorks 6:\nWhen an RTP restarts, all application state is lost.\nThis article revisits a legacy VxWorks checkpointing and task recovery mechanism and performs a full, explicit redesign for VxWorks 7 RTP-based systems, extending it with:\nCertification arguments (DO-178C / IEC 61508) A concrete middleware architecture A direct comparison with ARINC 653 partition restart semantics The goal is not theory, but deployable, auditable recovery.\n🧠 Why RTP Restart Is Not Enough # VxWorks 7 RTPs provide:\nAddress-space isolation Fault containment Deterministic restart But the restart model is stateless.\nFailure Event Native VxWorks 7 Outcome Task exception Task terminated RTP fault RTP restarted Application state Lost Control continuity Broken For flight control, power systems, robotics, or long-running edge AI pipelines, this is often unacceptable.\nThe legacy VxWorks checkpointing design fills this gap by introducing task-level state persistence, without kernel modification.\n🧩 Overall Architecture: RTP-Scoped Self-Recovery # The redesigned system embeds the checkpoint mechanism inside each RTP.\n+------------------------------------------------+ | RTP | | | | +------------------+ | | | Application | | | | Tasks | | | +------------------+ | | | | +------------------+ | | | Checkpoint | | | | Middleware | | | | - Memory registry| | | | - Object pools | | | | - Recovery FSM | | | +------------------+ | | | +------------------------------------------------+ | VxWorks 7 Kernel (MMU, Scheduler, Health Mon.) | +------------------------------------------------+ This creates a stateful RTP:\nTasks can fail and resume RTPs can restart and restore Kernel remains untouched 🧱 Checkpoint Content (RTP-Aware) # The original five checkpoint categories remain intact, but are reinterpreted under RTP ownership rules.\n1. Task Control Blocks (TCB) # Tasks still use WIND_TCB, but:\nIDs are RTP-local Kernel queue pointers are invalid after restart Checkpoint Strategy\nStore logical task state only Reset kernel-managed fields Normalize restored tasks to READY Restore flow:\ntaskInitExcStk(tcb, entry, stackBase, stackSize); taskActivate(taskId); This avoids undefined kernel references while preserving execution context.\n2. Execution and Exception Stacks # In VxWorks 7:\nRTP stacks are MMU-protected Addresses are deterministic per RTP instance Stacks are:\nAllocated from RTP memory pools Copied to persistent storage at checkpoint Restored before task activation This works cleanly on both 32-bit and 64-bit RTPs.\n3. Global and Dynamic Memory # RTP ownership simplifies checkpointing.\nGlobal Variables # Explicitly registered:\naddGlobalVar(\u0026amp;systemState, sizeof(systemState)); Dynamic Memory # Wrapped allocator (unchanged from 2013):\nvoid* myMalloc(size_t size) { void* p = alloc(size + 4); *(int*)p = size; return (char*)p + 4; } On restore, memory is rebuilt identically inside the RTP.\n4. Kernel Objects (Semaphores, Queues) # Object pools are mandatory in RTP systems.\nPre-allocation at RTP startup # SEM_ID semPool[MAX_SEM]; for (int i = 0; i \u0026lt; MAX_SEM; i++) semPool[i] = semBCreate(SEM_Q_FIFO, SEM_EMPTY); Checkpoint stores:\nLogical state (empty/full) Queue depth Ownership relationships Restore replays state, not creation.\n5. Files and Devices # RTPs isolate file descriptor tables.\nCheckpoint records:\nPath Flags Offset Restore logic:\nfd = open(path, flags); lseek(fd, offset, SEEK_SET); Devices remain kernel-resident; RTP only replays configuration.\n🛠️ Middleware Design (Concrete Layout) # A minimal, auditable middleware layout:\ncheckpoint/ ├── ckpt_core.c # checkpoint FSM ├── ckpt_mem.c # memory registry ├── ckpt_task.c # task snapshot/restore ├── ckpt_ipc.c # sem/msgQ pools ├── ckpt_file.c # fd replay ├── ckpt_storage.c # Flash/NVRAM backend ├── ckpt_api.h └── ckpt_config.h Key APIs # ckptInit(); ckptRegisterTask(taskId); ckptRegisterGlobal(void* addr, size_t size); ckptCheckpointNow(); ckptRestore(); No kernel hooks. No private symbols. Certification-friendly.\n⏱️ Checkpoint Timing and Health Monitoring # Checkpointing is cooperative.\nSafe points:\nControl-loop boundaries After IPC receive State machine transitions In VxWorks 7:\nHealth Monitor detects anomaly Middleware decides rollback vs restart Deterministic recovery path 📜 Certification Alignment # DO-178C (Avionics) # DO-178C Objective Mapping Determinism Explicit checkpoint points Error containment RTP isolation No unintended functionality No kernel modification Verification Simics + replayable recovery Supports Levels B–A when combined with partitioning.\nIEC 61508 (Industrial Safety) # IEC 61508 Concept Mapping Fault detection Health monitor + exceptions Fault reaction Task rollback Safe state Checkpoint-defined Diagnostic coverage Explicit state capture Middleware qualifies as application-level safety mechanism.\n🆚 RTP Checkpointing vs ARINC 653 Partition Restart # Aspect ARINC 653 RTP + Checkpoint Recovery unit Partition Task Restart type Cold Stateful State retention None Full Flexibility Low High Certification Strong Strong (with argument) Key Insight: ARINC 653 guarantees isolation. RTP checkpointing guarantees continuity.\nThey are complementary—not competing.\n🧪 Validation and Tooling # Original PowerPC prototype: ms-level recovery\nVxWorks 7 adds:\nMMU safety RTP restart hooks Simics full-system checkpoints Simics checkpoints validate runtime checkpoint correctness under controlled fault injection.\n⚠️ Known Constraints (Engineering Reality) # No transparent socket rollback No ISR rollback Cooperative checkpointing required Runtime overhead ~10–20% All constraints are explicit, documentable, and certifiable.\n🏁 Final Takeaway # VxWorks 7 gave us isolation. The legal VxWorks design gave us memory of the past.\nCombined, they enable something rare in embedded systems:\nA system that fails, heals, and continues — without forgetting who it was.\nThis is not a workaround. This is stateful resilience by design.\nIf your system must survive faults without losing its mission, this architecture is no longer optional — it’s inevitable.\n","date":"2026-02-01","externalUrl":null,"permalink":"/bsp/stateful-recovery-on-vxworks-7-rtps-checkpointing-certification-and-partition-aware-design/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eStateful Recovery on VxWorks 7 RTPs: Checkpointing, Certification, and Partition-Aware Design\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eIn safety-critical embedded systems, \u003cstrong\u003erestart is easy\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRecovery is hard.\u003c/strong\u003e\u003c/p\u003e","title":"Stateful Recovery on VxWorks 7 RTPs: Checkpointing, Certification, and Partition-Aware Design","type":"bsp"},{"content":" Designing a High-Reliability VxWorks BSP: From Reset Vector to VxBus\nBoard Support Packages (BSPs) are where embedded systems stop being theoretical and start being real. They are also where most RTOS projects fail quietly—booting once, hanging mysteriously, or passing tests until the first field deployment.\nThis article is a long-form, end-to-end technical deep dive into designing a high-reliability BSP for VxWorks, blending modern VxWorks 7 practices with hard-earned lessons from legacy systems. While silicon generations change, BSP failure modes rarely do.\nIf you’ve ever stared at a dead serial console wondering “Did the CPU even fetch the first instruction?”—this one’s for you.\n🧩 Why BSPs Still Matter (More Than Ever) # A BSP is not “just glue code.” It is the contract between the operating system and reality.\nIn safety-critical domains—aviation, space, industrial control—VxWorks remains dominant because it offers:\nDeterministic scheduling Proven certification artifacts Long-term ABI and architectural stability But VxWorks does not abstract hardware for you automatically. That burden falls squarely on the BSP.\nA BSP must:\nBring hardware from reset to multitasking Describe memory accurately Initialize clocks, timers, and interrupts in the right order Present hardware cleanly to drivers and applications Get it wrong, and no amount of application-layer brilliance will save you.\n🧱 BSP Fundamentals: What a BSP Really Owns # At its core, a BSP is responsible for four things:\nBootstrapping the CPU Describing memory and cache behavior Initializing core platform devices Providing a stable hardware abstraction Modern VxWorks (7.x) has added Device Tree and VxBus, but the BSP’s philosophical role hasn’t changed since VxWorks 5.x.\nA useful mental model:\nLayer Responsibility BSP Hardware truth Drivers Device behavior Kernel Scheduling \u0026amp; IPC Apps Business logic When BSPs fail, it’s almost always because hardware truth was assumed, not verified.\n🔌 Boot Flow: From Reset Vector to Kernel # Understanding the boot sequence is mandatory BSP literacy.\nPhase 1: romInit — Assembly Reality Check # This is the first instruction executed after reset.\nResponsibilities:\nDisable interrupts Initialize minimal CPU state Set up a temporary stack Transition CPU modes (if needed) Jump to romStart Key properties:\nPosition-independent No global variables No assumptions about RAM War story:\nMany BSPs fail because someone added a C call too early. If RAM isn’t proven usable yet, even saving registers can kill you.\nPhase 2: romStart — Controlled Relocation # Now we’re in C, but still fragile.\nResponsibilities:\nCopy data sections Zero BSS Optionally decompress images Initialize RAM regions Call usrInit Almost everything here is controlled by configuration macros. Resist the urge to “optimize” this path.\nRule: If Wind River already solved it, don’t rewrite it.\nPhase 3: usrInit — Birth of the Kernel # This is where the system becomes alive.\nResponsibilities:\nInitialize kernel objects Set up interrupts and timers Start multitasking Launch root tasks Once usrRoot() runs, BSP mistakes become Heisenbugs—harder to reproduce, harder to debug.\n🧠 Memory Bring-Up \u0026amp; MMU Configuration # This is where most BSPs die slowly.\nPhysical Memory Description # VxWorks relies on accurate physical memory descriptors:\nPHYS_MEM_DESC sysPhysMemDesc[]; Each entry defines:\nAddress range Cacheability Access permissions DMA suitability Common mistakes:\nMarking device memory as cacheable Forgetting DMA-safe regions Overlapping descriptors Reality: 90% of “random crashes” are cache coherency bugs wearing disguises.\nMMU \u0026amp; Cache Policy # You must clearly separate:\nNormal RAM Device registers Shared buffers Boot ROM / Flash One incorrect cache attribute can:\nBreak DMA Corrupt descriptors Stall peripherals High-reliability BSPs always:\nUse explicit, conservative mappings Document why each region exists ⏱️ Interrupts, Timers, and Early Console # Interrupt Initialization Order Matters # Correct order:\nInterrupt controller Vector table CPU enable Timer start Enable interrupts too early, and you’ll take exceptions before handlers exist.\nEarly Console: Your Lifeline # A serial console before full driver init is invaluable.\nCommon techniques:\nPolled UART Minimal register writes No interrupts No buffers War story: A single early printf() has saved more BSPs than any debugger.\n🌳 Device Tree \u0026amp; VxBus (VxWorks 7 Era) # VxWorks 7 embraced Device Tree not as a Linux clone, but as a hardware declaration language.\nBSP vs Device Tree Responsibilities # Component Owns BSP CPU, memory, clocks DTS Device topology VxBus Driver matching Device Tree should describe:\nAddress ranges Interrupts Clocks Compatibility strings BSP code should not hardcode device details.\nVxBus Driver Lifecycle # Bus enumeration Driver match (compatible) Probe Attach Publish services Clean BSPs allow drivers to remain board-agnostic.\n🔧 Hardware Abstraction \u0026amp; Driver Binding # Good BSPs enable polymorphism at the hardware level.\nTechniques:\nStandardized driver APIs Capability flags Device Tree parameters Late binding via VxBus This is how one OS image supports multiple boards.\n🧪 Debugging the Impossible: Real BSP War Stories # Mode Switching Traps # Switching CPU modes (real → protected, EL3 → EL1) invalidates assumptions instantly.\nSolution patterns:\nHooks after transition Manual debugger relocation Known-good stack placement Vector Tables \u0026amp; RAM Clearing Disasters # Problem:\nEarly RAM clearing wipes interrupt tables Fix:\nReserve vector memory explicitly Protect it from zeroing Stack Relocation Hacks # If RAM isn’t stable:\nPlace stack in ROM shadow Pre-clear memory manually Transition later Ugly? Yes. Necessary? Often.\nEmulator vs Hardware Lies # Emulators:\nMask bus timing issues Ignore signal integrity problems Hide power sequencing bugs Always validate on real silicon.\n🧭 Legacy BSPs vs VxWorks 7 BSPs # What changed:\nDevice Tree VxBus SMP awareness What didn’t:\nBoot fragility Memory truthfulness Ordering constraints Understanding legacy BSPs makes you better at modern ones.\n🏁 Conclusion: BSPs That Survive Time # A BSP is infrastructure, not a feature.\nHigh-reliability BSPs:\nFavor correctness over cleverness Document assumptions Fail loudly Respect hardware reality VxWorks continues to power spacecraft, industrial controllers, and safety systems because engineers still take BSPs seriously.\nIf applications are the brain, BSPs are the nervous system. And nobody wants unreliable nerves.\n","date":"2026-01-31","externalUrl":null,"permalink":"/bsp/designing-a-high-reliability-vxworks-bsp-from-reset-vector-to-vxbus/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eDesigning a High-Reliability \u003ca href=\"https://www.vxworks6.com/bsp/\" target=\"_blank\"\u003eVxWorks BSP\u003c/a\u003e: From Reset Vector to VxBus\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eBoard Support Packages (BSPs) are where embedded systems stop being theoretical and start being real. They are also where most RTOS projects fail quietly—booting once, hanging mysteriously, or passing tests until the first field deployment.\u003c/p\u003e","title":"Designing a High-Reliability VxWorks BSP: From Reset Vector to VxBus","type":"bsp"},{"content":" Multi-Task-Based Network Communication under the VxWorks Real-Time Operating System\nAbstract # This paper presents a practical approach to implementing network communication under the VxWorks real-time operating system. It first introduces the multi-task programming model provided by VxWorks, followed by an overview of BSD Socket–based client–server communication. Based on these foundations, a multi-task server architecture is proposed, and representative C-language code examples are provided to illustrate task creation, socket initialization, and inter-task coordination in real-time embedded environments.\n🚀 Introduction # With the widespread adoption of high-performance embedded processors, embedded operating systems have become essential in communications, defense systems, industrial control, and medical equipment. VxWorks, as one of the most mature and widely deployed real-time operating systems, integrates a full TCP/IP protocol stack and provides strong support for multitasking and real-time scheduling.\nBy combining VxWorks multitasking mechanisms with BSD Socket programming, developers can implement reliable network communication between embedded targets and external systems such as PCs or workstations. This not only enables real-time data exchange but also improves system configurability, remote debugging, and runtime monitoring capabilities.\n🌐 Task Management and Socket Programming in VxWorks # VxWorks uses a priority-based preemptive scheduling model. Each task is identified by a task ID and assigned a priority between 0 (highest) and 255 (lowest). Tasks with higher priority can preempt lower-priority tasks at any time.\nTo allow fair execution among tasks with equal priority, round-robin scheduling can be enabled during system initialization:\nkernelTimeSlice(10); /* Enable time slicing (ticks) */ Task Creation Example # Tasks are typically created using taskSpawn(), which both creates and starts a task:\nint serverTaskId; serverTaskId = taskSpawn( \u0026#34;tServer\u0026#34;, 100, /* priority */ VX_FP_TASK, /* options */ 8192, /* stack size */ (FUNCPTR)serverMain, /* entry point */ 0,0,0,0,0,0,0,0,0,0 ); This model allows each functional component—such as connection handling or data processing—to execute independently.\nBSD Socket Support # VxWorks provides full support for BSD Sockets. The programming model closely follows standard UNIX socket APIs, making it easy to port existing network code to VxWorks.\n📐 Multi-Task Server Architecture # A multi-task server implementation is well suited to VxWorks due to its real-time scheduling and task isolation. In the proposed design, the server is decomposed into multiple cooperating tasks, including:\nInitialization task Connection acceptance task Message sending task Message receiving task Network monitoring task Each task has a clear responsibility, reducing complexity and improving system reliability.\n🧮 Server-Side Implementation with Code Examples # Initialization and Listening Socket # The initialization task creates a listening socket and spawns the connection acceptance task.\n#define SERVER_PORT 5000 int listenSock; void initTask(void) { struct sockaddr_in serverAddr; listenSock = socket(AF_INET, SOCK_STREAM, 0); if (listenSock \u0026lt; 0) { perror(\u0026#34;socket\u0026#34;); return; } memset(\u0026amp;serverAddr, 0, sizeof(serverAddr)); serverAddr.sin_family = AF_INET; serverAddr.sin_port = htons(SERVER_PORT); serverAddr.sin_addr.s_addr = INADDR_ANY; if (bind(listenSock, (struct sockaddr *)\u0026amp;serverAddr, sizeof(serverAddr)) \u0026lt; 0) { perror(\u0026#34;bind\u0026#34;); close(listenSock); return; } listen(listenSock, 5); taskSpawn(\u0026#34;tAccept\u0026#34;, 90, 0, 8192, (FUNCPTR)acceptTask, 0,0,0,0,0,0,0,0,0,0); taskDelete(0); /* Initialization task exits */ } Connection Acceptance Task # The acceptance task waits for incoming connections and spawns communication tasks for each client.\nvoid acceptTask(void) { int clientSock; struct sockaddr_in clientAddr; int addrLen = sizeof(clientAddr); while (1) { clientSock = accept(listenSock, (struct sockaddr *)\u0026amp;clientAddr, \u0026amp;addrLen); if (clientSock \u0026lt; 0) continue; taskSpawn(\u0026#34;tRecv\u0026#34;, 80, 0, 8192, (FUNCPTR)recvTask, clientSock,0,0,0,0,0,0,0,0,0); taskSpawn(\u0026#34;tSend\u0026#34;, 85, 0, 8192, (FUNCPTR)sendTask, clientSock,0,0,0,0,0,0,0,0,0); } } Message Receiving Task # The receiving task continuously reads data from the socket and processes client messages.\nvoid recvTask(int sock) { char buf[256]; int n; while ((n = recv(sock, buf, sizeof(buf) - 1, 0)) \u0026gt; 0) { buf[n] = \u0026#39;\\0\u0026#39;; printf(\u0026#34;Received: %s\\n\u0026#34;, buf); if (strcmp(buf, \u0026#34;quit\u0026#34;) == 0) break; } close(sock); taskDelete(0); } Message Sending Task # The sending task reads keyboard input and transmits it to the client.\nvoid sendTask(int sock) { char buf[256]; while (1) { if (fgets(buf, sizeof(buf), stdin) == NULL) continue; send(sock, buf, strlen(buf), 0); if (strncmp(buf, \u0026#34;quit\u0026#34;, 4) == 0) break; } taskDelete(0); } Network Monitoring and Cleanup # In a complete system, an additional monitoring task supervises task termination, socket closure, and error recovery. This task ensures that system resources are released correctly and that the server can safely return to a listening state after a client disconnects.\n🔮 Conclusion # This paper demonstrated how multi-task programming and BSD Socket communication can be combined under VxWorks to implement a robust network server. By decomposing functionality into independent tasks and using standard socket APIs, the system achieves high real-time responsiveness, improved modularity, and easier maintenance. The provided code examples illustrate a practical foundation for developing networked embedded applications based on VxWorks.\n","date":"2026-01-26","externalUrl":null,"permalink":"/app/multi-task-based-network-communication-under-the-vxworks-rtos/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eMulti-Task-Based Network Communication under the VxWorks Real-Time Operating System\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eAbstract \n    \u003cdiv id=\"abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThis paper presents a practical approach to implementing network communication under the VxWorks real-time operating system. It first introduces the multi-task programming model provided by VxWorks, followed by an overview of BSD Socket–based client–server communication. Based on these foundations, a multi-task server architecture is proposed, and representative C-language code examples are provided to illustrate task creation, socket initialization, and inter-task coordination in real-time embedded environments.\u003c/p\u003e","title":"Multi-Task-Based Network Communication under the VxWorks Real-Time Operating System","type":"app"},{"content":" Application of the Embedded Real-Time Operating System VxWorks in Inertial Navigation Systems\nAbstract # This paper presents an analysis of the performance characteristics of the embedded real-time operating system VxWorks and its application in inertial navigation systems (INS). The development process based on VxWorks is described, along with practical application examples in navigation interface machines. The necessity and feasibility of transitioning existing INS software from assembly language to operating-system-supported high-level languages are discussed. This transition significantly improves software maintainability, testability, and reliability while fully utilizing the processing capabilities of modern navigation computers to meet increasingly complex navigation computation requirements.\n1. Introduction # An inertial navigation system (INS) is a real-time control system that integrates sensitive signal acquisition, platform control, navigation computation, human–machine interaction, and data transmission. It provides critical navigation information such as heading, attitude, and position for maritime and aerospace platforms. At the core of an INS is an embedded computer system responsible for data acquisition, filtering, control loop execution, navigation parameter computation, and system interaction.\nIn many legacy INS designs, embedded computers are based on Intel 80486 (PC/104) processors, with application software developed directly on the hardware using 8086 assembly language. Debugging and control are typically performed using monitor programs such as the Intel 957B. In such designs, management of memory, peripherals, and interrupts is tightly coupled with application logic, resulting in excessive software complexity.\nAlthough assembly language offers high execution efficiency and precise hardware control, it has several inherent disadvantages. Poor readability and limited portability make long-term maintenance, modification, and system upgrades difficult. Moreover, modern PC/104 platforms are 32-bit processors capable of real-time multitasking and concurrent execution. Relying solely on manually implemented control programs makes it difficult to exploit these capabilities, leading to inefficient resource utilization and reduced system reliability. Additionally, outdated debugging and testing methods for assembly-language software significantly increase maintenance effort and require prolonged operational testing to verify correctness and stability. As new peripheral devices and highly integrated components emerge, many of which are supported by vendor-supplied drivers, traditional development methods are no longer sufficient.\nTo address these issues, it is necessary to introduce an embedded real-time operating system (RTOS) into INS software development. An RTOS abstracts and manages system resources such as CPU scheduling, memory, peripherals, interrupts, and communication interfaces, allowing developers to focus on application logic. Acting as the core of the software stack, the operating system provides a stable runtime platform for application software.\nReal-time multitasking operating systems form the foundation of modern embedded systems. They encapsulate hardware resources and provide standardized APIs, allocating CPU time deterministically according to task priorities. VxWorks, a widely used embedded real-time multitasking operating system, is designed to be processor-independent, highly configurable, and tightly integrated with application software to form compact and reliable real-time systems.\nVxWorks is accompanied by the Tornado integrated development environment, which supports C and C++ development and provides powerful tools such as cross-compilers, simulators, target debuggers, performance analysis utilities, and software testing tools. Using Tornado, VxWorks-based application software has been successfully developed for multiple INS interface machines, establishing a solid foundation for migrating existing INS software from assembly language to high-level, OS-supported development.\n2. Advantages of VxWorks Compared with Bare-Metal INS Control Programs # VxWorks, developed by Wind River Systems, has been widely deployed since its introduction in 1983 and is well known for its successful use in military, aerospace, and other mission-critical real-time control systems.\n2.1 High-Reliability Real-Time Performance # One of the most critical requirements for INS computers is reliable real-time performance. In traditional INS control programs, a fixed control cycle—typically 0.1 seconds—is used. Pulse increments from horizontal accelerometers are read at each cycle, and torquing signals are computed based on data from the previous cycle. This introduces an inherent delay, as control outputs always lag behind the most recent sensor data, which conflicts with strict real-time control requirements.\nVxWorks effectively addresses this issue through its multitasking and interrupt-driven execution model. Its high-performance microkernel, Wind, provides priority-based preemptive scheduling, interrupt management, inter-task synchronization, inter-process communication, watchdog timers, and memory management. Real-time applications can be decomposed into independent tasks, each with its own execution context and stack, enabling concurrent processing of sensor input, control computation, and output generation.\nThe Wind kernel minimizes interrupt latency and context-switch overhead by combining priority-based scheduling with interrupt-driven execution. Tasks can be dynamically created, suspended, resumed, delayed, or deleted, and their priorities can be adjusted at runtime. Synchronization mechanisms such as semaphores, along with communication mechanisms including message queues, pipes, and sockets, allow precise coordination between tasks.\n2.2 Flexible Debugging and Efficient Software Testing # Developing INS control software in assembly language offers limited debugging capabilities. Typically, software self-tests are performed first, followed by hardware–software joint debugging using emulators or monitor programs. Fault localization often relies on manual code tracing, which is inefficient and time-consuming.\nVxWorks provides a far more flexible debugging environment. Using Tornado, application software is developed on a host system and cross-compiled into executable images for the target platform. Debugging can be performed using simulators or through remote connections to the target via Ethernet or serial interfaces. Performance analysis tools such as WindView enable developers to observe task execution, context switching, and CPU utilization in real time.\nSoftware testing is also significantly improved through the availability of coverage analysis and profiling tools, which help identify untested code paths and performance bottlenecks. These tools contribute to higher software quality and reduced validation effort.\n3. Development Process Based on VxWorks # 3.1 Hardware Configuration # The INS navigation interface machine is built on a PC/104 modular architecture, including CPU, input/output, and communication modules. A VxWorks Board Support Package (BSP) is customized to support the specific PC/104 hardware configuration, including device drivers and boot configuration.\n3.2 Software Development Workflow # The typical VxWorks-based development process includes the following steps:\nInstall the Tornado development environment on the host system. Configure and customize the BSP for the target hardware platform. Develop application software in C or C++, using VxWorks APIs for task management, synchronization, and communication. Compile and link the application with the VxWorks kernel to generate a bootable system image. Download the image to the target system using a bootloader. Perform debugging, testing, and performance analysis. 4. Application Example in a Navigation Interface Machine # In the navigation interface machine, VxWorks manages multiple real-time tasks responsible for data acquisition, navigation computation, control output, and system monitoring. Tasks are assigned priorities according to real-time requirements: the highest priority for control and sensor processing, medium priority for navigation computation, and lower priority for monitoring and diagnostic functions.\nInter-task communication is implemented using message queues to ensure deterministic data exchange. Interrupt service routines handle sensor data acquisition promptly, minimizing latency between measurement and control output.\nThis task-based architecture eliminates the delays inherent in traditional cyclic control schemes and achieves true real-time performance in torquing signal output.\n5. Conclusion # Introducing VxWorks into INS software development clearly separates system resource management from application logic, enabling the use of high-level programming languages and significantly improving software maintainability, portability, and reliability. By fully leveraging the multitasking and real-time capabilities of modern 32-bit processors, VxWorks-based INS software meets the demands of increasingly complex navigation computations. Successful application in navigation interface machines demonstrates the feasibility and effectiveness of this approach and provides a practical path for upgrading legacy INS software systems.\n","date":"2026-01-26","externalUrl":null,"permalink":"/app/application-of-the-vxworks-rtos-in-inertial-navigation-systems/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eApplication of the Embedded Real-Time Operating System VxWorks in Inertial Navigation Systems\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eAbstract \n    \u003cdiv id=\"abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThis paper presents an analysis of the performance characteristics of the embedded real-time operating system VxWorks and its application in inertial navigation systems (INS). The development process based on VxWorks is described, along with practical application examples in navigation interface machines. The necessity and feasibility of transitioning existing INS software from assembly language to operating-system-supported high-level languages are discussed. This transition significantly improves software maintainability, testability, and reliability while fully utilizing the processing capabilities of modern navigation computers to meet increasingly complex navigation computation requirements.\u003c/p\u003e","title":"Application of the VxWorks Embedded Real-Time Operating System in Inertial Navigation Systems","type":"app"},{"content":"","date":"2026-01-26","externalUrl":null,"permalink":"/tags/inertial-navigation/","section":"Tags","summary":"","title":"Inertial Navigation","type":"tags"},{"content":"","date":"2026-01-25","externalUrl":null,"permalink":"/tags/cloud-platform/","section":"Tags","summary":"","title":"Cloud Platform","type":"tags"},{"content":"","date":"2026-01-25","externalUrl":null,"permalink":"/tags/kubernetes/","section":"Tags","summary":"","title":"Kubernetes","type":"tags"},{"content":"","date":"2026-01-25","externalUrl":null,"permalink":"/tags/vmware-migration/","section":"Tags","summary":"","title":"VMware Migration","type":"tags"},{"content":" As cloud and virtualization costs rise—driven by licensing models, operational overhead, and vendor lock-in—many enterprises are actively seeking open, flexible alternatives.\nThis overview outlines how virtual machines (VMs) and containers can be migrated from VMware vSphere to Wind River® Cloud Platform, an integrated solution built on OpenStack and Kubernetes. The migration approach is designed to minimize disruption while accelerating time to value, enabling enterprises to modernize infrastructure without sacrificing operational continuity.\nThe platform supports both cold migrations, performed during planned maintenance windows, and warm migrations, where workloads remain active during transition. This flexibility allows customers to align migration strategy with business and operational requirements. Wind River has supported VM and container migrations across some of the most complex cloud environments globally, leveraging automation to streamline the transition from VMware-based infrastructure.\n🚀 Migration Overview # Wind River Cloud Platform simplifies workload migration through a set of integrated capabilities:\nCentralized management\nA unified operational view for migrating both VMs and containers from VMware environments.\nCustomer-operated migration\nAutomation-driven tooling combined with optional Wind River support services, training, and migration expertise.\nBlueprint-based automation\nPredefined blueprints standardize deployment, scaling, and lifecycle management.\nDedicated management clusters\nEnables Cloud Platform to operate alongside VMware and other clusters during phased transitions.\nBulk migration support\nWorkloads can be migrated manually or through scheduled automation.\nEnd-to-end lifecycle management\nMaintains continuity for backup and restore, provisioning, change management, scaling, patching, and upgrades before and after migration.\n🧭 Migration Methodologies # Wind River Professional Services delivers end-to-end migration programs tailored to customer environments. While each migration scenario is unique, most follow a common set of phases supported by Cloud Platform tools and automation to ensure predictable outcomes and reduced risk.\n🛠️ Migration Process # A typical migration from VMware vSphere to Wind River Cloud Platform follows a structured, phased approach:\nPhase 1: Discovery # Wind River and customer stakeholders assess the existing VMware environment to identify migration priorities and constraints.\nKey activities include:\nInventorying VMware infrastructure and prioritizing workloads Mapping VM dependencies and critical services Identifying existing workflows, scripts, blueprints, and operational policies Phase 2: Proof of Value # Using insights from discovery, Wind River evaluates the technical and economic benefits of migration.\nKey activities include:\nDefining migration schedules, maintenance windows, and KPIs Identifying how Cloud Platform capabilities, including Wind River Conductor, will automate migration Developing ROI, TCO, and time-to-value assessments Identifying risks and mitigation strategies to ensure business continuity Phase 3: Migration Proposal # Upon validation of value, Wind River delivers a formal migration proposal.\nKey activities include:\nDefining migration strategy and execution approach Specifying products, services, tools, and training Establishing timelines, SLAs, and customer acceptance criteria Phase 4: Planning and Design # With proposal approval, detailed technical and operational planning begins.\nKey activities include:\nDeveloping a detailed project plan and governance model Defining roles and responsibilities Finalizing architecture, design, and test plans Delivering customer training and knowledge transfer Phase 5: Implementation and Deployment # Migration execution begins with controlled validation and scales to full production.\nKey activities include:\nAchieving deployment and operational readiness Performing pilot migrations using noncritical workloads Automating workflows to accelerate large-scale migration Executing full production migration and validation Providing ongoing support under defined SLAs Decommissioning VMware infrastructure At the completion of this phase, customers are fully operational on Wind River Cloud Platform.\n☁️ Cloud Platform Migration Support # Simplified workload mobility\nMove workloads across on-premises, cloud, edge, and hybrid environments with minimal downtime.\nHybrid and multi-cloud support\nEnable portability across diverse infrastructure providers.\nScalable architecture\nSupport deployments ranging from single-site environments to globally distributed clouds.\nRisk reduction\nMinimize downtime, data loss, and performance degradation during migration.\n💼 Benefits of Workload Migration # Cost optimization\nReduce licensing and operational expenses compared to proprietary virtualization platforms.\nFreedom from vendor lock-in\nAdopt open technologies such as OpenStack and Kubernetes, supported by a broad ecosystem.\nInfrastructure modernization\nLower technical debt while improving security, scalability, and upgradeability.\n🏆 Why Wind River # Decades of experience in mission-critical systems Proven cloud platforms deployed in demanding environments Demonstrated success in large-scale VMware migrations Leadership in open-source technologies Award-winning customer support and professional services Reference: WIND RIVER CLOUD PLATFORM: VMware Workload Migration Overview\n","date":"2026-01-25","externalUrl":null,"permalink":"/industries/wind-river-cloud-platform-vmware-workload-migration-overview/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eAs cloud and virtualization costs rise—driven by licensing models, operational overhead, and vendor lock-in—many enterprises are actively seeking open, flexible alternatives.\u003c/p\u003e","title":"Wind River Cloud Platform VMware Workload Migration Overview","type":"industries"},{"content":" Implementation of IEC 61850 Fast Message Transmission Services in VxWorks\n📘 Abstract # Sampled Values (SV) and Generic Object-Oriented Substation Events (GOOSE) are the two communication services with the most stringent real-time requirements in the IEC 61850 standard. These services—collectively referred to as fast message transmission services (FMTS)—bypass the conventional TCP/IP protocol stack and map directly from the application or presentation layer to the data link layer.\nSince the default VxWorks communication model is socket-based and built on TCP/IP, it does not natively support this direct mapping. To address this limitation, this paper analyzes the Abstract Communication Service Interface (ACSI) and the Specific Communication Service Mapping (SCSM) for FMTS and proposes a VxWorks-based implementation strategy. A fast communication interface (FCI), dedicated application tasks, and real-time processing mechanisms are designed to support FMTS. Finally, a test environment is constructed to verify both the correctness and real-time performance of the GOOSE implementation.\nKeywords: IEC 61850, VxWorks, sampled values, GOOSE, real-time performance\n🧭 Introduction # VxWorks is a commercial embedded real-time operating system (RTOS) developed by Wind River Systems. It is characterized by low interrupt latency, fast task context switching, scalable components, and a priority-preemptive scheduling model combined with round-robin execution among tasks of equal priority. Owing to its excellent real-time performance and reliability, VxWorks is widely deployed in intelligent electronic devices (IEDs) within power systems.\nBy default, VxWorks applications access communication services through the TCP/IP protocol stack, and lower protocol layers are not directly exposed. However, IEC 61850 defines seven communication services that map directly from the application or presentation layer to the data link layer, bypassing TCP/IP. These include multicast and unicast sampled value messages, GOOSE message transmission and management services, and GSSE-related services.\nAmong these, multicast sampled value messages (SMM) and sending GOOSE messages (SGM) impose the highest real-time requirements. Due to their similar mapping principles, this paper focuses on SMM and SGM as representative examples to illustrate the implementation of all seven services in VxWorks.\nCompared with traditional foreground–background architectures, designing real-time communication tasks in an RTOS environment is significantly more complex. Therefore, this paper further investigates the real-time processing strategies required to meet FMTS performance constraints in VxWorks.\n🔍 FMTS Analysis # Abstract Communication Service Interface (ACSI) # ACSI defines communication services in IEC 61850 at an abstract level, specifying service behaviors, parameters, and data models independently of underlying protocols, operating systems, or hardware platforms.\nBoth SMM and SGM adopt a publisher/subscriber communication model. This model is particularly well suited for scenarios where one or more publishers distribute data to multiple subscribers under high data throughput and stringent real-time constraints.\nThe main differences between SMM and SGM are as follows:\nDataset content\nSMM datasets are limited to sampled values and are indexed by functional constraint data attributes. In contrast, SGM datasets are more flexible and may include various data objects or attributes.\nTransmission behavior\nSMM transmission is driven by periodic sampling events, typically at a fixed multiple of the sampling interval, and does not support retransmission. SGM operates periodically under normal conditions but supports rapid retransmission in response to events such as protection trips or blocking signals.\nAs a result, SGM involves more control block parameters, a more complex state machine, and higher implementation complexity compared to SMM.\nSpecific Communication Service Mapping (SCSM) # SCSM defines how ACSI services are mapped onto concrete protocol stacks. For FMTS, SCSM specifies:\nImplementation of the publisher/subscriber model Message encoding and decoding Coordination between communication services and application data updates FMTS maps directly to the data link layer, using multicast or broadcast Ethernet frames. Multicast enables dynamic subscription management, while broadcast requires VLAN configuration to limit traffic scope.\nSMM and SGM correspond to Sampled Value (SAV) and GOOSE messages, respectively. Their organization includes:\nEthernet frame fields\nDestination and source MAC addresses, priority tags, and EtherType values are assigned in accordance with IEEE 802.3 and IEC 61850 specifications.\nData segments\nApplication Protocol Data Units (APDUs) and Application Service Data Units (ASDUs) are encoded using ASN.1 Basic Encoding Rules (BER). For forward compatibility, IEC 61850-9-1 defines a simplified mapping for SMM, using double-byte encoding for sampled values and bit-level encoding for status data.\nThe send and receive processes of SAV and GOOSE messages must strictly follow the ACSI definitions of SMM and SGM.\n🛠️ FMTS Implementation in VxWorks # VxWorks Network Protocol Stack # The VxWorks network stack follows the OSI model and introduces a multiplexer (MUX) layer above the data link layer. MUX does not process data itself but forwards frames between enhanced network drivers (ENDs) and upper-layer protocols, providing a unified interface and isolating protocol stacks from hardware drivers.\nWhile standard applications access MUX via sockets and TCP/IP, FMTS requires direct access to MUX. To achieve this, a fast communication interface (FCI) is implemented above MUX.\nFast Communication Interface (FCI) # FCI provides a lightweight communication path between applications and the data link layer. It exposes six application interfaces and four MUX callback functions. The callbacks perform minimal data copying and validation before notifying applications through semaphores.\nKey FCI functions include:\nfciOpen / fciClose: Register or unregister FCI with MUX. fciMCastAddrSet: Configure multicast addresses for SAV and GOOSE messages. fciSend: Encapsulate APDUs into Ethernet frames and forward them to END drivers via MUX. fciPollSend / fciPollReceive: Polling-based debug interfaces. fciRcvRtn: Receive callback that filters SAV and GOOSE frames and delivers valid APDUs to applications. fciError / fciTxRestartRtn: Notify applications of communication failures and recovery. FCI does not implement APDU encoding/decoding or service state machines. These functions are handled by dedicated application tasks.\nApplication Task Design # FMTS functionality is implemented using the following application tasks:\nSRT (tSavReceiveTask): Implements SMM subscriber processing GRT (tGooseReceiveTask): Implements SGM subscriber processing GST (tGooseSendTask) and GSF (fGooseSend): Implement SGM publisher processing These tasks cooperate with FCI and other system components via shared memory and semaphores.\nSampled Value Receive Task (SRT) # SRT parses SAV APDUs and delivers sampled values to applications such as digital filtering modules.\nSRT first identifies whether the message uses IEC 61850-9-1 or 9-2 encoding. For 9-1 frames, fixed-length fields are decoded, counters are verified, and sampled values are converted into engineering units. For 9-2 frames, ASDUs are located dynamically, identifiers are validated against the CID file, and samples are decoded accordingly.\nParsed data and counters are written to shared memory, and semaphores are released to notify downstream applications.\nGOOSE Receive Task (GRT) # GRT decodes GOOSE APDUs and supplies status information to protection and control applications.\nAfter decoding control block parameters such as GoCBRef, StNum, SqNum, and TAL, GRT evaluates message validity based on dataset existence, test flags, sequence correctness, and timeout conditions. Depending on the result, GRT either updates shared memory and notifies applications or logs communication status events.\nGOOSE Send Task and Function (GST and GSF) # GST handles periodic GOOSE transmission, while GSF manages event-triggered rapid retransmission. Each GOOSE control block has dedicated GST and GSF instances to support independent timing requirements.\nTo reduce latency, static APDU fields are pre-encoded. On events, GSF immediately sends a new GOOSE message and schedules exponential backoff retransmissions, after which control returns to GST for periodic transmission.\n⚡ Real-Time Processing of FMTS # Real-Time Optimization Strategies # To ensure FMTS real-time performance in VxWorks, the following measures are applied:\nRegister FCI with MUX using the PROTO_SNARF flag to prioritize frame reception. Assign higher priorities to FMTS tasks than to standard network and application tasks. Use shared memory and binary semaphores for high-frequency data exchange. Pre-encode static APDU fields to reduce runtime encoding overhead. Enable DMA mode in END drivers to minimize CPU load. Real-Time Performance Testing # A test setup consisting of three ARM9-based VxWorks devices simulating protection, switchgear, and merging units is constructed. Sampled values are transmitted at 2400 Hz, while GOOSE trip and position messages are exchanged under various load conditions.\nMeasured end-to-end delays consistently remain below 2 ms, satisfying the IEC 61850 FMTS requirement of less than 3 ms. Test results also demonstrate that higher task priorities significantly improve GOOSE real-time performance under heavy network load.\n✅ Conclusion # This paper presents a practical approach to implementing IEC 61850 fast message transmission services in VxWorks. By introducing a fast communication interface, carefully designed application tasks, and targeted real-time optimizations, both SAV and GOOSE services can meet stringent real-time requirements.\nThe implementation has been validated through real-time performance testing and provides a solid reference for IEC 61850 engineering applications on VxWorks platforms. Future work will focus on unifying data structures across SMM, SGM, and MMS services and evaluating system-level response times under more realistic substation scenarios.\n","date":"2026-01-24","externalUrl":null,"permalink":"/app/implementation-of-iec-61850-fast-message-transmission-services-in-vxworks/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eImplementation of IEC 61850 Fast Message Transmission Services in VxWorks\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e📘 Abstract \n    \u003cdiv id=\"-abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eSampled Values (SV) and Generic Object-Oriented Substation Events (GOOSE) are the two communication services with the most stringent real-time requirements in the IEC 61850 standard. These services—collectively referred to as fast message transmission services (FMTS)—bypass the conventional TCP/IP protocol stack and map directly from the application or presentation layer to the data link layer.\u003c/p\u003e","title":"Implementation of IEC 61850 Fast Message Transmission Services in VxWorks","type":"app"},{"content":"","date":"2026-01-21","externalUrl":null,"permalink":"/tags/reliability/","section":"Tags","summary":"","title":"Reliability","type":"tags"},{"content":" 📘 Abstract # In application domains with extremely high reliability requirements, embedded devices are typically built on real-time operating systems such as VxWorks. Although VxWorks provides strong guarantees in terms of determinism and operational stability, abnormal system restarts remain unavoidable in complex deployments. Based on extensive maintenance experience in signal and safety-critical systems, this article summarizes practical troubleshooting techniques from multiple perspectives, including application-level tracing, task exception tracing, interrupt exception analysis, and auxiliary diagnostic considerations. Applying these methods has proven effective in significantly improving the maintenance efficiency and operational reliability of embedded signal systems.\nKeywords: VxWorks system, abnormal restart, exception tracing\n🧭 Introduction # Safety computer systems are designed according to fail-safe principles: when faults occur, the system transitions into a predefined safe state to prevent catastrophic consequences. Railway signal systems are typical functional safety systems. When computational abnormalities are detected, the system often proactively enters a safe mode, commonly implemented as a controlled restart. This behavior represents an active fail-safe mechanism.\nIn contrast, passive fail-safe behavior arises from unexpected program errors, such as memory corruption or stack overflow, which degrade system availability and are far more difficult to diagnose.\nAs embedded systems continue to expand in scale, application scope, and functional complexity, abnormal restart issues have become increasingly frequent and severe. Some failures occur sporadically, are difficult to reproduce, and require long-term observation and analysis. This article focuses on VxWorks-based embedded systems and presents systematic methods for troubleshooting abnormal restart problems.\n🔍 Troubleshooting Methods for Abnormal Restarts in VxWorks Systems # Application-Level Tracing # Application-level tracing relies on logging information generated by application tasks and interrupt handlers. The core idea is to record identifiable execution markers at key points in the code and store them in non-volatile or restart-preserved memory. After an abnormal restart, these records are retrieved and analyzed to determine the last executed code path.\nThis approach is particularly effective for identifying application logic errors. If logs repeatedly stop at the same execution marker before each restart, the code segment immediately following that marker is highly suspect.\nExample: Uninitialized Variable Leading to Memory Corruption # USHORT k; ULONG CKPara[50]; static ULONG CKPara_last[50]; ... if (!normalFlag) { /* Special execution path: k and CKPara not initialized */ } else { k = 0; CKPara[k] = value_a; k++; CKPara[k] = value_b; } ... for (j = 0; j \u0026lt; k; j++) { CKPara_last[j] = CKPara[j]; } sendLog(CKPara_last, CKPara); In this case, routine execution usually follows the else branch, where k is initialized correctly. However, under rare conditions, execution enters the if (!normalFlag) branch, leaving k uninitialized. As an unsigned short, k may assume a large random value. When k \u0026gt; 50, the loop overwrites memory beyond the bounds of CKPara_last, corrupting adjacent static or global variables and ultimately triggering an abnormal restart.\nRepeated log analysis consistently showed execution stopping just before this code block, enabling rapid localization and confirmation through code inspection.\nVxWorks System Exception Tracing Techniques # VxWorks Build and Debug Environment # Wind River provides the Tornado and Workbench integrated development environments for VxWorks, supporting GNU and Diab toolchains. While breakpoint debugging is supported, it is rarely practical in real-time systems due to timing sensitivity. Instead, engineers typically rely on shell output, Telnet logging, or persistent storage-based logging.\nTask Exception Tracing # VxWorks provides the excLib library, which supports exception hook registration through excHookAdd(). This mechanism allows developers to capture task exception context, including register states and call stacks.\nvoid excSysHandler(int tid, int vecNum, ESF1 *pESf) { REG_SET regSet; if (taskRegsGet(tid, \u0026amp;regSet) != ERROR) { trcStack(\u0026amp;regSet, (FUNCPTR) dbgPrintFun, tid); taskRegsShow(tid); } } void traceInit(void) { fd = open(\u0026#34;/ata0/exclog.txt\u0026#34;, O_RDWR | O_CREAT, 0644); seek(fd, 0, SEEK_END); ioGlobalStdSet(2, fd); excHookAdd((FUNCPTR) excSysHandler); } This approach redirects exception output to a persistent log file and records the function call stack at the time of the exception. For rare task-level faults, this method often enables precise fault localization from a single occurrence.\nInterrupt Exception Tracing # Interrupt exceptions cannot be captured using standard task exception hooks. Instead, VxWorks stores interrupt exception messages at the sysExcMsg address. By adjusting EXC_MSG_OFFSET and EXC_MSG_ADRS, or by reassigning sysExcMsg to application-managed memory, exception information can be preserved across non-power-loss restarts.\nAfter reboot, developers can inspect the memory region using the VxWorks shell and decode the ASCII-formatted exception message. Although stack traces are unavailable, the Program Counter (PC) value can be correlated with disassembly output (objdump) to approximate the fault location.\nTroubleshooting via Application Logic Analysis # When logs and exception tracing yield no clear clues, deeper logical analysis is required.\nStack Overflow Investigation # Stack overflows are a common and dangerous cause of abnormal restarts. Symptoms vary widely and may not be immediately reproducible. Engineers should verify:\nTask stack sizes specified in taskSpawn Root and shell stack sizes (ROOT_STACK_SIZE, SHELL_STACK_SIZE) Interrupt stack configuration (intStackEnable, ISR_STACK_SIZE) The checkStack utility can detect stack overflows in real time.\nIn one case, a system restarted irregularly every few months. A debug build revealed stack overflow in a floating-point task. Investigation showed that an interrupt handler allocated two large local structures (\u0026gt;3 KB). After refactoring to reduce stack usage, no further restarts occurred in field operation.\nComparative Testing and Fault Isolation # For elusive faults, engineers can accelerate test cycles, increase data volume, or introduce targeted instrumentation to reproduce failures more quickly. By incrementally enabling or disabling suspected code paths and comparing behavior, the root cause can often be isolated.\nIn an x86-based VxWorks system, abnormal restarts were traced to a floating-point comparison under stress conditions. After fixing the logic, the system operated continuously for over a year without a single restart, compared to multiple failures prior to the fix.\n🛡️ Techniques to Reduce VxWorks Exceptions # Enabling MMU Protection # VxWorks supports MMU-based memory protection. By enabling write protection for code segments and interrupt vector tables, illegal memory accesses are converted into detectable exceptions rather than silent corruption, greatly improving diagnosability when combined with task exception tracing.\nStatic Analysis and Code Inspection Tools # Manual code reviews are insufficient for large, long-lived systems. Static analysis tools can automatically detect issues such as uninitialized variables, buffer overflows, and invalid pointer usage. In the earlier example involving variable k, such tools would have flagged the defect immediately. Enforcing coding standards through automated checks significantly enhances system stability.\nTracking CPU and OS Errata # Some abnormal restarts originate from known CPU or OS defects. Engineers should regularly consult processor errata and VxWorks release notes, correlating documented issues with observed behavior. In certain x86 platforms, unresponsiveness was linked to system management interrupt (SMI) handling, prompting design adjustments.\n✅ Conclusion # Based on extensive real-world experience in railway and safety-critical embedded systems, this article presents a comprehensive set of troubleshooting methods for abnormal restarts in VxWorks environments. By combining application-level tracing, task and interrupt exception analysis, stack diagnostics, and preventive techniques, engineers can significantly improve fault localization efficiency and overall system reliability. These methods are not only applicable to VxWorks but also provide valuable reference for debugging other real-time embedded operating systems.\n","date":"2026-01-21","externalUrl":null,"permalink":"/app/research-on-troubleshooting-methods-for-abnormal-restarts-in-vxworks-systems/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003e📘 Abstract \n    \u003cdiv id=\"-abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn application domains with extremely high reliability requirements, embedded devices are typically built on real-time operating systems such as VxWorks. Although VxWorks provides strong guarantees in terms of determinism and operational stability, abnormal system restarts remain unavoidable in complex deployments. Based on extensive maintenance experience in signal and safety-critical systems, this article summarizes practical troubleshooting techniques from multiple perspectives, including application-level tracing, task exception tracing, interrupt exception analysis, and auxiliary diagnostic considerations. Applying these methods has proven effective in significantly improving the maintenance efficiency and operational reliability of embedded signal systems.\u003c/p\u003e","title":"Research on Troubleshooting Methods for Abnormal Restarts in VxWorks Systems","type":"app"},{"content":"","date":"2026-01-21","externalUrl":null,"permalink":"/tags/compactpci/","section":"Tags","summary":"","title":"CompactPCI","type":"tags"},{"content":" 📘 Abstract # This article introduces CompactPCI (cPCI) bus and interface technologies, with a focus on PCI configuration space organization and device control under the VxWorks real-time operating system. It explains how cPCI devices are configured, driven, and managed in VxWorks-based systems. Because real-time systems respond to external events primarily through interrupts, hardware interrupt handling is a critical design concern. Under VxWorks, cPCI interrupt processing involves binding external interrupts to interrupt service routines (ISRs) and configuring the interrupt control registers of the PCI9054 interface chip. Semaphores are used within ISRs to synchronize tasks, ensuring reliable and deterministic real-time data acquisition.\nKeywords: CompactPCI bus, PCI configuration space, interrupt control, semaphore synchronization\n🧭 Introduction # With growing demand for high-reliability and high-performance industrial systems, the CompactPCI bus has become a widely adopted embedded backplane architecture. CompactPCI combines high bandwidth, rugged Eurocard mechanical design, and open software support, making it suitable for telecommunications, industrial control, medical systems, automation, and data communication platforms.\nVxWorks, developed by Wind River Systems, is a widely used embedded real-time operating system (RTOS). It provides deterministic task scheduling, efficient interrupt handling, real-time resource management, and flexible inter-task communication mechanisms. Due to its reliability and real-time guarantees, VxWorks is extensively used in safety- and mission-critical domains such as aerospace, defense, medical devices, and communications.\nIn petroleum logging surface systems—vehicle-mounted real-time data acquisition and processing platforms—strict real-time requirements apply. These systems issue control commands to downhole instruments and receive large volumes of measurement data, performing real-time control, quality monitoring, data processing, visualization, and storage. Any loss of interrupt response can cause data corruption or operational failure. To meet these requirements, the system described here adopts a CompactPCI hardware architecture and VxWorks software platform to ensure real-time performance, reliability, and maintainability.\n🧩 Bus and Interface Technology # CompactPCI is an open industrial standard defined by the PCI Industrial Computer Manufacturers Group (PICMG). It is fully compatible with conventional PCI in electrical, logical, and software aspects while offering improved mechanical robustness. CompactPCI boards are installed in card cages using standardized 3U or 6U Eurocard form factors.\nCompactPCI integrates three key technologies:\nThe high-performance PCI local bus Rugged Eurocard mechanical structures Reliable high-density pin-and-socket connectors The PCI local bus is a high-performance 32-bit or 64-bit bus with multiplexed address and data lines. It supports multi-master operation and provides efficient interconnection between CPUs, memory subsystems, and peripheral controllers. Operating frequencies originally defined at 33 MHz have expanded to 66 MHz and beyond. At 33 MHz with a 32-bit bus width, PCI achieves a peak bandwidth of 132 MB/s, sufficient for network adapters, storage controllers, and data acquisition cards.\nA key feature of PCI is its configuration space, which enables automatic device discovery and resource allocation. System software reads device parameters from configuration space and assigns address resources dynamically, enabling plug-and-play functionality and allowing multiple identical devices to coexist without conflicts.\nIn this system, user function boards connect to the PCI bus through the PLX PCI9054 interface chip. The PCI9054 is a 32-bit, 33 MHz PCI controller compliant with PCI 2.2 specifications and supports burst transfers up to 132 MB/s. It can operate as both a PCI master and target and provides interfaces to PCI, EEPROM, and a LOCAL bus.\nThe LOCAL bus supports multiple operating modes (M, C, and J). In the described data acquisition system, the LOCAL bus operates in C mode (target mode). Configuration data for the PCI9054 is stored in an external serial EEPROM (NM93CS56L). During system startup, the PCI9054 loads configuration parameters—including vendor ID, device ID, address ranges, and base addresses—from EEPROM, enabling automatic resource allocation by the host system.\nThe PCI9054 supports three primary data transfer modes:\nPCI Initiator mode: LOCAL bus master accesses PCI memory or I/O space PCI Target mode: PCI master accesses LOCAL bus registers or memory DMA mode: PCI9054 transfers data autonomously between PCI and LOCAL buses In this design, PCI Target mode is used for register-level control and data access.\n⚙️ Device Configuration under VxWorks # VxWorks abstracts many low-level system services, allowing driver developers to focus on device logic rather than resource management. To implement a cPCI device driver, developers must understand the PCI configuration register space, which consists of 256 bytes divided into a standard header region and a device-specific region.\nThe header region includes fields such as:\nVendor ID and Device ID Revision ID Class code Header type Base Address Registers (BARs) define how much memory or I/O space a device requires and allow the system to map device resources into the processor’s address space. Writing all 1s to a BAR and reading it back reveals the size of the required address region.\nDevice Enumeration Process # Under VxWorks, cPCI device initialization typically follows these steps:\nLocate the device using pciFindDevice(), which identifies the bus number, device number, and function number based on vendor and device IDs. Access configuration space using APIs such as pciConfigInLong() and pciConfigOutLong() to configure BARs, interrupt lines, and command registers. Map device memory into the system address space and initialize control registers. Install interrupt handlers and prepare runtime data structures. An example device initialization routine is shown below:\nSTATUS Init_IP() { if (pciFindDevice(VID_IPCARRIER, DID_IPCARRIER, index, \u0026amp;pBusNo, \u0026amp;pDeviceNo, \u0026amp;pFuncNo) != OK) { return ERROR; } pciConfigInLong(pBusNo, pDeviceNo, pFuncNo, 0x10, \u0026amp;BaseAdd0_IPCarrier); pciConfigInLong(pBusNo, pDeviceNo, pFuncNo, 0x18, \u0026amp;BaseAdd2_IPCarrier); sysMmioMapAdd( (BaseAdd2_IPCarrier \u0026amp; PCI_DEV_MMU_MSK), PCI_DEV_ADRS_SIZE, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE, VM_STATE_VALID | VM_STATE_WRITABLE ); return OK; } 🔔 Interrupt Response and Control # Interrupt handling is central to real-time system performance. In VxWorks, interrupt service routines execute outside all task contexts, eliminating task-switching overhead and ensuring minimal response latency.\nThe PCI9054 provides an interrupt control/status register at offset 0x68. This register must be configured correctly to enable cPCI interrupts.\nUnder VxWorks, interrupt configuration involves two key steps:\nConnecting the interrupt vector using pciIntConnect() Enabling interrupts in the PCI9054 control register STATUS Init_IP_Int() { if (pciIntConnect(INUM_TO_IVEC(0x27), IPIsr, 0) == ERROR) { return ERROR; } *(int *)(BaseAdd0_IPCarrier + 0x68) = 0x0f010900; return OK; } To disable interrupts, the control register is written with 0x0f000000.\nSemaphore-Based Synchronization # To keep ISRs short and efficient, the interrupt routine simply releases a semaphore associated with the event:\nvoid IPIsr() { semGive(sem_DepthInt); } Binary semaphores in VxWorks provide fast and deterministic synchronization between ISRs and tasks. When a task calls semTake(), it either proceeds immediately or blocks until the ISR signals completion. This mechanism ensures reliable real-time data acquisition without excessive interrupt processing overhead.\n✅ Conclusion # By combining CompactPCI hardware with VxWorks real-time software, the system successfully implements stable and deterministic control of multiple cPCI boards, including DSP processing modules, high-speed and low-speed ADC channels, counters, and depth control units. Practical operation demonstrates that the described CompactPCI driving and interrupt control techniques are feasible and effective. The approach satisfies stringent real-time and reliability requirements, making it well suited for industrial and data acquisition systems based on VxWorks.\n","date":"2026-01-21","externalUrl":null,"permalink":"/bsp/driving-and-control-techniques-for-compactpci-bus-under-vxworks/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003e📘 Abstract \n    \u003cdiv id=\"-abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThis article introduces CompactPCI (cPCI) bus and interface technologies, with a focus on PCI configuration space organization and device control under the VxWorks real-time operating system. It explains how cPCI devices are configured, driven, and managed in VxWorks-based systems. Because real-time systems respond to external events primarily through interrupts, hardware interrupt handling is a critical design concern. Under VxWorks, cPCI interrupt processing involves binding external interrupts to interrupt service routines (ISRs) and configuring the interrupt control registers of the PCI9054 interface chip. Semaphores are used within ISRs to synchronize tasks, ensuring reliable and deterministic real-time data acquisition.\u003c/p\u003e","title":"Driving and Control Techniques for CompactPCI Bus under VxWorks","type":"bsp"},{"content":" 📘 Abstract # To support automatically loading different VxWorks images and applications from a single hard disk, this article presents a universal booting and application-loading method for VxWorks systems. The solution is based on separating bootrom, image, and startup configuration files, formatting the disk with DOS 7.1, and using config.sys and AutoExec.bat to dynamically select and deploy target programs. By leveraging DOS batch processing, the system can copy and activate the required bootrom, image, startup scripts, and executables at boot time, enabling a flexible “one disk, multiple applications” deployment model.\nKeywords: VxWorks, embedded systems, booting and loading, system configuration\n🧭 Introduction # VxWorks systems generally support two boot modes: load-based booting and bootable (standalone) booting.\nIn load-based mode, the system boots using a bootrom combined with a separate VxWorks image. This approach is widely used during development. The bootrom mounts a file system and loads the kernel image from a fixed disk location into RAM. While this method simplifies kernel replacement, it has several limitations:\nMultiple applications stored on disk must be manually renamed before loading. Automatic application selection is not supported without modifying the image. Adding or removing applications often requires recompiling the VxWorks image. In bootable mode, the system boots directly from a self-contained image, which can be burned into Flash using VxWorks_rom. This eliminates file system dependencies but makes program updates inconvenient, as reflashing is required for every change.\nTo improve flexibility and usability, this article introduces a universal booting and loading method that allows multiple VxWorks images and applications to coexist on a single disk and be selected dynamically at startup.\n🧠 VxWorks System Boot Process # A VxWorks target system requires two key components to boot:\nBootrom – a minimal boot program responsible for hardware initialization and kernel loading Image – the VxWorks kernel and application image The bootrom is generated by compiling the BSP (Board Support Package) in Tornado or Workbench. Its responsibilities include initializing hardware to a stable state and providing hardware abstraction services for the kernel.\nBootrom Execution Flow # romInit\nDisables interrupts Initializes registers and memory controller Sets up the stack Jumps to romStart romStart\nCopies romInit and itself into RAM (RAM_LOW_ADRS) Decompresses the remaining bootrom into RAM Transfers control to usrInit usrInit\nInitializes peripheral hardware Prepares for kernel image download Creates tUsrBoot, which calls usrRoot Starts tBoot, invoking bootCmdLoop to load the image After the image is downloaded, execution jumps to sysInit, starting the VxWorks kernel. When usrRoot completes, the system enters normal operation.\nBoot Line Configuration # The boot process is controlled by DEFAULT_BOOT_LINE in the BSP’s config.h.\nNetwork boot example:\n#define DEFAULT_BOOT_LINE \u0026#34;fei(0,0) host:VxWorks h=192.168.0.33 e=192.168.0.18 u=user pw=123\u0026#34; Local hard disk boot example:\n#define DEFAULT_BOOT_LINE \u0026#34;ata=0,0(0,0) host:/ata0/VxWorks h=192.168.0.33 e=192.168.0.18 u=user pw=123\u0026#34; 🛠 Universal Method for Booting and Loading Applications # The proposed solution enables multiple images and applications to be loaded from the same disk through configuration rather than recompilation.\nGenerating Bootrom, Image, and Startup Files # The system uses load-based booting (bootrom + image). For each application set:\nGenerate the corresponding bootrom and image Create a text-based startup script defining which applications to load and run To enable automatic application loading, add the following code to usrAppInit.c in the image project:\nint fd; if ((fd = open(\u0026#34;/ata0a/startup.txt\u0026#34;, O_RDWR, 0644)) != NULL) { usrStartupScript(\u0026#34;/ata0a/startup.txt\u0026#34;); close(fd); } Ensure the INCLUDE_STARTUP_SCRIPT component is enabled in the VxWorks image configuration.\nExample startup.txt:\nld 1,0,\u0026#34;/ata0a/APP/rt.out\u0026#34;; DualNetWork_Switch_OO(\u0026#34;198.1.108.1\u0026#34;,\u0026#34;198.1.108.253\u0026#34;,\u0026#34;255.255.255.0\u0026#34;,66,0,0); ld 1,0,\u0026#34;/ata1a/fei.out\u0026#34;; DualNetWorkSwitch(\u0026#34;191.8.200.1\u0026#34;,\u0026#34;255.255.255.0\u0026#34;,\u0026#34;191.8.200.1\u0026#34;,0); ld 1,0,\u0026#34;/ata1a/iiutest\u0026#34;; taskSpawn 0, 100, 0, 0x1000000, main; Disk Formatting # Format the boot disk using DOS 7.1, which provides compatibility with DOS startup scripts and batch processing required for dynamic file selection.\nStartup Menu with config.sys and AutoExec.bat # The boot menu is defined in config.sys, while application-specific file replacement is handled in AutoExec.bat.\nExample config.sys:\n[MENU] MENUITEM=vxWorks.dbg, Start default image MENUITEM=jk1, JK1 MENUITEM=jk2, JK2 MENUITEM=jk1test, JK1 Test MENUITEM=jk2test, JK2 Test MENUDEFAULT=vxWorks.dbg,3 [vxWorks.dbg] DEVICE=c:\\HIMEM.SYS DOS=HIGH,UMB SHELL=C:\\VXLOAD.COM C:\\bootrom.dbg Example AutoExec.bat (jk1test):\n@echo off goto %config% :jk1test del bootrom.dbg copy bootrom.ts1 bootrom.dbg del D:\\APP\\rt.out copy D:\\APP\\rt1.out D:\\APP\\rt.out del test.txt copy test1.txt test.txt del iiutest copy iiutest1 iiutest goto end :end This mechanism replaces default files with application-specific versions before VxWorks boots.\n✅ Conclusion # This article presents a universal VxWorks booting and application-loading method that enables multiple images, configurations, and executables to coexist on a single disk. By separating bootrom, image, startup scripts, and applications, the system achieves high flexibility and maintainability. New applications can be added or removed by editing configuration files only, without recompiling bootroms or kernel images. The approach significantly improves usability and supports scalable, production-ready VxWorks deployments.\n","date":"2026-01-19","externalUrl":null,"permalink":"/app/universal-method-for-booting-and-loading-applications-in-vxworks/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003e📘 Abstract \n    \u003cdiv id=\"-abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eTo support automatically loading different VxWorks images and applications from a single hard disk, this article presents a universal booting and application-loading method for VxWorks systems. The solution is based on separating \u003cstrong\u003ebootrom\u003c/strong\u003e, \u003cstrong\u003eimage\u003c/strong\u003e, and \u003cstrong\u003estartup configuration files\u003c/strong\u003e, formatting the disk with DOS 7.1, and using \u003ccode\u003econfig.sys\u003c/code\u003e and \u003ccode\u003eAutoExec.bat\u003c/code\u003e to dynamically select and deploy target programs. By leveraging DOS batch processing, the system can copy and activate the required bootrom, image, startup scripts, and executables at boot time, enabling a flexible “one disk, multiple applications” deployment model.\u003c/p\u003e","title":"Universal Method for Booting and Loading Applications in VxWorks","type":"app"},{"content":"","date":"2026-01-11","externalUrl":null,"permalink":"/tags/rtos-migration/","section":"Tags","summary":"","title":"RTOS Migration","type":"tags"},{"content":" 🚀 Migration Overview and Strategy # Migrating from VxWorks 5.5 to VxWorks 7 is not a simple version upgrade—it is a platform transformation. VxWorks 5.5 was designed for single-core, statically linked, board-centric systems, while VxWorks 7 targets multicore, network-centric, software-defined platforms.\nKey migration goals typically include:\nPreserving real-time determinism Improving scalability and security Enabling modern networking (IPv6, TSN) Supporting CI/CD and long-term maintainability A phased migration strategy is strongly recommended:\nArchitectural assessment BSP and hardware enablement Application refactoring Networking and protocol modernization Verification and performance validation 🧠 Architectural Evolution: 5.5 vs. 7.x # VxWorks 5.5 follows a monolithic, flat kernel model, whereas VxWorks 7 introduces a componentized, scalable architecture.\nKey differences:\nArea VxWorks 5.5 VxWorks 7 Kernel Monolithic Modular microkernel SMP Limited / none Full SMP, multicore Address Space Flat Protected RTPs Build Model Image-based Component-based Networking IPv4-centric IPv4/IPv6, TSN Security Minimal Policy-driven This shift requires rethinking assumptions about task ownership, memory access, and system initialization.\n🧩 BSP and Hardware Migration # In VxWorks 5.5, BSPs are tightly coupled to:\nA single CPU Static memory maps Direct device access In VxWorks 7:\nBSPs are SoC-centric Support multicore boot and SMP Separate hardware enablement from application logic Migration steps:\nReplace legacy BSP with a VxWorks 7-compatible BSP Verify interrupt routing and timer sources Validate cache and MMU configuration Enable symmetric multiprocessing incrementally Direct register access in applications should be audited and refactored into drivers or VxBus components.\n🔧 Build System and Toolchain Changes # VxWorks 5.5 uses:\nTornado IDE Makefile-based builds Static kernel images VxWorks 7 introduces:\nWind River Workbench / command-line tooling Component-based kernel configuration Modern GCC/LLVM toolchains Key changes:\nKernel features are selected as components Applications build as RTPs (Real-Time Processes) CI-friendly, scriptable builds replace IDE-only flows Migration tip: keep legacy applications building first as kernel-mode tasks, then transition to RTPs.\n🌐 Networking Stack Modernization # Networking changes are among the most significant.\nVxWorks 5.5:\nBSD 4.4-style IPv4 stack Limited multicast and no TSN Polling-heavy designs VxWorks 7:\nio-sock scalable network stack Full IPv6 dual-stack support TSN-aware Ethernet drivers Improved zero-copy paths Required updates:\nReplace inet_addr() with getaddrinfo() Support IPv6 socket families (AF_INET6) Replace broadcast with multicast where possible Introduce traffic prioritization and TSN scheduling Legacy socket code often compiles but must be behaviorally reviewed for timing and scalability.\n⏱️ Real-Time Task Model Migration # VxWorks 5.5 relies heavily on:\nGlobal tasks Shared memory Implicit synchronization VxWorks 7 promotes:\nRTP isolation Explicit IPC (message queues, sockets) CPU affinity and priority inheritance Migration guidelines:\nIdentify hard real-time tasks and keep them kernel-resident initially Move soft real-time and management logic into RTPs Use task pools instead of task-per-connection models Explicitly set scheduling policies and priorities Determinism improves when task placement and CPU affinity are controlled.\n🔐 Safety and Security Considerations # VxWorks 5.5 systems typically assume:\nTrusted code Closed networks Minimal attack surface VxWorks 7 assumes:\nNetwork exposure OTA updates Compliance with IEC 61508, ISO 26262, ISO 21434 Key actions:\nEnable memory protection Define security policies Separate safety-critical and non-critical workloads Log and audit system behavior Security should be treated as a design input, not a retrofit.\n🧪 Testing, Validation, and Performance Tuning # Validation must go beyond functional testing.\nRecommended practices:\nCompare worst-case latency before and after migration Validate scheduling under multicore load Stress-test networking paths with real traffic Use system tracing and profiling tools Expect initial performance regressions until:\nTask affinities are tuned Cache effects are understood Networking queues are sized correctly 🧭 Common Migration Pitfalls # Assuming source compatibility equals runtime compatibility Ignoring SMP side effects Leaving legacy global variables unprotected Treating IPv6 as optional Underestimating BSP effort Early architectural reviews prevent late-stage surprises.\n🏁 Conclusion # Migrating from VxWorks 5.5 to VxWorks 7 is a strategic modernization effort that unlocks multicore performance, deterministic networking, and long-term maintainability. While the learning curve is real, the payoff is a platform ready for software-defined, safety-critical systems.\nA disciplined, phased migration approach ensures that real-time guarantees are preserved while enabling future growth.\n📚 References # Wind River. VxWorks 7 Architecture Overview Wind River. VxWorks Migration Guide ","date":"2026-01-11","externalUrl":null,"permalink":"/bsp/vxworks-5.5-to-vxworks-7-migration-guide-architecture-networking-and-real-time/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003e🚀 Migration Overview and Strategy \n    \u003cdiv id=\"-migration-overview-and-strategy\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-migration-overview-and-strategy\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eMigrating from \u003cstrong\u003eVxWorks 5.5\u003c/strong\u003e to \u003cstrong\u003eVxWorks 7\u003c/strong\u003e is not a simple version upgrade—it is a \u003cstrong\u003eplatform transformation\u003c/strong\u003e. VxWorks 5.5 was designed for single-core, statically linked, board-centric systems, while VxWorks 7 targets \u003cstrong\u003emulticore, network-centric, software-defined platforms\u003c/strong\u003e.\u003c/p\u003e","title":"VxWorks 5.5 to VxWorks 7 Migration Guide: Architecture, Networking, and Real-Time Modernization","type":"bsp"},{"content":"","date":"2026-01-11","externalUrl":null,"permalink":"/tags/ipv6/","section":"Tags","summary":"","title":"IPv6","type":"tags"},{"content":" 🚀 Introduction # As embedded systems evolve toward software-defined, network-centric architectures, networking in real-time operating systems has become as critical as task scheduling itself. VxWorks 7, Wind River’s modern RTOS platform, builds on BSD socket foundations while introducing IPv6-first networking, Time-Sensitive Networking (TSN), and scalable multicore performance.\nThis article revisits network programming principles originally based on BSD 4.4, recontextualized for VxWorks 7 environments running on multicore SoCs, automotive Ethernet, and deterministic industrial networks. The focus is on TCP, UDP, multicast, IPv6 addressing, and TSN-aware design patterns for high real-time applications.\n🛠️ VxWorks 7 Networking Architecture # VxWorks 7 replaces monolithic networking assumptions with a componentized, scalable architecture optimized for multicore processors and high-throughput Ethernet.\nKey characteristics include:\nBSD socket API compatibility (POSIX-compliant) Dual-stack IPv4 / IPv6 support (IPv6 preferred) High-performance io-sock networking stack Native support for TSN (IEEE 802.1) features Improved SMP scalability and NUMA awareness Supported protocols and services include:\nTCP, UDP, SCTP IPv6, ICMPv6, Neighbor Discovery Multicast (IGMPv3 / MLDv2) DNS, DHCPv6 SNMP, FTP, NFS TSN traffic shaping and time-aware scheduling This architecture enables deterministic communication in safety-critical systems such as defense platforms, autonomous vehicles, and industrial automation.\n🔗 TCP Programming in VxWorks 7 # TCP remains the preferred protocol for configuration, diagnostics, logging, and non-real-time control traffic where reliability and ordering are mandatory.\nVxWorks 7 preserves the classic client–server socket model while significantly improving throughput and scalability on multicore systems.\nTCP socket creation follows the familiar interface:\nint CreateTCP(char *serverName, unsigned short wPortNum, int TcpType); serverName: Hostname or IPv4/IPv6 address wPortNum: TCP port TcpType: TCP_CLIENT = 0, TCP_SERVER = 1 Under IPv6, getaddrinfo() replaces legacy address resolution, allowing seamless dual-stack operation.\nServers typically:\nBind to wildcard IPv6 addresses (::) Support concurrent connections using task pools Assign priorities to worker tasks for predictable latency ⚡ UDP Programming for Deterministic Data Paths # UDP remains the protocol of choice for hard real-time data paths, sensor fusion, and cyclic control traffic.\nIn VxWorks 7:\nUDP sockets are fully IPv6-capable Zero-copy and optimized buffer handling reduce jitter TSN-aware NIC drivers enable bounded latency The UDP socket creation interface remains:\nint CreateUDP(char *serverName, unsigned short wPortNum, int UdpType); UdpType: UDP_CLIENT = 0, UDP_SERVER = 1 UDP is commonly used with:\nFixed-rate transmission (e.g., 1 kHz control loops) Application-level sequence counters Optional acknowledgments for critical messages 📡 Multicast Networking with IPv6 and TSN # Multicast remains essential for one-to-many real-time data distribution, such as state replication and sensor broadcasts.\nIn modern systems:\nIPv4 multicast uses IGMPv3 IPv6 multicast uses MLDv2 TSN ensures bounded latency for multicast streams Multicast configuration still relies on setsockopt():\nOption Parameter Description IP_MULTICAST_IF struct in_addr Select multicast interface IP_MULTICAST_TTL CHAR Set multicast TTL IP_MULTICAST_LOOP CHAR Enable/disable loopback IP_ADD_MEMBERSHIP struct ip_mreq Join multicast group IP_DROP_MEMBERSHIP struct ip_mreq Leave multicast group For IPv6, equivalent options (IPV6_JOIN_GROUP, etc.) are used.\nHelper functions include:\nmcastJoinGroup(...) mcastLeaveGroup(...) mcastRecvInit(...) mcastRecvQuit(...) SetCastTTL(...) All return OK on success or ERROR on failure.\n⏱️ TSN-Aware Real-Time Network Design # Time-Sensitive Networking (TSN) transforms Ethernet into a deterministic fieldbus replacement.\nVxWorks 7 supports TSN features such as:\nIEEE 802.1Qbv (Time-Aware Shaper) IEEE 802.1AS (Time Synchronization) IEEE 802.1Qci (Ingress Policing) Traffic class separation by priority A typical real-time stack design:\nLayer Function Application Control, fusion, supervision Transport UDP (real-time), TCP (management) Network IPv6, ICMPv6 TSN Layer Time-aware scheduling, shaping Link Automotive / Industrial Ethernet Physical Copper / Fiber 🧠 Packet Reception and Concurrency Models # Four reception models remain relevant in VxWorks 7:\nLoop-based, connectionless UDP Task-pool-based concurrent UDP Loop-based TCP sessions Concurrent TCP with worker tasks Modern systems favor:\nTask pools over task-per-connection CPU affinity for network threads Priority inheritance to avoid inversion Transmission rates are dynamically controlled using:\nNetwork congestion feedback TSN scheduling windows Application-level throttling (e.g., 50 Hz → 1 Hz fallback) 🧩 Conclusion # Network programming in VxWorks 7 builds on BSD socket fundamentals while embracing IPv6, TSN, and multicore scalability. TCP, UDP, and multicast remain core tools, now enhanced with deterministic Ethernet and modern tooling.\nThese patterns are proven across defense, automotive, aerospace, and industrial control systems, providing a future-proof foundation for real-time networked applications.\n📚 References # Wind River. VxWorks 7 Network Stack User Guide. IEEE 802.1 TSN Task Group Specifications. Stevens, W. R. UNIX Network Programming, Volume 1. Wind River. VxWorks 7 Architecture Overview. ","date":"2026-01-11","externalUrl":null,"permalink":"/app/modern-network-programming-in-vxworks-7-ipv6-tsn-and-bsd-socket-architecture/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003e🚀 Introduction \n    \u003cdiv id=\"-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eAs embedded systems evolve toward \u003cstrong\u003esoftware-defined, network-centric architectures\u003c/strong\u003e, networking in real-time operating systems has become as critical as task scheduling itself. \u003cstrong\u003eVxWorks 7\u003c/strong\u003e, Wind River’s modern RTOS platform, builds on BSD socket foundations while introducing \u003cstrong\u003eIPv6-first networking, Time-Sensitive Networking (TSN)\u003c/strong\u003e, and scalable multicore performance.\u003c/p\u003e","title":"Modern Network Programming in VxWorks 7: IPv6, TSN, and BSD Socket Architecture","type":"app"},{"content":"","date":"2025-12-28","externalUrl":null,"permalink":"/tags/defense/","section":"Tags","summary":"","title":"Defense","type":"tags"},{"content":"","date":"2025-12-28","externalUrl":null,"permalink":"/tags/embedded-software/","section":"Tags","summary":"","title":"Embedded Software","type":"tags"},{"content":" Radar systems operate under extreme real-time constraints, where milliseconds determine whether a target is correctly detected, tracked, or lost. Transforming noisy radar echoes into stable, actionable target tracks requires deterministic execution, predictable latency, and robust task coordination.\nThis article examines the design and implementation of radar data processing software built on VxWorks, based on research by Peng Xiaobo of the Shaanxi Huanghe Group Design Institute. The system focuses on point trace processing, condensing raw detection points into reliable target tracks while maintaining high real-time performance and operational stability.\n🧠 VxWorks as a Real-Time Radar Platform # Architecture and Core Strengths # VxWorks has been developed continuously since the early 1980s and is widely deployed in aerospace, defense, and industrial systems. Its long-term evolution has resulted in a high-performance RTOS with:\nDeterministic kernel scheduling Low interrupt and task-switch latency Mature synchronization and IPC mechanisms Strong portability across processor architectures These characteristics make VxWorks well suited for radar systems, where data processing pipelines must run predictably under sustained load.\nWind River Workbench Environment # Radar software development is performed using Wind River Workbench, an Eclipse-based integrated development environment that replaced the earlier Tornado tools. Workbench supports extensive configurability and debugging capabilities, often described as supporting “seven multis”:\nMulti-task Multi-target Multi-mode Multi-OS Multi-CPU Multi-connection Multi-host In typical deployments, serial interfaces are used for boot and low-level control, while Ethernet provides high-speed file transfer and debugging access. The radar processing software is implemented primarily in C, allowing tight control over timing and memory usage.\n📡 Radar Data Processing Overview # Modern radar architectures are generally divided into two major processing domains:\nSignal processing, responsible for detection, clutter suppression, and measurement extraction Data processing, responsible for correlation, tracking, filtering, and prediction The focus here is on the data processing layer, whose task is to convert uncertain observation points into stable estimates of target position, velocity, and trajectory. Outputs typically include radial distance, azimuth, elevation, and velocity, enabling real-time tracking and future position prediction for surveillance or guidance applications.\n🔄 Point Trace Processing Pipeline # Although radar implementations vary, the data processing workflow follows a consistent logical structure designed to handle ambiguity and noise.\nPreprocessing # The system receives observation data from the signal processor, organized by scan cycles and batches. Each observation includes parameters such as distance, azimuth, elevation, and target count.\nPreprocessing filters remove invalid or irrelevant points by applying thresholds on distance, angular limits, and other constraints. This step reduces computational load and improves downstream processing reliability.\nTrack Initiation # Track initiation determines whether a new set of observation points represents a real target or transient clutter. The challenge lies in balancing:\nResponsiveness, so new targets are detected quickly Reliability, so false tracks are minimized This is typically achieved using multi-scan confirmation logic, requiring consistent detections across successive radar scans before declaring a valid track.\nPoint-to-Track Correlation # Correlation associates new observation points with existing tracks. In simple scenarios with a single target, this process is straightforward. In dense environments with multiple targets or clutter, association becomes ambiguous.\nCorrelation modes include:\nPoint-to-point association during track initiation Point-to-track association during track maintenance Track-to-track association for data fusion Prediction gates and spatial constraints are used to determine the most likely associations between points and tracks.\nFiltering and State Estimation # To smooth noise and predict target motion, the system applies an α–β filtering algorithm. This lightweight filter estimates position and velocity based on current observations and prior state, making it suitable for real-time embedded execution.\nFiltering runs in parallel with correlation, producing continuous, stable target tracks despite measurement uncertainty.\nTrack Update and Maintenance # Radar measurements may occasionally miss a target due to occlusion or interference. When this occurs, the system uses filtered predictions to insert temporary points, maintaining track continuity.\nA counter tracks consecutive predicted inserts:\nReset when a real observation is received Incremented on predicted updates Used to determine whether a track remains valid This mechanism prevents short-term data loss from immediately terminating valid tracks.\nTrack Termination # To avoid indefinite prediction of nonexistent targets, each track is subject to a termination policy. If the number of consecutive missed detections exceeds a predefined threshold, the track is deleted.\nThis balances two competing goals:\nPreventing resource waste on false tracks Avoiding premature termination of real targets 🧩 Implementation on VxWorks # The radar data processing software is implemented as a set of real-time tasks running under VxWorks. Development uses Workbench and standard C, with data organized into structured files or buffers, including:\nPending observation points Preprocessed point sets Temporary predicted points Reliable track data Final output tracks VxWorks provides deterministic task scheduling, interrupt handling, and data transmission mechanisms, ensuring that the full processing pipeline meets strict real-time deadlines.\n🎯 Practical Impact and Results # By refining noisy radar observations into stable tracks, the system improves both detection probability and tracking accuracy. The VxWorks-based implementation demonstrates:\nHigh real-time reliability under sustained processing loads Strong portability across embedded hardware platforms Proven stability in operational radar systems The design is readily adaptable to other radar and sensor fusion systems requiring predictable, real-time data processing.\n🏁 Final Thoughts # Radar data processing is a cornerstone of modern surveillance and defense systems. This VxWorks-based implementation shows how a well-structured processing pipeline—combined with a deterministic RTOS—can deliver accurate, reliable target tracking in demanding environments.\nFor engineers building radar or sensor-processing platforms, this approach offers a proven reference for integrating real-time operating systems into computation-heavy, time-critical applications.\n","date":"2025-12-28","externalUrl":null,"permalink":"/app/radar-data-processing-with-vxworks-for-real-time-target-tracking/","section":"Apps","summary":"\u003c!--# Radar Data Processing with VxWorks for Real-Time Target Tracking--\u003e\n\u003cp\u003eRadar systems operate under extreme real-time constraints, where milliseconds determine whether a target is correctly detected, tracked, or lost. Transforming noisy radar echoes into stable, actionable target tracks requires deterministic execution, predictable latency, and robust task coordination.\u003c/p\u003e","title":"Radar Data Processing with VxWorks for Real-Time Target Tracking","type":"app"},{"content":"","date":"2025-12-28","externalUrl":null,"permalink":"/tags/radar-systems/","section":"Tags","summary":"","title":"Radar Systems","type":"tags"},{"content":" Embedded real-time systems demand deterministic behavior, long-term stability, and efficient resource usage. VxWorks, Wind River’s real-time operating system, has long met these requirements across aerospace, defense, and industrial control systems. When paired with a capable ARM processor such as Atmel’s AT91RM9200, it forms a solid foundation for low-power, high-reliability embedded platforms.\nThis article presents a practical design walkthrough based on an industrial deployment by Nanjing Electric Research Power Automation Co., where an AT91RM9200-based VxWorks system was successfully applied to substation automation and power management products.\n🔧 Why AT91RM9200 and VxWorks? # The AT91RM9200 is a 32-bit ARM9-based RISC microcontroller built around the ARM920T core. Running at up to 180 MHz and delivering roughly 200 MIPS, it balances performance with power efficiency—an essential trait for industrial and field-deployed equipment.\nKey features include:\n32-bit external bus supporting SDRAM, Flash, and peripheral expansion Rich I/O set: USART, SSC, SPI, I²C, USB, and Ethernet Peripheral Data Controller (PDC) for DMA-style transfers Integrated USB 2.0 host and 10/100 Mb Ethernet MAC Very low power consumption in both active and standby modes VxWorks complements this hardware with a compact, microkernel-based RTOS architecture. It supports:\nPreemptive priority scheduling and round-robin scheduling Deterministic interrupt and task latency Robust inter-task communication and synchronization Extremely small kernel footprint (as low as a few kilobytes) The combination was chosen for products such as NSA3000 substation automation systems and NSA6000 power load management platforms, where reliability and real-time response are critical.\n🧱 Hardware Architecture Overview # The hardware platform is centered on the AT91RM9200 and includes:\nSDRAM for runtime memory Flash for bootloader and OS storage Analog-to-digital sampling interfaces Serial ports for console and device communication USB and Ethernet interfaces for external connectivity Real-time clock and power management circuitry External crystal oscillators and expansion buses This configuration supports continuous data acquisition, control processing, and network communication while maintaining low cost and power consumption—ideal for power system automation.\n🛠️ Development Environment with Tornado # VxWorks development is performed using the Tornado integrated environment, which provides a complete toolchain for embedded RTOS work.\nKey components include:\nVxSim for simulation Shell for non-kernel execution and diagnostics Browser for memory and object inspection WindView for event tracing and timing analysis Debugger for source-level debugging For the AT91RM9200, which is an ARM9 little-endian processor, the ARMARCH4gnu toolchain is selected. Tornado manages project creation, compilation, linking, image download, and debugging, significantly reducing development friction.\n🚀 Boot Process and System Startup # A predictable boot sequence is essential for real-time systems. The VxWorks startup flow on AT91RM9200 follows a well-defined progression:\nromInit()\nExecutes immediately after reset, disables interrupts, and initializes basic hardware and SDRAM.\nromStart()\nCopies program code and initialized data from Flash into SDRAM.\nsysInit()\nClears the BSS segment and invokes sysHwInit() for board-level hardware initialization.\nkernelInit()\nStarts the VxWorks kernel and core services.\nusrRoot()\nPerforms higher-level initialization, including I/O systems, networking, and application startup.\nThis sequence ensures that hardware is fully prepared before multitasking begins.\n🔌 Driver Development and BSP Integration # In VxWorks, applications access hardware through device drivers integrated into the Board Support Package (BSP). The BSP is responsible for:\nHardware initialization Interrupt vector configuration Exposing hardware services to the OS Drivers may operate in polling or interrupt-driven modes. Interrupt service routines are kept minimal to avoid latency and deadlock risks.\nExamples from the implementation include:\nFlash Driver\nSupports erase, read, write, and reset operations for SST39VF6401B devices and integrates with the TrueFFS file system.\nSerial Driver\nManages transmit and receive buffers, defines console ports, and configures baud rates via BSP settings.\nEthernet Driver\nInitializes the on-chip EMAC, performs PHY auto-negotiation, handles frame transmission and reception, and supports multicast traffic.\n⏱️ Task Scheduling and System Control # The runtime system uses a root task to coordinate all application tasks. Scheduling is based on:\nPriority preemption, where higher-priority tasks can interrupt lower-priority ones Round-robin scheduling among tasks of equal priority In the absence of a hardware watchdog, a software watchdog mechanism is implemented to detect stalled tasks and recover from abnormal conditions. Task priorities are assigned according to real-time urgency, ensuring fast response for time-critical power system operations.\n🧩 Deployment Results and Practical Value # The AT91RM9200-based VxWorks platform demonstrated:\nStable long-term operation Efficient use of CPU and memory resources Predictable real-time performance Scalability across multiple industrial products Its successful deployment in NSA3000 and NSA6000 systems confirms the suitability of this architecture for substation automation and power management applications.\n🏁 Final Thoughts # This design illustrates how combining an ARM9 processor with VxWorks yields a reliable, low-power, and scalable embedded real-time system. By carefully integrating hardware design, boot sequencing, BSP development, and task scheduling, the platform meets the stringent demands of industrial automation.\nFor engineers working on ARM-based RTOS platforms, this approach provides a proven reference for building deterministic and maintainable embedded systems using VxWorks.\n","date":"2025-12-28","externalUrl":null,"permalink":"/bsp/building-an-arm-based-vxworks-rtos-on-at91rm9200/","section":"Bsps","summary":"\u003c!--# Building an ARM-Based VxWorks RTOS on AT91RM9200--\u003e\n\u003cp\u003eEmbedded real-time systems demand deterministic behavior, long-term stability, and efficient resource usage. \u003cstrong\u003eVxWorks\u003c/strong\u003e, Wind River’s real-time operating system, has long met these requirements across aerospace, defense, and industrial control systems. When paired with a capable ARM processor such as \u003cstrong\u003eAtmel’s AT91RM9200\u003c/strong\u003e, it forms a solid foundation for low-power, high-reliability embedded platforms.\u003c/p\u003e","title":"Building an ARM-Based VxWorks RTOS on AT91RM9200","type":"bsp"},{"content":"","date":"2025-12-28","externalUrl":null,"permalink":"/tags/hdlc/","section":"Tags","summary":"","title":"HDLC","type":"tags"},{"content":" Modern media gateways form the backbone of telecommunications infrastructure, bridging voice, data, and signaling across heterogeneous subsystems. Ensuring reliable, deterministic communication between these subsystems is a core design challenge, particularly in real-time environments.\nThis article examines a practical implementation of the HDLC (High-Level Data Link Control) protocol on the MPC8260 PowerQUICC II processor running VxWorks, based on an industrial research deployment by Dalian Huanyu Mobile Technology Co. The solution demonstrates how hardware-assisted communication, paired with a real-time operating system, can deliver robust inter-system connectivity in telecom-grade equipment.\n🔗 Why HDLC in Media Gateway Architectures # A typical media gateway consists of a master control system connected to multiple functional subsystems, such as:\nCircuit and optical relays Circuit switching modules Conference bridges Vocoders and signal processors These subsystems must exchange control, management, and payload data efficiently. The research identifies HDLC as a strong fit due to its simplicity, scalability, and low operational overhead—key advantages in embedded telecom systems.\nHDLC is a bit-oriented data link layer protocol that transmits information in structured frames. Each frame includes:\nAddress field for destination identification Control field defining frame type and sequencing Variable-length payload (byte-aligned) CRC checksum for error detection Frame boundaries are marked by unique bit patterns, enabling reliable synchronization, flow control, and timing management. This makes HDLC particularly suitable for point-to-multipoint bus topologies, where a master node communicates with multiple subordinate devices.\n⚡ VxWorks as the Real-Time Foundation # The master control system runs VxWorks, Wind River’s real-time operating system widely used in telecom, aerospace, and defense systems.\nVxWorks provides:\nA compact, deterministic microkernel Multitasking and inter-task communication High-performance I/O and networking stacks Customizable device driver and BSP infrastructure Development and debugging are supported through the Tornado environment, which connects host-based tools to target agents over Ethernet. This setup enables live inspection of tasks, memory, and I/O behavior—essential for validating real-time communication paths.\nIn the HDLC implementation, VxWorks is responsible for scheduling, interrupt handling, and protocol processing, ensuring predictable latency for voice and signaling traffic.\n🧠 MPC8260 PowerQUICC II: Communication-Centric Hardware # The MPC8260 is a PowerPC-based embedded processor designed specifically for networking and telecom applications. Its defining feature is the Communications Processor Module (CPM), which offloads communication-intensive tasks from the main CPU.\nKey architectural elements include:\nPowerPC core for application and control logic CPM for peripheral and protocol processing Support for FCC, MCC, SCC, and SMC controllers The Multi-Channel Controller (MCC) is central to this design. When configured in HDLC mode, it supports multiple independent communication channels with minimal CPU involvement. This division of labor allows the PowerPC core to focus on system control while the CPM handles frame transmission, reception, and low-level protocol mechanics.\n🛠️ System Implementation Details # In the deployed media gateway, the master system uses the MPC8260’s MCC to implement HDLC over a shared backplane bus. The configuration operates in normal response mode with a point-to-multipoint topology.\nOperational characteristics include:\nThe master polls subsystems using unique 8-bit HDLC addresses Subsystems receive frames only when their address matches Responses are sent using fixed return addresses Subsystems return to idle after completing a transaction Software Stack Architecture # The software is structured in clear layers:\nApplication Layer\nHandles service-specific data such as voice, control, or signaling information\nHDLC Protocol Layer\nEncapsulates, parses, and validates HDLC frames\nVxWorks OS and HDLC BSP\nManages MCC configuration, interrupt handling, and frame buffering via message passing\nHardware Layer\nImplements the physical backplane and signaling\nError Control Strategy # Different traffic types impose different reliability requirements:\nVoice traffic prioritizes low latency and tolerates occasional frame loss Data traffic relies on application-level error handling Signaling traffic requires strict reliability at the data link layer To support this, the system implements a go-back-N retransmission mechanism, leveraging HDLC’s Poll/Final (P/F) bit to detect errors and coordinate recovery between master and subsystems.\n📊 Deployment Results and Practical Impact # The completed system allows operators to monitor, configure, and manage all HDLC-connected subsystems through Ethernet access to the master controller. Extensive testing demonstrated stable operation and consistent performance under real-world conditions.\nThis design has been successfully commercialized in CDMA2000 1x mobile communication systems, validating its reliability and scalability. The architecture is well suited for broader adoption in embedded telecom platforms requiring deterministic, low-overhead interconnects.\n🧩 Final Thoughts # This implementation highlights the effectiveness of combining:\nHDLC for structured, reliable data link communication MPC8260 hardware acceleration for efficient protocol handling VxWorks for deterministic real-time system control Together, they form a proven blueprint for building scalable and maintainable inter-system communication in media gateways and similar embedded telecom systems. For engineers working in real-time communications, it reinforces the value of aligning protocol design, hardware capabilities, and RTOS architecture from the outset.\n","date":"2025-12-28","externalUrl":null,"permalink":"/app/implementing-hdlc-on-mpc8260-with-vxworks-for-media-gateways/","section":"Apps","summary":"\u003c!--# Implementing HDLC on MPC8260 with VxWorks for Media Gateways--\u003e\n\u003cp\u003eModern media gateways form the backbone of telecommunications infrastructure, bridging voice, data, and signaling across heterogeneous subsystems. Ensuring reliable, deterministic communication between these subsystems is a core design challenge, particularly in real-time environments.\u003c/p\u003e","title":"Implementing HDLC on MPC8260 with VxWorks for Media Gateways","type":"app"},{"content":" 🔌 Overview # Embedded platforms such as industrial controllers and communication gateways often outgrow the limited UARTs provided by on-chip peripherals. A 2011 paper documents a practical VxWorks device driver for the XR16L788 dual serial port chip. By integrating two XR16L788 devices with a Samsung S3C2410 ARM processor, the system expands to 16 reliable serial ports.\nAlthough the work targets legacy ARM9 hardware, its driver architecture and implementation strategy remain directly applicable to modern VxWorks serial driver development.\n🧱 VxWorks Serial Driver Model # VxWorks classifies serial ports as character devices managed through the I/O system. Applications interact with UARTs via standard APIs, while hardware details are encapsulated inside the driver.\nThe driver exposes a standard SIO (Serial I/O) interface, enabling:\nHardware-independent access Dynamic driver loading Clean separation between application and hardware logic This modular model allows serial drivers to evolve without kernel recompilation.\n🧩 Hardware Configuration # The reference design consists of:\nCPU: Samsung S3C2410 (ARM9) UART expansion: Two Exar XR16L788 chips Total UARTs: 16 serial channels Each XR16L788 provides eight high-speed UARTs with 64-byte TX/RX FIFOs and supports shared interrupts. The chips connect to the CPU via memory-mapped registers, minimizing additional glue logic.\n🛠️ Driver Data Structures # The driver adopts a two-level structure: one for the device and one for each UART channel.\n#define MAX_XR16788_DEVS 2 // Number of XR16L788 devices #define MAX_XR16788_CHANS 8 // Channels per device typedef struct XR16L788_DEV { int devNum; // Device index (0,1...) int devRegBase; // Base register address int oscFreq; // Input clock frequency int intNum; // CPU interrupt number int intMask; // Interrupt mask char *devNamePrefix; // Device name prefix void *pChanArray; // Array of channels } XR16L788_DEV; typedef struct XR16L788_CHAN { SIO_CHAN sio; // System SIO struct STATUS (*getTxChar)(); // TX callback STATUS (*putRcvChar)(); // RX callback void *getTxArg; void *putRcvArg; int chNum; // Channel index int chRegBase; // Channel register base int baudRate; // Baud rate int options; // Feature flags int mode; // Interrupt or poll mode XR_CH_REG *pXrChReg; // Channel registers struct XR16L788_DEV *pXrDev; // Parent device } XR16L788_CHAN; This layout cleanly separates shared device resources from per-channel state, simplifying scaling and maintenance.\n⚙️ Hardware Initialization # Initialization is split into two phases. The first configures chip-level signals and timing, while the second initializes individual channels.\nvoid sysSerialHwInit_16788(void) { xr16788Init(); // Init chip signals and timing for (devNum = 0; devNum \u0026lt; MAX_XR16788_DEVS; devNum++) { pDev = \u0026amp;xr16788Dev[devNum]; pDev-\u0026gt;pChanArray = \u0026amp;xr16788Chan[devNum]; if (ERROR == xrInitDev(pDev)) continue; for (chanNum = 0; chanNum \u0026lt; MAX_XR16788_CHANS; chanNum++) { pChan = \u0026amp;xr16788Chan[devNum][chanNum]; xrInitChan(pChan); // Channel-specific init } } } A second-stage routine connects interrupts and registers the channels with the VxWorks I/O system.\n⚡ Interrupt Handling # All UART channels on a device share a single interrupt. The ISR reads the interrupt identification register and dispatches processing accordingly.\nvoid xr16788Int(XR16L788_DEV *pDev) { UINT8 iir = XR_READ(pDev, IIR); if (iir \u0026amp; XR_IIR_NO_INT) return; switch (iir \u0026amp; XR_IIR_ID_MASK) { case XR_IIR_RX_RDY: xrRxInt(pDev-\u0026gt;pChanArray[i]); break; case XR_IIR_TX_RDY: xrTxInt(pDev-\u0026gt;pChanArray[i]); break; } } This centralized interrupt strategy reduces overhead while maintaining deterministic response times.\n🔄 SIO Operations and Baud Configuration # The driver implements standard SIO callbacks, including open, close, read, write, and ioctl operations. Baud rate configuration follows the classic UART divisor model.\nSTATUS xr16788Ioctl(XR16L788_CHAN *pChan, int request, void *arg) { switch (request) { case SIO_BAUD_SET: baud = *(int *)arg; divisor = pChan-\u0026gt;pXrDev-\u0026gt;oscFreq / (16 * baud); // Program DLL/DLM via DLAB break; } return OK; } Strict compliance with the SIO interface ensures compatibility with existing VxWorks applications.\n🧪 Validation Results # Testing confirmed stable full-duplex communication across all 16 ports at multiple baud rates, including long-duration stress tests. No data loss or interrupt anomalies were observed, validating the design for real-time use.\n📌 Relevance in 2025 # While the XR16L788 and S3C2410 are now considered legacy components, the driver structure, interrupt model, and SIO integration remain directly applicable to newer UART expansion chips and VxWorks 7-based systems. For engineers extending serial I/O on ARM, FPGA, or PCIe platforms, this design remains a solid reference implementation.\n","date":"2025-12-27","externalUrl":null,"permalink":"/bsp/developing-a-dual-serial-port-driver-for-vxworks-using-xr16l788/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003e🔌 Overview \n    \u003cdiv id=\"-overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eEmbedded platforms such as industrial controllers and communication gateways often outgrow the limited UARTs provided by on-chip peripherals. A 2011 paper documents a practical VxWorks device driver for the XR16L788 dual serial port chip. By integrating two XR16L788 devices with a Samsung S3C2410 ARM processor, the system expands to 16 reliable serial ports.\u003c/p\u003e","title":"Developing a Dual Serial Port Driver for VxWorks Using XR16L788","type":"bsp"},{"content":" 🚀 Overview # In real-time embedded systems, network performance can be the difference between deterministic behavior and system failure. A 2016 study by researchers from the Harbin Institute of Technology applied classical queueing theory to analyze the VxWorks network subsystem, modeling it as an M/M/1 queue. By deriving analytical expressions for delay, throughput, and packet loss, the work provides a lightweight yet powerful framework for predicting network behavior under load. Although published nearly a decade ago, this approach remains valuable in 2025 for tuning VxWorks-based systems in edge AI, industrial control, and 5G-enabled devices.\n🌐 Why Network Performance Modeling Matters in VxWorks # VxWorks is designed for deterministic task scheduling, but its networking stack must still cope with bursty traffic, interrupt overhead, and finite processing capacity. In high-load scenarios—such as satellite links, industrial automation, or distributed control—network delays can grow rapidly and violate real-time constraints.\nPurely empirical testing is costly and difficult to generalize. Mathematical modeling offers a complementary approach by allowing engineers to predict system behavior before deployment. Queueing theory, in particular, captures the stochastic nature of packet arrivals and processing times with relatively simple models.\n📐 Applying the M/M/1 Queue Model # The authors model the VxWorks network subsystem as a single-server queue:\nArrival process (λ): Packet arrivals follow a Poisson distribution. Service process (μ): Packet processing times are exponentially distributed. Queue discipline: First-come, first-served (FCFS). Capacity: Effectively infinite buffering. Stability condition: System utilization ρ = λ / μ must remain below 1. Under these assumptions, the steady-state probability of having n packets in the system is: $$ Pₙ = (1 − ρ)ρⁿ $$ This abstraction treats the network stack as a shared service point handling interrupts, protocol processing, and data forwarding—sufficiently accurate for high-level performance analysis.\n🧮 Key Performance Metrics # From the M/M/1 model, several critical metrics are derived:\nAverage queue length:\n$$ Lq = ρ² / (1 − ρ) $$ Average number of packets in the system:\n$$ L = ρ / (1 − ρ) $$ Average queueing delay:\n$$ Wq = ρ / [μ(1 − ρ)] $$ Average end-to-end delay:\n$$ W = 1 / [μ(1 − ρ)] $$ Using Little’s Law (L = λW), the paper further decomposes delay into fixed processing components and load-dependent queueing components. This refinement better reflects the multi-stage nature of the VxWorks network stack, including protocol handling at different layers. ⚙️ Insights for VxWorks Optimization # The analytical results highlight several practical tuning strategies:\nAvoid high utilization: As ρ approaches 1, delay increases exponentially. Operating near saturation is risky for real-time systems. Increase service rate (μ): Faster CPUs, optimized drivers, or offloading can significantly reduce delay. Control arrival rate (λ): Traffic shaping and rate limiting help prevent burst-induced congestion. Capacity planning: The model provides quantitative guidance on safe operating regions for network load. The study suggests that moderate utilization levels (for example, ρ around 0.5) often strike a good balance between throughput and latency.\n🔮 Relevance in 2025 # Modern VxWorks deployments increasingly support AI inference, 5G connectivity, and edge computing workloads, all of which place heavier demands on networking subsystems. While tools and stacks have evolved, the fundamental relationship between arrival rate, service capacity, and delay remains unchanged.\nThis 2016 queueing-theory-based analysis continues to serve as a solid conceptual foundation for RTOS network performance engineering, offering engineers a clear, quantitative way to reason about system limits before problems appear in the field.\nHave you used analytical models to tune real-time networking? They remain one of the most cost-effective tools in an embedded engineer’s toolbox.\n","date":"2025-12-27","externalUrl":null,"permalink":"/app/modeling-and-analyzing-network-performance-in-vxworks-with-queueing-theory/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003e🚀 Overview \n    \u003cdiv id=\"-overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn real-time embedded systems, network performance can be the difference between deterministic behavior and system failure. A 2016 study by researchers from the Harbin Institute of Technology applied classical queueing theory to analyze the VxWorks network subsystem, modeling it as an M/M/1 queue. By deriving analytical expressions for delay, throughput, and packet loss, the work provides a lightweight yet powerful framework for predicting network behavior under load. Although published nearly a decade ago, this approach remains valuable in 2025 for tuning VxWorks-based systems in edge AI, industrial control, and 5G-enabled devices.\u003c/p\u003e","title":"Modeling and Analyzing Network Performance in VxWorks with Queueing Theory","type":"app"},{"content":"","date":"2025-12-27","externalUrl":null,"permalink":"/tags/performance-analysis/","section":"Tags","summary":"","title":"Performance Analysis","type":"tags"},{"content":"","date":"2025-12-27","externalUrl":null,"permalink":"/tags/rtos-networking/","section":"Tags","summary":"","title":"RTOS Networking","type":"tags"},{"content":" 🚀 Overview # Booting VxWorks directly from NAND Flash offers a practical way to reduce hardware cost and board complexity in embedded systems. A 2018 study demonstrated a NAND-only boot design on Samsung’s S3C2440 ARM9 processor, using its built-in 4KB “stepping stone” SRAM. By eliminating NOR Flash entirely, the design simplified hardware while maintaining reliable system startup—an approach still relevant in 2025 for legacy ARM9 platforms and cost-sensitive products.\n💡 Why Choose NAND Boot for VxWorks? # VxWorks is widely used in communications, aerospace, and industrial systems due to its deterministic scheduling and efficient resource management. Traditionally, VxWorks boots from NOR Flash because NOR supports execute-in-place (XIP). However, NOR Flash has clear drawbacks:\nLow storage density Higher cost per bit Larger board footprint NAND Flash, by contrast, offers higher capacity at lower cost, but it cannot execute code directly. The S3C2440 addresses this limitation with a hardware-assisted mechanism: on power-up, the processor automatically copies the first 4KB of NAND Flash into internal SRAM (the “stepping stone”) and executes from there. This makes NAND-only booting feasible without external NOR Flash.\n🧠 Understanding the VxWorks Boot Flow # A standard VxWorks boot sequence involves several stages:\nromInit (Assembly)\nDisables interrupts, sets up the stack, initializes CPU registers, and jumps to C code. romStart (C)\nCopies the compressed VxWorks image to RAM, decompresses it, and transfers control to system initialization. sysInit / usrInit\nInitializes hardware, kernel objects, and user applications before launching the shell. For NAND boot on S3C2440, this flow must be adapted. The first 4KB of code—executed from stepping stone SRAM—must initialize SDRAM and NAND access, load the full boot image into external RAM, and then continue with the normal VxWorks startup process.\n🧩 Hardware Platform Overview # The experimental setup described in the study included:\nCPU: Samsung S3C2440 (ARM920T, up to 400 MHz, 4KB internal SRAM) NAND Flash: Samsung K9F2G08U0B (256 MB, page/block architecture) SDRAM: 64 MB external memory for runtime execution Ethernet: DM9000 controller for networking and debugging On reset, the S3C2440 hardware copies the first 4KB of NAND Flash into internal SRAM and begins execution, enabling a compact first-stage bootloader.\n🔧 NAND-Based Boot Sequence Design # The complete boot process is divided into three stages:\nStepping Stone Bootloader (4KB)\nInitializes NAND controller Sets up minimal SDRAM configuration Loads the remaining bootloader from NAND into SDRAM Full Bootloader in SDRAM\nCompletes SDRAM initialization Copies the VxWorks image from NAND to RAM Jumps to the VxWorks entry point VxWorks Runtime Execution\nKernel and applications run entirely from SDRAM Key low-level routines handle NAND page reads, bad block skipping, and basic error correction, all while respecting the tight 4KB size limit of the initial stage.\n🛠️ BSP Modifications and Build Process # To support NAND booting, the VxWorks Board Support Package (BSP) was modified:\nAdded NAND and SDRAM initialization code in romInit.s Adjusted memory layout to match NAND Flash organization Ensured all first-stage code fit within the 4KB stepping stone limit The boot image was compiled using standard VxWorks toolchains and programmed into NAND Flash via JTAG. Careful handling of NAND-specific issues—such as bad blocks and bit errors—was essential for reliable startup.\n📊 Results and Practical Benefits # Testing on the prototype board showed consistent and stable boot behavior:\nVxWorks shell available within a few seconds Full networking and task scheduling operational Approximately 20% hardware cost reduction compared to designs using both NOR and NAND Smaller board size due to fewer components This approach proved especially suitable for handheld devices, communication terminals, and other space- and cost-constrained products.\n🔮 Relevance in 2025 # Although the S3C2440 is now a legacy processor, the underlying principles remain valuable. Modern systems boot from NAND-derived storage such as eMMC or UFS using similar multi-stage loaders. VxWorks 7 and newer releases continue to support flexible, RAM-based boot mechanisms inspired by these earlier designs.\nFor engineers maintaining legacy ARM9 systems—or designing ultra-low-cost embedded platforms—this NAND-only boot strategy remains a practical and instructive reference.\n","date":"2025-12-27","externalUrl":null,"permalink":"/bsp/booting-vxworks-from-nand-flash-on-s3c2440-arm9/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003e🚀 Overview \n    \u003cdiv id=\"-overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eBooting VxWorks directly from NAND Flash offers a practical way to reduce hardware cost and board complexity in embedded systems. A 2018 study demonstrated a NAND-only boot design on Samsung’s S3C2440 ARM9 processor, using its built-in 4KB “stepping stone” SRAM. By eliminating NOR Flash entirely, the design simplified hardware while maintaining reliable system startup—an approach still relevant in 2025 for legacy ARM9 platforms and cost-sensitive products.\u003c/p\u003e","title":"Booting VxWorks from NAND Flash on S3C2440 ARM9","type":"bsp"},{"content":"","date":"2025-12-27","externalUrl":null,"permalink":"/tags/embedded-boot/","section":"Tags","summary":"","title":"Embedded Boot","type":"tags"},{"content":"","date":"2025-12-27","externalUrl":null,"permalink":"/tags/nand-flash/","section":"Tags","summary":"","title":"NAND Flash","type":"tags"},{"content":" ⚡ Overview # In modern smart grids and digital substations, IEC 61850 defines a standardized framework for high-speed, deterministic communication between Intelligent Electronic Devices (IEDs). Two of its most time-critical services—Sampled Values (SV) and Generic Object-Oriented Substation Events (GOOSE)—are collectively known as Fast Message Transmission Services (FMTS). These services operate directly at the Ethernet data link layer and demand strict real-time behavior.\nA 2008 study by Dou Xiaobo et al. from Southeast University examined how FMTS can be implemented on VxWorks, Wind River’s widely deployed real-time operating system. The research highlights limitations of VxWorks’ default TCP/IP-centric networking model and introduces a Fast Communication Interface (FCI) to enable direct Ethernet access. This article rewrites and distills the paper’s core ideas for embedded and power-system engineers.\n🔌 Why FMTS Is Challenging on VxWorks # VxWorks is popular in power-system IEDs due to its:\nDeterministic, preemptive scheduler Low interrupt latency and fast context switching Modular and scalable kernel design However, its standard networking stack is optimized for TCP/IP socket-based communication, which introduces unnecessary overhead for FMTS. IEC 61850 explicitly maps SV and GOOSE services directly to Layer 2 Ethernet, bypassing transport and network layers altogether.\nFMTS encompasses several services, including multicast and unicast SV, GOOSE send/read, and GSSE variants. In practice, the study focuses on two representative cases:\nSV Multicast (SMM) – continuous transmission of sampled measurement data GOOSE Send (SGM) – rapid event notification with retransmission Both rely on multicast or broadcast Ethernet frames, ASN.1/BER encoding, and strict validation rules.\n🧩 FMTS Communication Model # Abstract Communication Service Interface (ACSI) # The ACSI defines IEC 61850 services independently of operating systems and protocols. FMTS uses a publisher/subscriber model:\nPublishers acquire data, encode it, and multicast frames Subscribers receive, validate, and refresh internal buffers Key differences between SV and GOOSE include:\nSV: Fixed sampling intervals, no retransmission, validation via sample counters GOOSE: Flexible datasets, cyclic transmission with rapid bursts on state changes, validation via state and sequence numbers In both cases, publishers construct APDUs/ASDUs, while subscribers perform integrity and freshness checks.\nSpecific Communication Service Mapping (SCSM) # The SCSM maps ACSI services to concrete protocols. For FMTS, this mapping is a direct Ethernet binding:\nSV → Sampled Value (SAV) frames (IEC 61850-9-1, based on IEC 60044-8) GOOSE → GOOSE Protocol Data Units This design eliminates higher-layer latency but requires explicit access to the data link layer.\n🛠️ Fast Message Implementation on VxWorks # VxWorks follows an OSI-inspired architecture but introduces a Multiplexing Interface (MUX) between network drivers and upper-layer protocols. Normally, applications interact through sockets, but FMTS requires bypassing this path.\nFast Communication Interface (FCI) # The proposed FCI provides a controlled bridge between application tasks and the MUX layer. It consists of application-facing APIs and MUX callbacks:\nfciOpen – Registers the FCI with the MUX using muxBind, specifying callbacks, protocol identifiers, and device context fciMCastAddrSet – Configures multicast MAC addresses fciSend – Transmits raw Ethernet frames containing FMTS APDUs On the receive side, MUX callbacks copy and parse frames, then notify application tasks via VxWorks semaphores. This approach enables deterministic, TCP/IP-free Ethernet communication.\nApplication Task Structure # Publisher tasks\nTriggered by sampling interrupts Collect and buffer measurements Encode datasets into APDUs Queue frames in FIFO buffers and send via FCI Subscriber tasks\nValidate incoming frames (sample counters or sequence/state numbers) Update datasets and application buffers Task priorities and synchronization primitives are carefully chosen to minimize latency.\n⏱️ Real-Time Processing Considerations # Meeting IEC 61850 timing constraints—often in the microsecond to millisecond range—requires disciplined RTOS design:\nAssign highest priorities to FMTS-related tasks Use interrupt-driven data acquisition Minimize copying via FIFO queues Synchronize with lightweight semaphores By avoiding the TCP/IP stack and operating directly at Layer 2, the FCI-based design achieves predictable timing.\n🧪 Validation and Performance Results # The study evaluated the implementation using a VxWorks-based IED emulator connected through an Ethernet switch:\nGOOSE round-trip latency: ~1 ms on average IEC 61850 requirement: ≤ 4 ms for critical protection events Stability test: 72 hours at 100 Hz with no frame loss These results confirm that the proposed approach satisfies both performance and reliability requirements.\n🌍 Ongoing Relevance # Although published in 2008, this work remains highly relevant. IEC 61850 continues to evolve, and VxWorks is still widely deployed in utility automation. The paper provides a clear blueprint for implementing non-IP, real-time protocols on an RTOS by selectively bypassing conventional networking stacks.\nThe same principles apply today to industrial Ethernet, time-sensitive networking (TSN), and even real-time IoT systems—especially when deterministic behavior matters more than protocol generality.\nFor engineers working with IEC 61850 or real-time Ethernet: approaches like this remain essential for achieving true end-to-end determinism.\n","date":"2025-12-22","externalUrl":null,"permalink":"/app/iec-61850-fast-messaging-on-vxworks/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003e⚡ Overview \n    \u003cdiv id=\"-overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn modern smart grids and digital substations, \u003cstrong\u003eIEC 61850\u003c/strong\u003e defines a standardized framework for high-speed, deterministic communication between Intelligent Electronic Devices (IEDs). Two of its most time-critical services—\u003cstrong\u003eSampled Values (SV)\u003c/strong\u003e and \u003cstrong\u003eGeneric Object-Oriented Substation Events (GOOSE)\u003c/strong\u003e—are collectively known as \u003cstrong\u003eFast Message Transmission Services (FMTS)\u003c/strong\u003e. These services operate directly at the Ethernet data link layer and demand strict real-time behavior.\u003c/p\u003e","title":"IEC 61850 Fast Messaging on VxWorks","type":"app"},{"content":"","date":"2025-12-22","externalUrl":null,"permalink":"/tags/real-time-networking/","section":"Tags","summary":"","title":"Real-Time Networking","type":"tags"},{"content":"","date":"2025-12-22","externalUrl":null,"permalink":"/tags/smart-grid/","section":"Tags","summary":"","title":"Smart Grid","type":"tags"},{"content":"","date":"2025-12-21","externalUrl":null,"permalink":"/tags/migration/","section":"Tags","summary":"","title":"Migration","type":"tags"},{"content":"","date":"2025-12-21","externalUrl":null,"permalink":"/tags/porting/","section":"Tags","summary":"","title":"Porting","type":"tags"},{"content":" Porting legacy VxWorks 6.9 BSPs to VxWorks 7 involves handling substantial structural changes, updating directory hierarchies, and migrating VxBus drivers. This guide provides a detailed, expert-level roadmap to ensure full compatibility while leveraging VxWorks 7 features.\n🛠 Why Porting is Necessary # VxWorks 7 introduces critical improvements over version 6.9.x:\nModern VxBus Infrastructure: Replaces hard-coded device info with dynamic device probing. New Directory Structure: BSPs and drivers follow a reorganized hierarchy, requiring updates to include paths. Component Separation: Processor-specific and board-specific elements are decoupled, improving modularity and maintainability. Porting ensures BSPs remain compatible, maintainable, and ready for long-term development.\n📁 Source Tree Changes # Category VxWorks 6.9.3.x VxWorks 7 BSP Location target/config pkgs/os/board/bsp_legacy-6.9.0.0/ Driver Source target/src/hwif pkgs/os/drv/vxbus_legacy-version_string/src Driver Header target/h/hwif/ target/src/hwif/h/ or pkgs/os/drv/vxbus_legacy-version_string/h/ Driver Support Files target/config/comps/vxWorks pkgs/os/drv/vxbus_legacy-version_string/cdf/ version_string refers to the vxbus_legacy package version, e.g., 1.0.0.0 for initial release, higher for updates (e.g., 1.0.0.3).\n✅ Pre-Porting Checklist # Ensure BSP builds and boots in VxWorks 6.9.3.3. Backup all BSP source, header, and driver files. Familiarize with Workbench 4 and WrTool for migration. Identify all legacy VxBus drivers to be ported. 🔄 Porting Workflow Overview # Perform all actions within VxWorks Development Shell or Workbench 4:\nVerify legacy BSP builds. Copy BSP to VxWorks 7 workspace: cp -r legacyBSPPath yourVx7Workspace Modify Makefile and 20bsp.cdf. Update source include paths. Copy legacy drivers to appropriate vxbus_legacy directories. Build VSB and create VIP using WrTool: vxprj vsb create -force -bsp bsp6x_fsl_p4080_ds_6_9_0_0 -compat69 myP4080VSB -S prj build myP4080VSB vxprj vip create -force -vsb myP4080VSB bsp6x_fsl_p4080_ds_6_9_0_0 diab myP4080VIP prj build myP4080VIP Note: Any BSP changes during VIP creation require recreating the VIP with -force.\n⚡ Example: Porting fsl_p4080_ds PPC BSP # Step 1: Verify Build Environment # Confirm BSP builds and boots in 6.9.3.3.\nStep 2: Set WIND_BSP_PATHS # Linux: Update .cshrc or .login Windows: Control Panel → Environment Variables → Add WIND_BSP_PATHS Step 3: Launch Workbench 4 # Open the Development Shell and WrTool terminal.\nStep 4: Copy BSP # cp -r legacyBSPPath yourVx7Workspace Step 5: Create bsp.vsbl # layer bsp6x_fsl_p4080_ds { SYNOPSIS A legacy fsl_p4080_ds BSP to be used in VxWorks 7 VERSION 6.9.3.3.p LAYER_REQUIRES VXBUS_LEGACY LAYER_CONTENT compat69 } Step 6: Copy Required VxBus Drivers # Ensure all source, header, and support files are in the correct vxbus_legacy-version_string folders.\nStep 7: Verify BSP in VSB # vxprj vsb listBsps -compat69 Step 8: Edit Makefile # Set CPU to PPCE500MC or target CPU Comment out TGT_DIR Update include paths: include $(WIND_KRNL_MK)/defs.bsp.mk include $(WIND_KRNL_MK)/rules.bsp.mk Step 9: Update CDF Files # Move Bsp {} from 20bsp.cdf to a new bsp.cdf. Ensure the CPU matches Makefile.\nStep 10: Build VSB and VIP # vxprj vsb create -force -bsp bsp6x_fsl_p4080_ds_6_9_0_0 -compat69 myP4080VSB -S prj build myP4080VSB vxprj vip create -force -vsb myP4080VSB bsp6x_fsl_p4080_ds_6_9_0_0 diab myP4080VIP prj build myP4080VIP The resulting image is located at vxworks/workspace/myP4080VIP/default.\n📂 Driver Path Reference # Legacy Path (VxWorks 6.9.x) New Path (VxWorks 7) Purpose ../src/hwif/h/vxbus/vxbAccess.h vxbus/vxbAccess.h VxBus access macros ../src/hwif/h/vxbus/vxbRapidIO.h vxbus/vxbRapidIO.h RapidIO interface ../src/hwif/h/end/vxbDtsecEnd.h hwif/end/vxbDtsecEnd.h Ethernet controllers ../src/hwif/h/intCtlr/vxbIntDynaCtlrLib.h hwif/intCtlr/vxbIntDynaCtlrLib.h Interrupt controllers target/h/vme.h Local BSP directory (copy required) VME bus support target/src/drv/mem/flashMem.c Local BSP directory (copy required) Flash memory drivers 💡 Managing Local Source Files # Legacy internal files (e.g., flashMem.c, nvRamToFlash.c) are now locally scoped in VxWorks 7:\nCopy them into the migrated BSP folder: installDir/vxworks-7/pkgs/os/board/bsp_legacy-6.9.0.0/your_bsp/ Update #include to force local resolution: // Old #include \u0026lt;mem/flashMem.c\u0026gt; #include \u0026lt;mem/nvRamToFlash.c\u0026gt; // New #include \u0026#34;flashMem.c\u0026#34; #include \u0026#34;nvRamToFlash.c\u0026#34; 🏁 Best Practices # Port iteratively; resolve compilation errors progressively. Always use the latest vxbus_legacy version. Backup original BSPs. Validate VSB and VIP builds after each change. Document all modified paths and files. This guide ensures a complete, expert-level process for porting legacy VxWorks 6.9 BSPs to VxWorks 7 while maintaining reliability, compatibility, and VxBus support.\n","date":"2025-12-21","externalUrl":null,"permalink":"/bsp/porting-legacy-vxworks-6.9.3-bsps-to-vxworks-7-a-complete-guide/","section":"Bsps","summary":"\u003c!--# Porting Legacy VxWorks 6.9 BSPs to VxWorks 7--\u003e\n\u003cp\u003ePorting legacy VxWorks 6.9 BSPs to VxWorks 7 involves handling substantial structural changes, updating directory hierarchies, and migrating VxBus drivers. This guide provides a detailed, expert-level roadmap to ensure full compatibility while leveraging VxWorks 7 features.\u003c/p\u003e","title":"Porting Legacy VxWorks 6.9 BSPs to VxWorks 7","type":"bsp"},{"content":"","date":"2025-12-21","externalUrl":null,"permalink":"/tags/ppc/","section":"Tags","summary":"","title":"PPC","type":"tags"},{"content":" Exploring Embedded Multi-Core Communication: Insights from PowerPC P2020 and VxWorks\nAs embedded systems continue to evolve toward higher performance and stricter real-time guarantees, multi-core processors have become essential. A recent academic study examining the PowerPC P2020 dual-core processor running VxWorks 6.9 provides valuable, practice-oriented insights into how multi-core architectures can be effectively designed and optimized.\nThe work analyzes common multi-core execution models—AMP, SMP, and BMP—and presents an SMP-based system design validated through real-world experiments. This article distills those findings for embedded developers working on performance-critical systems.\n🧠 VxWorks and PowerPC P2020 in Multi-Core Designs # VxWorks is a modular real-time operating system known for deterministic scheduling and low interrupt latency. With the introduction of SMP support in VxWorks 6.9, the OS can dynamically schedule tasks across multiple cores while maintaining real-time guarantees.\nThe PowerPC P2020, developed by Freescale (now NXP), is a dual-core processor based on the e500v2 architecture, operating at up to 1.2 GHz. It integrates several hardware features critical for multi-core communication:\nDDR2/DDR3 memory for shared data access OpenPIC for interrupt routing and inter-processor interrupts (IPIs) DMA engines for high-throughput data movement without CPU intervention In a typical configuration, one core writes data to shared DDR memory (optionally via DMA) and signals the other core using an IPI. VxWorks SMP then handles task migration and load balancing transparently.\n🧩 Multi-Core Architecture Models: AMP, SMP, and BMP # The study compares three common multi-core software architectures:\nAsymmetric Multi-Processing (AMP) # Each core runs its own OS instance Communication via shared memory or message passing Strong fault isolation and predictable timing Lower overall resource utilization and higher communication latency AMP is well suited for safety-critical systems requiring strict isolation.\nSymmetric Multi-Processing (SMP) # A single OS instance shared by all cores Unified scheduler and shared address space High CPU utilization and low inter-core latency Cache coherence and fault containment require careful design SMP is ideal for compute-intensive workloads that benefit from dynamic load balancing.\nBound Multi-Processing (BMP) # Hybrid approach with partial resource sharing Balances isolation and efficiency Increased system complexity compared to AMP or SMP BMP is typically chosen when availability and performance must be balanced carefully.\n🏗️ Designing an SMP-Based System # The researchers selected SMP to maximize performance and simplify software management. Tasks were logically divided by function:\nCore 0: Control-oriented tasks (command handling, device management) Core 1: Data-intensive processing (filtering, compression, signal analysis) VxWorks manages task scheduling, migration, and synchronization across cores.\n🚀 Multi-Core Boot Process # The multi-core boot sequence involves tight coordination between hardware initialization and OS startup:\nClock and DDR initialization Dedicated memory regions per core, plus shared memory Core 0 boots first and releases Core 1 after kernel setup Synchronization using hardware semaphores, shared flags, and interrupts Kernel initialization completes in roughly hundreds of milliseconds, followed by application loading from external storage.\n⚙️ Task Scheduling Strategy # Among several scheduling strategies, the implementation uses a hybrid approach:\nTasks explicitly bound to a core remain fixed Unbound tasks are dynamically assigned to the least-loaded core This approach achieves effective load balancing while preserving determinism for critical tasks. Minor imbalances can still occur when task execution times vary significantly.\n🔄 Inter-Core Communication Mechanism # Inter-core communication is implemented using shared memory combined with IPIs:\nSender core acquires a mutex Data is written to shared memory and a status flag is set Mutex is released An IPI notifies the receiving core The receiver handles the interrupt, reads the data, clears the flag, and releases the lock. Measured communication latency is approximately 1–2 µs, suitable for high-frequency coordination.\n📊 Experimental Results # In a signal-processing application, the SMP configuration delivered substantial performance improvements:\nProcessing time reduced from 12.3 ms (single core) to 6.8 ms (dual core) CPU utilization exceeded 90% Task migration rate around 120 events per second Task switch overhead under 1 µs L2 cache hit rate near 95% Extended stability testing showed consistent performance with no deadlocks or starvation issues.\n🏁 Key Takeaways for Embedded Developers # This study demonstrates that SMP on PowerPC P2020 with VxWorks can deliver both high performance and real-time reliability when properly designed. Key lessons include:\nChoose AMP, SMP, or BMP based on isolation, performance, and complexity requirements Leverage hardware features like DMA and IPIs to minimize CPU overhead Combine static task binding with dynamic scheduling for balanced performance For embedded systems facing increasing computational demands, this architecture provides a proven blueprint for scalable, real-time multi-core communication.\n","date":"2025-12-21","externalUrl":null,"permalink":"/app/embedded-multi-core-communication-with-powerpc-p2020-and-vxworks/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eExploring Embedded Multi-Core Communication: Insights from PowerPC P2020 and VxWorks\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eAs embedded systems continue to evolve toward higher performance and stricter real-time guarantees, \u003cstrong\u003emulti-core processors\u003c/strong\u003e have become essential. A recent academic study examining the \u003cstrong\u003ePowerPC P2020 dual-core processor\u003c/strong\u003e running \u003cstrong\u003eVxWorks 6.9\u003c/strong\u003e provides valuable, practice-oriented insights into how multi-core architectures can be effectively designed and optimized.\u003c/p\u003e","title":"Embedded Multi-Core Communication with PowerPC P2020 and VxWorks","type":"app"},{"content":"","date":"2025-12-21","externalUrl":null,"permalink":"/tags/embedded-gui/","section":"Tags","summary":"","title":"Embedded GUI","type":"tags"},{"content":" 🚀 Overview # In embedded systems, combining hard real-time performance with modern graphical user interfaces has long been a challenge. In 2012, a strategic partnership between Wind River and Digia addressed this gap by extending Qt Commercial support to VxWorks, Wind River’s flagship real-time operating system (RTOS).\nThe collaboration enabled developers to deploy sophisticated, visually rich GUIs on systems that still required deterministic scheduling, low latency, and high reliability. Although Qt has since evolved under The Qt Company, the technical and commercial groundwork established by this partnership continues to influence embedded GUI development on VxWorks as of 2025.\n🤝 The Genesis of the Partnership # Announced in February 2012, the Wind River–Digia alliance responded to growing demand for cross-platform UI frameworks in embedded and safety-critical environments. Qt Commercial already had strong adoption on desktop and embedded Linux platforms, and extending official support to VxWorks allowed vendors to unify UI development across product lines.\nKey benefits delivered by the partnership included:\nSeamless Qt Commercial integration with VxWorks 6.9 and later Support for embedded hardware from Intel, Freescale (now NXP), and Texas Instruments Commercial licensing, professional support, and long-term maintenance Early releases were based on Qt Commercial 4.8.1 (beta), followed by stable versions such as Qt 4.8.3 later in 2012.\n🧩 Technical and Market Impact # The integration focused on making Qt practical for RTOS-based systems rather than general-purpose operating systems.\nFrom a technical perspective, Qt enabled:\nFaster GUI development through visual design tools and reusable components Hardware-accelerated graphics using OpenGL ES and OpenVG Predictable behavior suitable for real-time and safety-sensitive systems From a market standpoint, the partnership expanded VxWorks’ reach beyond traditional control applications. Aerospace and defense systems adopted more visual operator interfaces, medical devices benefited from animated diagnostic displays, and industrial automation platforms gained more intuitive HMIs. Industry coverage at the time highlighted the value of standardized GUI development in sectors where reliability and certification are critical.\n🔄 Evolution and Status in 2025 # Although Digia transferred Qt stewardship to The Qt Company in 2014, Qt support for VxWorks continued to mature. In 2015, Wind River announced support for Qt 5.5, bringing a more modular architecture and improved touch capabilities.\nBy 2025, Qt’s VxWorks support remains active and relevant:\nQt 6.8.1 supports VxWorks 24.03, released in December 2024 Subsequent updates added compatibility with VxWorks 25.03 Modern deployments rely on Qt Platform Abstraction (QPA) tailored for single-process RTOS environments Ongoing porting and integration efforts ensure that Qt keeps pace with VxWorks kernel and toolchain evolution.\n🌍 Why This Matters Today # As embedded systems adopt AI-assisted interfaces, Industry 4.0 architectures, and edge computing models, the need for deterministic yet user-friendly interfaces continues to grow. The original Wind River–Digia partnership demonstrated that a commercial GUI framework could coexist with a hard real-time RTOS.\nToday’s developers benefit from more than a decade of refinement, making Qt on VxWorks a proven solution for building reliable, differentiated embedded products where user experience and real-time guarantees must coexist.\n","date":"2025-12-21","externalUrl":null,"permalink":"/news/qt-commercial-support-for-vxworks-rtos/","section":"News","summary":"\u003ch2 class=\"relative group\"\u003e🚀 Overview \n    \u003cdiv id=\"-overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn embedded systems, combining \u003cstrong\u003ehard real-time performance\u003c/strong\u003e with \u003cstrong\u003emodern graphical user interfaces\u003c/strong\u003e has long been a challenge. In 2012, a strategic partnership between \u003cstrong\u003eWind River\u003c/strong\u003e and \u003cstrong\u003eDigia\u003c/strong\u003e addressed this gap by extending \u003cstrong\u003eQt Commercial\u003c/strong\u003e support to \u003cstrong\u003eVxWorks\u003c/strong\u003e, Wind River’s flagship real-time operating system (RTOS).\u003c/p\u003e","title":"Qt Commercial Support for VxWorks RTOS","type":"news"},{"content":" In the world of embedded systems, few operating systems carry the same weight as VxWorks. Developed by Wind River, this real-time operating system (RTOS) has become synonymous with mission-critical reliability, deterministic performance, and long-term operational stability.\nWhile VxWorks is widely used in automotive, industrial automation, and medical devices, its most iconic and demanding deployments are found in aerospace and defense. From Mars rovers navigating alien terrain to advanced aircraft executing split-second decisions, VxWorks underpins systems where failure is simply not an option.\nThis article explores why VxWorks dominates aerospace and defense, how it evolved to meet extreme requirements, and where it is deployed today.\n🕰️ A Brief History of VxWorks # VxWorks originated in the late 1980s as an evolution of the VRTX RTOS, initially focusing on small, tightly constrained embedded systems. Wind River steadily expanded its capabilities, adding file systems, networking, and development tooling.\nKey milestones include:\n1980s–1990s: 32-bit processor support and TCP/IP networking 2000s: Symmetric multiprocessing (SMP) and multicore scalability 2014: Introduction of VxWorks 7, emphasizing modularity, safety, and IoT readiness 2025: Continued evolution, with version 25.09 supporting modern multicore CPUs, virtualization, and advanced security models This steady, conservative evolution is precisely what makes VxWorks attractive for aerospace programs with decades-long lifecycles.\n🛡️ Why VxWorks Excels in Aerospace and Defense # Aerospace and defense platforms operate under extreme conditions—radiation exposure, vibration, thermal stress, and real-time decision constraints. VxWorks is engineered for exactly these scenarios.\nCore strengths include: # Deterministic Real-Time Behavior\nGuaranteed task scheduling and bounded interrupt latency for navigation, flight control, and sensor fusion.\nSafety and Security Certifications\nSupport for standards such as DO-178C (avionics) and ISO 26262, with features like memory partitioning, priority inheritance, secure boot, and cryptographic authentication (X.509, encryption).\nModular and Scalable Architecture\nA clean separation between kernel and middleware allows tailoring from minimal embedded targets to large multicore SoCs.\nRich Connectivity and Graphics\nNative support for IPv6, CAN, USB, and graphics APIs such as OpenGL and OpenVG for cockpit displays and mission systems.\nBuilt-in Virtualization\nA Type-1 hypervisor enables multiple isolated operating systems on the same hardware—critical for mixed-criticality avionics.\nThese capabilities make VxWorks a natural choice when systems must run predictably and continuously for years without human intervention.\n🚀 Iconic Applications in Space Exploration # NASA has relied on VxWorks for decades, making it one of the most proven operating systems beyond Earth.\nMars Rovers # VxWorks powers the core flight and mission software of multiple Mars rovers, including:\nPerseverance (Mars 2020 mission) Curiosity (Mars Science Laboratory) Spirit, Opportunity, and Sojourner These systems handle terrain navigation, robotic arm control, autonomous decision-making, and fault recovery—often surviving years beyond their original design life.\n25 Years of Intelligent Systems in Space | Wind River Probes, Orbiters, and Telescopes # Other notable space missions running VxWorks include:\nDeep Impact (comet Tempel 1 collision) Juno (Jupiter exploration) Phoenix Mars Lander (water ice discovery) Mars Reconnaissance Orbiter James Webb Space Telescope Fermi Gamma-ray Space Telescope These missions demonstrate VxWorks’ ability to operate reliably on radiation-hardened PowerPC and ARM systems with strict power budgets.\n✈️ Dominating the Skies: Aircraft and UAVs # VxWorks is equally entrenched in atmospheric flight systems, supporting both civilian and military platforms.\nCrewed Aircraft # Boeing 787 Dreamliner\nUses VxWorks as part of its Common Core System for flight-critical and aircraft management functions. Airbus A400M\nEmploys VxWorks in avionics and mission systems for heavy transport operations. VxWorks for Aerospace and Defense Solution Brief | Wind River Unmanned and Specialized Systems # Northrop Grumman X-47B unmanned combat aircraft Lockheed Martin RQ-170 Sentinel stealth reconnaissance UAV BAE Systems TARDIS radar displays for Tornado GR4 aircraft AgustaWestland Project Zero, an experimental tiltrotor platform Beyond aircraft, VxWorks also powers ground and navigation systems such as EGNOS and TacNet Tracker, where reliability and precision are equally critical.\n🔮 The Future of VxWorks in Aerospace # As aerospace systems evolve toward AI-assisted autonomy, edge computing, and cyber-resilient architectures, VxWorks continues to adapt. Ongoing investments in:\nSecure-by-design architectures Multicore determinism AI and acceleration frameworks Long-term certification support position VxWorks for future missions ranging from crewed Mars exploration to hypersonic and autonomous defense platforms.\nWith over 2 billion devices deployed worldwide, VxWorks remains one of the most battle-tested RTOS platforms ever built.\n🏁 Conclusion # From the vacuum of deep space to the complexity of modern airspace, VxWorks demonstrates how robust software enables extraordinary engineering achievements. Its dominance in aerospace and defense is not accidental—it is the result of decades of focus on predictability, safety, and trust.\nFor engineers working on high-reliability systems, VxWorks remains not just relevant—but foundational.\n","date":"2025-12-20","externalUrl":null,"permalink":"/industries/vxworks-powering-the-skies-and-beyond-in-aerospace-and-defense/","section":"Industries","summary":"\u003c!--# VxWorks in Aerospace and Defense: Powering Missions Beyond Earth--\u003e\n\u003cp\u003eIn the world of embedded systems, few operating systems carry the same weight as \u003cstrong\u003eVxWorks\u003c/strong\u003e. Developed by \u003cstrong\u003eWind River\u003c/strong\u003e, this real-time operating system (RTOS) has become synonymous with \u003cstrong\u003emission-critical reliability\u003c/strong\u003e, \u003cstrong\u003edeterministic performance\u003c/strong\u003e, and \u003cstrong\u003elong-term operational stability\u003c/strong\u003e.\u003c/p\u003e","title":"VxWorks in Aerospace and Defense: Powering Missions Beyond Earth","type":"industries"},{"content":"","date":"2025-12-18","externalUrl":null,"permalink":"/tags/enterprise-it/","section":"Tags","summary":"","title":"Enterprise IT","type":"tags"},{"content":" 🏗️ Solving the Edge Dilemma with a Unified Cloud-Native Platform\nAs enterprises accelerate AI adoption and digital transformation, traditional IT architectures are increasingly strained at the edge. While centralized cloud platforms deliver agility and scale, edge environments often remain fragmented, resource-constrained, and difficult to manage.\nThis growing gap between cloud and edge capabilities is commonly referred to as the “edge dilemma.”\n🧩 The Challenge: The Edge Dilemma # Organizations deploying workloads at the edge face several structural challenges:\nHardware Constraints: Remote and edge locations often lack sufficient compute and acceleration resources. Operational Complexity: Multi-vendor stacks create management silos and integration overhead. Slow Innovation Cycles: Updating or deploying new features can require on-site intervention and long validation cycles. AI Readiness Gaps: Running AI/ML workloads at the edge while ensuring data resilience, governance, and compliance remains difficult. These constraints limit the ability of enterprises to treat edge environments as true extensions of the cloud.\n🛠️ The Solution: A Unified Cloud-Native Platform # To address these challenges, Wind River and Rakuten Symphony combine complementary technologies to form a cloud-to-edge continuum. The result is a single, cohesive platform that brings cloud-native principles to distributed edge environments.\nWind River® Cloud Platform # Wind River Cloud Platform provides a production-grade Kubernetes infrastructure purpose-built for edge use cases:\nDistributed Computing: Designed to manage thousands of nodes across geographically dispersed sites. Deterministic Performance: Real-time and low-latency behavior for mission-critical workloads. Zero-Touch Automation: Automated provisioning, lifecycle management, and upgrades at scale. This enables enterprises to deploy and operate edge workloads with the same rigor as centralized cloud services.\nRakuten Cloud-Native Storage # Rakuten’s cloud-native storage adds an application-aware, software-defined storage (SDS) layer optimized for modern workloads:\nScalability and Performance: High throughput and low latency for containers and virtual machines. Built-in Data Protection: Integrated disaster recovery and resilience mechanisms. AI Optimization: Tuned for fast data ingestion and access required by AI training and inference pipelines. Together, compute and storage form a tightly integrated, cloud-native foundation at the edge.\n🌟 Key Benefits and Business Value # The integrated platform is designed to reduce Total Cost of Ownership (TCO) while increasing agility and reliability:\nAI/ML Enablement: Low-latency compute paired with high-throughput storage supports real-time AI inference at the edge. Operational Simplicity: Centralized management and automated updates replace manual, error-prone site-by-site operations. Business Continuity: Built-in resilience, dynamic scaling, and data protection ensure uninterrupted services. Future-Proof Architecture: Open standards and cloud-native design minimize vendor lock-in and support Industry 4.0 evolution. 🏭 Industry Use Cases # The unified platform enables advanced edge scenarios across multiple industries:\nIndustry Application Value Delivered Manufacturing Real-time AI quality inspection Deterministic compute for high-speed sensor and video analytics Healthcare AI-assisted diagnosis and medical imaging Low-latency access to compliant, resilient patient data Retail Smart checkout and behavior analysis Real-time edge processing with scalable data backends Finance Fraud detection and risk analysis High-performance, low-latency transaction security Energy Predictive maintenance Reliable remote monitoring in harsh environments 🏁 Summary: A Foundation for Edge Intelligence # By combining Wind River’s cloud-native Kubernetes platform with Rakuten Symphony’s software-defined storage, enterprises gain a robust, enterprise-grade edge foundation.\nThis unified approach allows organizations to move beyond the limitations of isolated edge hardware and operate distributed environments with the same scalability, resilience, and agility traditionally associated with centralized data centers—unlocking the full potential of AI and intelligent services at the edge.\n","date":"2025-12-18","externalUrl":null,"permalink":"/industries/solving-the-edge-dilemma-with-a-unified-cloud-native-platform/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003e🏗️ Solving the Edge Dilemma with a Unified Cloud-Native Platform\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eAs enterprises accelerate \u003cstrong\u003eAI adoption\u003c/strong\u003e and \u003cstrong\u003edigital transformation\u003c/strong\u003e, traditional IT architectures are increasingly strained at the edge. While centralized cloud platforms deliver agility and scale, edge environments often remain fragmented, resource-constrained, and difficult to manage.\u003c/p\u003e","title":"Solving the Edge Dilemma with a Unified Cloud-Native Platform","type":"industries"},{"content":"","date":"2025-12-16","externalUrl":null,"permalink":"/tags/boot-image/","section":"Tags","summary":"","title":"Boot Image","type":"tags"},{"content":" Understanding the Difference Between the Files VxWorks and VxWorks.bin\nWhen developing or deploying systems based on VxWorks, it is common to encounter two similarly named files: VxWorks and VxWorks.bin. Because the filenames are almost identical, they are often assumed to be interchangeable. In reality, they represent different image formats, each serving a distinct role in the build, debug, and boot process.\nThis article explains what each file is, how they are related, and when you should use one versus the other.\n🧭 Introduction # In a typical VxWorks BSP build, the kernel is produced in more than one form. These forms exist to satisfy different requirements:\nRich visibility during development and debugging Simplicity and robustness during booting and deployment Understanding the difference between VxWorks and VxWorks.bin helps avoid common boot issues and makes debugging far more effective.\n📦 What Is the VxWorks File? # The file named VxWorks is usually the primary kernel build output generated by the VxWorks build system for a specific BSP.\nDepending on the architecture and toolchain, this file is typically:\nAn ELF-format executable A symbol-rich image A structured file containing headers, sections, and metadata Because of these properties, VxWorks is mainly used during development and debugging.\nKey characteristics of VxWorks # Contains full symbol information (unless explicitly stripped) Preserves section layout such as .text, .data, and .bss Can be loaded directly by debuggers or ELF-aware bootloaders Enables source-level debugging and postmortem analysis In most BSPs, all other image formats are derived from this file.\n🧱 What Is the VxWorks.bin File? # The VxWorks.bin file is a raw binary image produced from the VxWorks executable.\nIt is typically created by:\nRemoving executable headers Stripping metadata and symbol information Flattening the image into a contiguous block of bytes The result is a minimal image that contains only what must be placed in memory for the system to boot.\nKey characteristics of VxWorks.bin # Raw binary data (no ELF headers) Smaller footprint than VxWorks Easy for simple bootloaders to load Commonly used in production and manufacturing Many embedded bootloaders cannot parse ELF files, making VxWorks.bin the preferred format for final deployment.\n🔍 Key Differences at a Glance # Aspect VxWorks VxWorks.bin File format Executable (often ELF) Raw binary Headers \u0026amp; metadata Present Removed Debug symbols Often included Not included Typical usage Development \u0026amp; debugging Booting \u0026amp; deployment Bootloader requirement ELF-aware loader Simple binary loader 🔗 How the Two Files Are Related # The relationship between the two images is straightforward:\nVxWorks.bin is generated from VxWorks.\nA typical workflow looks like this:\nConfigure the BSP and kernel components Build the VxWorks kernel Generate the VxWorks executable Convert or strip it to produce VxWorks.bin Any change to kernel configuration, components, or BSP code requires rebuilding VxWorks, which in turn produces a new VxWorks.bin.\n🚀 Role in the Boot Process # Which file is used depends largely on the bootloader design:\nDevelopment bootloaders or advanced loaders may load the VxWorks ELF file directly ROM-based or lightweight bootloaders usually expect VxWorks.bin Common scenarios include:\nTFTP boot during development using VxWorks Flash programming for production using VxWorks.bin Although both files boot the same operating system, they take different paths to get there.\n🧠 Why Both Files Exist # Maintaining both formats serves practical engineering needs:\nVxWorks prioritizes visibility, symbols, and debugging VxWorks.bin prioritizes simplicity, size, and reliability This separation allows efficient bring-up and debugging without compromising production robustness.\n⚠️ Common Sources of Confusion # Typical mistakes include:\nTreating VxWorks and VxWorks.bin as interchangeable Flashing an ELF-format image into a bootloader that expects raw binary Debugging a deployed issue without the matching VxWorks symbol file A recommended best practice is to keep both files from the same build together, ensuring symbols always match the deployed binary.\n✅ Summary # In summary:\nVxWorks is a symbol-rich, executable kernel image used mainly for development VxWorks.bin is a stripped, raw binary image used for booting and deployment Both represent the same VxWorks system in different formats The correct choice depends on your bootloader and development stage Understanding this distinction leads to smoother bring-up, easier debugging, and more reliable VxWorks deployments.\n","date":"2025-12-16","externalUrl":null,"permalink":"/bsp/vxworks-vs-vxworks.bin-understanding-the-key-differences/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eUnderstanding the Difference Between the Files \u003ccode\u003eVxWorks\u003c/code\u003e and \u003ccode\u003eVxWorks.bin\u003c/code\u003e\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eWhen developing or deploying systems based on \u003cstrong\u003eVxWorks\u003c/strong\u003e, it is common to encounter two similarly named files: \u003cstrong\u003e\u003ccode\u003eVxWorks\u003c/code\u003e\u003c/strong\u003e and \u003cstrong\u003e\u003ccode\u003eVxWorks.bin\u003c/code\u003e\u003c/strong\u003e. Because the filenames are almost identical, they are often assumed to be interchangeable. In reality, they represent \u003cstrong\u003edifferent image formats\u003c/strong\u003e, each serving a distinct role in the build, debug, and boot process.\u003c/p\u003e","title":"VxWorks vs VxWorks.bin: Understanding the Key Differences","type":"bsp"},{"content":"","date":"2025-12-16","externalUrl":null,"permalink":"/tags/mission-critical-software/","section":"Tags","summary":"","title":"Mission-Critical Software","type":"tags"},{"content":"","date":"2025-12-16","externalUrl":null,"permalink":"/tags/platform-engineering/","section":"Tags","summary":"","title":"Platform Engineering","type":"tags"},{"content":" Software has become the primary driver of innovation in mission-critical and safety-critical industries such as aerospace, telecommunications, industrial automation, automotive, robotics, and unmanned systems. As systems grow more intelligent and interconnected, software complexity has increased dramatically—placing unprecedented pressure on development speed, consistency, and reliability.\nTo keep pace with innovation, organizations are transitioning from traditional waterfall development to agile and cloud-native approaches, adopting virtualization, containerization, and Over-The-Air (OTA) updates to shorten delivery cycles. In this environment, Platform Engineering has emerged as a foundational discipline to ensure speed without sacrificing quality, safety, or security.\nPlatform Engineering creates a standardized software development platform that provides a consistent pipeline, accelerates time-to-market, and allows developers to focus on delivering differentiated functionality rather than rebuilding infrastructure.\n🎯 What Is Platform Engineering? # Platform Engineering focuses on building self-service internal platforms that abstract infrastructure complexity and reduce developer cognitive load. By hiding operational intricacies behind well-defined interfaces, developers can concentrate on feature development and system behavior rather than tooling and integration overhead.\nThis approach has been instrumental to the scalability of organizations such as Google, Meta, and Amazon, enabling rapid iteration, frequent releases, and consistent quality at scale.\nAt its core, Platform Engineering is not about adding more tools—it is about curating and standardizing workflows to make software delivery predictable and repeatable.\n🧩 Core Principles of Platform Engineering # A mature platform is built on a robust, end-to-end pipeline that emphasizes both developer efficiency and system integrity. Key principles include:\nAutomation: Eliminating repetitive manual tasks across build, test, deployment, and validation Self-Service: Enabling developers to provision environments and services on demand Standardization: Applying consistent practices across the entire software development lifecycle (SDLC) Developer Experience (DevEx): Reducing friction to improve productivity, quality, and morale As system architectures expand across hardware, software, and electronics domains, these principles become increasingly critical—especially in the face of talent shortages and growing delivery pressure.\n⚙️ Why Platform Engineering Matters for Embedded and Mission-Critical Systems # Embedded software development presents unique challenges that make Platform Engineering especially valuable:\nHigh Variability: Numerous product variants dramatically increase code and validation complexity Strict Requirements: Functional safety, real-time behavior, and cybersecurity are non-negotiable Legacy Constraints: Existing architectures and long-lived codebases complicate modernization In mission-critical environments, failures are unacceptable. Platform Engineering enforces consistency, reducing integration errors and security gaps. A well-defined platform simplifies vulnerability management, supports reuse across variants, and streamlines verification and certification workflows.\n🛣️ Enabling the Transition to Platform-Based Development # Industry research shows that aerospace, industrial, and automotive organizations are actively adopting Platform Engineering to address rising complexity. Their primary objectives include:\nCentralizing development practices Managing and modernizing legacy systems Promoting knowledge sharing across teams Establishing unified technical standards Improving long-term cost efficiency However, transitioning from project-centric models to platform-based development is rarely trivial. Legacy systems, fragmented tooling, and heterogeneous architectures often hinder reuse and consistency.\nA step-by-step adoption strategy, supported by domain-specific solutions, helps organizations manage risk while steadily realizing platform benefits.\n🌐 Managing Heterogeneity at the Edge # Heterogeneity in edge and embedded systems far exceeds that of cloud or consumer computing. Diverse processors, semiconductor vendors, operating systems, and deployment environments introduce significant integration challenges.\nSimply increasing engineering headcount is not sustainable. The scalable solution is to abstract common patterns across diverse environments, providing a shared foundation that teams can extend where necessary.\nBy integrating industry best practices into a unified pipeline, organizations can support diverse products while maintaining consistency in security, validation, and delivery processes.\n🏗️ Building a Mature Platform Organization # A successful Platform Engineering initiative begins with a dedicated platform team responsible for maintaining shared infrastructure and development standards.\nCustomization remains essential. Through add-ons, plugins, blueprints, and integration frameworks, teams can introduce specialized tools and workflows without breaking the common baseline. Over time, the platform evolves into a collaborative environment that supports proactive security governance and continuous improvement.\nThis balance—standardization with controlled flexibility—is what allows platform-based development to scale across large, distributed engineering organizations.\n🔮 The Future of Platform Engineering # Platform Engineering represents a fundamental shift in how mission-critical and embedded software is developed. By unifying infrastructure, simplifying workflows, and enforcing consistency, organizations can empower developers to focus on innovation while maintaining the highest levels of reliability and security.\nAs product complexity continues to grow, Platform Engineering will play a central role in managing variability, accelerating delivery, and sustaining long-term competitiveness in safety-critical industries.\n","date":"2025-12-16","externalUrl":null,"permalink":"/industries/platform-engineering-for-mission-critical-systems-standardized-agile-secure/","section":"Industries","summary":"\u003c!--# Platform Engineering for Mission-Critical Systems: Standardized, Agile, Secure--\u003e\n\u003cp\u003eSoftware has become the primary driver of innovation in \u003cstrong\u003emission-critical and safety-critical industries\u003c/strong\u003e such as aerospace, telecommunications, industrial automation, automotive, robotics, and unmanned systems. As systems grow more intelligent and interconnected, software complexity has increased dramatically—placing unprecedented pressure on development speed, consistency, and reliability.\u003c/p\u003e","title":"Platform Engineering for Mission-Critical Systems: Standardized, Agile, Secure","type":"industries"},{"content":"","date":"2025-12-13","externalUrl":null,"permalink":"/tags/aspice/","section":"Tags","summary":"","title":"ASPICE","type":"tags"},{"content":"","date":"2025-12-13","externalUrl":null,"permalink":"/tags/automotive-cybersecurity/","section":"Tags","summary":"","title":"Automotive Cybersecurity","type":"tags"},{"content":"","date":"2025-12-13","externalUrl":null,"permalink":"/tags/automotive-software/","section":"Tags","summary":"","title":"Automotive Software","type":"tags"},{"content":" Before the concept of the Software-Defined Vehicle (SDV) emerged, automotive software was already subject to far stricter discipline than most other industries. The reason is simple: scale, safety, and regulatory pressure. In automotive systems, every line of code must be traceable—linked upstream to a validated requirement and downstream to verification and test results.\nTraceability is not just a quality assurance mechanism; it is a structural foundation for modern automotive software development. It ensures that changes are controlled, unintended side effects are minimized, and regulatory compliance can be demonstrated at any time. It is also a key requirement under UN/ECE Regulation No. 156, governing software updates and lifecycle management.\nThe roots of traceability lie in established automotive best practices such as ASPICE (Automotive Software Process Improvement and Capability Determination), which formalizes traceability through the V-Model. In this model, every development activity—requirements, design, implementation, integration, and testing—is explicitly linked, making dependencies and responsibilities transparent throughout the lifecycle.\n🔗 Implementing Software Traceability # Emphasizing traceability early in the development process is critical. Writing code before requirements are reviewed and approved almost guarantees rework later. Retrofitting traceability after implementation is costly, time-consuming, and often incomplete.\nIn practice, effective traceability requires consistent linking across multiple systems:\nRequirements management Task and issue tracking Source code repositories Test management and execution systems Traditionally, maintaining these links involved extensive manual effort, making traceability fragile and error-prone at scale.\nWind River Studio Developer addresses this challenge by automating traceability across these systems and presenting them through a single pane of glass. Development teams can visualize how requirements map to code, how code maps to tests, and how changes propagate across the system. This visibility extends beyond internal teams to external suppliers, allowing OEMs to track third-party code with the same rigor as in-house development.\n🧪 Testing Advantages Enabled by Traceability # Traceability fundamentally changes how testing is performed and optimized.\nAutomotive testing environments are highly distributed, spanning:\nSoftware-in-the-Loop (SIL) testing in cloud environments Hardware-in-the-Loop (HIL) testing on physical benches With traceability in place, test results are automatically associated with specific requirements, tasks, and code changes. This enables developers to do more than just verify whether a requirement passed or failed.\nMore importantly, traceability allows teams to intelligently select related tests—not only those directly linked to a changed requirement, but also adjacent tests that may be indirectly affected. This dramatically improves confidence in change impact analysis while reducing overall test execution time.\nLooking forward, Generative AI can leverage this traceability graph to:\nSelect the most relevant tests for a given change Generate new test scenarios Identify risk areas humans may overlook The result is more focused testing, faster feedback cycles, and earlier defect discovery—ideally before software ever reaches a vehicle.\n🔒 Traceability and Automotive Security # Traceability is equally critical in the domain of automotive cybersecurity.\nWhen a security incident occurs, rapid root-cause analysis is essential. With traceability:\nIncidents can be linked directly to specific code fragments The originating change, requirement, and responsible developer can be identified Remediation actions can begin immediately, not days later In parallel, secure software deployment relies on strong integrity guarantees. Modern key management systems can cryptographically sign every software component before it is deployed to a vehicle. Each signed artifact remains traceable to its originating requirements and verification evidence, ensuring both authenticity and accountability.\nAs vehicles evolve into platforms hosting tens of thousands of independent software components—many sourced from different suppliers—software independence becomes unavoidable. Managing, updating, securing, and validating this ecosystem is impossible without robust traceability.\nIn this context, traceability is no longer a compliance checkbox. It becomes a mission-critical capability for the software-defined vehicle era, making integrated platforms like Wind River Studio foundational tools for modern automotive software development.\n","date":"2025-12-13","externalUrl":null,"permalink":"/industries/automotive-software-traceability-for-the-software-defined-vehicle-era/","section":"Industries","summary":"\u003c!--# Automotive Software Traceability for the Software-Defined Vehicle Era--\u003e\n\u003cp\u003eBefore the concept of the \u003cstrong\u003eSoftware-Defined Vehicle (SDV)\u003c/strong\u003e emerged, automotive software was already subject to far stricter discipline than most other industries. The reason is simple: scale, safety, and regulatory pressure. In automotive systems, every line of code must be \u003cstrong\u003etraceable\u003c/strong\u003e—linked upstream to a validated requirement and downstream to verification and test results.\u003c/p\u003e","title":"Automotive Software Traceability for the Software-Defined Vehicle Era","type":"industries"},{"content":"","date":"2025-12-13","externalUrl":null,"permalink":"/tags/traceability/","section":"Tags","summary":"","title":"Traceability","type":"tags"},{"content":"","date":"2025-12-11","externalUrl":null,"permalink":"/tags/iec-61508/","section":"Tags","summary":"","title":"IEC 61508","type":"tags"},{"content":"","date":"2025-12-11","externalUrl":null,"permalink":"/tags/intel-aep/","section":"Tags","summary":"","title":"Intel AEP","type":"tags"},{"content":"","date":"2025-12-11","externalUrl":null,"permalink":"/tags/safety-certification/","section":"Tags","summary":"","title":"Safety Certification","type":"tags"},{"content":" Organizations operating in safety-critical domains must ensure that their systems protect personnel, equipment, and the surrounding environment. Functional safety certification—while rigorous and resource-intensive—is essential for building market credibility and competitive advantage.\nWind River recently introduced two key enhancements to strengthen certification support for intelligent edge systems:\nBroader processor support under the IEC 61508 industrial safety standard. New support for hardware platforms covered by Intel’s Airworthiness Evidence Package (AEP), enabling more efficient aerospace certification. 🛡️ Wind River’s Functional Safety Foundation # Helping customers achieve functional safety certification efficiently and cost-effectively is a core value of the Wind River Helix (VxWorks) RTOS and the Wind River Helix Hypervisor platforms.\nWhen developing on the Wind River Helix Hypervisor or the safety-certified VxWorks Cert Edition, customers only need to certify the code they create—not the underlying operating system. For system-level certifications (such as full aircraft airframes), Wind River provides the required certification evidence to support approval.\nBoth platforms are backed by decades of deployment and industry certifications, including:\nAerospace: RTCA DO-178C / EUROCAE ED-12C DAL A Industrial: IEC 61508 SIL 3 Automotive: ISO 26262 ASIL-D Medical: IEC 62304 Class C The Hypervisor holds equivalent certifications in aerospace, automotive, and industrial markets, giving developers a trusted software foundation and significantly reducing project risk.\n🏭 Industrial Expansion With IEC 61508 SIL 3 Support # Wind River has held IEC 61508 SIL 3 certification since 2018, but recently expanded the Wind River Helix RTOS to support Arm Cortex-A53 processors based on the Armv8-A 64-bit architecture.\nWhy Cortex-A53 Matters # A widely adopted processor in industrial automation and edge devices. Balances performance, power efficiency, and cost—typically deployed in quad-core configurations. Ideal for multi-threaded workloads such as HMIs, edge analytics, and data acquisition. Customer Benefits # Using the already-certified RTOS significantly shortens the certification timeline, enabling industrial vendors to reach the market faster with compliant, reliable products.\n✈️ Intel AEP Integration for Aerospace Certification # Intel’s Airworthiness Evidence Package (AEP) provides detailed, non-public documentation that helps developers certify Intel hardware and software components for use in airborne safety-critical systems.\nSupported Processors # The quad-core Intel Core i7-1186 GRE (Tiger Lake UP3) is covered under Intel’s AEP. The Intel Core i7-1185 GRE, a functionally equivalent variant, is also confirmed as supported.\nThis enables aerospace developers to build and test software early—before final certification hardware is deployed.\nSupported Hardware Platforms # Wind River now supports two ruggedized COTS platforms using the 1186 processor:\nNorth Atlantic Industries 68INT6 single-board computer Supermicro STS-E100-12T-H, valued for its configurability in mission-critical deployments System-Level Advantages # Deterministic performance from Wind River Helix RTOS on the NAI 68INT6 Mixed-criticality consolidation enabled by Wind River Helix Hypervisor Optimized SWaP (Size, Weight, and Power)—crucial for aerospace platforms Hardware alignment with Intel AEP helps streamline aircraft airframe certification Wind River’s expanded industrial support and deeper aerospace integration reinforce its leadership in delivering safe, reliable intelligent edge platforms. These improvements ensure customers can meet certification requirements with reduced risk and faster time-to-market—whether building next-generation industrial controllers or mission-critical avionics systems.\n","date":"2025-12-11","externalUrl":null,"permalink":"/industries/wind-river-expands-safety-certification-support-for-edge-systems/","section":"Industries","summary":"\u003c!--# Wind River Expands Safety Certification Support for Edge Systems--\u003e\n\u003cp\u003eOrganizations operating in safety-critical domains must ensure that their systems protect personnel, equipment, and the surrounding environment. Functional safety certification—while rigorous and resource-intensive—is essential for building market credibility and competitive advantage.\u003c/p\u003e","title":"Wind River Expands Safety Certification Support for Edge Systems","type":"industries"},{"content":"","date":"2025-12-11","externalUrl":null,"permalink":"/tags/ai-lifecycle/","section":"Tags","summary":"","title":"AI Lifecycle","type":"tags"},{"content":"","date":"2025-12-11","externalUrl":null,"permalink":"/tags/cloud-edge/","section":"Tags","summary":"","title":"Cloud-Edge","type":"tags"},{"content":"","date":"2025-12-11","externalUrl":null,"permalink":"/tags/continuous-intelligence/","section":"Tags","summary":"","title":"Continuous Intelligence","type":"tags"},{"content":" For the past decade, the technology industry has pushed workloads away from physical infrastructure and into centralized hyperscale clouds. Compute, storage, and application logic consolidated into data centers, accelerating innovation and simplifying operations. Just as enterprises mastered cloud-first thinking, a new transformation has emerged—one that reverses the direction of compute flow.\nThe next era of AI will not be defined solely by what happens in massive cloud clusters, but by what happens at the edge—where data originates, events occur, and real-time decisions carry real-world consequences.\nEdge AI is more than placing inference models onto devices. It creates a closed, continuous loop: data is generated on distributed systems, models evolve through centralized training, and new intelligence flows back to the field. The edge becomes an active participant in a permanent cycle of learning and improvement.\n⚡ Why Intelligence Cannot Live Only in the Cloud # Enterprises originally adopted cloud computing to gain elasticity, programmability, and faster development cycles. But in industries where physical systems interact with the real world—robotics, aerospace, automotive, industrial automation, telecommunications—cloud-only AI introduces unavoidable limitations.\nLatency Limits # When decisions must be made within milliseconds, round-tripping data across long distances is too slow. Autonomous vehicles, robotic systems, and power grids cannot rely on cloud responsiveness. Edge AI performs inference at the point of action, combining local immediacy with cloud-scale training.\nResilience and Autonomy # Many systems operate in environments with intermittent or constrained connectivity. Edge devices must operate autonomously—even when offline—to maintain safety, reliability, and mission readiness.\nEconomics of Data Movement # Sending firehose-scale sensor data to the cloud is costly and inefficient. Edge computation reduces cloud storage, network egress, and central compute spending. Devices transmit only what matters: insights, anomalies, exceptions.\nThis is not a battle of edge versus cloud. It is a strategic pairing where each plays a distinct role in a unified AI lifecycle.\n🔄 The Continuous Circle of Edge AI # Historically, AI models were trained once, deployed once, and rarely updated. Value peaked on day one and decayed over time.\nEdge AI replaces that static model with a dynamic, circular lifecycle:\n1. Data Generation at the Edge # Machines, robots, vehicles, and sensors observe the world in ways cloud systems cannot. They produce contextual, real-world data—often unique to each deployment.\n2. Centralized Cloud Training # Data flows into centralized training pipelines where engineers refine models using large-scale compute, specialized frameworks, and massive multi-environment datasets.\n3. Deployment Back to the Edge # Once validated, updated intelligence—code, firmware, or model artifacts—is pushed back to field devices. CI/CD extends beyond software to physical systems. Rollouts occur gradually, with monitoring and instant rollback if needed.\n4. Continuous Improvement # The cycle repeats. Data flows inward, intelligence flows outward.\nThis creates a powerful flywheel:\nMore field operation → More data More data → Better training Better training → Stronger models Stronger models → Increased value and differentiation Unlike traditional software, where value erodes over time, Edge AI systems accumulate value with every cycle.\n💰 The Business Drivers Behind Edge AI # Organizations pursue Edge AI not for novelty, but because it changes financial outcomes.\nRecurring, Lifecycle-Based Revenue # Products evolve continuously, enabling subscription models, service revenue, and long-term monetization. Devices become platforms, not static assets.\nPredictive Efficiency # Local inference enables real-time control, predictive maintenance, automated optimization, and reduced downtime. These benefits compound across large fleets of deployed devices.\nEcosystem Leverage # Edge-connected products integrate with analytics tools, digital twins, optimization engines, and partner applications. Systems evolve from isolated hardware to multi-sided platforms.\nEdge AI reframes the idea of a “shipped product.” What ships is simply the starting point.\n🏗️ What Must Change in Edge System Architecture # Most edge systems weren’t built for AI-driven, continuous-update environments. They were designed for stability, determinism, and minimal change. Edge AI requires the opposite: elasticity, adaptability, and seamless update paths.\nTo support this shift, edge architectures need four foundational capabilities:\n1. An Execution Environment Optimized for Inference # Some environments require real-time determinism (RTOS), others full Linux capability, and increasingly hybrid architectures that blend both. The OS must support containers, accelerators, and modern ML frameworks.\n2. Secure and Selective Data Movement # The AI cycle breaks without a secure data plane. Systems must export relevant data with privacy controls and bandwidth efficiency—not raw bulk streams.\n3. Continuous Observability # Telemetry and operational data become inputs to the AI lifecycle. Developers need visibility into how models behave in the field over time.\n4. Scalable, Controlled CI/CD for Distributed Devices # Edge AI requires automated rollout, staged deployment, health monitoring, and rollback capabilities across global fleets.\nThese requirements mark a major departure from traditional embedded system design.\n🧭 Why This Shift Matters for Executives # The strategic question for leadership:\nWill your products diminish in value, or improve continuously?\nEdge AI transforms every deployed device into a learning asset:\nIntelligence accumulates over time Innovation becomes continuous Operational insights feed product differentiation Data becomes a long-term strategic moat The competitive gap between companies that adopt continuous Edge AI and those that do not will widen dramatically over the next decade.\n🔧 Closing the Loop: How Edge AI Becomes Real # The vision becomes practical when the technology foundations align. The Wind River platform ecosystem enables this continuous Edge AI lifecycle across three dimensions:\nAt the Edge # Wind River platforms—including VxWorks, eLxr Linux, and Wind River Cloud Platform—provide secure, deterministic, container-ready environments capable of hosting AI workloads and hardware acceleration.\nIn the Cloud # Wind River Analytics aggregates telemetry and operational data, providing visibility into fleet behavior, model performance, and operational trends.\nThrough Lifecycle Management # Wind River Conductor delivers cloud-native CI/CD for devices—handling configuration changes, model updates, and full application deployments across distributed systems.\nThis completes the intelligence loop:\nedge → data → cloud → training → deployment → edge.\nEdge AI is not a product; it is a systemic shift in how intelligence is created, deployed, improved, and monetized. It turns devices into evolving systems and transforms data into defensible competitive advantage.\nThe organizations that master the continuous circle of Edge AI will define the next decade of innovation.\nReference: The Continuous Circle of Edge AI - Why the Future of Intelligence Lives Outside the Datacenter By Paul Miller, CTO, Wind River\n","date":"2025-12-11","externalUrl":null,"permalink":"/industries/the-continuous-edge-ai-lifecycle/","section":"Industries","summary":"\u003c!--# The Continuous Circle of Edge AI--\u003e\n\u003cp\u003eFor the past decade, the technology industry has pushed workloads away from physical infrastructure and into centralized hyperscale clouds. Compute, storage, and application logic consolidated into data centers, accelerating innovation and simplifying operations. Just as enterprises mastered cloud-first thinking, a new transformation has emerged—one that reverses the direction of compute flow.\u003c/p\u003e","title":"The Continuous Edge AI Lifecycle","type":"industries"},{"content":"","date":"2025-12-08","externalUrl":null,"permalink":"/tags/boot-optimization/","section":"Tags","summary":"","title":"Boot Optimization","type":"tags"},{"content":" Fast Boot Optimization of VxWorks on PowerPC Platforms\nVxWorks is widely adopted in aerospace, communications, and defense due to its reliability and real-time performance. While its typical 10-second boot time outperforms many embedded operating systems, mission-critical applications—especially weapon systems—often demand even faster initialization. This article analyzes the VxWorks boot process on PowerPC platforms, identifies key sources of latency, and proposes a multi-layer optimization strategy. Using the techniques presented here, a 1.58 MB kernel was able to boot in 0.8 seconds, reducing startup time by 91%.\n🚀 Introduction # Real-time systems frequently require rapid boot sequences to ensure immediate operation after power-on. Although VxWorks is fast by default, its standard initialization process may still be inadequate for time-sensitive domains such as weapons control or emergency-response systems.\nA detailed understanding of the VxWorks boot process enables targeted optimizations. This article presents a systematic approach for PowerPC platforms, covering software trimming, driver optimization, memory tuning, and image type selection.\n🧩 Analysis of the VxWorks Boot Process # VxWorks images fall into two primary categories, each with distinct startup behavior.\n2.1 Downloadable Images # Downloadable images rely on BootRom, which runs after reset and performs:\nCPU register and stack initialization Cache enabling Basic hardware setup Kernel loading via Ethernet or serial port Once loaded, control transfers to the kernel, which repeats several initialization steps such as usrInit, sysHwInit, and usrKernelInit. This overlapping work results in redundant initialization, slowing overall startup.\n2.2 ROM-Based Images # ROM images reside directly in NOR Flash. On reset, the CPU executes romInit, which then copies or decompresses the kernel into RAM unless the system uses a ROM-resident image.\nSince ROM-based images bypass BootRom and reduce duplicated early-stage initialization, they generally start up significantly faster than downloadable images.\n⚙️ Fast Boot Optimization Strategy # Based on the boot process analysis, several optimization techniques can be applied to reduce startup latency.\n3.1 Kernel Component Reduction # Because VxWorks uses a modular kernel, eliminating unnecessary components:\nReduces execution time during initialization Shrinks the kernel image, shortening Flash-to-RAM copy duration Care must be taken to retain all modules required by the application.\n3.2 Device Driver Optimization # Drivers often introduce avoidable delays:\nProbing unused peripherals Conservative polling loops Long timeouts for stability Removing unused drivers and shortening noncritical delays can yield major improvements.\n3.3 Selecting the Optimal Kernel Image Type # Three ROM image types were evaluated:\nImage Type Compressed Moves Code to RAM Pros Cons VxWorks_rom.bin No Yes Fastest execution Larger image size VxWorks_romCompress.bin Yes Yes Smaller copy size Decompression overhead VxWorks.res_rom.bin No Only data Saves RAM Flash execution slows performance Experiments found VxWorks_rom.bin achieves the fastest startup.\n3.4 Flash Access Timing Optimization # PowerPC Option Registers (OR) control Flash timing. Tuning these registers to the fastest stable values increases Flash read speed and reduces kernel copy time.\n3.5 Removing Memory Zeroing # After relocation, VxWorks normally clears unused RAM regions. Since applications reinitialize memory anyway, this step is unnecessary and time-consuming. Removing it provides a significant speed boost.\n3.6 Memory Mapping Optimization Using BAT # PowerPC’s Block Address Translation (BAT) can map large regions more efficiently than TLB-based paging. Mapping Flash and FPGA regions with BAT:\nReduces early-stage TLB usage Improves memory access speed Enhances overall boot performance 🧪 Experimental Setup and Results # 4.1 Hardware \u0026amp; Software Environment # CPU: MPC8377 @ 600 MHz RAM: 512 MB Flash: 64 MB NOR, 8 GB NAND I/O: Ethernet, CAN, RS422 OS: VxWorks 6.9 Measurement: GPIO toggling observed via oscilloscope 4.2 Boot Mode Comparison # Using identical kernel configurations, image type tests showed that the ROM uncompressed image (VxWorks_rom.bin) provides the lowest boot latency because it avoids both BootRom overhead and decompression delays.\n4.3 Optimization Results # After applying the complete optimization strategy:\nBefore: 9.62 s After: 0.8 s A total reduction of 8.82 seconds, or 91%, was achieved.\n🧭 Conclusion # This work demonstrates an effective method for dramatically accelerating VxWorks startup on PowerPC platforms. By refining kernel components, optimizing drivers, tuning Flash and memory performance, and selecting the optimal ROM image type, boot times can be reduced to sub-second levels.\nAlthough the study focused on VxWorks 6.9 running on PowerPC hardware, the overall methodology applies broadly to other architectures and embedded systems requiring rapid initialization.\n","date":"2025-12-08","externalUrl":null,"permalink":"/bsp/fast-booting-vxworks-on-powerpc-cutting-startup-time-to-0.8s/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eFast Boot Optimization of VxWorks on PowerPC Platforms\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eVxWorks is widely adopted in aerospace, communications, and defense due to its reliability and real-time performance. While its typical 10-second boot time outperforms many embedded operating systems, mission-critical applications—especially weapon systems—often demand even faster initialization. This article analyzes the VxWorks boot process on PowerPC platforms, identifies key sources of latency, and proposes a multi-layer optimization strategy. Using the techniques presented here, a 1.58 MB kernel was able to boot in \u003cstrong\u003e0.8 seconds\u003c/strong\u003e, reducing startup time by \u003cstrong\u003e91%\u003c/strong\u003e.\u003c/p\u003e","title":"Fast Booting VxWorks on PowerPC: Cutting Startup Time to 0.8s","type":"bsp"},{"content":" VxBus in VxWorks SMP: Architecture, Concepts, and Driver Model\n🏁 Preface # This document provides a comprehensive explanation of the VxBus infrastructure as it applies to VxWorks systems running in symmetric multiprocessing (SMP) mode. VxBus forms the foundation for SMP-safe driver development and ensures consistent behavior across all CPU cores. While this article focuses on conceptual and architectural clarity, developers can refer to the VxWorks Device Driver Developer’s Guide, Volume 1 for in-depth API usage and advanced examples.\n🚀 1. Introduction # Modern VxWorks systems increasingly rely on SMP to deliver higher performance, scalability, and fault isolation. To operate safely across multiple cores, device drivers must follow strict rules for concurrency, initialization, and interrupt handling. Wind River introduced VxBus to replace legacy BSP-tied drivers with a unified, modular, and portable framework.\nAt its core, VxBus:\nprovides consistent APIs for OS and middleware components enforces strict rules for hardware register access reduces architecture-specific code inside drivers simplifies BSP integration supports dynamic driver inclusion works with diverse bus types through a common model Historically, bus controllers lived inside BSPs. Under VxBus, bus controllers behave like normal devices, residing outside BSP directories, improving modularity and reducing board-level maintenance.\n🎯 2. Benefits of VxBus # Key advantages of the VxBus model include:\nHigh Portability — drivers work across multiple BSPs with minimal modification. Clean Architecture — separation of driver logic from board-specific logic. Consistent Configuration — unified project-system integration. Simplified BSPs — fewer files, smaller maintenance footprint. Dynamic Device Discovery — runtime registration of devices and drivers. Scalable Bus Framework — extensible for new bus technologies. 📘 3. Core Terminology # Essential concepts in the VxBus ecosystem:\nDevice — a hardware component with a defined function. Driver — software that determines whether it can manage a device and exposes methods to the OS. Instance — a pairing of a driver with a specific device. Bus — a communication pathway between CPU and devices. Parent/Child — hierarchical relationship between buses and downstream devices. Orphan Device — a device discovered with no matching driver. These terms form the conceptual vocabulary of VxBus.\n🧩 4. VxBus Device Instances # A device instance is formed when VxWorks successfully matches a driver to a hardware device. The OS provides:\nregister mappings configuration information access interfaces for memory and I/O This ensures consistency in:\nregister addressing driver independence from BSP internals hardware abstraction through VxBus facilities Each instance encapsulates its own executable logic, configuration, and hardware bindings.\n⚙️ 5. Component Configuration # 5.1 Device Drivers # VxBus device drivers are responsible for:\nhardware initialization runtime management exposing services to other drivers and OS components interaction with VxBus APIs All driver code resides outside the BSP, supporting reuse across multiple platforms.\n5.2 Bus Controller Drivers # Like all VxBus drivers, bus controllers live outside the BSP and:\ninitialize and configure the bus detect downstream devices expose subordinate memory and device access manage processor or memory elements attached to the bus VxWorks separates BSP files from bus controller and driver logic to maintain modularity.\n🗂️ 6. Directory Structure Overview # A typical VxBus directory structure includes:\nBSP directory — board configuration device drivers — /target/src/hwif/\u0026lt;BUS\u0026gt; bus controller drivers — /target/src/hwif/busCtlr VxBus core logic — /src/hwif/vxBus Each driver has a dedicated folder, promoting modular design.\n🛠️ 7. Driver Interface # Drivers declare their capabilities through driver methods:\neach method has a unique ID methods are invoked exclusively through VxBus APIs method tables advertise driver functionality dynamic registration is supported The OS and middleware call these methods via standardized APIs, ensuring consistent behavior across drivers.\n🧱 8. Driver Method Registration # Drivers define method tables mapping method IDs to function pointers using DEVMETHOD. VxBus uses these tables to determine available driver functionality.\nThe process involves:\ndefining supported methods including the method list inside the driver registration structure assigning the table to each device instance This modular, table-driven model streamlines driver invocation.\n🔔 9. Interrupt Management # Interrupts are associated with device instances and interrupt indices. In SMP systems:\nall interrupts initially route to the boot processor routing is updated as additional CPUs come online routing logic is governed by system configuration tables interrupt lines are identified by pin numbers Drivers may reroute interrupts dynamically using APIs such as:\nvxbIntToCpuRoute() vxbIntReroute() This flexibility is crucial for performance tuning in SMP environments.\n⚡ 10. Deferred Interrupt Service Routines (Deferred ISRs) # ISRs must execute minimal logic to reduce latency. Extended processing is deferred to task context:\nISR disables further interrupts triggers a defer task defer task processes work ISR re-enables interrupts afterward In SMP systems, the defer task may execute on a different core. Correct CPU affinity is essential for performance and determinism.\n🧰 11. Services Available to Drivers # VxBus provides a rich set of services:\nconfiguration and environment retrieval memory allocation and management DMA handling synchronization primitives (mutexes, spinlocks, atomics, semaphores) interrupt management and deferral watchdog timers diagnostics and debugging utilities These standardized services prevent reimplementation of common mechanisms.\n🧩 12. Modularity and Component Model # VxBus aligns with the VxWorks kernel configuration system:\neach driver maps to a kernel component drivers may provide bus control, interrupt control, or device services systems can enable or disable drivers with fine granularity This modular approach supports robust customization.\n🔒 13. Driver Data Synchronization # SMP systems require careful coordination between:\nclient tasks defer tasks ISRs Task-Level Synchronization # Use:\nmutexes semaphores message queues spinlocks Interrupt-Level Synchronization # In interrupt context:\nintCpuLock()/intCpuUnlock() temporarily mask interrupts ISR-safe spinlocks allow non-blocking SMP protection Note: Task-level interrupt disabling is unsafe in SMP because ISRs may still fire on other cores.\n🔄 14. Porting Drivers to VxBus # Porting steps include:\nvalidating driver functionality creating the needed VxBus scaffolding removing BSP-owned driver logic following VxBus initialization sequences implementing required driver-class methods eliminating BSP-specific dependencies replacing raw register access with VxBus helpers Nearly all modern BSPs rely entirely on VxBus.\n🏁 15. Conclusion # SMP environments depend heavily on inter-processor communication (IPIs), which require VxBus-compliant interrupt controller drivers. For this reason, VxBus is foundational—not optional—for VxWorks SMP systems.\nVxBus provides:\na unified driver framework strict, consistent interfaces robust SMP support portable, modular driver design Its architecture ensures safe, scalable driver behavior across all CPU cores and remains essential for modern VxWorks systems.\n","date":"2025-12-07","externalUrl":null,"permalink":"/bsp/vxbus-architecture-and-driver-model-for-vxworks-smp/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxBus in VxWorks SMP: Architecture, Concepts, and Driver Model\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🏁 Preface \n    \u003cdiv id=\"-preface\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-preface\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThis document provides a comprehensive explanation of the VxBus infrastructure as it applies to VxWorks systems running in symmetric multiprocessing (SMP) mode. VxBus forms the foundation for SMP-safe driver development and ensures consistent behavior across all CPU cores. While this article focuses on conceptual and architectural clarity, developers can refer to the \u003cem\u003eVxWorks Device Driver Developer’s Guide, Volume 1\u003c/em\u003e for in-depth API usage and advanced examples.\u003c/p\u003e","title":"VxBus Architecture and Driver Model for VxWorks SMP","type":"bsp"},{"content":"","date":"2025-12-07","externalUrl":null,"permalink":"/tags/fuzzing/","section":"Tags","summary":"","title":"Fuzzing","type":"tags"},{"content":" A High-Acceptance-Rate VxWorks Fuzzing Framework Using Protocol Features and Memory Feedback\n🚀 Introduction # IoT deployments now reach tens of billions of devices, many of which rely on VxWorks for critical applications in aviation, industrial control, and medical platforms. Vulnerabilities in the TCP stack of VxWorks can have severe consequences, from remote code execution to widespread IoT system compromise.\nFuzzing TCP on VxWorks is challenging due to:\nStrict state transitions and checksum requirements No built-in coverage feedback in a closed-source RTOS Generic fuzzers producing syntactically invalid packets that VxWorks immediately drops These limitations motivate the creation of a specialized fuzzing framework that understands TCP structure and extracts useful signals from an opaque system.\n📚 Background and Motivation # TCP Complexity # TCP enforces rigid constraints—valid sequence/acknowledgment logic, checksum correctness, port relationships, and strict connection states. Invalid packets are dropped early, greatly limiting fuzzing throughput and exploration depth.\nLimited Visibility in VxWorks # As VxWorks is proprietary and embedded, traditional coverage-guided fuzzers (AFL, libFuzzer) cannot obtain code-level feedback. Most IoT fuzzers operate blindly, resulting in poor test quality.\nVxWorks Task Behavior # The network stack is processed primarily by tNet0. Monitoring its PC register movement and associated memory activity offers a coarse but useful signal about how deeply a packet was processed.\nWDB Debugging Limitations # VxWorks’ WDB interface detects exceptions but misses silent network hangs, necessitating a second detection mechanism.\n🔧 vxTcpFuzzer Design # vxTcpFuzzer consists of three core components designed specifically to increase packet acceptance and detect abnormal behavior in closed-source VxWorks environments.\nProtocol Feature Fusion Fuzzer # Instead of random mutation, vxTcpFuzzer uses TCP field characteristics as structured features:\nData types Allowed lengths Default/typical values Inter-field constraints State-dependent behavior This ensures that generated packets:\nComply with TCP syntax Follow correct state transitions Maintain sequence/ACK relationships Recalculate dependent fields correctly Mutate options and fields in structured ways This dramatically boosts acceptance rates.\nMemory Feedback Mechanism # Without code coverage, vxTcpFuzzer monitors:\nMemory regions accessed by tNet0, inferred from PC movements Content differences between test iterations If memory changes, the packet is marked as interesting and prioritized for mutation.\nThis becomes a lightweight, indirect coverage metric suitable for black-box systems.\nDual Anomaly Detector # To catch all forms of failure:\nWDB exception detection captures crashes with explicit faults Heartbeat detection catches silent hangs where networking halts without exceptions Together, they provide comprehensive crash monitoring and automated target recovery.\n📊 Experimental Results # Test Setup # vxTcpFuzzer was evaluated on:\nVxWorks 6.6 VxWorks 6.9 VxWorks 6.9_z7 Effectiveness # vxTcpFuzzer achieved:\n44–55% packet acceptance rate (vs. \u0026lt;25% in traditional fuzzers) 24–35% abnormality discovery, indicating deeper traversal of code paths Six confirmed crashes across all devices tested Vulnerabilities Found # Integer Overflow (CVE-2019-12255) # Triggered in VxWorks 6.6 using:\nURG flag set Urgent pointer = 0 Large payload This can crash the network task and potentially lead to remote code execution.\nDenial-of-Service (DoS) # All three versions encountered DoS conditions caused by specially crafted packets that pushed TCP processing into unstable logic paths, freezing network responsiveness.\nAnomaly Detection Performance # WDB caught most explicit crashes Heartbeat detection caught silent failures missed by WDB Both mechanisms were essential for robust detection and automated recovery.\n💬 Discussion # Current limitations include:\nManual extraction of TCP field features\nFuture work could incorporate LLM-based protocol modeling.\nTCP-only support\nExtending to UDP, ICMP, ARP, and VxWorks-specific protocols could broaden coverage.\nCoarse memory-based feedback\nMore precise inference of execution paths could improve fuzzing depth.\nCare must also be taken when fuzzing real-time production systems, as aggressive test traffic may destabilize operational environments.\n🏁 Conclusion # vxTcpFuzzer provides an effective, high-acceptance TCP fuzzing solution for VxWorks. By combining:\nProtocol-aware packet generation Memory-based black-box feedback Dual crash detection mechanisms …it significantly improves test quality and vulnerability discovery in embedded systems.\nThis approach strengthens the security posture of IoT devices that depend on VxWorks and demonstrates a viable path toward advanced RTOS fuzzing in closed-source environments.\n","date":"2025-12-07","externalUrl":null,"permalink":"/app/vxworks-tcp-fuzzing-framework-with-memory-aware-feedback/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eA High-Acceptance-Rate VxWorks Fuzzing Framework Using Protocol Features and Memory Feedback\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🚀 Introduction \n    \u003cdiv id=\"-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIoT deployments now reach tens of billions of devices, many of which rely on VxWorks for critical applications in aviation, industrial control, and medical platforms. Vulnerabilities in the TCP stack of VxWorks can have severe consequences, from remote code execution to widespread IoT system compromise.\u003c/p\u003e","title":"VxWorks TCP Fuzzing Framework with Memory-Aware Feedback","type":"app"},{"content":"","date":"2025-12-04","externalUrl":null,"permalink":"/tags/critical-infrastructure/","section":"Tags","summary":"","title":"Critical Infrastructure","type":"tags"},{"content":" 🛡️ Mission-Critical Systems: The Digital Lifeline of the Modern Age\nSince the debut of the Wind River VxWorks RTOS in 1987, Wind River has remained deeply involved in the embedded and edge computing world. Decades of real-world deployments have revealed a simple truth: mission-critical computing is fundamentally different from consumer or enterprise systems.\nEvery application may feel “mission-critical” to someone, but for many commercial scenarios, failure—while painful—does not risk human life.\nBy contrast, the mission-critical environments below demand absolute reliability, microsecond-level responsiveness, and uncompromising isolation. Real customer examples illustrate how such systems are architected.\n✈️ Aerospace # The Software Controlling a Jetliner Cannot Fail # If you have flown on a commercial jet in the last two decades, it almost certainly relied on Wind River software.\nAviation systems are engineered for worst-case scenarios. One foundational protection is isolation, ensuring that failures in one subsystem cannot compromise another. This may be implemented via strong hardware partitioning or a robust hypervisor, allowing multiple safety domains to run independently—even when sharing the same SoC.\n🏥 Medical Systems # A Ventilator Connected to a Patient Cannot Reboot # One patient relied on a ventilator for three uninterrupted years. The device never rebooted.\nA reboot, even a brief one, would be fatal.\nDesigning for this level of continuous operation requires:\nStable long-term resource management Zero-downtime operation Update and security mechanisms that function without rebooting Architectures that preserve system integrity under constant data flow In mission-critical medical systems, these constraints are mandatory—not optional.\n🚀 Space Systems # The Mars Rover Has No “Overnight Maintenance Window” # NASA’s Curiosity rover runs Wind River VxWorks. Like modern vehicles, it receives OTA updates. Unlike vehicles, it cannot simply wait for a parking moment.\nIf an update fails on Earth, a technician can roll back or repair the system.\nIf an update fails on Mars, the rover could be permanently bricked.\nThousands of edge devices—remote sensors, offshore installations, deep industrial systems—face similar constraints. They demand update processes engineered with extreme caution and bulletproof rollback strategies.\n🚗 Automotive # Assisted Driving Systems Must React in Microseconds # Picture an autonomous-capable vehicle entering an intersection just as a fast-moving truck appears. The system must:\nDetect the truck within milliseconds Decide precisely whether to brake or accelerate Override preset control logic if necessary Respond without entering an undefined state This microsecond-level certainty is essential not only in automotive applications but across many modern edge-inference systems requiring instant reaction to real-world events.\n📡 Telecommunications # The Emergency Call Cannot Drop # During the 2025 Eaton Fire in Southern California, a major telecom operator (a Wind River customer) had one priority: ensure 911 calls never drop.\nA dropped call could cost lives.\nAchieving this level of availability required:\nHardware and software isolation Architectures optimized for peak throughput Cost-effective yet highly resilient service delivery This need for unwavering reliability shaped broad architectural decisions, from abstraction layers to the extent of COTS hardware adoption.\n🧭 A New Way of Thinking About System Design # Mission-critical requirements reshape the entire development lifecycle:\nSystems must run for years, even decades Updates must be certifiable and fully validated Hardware choices must consider extremely long lifecycles Compliance and verification processes are far more rigorous “Fail fast, iterate quickly” is often not possible The good news: cross-industry knowledge sharing is accelerating progress.\nWind River and partners such as Aptiv actively contribute to open-source and engineering communities—from IEEE Space Computing to OpenInfra—helping developers design safer, more reliable systems.\n🌐 About Wind River # Wind River is a global leader in software for the intelligent edge. For more than 40 years, Wind River has powered billions of devices requiring the highest levels of safety, security, and reliability—across automotive, aerospace, industrial, medical, and telecommunications industries. The company provides a comprehensive portfolio, backed by global services and an extensive partner ecosystem, enabling mission-critical innovation worldwide.\n","date":"2025-12-04","externalUrl":null,"permalink":"/industries/how-mission-critical-systems-are-built/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003e🛡️ Mission-Critical Systems: The Digital Lifeline of the Modern Age\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eSince the debut of the Wind River \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks RTOS\u003c/a\u003e in 1987, Wind River has remained deeply involved in the embedded and edge computing world. Decades of real-world deployments have revealed a simple truth: \u003cstrong\u003emission-critical computing is fundamentally different\u003c/strong\u003e from consumer or enterprise systems.\u003c/p\u003e","title":"How Mission-Critical Systems Are Built","type":"industries"},{"content":"","date":"2025-12-04","externalUrl":null,"permalink":"/tags/safety/","section":"Tags","summary":"","title":"Safety","type":"tags"},{"content":"","date":"2025-12-02","externalUrl":null,"permalink":"/tags/synaptron/","section":"Tags","summary":"","title":"Synaptron","type":"tags"},{"content":" Wind River has formed a strategic partnership with Synaptron, a pioneer in Artificial Intelligence (AI) and Machine Learning (ML). This collaboration combines Synaptron\u0026rsquo;s advanced AI and predictive analytics with Wind River\u0026rsquo;s trusted cloud and edge platforms, enabling enterprises to design and deploy next-generation intelligent systems faster and more confidently.\nThe cooperation aims to fuse the real-time, mission-critical capabilities of Wind River’s platforms with Synaptron’s high-performance AI models. Through this integration, edge devices can process data using sophisticated machine learning algorithms—delivering actionable insights and enabling intelligent automation directly where it is needed most.\nIndustries such as industrial manufacturing, automotive, and telecommunications stand to gain improved operational efficiency, predictive maintenance, and new autonomous capabilities.\n“AI is driving the future of the intelligent edge. This collaboration with Synaptron puts our customers at the forefront of this transformation.”\n— Rajeev Rawal, Head of Sales for India, ASEAN, and ANZ at Wind River\n🚀 Key Advantages of the Collaboration # Accelerated AI Deployment: Streamlined deployment and management of advanced ML models on Wind River’s secure edge environments. Enhanced Predictive Analytics: Real-time data analysis using Synaptron AI models to enable proactive maintenance and reduce downtime. Intelligent Automation at the Edge: Higher autonomy and faster decision-making without dependency on cloud connectivity. “Wind River’s technology provides the reliability and security essential for mission-critical AI workloads. Together, we will help organizations unlock the full value of their data.”\n— Pranav Merchant, Sales Director at Synaptron\n🌀 About Wind River # Wind River is a global leader in intelligent edge software. For over 40 years, the company has powered billions of devices across industries requiring stringent safety, security, and reliability—such as aerospace, automotive, industrial, medical, and telecommunications. Its comprehensive software portfolio, professional services, and partner ecosystem accelerate digital transformation worldwide.\n🧠 About Synaptron # Synaptron is an innovator in Artificial Intelligence, specializing in intelligent automation, predictive analytics, and machine learning. The company helps enterprises transform operations and unlock new capabilities through data-driven insights and advanced AI solutions.\n","date":"2025-12-02","externalUrl":null,"permalink":"/news/wind-river-and-synaptron-team-up-to-accelerate-ai-driven-intelligent-systems/","section":"News","summary":"\u003c!--## 🤝 Wind River and Synaptron Partner to Accelerate AI-Enabled Intelligent Systems--\u003e\n\u003cp\u003eWind River has formed a strategic partnership with Synaptron, a pioneer in Artificial Intelligence (AI) and Machine Learning (ML). This collaboration combines Synaptron\u0026rsquo;s advanced AI and predictive analytics with Wind River\u0026rsquo;s trusted cloud and edge platforms, enabling enterprises to design and deploy next-generation intelligent systems faster and more confidently.\u003c/p\u003e","title":"Wind River \u0026 Synaptron Team Up to Accelerate AI-Driven Intelligent Systems","type":"news"},{"content":"","date":"2025-11-30","externalUrl":null,"permalink":"/tags/kernel-hardening/","section":"Tags","summary":"","title":"Kernel Hardening","type":"tags"},{"content":"","date":"2025-11-30","externalUrl":null,"permalink":"/tags/rtos-security/","section":"Tags","summary":"","title":"RTOS Security","type":"tags"},{"content":" Modern aircraft are no longer just mechanical systems—they are airborne data centers. With connectivity to satellites, ground stations, and UAV networks, the attack surface has expanded dramatically.\nAt the heart of these systems lies the Real-Time Operating System (RTOS). If an attacker compromises the OS, they compromise everything.\nThis article explores how VxWorks 7’s Kernel Hardening mechanisms perform under real academic testing and what they mean for avionics security.\n🛡️ What Is Kernel Hardening? # Kernel hardening refers to a suite of defensive mechanisms designed to strengthen the OS kernel against memory corruption, unauthorized code execution, and exploit techniques.\nIn the evaluated VxWorks 7 system, the following defenses were analyzed:\nGuard Pages # Extra protected memory regions are placed around:\nInterrupt stacks Kernel task stacks If a buffer overflow spills past its boundaries, the guard page immediately triggers a fault instead of corrupting adjacent memory.\nNon-Executable (NX) Memory # The kernel marks key memory areas as non-executable, including:\nHeap Stack Data sections Only the .text segment is executable. This prevents attackers from injecting code into writable memory regions.\nWrite Protection # VxWorks 7 enforces write protection on:\nThe .text segment The exception vector table This stops malicious or buggy code from modifying the OS’s executable instructions.\n🧪 The Stress Test: Does Hardening Actually Work? # Researchers tested VxWorks 7 using two classic vulnerability categories:\nCWE-121: Buffer Overflows CWE-134: Format String Vulnerabilities The goal: determine whether the kernel defenses truly prevent exploitation.\n💥 Buffer Overflow Attack Results # A buffer overflow occurs when data exceeds buffer boundaries and overwrites adjacent memory—often the return pointer, enabling attackers to hijack control flow.\nWithout Hardening # The vulnerable program successfully overwrote the return pointer.\nThis represents a critical compromise pathway.\nWith Hardening Enabled # The MMU detected the illegal write immediately. In response, the system:\nTerminated the operation Ejected the file system Stopped processing to prevent further corruption This prevented arbitrary memory writes, blocking attacker control.\nHowever, the defense triggered a system crash, requiring a manual reboot.\nVerdict: Protection Works (with a Cost) # VxWorks 7 prevented control-flow hijacking entirely, but its defensive reaction caused a Denial of Service.\nIn avionics, this trade-off—safety over continuity—is expected.\n🧵 Format String Vulnerability Results # Format string bugs allow attackers to:\nLeak memory data Write arbitrary values to memory Data Leakage Attempt # Even with hardening:\nStack addresses could still be printed But MMU protection prevented reading the underlying memory contents Leaking pointers still exposes system layout information—useful for attackers.\nWrite Attempt # When attempting to write data via the vulnerability, the hardened kernel:\nBlocked the invalid write Halted the process to maintain system integrity Verdict # Hardening significantly reduced the damage potential, stopping write-based attacks while limiting data exposure.\n🧭 Final Analysis # VxWorks 7’s kernel hardening features are effective and practical, not just theoretical.\nThe Strengths # Full protection against buffer overflow code execution attempts Write-based attacks consistently blocked Kernel integrity preserved even under active exploitation The Trade-offs # Hardening responses frequently cause Denial of Service A system reboot may be required after protection triggers Some non-sensitive stack data can still be leaked via format string misuse In avionics, safety outweighs uptime, making these trade-offs acceptable.\nThe Bigger Picture # Kernel hardening is not a substitute for secure software development.\nThe best protection is still:\nDefensive coding Input validation Safe API usage Memory-safe development practices Hardening mitigates symptoms, not the root cause—but when needed, it proves highly effective.\n","date":"2025-11-30","externalUrl":null,"permalink":"/bsp/secure-skies-kernel-hardening-in-vxworks-7-explained/","section":"Bsps","summary":"\u003c!--# ✈️ Secure Skies: A Deep Dive into Kernel Hardening in VxWorks 7--\u003e\n\u003cp\u003eModern aircraft are no longer just mechanical systems—they are \u003cstrong\u003eairborne data centers\u003c/strong\u003e. With connectivity to satellites, ground stations, and UAV networks, the \u003cstrong\u003eattack surface\u003c/strong\u003e has expanded dramatically.\u003c/p\u003e","title":"Secure Skies: Kernel Hardening in VxWorks 7 Explained","type":"bsp"},{"content":"","date":"2025-11-24","externalUrl":null,"permalink":"/tags/hyundai-rotem/","section":"Tags","summary":"","title":"Hyundai Rotem","type":"tags"},{"content":"","date":"2025-11-24","externalUrl":null,"permalink":"/tags/industrial/","section":"Tags","summary":"","title":"Industrial","type":"tags"},{"content":"","date":"2025-11-24","externalUrl":null,"permalink":"/tags/railway/","section":"Tags","summary":"","title":"Railway","type":"tags"},{"content":" Wind River, an Aptiv company and a leader in intelligent edge software, has announced a major expansion of its long-term collaboration with Hyundai Rotem, a global provider of rail solutions and smart logistics systems. Hyundai Rotem will adopt Wind River® Studio Developer to modernize, automate, and scale its software development environment for next-generation industrial rail systems.\nBuilding on a partnership spanning more than 30 years—and Hyundai Rotem’s extensive use of VxWorks®—this transition represents a major step toward a software-defined, cloud-native development model across the company’s rail and transportation platforms.\n“Using Wind River solutions, Hyundai Rotem can modernize its software practices while ensuring safety, security, and quality,”\n—Javed Khan, President, Software, Advanced Safety and User Experience, Aptiv\n“By leveraging Wind River technology, we are accelerating software-defined capabilities that enhance automation, innovation, and long-term ROI,”\n—Won-Sang Lee, Vice President and CTO, RS R\u0026amp;D Center, Hyundai Rotem\nEnabling Software-Defined Rail Systems # Hyundai Rotem will adopt Studio Developer, Wind River’s modern DevOps platform designed for mission-critical intelligent edge systems. Key capabilities include:\nContinuous integration and continuous delivery (CI/CD) Cloud-native workflows and deployment Automated testing and shift-left development Improved collaboration across engineering teams Lifecycle extension through better automation and traceability These capabilities help overcome traditional barriers to automation and modernization in large-scale industrial software environments.\nTo support this transformation, Hyundai Rotem will deploy Wind River Cloud Platform as the hosting infrastructure for Studio Developer—providing a robust, private, on-premises cloud environment tailored for mission-critical rail workloads.\nAt the system level, Hyundai Rotem will continue to rely on VxWorks, the industry-leading safety-certified RTOS, for its signaling systems, train control management systems, and other safety-critical components. The combination of cloud-native DevOps with a proven safety platform positions the company to accelerate development while maintaining stringent reliability and certification standards.\nWind River Studio Developer: Designed for Intelligent Edge Transformation # Studio Developer provides a unified environment for developing, deploying, and operating mission-critical systems across distributed, intelligent edge platforms. Its benefits include:\nFaster automation pipelines Reduced integration overhead Enhanced agility in iterative development Support for long lifecycle industrial systems Cloud-native scalability for complex edge deployments Likewise, Wind River Cloud Platform offers a stable, secure foundation for deploying and managing advanced cloud architectures in environments where reliability, determinism, and compliance are paramount.\nAbout Wind River # Wind River is a leader in intelligent edge software, enabling the world’s most critical systems for more than 40 years. Its technology powers billions of devices across aerospace, automotive, industrial, medical, and telecommunications sectors. The company provides a comprehensive software portfolio, supported by global professional services and an extensive partner ecosystem.\nAbout Hyundai Rotem # Hyundai Rotem is a global technology company specializing in railway solutions, eco-friendly plants, and smart logistics. Its logistics portfolio includes AGVs, AMRs, and automated warehouse systems designed to improve operational efficiency. More information is available on Hyundai Rotem’s official website.\n","date":"2025-11-24","externalUrl":null,"permalink":"/news/wind-river-and-hyundai-rotem-modernize-rail-software-with-cloud-native-devops/","section":"News","summary":"\u003c!--# Wind River and Hyundai Rotem Modernize Rail Software with Cloud-Native DevOps--\u003e\n\u003cp\u003eWind River, an Aptiv company and a leader in intelligent edge software, has announced a major expansion of its long-term collaboration with \u003cstrong\u003eHyundai Rotem\u003c/strong\u003e, a global provider of rail solutions and smart logistics systems. Hyundai Rotem will adopt \u003cstrong\u003eWind River® Studio Developer\u003c/strong\u003e to modernize, automate, and scale its software development environment for next-generation industrial rail systems.\u003c/p\u003e","title":"Wind River and Hyundai Rotem Modernize Rail Software with Cloud-Native DevOps","type":"news"},{"content":"","date":"2025-11-19","externalUrl":null,"permalink":"/tags/elxr-pro/","section":"Tags","summary":"","title":"ELxr Pro","type":"tags"},{"content":"","date":"2025-11-19","externalUrl":null,"permalink":"/tags/mlsoc/","section":"Tags","summary":"","title":"MLSoC","type":"tags"},{"content":"","date":"2025-11-19","externalUrl":null,"permalink":"/tags/sima.ai/","section":"Tags","summary":"","title":"SiMa.ai","type":"tags"},{"content":"","date":"2025-11-19","externalUrl":null,"permalink":"/video/","section":"Videoes","summary":"","title":"Videoes","type":"video"},{"content":"Learn how SiMa.ai and Wind River have partnered to deliver an integrated edge AI platform that combines SIMA.ai\u0026rsquo;s Machine Learning System-on-Chip (MLSoC) and Palette software with Wind River’s eLxr Pro. This joint solution enables high-performance, energy-efficient, and secure AI/ML development for robotics, medical, industrial, and other critical edge applications.\n","date":"2025-11-19","externalUrl":null,"permalink":"/video/wind-river-reformers-spotlight-on-sima.ai/","section":"Videoes","summary":"\u003cp\u003eLearn how SiMa.ai and Wind River have partnered to deliver an integrated edge AI platform that combines SIMA.ai\u0026rsquo;s Machine Learning System-on-Chip (MLSoC) and Palette software with Wind River’s eLxr Pro. This joint solution enables high-performance, energy-efficient, and secure AI/ML development for robotics, medical, industrial, and other critical edge applications.\u003c/p\u003e","title":"Wind River Reformers: Spotlight on SiMa.ai","type":"video"},{"content":"","date":"2025-11-16","externalUrl":null,"permalink":"/tags/servicenow/","section":"Tags","summary":"","title":"ServiceNow","type":"tags"},{"content":" Wind River, an Aptiv company and a global leader in intelligent edge software, has partnered with ServiceNow to deliver a next-generation solution that enables enterprises worldwide to host the ServiceNow AI Platform directly within their own data centers. Powered by the Wind River Cloud Platform, this architecture allows organizations to deploy, scale, upgrade, and operate ServiceNow applications locally for maximum data control, security, and governance.\nThe Wind River Cloud Platform provides proven six-nines (99.9999%) availability, delivering a highly resilient private cloud foundation suitable for mission-critical and large-scale enterprise workloads. Beyond supporting the ServiceNow AI Platform, it can run diverse applications and services on a unified infrastructure—ideal for global industries that must ensure data sovereignty, meet regulatory requirements, and maintain strict operational performance.\nThis combined solution enables enterprises to achieve IT/OT convergence, build hybrid architectures, and leverage intelligent automation while maintaining full ownership of data, infrastructure, and workflows.\n“As enterprises modernize their infrastructure to meet increasing demands for data control, compliance, and operational agility, the convergence of IT and OT through a sovereign private cloud is no longer an option—it is essential. This joint solution from Wind River and ServiceNow enables organizations to unify digital workflows with real-time operations while maintaining complete control over data and infrastructure.” — Sandeep Modhvadia, Chief Product Officer, Wind River\n“As enterprises embrace the intelligent era, cybersecurity and resilience must be embedded into every layer of the business. The Wind River Cloud Platform, built on the ServiceNow AI Platform, enables customers to proactively manage risks, streamline compliance workflows, and secure their operations with confidence.” — Michael Park, Senior Vice President of Global Partners and Channels, ServiceNow\nTogether, Wind River and ServiceNow are enabling enterprises to run AI-powered workloads on-premises with the security and control of a true private cloud—without sacrificing scale, performance, or compliance. Real-time processing, automated workflows, and Agentic AI capabilities allow organizations to detect anomalies, act autonomously, and accelerate decision-making across global operations.\n✨ Key Benefits of the Joint Wind River–ServiceNow Solution # Automated Activation of ServiceNow AI Applications\nStreamlines deployment with built-in automation, reducing complexity and accelerating time-to-value for global IT teams.\nIntelligent Lifecycle and Operations Management\nWind River’s orchestration capabilities ensure smooth updates, predictable performance, and resilient uptime.\nData Sovereignty and Infrastructure Control\nEnsures compliance with international regulations by keeping AI workloads and sensitive data on-premises.\nReal-Time Edge Performance\nProcesses data closer to the source, improving responsiveness, reducing latency, and enhancing operational reliability.\nUnified, Scalable Infrastructure\nRuns diverse enterprise workloads—from AI inference to mission-critical operations—on a secure private cloud with integrated IT/OT environments.\n🧩 Platform Overview # Wind River Cloud Platform # A production-grade, open-source-based private cloud designed for both virtualized and containerized workloads. It features distributed Kubernetes infrastructure, automation tools, and analytics designed for high-reliability environments across telecom, industrial, and enterprise sectors.\nServiceNow AI Platform # A unified AI-driven productivity and workflow platform that integrates enterprise applications, automation tools, low-code development, and advanced analytics. It helps organizations modernize operations, reduce costs, and unlock new efficiencies across global business processes.\nThis global-ready private cloud solution from Wind River and ServiceNow empowers enterprises to meet modern AI demands while maintaining full control, security, and operational resilience.\n","date":"2025-11-16","externalUrl":null,"permalink":"/news/wind-river-and-servicenow-launch-ai-ready-private-cloud-for-global-enterprises/","section":"News","summary":"\u003c!--# ☁️ Wind River and ServiceNow Launch AI-Ready Private Cloud for Global Enterprises--\u003e\n\u003cp\u003e\u003cstrong\u003eWind River\u003c/strong\u003e, an Aptiv company and a global leader in intelligent edge software, has partnered with \u003cstrong\u003eServiceNow\u003c/strong\u003e to deliver a next-generation solution that enables enterprises worldwide to host the \u003cstrong\u003eServiceNow AI Platform\u003c/strong\u003e directly within their own data centers. Powered by the \u003cstrong\u003eWind River Cloud Platform\u003c/strong\u003e, this architecture allows organizations to deploy, scale, upgrade, and operate ServiceNow applications locally for maximum data control, security, and governance.\u003c/p\u003e","title":"Wind River and ServiceNow Launch AI-Ready Private Cloud for Global Enterprises","type":"news"},{"content":"","date":"2025-10-23","externalUrl":null,"permalink":"/tags/cloud/","section":"Tags","summary":"","title":"Cloud","type":"tags"},{"content":"","date":"2025-10-23","externalUrl":null,"permalink":"/tags/infrastructure/","section":"Tags","summary":"","title":"Infrastructure","type":"tags"},{"content":"","date":"2025-10-23","externalUrl":null,"permalink":"/tags/starlingx/","section":"Tags","summary":"","title":"StarlingX","type":"tags"},{"content":" As IT teams face shrinking budgets and limited staffing, managing distributed infrastructure has become increasingly complex. For organizations still constrained by VMware’s licensing model, rising costs and operational pressure have pushed many to reconsider the foundations of their IT environments.\nA growing number of enterprises are turning to openness—not just open-source technologies, but also the commitment to deliver enterprise-grade reliability on an open foundation.\nVMware has been a central pillar of enterprise virtualization for decades. But recent portfolio shifts and licensing changes have increased both costs and constraints. As a result, many organizations are planning their next infrastructure cycle from a zero-based perspective, rethinking everything from cost structure to operational strategy.\n🧱 Operational Efficiency Takes Center Stage # When redesigning or upgrading IT infrastructure, operational expenditure (OpEx) is a primary concern. Enterprises must maintain consistent and reliable operations across diverse environments—factories, logistics hubs, retail sites, customer service centers, and more.\nAt the same time, avoiding vendor lock-in has become a strategic priority. Open-source platforms offer choice, flexibility, and faster paths to adopt new technologies. But none of that matters unless the platform maintains non-negotiable reliability, especially for business-critical operations.\n🔒 Wind River: Mission-Critical Reliability for Enterprise Cloud # Wind River brings decades of experience delivering real-time, mission-critical operating systems to aerospace, medical, industrial automation, and telecom markets. Today, it is applying that proven reliability to the enterprise cloud.\nThe Wind River Cloud Platform, built on open-source technologies including StarlingX, Kubernetes, and OpenStack, provides:\nUp to six nines (99.9999%) high availability Non-disruptive scalability across more than 50,000 nodes Field-proven stability in production networks operated by Verizon, Vodafone, and others The platform’s resilience comes from advanced automation and self-healing capabilities that ensure continuous operation—even during connectivity disruptions. By combining high availability with streamlined operations, enterprises can maintain uptime while reducing manual effort.\n🧨 Simplifying Cost and Licensing Models # Traditional IaaS products such as VMware typically charge based on virtual machines or CPU cores—models that can become expensive and limiting as workloads scale.\nWind River takes a different approach with a per-node pricing model.\nThis helps enterprises:\nChoose the right hardware without fear of triggering additional licensing penalties Scale more predictably Avoid performance compromises driven by cost constraints 🛑 Unified Management for Distributed Operations # At the heart of the Wind River Cloud Platform is StarlingX, a system designed for low-latency, high-performance edge environments and built on a latency-optimized Debian GNU/Linux base.\nA single system controller can manage up to 5,000 subclouds, offering centralized visibility and control across:\nBranch offices Production plants Warehouses Retail stores Remote or harsh-environment sites Wind River is also a major contributor to the StarlingX community, continuously upstreaming its engineering work while enhancing its commercial platform with advanced deployment, migration, and lifecycle management tools.\n✅ Automation and Analytics for Intelligent Operations # The platform integrates two critical operational tools: Conductor and Analytics.\nConductor provides zero-touch orchestration, enabling automated deployment and lifecycle management across distributed cloud environments. Analytics collects and interprets system data to improve performance, optimize availability, and help prevent issues before they occur. Together, these tools significantly reduce operational burden while increasing the intelligence of infrastructure management.\n🔍 Why Open, On-Premises Private Cloud Matters Now # As enterprises accelerate digital transformation—from engineering workflows to manufacturing to retail—their IT environments become increasingly fragmented and geographically distributed. Managing these systems in silos only increases operational costs and risk.\nTo ensure long-term sustainability and future innovation, enterprises need a stable, unified, open model for managing distributed infrastructure.\nOpen-source, on-premises private cloud solutions such as the Wind River Cloud Platform provide:\nHigh scalability Telecom-grade reliability Predictable costs Freedom from proprietary lock-in These capabilities are becoming essential as organizations navigate the post-VMware landscape and build a cloud foundation that is robust, flexible, and ready for the next decade of digital operations.\n","date":"2025-10-23","externalUrl":null,"permalink":"/news/the-post-vmware-cloud-a-new-infrastructure-strategy/","section":"News","summary":"\u003c!--# The Post-VMware Cloud: A New Infrastructure Strategy--\u003e\n\u003cp\u003eAs IT teams face shrinking budgets and limited staffing, managing distributed infrastructure has become increasingly complex. For organizations still constrained by VMware’s licensing model, rising costs and operational pressure have pushed many to reconsider the foundations of their IT environments.\u003c/p\u003e","title":"The Post-VMware Cloud: A New Infrastructure Strategy","type":"news"},{"content":"","date":"2025-10-23","externalUrl":null,"permalink":"/tags/vmware/","section":"Tags","summary":"","title":"VMware","type":"tags"},{"content":"Explore how a modular, nondisruptive testing framework can seamlessly integrate into your existing development environment with no rip and replace required. By eliminating common challenges tied to traditional testing approaches, such as hardware dependencies, simulation complexity, and test coverage limitations, this approach enables teams to enhance efficiency without overhauling their toolchain. We will walk through real-world applications, including insights from a leading Tier 1 supplier, to show how these capabilities translate to measurable efficiency gains in embedded DevSecOps pipelines.\nKEY TAKEAWAYS:\nUnderstand the pain points of traditional embedded software testing and how to overcome them. Discover how modular, stand-alone testing fits into existing DevSecOps workflows without requiring full stack replacements. Hear from an industry leader applying these solutions in live automotive projects. Whether you are exploring automated testing solutions or scaling existing processes, this session will provide practical knowledge to drive quality and innovation forward.\n","date":"2025-10-15","externalUrl":null,"permalink":"/video/accelerating-embedded-software-testing-with-modular-automation/","section":"Videoes","summary":"\u003cp\u003eExplore how a modular, nondisruptive testing framework can seamlessly integrate into your existing development environment with no rip and replace required. By eliminating common challenges tied to traditional testing approaches, such as hardware dependencies, simulation complexity, and test coverage limitations, this approach enables teams to enhance efficiency without overhauling their toolchain. We will walk through real-world applications, including insights from a leading Tier 1 supplier, to show how these capabilities translate to measurable efficiency gains in embedded DevSecOps pipelines.\u003c/p\u003e","title":"Accelerating Embedded Software Testing With Modular Automation","type":"video"},{"content":"","date":"2025-10-15","externalUrl":null,"permalink":"/tags/modular-automation/","section":"Tags","summary":"","title":"Modular Automation","type":"tags"},{"content":"","date":"2025-10-04","externalUrl":null,"permalink":"/tags/black-box/","section":"Tags","summary":"","title":"Black Box","type":"tags"},{"content":"","date":"2025-10-04","externalUrl":null,"permalink":"/tags/smart-edge/","section":"Tags","summary":"","title":"Smart Edge","type":"tags"},{"content":" Black Box®, a long-established IT solutions provider known for its innovation in digital infrastructure, has formed a strategic partnership with Wind River, an Aptiv company and a global leader in intelligent edge software. Together, the companies aim to deliver next-generation intelligent edge and private cloud solutions for industries such as manufacturing, industrial operations, telecommunications, retail, finance, and automotive.\nUniting Cloud, Edge, and Integration Expertise # This collaboration combines:\nWind River Cloud Platform, a production-grade distributed Kubernetes solution Wind River eLxr Pro, an enterprise-grade Linux distribution Black Box’s global integration and deployment expertise The goal is to help enterprises accelerate modernization, enhance operational efficiency, and scale cloud-to-edge digital transformation with confidence.\nBlack Box’s service-driven model and Wind River’s advanced cloud-native technologies collectively aim to provide enterprises with resilient, secure, and high-performance infrastructure across diverse mission-critical environments.\nWind River Cloud Platform and eLxr Pro # Wind River Cloud Platform # A fully integrated Kubernetes platform designed for virtualized and containerized workloads, optimized for:\nComplex distributed architectures Automated orchestration and lifecycle management High-reliability, mission-critical deployments The platform is widely used for intelligent edge environments where uptime, security, and deterministic performance are key requirements.\nWind River eLxr Pro # Built on the open-source eLxr Debian-derivative project, eLxr Pro adds:\nCommercial-grade enterprise support Long-term maintenance Security patching and compliance features This allows organizations to deploy secure, scalable Linux solutions that power workloads from cloud to edge with confidence and reliability.\nExpanded Global Agreement # As part of the partnership framework, Black Box has also entered into a broader agreement with Wind River to execute end-user contracts across multiple global regions, further strengthening deployment and support capabilities.\nExecutive Perspectives # “By partnering with Black Box, we are unleashing this capability at scale… This will help customers accelerate innovation, reduce risk, and enable smarter operations across the entire cloud-to-edge continuum.”\n— Darrell Jordan-Smith, Chief Revenue Officer, Wind River\n“This partnership marks Black Box’s entry into the hyper-converged and edge computing space… creating long-term value for our customers and shareholders.”\n— Sanjeev Verma, President and CEO, Black Box\nFocus Areas of the Collaboration # The strategic partnership will deliver:\nIntegrated intelligent edge and cloud-native digital infrastructure Secure, scalable private cloud platforms Automated lifecycle management and centralized orchestration Support for VMs, workload migration, containers, and AI pipelines Enterprise-grade Linux with long-term support and hardened security Looking Ahead # Wind River and Black Box share a common mission: to empower enterprises with reliable, secure, and high-performance digital infrastructure tailored to modern operational and compliance requirements. As organizations shift toward distributed cloud and edge architectures, the combined strengths of both companies position them to accelerate innovation across industries worldwide.\n","date":"2025-10-04","externalUrl":null,"permalink":"/news/wind-river-and-black-box-partner-on-smart-edge-and-cloud/","section":"News","summary":"\u003c!--# Wind River \u0026 Black Box Partner on Smart Edge and Cloud--\u003e\n\u003cp\u003eBlack Box®, a long-established IT solutions provider known for its innovation in digital infrastructure, has formed a \u003cstrong\u003estrategic partnership\u003c/strong\u003e with \u003cstrong\u003eWind River\u003c/strong\u003e, an Aptiv company and a global leader in intelligent edge software. Together, the companies aim to deliver next-generation \u003cstrong\u003eintelligent edge\u003c/strong\u003e and \u003cstrong\u003eprivate cloud\u003c/strong\u003e solutions for industries such as manufacturing, industrial operations, telecommunications, retail, finance, and automotive.\u003c/p\u003e","title":"Wind River \u0026 Black Box Partner on Smart Edge and Cloud","type":"news"},{"content":"","date":"2025-09-25","externalUrl":null,"permalink":"/tags/ai-driven-systems/","section":"Tags","summary":"","title":"AI-Driven Systems","type":"tags"},{"content":"","date":"2025-09-25","externalUrl":null,"permalink":"/tags/automotive-technology/","section":"Tags","summary":"","title":"Automotive Technology","type":"tags"},{"content":"","date":"2025-09-25","externalUrl":null,"permalink":"/tags/cloud-native-devsecops/","section":"Tags","summary":"","title":"Cloud-Native DevSecOps","type":"tags"},{"content":"","date":"2025-09-25","externalUrl":null,"permalink":"/tags/hyundai-mobis/","section":"Tags","summary":"","title":"Hyundai Mobis","type":"tags"},{"content":"","date":"2025-09-25","externalUrl":null,"permalink":"/tags/software-defined-vehicle/","section":"Tags","summary":"","title":"Software-Defined Vehicle","type":"tags"},{"content":"Wind River, a leader in intelligent edge software and an Aptiv company, has successfully completed the Mobis Development Studio in partnership with Hyundai Mobis. This collaboration aims to drive innovation in the development of Software-Defined Vehicles (SDVs) by combining Hyundai Mobis\u0026rsquo; cloud-based vehicle development infrastructure with Wind River Studio Developer. The platform promises to accelerate SDV development, enhancing both software quality and efficiency.\nWhat is the Mobis Development Studio? # The Mobis Development Studio is a cutting-edge, web-based software development environment designed specifically for the automotive industry. It integrates advanced features like an intuitive user interface tailored for Electronic Control Units (ECUs), high-speed build capabilities, and automated testing tools. This platform significantly improves the software lifecycle management for SDVs, enabling Hyundai Mobis to transition into a software-driven mobility technology leader.\nKey features include:\nHigh-speed builds to streamline development workflows Automated testing tools to ensure reliability and efficiency Collaboration tools to support global development teams Shift-left testing for earlier validation in the lifecycle By leveraging these capabilities, Mobis Development Studio supports faster innovation and reduces development time for SDVs.\nEnhancing SDV Development with Wind River Studio Developer # Wind River Studio Developer plays a pivotal role in the Mobis Development Studio. This cloud-native DevSecOps platform is designed to accelerate mission-critical system development at the intelligent edge. The platform enables:\nAgile development practices such as Continuous Integration (CI), Continuous Delivery (CD), and Continuous Testing (CT) Enhanced collaboration through real-time tools and resources Shift-left testing, allowing for early validation of software quality These features ensure that automakers can rapidly design, develop, and deploy SDVs while maintaining high standards of security, reliability, and performance.\nSandeep Modhvadia, Chief Product Officer at Wind River, shares:\n\u0026ldquo;As the automotive industry continues to evolve towards a smarter, more autonomous future, software has become a key driver of this transformation. Through our collaboration with Hyundai Mobis, we have introduced a next-generation development framework that spans cloud and edge environments, providing robust lifecycle management capabilities. Together, we are helping automakers accelerate innovation and hasten the arrival of the Software-Defined Vehicle future.\u0026rdquo;\nDriving Innovation in Automotive Software # Hyundai Mobis is committed to advancing the automotive industry by driving the development of intelligent, AI-driven vehicle systems. With the Mobis Development Studio, the company aims to improve the automation of the entire vehicle development lifecycle, which will ultimately lead to faster, more efficient development of next-generation intelligent vehicle software.\nSoo-Kyung Jung, Executive Vice President and Head of Automotive Electronics Business Division at Hyundai Mobis, explains:\n\u0026ldquo;We look forward to significantly improving the automation level of the entire vehicle development lifecycle through this cooperation with Wind River. This development environment is not only highly automated but is also rapidly expanding towards a new AI-driven development system.\u0026rdquo;\nWind River\u0026rsquo;s Role in SDV Innovation # Wind River’s expertise in mission-critical edge computing is fundamental to the success of the Mobis Development Studio. As an authorized CVE Numbering Authority (CNA), Wind River can assign CVE IDs for vulnerabilities, allowing global IT and cybersecurity professionals to quickly identify and address security risks, further strengthening the integrity of SDVs.\nWith over four decades of experience in delivering high-quality software and support across industries such as automotive, aerospace, and industrial sectors, Wind River continues to lead the charge in intelligent edge computing.\nKey Benefits of the Mobis Development Studio for SDV Development # By combining the strengths of Wind River and Hyundai Mobis, this collaboration delivers several important benefits for automakers developing SDVs:\nEnhanced software quality and lifecycle management Faster time-to-market for next-gen SDV systems Improved collaboration and automation across development teams Increased security and vulnerability management for automotive systems The Mobis Development Studio enables manufacturers to develop more robust, secure, and intelligent SDV systems that are scalable and sustainable throughout their lifecycle.\nAbout Wind River # Wind River is a global leader in intelligent edge software, providing innovative solutions for industries that demand high levels of safety, security, and reliability. The company’s software supports billions of devices and systems across automotive, aerospace, industrial, medical, and telecommunications industries. Wind River’s comprehensive product portfolio, global professional services, and extensive partner ecosystem accelerate the digital transformation of these sectors.\nKey Takeaways: # Mobis Development Studio accelerates SDV development with intuitive tools and automated testing. Wind River Studio Developer enhances collaboration and agile practices in SDV development. The collaboration aims to improve automation and AI-driven innovation in vehicle systems. For more updates on Software-Defined Vehicles and the latest in automotive technology, stay tuned to Wind River’s news and blog.\n","date":"2025-09-25","externalUrl":null,"permalink":"/news/wind-river-and-hyundai-mobis-partner-to-accelerate-software-defined-vehicle-development/","section":"News","summary":"\u003cp\u003eWind River, a leader in intelligent edge software and an Aptiv company, has successfully completed the \u003cstrong\u003eMobis Development Studio\u003c/strong\u003e in partnership with Hyundai Mobis. This collaboration aims to drive innovation in the development of \u003cstrong\u003eSoftware-Defined Vehicles (SDVs)\u003c/strong\u003e by combining Hyundai Mobis\u0026rsquo; cloud-based vehicle development infrastructure with \u003cstrong\u003eWind River Studio Developer\u003c/strong\u003e. The platform promises to accelerate SDV development, enhancing both software quality and efficiency.\u003c/p\u003e","title":"Wind River and Hyundai Mobis Partner to Accelerate Software-Defined Vehicle Development","type":"news"},{"content":"","date":"2025-09-15","externalUrl":null,"permalink":"/tags/application-development/","section":"Tags","summary":"","title":"Application Development","type":"tags"},{"content":"","date":"2025-09-15","externalUrl":null,"permalink":"/tags/qemu/","section":"Tags","summary":"","title":"QEMU","type":"tags"},{"content":"","date":"2025-09-15","externalUrl":null,"permalink":"/tags/sdk/","section":"Tags","summary":"","title":"SDK","type":"tags"},{"content":"","date":"2025-09-15","externalUrl":null,"permalink":"/tags/vscode/","section":"Tags","summary":"","title":"VSCode","type":"tags"},{"content":" About # The role of the Application Developer is to create Downloadable Kernel Modules (DKMs), Real-Time Processes (RTPs), and libraries for a given VxWorks Source Build (VSB) and VxWorks Image Project (VIP).\nThe Software Development Kit (SDK) equips developers with the necessary tools to compile, debug, and test applications and libraries.\nRTP (Real-Time Process) – An executable application running in user space. RTPs operate in isolated environments, adding robustness. They generate .vxe files which can be loaded from a file system (RomFS, NFS, SD card) or directly through the WRDBG debugger. DKM (Downloadable Kernel Module) – A kernel-mode application with full system and hardware access. DKMs generate .out files which can be linked statically with the kernel, dynamically loaded from a file system, or loaded via WRDBG. Note: RTP applications must use the .vxe extension, and DKM applications must use the .out extension when debugging.\nPrerequisites # Python 3.6+\nLinux sudo apt-get install python3 \u0026amp;\u0026amp; python3 -m pip install -U pip Windows\nDownload Python and select Add Python to PATH during installation. Generated SDK provided by the Platform Developer.\nSDK Directory Structure # An example layout of a generated SDK:\nWRSDK_VXWORKS-7_\u0026lt;VIP_NAME\u0026gt;_\u0026lt;VSB_ARCH\u0026gt;_\u0026lt;HOST_TYPE\u0026gt;_\u0026lt;TIMESTAMP\u0026gt; ├── bsps # BSP images and boot files │ └── \u0026lt;BSP_NAME\u0026gt; │ ├── boot/vxWorks │ ├── uboot/uVxWorks, vxWorks.bin │ └── readme/readme.md ├── toolkit # Developer tools and cross-compilers │ ├── wind_sdk_env.linux / wind_sdk_env.bat │ ├── host_tools │ ├── wrdbg_tools │ ├── sdk_tools/qemu │ ├── bin │ ├── compilers │ ├── include │ └── license ├── artifacts # Optional: artifacts to rebuild VSB/VIP │ ├── \u0026lt;VIP_PROFILE\u0026gt;.cdf │ └── vsb.config ├── examples # Buildable code examples └── docs # VxWorks API \u0026amp; BSP docs └── resources/vxworks-7 Application Development # Command-line # Command-line Prerequisites # Before building applications:\nEnsure prerequisites are met. Enter the base SDK directory. Source the SDK environment to update PATH and environment variables: Linux source toolkit/wind_sdk_env.linux Windows toolkit\\wind_sdk_env.bat Compiling Applications # Application compilation follows typical C/C++ workflows (Make, CMake). Example Makefiles are in examples/makefiles.\nCompiling RTPs # With Makefile\nmake Without Makefile\nLinux:\n$CC rtp.c -o rtp.vxe -static Windows:\n%CC% rtp.c -o rtp.vxe -static Compiling DKMs # With Makefile\nmake Without Makefile\nLinux:\n$CC -dkm dkm.c -o dkm.out Windows:\n%CC% -dkm dkm.c -o dkm.out Compiling CMake RTPs # Copy Preload.cmake and vxsdk_toolchain.cmake from examples/cmakefiles. Create a CMakeLists.txt. Run: cmake -DCMAKE_TOOLCHAIN_FILE=vxsdk_toolchain.cmake . make Running Applications # Running RTPs # wrdbg file \u0026lt;PATH_TO_RTP_APP\u0026gt; run Example:\nfile ~/SDK/examples/hello_world/RTP/hello_world.vxe Running DKMs # wrdbg module load \u0026lt;PATH_TO_DKM_APP\u0026gt; Check with:\nlkup \u0026#34;startHelloWorld\u0026#34; Debugging Applications # Debugging RTPs # wrdbg file ~/SDK/examples/hello_world/RTP/hello_world.vxe See the WRDBG Reference Guide.\nDebugging DKMs # wrdbg module load ~/SDK/examples/hello_world/DKM/hello_world.out task create startHelloWorld Visual Studio Code Extension # VSCode Prerequisites # Ensure prerequisites are met. Complete the VSCode Setup. Creating VSCode Applications # RTP/DKM: Right-click in Explorer → New VxWorks Real Time Process or New VxWorks Downloadable Kernel Module.\nCMake RTPs: Right-click in Explorer → New VxWorks CMake Project.\nCompiling VSCode Applications # RTPs/DKMs: Right-click project → Build Project. CMake RTPs: Right-click project → Build CMake Project. Debugging VSCode Applications # RTPs: Choose Launch RTP in Debugger and run. DKMs: Choose Launch DKM and run. Execution stops at main() initially. VSCode Docker Support # Requires Linux SDK. On Windows, use WSL + Linux SDK.\nInstall Remote - Containers (and Remote - WSL for Windows).\nReopen SDK folder in Container mode.\nBooting a VxWorks Target # Option 1: Hardware – Refer to BSP-specific README. Option 2: QEMU – Use included emulation support if provided. QEMU Usage # startqemu.py --smp 2 --m 512 -b Or run from SDK tools:\npython toolkit/sdk_tools/qemu/startqemu.py Connecting to a VxWorks Target # wrdbg target connect vxworks7:TCP:\u0026lt;TARGET_IP\u0026gt;:1534 -kernel \u0026lt;PATH_TO_VXWORKS_IMAGE\u0026gt; Example:\ntarget connect vxworks7:TCP:10.10.10.5:1534 -kernel ~/SDK/bsps/ti_sitara/boot/vxWorks Inline Assembly # You can embed assembly with asm:\n#include \u0026#34;vxWorks.h\u0026#34; void main(void) { __asm(\u0026#34;mov ax, bx\u0026#34;); } Multiple instructions:\n#include \u0026#34;vxWorks.h\u0026#34; void main(void) { __asm(\u0026#34;push {fp, lr}; add fp, sp, #4; mov r3, #0; mov r0, r3; pop {fp, pc};\u0026#34;); } Known Limitations # RTP/DKM debugging may leave wrpython2.7 or TCF-server processes running (clean up manually). wrdbg cannot handle user input. For interactive applications, use the serial/virtual console. ","date":"2025-09-15","externalUrl":null,"permalink":"/app/vxworks-7-sdk-application-developer-guide/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003eAbout \n    \u003cdiv id=\"about\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#about\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThe role of the \u003cstrong\u003eApplication Developer\u003c/strong\u003e is to create Downloadable Kernel Modules (DKMs), Real-Time Processes (RTPs), and libraries for a given VxWorks Source Build (VSB) and VxWorks Image Project (VIP).\u003cbr\u003e\nThe Software Development Kit (SDK) equips developers with the necessary tools to compile, debug, and test applications and libraries.\u003c/p\u003e","title":"VxWorks 7 SDK Application Developer Guide","type":"app"},{"content":"","date":"2025-09-11","externalUrl":null,"permalink":"/tags/latent-ai/","section":"Tags","summary":"","title":"Latent AI","type":"tags"},{"content":" Wind River and Latent AI Join Forces on Edge AI # Wind River and Latent AI have announced a strategic partnership to accelerate the adoption of Edge AI in mission-critical infrastructure. The collaboration integrates Wind River’s real-time and embedded platforms with Latent AI’s Efficient Inference Platform (LEIP), delivering secure, deterministic, and power-efficient AI inference at the edge.\nKey Highlights # Integrated AI-RTOS: Combines VxWorks®, Wind River® Linux, and eLxr™ Pro with Latent AI’s LEIP to support secure, certifiable AI workflows from model training to deployment. Efficiency Boost: LEIP compresses AI models by up to 10× while maintaining accuracy, enabling faster, adaptive decision-making in constrained environments. Mission-Critical Focus: Designed for industries where reliability, safety, and compliance are mandatory, from aerospace to defense and industrial automation. “By combining Wind River’s expertise in mission-critical edge computing with Latent AI’s optimization, we’re enabling real-time, adaptive AI in the toughest environments.” — Javed Khan, Aptiv\n“This is a turning point for Edge AI, moving from pilot projects to mission-critical systems—from fighter jets to Mars rovers.” — Jags Kandasamy, Latent AI\nEcosystem and Platforms # VxWorks®: Leading RTOS for high-safety, high-security environments, now supporting OCI-compliant containers. Wind River Linux: A secure, embedded Linux platform for reliable cloud-to-edge deployments. eLxr Pro: Enterprise-grade Debian derivative with commercial support for scalable, long-term edge solutions. This partnership builds on Wind River’s broader Edge AI ecosystem strategy, including collaborations with DEEPX, SiMa.ai, and Nota AI to deliver joint hardware-software solutions and on-device generative AI.\nWith the Wind River–Latent AI integration, developers can now build certifiable AI-driven systems that meet the rigorous standards of critical infrastructure while unlocking real-time intelligence at the tactical edge.\n","date":"2025-09-11","externalUrl":null,"permalink":"/news/wind-river-and-latent-ai-partner-to-advance-edge-ai-for-critical-systems/","section":"News","summary":"\u003ch2 class=\"relative group\"\u003eWind River and Latent AI Join Forces on Edge AI \n    \u003cdiv id=\"wind-river-and-latent-ai-join-forces-on-edge-ai\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#wind-river-and-latent-ai-join-forces-on-edge-ai\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eWind River\u003c/strong\u003e and \u003cstrong\u003eLatent AI\u003c/strong\u003e have announced a strategic partnership to accelerate the adoption of \u003cstrong\u003eEdge AI in mission-critical infrastructure\u003c/strong\u003e. The collaboration integrates Wind River’s real-time and embedded platforms with Latent AI’s \u003cstrong\u003eEfficient Inference Platform (LEIP)\u003c/strong\u003e, delivering \u003cstrong\u003esecure, deterministic, and power-efficient AI inference\u003c/strong\u003e at the edge.\u003c/p\u003e","title":"Wind River and Latent AI Partner to Advance Edge AI for Critical Systems","type":"news"},{"content":" Introduction: Why Security Hardening Matters # In critical environments—such as defense systems, healthcare devices, and industrial automation—security and reliability are non-negotiable. Just as hospitals follow strict safety protocols before surgery, developers of real-time operating systems (RTOS) must follow strict standards to reduce risks of cyberattacks and human error.\nFor VxWorks, Wind River provides a security-hardened kernel profile that maps directly to NIST 800-53 controls. This approach enables compliance, improves resilience, and ensures mission-critical embedded systems are protected from vulnerabilities.\nPrerequisites for Building a Hardened VxWorks Kernel # To follow this guide, you will need:\nIntel target hardware with TPM and Secure Boot support (e.g., Dell Latitude E6540). Two USB flash drives (minimum 4 GB each). A Windows workstation with: Wind River VxWorks 7, SR21.07 Key References and Documentation # Wind River\nVxWorks Hardening Guide Approach VxWorks Hardening Guide NIST\nSP 800-53 Rev 4: Security and Privacy Controls Cybersecurity Framework Understanding NIST 800-53 and Its Role in RTOS Security # NIST 800-53 defines a structured set of outcomes for secure system design. Instead of prescribing strict steps, it outlines security goals that organizations must achieve:\nPrepare the Organization – align processes and technology to produce secure software. Protect the Software – prevent unauthorized access to software components. Produce Well-Secured Software – minimize vulnerabilities in design and implementation. Respond to Vulnerabilities – detect and address risks quickly after release. This framework underpins the VxWorks hardened profile.\nVxWorks Hardened Profile: NIST Compliance in Action # Wind River has aligned VxWorks with NIST 800-53 via the hardened profile, which is structured around five cybersecurity functions:\nIdentify Protect Detect Respond Recover The profile defines three levels of requirements:\nMandatory – required by both Wind River and developers. Discretionary – optional but recommended. Not Applicable – irrelevant for RTOS (desktop-specific). VxWorks Hardened Profile Features # When applied, the hardened profile automatically includes:\nDisk encryption (protecting data at rest). Secrets repository (secure storage of keys and credentials). SSH support for secure access. Kernel hardening protections. Secure loader. Stack smashing protection in RTPs. 🔐 Developers must still implement hardware security features such as secure boot, anti-tampering protections, and patch management.\nHardened Kernel Configurations # You can build the hardened VxWorks kernel in three modes:\nRequired Controls – base set of NIST 800-53 controls. Required + Discretionary Controls – adds networking protections. Development (with shell) – for testing only; never deploy this in production. Step 1: Create Hardened VxWorks Projects # Open Wind River Workbench.\nNavigate to File → New → Example → VxWorks System Setup.\nSelect VxWorks Security Hardened System.\nSet base name: hssHardenedVx1.\nSelect image: development (with shell).\nWorkbench generates:\nhssHardenedVx1_develop_vsb hssHardenedVx1_develop_vip hssHardenedVx1_develop_rtp Apply security-related changes:\n// In rtpPartition.c – set default RTP path #define EX_USE_ROMFS // In scapVxWorks.c – disable SCAP mechanism #define EX_CONFIG_CHECK_SKIP Update DEFAULT_BOOT_LINE with a valid IP and build the projects. Step 2: USB Setup for Hardened VxWorks Kernel # Flashdrive1: copy secure boot keys (db.sig, KEK.sig, PK.sig) and bootloader files. Flashdrive2: create a 2 GB FAT partition for encrypted kernel storage. Step 3: Secure Boot Configuration in BIOS # Insert flashdrive1 and boot into BIOS. Add secure boot keys (db.sig, KEK.sig, PK.sig). Reboot the system; VxWorks should start with the kernel shell. Use the devs command to identify flash drive names:\n-\u0026gt; devs drv refs name 4 [ 3] /ata0a ... 8 [ 3] /romfs 1 [ 3] /ttyS0 Example: flashdrive1 = /bd0a, flashdrive2 = /bd16a.\nStep 4: Stage Two Hardened Projects # Recreate projects with updated device names:\nTrust store vault root → /bd0a Encrypted partition → /bd16a Then repeat USB preparation and boot steps.\nAt this point, you will have a development configuration of the hardened VxWorks kernel.\nNext Steps: Moving from Development to Production # Now that you have a hardened development environment, you can:\nBuild and test secure RTP applications. Deploy .vxe binaries to /romfs. Debug using Wind River tools. For production deployment:\nRebuild projects using “required controls” or “required + discretionary controls”. This removes the kernel shell and ensures only hardened components are included. Frequently Asked Questions (FAQ) # ❓ What is NIST 800-53? # NIST 800-53 is a framework published by the U.S. National Institute of Standards and Technology. It provides security and privacy controls for federal information systems and is widely adopted in defense, aerospace, and industrial sectors.\n❓ Can I use the VxWorks hardened profile on ARM-based targets? # Currently, the hardened profile is supported only on the itl_generic BSP (Intel targets). ARM targets may not support all secure boot and TPM features required for compliance.\n❓ Why shouldn’t I deploy the “development (with shell)” kernel? # The development configuration includes the VxWorks kernel shell, which provides powerful debugging capabilities. However, it also exposes security risks and should never be used in production systems.\n❓ What security features does the hardened profile enable automatically? # It enables disk encryption, secrets repository, SSH support, kernel hardening, secure loader, and stack smashing protection. Developers must add hardware-level protections such as anti-tampering measures and patch management.\n❓ Is VxWorks hardened profile compliant with STIG requirements? # Yes. The VxWorks Hardening Guide is presented in STIG (Security Technical Implementation Guide) format and maps directly to NIST 800-53 controls.\nConclusion # Building a security-hardened VxWorks kernel ensures compliance with NIST 800-53, strengthens embedded system security, and prepares your application for deployment in critical environments.\nBy following the steps in this guide—covering secure boot, USB setup, BIOS configuration, and project rebuilding—you can create a hardened foundation for developing secure, reliable, and resilient RTOS-based applications.\n✅ Best practice: Always use hardened profiles for production and integrate hardware-level protections early in your design.\n","date":"2025-09-08","externalUrl":null,"permalink":"/bsp/building-a-security-hardened-vxworks-kernel/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction: Why Security Hardening Matters \n    \u003cdiv id=\"introduction-why-security-hardening-matters\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction-why-security-hardening-matters\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn critical environments—such as defense systems, healthcare devices, and industrial automation—security and reliability are non-negotiable. Just as hospitals follow strict safety protocols before surgery, developers of \u003cstrong\u003ereal-time operating systems (RTOS)\u003c/strong\u003e must follow strict standards to reduce risks of cyberattacks and human error.\u003c/p\u003e","title":"Building a Security-Hardened VxWorks Kernel","type":"bsp"},{"content":"","date":"2025-09-08","externalUrl":null,"permalink":"/tags/nist-800-53/","section":"Tags","summary":"","title":"NIST 800-53","type":"tags"},{"content":"","date":"2025-09-08","externalUrl":null,"permalink":"/tags/secure-boot/","section":"Tags","summary":"","title":"Secure Boot","type":"tags"},{"content":" by Yichuan Wang 1,2,Jiazhao Han 1,Xi Deng 1 andXinhong Hei 1,2,* 1 School of Computer Science and Engineering, Xi’an University of Technology, Xi’an 710048, China 2 Shaanxi Key Laboratory for Network Computing and Security Technology, Xi’an 710048, China\nAuthor to whom correspondence should be addressed. With the widespread application of Internet of Things (IoT) devices, the security of embedded systems faces severe challenges. As an embedded operating system widely used in critical mission scenarios, the security of the TCP stack in VxWorks directly affects system reliability. However, existing protocol fuzzing methods based on network communication struggle to adapt to the complex state machine and grammatical rules of the TCP. Additionally, the lack of a runtime feedback mechanism for closed-source VxWorks systems leads to low testing efficiency. This paper proposes the vxTcpFuzzer framework, which generates structured test cases by integrating the field features of the TCP. Innovatively, it uses the memory data changes of VxWorks network protocol processing tasks as a coverage metric and combines a dual anomaly detection mechanism (WDB detection and heartbeat detection) to achieve precise anomaly capture. We conducted experimental evaluations on three VxWorks system devices, where vxTcpFuzzer successfully triggered multiple potential vulnerabilities, verifying the framework’s effectiveness. Compared with three existing classic fuzzing schemes, vxTcpFuzzer demonstrates significant advantages in test case acceptance rates (44.94–54.92%) and test system abnormal rates (23.79–34.70%) across the three VxWorks devices. The study confirms that protocol feature fusion and memory feedback mechanisms can effectively enhance the depth and efficiency of protocol fuzzing for VxWorks systems. Furthermore, this approach offers a practical and effective solution for uncovering TCP vulnerabilities in black-box environments.\nKeywords: IoT; fuzzing; TCP; VxWorks; system security; vulnerability detection\n1. Introduction # The Internet of Things (IoT), defined as a collection of objects with embedded systems [1], enables interconnection or wireless communication and has become an indispensable part of our lives. It is projected that the number of connected IoT devices will reach 38 billion by the end of 2025 and rise to 50 billion by 2030 [2]. Meanwhile, IoT technologies have been widely applied in critical infrastructure, industrial sectors, and smart home domains. Critical infrastructures such as power plants, water resources, and transportation systems are vital to national operations, while smart home devices bring convenience to most people. Most of these IoT devices are embedded system objects with firmware and various applications.\nHowever, security threats posed by software vulnerabilities in embedded systems are continuously increasing. For example, Mirai malware [3] infected millions of IoT devices and ordered them to launch large-scale cyberattacks. Due to these attacks, hundreds of thousands of web servers around the world have fallen into a denial of service. In fact, an attacker can also move sideways with vulnerable devices to achieve critical targets. For example, in the work-from-home scenarios during COVID-19, Trend Micro has reported that introducing vulnerable IoT devices to the household will expose employees to malware and attacks that could slip into a company’s network [4]. According to [5,6], more than 1.5 billion cyberattacks have been detected in the first half of 2021, targeting 50 billion embedded devices, including pacemakers, cars, and various IoT devices.\nAs a representative operating system of embedded systems, VxWorks is widely used in various mission-critical scenarios with its high reliability and real-time capabilities. VxWorks is renowned for its unparalleled deterministic performance. It is designed for a scalable, safe, secure, and reliable operating environment ideal for mission-critical computing systems with the highest demands [7]. However, even well-designed VxWorks systems are not invulnerable. Historical research has shown that high-risk exploitable vulnerabilities (such as buffer overflow vulnerabilities [8]) have existed in the core network components of VxWorks systems, which may lead to system crashes or even more severe consequences.\nWith the extensive integration of Internet technologies within embedded systems, particularly the widely used and network-capable VxWorks system, the security assurance of its network system has become particularly crucial. In the network framework of VxWorks, the transmission control protocol (TCP) stack serves as the core module for network communication. Consequently, the security of the TCP stack is directly linked to the stability and protection capability of the entire system. Especially in practical application scenarios, VxWorks is often employed in environments with extremely high security requirements, which further highlights the significance of research on the security of its network protocol stack. Therefore, this paper primarily focuses on the vulnerability detection methods of the TCP protocol in VxWorks. Due to the rich functionality of the TCP protocol (such as reliable transmission and congestion control), complex state model, and various possible exception handling mechanisms, correctly implementing them is challenging [9,10]. As a result, developers may inadvertently introduce serious bugs when implementing the TCP stack [11]. Owing to its complexity and wide application, the TCP has long been a key target for attackers. In recent years, research on vulnerabilities in the TCP has shown that its implementation may have serious security risks such as remote code execution and denial-of-service.\nIn the research on detecting errors in the TCP stack, some studies [12,13,14] have adopted model checking or static and dynamic analysis based on source code to detect errors in TCP implementations. However, these approaches require specific TCP expertise, complex configuration operations, and heavily rely on the source code of the TCP stack. This is undoubtedly difficult to implement for the closed-source VxWorks system. In contrast, network communication-based protocol fuzz testing technology has shown promising prospects in overcoming these issues and has become one of the mainstream methods for automated network protocol vulnerability discovery. Fuzzing is “an automated testing method that uses random data (from files, network protocols, API calls, etc.) as software input to generate a large number of test cases in order to find exploitable vulnerabilities” [15], first proposed by Miller et al. [16] in 1990. Although fuzzing is an effective technique for automatically detecting software vulnerabilities, applying this technology directly to embedded devices that lack visibility and have strong hardware dependencies is challenging [17,18]. First, the methods in [19,20,21,22,23,24,25,26,27] are all current fuzzing approaches targeting various application-layer protocols. They cannot directly control the implementation details or state machines of TCP, which belongs to the transport layer, making it difficult to directly apply these methods to TCP fuzz testing. Second, TCP communication packets adhere to strict syntactic specifications. Most random mutation strategies employed in traditional fuzzing inadvertently violate these grammatical rules, leading to immediate rejection of test cases during the pre-execution syntax validation phase. This highlights the inefficiency of generic mutation strategies for stateful transport-layer protocols. Finally, because internal execution information cannot be obtained from embedded system devices, most existing IoT network protocol fuzzers [19,22,24,25] work in a black-box manner. This leads to the optimization mutation strategies of seeds becoming random and blind, making the entire fuzzing process more like a brute-force attack.\nIn regard to challenges, in this paper, we focus on detecting vulnerabilities in TCP by sending messages to VxWorks devices based on network communication in a black-box environment. Therefore, to develop an efficient fuzz testing framework for the VxWorks TCP protocol stack, the following core challenges must be addressed:\nInherent Specificity of TCP. As a connection-oriented transport-layer protocol, TCP fundamentally differs from application-layer protocols in implementation. Existing network protocol fuzzing tools typically overlook critical TCP aspects, including connection states, sequence number synchronization, retransmission mechanisms, and complex option fields. These limitations render most traditional protocol test case generation methods inapplicable to TCP directly.\nThe black-box testing process lacks effective guidance. In network communication-based fuzz testing, the closed-source nature of VxWorks results in a lack of visibility during the fuzzing process. Consequently, it is almost impossible to obtain the system’s internal execution information to guide the fuzz testing process (as is performed in most typical black-box fuzzers). Therefore, there is a need for a lightweight solution in the black-box environment to acquire feedback information of VxWorks during fuzz testing. This information can then serve as a new coverage metric to guide and optimize subsequent testing.\nTo address the aforementioned challenges, we propose a high-acceptance-rate network fuzz testing framework for VxWorks, which integrates protocol features and memory extraction and is named vxTcpFuzzer. vxTcpFuzzer consists of three key technologies. First, we implement a fuzzing method based on protocol feature fusion. This method extracts TCP field features and integrates them into the test case generation process to produce highly structured test cases with a higher acceptance rate. Meanwhile, it takes into account the multiple states of TCP and state transitions and sequentially performs coverage testing on all server states. Second, we extract memory data of the network protocol processing tasks in VxWorks and use changes in task memory data during testing as feedback to guide the direction of fuzzing. Specifically, we can obtain the content of the memory area being executed by the network protocol processing task (tNet0) according to the value of its program counter (PC) register. This enables us to detect changes in the memory data executed by the task before and after each round of testing. The changes in task memory data are then used as feedback information during testing to form a new coverage metric, which guides and optimizes subsequent fuzzing. Finally, we implement a dual anomaly detection mechanism to detect whether anomalies occur in VxWorks during fuzzing. By improving the Wind River DeBug (WDB) detection mechanism and skillfully combining it with a heartbeat detection mechanism, a more comprehensive anomaly detection mechanism is achieved. Our main contributions are summarized as follows:\nA novel fuzzing framework. We propose a network communication-based fuzzing framework, vxTcpFuzzer, specifically designed for TCP in VxWorks systems under black-box environments. vxTcpFuzzer can bypass the encapsulation logic of the local kernel protocol stack, construct TCP packets with arbitrary data, and perform fuzzing.\nA new method. We adopt a new method to implement an automated, multi-state coverage TCP fuzzing framework, vxTcpFuzzer. vxTcpFuzzer includes a test case generation method that integrates protocol features, a feedback guidance method that extracts memory data, and a dual anomaly detection mechanism that detects the state of the test system from multiple aspects.\nImplementation and vulnerability discovery. We implement the designed fuzzing framework vxTcpFuzzer and evaluate it on three types of VxWorks devices. During testing, six crashes were successfully triggered, verifying the effectiveness of the proposed framework. Meanwhile, a comparison with three advanced fuzzing schemes was conducted, revealing their inapplicability.\nThe remaining parts of this paper are structured as follows: Section 2 introduces the background and motivation of this work. Section 3 elaborates on the implementation details of the proposed fuzzing framework vxTcpFuzzer. Section 4 presents our experimental results and comparisons with three fuzzing schemes. Section 5 discusses the existing limitations of this work and prospects for future work. Finally, Section 6 provides a summary of this work.\n2. Background and Motivation # 2.1. Overview of the TCP Protocol # TCP is a connection-oriented, reliable, byte-stream-based transport layer communication protocol defined by the IETF’s RFC 793 [28]. In the simplified OSI model of computer networks, it performs the functions specified by the fourth layer, the transport layer. In practical applications, the TCP has different implementations, forming various TCP stacks. For example, there are kernel-level TCP stacks such as Linux TCP and FreeBSD TCP, as well as user-level TCP stacks like mTCP and TLDK. The VxWorks system employs a protocol stack modified from BSD4.4 TCP/IP, which has been optimized for real-time performance [29], including optimizations such as the addition of zero-copy technology at the TCP layer. However, all these TCP stacks follow the TCP/IP standard protocol and have the same protocol format and state machine.\nThe TCP packet has a fixed format. Figure 1 shows the format of the TCP protocol header. The TCP header is a fixed-length structure composed of different fields, which contain key information for reliable transmission control. These fields work together to ensure that TCP provides reliable, ordered, and error-free data transmission. Through the coordination of sequence numbers, acknowledgment numbers, and window sizes, TCP implements functions such as retransmission, flow control, and congestion control. To ensure that no packets are lost, TCP assigns a sequence number to each packet, and the sequence numbers also ensure the in-order reception of packets by the receiving entity. The receiving entity then sends back a corresponding acknowledgment (ACK) for each successfully received packet. Additionally, TCP uses a checksum function to verify whether there are errors in the data, calculating the checksum both during sending and receiving. Therefore, there are inter-packet relationships in the TCP, that is, each pair of packets must meet the appropriate IP addresses, port numbers, logically sequential sequence numbers (i.e., within the window), and correct checksum. For example, the acknowledgment number of the current packet should be equal to the sum of the sequence number and data length of the previous packet to be a correct acknowledgment number. During a TCP connection, only packets with appropriate IP addresses, port numbers, logically sequential sequence numbers, and correct checksums can be accepted by the other party.\nFigure 1. TCP packet header Therefore, during TCP fuzzing, the generation or mutation of test cases must consider both the field features of TCP packets and the inter-packet correlation features. Otherwise, most generated test cases will be directly discarded by the tested system without any processing due to errors such as format violations or data verification failures, leading to a significant decline in fuzzing efficiency.\nTCP is a stateful protocol, and its state model follows the basic state model defined in RFC 793. Figure 2 illustrates the TCP state machine model, which consists of 11 states and 20 state transitions. The 11 states can be categorized into client states and server states based on different entities. The server states include CLOSED, LISTEN, SYN_RCVD, ESTABLISHED, CLOSE_WAIT, and LAST_ACK.\nFigure 2. TCP state machine model As indicated by the TCP state machine model, when fuzzing a TCP stack, to improve code coverage, test cases should cover as many protocol states and state transitions as possible. Therefore, during network communication-based TCP fuzzing, it is necessary to perform coverage testing targeting different protocol states and state transitions.\n2.2. Network Protocol Fuzzing Method # Currently, when using fuzzing to mine vulnerabilities in network protocols, the fuzzer typically acts as a client, while the network protocol implementation program runs on the server under test [30]. The fuzzer interacts with the network protocol implementation program through a specific port. The client generates and sends data packets, while also receiving response packets from the server under test. The server under the test receives data packets from the client, updates its internal state after processing the request, and returns the processing results to the client.\nAt present, communication-based network protocol fuzz testing methods can mainly be divided into two categories. The first category is black-box protocol fuzz testing, which is relatively fast. Representative works include Boofuzz [19], Peach [24], and IoTInfer [25]. Customized templates are used to generate test data packets and send them to the designated test ports. These tools infer the presence of vulnerabilities either through side-channel indicators such as response latency or by reconstructing a finite-state machine from observed traffic. However, writing protocol primitives requires substantial expert experience and manual intervention. Additionally, black-box fuzzing cannot obtain internal feedback from the server to improve the quality of test case generation. The inherent randomness leads to significant time wastage on ineffective test cases.\nThe second category is gray-box protocol fuzzing. Some researchers have transplanted gray-box fuzzing technologies to network scenarios. In 2020, AFLNET [21], a stateful gray-box fuzzer for network servers, was proposed. AFLNET extracts the internal state of the server by analyzing the content of response packets from the network server, enabling fuzzing for specific states. Meanwhile, it can obtain the code coverage of the server under test to improve the effectiveness of test cases. CGFuzzer (2022) [26] employed a coverage-guided generative adversarial network to learn Industrial Internet of Things protocol grammars and synthesize high-acceptance test cases, achieving significant coverage improvements. MPFuzz (2024) [27] further extended this line of work with a parallel fuzzing architecture that synchronizes critical fields across instances using protocol-specific information and refines generated packets via a semantics-aware optimization module, markedly enhancing parallel fuzzing efficiency.\nHowever, both black-box and gray-box network protocol fuzzing methods are primarily designed for fuzz testing of application-layer protocols and cannot directly control the implementation details of the TCP belonging to the transport layer. Secondly, these methods generally rely on Sockets to send data for testing and cannot independently control the state changes of the TCP. At the same time, the TCP is fundamentally different from the application-layer protocols, and these fuzzing methods do not take into account the basic characteristics and functions of the TCP. Consequently, their test-case generation strategies and feedback mechanisms are not directly applicable to fuzzing the TCP stack in VxWorks, leading to a substantial degradation in testing efficacy.\n2.3. The Task Characteristics of VxWorks # VxWorks is a high-reliability and real-time embedded operating system developed by Wind River Systems in the United States. Due to its high reliability and excellent real-time performance, it is widely used in various fields such as aviation, aerospace, medical, communication, and industry. Its representative customers include Boeing, Airbus, NASA, Samsung, Siemens, Huawei, and Cisco [31]. VxWorks is also a real-time multitasking operating system. Its kernel provides a basic multitasking environment, allowing a program to run as a series of independent tasks. Each task has its own thread and system resources. Therefore, in the VxWorks system, a task is the basic execution unit and the main object for resource allocation and scheduling. Each task has an independent execution environment, including a stack pointer (SP), a register set, and its own stack and data segment. VxWorks manages the state and attributes of each task through a task control block (TCB), which contains key information about the task, such as its priority, status, stack pointer, and program counter. In terms of memory management, VxWorks uses a partitioned memory model. All tasks share the same physical address space and ensure the privacy of local run-time data by allocating independent stack areas. In task scheduling, VxWorks uses a priority-based preemptive scheduling algorithm. The kernel supports task switching by saving the task’s context (including the program counter PC register, stack pointer SP, etc.). The PC register stores the address of the instruction currently being executed by the task and is the core pointer of the task’s running state. For multitasking systems, the PC register enables the operating system to restore the execution progress of a task during task switching. Therefore, by capturing the PC register values of tasks, the memory address ranges, currently accessed by the tasks, can be indirectly obtained. This allows for the precise positioning and extraction of memory data in the task’s running area.\nInspired by the characteristics of the PC register in VxWorks tasks, we can design a lightweight and non-intrusive task memory monitoring method. This method aims to address the challenge of acquiring internal execution information from the system under test during network fuzz testing, which is crucial for effectively guiding the direction of fuzz testing.\n2.4. VxWorks Debugging Mechanism # VxWorks provides remote debugging capabilities through the WDB (Wind River Debug) RPC protocol. This protocol enables communication between a host and target devices, thereby facilitating task monitoring, memory access, and exception capture. In several existing studies [8,32], automated vulnerability detection methods specifically designed for VxWorks systems have been implemented. These studies utilize the WDB RPC protocol for target exception capture, a mechanism we refer to as the WDB detection mechanism.\nThe implementation of the WDB detection mechanism primarily relies on VxWorks’ inherent task exception handling. When VxWorks’ task exception handling mechanism detects an exception in a task, it proactively transmits relevant exception information to the connected host via the WDB RPC protocol. However, VxWorks’ task exception handling mechanism operates by jumping to corresponding exception handling routines based on the exception vector table. Consequently, certain unknown error types may fail to be correctly captured by VxWorks’ exception handling mechanism, and it is incapable of addressing exceptions involving complete network failures in VxWorks. Thus, the WDB detection mechanism has inherent limitations. It can only detect exception types that are capturable by VxWorks’ task exception handling, potentially resulting in missed exception cases.\n3. Design and Implementation # This section elaborates on various methods for implementing the vxTcpFuzzer framework, primarily including a protocol feature fusion fuzzer, a memory feedback utilization method, and a dual anomaly detector.\n3.1. Framework # This paper takes the TCP transport layer protocol of VxWorks as the research object, exploring how to develop a lightweight, high-acceptance-rate, and practical fuzz testing method for the TCP protocol in a black-box environment. As shown in Figure 3, it is the overall workflow of the vxTcpFuzzer framework.\nFigure 3. Workflow of vxTcpFuzzer One of the core objectives of vxTcpFuzzer is to systematically cover and test all critical states and their transitions in the TCP server. Therefore, before each round of fuzz testing targeting a specific state (e.g., SYN_RCVD), a protocol status activation phase is essential to precisely drive and confirm that the system has reached the target state. First, based on the transition conditions defined in the TCP state machine model (Figure 2) as shown in Table 1, vxTcpFuzzer pre-constructs a set of specific, syntactically correct TCP packets (referred to as the “activation corpus”). These packets are specifically designed to reliably drive the VxWorks TCP server from its current state to the target state under test (e.g., sending a SYN packet to drive the system to the SYN_RCVD state). Then, prior to the start of each fuzz testing round, vxTcpFuzzer sends the corresponding packets from the activation corpus and analyzes the response packets from VxWorks (as shown in the “Response Packets” column in Table 1). By parsing information such as flag bits (e.g., SYN+ACK) in the response packets, vxTcpFuzzer confirms whether the system has successfully entered the expected target state. For instance, when testing the SYN_RCVD state of the TCP protocol, we first send a TCP packet with the SYN flag set (trigger condition). Once VxWorks responds with a {SYN, ACK} packet (state confirmation signal), it indicates that the system has successfully entered the SYN_RCVD state, allowing the initiation of fuzz testing for this specific state.\nTable 1. Transition conditions and response packets for TCP server states Notably, CLOSED in Table 1 is not a genuine server state but a hypothetical starting/ending point. Therefore, our testing primarily focuses on the other five TCP server states.\nThe framework in our fuzz testing process is primarily divided into three components. The first is the Protocol Feature Fusion Fuzzer, which analyzes and extracts the feature attributes of each TCP field and integrates them with test case generation to implement a protocol feature fusion-based test case generation method (Section 3.2).\nThe second component is the Memory Feedback Utilization Method. During protocol fuzz testing, memory data of corresponding network tasks is extracted before and after each test round. The variation in network task memory data is used as coverage metrics for test cases during fuzz testing (Section 3.3).\nThe final component is the Dual Anomaly Detector. Throughout the entire fuzzing process, a dual anomaly detector specific to the VxWorks system is employed to detect system anomalies and implement post-anomaly recovery of the testing environment (Section 3.4).\n3.2. Protocol Feature Fusion Fuzzer # The quality of initial test cases significantly impacts the overall effectiveness of fuzz testing. In Section 2.2, we discussed the unique characteristics of the TCP protocol and its fundamental differences from other application-layer protocols. This renders traditional conventional protocol fuzzers incapable of generating valid TCP test cases. Test case generation methods targeting the TCP protocol require more sophisticated simulation of the protocol’s state machine, connection procedures, error handling, and interactions with the network environment to produce effective and feasible test cases. Therefore, we propose the design of a more sophisticated TCP fuzzer that incorporates detailed implementations of connection state transitions, flow control mechanisms, and synchronization of sequence and acknowledgment numbers. Our approach focuses on individual TCP fields, extracting and analyzing their characteristic attributes and inter-field dependencies, which are then integrated into the test case generation process. By leveraging a protocol feature fusion-based fuzzing method, we generate structured test cases that adhere to TCP syntax and semantics, thereby enhancing the overall quality of initial test cases.\nThe protocol feature fusion-based fuzzing method integrates characteristic attributes of TCP fields into the test case generation process. By leveraging these protocol-specific features, we can more effectively select mutation strategies to generate high-quality test cases. Regarding the field characteristic information of TCP, it primarily includes field name, data type, field length, typical field values, and correlation relationships between fields, among others. Specifically, the feature vector of each field is defined as a five-tuple structure: V = (Name, Type, Len, Default, Constraints). The role of each field’s feature vector is mainly reflected in three aspects: first, in strategy selection, mutation strategies are matched according to Type and Len. Second, in value constraints, default and constraints are used to ensure syntactic validity; third, in maintaining correlation relationships, logical consistency between fields is preserved through constraints. For example, the feature vector of the urgent pointer field is as follows: VURG = (URG_PTR, uint16, 16, 0, {flagU = 1}). This determines that its mutation must satisfy the following: when the URG flag in the flag field is activated, non-zero values need to be generated. Otherwise, the default value 0 is maintained. In this paper, we extract all TCP field features and represent them as feature vectors and then apply tailored mutation strategies based on distinct feature vectors. Table 2 outlines the customized generation strategies for different TCP protocol fields.\nTable 2. Generation strategies for TCP protocol fields The specific content of the generation strategies implemented based on different features of TCP protocol fields is as follows:\nFor the source port field, a strategy of random acquisition after inspection is implemented. By randomly obtaining the port number of the current host and then inspecting whether the port is an idle port, the idle port number of the current host can be obtained. This value is then assigned to the source port field to change the value of the source port number on the basis of ensuring that the local host port is idle.\nFor sequence number and acknowledgment number fields, a strategy of timing dependency calculation is implemented. After using activation cases in the activation phase to drive the TCP service of the system to the state under test, the timing information contained in the system’s response to the activation cases is extracted. This timing information is then further processed using TCP message timing relationship calculation rules to derive the specific values of the sequence number and acknowledgment number acceptable to the test object in the next step. To more clearly demonstrate the implementation details of this strategy, we provide a basic example. Figure 4 illustrates the calculation process for the values of the sequence number and acknowledgment number fields in a test case during the testing of the SYN_RCVD state of the TCP.\nFigure 4. An example of implementing the timing correlation calculation strategy for sequence numbers and acknowledgment numbers when testing the SYN_RCVD state (In the figure, the “…” indicates the omitted content of other fields in the TCP message). For the data offset, reserved, flags, window, and urgent pointer fields, a progressive assignment strategy is implemented. The progressive assignment strategy generates a series of values for a field by incrementally assigning values from zero up to the maximum allowable value within the field’s defined length constraints. This approach systematically explores the entire value range of the field to generate diverse test inputs.\nFor the options field, a two-layer composite mutation strategy is implemented. The so-called two-layer composite mutation is divided into a lower-layer option value mutation and upper-layer option tuple position mutation. A lower-layer mutation involves performing mutation operations such as bit flipping, insertion, replacement, or deletion based on the initial value of the option value within the same type of option tuple. To increase the complexity of fuzzing, after the initial length of the option tuple has been mutated based on the initial value, it is assigned to the original type of option. The source of the option tuple is a typical option set formed by combining TCP common options obtained from documents such as RFC 793 [28], RFC 1323 [33], and RFC 5925 [34]. An upper-layer mutation involves fuzzing the option tuple that has undergone a lower-layer mutation through copying, crossing, and position replacement of the option tuple and finally obtaining a series of option lists with different values. To more clearly illustrate the generation process of this strategy, we present a simple example. Figure 5 depicts a process of implementing a two-layer composite mutation on the MSS option. First, the initial option undergoes a lower-layer mutation based on its initial value to generate a series of option tuples. Subsequently, an upper-layer mutation is performed on these option tuples to obtain the final option list.\nFigure 5. An example of the process for implementing the two-layer composite mutation strategy on the MSS option. The above generation strategies do not include mutations for the destination port and checksum fields. For these two fields, this paper chooses not to perform mutations. The destination port is set to the TCP service port opened by the VxWorks system under test during experiments (e.g., port 21 for FTP services). Fixing this field ensures that test cases always act on the protocol stack of the target service, preventing test cases from being discarded by underlying network modules due to incorrect port settings. As for the checksum field, its correct value needs to be dynamically calculated after the packet is constructed. Random mutations on this field would cause the packet to be directly discarded by the protocol stack during the verification phase, making it impossible to trigger anomalies in deep-seated state machines or memory processing logic. The design is precisely based on the relevant characteristics of TCP fields: The checksum serves as the basic verification mechanism for TCP reliable transmission, and any invalid checksum will result in packet discarding. The destination port, on the other hand, is the first-layer filtering condition for the protocol stack to distribute packets. Maintaining the validity of these two fields can significantly improve the probability of test cases passing the initial verification of the protocol stack, thereby enabling more effective testing of potential vulnerabilities in core protocol logic.\nThe field mutation strategies described above do not generate a single test case by assigning a value to each field independently. Instead, they consider factors such as TCP state transitions and synchronization of sequence/acknowledgment numbers. Test cases are generated by first determining values for critical fields (source port, destination port, sequence number, and acknowledgment number) and then combining these with values from other fields. This approach ensures that each test case passes the initial validation of the target system’s protocol stack, thereby enhancing the quality of individual test cases.\nIn this paper, a fuzzing method based on protocol feature fusion is used to generate the initial test cases for the fuzzing process, which are then placed into the test case pool.\nAfter the generated initial test cases are executed, the Havoc mutation algorithm proposed in Section 3.3.2 utilizes the saved seeds to generate new test cases for continuous testing. This process iterates cyclically until the user halts the program or a timeout occurs.\n3.3. Memory Feedback Utilization Method # To address the issue of insufficient effective feedback from VxWorks systems in a black-box environment, we drew inspiration from the characteristics of VxWorks tasks outlined in Section 2.3 and designed a feedback mechanism based on memory data changes of tasks. The core of this mechanism lies in monitoring memory data changes of network tasks, using them as a new coverage metric. Based on this, “interesting” test cases that can trigger new memory states are selected to be added to the seed queue, providing a foundation for subsequent heuristic Havoc mutations, thereby guiding the fuzz testing to explore potential new execution paths. This method mainly consists of two components: a task memory data extraction method (responsible for acquiring memory changes) and a heuristic Havoc mutation algorithm (responsible for generating new test cases through seed mutation).\n3.3.1. Memory Data Extraction Method # In the VxWorks operating system, the task named tNet0 is responsible for executing network drivers and handling network protocols within the VxWorks network stack. When a TCP packet arrives, it triggers a state transition of tNet0, leading to a context switch of the task, and further causing corresponding changes in the contents of the task register set. Therefore, in the process of fuzz testing the TCP protocol, this paper monitors the PC register values of the tNet0 task. When the PC register value of the tNet0 task changes, the memory data of the task execution area is extracted. During fuzzing, we compare the task memory data extracted from two consecutive rounds of testing. When there are differences in the task memory data, we consider the test case of this round as “interesting” because this test case has altered the task memory data, which indirectly indicates that the test case may have covered a new task execution area. Therefore, we use the task memory data changes caused by test cases as a new coverage metric.\nThe task memory data extraction method implemented in this paper is shown in Algorithm 1. First, the task name is converted to a taskID, that is, the specific ID assigned by VxWorks to the tNet0 task is looked up (line 1). Then, the initial PC register value of the task is obtained through the tNet0 taskID (line 2). The PC register of tNet0 is then monitored for changes (lines 3–4). When the PC value differs from the initial value, 100 bytes of memory data starting from the PC address are extracted and written to a specified file (lines 5–7). If the PC register value does not change, the task is monitored for a certain period of time before continuing to monitor (line 9).\nAlgorithm 1: Task memory data extraction algorithm --- Input: task name, taskName Output: 100 bytes of memory data, memData 1: taskID ← taskNameToId(taskName); 2: init_pc ← taskRegsGet(taskID); 3: while True do 4: cur_pc ← taskRegsGet(taskID); 5: if cur_pc is not equal to init_pc then 6: memData ← memcpy(cur_pc, 100); 7: memfwirte(memData, memfile); 8: else 9: taskDelay(); 10: end if 11: end while We applied the task memory data extraction algorithm in vxTcpFuzzer to obtain feedback information for each round of testing. First, before and after each round of testing, the task memory data of tNet0 is read once respectively, and we compare whether the content of the memory data has changed. If a change occurs, it will be further compared with the memory data after the previous round of testing. When the memory data from two test rounds are inconsistent, the test case of the current round is considered as one that we are interested in (i.e., it triggers a new memory state). In brief, changes in memory data are obtained by comparing the memory data of the task execution area extracted before and after each test round; its direct purpose is to identify and select “interesting” test cases. Finally, all “interesting” test cases will be added to the seed queue, serving as the basic input for subsequent heuristic Havoc mutations.\n3.3.2. Heuristic Havoc Mutation # To perform continuous and efficient testing, we implement mutation operations on the seed cases in the seed queue. These seeds refer to the “interesting” test cases that have successfully triggered new changes in memory states, indicating that they may have explored new execution paths. In the phase where the protocol feature fusion fuzzer generates initial cases, the adopted generation strategy only mutates a certain field in the protocol each time. However, the conditions for triggering bugs may be complex. For example, it may require modifying different data fields in the same packet to trigger an exception. Therefore, the testing process needs the involvement of Havoc mutation. But the traditional Havoc mutation randomly selects some random fragments in a packet for mutation, which has strong blindness. To address this, this paper designs a heuristic Havoc mutation algorithm, which enables the Havoc mutation to focus on these valuable seeds selected through memory feedback and perform purposeful mutations based on them.\nThe overall workflow of the heuristic Havoc mutation algorithm is shown in Algorithm 2: First, traverse the seed queue, locate the abnormal fields and extract the abnormal values for each seed, and divide the abnormal values into corresponding lists according to the field types (line 1). Then map the field names to their corresponding abnormal value lists in a dictionary called Field_lists (line 2). Filter out the fields with non-empty abnormal value lists from Field_lists to form a new non-empty dictionary Noempty_fields (line 3). Extract all field names that need to be combined from Noempty_fields and store them in the list Fields (line 4). For each combination size (from 2 to the length of Fields), generate all possible field subset combinations (lines 5–6). For each field subset, obtain the corresponding abnormal value lists and calculate the Cartesian product of these abnormal value lists to generate all possible abnormal value combinations (lines 7–8). For each abnormal value combination, construct a new TCP packet and set the abnormal values for the field subset to generate a new test case (line 9). Finally, add the newly constructed test case to the test case set P (line 10).\nAlgorithm 2: Heuristic Havoc mutation algorithm --- Input: Seed queue, S Output: New test case set, P 1: L ← excfield_position(S); 2: Map the field name to the corresponding list L to the Field_lists 3: Filter out the empty list in the Field_lists to get Noempty_fields 4: Extract all field names from the Noempty_fields to Fields 5: for each combination size comsize in between range 2 and len(Fields) do 6: for each field combination fieldsubset in all subsequences of length comsize in Fields do 7: Get the list of exceptional values for each field in the current fieldsubset to Value_lists; 8: for each exceptional value combination values in Value_lists Cartesian product do 9: C ← build_newcase(fieldsubset, values); 10: add C to set P 11: end for 12: end for 13: end for 14: return P Algorithm 2 begins with the identification and extraction of abnormal fields from the seed queue. The detailed procedure is presented in Algorithm 3. For every seed in the queue (Line 1), we extract the abnormal value of each field and compare it with the corresponding default value (Lines 2–4). Whenever a mismatch is detected, the value is recorded as an anomaly and appended to the anomaly list of the corresponding field, and the current seed is skipped (Lines 5–7).\nAlgorithm 3: Abnormal field identification and extraction algorithm --- Input: Seed queue, S Output: Lists of abnormal value, L 1: for each seed in S do 2: for each field in seed do 3: value ← seed[field]; 4: default ← get_default(field); 5: if value != default then 6: add value to L[field] 7: break 8: end if 9: end for 10: end for 11: return L Specifically, the heuristic Havoc mutation targets the seeds preserved during the fuzzing campaign. The processing method for the obtained seeds involves first locating the abnormal fields of the seeds. By sequentially comparing the values of each field in the seed with the default values, the abnormal fields causing changes in the memory data of the tNet0 task are positioned. After locating the abnormal fields of the seed, the values of these fields are extracted and stored in the corresponding abnormal value lists. The abnormal value lists are created separately according to the field types. Then, Cartesian-product-style iterative combinations are performed on the contents of the abnormal value lists to generate new test cases. The so-called Cartesian-product-style iterative combination refers to extracting combinations of multiple fields from these abnormal value lists to generate new test cases. First, mutations of combinations of every two fields are generated, followed by combinations of three fields, and so on, until combinations of all abnormal fields are covered. In this way, we explore the interactions between abnormal fields to produce test cases that can cover multiple field domains simultaneously. After iterative combination of the seed queue, a large number of new test cases can be generated. These test cases can conduct comprehensive coverage testing for scenarios where abnormalities are jointly triggered in different field domains, potentially triggering more complex bugs.\n3.4. Dual Anomaly Detector # The detection of abnormal conditions in the test object is a crucial part of fuzz testing. Only by effectively and comprehensively monitoring the state of the devices under test (DUT), potential vulnerabilities in the DUT can be discovered in a timely manner. Given the certain limitations of the WDB detection mechanism analyzed in Section 2.4, we have improved the WDB detection mechanism and combined it with the client heartbeat detection mechanism to jointly implement the dual anomaly detection mechanism proposed in this paper.\nAs shown in Figure 6, the dual abnormal detection mechanism consists of two parts: the WDB detection mechanism and the client heartbeat detection mechanism. First is the WDB detection mechanism implemented using the WDB RPC protocol of VxWorks. This mechanism acts as a HOST agent to establish a connection with VxWorks. It first uses the WDB_TARGET_CONNECT2 function in the WDB RPC protocol to create a connection request packet to achieve connection establishment. Then, after each round of testing, the WDB detection mechanism uses the WDB_EVENT_GET function to create an abnormal detection packet and send a detection request to VxWorks. Through the detection request packet, it can detect whether there is a task exception in VxWorks. For the client heartbeat detection mechanism, we did not create a separate client to specifically monitor the network communication of the test target. Instead, we cleverly used the activation corpus in the protocol state activation phase described in Section 3.1. Specifically, before testing a certain state of TCP in each round of test cases, the activation corpus is used to activate TCP to the state to be tested. Suppose the test case of this round causes the network communication of the test target to crash, and then the protocol state activation before the start of the next round of testing will fail because no response is received. We use this feature: if the protocol state activation fails for 3 consecutive times, it is considered that the network service of the DUT has crashed. Immediately record the crash information and the corresponding test case at this time.\nFigure 6. Dual anomaly detection mechanism structure When the WDB detection mechanism or client heartbeat detection mechanism identifies an anomaly in the test target, a similar anomaly handling procedure is initiated. However, discrepancies exist in implementation details, with the anomaly handling process primarily categorized into two aspects: anomaly information preservation and test environment restoration.\nFor the WDB detection mechanism, the test case triggering the anomaly is first saved, accompanied by recording the corresponding anomaly information. Subsequently, the WDB_REGS_GET and WDB_MEM_READ functional APIs are employed to extract and save the register set and memory data at the breakpoint of the abnormal task, respectively, to facilitate subsequent failure analysis. Finally, the WDB_CONTEXT_KILL function is invoked to initiate a hot restart of VxWorks, enabling the system to restore the test environment via reboot.\nFor the client heartbeat detection mechanism, the anomaly information preservation process mirrors that of the WDB mechanism: the triggering test case is saved alongside corresponding log records. Notwithstanding, the test environment restoration differs in implementation. For the VxWorks system installed on a virtual machine, the client heartbeat detection mechanism uses a forced restart of the virtual machine file. For the VxWorks system deployed on a development board, it uses a power-off and then power-on restart method.\n4. Implementation and Evaluation # In this section, we explain the fuzzing experiments conducted on multiple VxWorks devices using vxTcpFuzzer. Furthermore, we compare it with several benchmark tools to further evaluate the effectiveness of the framework.\n4.1. Experimental Setup # The experimental setup included the following:\nEnvironment Configuration. To better monitor network communications, all devices under test (DUTs) were directly connected to a local PC. Our fuzzing framework was executed on a Windows 10 desktop PC equipped with an AMD Ryzen 7 5700U with Radeon Graphics 1.80 GHz CPU and 16 GB of RAM.\nDevices Under Test. First, we installed two versions of the VxWorks system, namely VxWorks6.6 and VxWorks6.9, on virtual machines with Pentium series CPUs. VxWorks 6.6 and 6.9 represent two major versions of VxWorks that are widely deployed in the embedded field, and these two versions have been confirmed to potentially have security vulnerabilities [35]. Additionally, to test a more realistic network environment, we ported VxWorks6.9 to a ZYNQ development board with a Cortex-A9 CPU, simulating a VxWorks device operating in a real-world environment. The Cortex-A9-based ZYNQ platform was chosen as the target for porting because VxWorks 6.9 provides support for this platform, and it is representative in terms of usage in the embedded field [36]. For convenience, we refer to the VxWorks devices installed on the virtual machine and the ZYNQ development board as VxWorks6.9 and VxWorks6.9_z7, respectively.\nTest Service Target. The VxWorks operating system provides TCP services on multiple ports. In our testing experiments, we selected the FTP server available on port 21. The default number of concurrent connections for the VxWorks FTP server is eight. Therefore, after each test case, our fuzzer sends a TCP packet with the RST flag to actively release the connection, preventing subsequent test cases from failing due to exhausted connection resources.\nBaseline Tool. To further verify the performance of the proposed framework in terms of crash detection and test case generation, we compared it with three other network communication-based fuzzing tools as benchmarks.\nWe performed fuzz testing on the three DUTs using a certain number of test cases and repeated the process five times to eliminate randomness. Each experiment was run independently without interference from others.\n4.2. Runtime Testing # Table 3 presents the fuzzing results of vxTcpFuzzer on three VxWorks devices, including the number of memory changes, average test case acceptance rate (ATCAR), average test system abnormal rate (ATSAR), and the number and types of crashes detected. The ATCAR for VxWorks6.6 is over 44%, while, for VxWorks6.9 and VxWorks6.9_z7, it is above 50%. The specific definitions and calculations of test case acceptance rate (TCAR) and test system abnormal rate (TSAR) will be elaborated in Section 4.3, including the detailed TCAR and TSAR data obtained during the fuzz testing process. The other test results presented in Table 3 will be analyzed in detail from the following three aspects: memory data changes, vulnerability identification, and the performance of the dual anomaly detection mechanism.\nTable 3. The fuzzing results of vxTcpFuzzer on three VxWorks devices 4.2.1. Memory Data Changes # In vxTcpFuzzer, we propose the number of task-memory data changes as a novel coverage metric. The more memory data changes occur, the more likely it is that the test cases cover new task execution areas. Consequently, the growth trend of memory data changes reflects both the effectiveness of individual test cases and the overall efficiency of the fuzzing campaign. Figure 7 illustrates this trend for vxTcpFuzzer while fuzzing three VxWorks devices.\nFigure 7. Trend of memory data changes in the testing process of three VxWorks devices As can be seen from the figure, the number of memory changes for all three VxWorks devices continues to increase. As the number of test cases grows, the number of different task execution branches covered by vxTcpFuzzer also keeps rising. In Figure 7, it can be observed that the memory data changes for VxWorks6.6 stop at 80,000 test cases. This is because, during the fuzzing process of VxWorks6.6, vxTcpFuzzer can generate over 80,000 test cases on average, while, for VxWorks6.9 and VxWorks6.9_z7, it can generate more than 100,000 test cases. The same situation will be followed in the subsequent analysis.\n4.2.2. Vulnerability Identification # After conducting multiple fuzzing tests on the TCP protocol of three VxWorks devices using vxTcpFuzzer, we detected a total of six crashes. As shown in Table 3, four crashes were detected in VxWorks6.6, with the corresponding vulnerability types being integer overflow and denial of service (DoS). One crash was detected in each of VxWorks6.9 and VxWorks6.9_z7, with the corresponding vulnerability type being DoS. We further manually verified these crashes and found that they all occurred when the TCP service of the test system was in a specific state and received test inputs with abnormal fields. Through analysis of the crashes, we discovered that the DoS-type vulnerabilities in VxWorks6.6, VxWorks6.9, and VxWorks6.9_z7 were caused by the same error:\nInteger Overflow. As shown in Table 3, during the testing process of VxWorks6.6, a total of four crashes were triggered, three of which were caused by integer overflow. The manifestation was that, after sending test cases to VxWorks6.6, the system task crashed and was unable to perform any TCP connection interactions. Figure 8 displays the system output of VxWorks6.6 when these three crashes were triggered. Figure 9 presents the test cases that triggered these three crashes. Through analyzing the system outputs and test cases, we found that the condition for triggering this crash is as follows: when the TCP is in the ESTABLISHED state, receiving a test case with the URG flag in the flag field, an urgent pointer field of 0, and carrying a large amount of payload, those conditions will cause the crash (corresponding to the part in red font in Figure 9).\nFigure 8. System output of VxWorks6.6 during integer overflow Figure 9. Test cases triggering three integer overflows in VxWorks 6.6 (The text in red indicates the key content that triggers the crash). Specifically, the urgent pointer field in the TCP protocol is used to identify the position of urgent data in the data stream. However, VxWorks6.6 triggered an integer underflow when processing the URG flag in the TCP packet due to the urgent pointer being equal to 0. During the testing of the ESTABLISHED state of the TCP protocol, vxTcpFuzzer’s heuristic Havoc mutation method generated test cases with the URG flag and an urgent pointer of 0, thereby triggering the corresponding crashes. Finally, by combining the information from the test system crashes, we confirmed that the integer overflow vulnerability causing these three crashes was the CVE-2019-12255 vulnerability. The vulnerability has been confirmed to permit remote code execution across VxWorks 6.5–6.9 and early releases of VxWorks 7, affecting more than two billion embedded devices deployed in industrial control, medical, and networking equipment. Given VxWorks’ ubiquity in mission-critical domains—including avionics, aerospace, and industrial automation—a successful exploit can crash core network tasks and render the entire system incapable of network communication. In scenarios that rely on real-time data delivery (e.g., flight control and industrial process monitoring), such a disruption may trigger cascading failures or lead to complete loss of system control.\nAnother type of crash was found:\nDenial of Service (DoS). During the testing process of VxWorks6.6, VxWorks6.9, and VxWorks6.9_z7, each experienced one crash of the DoS type. Through analysis, it was determined that these crashes in the three VxWorks devices were caused by the same DoS vulnerability. Figure 10 presents the test case that caused this DoS incident. Through analyzing the content of the test case and the response messages from the VxWorks system, we identified that this DoS vulnerability is triggered when the VxWorks system receives a test case containing illegal TCP options after a normal TCP connection has been established. Specifically, when the test case received by the tested VxWorks system contains a WSOPT option with an empty data field in the option field, the test system determines that there is an illegal option. As a result, it actively resets and disconnects the current TCP connection, causing a DoS. During the testing of the TCP state after establishing a connection, vxTcpFuzzer’s dual-layer composite mutation strategy generates test cases with option content consisting of five groups of empty WSOPT options, thereby triggering the DoS vulnerability in the VxWorks test system. Finally, by analyzing the output information of the test system when the DoS vulnerability occurred, the DoS vulnerability was confirmed to be the CVE-2019-12258 vulnerability.\nFigure 10. Test case triggering DoS in VxWorks (The text in red represents the key content that causes the DoS). Although this vulnerability only causes a single connection to be reset (rather than the crash of an entire task), its impact is equally non-negligible. In VxWorks-powered embedded devices (e.g., medical equipment and network infrastructure), frequent triggering of such vulnerabilities can render the core TCP services provided by the devices (such as remote monitoring, data uploading, and firmware updating) unreliable. More alarmingly, attackers may exploit this vulnerability to launch low-cost DoS attacks. By continuously sending malicious packets to exhaust limited connection resources, they can completely block legitimate users from accessing device services, thereby achieving a DoS effect. In critical infrastructure or public service networks, this could serve as a prelude to or a component of larger-scale attacks, with an impact scope that may far exceed individual devices. This is consistent with attack patterns such as those of the Mirai botnet.\n4.2.3. Performance of the Dual Anomaly Detector\nWe have improved the WDB detection mechanism. We have skillfully integrated it with the client heartbeat detection mechanism to achieve a dual anomaly detection mechanism. As described in Section 3.4, the WDB detection mechanism may miss some abnormal situations. Therefore, this paper compensates for this defect by combining it with the client heartbeat detection mechanism, and facts have proven that this measure is necessary. Table 4 shows the number of anomalies detected by the WDB detection mechanism and the client heartbeat detection mechanism during the fuzzing of three types of VxWorks devices.\nTable 4. Number of anomalies detected by the dual anomaly detection mechanism during fuzzing As shown in Table 4, during the testing of the three types of VxWorks devices, the vast majority of crashes were successfully detected by the WDB detection mechanism. However, in the case of VxWorks6.6, one crash instance was missed by the WDB mechanism. This anomaly was successfully captured by the client heartbeat detection mechanism. The crash scenario illustrated in Figure 11 corresponds to the system output at the moment the anomaly was detected by the heartbeat mechanism. In this case, the WDB detection mechanism failed to identify the crash, even though the VxWorks network service had already crashed and was in an unresponsive state.\nFigure 11. System output when anomaly detected by client heartbeat detection mechanism. From the output information shown in Figure 11, it can be inferred that the root cause of the anomaly was memory corruption in the network task, which led to abnormal network communication. VxWorks’ internal exception handling mechanism was unable to capture this type of error, which in turn prevented the WDB detection mechanism from recognizing the anomaly. In contrast, the client heartbeat detection mechanism was able to detect the crash. Once the number of failed network communication attempts reached a predefined threshold, the heartbeat mechanism triggered the corresponding exception handling procedures, including logging the anomaly and restoring the test environment.\nWhile the WDB detection mechanism is efficient in detecting anomalies in VxWorks, it is possible for it to miss some anomalies. Therefore, combining it with the client heartbeat detection mechanism is necessary and effective.\n4.3. Comparison with Benchmark Tools # To further verify the performance of vxTcpFuzzer in terms of test case generation and crash detection, we selected three different fuzzing schemes as benchmarks:\nBoofuzz-chksum: Boofuzz [19] is an excellent network protocol fuzzer, an improved version based on the Sulley framework. It supports manually defined protocol tree structures as input for continuous test generation. Therefore, we can utilize its protocol definition method to implement the definition of the TCP protocol, thereby generating test cases for fuzz testing targeting the TCP. However, when generating test cases, since Boofuzz does not provide a TCP checksum algorithm, all the test cases it generates will be discarded during the initial checksum verification phase, failing to achieve the actual testing effect. To enable the test cases generated by Boofuzz to pass the initial checksum phase, we added a TCP checksum algorithm module to the original Boofuzz, which is denoted as Boofuzz-chksum. Netzob-generation: Netzob [37] is a protocol reverse analysis tool developed by Bossert et al. It can infer message formats and state machines through passive/active methods and generate test cases based on the inferred protocol model for fuzzing. Netzob-generation uses an active definition-based message format generation algorithm for fuzzing. Similar to Boofuzz, we can use the method of actively defining protocol messages provided by Netzob to implement the format definition of the TCP protocol, thus generating TCP-compliant test cases for fuzz testing targeting TCP. Netzob-mutation: Netzob-mutation is a TCP fuzzing scheme we implemented using another method provided in Netzob, which passively infers message formats and state machines. First, Netzob is used to reversely infer message formats and state machines using captured TCP traffic. Then, mutation algorithms are applied to mutate the inferred results, thereby generating TCP test cases for fuzzing. There are also many advanced fuzz testing tools capable of testing protocols through network communication, such as Peach and AFLNET. However, since they are gray-box fuzzers that require access to the system firmware, it is neither feasible nor fair to use these tools as baselines for black-box solutions.\nWe will compare the efficiency of vxTcpFuzzer with these three baseline approaches in the following three aspects: test case acceptance rate, test system abnormal rate, and found bugs.\n4.3.1. Test Case Acceptance Rate # The Test Case Acceptance Rate (TCAR) is generally defined as the proportion of test cases successfully executed by the system under test (SUT) out of the total number of test cases. During the fuzzing process, a low TCAR often indicates that a large number of test cases are not executed by the SUT. This can result in insufficient coverage of the target system, failing to comprehensively test all functions and boundary conditions of the target system. During the fuzz testing of the network protocol in VxWorks, it is impossible to directly obtain information on whether the test cases are executed by VxWorks. Therefore, we regard the test cases with response messages as those successfully executed by VxWorks. Conversely, test cases without response messages are considered as not being successfully executed. However, this evaluation method is not comprehensive. This is because test cases that are successfully executed do not necessarily generate responses. The TCAR calculation formula used in this paper is shown in Equation (1), where Nresponse represents the total number of test cases with response messages, and Nall represents the total number of test cases received by VxWorks. In our fuzzing process, we calculate the TCAR every 5000 test cases.\nTCAR = Nresponse/Nall × 100%\t(1)\nAs shown in Figure 12, Figure 13 and Figure 14, the TCAR of vxTcpFuzzer, Boofuzz-chksum, Netzob-generation, and Netzob-mutation during the fuzz testing of three VxWorks devices are recorded. Figure 12 represents the test case acceptance rate of VxWorks6.6. The average acceptance rates of Boofuzz-chksum, Netzob-generation, and Netzob-mutation are 4.74%, 8.69%, and 20.87%, respectively, while that of vxTcpFuzzer is 44.9%. Figure 13 shows the test case acceptance rate of VxWorks6.9. The average acceptance rates of Boofuzz-chksum, Netzob-generation, and Netzob-mutation are 4.96%, 8.82%, and 23.80%, respectively, and the average acceptance rate of vxTcpFuzzer is 53.9%. Figure 14 depicts the test case acceptance rate of VxWorks6.9_z7. The average acceptance rates of Boofuzz-chksum, Netzob-generation, and Netzob-mutation are 4.96%, 8.82%, and 23.80%, respectively, and the average acceptance rate of our vxTcpFuzzer is 54.9%.\nFigure 12. TCAR on VxWorks6.6 Figure 13. TCAR on VxWorks6.9 Figure 14. TCAR on VxWorks6.9_z7 After comparison, the TCAR of vxTcpFuzzer is generally higher than the other three fuzz testing methods. In the test case generation phase, vxTcpFuzzer extracts the field feature information of the TCP and forms a feature vector. It then matches the corresponding mutation strategy based on the feature vector. This allows the generated test cases to retain a large number of syntactic and semantic features, thereby increasing the probability of the test cases being valid. Boofuzz-chksum can quickly construct and generate test cases. However, due to its coarse-grained protocol definition rules and the randomness and blindness of its test case generation method, it produces a large number of invalid test cases. Netzob-generation, which is based on manually defined protocol formats, has more refined protocol definition rules than Boofuzz-chksum. Therefore, its TCAR is slightly higher than Boofuzz-chksum. However, its test case generation algorithm is still random and blind. Netzob-mutation, which is based on reverse analysis, can perform detailed segmentation and clustering of TCP traffic. It can obtain a more comprehensive protocol format and state machine, resulting in a higher TCAR. However, there may be some errors in the reverse analysis results. Moreover, the test case mutation algorithm is not highly integrated with the protocol features. Therefore, its TCAR is still lower than that of vxTcpFuzzer.\n4.3.2. Test System Abnormal Rate # The test system anomaly refers to the phenomenon in fuzzing where test cases violating TCP protocol specifications are incorrectly accepted as valid by VxWorks. Ideally, erroneous or anomalous test cases should not be processed by VxWorks; instead, they should trigger connection termination via RST-flagged TCP responses. However, when logical anomalies exist in the test system, some invalid test cases may still be executed, leading to potential security vulnerabilities. A higher TSAR indicates greater fuzzing efficiency. In this study, we calculate the number of anomalous test cases by subtracting the count of RST-flagged responses from the total number of test cases that generate responses. As shown in Equation (2), where Nresponse represents the total number of test cases with response messages, Nrst represents the total number of test cases with RST responses, and Nall represents the total number of test cases received by VxWorks. In our fuzzing process, we calculate the TSAR every 5000 test cases.\nTSAR = (Nresponse − Nrst)/Nall × 100%\t(2)\nDuring fuzzing, the test system abnormal rate serves as an intuitive metric for evaluating fuzzer performance. An increased anomaly rate indicates that the fuzzer can more effectively uncover potential vulnerabilities in the system, thereby signifying superior fuzzer performance. In Table 5, Table 6 and Table 7, we present the TSAR of vxTcpFuzzer, Boofuzz-chksum, Netzob-generation, and Netzob-mutation on three VxWorks devices during the testing process.\nTable 5. TSAR of vxTcpFuzzer and three fuzzing schemes on VxWorks6.6 Table 6. TSAR of vxTcpFuzzer and three fuzzing schemes on VxWorks6.9 Table 7. TSAR of vxTcpFuzzer and three fuzzing schemes on VxWorks6.9_z7 Table 5, Table 6 and Table 7 present the test system anomaly rate for vxTcpFuzzer, Boofuzz-chksum, Netzob-generation, and Netzob-mutation across three VxWorks devices. On the three VxWorks devices, the average test system anomaly rates are 23.79%, 31.83%, and 34.70% for vxTcpFuzzer, 0.57%, 0.72%, and 0.73% for Boofuzz-chksum, 2.99%, 3.03%, and 3.03% for Netzob-generation, and 7.61%, 10.26%, and 10.26% for Netzob-mutation. Overall, our approach (vxTcpFuzzer) demonstrates significantly higher TSAR compared to the other three fuzzing methods. This advantage is attributed to vxTcpFuzzer’s capability to conduct fuzz testing across all TCP server-side states. Concurrently, it enables real-time tracking of TCP state transitions during testing, facilitating comprehensive evaluation of state stability and transition integrity.\nAs shown in Table 5, Table 6 and Table 7, vxTcpFuzzer exhibits a decline in TSAR during the final testing phase for each VxWorks device. This is attributed to the fuzzer’s focus on the LAST_ACK state—the terminal state of TCP connection termination—during this phase. Since most test cases targeting this state yield no response messages, the TSAR metric naturally decreases. Nevertheless, this observation further validates the capability of our approach to perform multi-state fuzzing across the TCP lifecycle.\n4.3.3. Found Bugs # To ensure a fair comparison of vulnerability detection capabilities, we compared the tools under identical testing conditions:\nTest case scale: All tools tested 80,000 cases on VxWorks 6.6 and 100,000 cases each on VxWorks 6.9 and VxWorks 6.9_z7 (consistent with vxTcpFuzzer); Anomaly detection mechanism: The benchmark tools uniformly adopted the dual anomaly detection mechanism of vxTcpFuzzer (WDB detection + heartbeat detection); Testing targets: All targeted the TCP services exposed by the three types of VxWorks devices. Under the same testing scale and anomaly monitoring mechanism, none of the three benchmark tools detected any crashes, while vxTcpFuzzer detected a total of two potential errors, corresponding to integer overflow and DoS vulnerabilities.\nBoofuzz-chksum and Netzob-generation rely on manually defined protocol formats based on fixed rules, resulting in rigid test-case generation strategies. They also lack state-tracking capabilities, restricting testing to a single TCP state and yielding insufficient coverage.\nNetzob-mutation leverages protocol-inference algorithms to model TCP message structures and state machines, enabling state-aware fuzzing. However, limitations in its reverse-engineering algorithms impede effective clustering of variable-length fields (e.g., TCP options), while the absence of feedback-driven optimization prevents iterative model refinement. Consequently, it overlooks numerous protocol formats and state transitions.\n4.4. Evaluation of Memory Feedback Utilization # The vxTcpFuzzer we designed and implemented is capable of fuzzing each server state of the TCP independently. For each state, the fuzzing process is divided into two phases. The first phase is the initial cases testing phase, which utilizes the protocol feature fusion fuzzer to generate initial test cases for testing. The second phase is the Havoc mutation testing phase, which mutates the seeds retained from the initial testing phase using heuristic Havoc strategies and then performs further testing. We use the number of test cases triggering memory data changes during these two phases for each protocol state as the evaluation metric for the memory feedback utilization module. In other words, we compare the number of interesting test cases (i.e., those that induce memory data changes) across the two phases.\nBecause the interesting test cases generated in the first phase serve as seeds for the second phase Havoc mutations, an increase in the number of interesting test cases in the second phase demonstrates the effectiveness of the memory feedback module during fuzzing.\nFigure 15, Figure 16 and Figure 17 record, for each TCP state and for all three VxWorks devices, the number of interesting test cases preserved in the two phases. As shown, the second phase consistently produces more interesting test cases than the first phase for every state on all three devices. This is attributed to the heuristic Havoc mutation method employed in the second phase, which uses the interesting cases from the first phase as seeds. The method first locates the anomalous fields within these seeds and then generates new test cases through Cartesian-product-style iterative combinations of these fields. Consequently, each new test case contains at least two anomalous field values. These results further confirm the effectiveness of our memory feedback module.\nFigure 15. Number of interesting cases for each protocol state during the testing process of VxWorks6.6 Figure 16. Number of interesting cases for each protocol state during the testing process of VxWorks6.9 Figure 17. Number of interesting cases for each protocol state during the testing process of VxWorks6.9_z7 5. Discussion # The vxTcpFuzzer has been successfully tested on three different VxWorks devices, revealing two potential security vulnerabilities. However, the efficiency and scalability of the framework still have certain limitations. In this section, we mainly discuss the limitations of the framework and propose possible solutions for future work:\nManual Protocol Feature Extraction. In the framework of this paper, the protocol feature fusion fuzzer relies on manual extraction and a certain level of TCP protocol knowledge in the protocol field feature extraction part. The manual extraction work mainly includes the manual analysis and extraction of the relevant features of each field in the TCP protocol header. It requires a specific understanding of the basic structure and function of each field in TCP and the ability to use programming to describe the feature information of each field in the form of corresponding vectors. This part of the work is the foundation and beginning of the entire fuzz testing and to some extent determines the efficiency of the entire fuzz testing. Therefore, manual extraction increases the workload of the fuzzing framework and may affect the effectiveness of fuzz testing. To remove this limitation, we will consider using LLM models to automatically extract protocol field features in future work.\nTest Protocol Scope. The fuzzing framework implemented in this paper currently only tests the TCP protocol of the VxWorks system, covering a limited range of protocols. VxWorks has a powerful networking system that provides users with a variety of network protocols, including IP, ICMP, RIP, FTP, Telnet, HTTP, and DNS. Therefore, we plan to further expand the types of protocols that the framework can test to provide a multi-protocol coverage fuzzing framework for the VxWorks network structure.\nPotential Risks and Balancing Strategies. In mission-critical real-time systems (such as VxWorks), aggressive fuzz testing strategies may introduce additional risks. For instance, high-frequency abnormal inputs could lead to system resource exhaustion or service interruptions, undermining the scheduling stability of real-time tasks; the triggering of certain vulnerabilities might cause irreversible system crashes, resulting in severe consequences in scenarios like aerospace and medical care. Thus, in practical deployment, it is necessary to balance testing depth against system reliability. This can be achieved through measures such as limiting testing rates, utilizing test environments isolated from production environments, or adopting progressive load injection strategies. Future work may explore dynamic adjustment mechanisms that adaptively modify testing intensity based on the real-time state of the system, aiming to balance security and availability. Limitations and Future Work. The fuzzing framework in this paper can be enhanced in several aspects. First, as described in Section 3.3, the new coverage metric used in this framework judges by comparing whether the task memory data changes before and after each round of testing. This is a relatively coarse and direct use of memory change information. Therefore, more fine-grained analysis can be conducted, such as analyzing program code through memory data to obtain specific coverage path information. Second, in the protocol feature fusion fuzzing stage of this framework, the extraction of protocol features requires manual analysis and is not fully automated. To address this issue, we plan to try methods such as [38,39] to achieve automated protocol feature extraction and fusion. Finally, the current framework only targets the TCP protocols in the VxWorks system. We therefore plan to further extend it to other protocols in the VxWorks system, including various application layer protocols provided by VxWorks.\n6. Conclusions # In this paper, we present vxTcpFuzzer, a TCP fuzzing framework specifically designed for VxWorks operating systems in black-box environment. Unlike conventional black-box network fuzzers, vxTcpFuzzer leverages memory data changes during VxWorks network task execution to establish a feedback-driven mechanism that guides the fuzzing process. Additionally, vxTcpFuzzer analyzes and extracts field features of the protocol, matching different generation strategies based on these features, thereby enabling the generation of test cases that highly conform to syntactic rules. Moreover, vxTcpFuzzer can activate and track the state changes of the TCP, performing fuzzing with multi-state coverage of the protocol. We tested vxTcpFuzzer on three VxWorks system devices, and it successfully detected potential vulnerabilities in the devices, verifying the effectiveness of the method.\nThis work increases the efficiency of vulnerability discovery in the TCP stack of VxWorks and, more importantly, provides an immediate benefit to the security of widely deployed IoT devices. As the operating system in critical IoT devices—industrial control systems, medical equipment, and network infrastructure—VxWorks demands a robust network stack. vxTcpFuzzer is an efficient, lightweight tool that actively uncovers deep bugs such as CVE-2019-12255 and CVE-2019-12258. Exploitation of these flaws can trigger denial-of-service, enable remote control, or turn devices into stepping stones for botnets like Mirai. By furnishing a practical technique for hardening IoT infrastructure, vxTcpFuzzer strengthens resilience against cyber attacks.\nAuthor Contributions # Conceptualization, Y.W. and J.H.; methodology, Y.W.; software, J.H. and X.H.; validation, Y.W., J.H., and X.H.; formal analysis, J.H.; investigation, J.H. and X.D.; resources, Y.W. and X.H.; data curation, Y.W. and J.H.; writing—original draft preparation, J.H.; writing—review and editing, J.H. and X.D.; visualization, J.H.; supervision, Y.W.; project administration, Y.W.; funding acquisition, Y.W. and X.H. All authors have read and agreed to the published version of the manuscript.\nFunding # This research work is supported by the National Natural Science Founds of China (U2468206,62302389) and the Key Research and Development Program of Shaanxi Province (2022CGKC-09).\nData Availability Statement # The raw data supporting the conclusions of this article will be made available by the authors on request.\nConflicts of Interest # The authors declare no conflicts of interest.\nReferences # Kostas, K.; Just, M.; Lones, M.A. IoTDevID: A behavior-based device identification method for the IoT. IEEE Internet Things J. 2022, 9, 23741–23749. [Google Scholar] [CrossRef]\nChui, M.; Collins, M.; Patel, M. The Internet of Things: Catching up to an Accelerating Opportunity; McKinsey \u0026amp; Company: New York, NY, USA, 2021. [Google Scholar]\nAffinito, A.; Zinno, S.; Stanco, G.; Botta, A.; Ventre, G. The evolution of Mirai botnet scans over a six-year period. J. Inf. Secur. Appl. 2023, 79, 103629. [Google Scholar] [CrossRef]\nMicro, T. Smart Yet Flawed: IoT Device Vulnerabilities Explained. Secur. News, Trend Micro Inc., Irving, TX, USA, Tech. Rep 2020. Available online: https://www.trendmicro.com/vinfo/hk-en/security/news/internet-of-things/smart-yet-flawed-iot-device-vulnerabilities-explained (accessed on 8 August 2025).\nNordrum, A. Popular internet of things forecast of 50 billion devices by 2020 is outdated. IEEE Spectr. 2016, 18, 223–236. [Google Scholar]\nTravis, F.J.M. Secure Interface Improvements Internet of Things (IoT) Vendors Need to Protect Smart Home IoT Devices from Cyber Attacks. Ph.D. Thesis, University of the Cumberlands, Williamsburg, KY, USA, 2023. [Google Scholar]\nMore, S.; Mukhede, S.; Deshmukh, M.M. Comparative Analysis of Embedded Operating Systems: A Criteria-Based Evaluation. Int. J. Eng. Technol. Manag. Sci. 2024, 1, 34–41. [Google Scholar]\nFormaggio, Y. Attacking VxWorks: From Stone Age to Interstellar. 44CON Cyber Security 2015. Available online: https://www.youtube.com/watch?v=T6N-87GlmsI (accessed on 8 August 2025).\nBishop, S.; Fairbairn, M.; Norrish, M.; Sewell, P.; Smith, M.; Wansbrough, K. Rigorous specification and conformance testing techniques for network protocols, as applied to TCP, UDP, and Sockets. In Proceedings of the 2005 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, Philadelphia, PA, USA, 22–26 August 2005; pp. 265–276. [Google Scholar]\nEdwards, A.; Muir, S. Experiences implementing a high performance TCP in user-space. ACM SIGCOMM Comput. Commun. Rev. 1995, 25, 196–205. [Google Scholar] [CrossRef]\nZou, Y.-H.; Bai, J.-J.; Zhou, J.; Tan, J.; Qin, C.; Hu, S.-M. {TCP-Fuzz}: Detecting memory and semantic bugs in {TCP} stacks with fuzzing. In Proceedings of the 2021 USENIX Annual Technical Conference (USENIX ATC 21), Santa Clara, CA, USA, 14–16 July 2021; pp. 489–502. [Google Scholar]\nLockefeer, L.; Williams, D.M.; Fokkink, W. Formal specification and verification of TCP extended with the Window Scale Option. Sci. Comput. Program. 2016, 118, 3–23. [Google Scholar] [CrossRef]\nChen, Q.A.; Qian, Z.; Jia, Y.J.; Shao, Y.; Mao, Z.M. Static detection of packet injection vulnerabilities: A case for identifying attacker-controlled implicit information leaks. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, Denver, CO, USA, 12–16 October 2015; pp. 388–400. [Google Scholar]\nKothari, N.; Mahajan, R.; Millstein, T.; Govindan, R.; Musuvathi, M. Finding protocol manipulation attacks. In Proceedings of the ACM SIGCOMM 2011 Conference, Toronto, ON, Canada, 15–19 August 2011; pp. 26–37. [Google Scholar]\nOehlert, P. Violating assumptions with fuzzing. IEEE Secur. Priv. 2005, 3, 58–62. [Google Scholar] [CrossRef]\nMiller, B.P.; Fredriksen, L.; So, B. An empirical study of the reliability of UNIX utilities. Commun. ACM 1990, 33, 32–44. [Google Scholar] [CrossRef]\nMuench, M.; Stijohann, J.; Kargl, F.; Francillon, A.; Balzarotti, D. What You Corrupt Is Not What You Crash: Challenges in Fuzzing Embedded Devices. In Proceedings of the NDSS, Montreal, QC, Canada, 3–8 December 2018. [Google Scholar]\nZheng, Y.; Davanian, A.; Yin, H.; Song, C.; Zhu, H.; Sun, L. {FIRM-AFL}:{High-Throughput} greybox fuzzing of {IoT} firmware via augmented process emulation. In Proceedings of the 28th USENIX Security Symposium (USENIX Security 19), Santa Clara, CA, USA, 14–16 August 2019; pp. 1099–1114. [Google Scholar]\nJTPEREYDA. Boofuzz: Network Protocol Fuzzing for Humans. Available online: https://github.com/jtpereyda/boofuzz (accessed on 28 June 2025).\nLuo, Z.; Zuo, F.; Jiang, Y.; Gao, J.; Jiao, X.; Sun, J. Polar: Function code aware fuzz testing of ics protocol. ACM Trans. Embed. Comput. Syst. (TECS) 2019, 18, 1–22. [Google Scholar] [CrossRef]\nPham, V.-T.; Böhme, M.; Roychoudhury, A. Aflnet: A greybox fuzzer for network protocols. In Proceedings of the 2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST), Porto, Portugal, 24–28 October 2020; pp. 460–465. [Google Scholar]\nChen, J.; Diao, W.; Zhao, Q.; Zuo, C.; Lin, Z.; Wang, X.; Lau, W.C.; Sun, M.; Yang, R.; Zhang, K. IoTFuzzer: Discovering memory corruptions in IoT through app-based fuzzing. In Proceedings of the NDSS, Montreal, QC, Canada, 3–8 December 2018; pp. 1–15. [Google Scholar]\nLuo, Z.; Yu, J.; Zuo, F.; Liu, J.; Jiang, Y.; Chen, T.; Roychoudhury, A.; Sun, J. Bleem: Packet sequence oriented fuzzing for protocol implementations. In Proceedings of the 32nd USENIX Security Symposium (USENIX Security 23), Anaheim, CA, USA, 9–11 August 2023; pp. 4481–4498. [Google Scholar]\nEddington, M. Peach Fuzzing Platform. Available online: https://gitlab.com/gitlab-org/securi-ty-products/protocol-fuzzer-ce (accessed on 28 June 2025).\nShu, Z.; Yan, G. IoTInfer: Automated Blackbox Fuzz Testing of IoT Network Protocols Guided by Finite State Machine Inference. IEEE Internet Things J. 2022, 9, 22737–22751. [Google Scholar] [CrossRef]\nYu, Z.; Wang, H.; Wang, D.; Li, Z.; Song, H. CGFuzzer: A Fuzzing Approach Based on Coverage-Guided Generative Adversarial Networks for Industrial IoT Protocols. IEEE Internet Things J. 2022, 9, 21607–21619. [Google Scholar] [CrossRef]\nLuo, Z.; Yu, J.; Du, Q.; Zhao, Y.; Wu, F.; Shi, H.; Chang, W.; Jiang, Y. Parallel Fuzzing of IoT Messaging Protocols Through Collaborative Packet Generation. IEEE Trans. Comput.-Aided Des. Integr. Circuits Syst. 2024, 43, 3431–3442. [Google Scholar] [CrossRef]\nRFC 793: TCP (Transmission Control Protocol). Available online: https://www.rfc-editor.org/rfc/rfc793 (accessed on 28 June 2025).\nLiu, P.; Lu, J.; Huang, S.; Lu, P.; Wang, J. Real-time performance analysis of network buffer under multi-core scheduling platform. Multimed. Tools Appl. 2023, 82, 34653–34677. [Google Scholar] [CrossRef]\nFeng, X.; Sun, R.; Zhu, X.; Xue, M.; Wen, S.; Liu, D.; Nepal, S.; Xiang, Y. Snipuzz: Black-box fuzzing of iot firmware via message snippet inference. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, New York, NY, USA, 15–19 November 2021; pp. 337–350. [Google Scholar]\nLi, R. Computer embedded automatic test system based on VxWorks. Int. J. Embed. Syst. 2022, 15, 183–192. [Google Scholar] [CrossRef]\nZheng, W.; Zhou, Y.; Wang, B. Design and Implementation of VxWorks System Vulnerability Mining Framework Based on Dynamic Symbol Execution. In Proceedings of the 9th International Conference on Computer Engineering and Networks, Hefei, China, 17–19 October 2020; pp. 801–811. [Google Scholar]\nRFC 1323: TCP Extensions for High Performance. Available online: https://www.rfc-editor.org/rfc/rfc1323 (accessed on 28 June 2025).\nRFC 5925: The TCP Authentication Option. Available online: https://www.rfc-editor.org/rfc/rfc5925 (accessed on 28 June 2025).\n11 Zero Day Vulnerabilities Impacting Billions of Mission-Critical Devices. Available online: https://www.armis.com/research/urgent-11 (accessed on 28 June 2025).\nZynq-7000 SoC Data Sheet: Overview. Available online: https://docs.amd.com/v/u/en-US/ds190-Zynq-7000-Overview (accessed on 28 June 2025).\nBossert, G.; Guihéry, F.; Hiet, G. Netzob: Protocol Reverse Engineering, Modeling and Fuzzing. Available online: https://github.com/netzob/netzob (accessed on 28 June 2025).\nYan, H.; Li, X.; Dai, R.; Li, H.; Zhao, X.; Li, F. MARS: Automated protocol analysis framework for internet of things. IEEE Internet Things J. 2022, 9, 18333–18345. [Google Scholar] [CrossRef]\nZhao, S.; Yang, S.; Wang, Z.; Liu, Y.; Zhu, H.; Sun, L. Crafting Binary Protocol Reversing via Deep Learning With Knowledge-Driven Augmentation. IEEE/ACM Trans. Netw. 2024, 32, 5399–5414. [Google Scholar] [CrossRef]\nDisclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.\n© 2025 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).\n","date":"2025-09-07","externalUrl":null,"permalink":"/app/a-high-acceptance-rate-vxworks-fuzzing-framework/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eby Yichuan Wang 1,2,Jiazhao Han 1,Xi Deng 1 andXinhong Hei 1,2,*\n1 School of Computer Science and Engineering, Xi’an University of Technology, Xi’an 710048, China\n2 Shaanxi Key Laboratory for Network Computing and Security Technology, Xi’an 710048, China\u003c/p\u003e","title":"A High Acceptance Rate VxWorks Fuzzing Framework Based on Protocol Feature Fusion and Memory Extraction","type":"app"},{"content":"","date":"2025-09-07","externalUrl":null,"permalink":"/tags/system-security/","section":"Tags","summary":"","title":"System Security","type":"tags"},{"content":"","date":"2025-09-06","externalUrl":null,"permalink":"/tags/user-authentication/","section":"Tags","summary":"","title":"User Authentication","type":"tags"},{"content":" Table of Contents # Introduction to User Authentication in VxWorks 7 Why User Authentication and Management Matter Core Features of User Authentication in VxWorks 7 Hands-On: Configuring Secure User Authentication in VxWorks 7 Step 1: Create and Build the VSB Project Step 2: Create and Build the VIP Project Step 3: Boot the Target and Create Initial User Step 4: Adding Users and Managing Privileges Best Practices for VxWorks User Management Challenges and Solutions FAQ: VxWorks 7 User Authentication Conclusion Introduction to User Authentication in VxWorks 7 # In the realm of embedded systems, security is paramount, especially for real-time operating systems (RTOS) like VxWorks 7 from Wind River. As industries such as aerospace, automotive, and industrial automation increasingly rely on connected devices, implementing robust user authentication and management becomes essential to prevent unauthorized access and ensure system integrity.\nVxWorks 7 offers advanced features for user authentication, including secure login mechanisms, user database management, and policy enforcement, making it a top choice for mission-critical applications.\nThis guide dives deep into VxWorks 7 user authentication and management, covering key features, configuration steps, practical code examples, and best practices. We’ll focus on enabling secure user login for the kernel shell, a common requirement for protecting access to embedded systems.\nWhy User Authentication and Management Matter in VxWorks # The VxWorks 7 user authentication framework protects devices from unauthorized access by requiring credentials before granting shell access or executing privileged operations.\nKey benefits include:\nEnhanced Security: Prevents default or anonymous access, aligning with certifications (IEC 61508, ISO 26262). Policy Enforcement: Password complexity rules, failed login attempts, and user privileges. Flexibility: Integrates with local UDB or enterprise systems like LDAP/Active Directory. Compliance: DISA User Management features enforce stricter controls (password length, failed login limits). Compared to older versions (e.g., loginLib), VxWorks 7 provides improved hashing and runtime configuration for stronger protection.\nCore Features of User Authentication in VxWorks 7 # The Security Profile in VxWorks 7 enhances user management with:\nUser Database (UDB): Encrypted storage of user credentials. Secure Login Policy: Required authentication for shell access. Role-Based Privileges: RBAC with manifest files for permissions. LDAP/AD Integration: Runtime configurable for enterprise authentication. Advanced Policies: Failed login limits, password rules, secure boot integration. Tools \u0026amp; APIs: Includes USER_MANAGEMENT, INCLUDE_SHELL_SECURITY, and functions like userAdd. Hands-On: Configuring Secure User Authentication in VxWorks 7 # Let’s configure secure login for a simulated target (vxsim_windows) using Wind River Workbench.\nStep 1: Create and Build the VxWorks Source Build (VSB) Project # cd \u0026lt;WIND_HOME\u0026gt; wrenv -p vxworks-7 cd \u0026lt;YOUR_WORKSPACE\u0026gt; vxprj vsb create users_vsb -bsp vxsim_windows -smp -force -S cd users_vsb # Add authentication components vxprj vsb add USER_MANAGEMENT vxprj vsb add USER_MANAGEMENT_POLICY vxprj vsb add USER_MANAGEMENT_USER_PRIVILEGES # Build make -j 32 Step 2: Create and Build the VxWorks Image Project (VIP) # cd .. vxprj create -smp vxsim_windows users_vip -profile PROFILE_DEVELOPMENT -vsb users_vsb cd users_vip # Add components vxprj vip bundle add BUNDLE_STANDALONE_SHELL vxprj vip component add INCLUDE_USER_DATABASE vxprj vip component add INCLUDE_SHELL_SECURITY vxprj vip component add INCLUDE_LOGIN_POLICY # Parameters vxprj parameter set UDB_STORAGE_PATH \u0026#34;\\\u0026#34;host:vxUserDB.txt\\\u0026#34;\u0026#34; vxprj parameter set UDB_PROMPT_INITIAL_USER TRUE vxprj parameter set UDB_HASH_KEY \u0026#34;\\\u0026#34;\\x48\\x61\\x72\\x6d\\x6f\\x6e\\x69\\x63\\x73\\x73\\\u0026#34;\u0026#34; # Build vxprj build Step 3: Boot the Target and Create Initial User # cd default vxsim At the prompt:\nEnter initial username and password. Then log in: login: \u0026lt;your_username\u0026gt; password: \u0026lt;your_password\u0026gt; Step 4: Adding Users and Managing Privileges (Code Examples) # -\u0026gt; userAdd \u0026#34;newuser\u0026#34;, \u0026#34;securepassword\u0026#34; value = 0 = 0x0 -\u0026gt; logout For privilege management:\nvxprj vip component add INCLUDE_USER_PRIVILEGES vxprj vip parameter set PRIVILEGE_MANIFEST_PATH \u0026#34;\\\u0026#34;host:privilege_manifest/prvlgManifest.txt\\\u0026#34;\u0026#34; prvlgManifest.txt example:\n[user:newuser] allow: shell_commands deny: system_reboot Best Practices for VxWorks User Management # Use SHA-256 hashing (default in VxWorks 7). Integrate LDAP/Active Directory for enterprise deployments. Enforce DISA security policies (failed login limits, password complexity). Perform regular audits and track failed login attempts. Use secure boot to ensure only signed binaries run. Test thoroughly in a dev environment before production rollout. Challenges and Solutions # UDB File Deletion: System prompts for new user → Store UDB on encrypted filesystem. Privilege Errors: No-privileges by default → Customize manifest. Weak Hashing in Old Versions: Upgrade to VxWorks 7 with SHA-256. FAQ: VxWorks 7 User Authentication # Q: How do I enable secure login in VxWorks 7? A: Add INCLUDE_SHELL_SECURITY and configure UDB_STORAGE_PATH in your VIP project.\nQ: Can VxWorks 7 integrate with Active Directory or LDAP? A: Yes, it supports runtime LDAP/AD configuration for enterprise authentication.\nQ: What hashing algorithm is used for VxWorks 7 passwords? A: VxWorks 7 uses SHA-256 hashing for stronger password protection.\nQ: Where is the user database stored? A: By default in vxUserDB.txt, which is encrypted. For production, store it on secure or encrypted storage.\nConclusion # Implementing user authentication and management in VxWorks 7 strengthens embedded system security and ensures only authorized users access critical functions. By following this guide’s step-by-step process, you can configure a secure setup tailored to your needs.\nFor more advanced security features, refer to the VxWorks 7 Security Programmer’s Guide or explore integration with enterprise authentication systems like LDAP and Active Directory.\n","date":"2025-09-06","externalUrl":null,"permalink":"/app/vxworks-7-user-authentication-and-management-step-by-step-secure-login-guide/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003eTable of Contents \n    \u003cdiv id=\"table-of-contents\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#table-of-contents\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#introduction-to-user-authentication-in-vxworks-7\"\u003eIntroduction to User Authentication in VxWorks 7\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#why-user-authentication-and-management-matter-in-vxworks\"\u003eWhy User Authentication and Management Matter\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#core-features-of-user-authentication-in-vxworks-7\"\u003eCore Features of User Authentication in VxWorks 7\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#hands-on-configuring-secure-user-authentication-in-vxworks-7\"\u003eHands-On: Configuring Secure User Authentication in VxWorks 7\u003c/a\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"#step-1-create-and-build-the-vxworks-source-build-vsb-project\"\u003eStep 1: Create and Build the VSB Project\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#step-2-create-and-build-the-vxworks-image-project-vip\"\u003eStep 2: Create and Build the VIP Project\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#step-3-boot-the-target-and-create-initial-user\"\u003eStep 3: Boot the Target and Create Initial User\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#step-4-adding-users-and-managing-privileges-code-examples\"\u003eStep 4: Adding Users and Managing Privileges\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#best-practices-for-vxworks-user-management\"\u003eBest Practices for VxWorks User Management\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#challenges-and-solutions\"\u003eChallenges and Solutions\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#faq-vxworks-7-user-authentication\"\u003eFAQ: VxWorks 7 User Authentication\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#conclusion\"\u003eConclusion\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eIntroduction to User Authentication in VxWorks 7 \n    \u003cdiv id=\"introduction-to-user-authentication-in-vxworks-7\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction-to-user-authentication-in-vxworks-7\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn the realm of embedded systems, \u003cstrong\u003esecurity is paramount\u003c/strong\u003e, especially for real-time operating systems (RTOS) like \u003cstrong\u003eVxWorks 7\u003c/strong\u003e from Wind River. As industries such as aerospace, automotive, and industrial automation increasingly rely on connected devices, implementing robust \u003cstrong\u003euser authentication and management\u003c/strong\u003e becomes essential to prevent unauthorized access and ensure system integrity.\u003c/p\u003e","title":"VxWorks 7 User Authentication and Management: Step-by-Step Secure Login Guide","type":"app"},{"content":"","date":"2025-09-05","externalUrl":null,"permalink":"/tags/cve/","section":"Tags","summary":"","title":"CVE","type":"tags"},{"content":"","date":"2025-09-05","externalUrl":null,"permalink":"/tags/security/","section":"Tags","summary":"","title":"Security","type":"tags"},{"content":"","date":"2025-09-05","externalUrl":null,"permalink":"/tags/vulnerabilities/","section":"Tags","summary":"","title":"Vulnerabilities","type":"tags"},{"content":"Wind River, a global leader in software for mission-critical intelligent systems, has been officially approved as a CVE® Numbering Authority (CNA) by the Common Vulnerabilities and Exposures (CVE) Program. This milestone underscores the company’s ongoing commitment to improving cybersecurity transparency, vulnerability disclosure, and system reliability for its customers and the wider technology ecosystem.\nWhy Becoming a CVE Numbering Authority Matters # As industries move rapidly toward a hyper-connected, intelligent future, cybersecurity challenges are becoming more complex and global. By joining the CVE Program, Wind River can now:\nAssign CVE IDs to vulnerabilities discovered in its products or services Publish detailed vulnerability records for the global community Support faster vulnerability identification and correlation by IT and security professionals Enable timely response strategies to defend against evolving cyber threats This step enhances trust and transparency, ensuring customers and partners benefit from improved vulnerability management and disclosure processes.\nIndustry Perspective # \u0026ldquo;As all industries accelerate toward a highly interconnected and intelligent future, the cybersecurity threat landscape continues to evolve, making security a global focus. By becoming a CVE Numbering Authority, Wind River will be able to provide customers with more efficient and professional vulnerability management services, further demonstrating the company\u0026rsquo;s firm commitment and responsibility in the field of cybersecurity.\u0026rdquo;\n— Eashwer Srinivasan, Vice President of Engineering at Wind River\nAbout the CVE Program # The CVE Program is a global, community-driven initiative that provides standardized identifiers for publicly known security vulnerabilities. Key highlights include:\nUnified vulnerability identification: CVE IDs ensure consistent tracking across tools and databases. Global collaboration: CNAs around the world contribute to maintaining the CVE List. Integration with NVD: All CVE records are also included in the National Vulnerability Database (NVD), maintained by the U.S. National Institute of Standards and Technology (NIST). Authoritative security resource: The NVD provides SCAP-compliant data used by governments, enterprises, and security researchers worldwide. What This Means for Customers # As a CNA, Wind River can now directly manage vulnerability disclosure for its solutions. This allows:\nFaster response to emerging threats Improved communication with customers and partners More reliable, secure mission-critical systems By taking on this responsibility, Wind River demonstrates its role not only as a technology provider but also as a trusted cybersecurity partner in the broader ecosystem.\nConclusion # Wind River’s recognition as a CVE Numbering Authority highlights its leadership in cybersecurity best practices and its dedication to building a safer digital future. For customers and the industry alike, this ensures greater security transparency, stronger defenses, and higher confidence in mission-critical systems.\n","date":"2025-09-05","externalUrl":null,"permalink":"/news/wind-river-named-cve-numbering-authority-strengthening-cybersecurity-leadership/","section":"News","summary":"\u003cp\u003e\u003cstrong\u003eWind River\u003c/strong\u003e, a global leader in software for mission-critical intelligent systems, has been officially approved as a \u003cstrong\u003eCVE® Numbering Authority (CNA)\u003c/strong\u003e by the \u003cstrong\u003eCommon Vulnerabilities and Exposures (CVE) Program.\u003c/strong\u003e This milestone underscores the company’s ongoing commitment to improving \u003cstrong\u003ecybersecurity transparency, vulnerability disclosure, and system reliability\u003c/strong\u003e for its customers and the wider technology ecosystem.\u003c/p\u003e","title":"Wind River Named CVE Numbering Authority, Strengthening Cybersecurity Leadership","type":"news"},{"content":" In high-reliability embedded systems—where deterministic behavior and fault tolerance are non-negotiable—VxWorks has long been a cornerstone RTOS. Used in spacecraft, avionics, and defense systems, it combines real-time performance with industrial-grade robustness.\nThis article explores the adaptation of VxWorks 7.0 to the NXP (Freescale) T2080 processor, based on a research implementation targeting airborne radar systems. It walks through the full porting workflow, from bootloader selection to kernel configuration, device tree integration, and custom driver development.\n🚀 Why VxWorks 7.0 and the T2080? # VxWorks has a long history in mission-critical environments such as the Mars Pathfinder, Patriot missile systems, and fighter aircraft. With VxWorks 7, Wind River introduced a modular, componentized architecture that separates the core kernel from services like networking and file systems. This design improves scalability, maintainability, and support for modern 64-bit PowerPC platforms.\nThe T2080 processor belongs to NXP’s QorIQ family and is designed for compute-intensive embedded workloads:\nQuad-core PowerPC architecture with SMT (8 threads) Integrated AltiVec vector engine Up to 172 GFLOPS of vector performance Optimized for radar, networking, industrial control, and defense systems In the referenced research, the T2080 is used as the foundation for a universal processing card in airborne radar units. The primary objective of the adaptation was to achieve predictable real-time behavior while fully exploiting the processor’s parallel and vector-processing capabilities.\n🧰 Bootloader Development with U-Boot # A robust bootloader is essential for any RTOS port. For VxWorks 7, Wind River recommends U-Boot, replacing the legacy Bootrom approach used in VxWorks 6.x.\nU-Boot offers several advantages:\nRich hardware debug commands Flexible boot media support Easier board-level customization Strong community and vendor backing Development Environment # The adaptation was performed using:\nUbuntu 14.04 running on VMware Cross-compilation tools from the NXP Yocto SDK U-Boot source tailored for QorIQ platforms Key source directories included:\narch/powerpc/mpc85xx for processor startup code board/freescale/t208xrdb as the reference board template Boot Flow on the T2080 # The T2080 supports multiple boot sources, including IFC NOR Flash, SPI Flash, and eMMC.\nNOR Flash boot\nStage 1: Assembly code initializes basic hardware and DDR, then copies U-Boot to RAM Stage 2: C code configures MMU, peripherals, networking, and loads the kernel SPI Flash / eMMC boot\nUses U-Boot SPL, which runs from internal SRAM SPL initializes DDR and loads the full U-Boot image into RAM Board Transplantation # Porting U-Boot required:\nCreating a custom board directory (e.g., t208xleihua) Modifying configuration headers and device parameters Adding board-specific defconfig entries The final image was built using standard U-Boot build commands, producing a tailored bootloader capable of reliably launching VxWorks 7 on the custom T2080 hardware.\n⚙️ Kernel Adaptation in VxWorks 7 # Once U-Boot was operational, attention shifted to adapting the VxWorks kernel using Wind River Workbench 4.0.\nVxWorks 7 introduces several architectural changes:\nBSP logic is reorganized into the Platform Support Library (PSL) Drivers follow the VxBus GEN2 model Kernel services are built and configured through modular projects VSB and VIP Projects # The workflow involves two primary project types:\nVSB (VxWorks Source Build)\nCompiles core libraries and system components\nVIP (VxWorks Image Project)\nBuilds the final bootable kernel image\nDevelopers select required kernel components—such as networking, file systems, or debugging features—through the Kernel Configuration interface, then build the final image for deployment.\n🌳 Device Tree Integration # A major improvement in VxWorks 7 is its adoption of the Device Tree (DT) mechanism, inspired by Linux.\nPreviously, hardware details were embedded directly in BSP or driver code, requiring recompilation for any hardware change. Device Tree decouples hardware description from software logic.\nKey characteristics:\nHardware is described in a human-readable DTS file DTS is compiled into a binary DTB U-Boot passes the DTB to the kernel at boot time The kernel dynamically binds drivers to devices based on DT entries For the T2080 board, the DTS file resides in the BSP directory and defines CPUs, memory regions, interrupts, buses, and peripherals. Tools such as vxrtdtbdump are used to inspect and validate the DTB during debugging.\n🔌 Custom Driver Development # Although VxWorks provides many standard drivers, certain T2080-specific peripherals—such as SRIO interfaces—required custom implementation.\nDriver development followed these principles:\nUse DKM (Downloadable Kernel Module) projects Conform to VxBus GEN2 driver architecture Define hardware resources via Device Tree nodes In the SRIO case, multiple physical ports were modeled as a single logical device with shared registers. Driver source code was integrated into the VSB for tight coupling with the kernel, allowing performance tuning and bug fixes at the system level.\n📌 Key Takeaways # This adaptation demonstrates a complete and modern workflow for porting VxWorks 7.0 to a high-performance PowerPC platform:\nU-Boot provides a flexible and debuggable boot foundation VxWorks 7’s modular architecture simplifies kernel customization Device Tree cleanly separates hardware description from software VxBus GEN2 enables scalable, reusable driver design The approach serves as a practical reference for engineers working on PowerPC-based real-time systems, particularly in aerospace, radar, and defense applications where performance and determinism are critical.\n","date":"2025-09-03","externalUrl":null,"permalink":"/bsp/adapting-vxworks-7.0-to-t2080-bootloader-kernel-and-driver-development/","section":"Bsps","summary":"\u003c!--# Adapting VxWorks 7 to the T2080 PowerPC Processor--\u003e\n\u003cp\u003eIn high-reliability embedded systems—where deterministic behavior and fault tolerance are non-negotiable—VxWorks has long been a cornerstone RTOS. Used in spacecraft, avionics, and defense systems, it combines real-time performance with industrial-grade robustness.\u003c/p\u003e","title":"Adapting VxWorks 7 to the T2080 PowerPC Processor","type":"bsp"},{"content":"","date":"2025-09-03","externalUrl":null,"permalink":"/tags/gnu-gcc/","section":"Tags","summary":"","title":"GNU GCC","type":"tags"},{"content":"This guide walks you through installing the Cobham Gaisler VxWorks 6.7 Source Distribution, which includes:\nA SPARC port of the VxWorks 6.7 kernel Generic BSPs (with and without MMU) Several board-specific BSPs The GNU GCC LEON toolchain LEON plug-ins for the Workbench IDE The process includes installing the Wind River VxWorks platform, service pack, toolchain, LEON distribution, building the SPARC/LEON kernel, and updating Workbench build rules.\nPrerequisites # Wind River VxWorks General Purpose Platform (GPP) 3.7 with full kernel sources A valid Wind River source license Installed Workbench 3.1 (other versions not supported) ⚠️ Note: The Cobham Gaisler VxWorks distribution must match the Wind River version (e.g., 6.7 with 6.7). Mixing 6.5 and 6.7 is not supported.\nDefault installation paths:\nWindows: C:\\WindRiver6.7 Linux: /opt/WindRiver6.7 Step 1: Install VxWorks 6.7 Service Pack 1 # The LEON VxWorks distribution is built against Service Pack 1.\nDownload: DVD-R138711.1-6-01.zip from Wind River Support.\nWhen installing:\nDeselect “Check online for latest updates” to prevent version mismatches. Figure 1.1. Deselect updating Step 2: Install the GNU GCC LEON Toolchain # The LEON distribution requires its own GNU GCC toolchain (not Wind River’s).\nDownload from Gaisler’s protected area.\nInstall location must be:\nWindows: C:\\opt Linux: /opt Windows Installation # Two options:\nInstaller:\nRun sparc-wrs-vxworks-4.1-x.y.z-mingw.exe\nInstalls to C:\\opt\\sparc-wrs-vxworks-mingw and updates PATH.\nFigure 2.1. VxWorks GNU GCC LEON toolchain Windows installer Log out and back in to refresh PATH.\nManual:\nExtract sparc-wrs-vxworks-4.1-x.y.z-mingw.zip into C:\\opt\nUpdate PATH manually in system environment variables.\nLinux Installation # cd /opt tar -xf sparc-wrs-vxworks-4.1-x.y.z-linux.tar.bz2 export PATH=/opt/sparc-wrs-vxworks/bin:$PATH Step 3: Install the LEON VxWorks Distribution # The distribution is provided as a password-protected zip (request password from support@gaisler.com).\nWindows # Use installer dist-x.y.z/install/setup-6.7-x.y.z.exe Enter your Wind River path Backup created under grbck and grbck.new Figure 3.1. Windows installer, enter WindRiver path Linux # Run the installation script:\ncd dist-x.y.z bash ./install/install.sh /opt/WindRiver6.7 Steps performed automatically:\nUninstall old LEON distribution Install LEON plug-ins for Workbench Install BSP \u0026amp; SPARC sources Update Makefile Backups are stored as .grbak and .grnew files.\nManual Installation (Advanced) # Extract VxWorks 6.7 SPARC/LEON sources Install Workbench plug-ins (SPARC-specific) Configure environment variables Step 4: Build the LEON VxWorks Kernel \u0026amp; Libraries # Extract the distribution:\ngunzip dist-vxworks-6.7-x.y.z.tar.gz tar -xf dist-vxworks-6.7-x.y.z.tar Available TOOL variants:\nTOOL Compiler FPU MUL/DIV gnu GCC Hardware SPARCv7 SW gnuv8 GCC Hardware SPARCv8 HW sfgnu GCC Software SPARCv7 SW sfgnuv8 GCC Software SPARCv8 HW Build on Windows # Use GUI builder: dist-x.y.z/install/compile-6.7.exe Figure 4.1. LEON VxWorks Kernel builder GUI Figure 4.2. Kernel Builder, enter WindRiver path Figure 4.3. Kernel Builder, enter WindRiver path Figure 4.4. Kernel builder GUI invoked the build scripts Or use Wind River Shell: C:\\WindRiver\\wrenv.exe -p vxworks-6.7 sh cd dist-x.y.z make multibuild TOOLS=\u0026#34;gnu gnuv8\u0026#34; Build on Linux # /opt/WindRiver/wrenv.sh -p vxworks-6.7 sh cd dist-x.y.z make multibuild TOOLS=\u0026#34;gnu gnuv8\u0026#34; Build logs are generated as:\nloc_sparc-compile-TOOL.out loc_lib-compile_usrtool_TOOL_tool_TOOL.out Step 5: Update Workbench Build Rules # To enable RTP and Downloadable Kernel Module (DKM) projects:\nOpen Workbench → Window \u0026gt; Preferences \u0026gt; Wind River \u0026gt; Build \u0026gt; Build Properties Select each build rule and click Restore Defaults Figure 5.1. Open the Workbench 3.1 preferences Figure 5.2. VxWorks project build rules for Workbench 3.1 Final Notes # Installation and build are now complete Refer to the Getting Started Guide in the docs directory for running projects on LEON hardware For support, contact: support@gaisler.com ","date":"2025-09-03","externalUrl":null,"permalink":"/bsp/installing-vxworks-6.7-on-leon-sparc/","section":"Bsps","summary":"\u003cp\u003eThis guide walks you through installing the \u003cstrong\u003eCobham Gaisler VxWorks 6.7 Source Distribution\u003c/strong\u003e, which includes:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eA SPARC port of the VxWorks 6.7 kernel\u003c/li\u003e\n\u003cli\u003eGeneric BSPs (with and without MMU)\u003c/li\u003e\n\u003cli\u003eSeveral board-specific BSPs\u003c/li\u003e\n\u003cli\u003eThe GNU GCC LEON toolchain\u003c/li\u003e\n\u003cli\u003eLEON plug-ins for the Workbench IDE\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe process includes installing the Wind River VxWorks platform, service pack, toolchain, LEON distribution, building the SPARC/LEON kernel, and updating Workbench build rules.\u003c/p\u003e","title":"Installing VxWorks 6.7 on LEON SPARC: Step-by-Step Guide","type":"bsp"},{"content":"","date":"2025-09-03","externalUrl":null,"permalink":"/tags/leon-sparc/","section":"Tags","summary":"","title":"LEON SPARC","type":"tags"},{"content":"","date":"2025-09-03","externalUrl":null,"permalink":"/tags/vxworks-6.7/","section":"Tags","summary":"","title":"VxWorks 6.7","type":"tags"},{"content":"","date":"2025-09-03","externalUrl":null,"permalink":"/tags/powerdna/","section":"Tags","summary":"","title":"PowerDNA","type":"tags"},{"content":"","date":"2025-09-03","externalUrl":null,"permalink":"/tags/ueipac/","section":"Tags","summary":"","title":"UEIPAC","type":"tags"},{"content":"United Electronic Industries (UEI) provides the UEIPAC platform as a powerful solution for embedded and real-time applications. Powered by VxWorks, the industry-leading real-time operating system (RTOS), UEIPAC supports a flexible range of CPU and I/O modules designed for industrial, aerospace, and military applications.\nThis article walks you through:\nBuilding and configuring a VxWorks kernel for UEIPAC Booting and storing the kernel image on the device Enabling networking, USB, and flash storage Using the PowerDNA API for real-time I/O programming Whether you are starting a new project or migrating an application, this guide will help you unlock the full potential of UEIPAC with VxWorks.\n1. Setting Up the VxWorks Kernel for UEIPAC # The UEIPAC VxWorks BSP (Board Support Package) provides all the components required to run VxWorks on UEI hardware.\n1.1 Install Software # Copy the UEIPAC VxWorks archive into your %WIND_HOME%\\vxworks-6.x\\target directory. Extract the archive: tar xvfz ueipac-vxworks-x.y.tgz Adjust GCC configuration by removing the -ansi flag in defs.gnu to ensure compatibility with the PowerDNA libraries. 1.2 Build External Drivers # UEIPAC requires additional drivers, including:\nPowerDNA driver for I/O layers Bonding driver for dual-port Ethernet fault tolerance Build and install these drivers into your VxWorks environment so they can be included in your kernel configuration.\n2. Kernel Configuration Options # When creating a VxWorks Image Project in Workbench, configure the following:\nSymbol Table Support #define INCLUDE_STANDALONE_SYM_TBL Serial Console #define INCLUDE_SIO #define CONSOLE_BAUD_RATE 57600 Networking: Configure dual Ethernet ports or enable bonding for redundancy. #define DRV_UEI_BONDING #define INCLUDE_IPIFCONFIG_CMD Flash Storage (TFFS/DOSFS): #define INCLUDE_IO_FILE_SYSTEM #define INCLUDE_TFFS #define TFFS_MOUNT_POINT \u0026#34;/tffs0\u0026#34; USB Host Support: #define INCLUDE_USB #define INCLUDE_EHCI #define INCLUDE_USB_SHOW These settings enable networking, file I/O, USB devices, and PowerDNA I/O layers.\n3. Booting VxWorks on UEIPAC # UEIPAC uses U-Boot as the boot loader.\n3.1 Manual Boot via TFTP # Start a TFTP server on your host.\nTransfer the kernel image:\n=\u0026gt; tftp 4000000 vxWorks =\u0026gt; bootvx 3.2 Store Kernel in Flash # Convert and flash the kernel for persistent boot:\n$ mkimage -O vxworks -C gzip -n \u0026#39;UEIPAC VxWorks\u0026#39; -a 4000000 -d uVxWorks.gz uVxWorks =\u0026gt; erase fe200000 fe3fffff =\u0026gt; tftp 4000000 uVxWorks =\u0026gt; cp.b 4000000 fe200000 ${filesize} =\u0026gt; bootm fe200000 Configure auto-boot with:\n=\u0026gt; setenv bootcmd bootm fe200000 =\u0026gt; saveenv 4. Programming with PowerDNA API # The PowerDNA API provides the software interface to control I/O layers on UEIPAC.\nSupported Modes # Immediate: Simple point-by-point I/O access. DMAP (Data Mapping): Efficient real-time refresh across multiple I/O layers. VMAP (Variable Mapping): High-performance buffered data transfers. Note: UEIPAC supports Immediate, DMAP, and VMAP modes locally. ACB and Messaging modes are supported only for remote devices.\nExample: DMAP I/O Programming # DqRtDmapInit(handle, \u0026amp;dmapid, 1000.0); // Init at 1 kHz DqRtDmapAddChannel(handle, dmapid, 1, DQ_SS0IN, \u0026amp;chentry, 1); // Add input DqRtDmapStart(handle, dmapid); // Start DqRtDmapRefresh(handle, dmapid); // Sync data DqRtDmapReadScaledData(handle, dmapid, 1, indata, 1); // Read input DqRtDmapStop(handle, dmapid); // Stop This allows real-time acquisition and output across multiple channels.\n5. Building and Running Applications # Applications can be built as Downloadable Kernel Modules (DKMs) in WindRiver Workbench:\nCreate a new DKM project.\nLink against the libPDNA.a library.\nTransfer the module via FTP:\n[vxWorks *] ftp 192.168.100.101 ftp\u0026gt; get Sample204.out Load and run:\n[vxWorks *] ld Sample204.out [vxWorks *] C main 6. Key Takeaways # UEIPAC with VxWorks provides a reliable RTOS platform for industrial and aerospace embedded applications. Kernel customization allows you to enable networking, storage, and USB support. U-Boot boot loader simplifies deployment of kernel images. The PowerDNA API delivers flexible programming interfaces for high-performance real-time I/O. With this setup, you can develop deterministic, real-time embedded applications that leverage UEIPAC’s hardware capabilities.\nFinal Thoughts # By combining VxWorks RTOS and UEIPAC hardware, engineers can build mission-critical systems with robust networking, storage, and I/O support. Whether you’re deploying in industrial automation, aerospace, or defense, mastering this workflow will ensure stable and efficient system performance.\n","date":"2025-09-03","externalUrl":null,"permalink":"/bsp/ueipac-vxworks-kernel-setup-and-powerdna-programming-guide/","section":"Bsps","summary":"\u003cp\u003eUnited Electronic Industries (UEI) provides the \u003cstrong\u003eUEIPAC platform\u003c/strong\u003e as a powerful solution for embedded and real-time applications. Powered by \u003cstrong\u003eVxWorks\u003c/strong\u003e, the industry-leading \u003cstrong\u003ereal-time operating system (RTOS)\u003c/strong\u003e, UEIPAC supports a flexible range of CPU and I/O modules designed for industrial, aerospace, and military applications.\u003c/p\u003e","title":"UEIPAC VxWorks: Kernel Setup and PowerDNA Programming Guide","type":"bsp"},{"content":"","date":"2025-09-01","externalUrl":null,"permalink":"/tags/memory-management/","section":"Tags","summary":"","title":"Memory Management","type":"tags"},{"content":"Efficient memory management is at the heart of every real-time operating system (RTOS), and VxWorks is no exception. As embedded applications grow in complexity—supporting networking, graphics, safety, and security—developers need to understand how VxWorks handles memory to ensure performance and reliability.\nIn this blog, we’ll explore the fundamentals of VxWorks memory management, covering the memory model, allocation mechanisms, MMU support, virtual memory, and best practices for embedded developers.\nVxWorks Memory Model # VxWorks is designed to be flexible and scalable across different hardware platforms, from microcontrollers to multicore processors. Its memory management model typically consists of:\nCode (text segment): Stores the compiled instructions of your application and kernel. Data: Stores global and static variables. Heap: Used for dynamic memory allocation (e.g., malloc, new). Stack: Allocated per task for local variables and function calls. I/O Buffers and Device Memory: For drivers and peripherals. Shared Memory: Allows inter-task or inter-process communication. Unlike desktop OSes, predictability and determinism are top priorities in VxWorks memory management. Every byte counts in embedded systems, especially those running safety-critical or mission-critical applications.\nDynamic Memory Allocation in VxWorks # Dynamic allocation is supported but must be carefully managed in embedded systems due to fragmentation risks.\nMemory Partitions # VxWorks provides memory partition libraries (memPartLib) that allow developers to create and manage custom memory pools. Each partition can be optimized for specific allocation patterns, reducing fragmentation.\n/* Example: Creating a memory partition */ char pool [1024]; PART_ID partId = memPartCreate (pool, sizeof(pool)); void *p = memPartAlloc (partId, 100); memPartFree (partId, p); Partitions are useful for:\nNetworking buffers (e.g., TCP/IP stack memory pools) Graphics framebuffers Message queues and IPC objects Safety-critical subsystems where memory must always be available Heap Allocation # Applications can use the standard heap (malloc, calloc, free), but long-running embedded systems often avoid heavy reliance on it. Instead, they prefer pre-allocated buffers or partitions for predictability.\n🔎 Tip: For deterministic performance, use fixed-size block allocation (via memPartAlloc or Wind River’s memory pools) instead of variable-size heap allocations.\nTask Stack Management # Every task in VxWorks has its own dedicated stack. Stack sizing is critical:\nToo small → risk of overflow, leading to data corruption. Too large → waste of precious memory resources. VxWorks provides stack analysis tools:\ntaskCheckStack(TASK_ID tid); /* Check if stack overflow occurred */ Best practices include:\nUse taskStackAllot() to set stack size explicitly. Enable stack overflow detection in debug builds. Profile stack usage under worst-case conditions. MMU (Memory Management Unit) and Protection # On processors that support it, VxWorks leverages the MMU to provide:\nVirtual-to-physical address mapping Memory protection (read/write/execute permissions) Task/Process isolation in VxWorks RTPs (Real-Time Processes) Example Use Cases # Preventing one task from corrupting another’s memory Enforcing read-only protection on critical code sections Mapping device registers into user space securely The MMU setup is usually handled by the BSP (Board Support Package), but developers can configure additional protections in user space when needed.\nVirtual Memory and RTPs in VxWorks 7 # VxWorks 7 introduced Real-Time Processes (RTPs), bringing UNIX-like process isolation to the RTOS world. Each RTP has:\nIts own virtual address space Isolated heaps and stacks Protection from kernel and other processes This improves security, fault isolation, and debugging, making VxWorks more suitable for complex applications like IoT gateways, medical devices, and industrial controllers.\nMonitoring and Debugging Memory Usage # VxWorks provides built-in tools for memory diagnostics:\nmemShow() → Displays current heap usage and fragmentation. memPartShow() → Shows partition statistics. Wind River Workbench IDE → Visual memory profiling tools. Example usage:\nmemShow(0); /* Show default system memory pool */ memPartShow(partId); /* Show custom partition usage */ 🔎 Tip: Periodically log memory usage in long-running systems to catch leaks early.\nBest Practices for Memory Management in VxWorks # To ensure both performance and reliability, follow these guidelines:\nPre-allocate memory where possible Avoid unpredictable allocations during runtime in time-critical code.\nUse memory partitions for critical subsystems This helps prevent fragmentation and ensures reserved memory for essential functions.\nMonitor memory usage regularly Use memShow() and Workbench tools to detect leaks before deployment.\nAlign with MMU protection strategies Catch invalid accesses early in development.\nOptimize stack sizes per task Balance safety vs. memory efficiency.\nAvoid memory leaks in RTPs Unlike kernel tasks, leaks in RTPs can accumulate over time and degrade system stability.\nTest under stress conditions Simulate high load and long uptime to ensure stable memory behavior.\nConclusion # Memory management in VxWorks is more than just malloc and free—it’s about predictability, efficiency, and safety in real-time embedded systems. By understanding how VxWorks organizes memory, provides partitioned pools, supports MMU-based protection, and introduces RTP-based isolation, developers can build reliable applications that run smoothly for years.\nFor embedded developers, mastering VxWorks memory management is not optional—it’s essential.\n✅ Key Takeaway: Efficient use of partitions, stack management, and MMU protection are the keys to stable, long-lived VxWorks applications.\n","date":"2025-09-01","externalUrl":null,"permalink":"/bsp/memory-management-in-vxworks-explained/","section":"Bsps","summary":"\u003cp\u003eEfficient memory management is at the heart of every \u003cstrong\u003ereal-time operating system (RTOS)\u003c/strong\u003e, and VxWorks is no exception. As embedded applications grow in complexity—supporting networking, graphics, safety, and security—developers need to understand how VxWorks handles memory to ensure performance and reliability.\u003c/p\u003e","title":"Memory Management in VxWorks Explained","type":"bsp"},{"content":"","date":"2025-09-01","externalUrl":null,"permalink":"/tags/mmu/","section":"Tags","summary":"","title":"MMU","type":"tags"},{"content":"In real-time embedded systems, networking requirements are rarely standard. Industries like aerospace, defense, telecommunications, industrial control, and autonomous vehicles often demand custom network stacks optimized for determinism, low latency, and reliability.\nThis is where VxWorks, the industry-leading real-time operating system (RTOS) from Wind River, becomes a powerful platform. Its modular networking architecture and VxBus driver framework enable developers to build, extend, or replace the default VxWorks network stack with a tailored solution.\nIn this article, we’ll dive into the why, what, and how of building a custom network stack on VxWorks—with best practices, examples, and performance tips.\nWhy Build a Custom Network Stack on VxWorks? # Although VxWorks ships with a full-featured TCP/IP stack (IPv4, IPv6, TCP, UDP, SCTP, IPsec), there are scenarios where a custom stack is required:\nPerformance Optimization – Reduce packet latency in avionics or real-time automation systems. Lightweight Implementations – Create smaller stacks for IoT sensors or low-power embedded devices. Proprietary Protocols – Add domain-specific or military protocols not available in the default stack. Enhanced Security – Integrate encryption, deep packet inspection, or hardened stack features. Hardware Integration – Support FPGA-based or custom NIC hardware where vendor drivers aren’t available. 👉 Simply put: a custom network stack allows you to align networking performance and functionality with system-level requirements.\nVxWorks Networking Architecture # Understanding the networking architecture is key before customizing:\nSocket Layer (Applications \u0026amp; Middleware)\nApplications communicate using BSD-compatible sockets. Middleware such as HTTP, SNMP, and DDS sit here.\nTCP/IP Protocol Stack (IPNet)\nImplements IP, TCP, UDP, SCTP, IPv6, routing, and security extensions. This layer is modular and extensible.\nNetwork Device Drivers (END / VxBus)\nThe END (Enhanced Network Driver) model and VxBus framework abstract hardware-specific details.\nHardware Layer\nThe actual NIC (Ethernet, CAN, custom FPGA, or SoC-based MAC).\nA custom stack usually modifies one or more of these layers. For example:\nA proprietary protocol may extend the TCP/IP stack. A custom driver may replace the NIC abstraction. Step-by-Step: Building a Custom Network Stack on VxWorks # 1. Define Networking Requirements # Start with clear system goals:\nTarget latency (e.g., \u0026lt;100µs per packet) Supported protocols (TCP, UDP, or proprietary) Expected throughput (e.g., 1 Gbps sustained) Security and encryption requirements Resource budgets (memory footprint, CPU load) This step determines whether to modify the existing VxWorks IP stack or replace it with a minimal/custom version.\n2. Set Up the Development Environment # You’ll need:\nVxWorks 7 SDK with networking libraries Wind River Workbench IDE (or command-line build system) BSP (Board Support Package) for your target hardware Access to System Viewer, kernel shell, and debug tools 3. Implement a Custom Network Driver # Most custom stacks begin at the driver level. Using VxBus, you can attach your NIC (or FPGA-based MAC) to the system:\nSTATUS myNicDrvAttach ( struct netif *pIf /* Network interface pointer */ ) { /* Initialize custom NIC hardware */ nicHwInit(); /* Register transmit (TX) and receive (RX) handlers */ pIf-\u0026gt;if_output = myNicSend; pIf-\u0026gt;if_input = myNicReceive; return OK; } Transmit function: Converts socket buffers to hardware descriptors. Receive function: Maps incoming packets into VxWorks buffer chains. Register the driver with muxDevLoad() so it’s recognized by the OS. 4. Extend or Replace the Protocol Stack # If you need a new protocol:\nRegister a new protocol handler inside IPNet. Hook into the packet dispatcher for parsing. Implement state machines, timers, and retransmission logic. Example (pseudo-code for a custom telemetry protocol):\nSTATUS myProtoInput (M_BLK_ID mBlk) { /* Parse custom header */ MY_HDR *hdr = (MY_HDR *)mBlk-\u0026gt;m_data; if (hdr-\u0026gt;type == MY_TELEMETRY) processTelemetry(mBlk); netMblkClChainFree(mBlk); /* Free buffer */ return OK; } This allows your protocol to coexist with TCP/UDP while offering real-time packet handling.\n5. Optimize for Real-Time Performance # Performance tuning is critical in VxWorks:\nUse zero-copy buffer techniques (mBlk and clBlk pools). Apply CPU core affinity for network tasks. Configure priority scheduling to favor networking ISR/DPC. Adjust socket buffer sizes for throughput vs. latency. Enable jumbo frames if hardware supports them. 6. Testing and Debugging # Validation ensures determinism and stability:\nifShow, netstat, and muxShow for runtime inspection. Wireshark for protocol verification. System Viewer for profiling ISR latency. Stress-test with tools like iperf or custom traffic generators. Best Practices for Custom Network Stacks # Modularity First – Keep drivers, protocols, and applications loosely coupled. Leverage VxWorks APIs – Reuse buffer management, timers, and task scheduling. Document Everything – Protocol definitions, driver callbacks, and ISR mappings. Continuous Integration Testing – Automate regression tests with real network loads. Security from Day 1 – Don’t treat encryption and hardening as afterthoughts. Real-World Examples # Custom stacks on VxWorks are already used in:\nAvionics: Deterministic data bus protocols (e.g., ARINC-664). Defense: Encrypted battlefield communications with proprietary ciphers. Industrial IoT: Lightweight stacks optimized for microcontrollers. Telecom: High-throughput packet forwarding engines on FPGA accelerators. Conclusion # Building a custom network stack on VxWorks unlocks the ability to tailor real-time networking to mission-critical requirements. Whether you’re optimizing for latency, adding proprietary protocols, or integrating with specialized hardware, VxWorks provides the flexible architecture and toolchain to make it possible.\nBy following the step-by-step process—requirements gathering, driver development, protocol integration, performance tuning, and rigorous testing—you can deliver a high-performance, reliable, and secure networking solution for embedded systems.\n","date":"2025-09-01","externalUrl":null,"permalink":"/bsp/building-a-custom-network-stack-on-vxworks-a-developers-guide/","section":"Bsps","summary":"\u003cp\u003eIn \u003cstrong\u003ereal-time embedded systems\u003c/strong\u003e, networking requirements are rarely standard. Industries like \u003cstrong\u003eaerospace, defense, telecommunications, industrial control, and autonomous vehicles\u003c/strong\u003e often demand \u003cstrong\u003ecustom network stacks\u003c/strong\u003e optimized for \u003cstrong\u003edeterminism, low latency, and reliability\u003c/strong\u003e.\u003c/p\u003e","title":"Building a Custom Network Stack on VxWorks: A Developer’s Guide","type":"bsp"},{"content":"","date":"2025-09-01","externalUrl":null,"permalink":"/tags/custom-drivers/","section":"Tags","summary":"","title":"Custom Drivers","type":"tags"},{"content":"","date":"2025-09-01","externalUrl":null,"permalink":"/tags/network-stack/","section":"Tags","summary":"","title":"Network Stack","type":"tags"},{"content":"","date":"2025-09-01","externalUrl":null,"permalink":"/tags/concurrency-errors/","section":"Tags","summary":"","title":"Concurrency Errors","type":"tags"},{"content":"","date":"2025-09-01","externalUrl":null,"permalink":"/tags/concurrent-programming/","section":"Tags","summary":"","title":"Concurrent Programming","type":"tags"},{"content":"As real-time embedded systems grow more complex, concurrent programming with multithreads and interrupts has become a cornerstone of modern design. However, testing such concurrent systems in VxWorks remains a challenge due to the overlapping execution of threads and interrupts, which introduces uncertainty and hidden concurrency errors.\nThis blog explores the dynamic testing tool for VxWorks concurrent programs proposed by researchers, highlighting its framework, algorithms, and experimental validation.\nWhy Concurrency Testing Matters in VxWorks # Real-time embedded systems require high reliability. Concurrency introduces uncertainty due to random interleavings of threads and interrupts. Common concurrency errors include: Data races Deadlocks Atomicity violations Traditional testing methods (static analysis or simulation) often fall short. A dynamic testing tool that works directly with running programs provides a more practical solution.\nFramework of the Dynamic Testing Tool # The tool is built around Labeled Transition Systems (LTS) as the formal model for concurrent programs. The framework consists of four main modules:\nProgram Analyzer\nExtracts shared objects and execution states. Converts complex statements into simple forms (if, while, goto, assignments). Builds the state space model for concurrency. Program Instrumentor\nInserts monitoring hooks into source code. Handles shared objects, thread functions, and interrupt service routines (ISRs). Tracks access to shared resources and interrupt events. Interrupt Generator\nSimulates realistic interrupt signals. Uses high-speed serial interfaces (HSSI) for accurate timing. Allows systematic exploration of interrupt-triggered concurrency errors. Execution Controller\nManages execution flow. Implements Dynamic Partial-Order Reduction (DPOR) to reduce redundant state exploration. Detects concurrency errors in real time. Key Algorithms # 1. Dynamic Partial-Order Reduction (DPOR) # Reduces the state explosion problem in concurrency testing. Eliminates redundant interleavings while ensuring coverage. Extended to handle multi-thread + multi-interrupt scenarios in VxWorks. 2. Concurrency Error Detection # The tool checks for:\nDeadlocks – by analyzing blocked states. Atomicity violations – by detecting inconsistent read/write sequences. Data races – when higher-priority interrupts preempt lower-priority tasks improperly. Testing Workflow # Analyze source program → generate LTS model. Instrument code → insert hooks for threads, interrupts, and shared objects. Compile with instrumentation libraries → produce controllable executables. Deploy to target system (ARM/PPC with VxWorks). Run with Execution Controller + Interrupt Generator → dynamically explore all concurrency paths. Report detected concurrency errors for debugging. Experimental Platform \u0026amp; Results # Hardware Platforms: ARM (Exynos 4412, VxWorks 5.5) PPC (MPC8247, VxWorks 5.5) Controller: Intel i7 with Windows Interrupt Generator: S3C6410 with Linux Results # DPOR-based tool significantly reduced execution time. Example: Without DPOR: 1193k transitions, 472s With DPOR: 236k transitions, 89s Compared with VeriSoft and thread-based methods, the tool achieved higher accuracy and better efficiency, especially in multi-interrupt cases. Why This Matters for Developers # For VxWorks system developers, this dynamic testing tool provides:\nAutomated concurrency error detection in real applications. Support for multithread + multi-interrupt programs, reflecting real-world embedded systems. Efficient state-space reduction, making large systems testable. This approach helps ensure safety, reliability, and correctness in mission-critical embedded applications such as aerospace, defense, and industrial control.\nConclusion # The dynamic testing tool for VxWorks concurrent programs offers a powerful solution to detect data races, deadlocks, and atomicity violations in embedded real-time systems. By combining LTS modeling, instrumentation, and DPOR algorithms, it achieves high accuracy and efficiency.\nFor developers working on complex embedded systems, adopting such a tool can drastically improve system robustness and reduce the risk of concurrency-induced failures.\n","date":"2025-09-01","externalUrl":null,"permalink":"/app/design-of-dynamic-testing-tool-for-vxworks-concurrent-programs/","section":"Apps","summary":"\u003cp\u003eAs \u003cstrong\u003ereal-time embedded systems\u003c/strong\u003e grow more complex, \u003cstrong\u003econcurrent programming\u003c/strong\u003e with multithreads and interrupts has become a cornerstone of modern design. However, testing such concurrent systems in \u003cstrong\u003eVxWorks\u003c/strong\u003e remains a challenge due to the overlapping execution of threads and interrupts, which introduces uncertainty and hidden concurrency errors.\u003c/p\u003e","title":"Design of Dynamic Testing Tool for VxWorks Concurrent Programs","type":"app"},{"content":"","date":"2025-09-01","externalUrl":null,"permalink":"/tags/dynamic-testing/","section":"Tags","summary":"","title":"Dynamic Testing","type":"tags"},{"content":"","date":"2025-08-31","externalUrl":null,"permalink":"/tags/rs485/","section":"Tags","summary":"","title":"RS485","type":"tags"},{"content":"","date":"2025-08-31","externalUrl":null,"permalink":"/tags/tews-technologies/","section":"Tags","summary":"","title":"TEWS Technologies","type":"tags"},{"content":"","date":"2025-08-31","externalUrl":null,"permalink":"/tags/tpmc861/","section":"Tags","summary":"","title":"TPMC861","type":"tags"},{"content":"The TPMC861-SW-42 VxWorks device driver is designed to support the TPMC861 4-Channel Isolated Serial Interface (RS422/RS485) module from TEWS Technologies. This driver integrates seamlessly with VxWorks real-time operating systems, providing robust and flexible serial communication support for embedded applications.\nIn this guide, we’ll explore:\nKey features of the TPMC861 driver Configuration and VxBus driver support Legacy I/O compatibility Basic I/O functions (open, read, write, ioctl) Advanced features like FIFO trigger levels and RTP support Introduction to TPMC861-SW-42 # The TPMC861-SW-42 driver enables developers to operate the TPMC861 module in compliance with the VxWorks I/O system specification. It provides:\nBasic I/O functions: open(), close(), read(), write(), and ioctl() Buffered I/O functions: fopen(), fclose(), fprintf(), fscanf() Advanced control via ioctl() for baud rate, parity, stop bits, and FIFO configurations The driver supports both legacy systems and the modern VxBus-enabled driver model. While legacy functions exist, VxBus support is mandatory for VxWorks SMP systems and recommended for all new developments.\nVxBus Driver Support # With VxBus integration, the TPMC861 devices are automatically detected and configured during system boot. Developers can customize driver behavior through configuration parameters.\nDevice Driver Configuration Parameters # Port Naming:\nDefault prefix: /tpmc861/ Channels numbered sequentially (e.g., /tpmc861/0, /tpmc861/1, etc.) Supports custom naming to match local serial ports (/tyCo/n) Software FIFO Configuration:\nDefault: 2048 Bytes for both RX and TX Adjustable depending on application requirements Default Port Settings:\n9600 Baud 8 Data bits, 1 Stop bit FIFO enabled (RX=56, TX=8 trigger levels) RTP Support # The driver includes RTP (Real-Time Process) support, allowing TPMC861 devices to be tunneled from RTP contexts when properly configured.\nLegacy Compatibility # For compatibility with pre-VxBus applications, initialization is done via tpmc861Init(), ensuring consistent behavior across both driver models.\nLegacy I/O System Functions # Although modern projects should use VxBus, legacy APIs are still provided for backward compatibility:\ntpmc861Drv() – Installs the driver into the I/O system tpmc861DevCreate() – Creates devices on specific serial channels tpmc861PciInit() – Initializes PCI devices (Intel x86 platforms) tpmc861Init() – Installs the driver and adds all devices automatically Basic I/O Functions # The TPMC861 driver provides all standard POSIX-style I/O functions:\n1. open() # Opens a device for communication.\nExample:\nfd = open(\u0026#34;/tpmc861/2\u0026#34;, 0, 0); 2. close() # Closes an open device.\n3. read() # Reads data from a device into a buffer.\n4. write() # Writes data from a buffer to a device.\n5. ioctl() # Provides extended device control, including:\nFIOBAUDRATE – Set baud rate FIO_EXAR16XXX_DATABITS – Configure data bits (5–8) FIO_EXAR16XXX_STOPBITS – Set stop bits (1, 1.5, 2) FIO_EXAR16XXX_PARITY – Configure parity (Even, Odd, Space, Mark) FIO_EXAR16XXX_FIFO – Configure FIFO levels FIO_EXAR16XXX_CHANNEL_INFO – Retrieve PCI and board info Advanced Configuration: FIFO Trigger Levels # The driver allows tuning of FIFO trigger levels to balance system performance:\nHigher RX trigger levels → fewer interrupts, higher risk of buffer overrun Lower RX trigger levels → more interrupts, but safer data handling TX trigger levels can reduce transmission gaps This flexibility ensures that the driver can be optimized for both high-throughput and low-latency applications.\nWhy TPMC861-SW-42 Matters # The TPMC861-SW-42 driver is ideal for embedded systems developers working with VxWorks who require:\nReliable and isolated RS422/RS485 serial communication Flexible configuration for custom I/O requirements Future-proof design with support for VxBus and RTP By combining compatibility, performance, and configurability, TEWS Technologies ensures the TPMC861 driver can meet the needs of both legacy systems and modern real-time embedded applications.\nConclusion # The TPMC861-SW-42 VxWorks device driver offers a comprehensive solution for developers integrating RS422/RS485 interfaces into embedded systems. With its support for VxBus, legacy functions, and advanced I/O controls, it provides the flexibility and reliability essential in demanding real-time environments.\nFor more details, visit TEWS Technologies.\n","date":"2025-08-31","externalUrl":null,"permalink":"/bsp/tpmc861-vxworks-device-driver-complete-guide/","section":"Bsps","summary":"\u003cp\u003eThe \u003cstrong\u003eTPMC861-SW-42 VxWorks device driver\u003c/strong\u003e is designed to support the \u003cstrong\u003eTPMC861 4-Channel Isolated Serial Interface (RS422/RS485)\u003c/strong\u003e module from \u003cstrong\u003eTEWS Technologies\u003c/strong\u003e. This driver integrates seamlessly with VxWorks real-time operating systems, providing robust and flexible serial communication support for embedded applications.\u003c/p\u003e","title":"TPMC861 VxWorks Device Driver: Complete Guide","type":"bsp"},{"content":"Interrupt latency is one of the most critical factors influencing the performance of real-time systems. It refers to the delay between the occurrence of an interrupt and the execution of the corresponding Interrupt Service Routine (ISR). High interrupt latency can lead to suboptimal system performance, especially in applications where time-sensitive tasks are involved, such as embedded systems, robotics, automotive systems, and industrial controls.\nIn this blog, we\u0026rsquo;ll explore several techniques and best practices for optimizing interrupt latency in VxWorks, an advanced real-time operating system (RTOS), to ensure maximum responsiveness for your applications.\nWhat is Interrupt Latency? # Interrupt latency is defined as the time interval between when an interrupt is generated (e.g., a hardware event like a timer overflow or sensor reading) and when the corresponding interrupt service routine (ISR) starts executing. Minimizing this latency is crucial for ensuring that your real-time system responds to critical events within a predictable and timely manner.\nInterrupt latency can be measured in microseconds (µs) or even nanoseconds (ns), depending on the system requirements. To understand how to minimize interrupt latency, we first need to understand the main factors that contribute to it.\nKey Factors Affecting Interrupt Latency # Interrupt Priority: VxWorks uses a priority-based interrupt handling mechanism. Interrupts are processed in the order of their priority levels. A higher-priority interrupt will preempt lower-priority interrupts, reducing latency for critical tasks. Interrupt Handling Overhead: When an interrupt occurs, the system must save the current processor context, process the interrupt, and restore the context after the ISR finishes. This overhead can contribute to latency. Task Scheduling and Preemption: If a higher-priority task is running when an interrupt occurs, it might delay interrupt servicing if the interrupt priority is not appropriately set. Processor and Cache Efficiency: Processor cache misses, especially when the ISR accesses non-cached data, can result in increased latency. Additionally, the choice of processor architecture can impact the speed of interrupt handling. Real-World Use Cases # Understanding how interrupt latency optimizations impact real-world applications can help guide their importance. Below are some real-world use cases where optimizing interrupt latency directly affects performance:\nAutomotive Systems: In safety-critical automotive systems like collision detection, airbag deployment, or adaptive cruise control, low interrupt latency is vital for responding quickly to sensor inputs and activating safety mechanisms. Industrial Robotics: In robotic arms or precision machinery, quick response to sensor inputs is crucial for performing precise and controlled movements. Minimizing interrupt latency ensures that the robot can react instantly to external conditions. Medical Devices: For devices like pacemakers or diagnostic equipment, timely processing of sensor data through optimized interrupts can be life-saving by ensuring real-time monitoring and control. Best Practices for Optimizing Interrupt Latency in VxWorks # 1. Use Priority-based Interrupt Handling # In VxWorks, interrupts are managed based on their priority. Higher-priority interrupts are processed before lower-priority ones. To optimize interrupt latency:\nAssign high priority to time-critical interrupts that require immediate attention. Avoid using too many interrupt levels to prevent excessive complexity and prioritization overhead. For instance, when setting up interrupt priorities, you can use VxWorks APIs to control interrupt priorities dynamically:\nintLock(); // Disable interrupts temporarily // Critical code here intUnlock(); // Re-enable interrupts By carefully setting interrupt priorities, you ensure that time-sensitive ISRs are executed as soon as they are triggered.\n2. Optimize ISR Code for Efficiency # The Interrupt Service Routine (ISR) is responsible for handling interrupts as quickly as possible. The longer the ISR runs, the longer the interrupt latency becomes. To optimize ISRs:\nKeep ISR execution time minimal: Avoid performing lengthy computations or blocking operations inside the ISR. Move heavy processing outside: Complex computations and tasks should be moved out of the ISR and deferred to a Deferred Interrupt Service Routine (DISR) or a task. This allows the ISR to return quickly and minimizes latency. Here’s a simple ISR that immediately defers complex work to a separate task:\nvoid isrHandler(int vector, void *arg) { // Quick interrupt handling // Defer complex work to a DISR or task taskSpawn(\u0026#34;myTask\u0026#34;, 100, 0, 2000, myTaskFunc, 0, 0, 0, 0, 0, 0, 0, 0, 0); } By reducing the ISR workload, you allow the system to respond quickly to the next interrupt.\n3. Utilize Deferred Interrupt Service Routines (DISRs) # In VxWorks, you can implement Deferred Interrupt Service Routines (DISRs) to offload time-consuming tasks from the ISR. DISRs allow you to schedule lower-priority tasks that are executed outside the ISR context, enabling the system to quickly return to normal operation.\nTo implement DISRs:\nThe ISR only performs quick, essential operations like acknowledging the interrupt. Complex or time-consuming processing is delegated to a DISR, which runs in the background without blocking the ISR. intConnect(INT_VEC, isrHandler, 0); // Connect the ISR to the interrupt vector By using DISRs, the system can acknowledge interrupts quickly and then perform more computationally intensive tasks in the background, significantly reducing interrupt latency.\n4. Tune Interrupt Coalescing for Optimal Performance # Some network cards and peripheral devices support interrupt coalescing, which groups multiple interrupts into a single interrupt. While this can reduce the overall number of interrupts, it can also increase latency if not configured properly.\nYou should:\nTune interrupt coalescing settings to balance throughput and latency. For time-sensitive applications, it may be beneficial to disable or reduce the coalescing window to ensure prompt interrupt handling. Review hardware and driver documentation to fine-tune interrupt coalescing based on the system\u0026rsquo;s requirements. 5. Optimize Processor Cache and Memory Access # Cache misses during interrupt handling can significantly increase latency, as accessing memory not in the cache may take several CPU cycles. To optimize:\nEnsure that the ISR code fits within the processor’s cache to minimize cache misses. Avoid accessing large blocks of memory that are not in the cache, as these accesses increase latency. For example, avoid performing large memory allocations or non-cached data accesses within the ISR.\n6. Configure the System for Low Interrupt Latency # VxWorks offers several configuration options that can help optimize interrupt latency. These include:\nInterrupt Stack Size: Ensure the interrupt stack is large enough to avoid stack overflows, which can cause delays in ISR execution.\nYou can configure stack size through the VxWorks configuration tools or by modifying config.h:\n#define INTERRUPT_STACK_SIZE 0x2000 // Define sufficient stack size for interrupts System Clock Rate: Fine-tune the system clock rate to achieve higher-resolution timekeeping, which can help improve interrupt handling precision.\nSet the clock rate using the sysClkRateSet() function:\nsysClkRateSet(1000); // Set system clock rate to 1ms 7. Minimize Task Preemption # Excessive preemption of tasks can delay the handling of interrupts, especially if a high-priority task holds the CPU. To minimize interrupt latency:\nOptimize task execution times to ensure that high-priority interrupts are not delayed by other tasks. Ensure tasks that don’t require immediate execution don’t consume too much CPU time, thus blocking interrupt servicing. You can adjust task priorities dynamically using VxWorks’ priority management functions to control preemption.\n8. Use Real-Time Performance Analysis Tools # To monitor and optimize interrupt latency, VxWorks provides performance analysis tools that allow you to track real-time system behavior. These tools help you identify potential bottlenecks and optimize your system accordingly:\nWindView: A system trace tool that visualizes interrupt latency and other real-time events in a graphical manner. System Viewer: A real-time diagnostic tool that provides a detailed view of system performance, helping you understand how interrupt latency impacts the overall system. If you\u0026rsquo;re using multi-core processors, consider additional analysis to see how interrupts are distributed across cores.\n9. Interrupt Latency in Multi-core Systems # Optimizing interrupt latency in multi-core systems presents unique challenges. To minimize latency:\nDistribute interrupts evenly across cores to avoid overloading any single core. Use core affinity to bind specific interrupts to specific cores, reducing unnecessary context switching and improving response time. Utilize hardware features like interrupt controllers designed for multi-core processors to achieve low-latency interrupt handling. Performance Trade-offs # When optimizing interrupt latency, there are often trade-offs between latency and throughput. For instance, optimizing for low latency may involve using more system resources, which could affect throughput or increase CPU utilization. Depending on your application’s requirements, it\u0026rsquo;s important to strike the right balance.\nTroubleshooting High Interrupt Latency # If you\u0026rsquo;re experiencing high interrupt latency despite optimizations, follow these steps:\nIdentify bottlenecks using tools like WindView to trace interrupt paths and identify slow points. Check interrupt priority inversion: Ensure that lower-priority interrupts are not being blocked by higher-priority tasks or other interrupts. Examine hardware limitations: Ensure your hardware can handle the interrupt rates expected by your application. Conclusion # Optimizing interrupt latency in VxWorks is crucial for ensuring that your system responds promptly to time-sensitive events. By carefully managing interrupt priorities, optimizing ISR code, leveraging Deferred Interrupt Service Routines (DISRs), and fine-tuning system configurations, you can significantly reduce interrupt latency and improve the performance of your real-time applications.\nAdditionally, monitoring tools like WindView and System Viewer, along with hardware-level optimizations, provide valuable insights into how interrupt latency impacts system performance. By implementing the strategies discussed here, you can fine-tune your VxWorks system to achieve optimal responsiveness and reliability.\nLegal Notices # Wind River and VxWorks are registered trademarks of Wind River Systems. Other names and brands may be claimed as the property of their respective owners.\n","date":"2025-08-31","externalUrl":null,"permalink":"/bsp/how-to-optimize-interrupt-latency-in-vxworks/","section":"Bsps","summary":"\u003cp\u003eInterrupt latency is one of the most critical factors influencing the performance of real-time systems. It refers to the delay between the occurrence of an interrupt and the execution of the corresponding Interrupt Service Routine (ISR). High interrupt latency can lead to suboptimal system performance, especially in applications where time-sensitive tasks are involved, such as embedded systems, robotics, automotive systems, and industrial controls.\u003c/p\u003e","title":"How to Optimize Interrupt Latency in VxWorks","type":"bsp"},{"content":"","date":"2025-08-31","externalUrl":null,"permalink":"/tags/interrupt-latency/","section":"Tags","summary":"","title":"Interrupt Latency","type":"tags"},{"content":"","date":"2025-08-31","externalUrl":null,"permalink":"/tags/optimization/","section":"Tags","summary":"","title":"Optimization","type":"tags"},{"content":" 10 Real-World Applications of VxWorks Across Industries\nWhen discussing real-time operating systems (RTOS) used in mission-critical environments, VxWorks stands out as one of the most trusted platforms. Developed by Wind River, VxWorks has been widely adopted in industries where deterministic performance, reliability, and safety certification are essential.\nFrom spacecraft exploring Mars to automated factories and advanced vehicles, VxWorks powers a wide range of embedded systems that require strict timing guarantees and long-term stability.\nThis article explores ten real-world applications of VxWorks across major industries, highlighting how the RTOS supports some of the most demanding embedded systems in operation today.\n🚀 Aerospace and Defense # Aerospace and defense systems require absolute reliability and deterministic timing. VxWorks has been widely used in avionics and mission-critical defense platforms for decades.\nTypical aerospace applications include:\nFlight control systems Avionics computers Radar processing systems Mission management platforms NASA\u0026rsquo;s Mars rovers, including Spirit, Opportunity, Curiosity, and Perseverance, all run VxWorks as their onboard operating system.\nThe RTOS is particularly well suited for aerospace systems because it supports DO-178C safety certification, deterministic task scheduling, and proven long-term stability in harsh environments.\n🛰️ Space Exploration # Space systems operate in extreme environments where hardware failures cannot easily be repaired. For this reason, many spacecraft rely on highly reliable operating systems such as VxWorks.\nExamples of space systems using VxWorks include:\nScientific instruments aboard spacecraft Satellite onboard computers Deep-space exploration vehicles Space telescopes and observation platforms The Mars Ingenuity Helicopter uses VxWorks to manage flight operations and communication with the Perseverance rover.\nIn space applications, the RTOS must support fault tolerance, watchdog monitoring, and reliable task scheduling over extremely long mission durations.\n🚗 Automotive Systems # Modern vehicles increasingly rely on complex embedded systems that must respond in real time.\nVxWorks is used in automotive systems such as:\nAdvanced Driver Assistance Systems (ADAS) Autonomous vehicle control platforms Vehicle-to-Everything (V2X) communication High-performance vehicle control units The RTOS supports automotive safety requirements such as ISO 26262, enabling deterministic control of safety-critical vehicle systems.\nAs vehicles move toward higher levels of automation, real-time operating systems like VxWorks play a critical role in ensuring predictable behavior.\n🏭 Industrial Automation # Industrial automation systems require precise timing to control machinery, robots, and production processes.\nVxWorks is widely used in factory automation and industrial control systems, including:\nRobotics controllers Motion control platforms Programmable logic controllers (PLCs) Process monitoring systems These systems often rely on deterministic industrial networks such as:\nEtherCAT CANopen Modbus VxWorks supports these communication protocols while maintaining predictable real-time behavior in demanding manufacturing environments.\n🏥 Medical Devices # Medical devices must operate safely and reliably, often under strict regulatory requirements.\nVxWorks is used in various medical systems, including:\nPatient monitoring equipment Infusion pumps Diagnostic imaging systems Surgical robotics platforms Medical device software must comply with IEC 62304, which defines lifecycle requirements for medical device software. VxWorks helps developers meet these requirements while providing deterministic performance and strong system reliability.\n📡 Networking and Telecommunications # Modern telecommunications infrastructure requires extremely high throughput and reliable packet processing.\nVxWorks powers networking platforms such as:\n5G base stations Network routers and switches Edge computing gateways Network security appliances Its support for multi-core processors, deterministic networking, and virtualization makes it suitable for telecom systems that must handle large volumes of data with minimal latency.\n🚆 Rail and Transportation # Rail systems depend on real-time communication and safety monitoring to prevent accidents and maintain reliable operations.\nVxWorks is used in transportation systems including:\nTrain control systems Rail signaling infrastructure Metro automation platforms Positive Train Control (PTC) systems Railway safety systems often require SIL 4 certification, one of the highest safety integrity levels used in transportation control systems.\nThe deterministic scheduling of VxWorks helps ensure safe coordination between trains and control systems.\n🤖 Robotics # Robotics systems require extremely precise timing for motion control, sensing, and decision making.\nVxWorks supports many robotics platforms, such as:\nIndustrial robotic arms Autonomous warehouse robots Unmanned aerial vehicles (UAVs) Inspection and service robots In robotics applications, the RTOS coordinates sensor input, control algorithms, and actuator outputs in real time.\nLow-latency task switching and predictable scheduling make VxWorks a strong platform for robotics development.\n⚡ Energy and Power Systems # Energy infrastructure depends on reliable monitoring and control systems to maintain stable power delivery.\nVxWorks is used in applications such as:\nSmart grid control systems Power plant monitoring systems Wind turbine controllers Nuclear facility safety systems In these environments, the operating system must support long uptime, deterministic control, and strong cybersecurity capabilities.\nThese characteristics make VxWorks suitable for critical infrastructure deployments.\n📺 Consumer and Embedded Electronics # Although VxWorks is best known for mission-critical systems, it has also appeared in various consumer electronics products.\nExamples include:\nSet-top boxes Network storage devices Broadband gateways Early gaming hardware and networking equipment Its small footprint and modular architecture allow VxWorks to run efficiently on resource-constrained embedded hardware.\n🌍 Why VxWorks Remains Widely Used # Across these industries, several factors explain the continued adoption of VxWorks:\nDeterministic real-time scheduling Long-term reliability in embedded deployments Extensive safety certification support Scalability from small embedded systems to multi-core platforms Broad ecosystem of development tools and BSP support These characteristics make VxWorks suitable for applications where system failure is not an option.\n🏁 Conclusion # VxWorks has played a central role in embedded computing for decades. From Mars exploration missions to smart factories and autonomous vehicles, it continues to power systems that require strict real-time performance and high reliability.\nAs industries continue adopting advanced technologies such as autonomous transportation, intelligent robotics, and edge computing, real-time operating systems like VxWorks will remain a foundational component of modern embedded systems.\n","date":"2025-08-29","externalUrl":null,"permalink":"/industries/top-10-real-world-applications-of-vxworks-in-industry/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003e10 Real-World Applications of VxWorks Across Industries\u003c/p\u003e\u003c/blockquote\u003e\n\u003cscript async src=\"https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1543398821442998\"\n     crossorigin=\"anonymous\"\u003e\u003c/script\u003e\n\u003c!-- vxworks6_ads_1 --\u003e\n\u003cp\u003e\u003cins class=\"adsbygoogle\"\nstyle=\"display:block\"\ndata-ad-client=\"ca-pub-1543398821442998\"\ndata-ad-slot=\"7693617958\"\ndata-ad-format=\"auto\"\ndata-full-width-responsive=\"true\"\u003e\u003c/ins\u003e\u003c/p\u003e\n\u003cscript\u003e\n     (adsbygoogle = window.adsbygoogle || []).push({});\n\u003c/script\u003e\n\u003cp\u003eWhen discussing \u003cstrong\u003ereal-time operating systems (RTOS)\u003c/strong\u003e used in mission-critical environments, \u003cstrong\u003eVxWorks\u003c/strong\u003e stands out as one of the most trusted platforms. Developed by Wind River, VxWorks has been widely adopted in industries where \u003cstrong\u003edeterministic performance, reliability, and safety certification\u003c/strong\u003e are essential.\u003c/p\u003e","title":"10 Real-World Applications of VxWorks Across Industries","type":"industries"},{"content":"","date":"2025-08-29","externalUrl":null,"permalink":"/tags/industry-applications/","section":"Tags","summary":"","title":"Industry Applications","type":"tags"},{"content":" Running VxWorks on real hardware isn’t always convenient — development boards can be costly, and setting up hardware debugging takes time. Fortunately, with QEMU (Quick EMUlator), you can emulate a supported platform and start experimenting with VxWorks 7 on your laptop.\nIn this guide, we’ll walk step-by-step through setting up QEMU for VxWorks development, so you can get hands-on quickly without hardware.\nWhy Use QEMU for VxWorks? # Cost-effective: No physical hardware required. Faster iteration: Debug, reboot, and test configurations quickly. Learning-friendly: Great for training, experimenting with drivers, or exploring BSPs. Portable: Run the same environment across Windows, Linux, or macOS. Prerequisites # Before starting, make sure you have:\nHost System: Linux (Ubuntu recommended) or Windows with WSL2. QEMU installed (v7.0 or newer preferred). VxWorks 7 Development Kit (SDK) from Wind River. Basic knowledge of RTOS concepts and command-line usage. Step 1: Install QEMU # On Ubuntu/Debian:\nsudo apt update sudo apt install qemu-system-arm qemu-system-x86 qemu-utils On Fedora:\nsudo dnf install qemu qemu-system-arm qemu-system-x86 On macOS (with Homebrew):\nbrew install qemu Verify installation:\nqemu-system-arm --version Step 2: Prepare VxWorks Bootable Image # From your VxWorks 7 SDK, you’ll need to build or locate the appropriate boot image for QEMU.\nTypical file formats include:\nvxWorks (kernel image) vxWorks.st (bootable image with symbol table) bootrom (for some targets) For ARM emulation, copy the vxWorks image into your working directory.\nStep 3: Launch VxWorks in QEMU # Run QEMU with the right machine type. For example, to emulate an ARM VersatilePB board:\nqemu-system-arm -M versatilepb -kernel vxWorks -nographic -append \u0026#34;console=ttyAMA0\u0026#34; Explanation:\n-M versatilepb → Emulates the ARM VersatilePB board. -kernel vxWorks → Loads the VxWorks kernel image. -nographic → Runs in console mode (no GUI). -append \u0026quot;console=ttyAMA0\u0026quot; → Redirects output to serial console. If everything works, you should see the VxWorks boot console in your terminal. 🎉\nStep 4: Interact with the VxWorks Shell # Once booted, you’ll drop into the VxWorks kernel shell (C-interpreter). Try a few commands:\n-\u0026gt; i Shows active tasks.\n-\u0026gt; sp(taskDelay, 100) Spawns a new task that delays.\n-\u0026gt; version Displays the VxWorks version running inside QEMU.\nStep 5: Enable Networking (Optional) # QEMU supports virtual networking so you can test TCP/IP inside VxWorks. Example:\nqemu-system-arm -M versatilepb -kernel vxWorks -net nic -net user -nographic Inside VxWorks, configure the interface:\n-\u0026gt; ifconfig \u0026#34;fei0\u0026#34;, \u0026#34;inet 192.168.0.10\u0026#34;, \u0026#34;up\u0026#34; -\u0026gt; ping \u0026#34;192.168.0.1\u0026#34; This allows testing sockets, servers, and client applications — all within emulation.\nCommon Issues \u0026amp; Fixes # QEMU freezes on boot → Ensure you’re using a board type (-M) supported by your VxWorks BSP. No console output → Add -serial mon:stdio to force console redirection. Image not loading → Verify the image matches the emulated board (ARM vs x86). Next Steps # Now that you have VxWorks running in QEMU, you can:\nExplore task scheduling and memory management. Experiment with custom BSPs. Test drivers and networking without hardware. Prepare for deployment to physical boards with minimal changes. Final Thoughts # Running VxWorks 7 on QEMU is a powerful way to learn, prototype, and test without depending on hardware. Whether you’re a beginner or an experienced embedded engineer, QEMU provides a flexible sandbox to explore the world of real-time operating systems.\n👉 In future tutorials, we’ll dive deeper into BSP customization, device drivers, and performance testing on QEMU.\n","date":"2025-08-16","externalUrl":null,"permalink":"/bsp/getting-started-with-vxworks-7-on-qemu-step-by-step-guide/","section":"Bsps","summary":"\u003c!--# Getting Started with VxWorks 7 on QEMU: Step-by-Step Guide--\u003e\n\u003cp\u003eRunning VxWorks on real hardware isn’t always convenient — development boards can be costly, and setting up hardware debugging takes time. Fortunately, with \u003cstrong\u003eQEMU\u003c/strong\u003e (Quick EMUlator), you can emulate a supported platform and start experimenting with \u003cstrong\u003eVxWorks 7\u003c/strong\u003e on your laptop.\u003c/p\u003e","title":"Getting Started With VxWorks 7 on QEMU:Step-by-Step Guide","type":"bsp"},{"content":" Why VxWorks is Chosen for Real-Time Applications\nIn the world of embedded systems and mission-critical devices, real-time operating systems (RTOS) form the backbone of reliable computing. Among them, VxWorks, developed by Wind River Systems, has stood for decades as one of the most trusted and commercially successful solutions.\nBut why is VxWorks so widely selected? In this post, we’ll explore its history, technical strengths, case studies, comparisons, developer experience, and future outlook to understand what makes it unique.\nA Brief History of VxWorks # Figure: Evolution of VxWorks from the 1980s to today\n1980s: VxWorks introduced as a deterministic RTOS. 1990s–2000s: Expanded into aerospace, defense, and telecom. Today: Powers spacecraft, industrial automation, automotive safety, and medical devices. One of its most famous deployments is in NASA’s Mars rovers, where reliability is literally mission-critical.\nWhy VxWorks? # Figure: Difference between hard real-time and soft real-time systems\nUnlike Linux or Windows, VxWorks provides hard real-time guarantees: every critical task executes within a predictable deadline.\nThis determinism is vital in flight control, surgical robots, and industrial automation where missed deadlines could cause failures.\nKey Technical Features # Figure: VxWorks kernel and scheduling model\nPriority-based preemptive scheduler. Low interrupt latency. Memory protection \u0026amp; process isolation. Full TCP/IP stack and IPC mechanisms. Scales from MCUs to high-performance SoCs. Advantages and Disadvantages # Figure: Major strengths and weaknesses of VxWorks\nAdvantages:\nDeterministic performance. Safety certifications (DO-178C, ISO 26262, IEC 61508). Mature development tools. Proven reliability. Security features. Disadvantages:\nHigh licensing cost. Vendor lock-in. Steeper learning curve. Less suited for general-purpose workloads. Real-World Case Studies # Figure: Typical industries where VxWorks is deployed\n🚀 NASA Mars Rovers — Spirit, Opportunity, Curiosity. ✈️ Avionics — flight control systems in Boeing/Airbus. 🏭 Industrial robotics — CNC machines and robotic arms. 🏥 Medical devices — imaging systems, monitoring equipment. How VxWorks Compares to Alternatives # Figure: Comparison between VxWorks and other RTOS options\nFeature / OS VxWorks FreeRTOS/Zephyr QNX Neutrino RTEMS Real-Time Linux License Commercial (expensive) Open-source (free) Commercial Open-source Open-source Determinism Hard real-time Hard/soft RT Hard real-time Hard real-time Soft real-time Certifications DO-178C, ISO 26262, IEC 61508 Limited Strong (auto/medical) Limited Few Maturity 30+ years, proven IoT popularity Strong in automotive Aerospace niche Widespread use Tools Wind River Workbench Community toolchains QNX Momentics GCC-based Standard Linux tools Development Workflow with VxWorks # Figure: A typical development workflow using Wind River Workbench\nCross-compilation for target hardware. Early simulation without physical devices. Advanced debugging and profiling tools. CI/CD pipeline integration. The Future of VxWorks # Figure: Future directions of VxWorks in AI, IoT, and space exploration\nRISC-V support alongside ARM, x86, PowerPC. Containerization and virtualization for mixed-criticality systems. Edge AI/ML for deterministic inference workloads. Deep space missions — continuing to power NASA spacecraft. Editorial Take # In my view, VxWorks is best for safety-critical industries where certification and determinism are non-negotiable.\nFor cost-sensitive projects, FreeRTOS or Zephyr are more practical. For soft real-time workloads with flexibility, Real-Time Linux fits better. For mixed-criticality systems, combining VxWorks with Linux on the same hardware is an emerging trend. Conclusion # VxWorks remains a cornerstone RTOS for real-time, safety-critical, and mission-critical systems. Its deterministic performance, certification pedigree, mature toolchain, and decades of trust make it hard to replace.\nWhile its cost and vendor lock-in are drawbacks, its proven track record across spacecraft, aircraft, medical, and industrial systems shows that for many industries, the premium for reliability is well worth it.\n","date":"2025-08-16","externalUrl":null,"permalink":"/industries/vxworks-in-real-time-applications-advantages-drawbacks-and-use-cases/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eWhy VxWorks is Chosen for Real-Time Applications\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eIn the world of embedded systems and mission-critical devices, \u003cstrong\u003ereal-time operating systems (RTOS)\u003c/strong\u003e form the backbone of reliable computing. Among them, \u003cstrong\u003eVxWorks\u003c/strong\u003e, developed by \u003cstrong\u003eWind River Systems\u003c/strong\u003e, has stood for decades as one of the most trusted and commercially successful solutions.\u003c/p\u003e","title":"VxWorks in Real-Time Applications: Advantages, Drawbacks, and Use Cases","type":"industries"},{"content":"","date":"2025-08-16","externalUrl":null,"permalink":"/tags/distributed-infrastructure/","section":"Tags","summary":"","title":"Distributed Infrastructure","type":"tags"},{"content":"As cloud strategies mature, enterprise IT leaders are rethinking how workloads should run across private cloud, hybrid cloud, and edge environments.\nRising public cloud costs, inflexible licensing models, operational complexity, and the risks of vendor lock-in are driving the need for a smarter alternative.\nWind River® Cloud Platform delivers exactly that.\nBuilt on proven open-source technologies—including StarlingX, OpenStack, and Kubernetes—it’s an enterprise-grade, fully supported platform already powering some of the world’s largest mission-critical cloud deployments.\nWhy Wind River Cloud Platform # Lower Total Cost of Ownership # Straightforward licensing — Simple node-based pricing with no virtual machine or CPU-core counting. Smaller footprint — Reduced hardware requirements cut capital expenditures (CapEx). High efficiency — Only 1–2 CPU cores per node for platform operations, enabling higher workload density and lower power usage. Unified Workload Management # Manage virtual machines and containers side-by-side on a single platform. High performance and scalability for traditional, cloud-native, and hybrid workloads. Designed for private cloud, hybrid cloud, and edge computing. Simplified Operations \u0026amp; Lifecycle Automation # End-to-end automation from Day 0 to Day 2 operations. Self-healing capabilities for both networking and infrastructure. Centralized control for remote deployment and management. Reduced manual work means fewer errors and lower operational expenses (OpEx). Freedom from Vendor Lock-in # 100% open-source foundation, backed by full enterprise support from Wind River. No dependence on proprietary architectures. Full control to design, deploy, and scale infrastructure your way. Mission-Critical Reliability \u0026amp; Scale # Up to 99.9999% availability (less than 32 seconds downtime per year). Proven stability in massive deployments—over 50,000 nodes with zero failures. Carrier-grade networking features including SR-IOV, DPDK, and TSN for real-time performance. Built-in Security \u0026amp; Compliance # End-to-end protections: secure boot, RBAC, encrypted communications, and vulnerability management. Meets rigorous industry standards, including NEBS and PCI DSS. Deploy Anywhere. Scale Without Limits. # Whether it’s a data center, edge location, or remote site, Wind River Cloud Platform supports:\nAny workload Any deployment location Any scale Proven Results # Wind River customers have:\nReduced operational costs by over 50% through automation and integrated lifecycle management. Lowered energy and hardware costs thanks to minimal platform overhead. Achieved zero downtime from the edge to the core data center. Built a future-ready foundation for AI/ML, automation, and evolving workloads. It’s time to rethink what’s possible.\nWind River is enabling enterprises, telecom operators, and global innovators to redefine private cloud and distributed infrastructure—delivering unmatched flexibility, performance, and efficiency.\n","date":"2025-08-16","externalUrl":null,"permalink":"/news/wind-river-is-redefining-private-cloud-and-distributed-infrastructure/","section":"News","summary":"\u003cp\u003eAs cloud strategies mature, enterprise IT leaders are rethinking how workloads should run across private cloud, hybrid cloud, and edge environments.\u003cbr\u003e\nRising public cloud costs, inflexible licensing models, operational complexity, and the risks of vendor lock-in are driving the need for a smarter alternative.\u003c/p\u003e","title":"Wind River is Redefining Private Cloud and Distributed Infrastructure","type":"news"},{"content":"","date":"2025-08-12","externalUrl":null,"permalink":"/tags/analyzing-network-performance/","section":"Tags","summary":"","title":"Analyzing Network Performance","type":"tags"},{"content":"","date":"2025-08-12","externalUrl":null,"permalink":"/tags/modeling/","section":"Tags","summary":"","title":"Modeling","type":"tags"},{"content":"In real-time embedded systems like VxWorks, reliable and predictable Ethernet communication is critical. To improve both reliability and real-time performance, we can model the network behavior mathematically and apply queueing theory to determine the optimal buffer size that minimizes both packet loss and latency.\nThis blog explores the modeling approach, optimization process, and engineering recommendations for VxWorks network performance tuning.\nWhy Network Modeling Matters in VxWorks # When Ethernet frames are sent in a VxWorks system, delays can arise from:\nTransmission delay – due to the physical medium. Queueing delay – when frames wait in the send buffer before transmission. If a frame is not transmitted within the current cycle, it must wait until the next one, leading to significant delays. On the other hand, too short a queue can underutilize the link. The goal: find the sweet spot in buffer size.\nBuilding the Ethernet Queue Model # The frame sending process in VxWorks can be modeled with Poisson arrivals (independent frame arrivals, no limit on count). Let:\nλ – average frame arrival rate (frames/time unit) μ – average transmission rate (frames/time unit, μ \u0026gt; λ) ρ = λ / μ – traffic intensity L – buffer length L₀ – optimal buffer length If L is too large → frames pile up, some get dropped due to delay.\nIf L is too small → link goes idle, wasting capacity.\nThe Loss-Cost Optimization Approach # We assign loss costs:\nc₁ – cost of dropping a frame when L \u0026gt; L₀ c₂ – cost of idle capacity when L \u0026lt; L₀ (typically c₁ ≥ c₂) By deriving steady-state probabilities from the birth-death process and geometric distribution, we can calculate:\nN_d – average dropped frames when busy\nN_p – average idle frames when underutilized\nF(L) – total communication loss cost:\nF(L) = c₁ * N_d + c₂ * N_p The optimal queue length L₀ is the integer that minimizes F(L).\nVisualization: Optimal Queue Length # Below is a conceptual plot showing the loss cost curve versus queue length, with the optimal point L₀ marked.\nVisualization: Cost Components # To better understand the trade-offs, the following diagram separates the dropped-frame cost, idle-capacity cost, and the total loss cost. The intersection of these trade-offs determines the optimal queue length.\nKey Engineering Recommendations # From simulation and analysis, we found that tuning the buffer size significantly reduces queueing delays and improves performance. Beyond the math, here are practical tips for VxWorks network design:\nDesign the right topology – For critical nodes, use mesh structures with redundancy. Use separate send and receive buffers – Enable zero communication dead time on the application layer. Increase resources to avoid congestion – Wider bandwidth, multiple routers, backup links. Tune timeout and retransmission – Set timeout equal to one full round trip (send, process, and ACK). Separate data and control channels – Use two sockets: one for data, one for monitoring/ack. Fast reconnection handling – On link failure, quickly re-establish sockets to resume normal operation. Conclusion # By modeling Ethernet queueing behavior in VxWorks and finding the optimal buffer size, we can reduce packet loss, improve utilization, and enhance real-time performance. Combined with thoughtful topology, timeout tuning, and redundancy, these strategies can significantly boost VxWorks network reliability.\nThis approach has strong engineering applicability for embedded systems requiring deterministic network performance.\nReferences\nWang G., Yue S., Li Y., et al. Networked Command and Control System Software Architecture Research, Modern Defense Technology, 2013(2). Qiu A., Zhang T., Gu Y. Real-Time Ethernet for Spacecraft Applications, Journal of Space Science, 2015(3). Miao X. Architecture of 11 Industrial Real-Time Ethernet Standards, Instrumentation Standardization \u0026amp; Measurement, 2009(3). Lu C. Queueing Theory, Beijing University of Posts and Telecommunications Press, 2000. ","date":"2025-08-12","externalUrl":null,"permalink":"/app/modeling-and-analyzing-network-performance-in-vxworks/","section":"Apps","summary":"\u003cp\u003eIn real-time embedded systems like \u003cstrong\u003eVxWorks\u003c/strong\u003e, reliable and predictable Ethernet communication is critical. To improve both \u003cstrong\u003ereliability\u003c/strong\u003e and \u003cstrong\u003ereal-time performance\u003c/strong\u003e, we can model the network behavior mathematically and apply \u003cstrong\u003equeueing theory\u003c/strong\u003e to determine the optimal buffer size that minimizes both \u003cstrong\u003epacket loss\u003c/strong\u003e and \u003cstrong\u003elatency\u003c/strong\u003e.\u003c/p\u003e","title":"Modeling and Analyzing Network Performance in VxWorks","type":"app"},{"content":"In embedded real-time systems, interrupts are the core mechanism for responding to external events. Whether it’s a sensor signal, peripheral input, or timer trigger, interrupts ensure that the system reacts in microseconds. The efficiency of an interrupt handling mechanism directly impacts the real-time performance of an operating system.\nBased on experimental data, this article analyzes the RTLinux and VxWorks interrupt mechanisms, compares their latency, and offers optimization suggestions.\n🔍 Key Takeaways # VxWorks ISR runs outside of task context → avoids task switching, resulting in lower latency. RTLinux uses a soft interrupt mechanism → more flexible, but higher latency. On the same hardware, VxWorks interrupt latency is about 35% lower than RTLinux. RTLinux can improve real-time performance by shortening interrupt-off time and optimizing scheduling. Why Compare RTLinux and VxWorks? # VxWorks → A mature commercial RTOS with excellent real-time performance, widely used in aerospace, defense, and medical equipment. RTLinux → An open-source real-time extension to Linux, lower cost, highly customizable, suited for industrial automation and research. For projects that need to balance performance and cost, understanding their interrupt mechanism differences is crucial for making the right system choice.\nVxWorks Interrupt Handling Mechanism # VxWorks is designed for minimal interrupt latency.\nExecution Context\nThe ISR (Interrupt Service Routine) runs in a special context, outside task context, avoiding the overhead of task switching.\nShared Interrupt Stack\nAll ISRs share a single interrupt stack allocated at system startup to prevent repeated memory allocation.\nISR Limitations\nCannot call blocking functions (e.g., acquiring a semaphore). Can send semaphores, messages, or events to tasks but cannot wait for them. Communication Pattern\nThe ISR only performs minimal work to signal the interrupt; non-real-time work is deferred to a task, reducing interrupt-off time.\nImplementation\nUses an interrupt vector table, binding ISRs via intConnect() and relying on the BSP interrupt controller driver for fast dispatch.\nRTLinux Interrupt Handling Mechanism # RTLinux takes a different approach: the Linux kernel runs as a task under a small real-time kernel.\nSoft Interrupt Concept\nSimulates hardware interrupt control using software variables, separating real-time and non-real-time interrupts. Real-time interrupts take priority over the Linux kernel. Interrupt Interception\nModifies the cli (disable interrupt) and sti (enable interrupt) macros so Linux cannot block real-time interrupts. Real-Time Guarantee\nNo matter what state the Linux kernel is in (kernel mode, user mode, even with interrupts “disabled”), the real-time kernel always handles real-time interrupts first.\nInterrupt Handling Flow Comparison # Experimental Comparison: Interrupt Latency # Hardware Platform: Samsung S3C2440A (ARM920T core, 500 MHz) Method: Timer interrupt interval: 2 μs All other interrupts masked Measured from interrupt trigger to ISR execution using an oscilloscope System Avg. Interrupt Latency Latency Difference VxWorks Low (Baseline) — RTLinux ~35% higher +35% 📊 Visual comparison:\nResult: VxWorks clearly outperforms RTLinux in interrupt latency on the same platform.\nReal-World Application Scenarios # VxWorks\nSpacecraft attitude control Missile guidance systems High-end medical devices RTLinux\nIndustrial automation systems Robotic motion control Real-time data acquisition for research Optimization Tips for RTLinux # ✅ Shorten interrupt-off time\nHandle only critical operations inside the ISR; move the rest to task context.\n✅ Reduce interrupt dispatch time (IDT)\nOptimize interrupt vector lookup and dispatch routines.\n✅ Optimize scheduler\nAdjust priority policies to reduce kernel preemption time (KVT).\n✅ Holistic optimization\nImprove both system-level and application-level design for better real-time performance.\nConclusion # VxWorks → Low-latency, stable performance, ideal for extremely time-critical applications. RTLinux → Flexible, open-source, customizable; with proper tuning, it can meet many real-time needs. Borrowing VxWorks’s “fast ISR return + deferred task processing” model could significantly improve RTLinux’s interrupt performance. 📚 References # VxWorks Programmer’s Guide 5.4, Wind River Systems, 1999. Programming Environments Manual for 32-bit PowerPC Architecture, Motorola Inc., 2001. Ma Wen-jun, Zhao Feng-yu. Comparison and Analysis of Interrupt Mechanism Between RTLinux and VxWorks, Microcomputer Information, 2011. ","date":"2025-08-12","externalUrl":null,"permalink":"/app/comparison-of-interrupt-mechanisms-in-rtlinux-and-vxworks/","section":"Apps","summary":"\u003cp\u003eIn embedded real-time systems, interrupts are the core mechanism for responding to external events. Whether it’s a sensor signal, peripheral input, or timer trigger, interrupts ensure that the system reacts in microseconds. The efficiency of an interrupt handling mechanism directly impacts the real-time performance of an operating system.\u003c/p\u003e","title":"Comparison of Interrupt Mechanisms in RTLinux and VxWorks","type":"app"},{"content":"","date":"2025-08-12","externalUrl":null,"permalink":"/tags/interrupt-mechanism/","section":"Tags","summary":"","title":"Interrupt Mechanism","type":"tags"},{"content":"","date":"2025-08-12","externalUrl":null,"permalink":"/tags/latency/","section":"Tags","summary":"","title":"Latency","type":"tags"},{"content":"","date":"2025-08-12","externalUrl":null,"permalink":"/tags/rtlinux/","section":"Tags","summary":"","title":"RTLinux","type":"tags"},{"content":" Introduction # VxWorks, developed by Wind River, is a real-time operating system (RTOS) widely used in embedded systems.\nIts USB stack supports a variety of USB serial adapters, allowing you to connect and access the VxWorks target console through them.\nThis guide walks you through building and deploying VxWorks with USB serial adapter support and configuring the console to use the adapter.\nPrerequisites # You will need:\nWind River VxWorks 7 SR0660 Intel target booting from UEFI BIOS USB flash drive (minimum 4 GB) USB serial adapter\nSupported types: FTDI 232 Prolific 2303 Any adapter supporting the USB CDC protocol Step 1: Create and Build the VxWorks Source Build (VSB) # Open a DOS shell and configure the build environment. Create the VSB and add required USB support. cd \u0026lt;WIND_HOME\u0026gt; # VxWorks installation directory wrenv -p vxworks-7 cd \u0026lt;YOUR_WORKSPACE\u0026gt; # your workspace vxprj vsb create adapter_vsb -bsp itl_generic -smp -force -S cd adapter_vsb vxprj vsb add USB_CLASS # USB class support vxprj vsb add USB_HELPER # USB helper utilities vxprj vsb add USB_SERIAL # USB serial device support make -j 32 # build the VSB Step 2: Create and Build the VxWorks Image Project (VIP) # Create a VIP using the VSB from Step 1. Add components for USB serial adapters. cd .. vxprj create -smp itl_generic adapter_vip \\ -profile PROFILE_INTEL_GENERIC \\ -vsb adapter_vsb cd adapter_vip vxprj vip component add INCLUDE_MULTI_STAGE_WARM_REBOOT vxprj vip bundle add BUNDLE_STANDALONE_SHELL # Add drivers for supported USB serial adapters vxprj vip component add INCLUDE_USB_GEN2_SER_FTDI232 vxprj vip component add INCLUDE_USB_GEN2_SER_PL2303 vxprj vip component add INCLUDE_USB_GEN2_SER_WRS_CDC vxprj vip component add INCLUDE_USB_GEN2_SERIAL_INIT vxprj build Step 3: Boot VxWorks and Test the USB Serial Adapter # 3.1 Deploy UEFI Bootloader and Kernel Image # Follow the itl_generic BSP README to deploy the bootloader and kernel image to your USB flash drive:\n\u0026lt;WIND_HOME\u0026gt;\\vxworks-7\\pkgs_v2\\os\\board\\intel\\itl_generic-a.b.c.d\\itl_generic_readme.md After deployment, your USB flash drive should contain:\nEFI BOOT bootapp.sys BOOTIA32.EFI BOOTX64.EFI 3.2 Prepare the Target # Set the BIOS to boot from the USB flash drive. Connect: USB flash drive to the target USB serial adapter to the target 3.3 Boot and Verify # Power on the target.\nYou should see:\nKernel shell prompt Messages confirming USB serial adapter detection and initialization Example:\n-\u0026gt; Find USB-to-Serial adapter device: FTDI USB-to-Serial Adapter Added new USB-to-Serial adapter device as /usb2ttyS/0 -\u0026gt; devs drv refs name ... 12 [ 3] /usb2ttyS/0 ... -\u0026gt; Step 4: Set VxWorks Console to Use USB Serial # Adding INCLUDE_USB_GEN2_SERIAL_PCCONSOLE_INIT creates /ttyUSB0, which maps to /usb2ttyS/0 in the VxWorks I/O system.\nvxprj vip component add INCLUDE_USB_GEN2_SERIAL_PCCONSOLE_INIT vxprj vip component add INCLUDE_USB_GEN2_HELPER vxprj vip parameter setstring CONSOLE_NAME \u0026#34;/ttyUSB0\u0026#34; # Verify settings vxprj vip parameter value CONSOLE_NAME CONSOLE_NAME = \u0026#34;/ttyUSB0\u0026#34; vxprj vip parameter value CONSOLE_BAUD_RATE CONSOLE_BAUD_RATE = (9600) Rebuild the VxWorks kernel and deploy the image file to the target USB flash drive. Rebuild the kernel and redeploy the image.\nStep 5: Reboot with Console Over USB Serial # Connect a serial cable from the USB adapter to your workstation. Boot the target again from the USB flash drive. Example device list:\n-\u0026gt; devs drv refs name ... 3 [ 3] /ttyUSB0 ... 2 [ 3] /tyCo/1 ==\u0026gt; /ttyUSB0 12 [ 3] /usb2ttyS/0 -\u0026gt; The console will now be available via both the PC console and the USB serial connection.\n","date":"2025-08-10","externalUrl":null,"permalink":"/bsp/integrating-usb-serial-adapters-with-vxworks-7/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eVxWorks, developed by Wind River, is a real-time operating system (RTOS) widely used in embedded systems.\u003cbr\u003e\nIts USB stack supports a variety of USB serial adapters, allowing you to connect and access the VxWorks target console through them.\u003c/p\u003e","title":"Integrating USB Serial Adapters with VxWorks 7: Build and Console Configuration Guide","type":"bsp"},{"content":"","date":"2025-08-10","externalUrl":null,"permalink":"/tags/usb/","section":"Tags","summary":"","title":"USB","type":"tags"},{"content":"","date":"2025-08-10","externalUrl":null,"permalink":"/tags/usb-serial/","section":"Tags","summary":"","title":"USB Serial","type":"tags"},{"content":" Introduction # This post shows how to measure and visualize the real-time performance of VxWorks, explains why those measurements matter, and walks you through reproducing the tests yourself. You’ll get:\nA short explanation of why real-time performance matters. A replicable test kit (VxWorks C test program) to measure: Interrupt latency Context switch time Timer precision A Python plotting script to turn console logs into histograms and timing plots. Step-by-step instructions to run comparable tests on Linux (with/without PREEMPT-RT) and FreeRTOS. Sample/representative results and publication-ready charts for your experiment. Why real-time performance matters # In hard real-time systems, missing a deadline may cause system failure. Key metrics: Interrupt latency — time from event to ISR entry. Context switch time — time to switch execution between tasks. Timer precision — accuracy of periodic tasks. A real RTOS (like VxWorks) provides deterministic behaviour with low jitter → essential for avionics, industrial control, robotics, and other safety-critical domains. Test hardware \u0026amp; software (recommended) # Hardware target: modern embedded CPU or x86 target (example: Intel Core i7-class development board). VxWorks: VxWorks 7 (timestamp/timer APIs available). Host tools: Wind River Workbench (build \u0026amp; console), Python 3 with matplotlib on host PC. Optional: logic analyzer / oscilloscope for hardware-accurate interrupt timing. VxWorks Real-Time Performance Test Kit # VxWorks C Test Program (save as performanceTest.c) This program demonstrates interrupt latency, a semaphore-based context-switch test, and a periodic timer callback for timer precision.\n/* performanceTest.c Compile \u0026amp; link in VxWorks build system. Adapt interrupt vector and timestamp APIs to your BSP if required. */ #include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; #include \u0026lt;semLib.h\u0026gt; #include \u0026lt;intLib.h\u0026gt; #include \u0026lt;sysLib.h\u0026gt; #include \u0026lt;tickLib.h\u0026gt; #include \u0026lt;timers.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;time.h\u0026gt; #include \u0026lt;drv/timer/timestampDev.h\u0026gt; SEM_ID sem1, sem2; volatile UINT64 irqStartTime, irqEndTime; volatile BOOL irqTriggered = FALSE; /* ISR for latency measurement */ void latencyISR(void) { irqEndTime = vxTimestamp(); irqTriggered = TRUE; } /* Interrupt latency test */ void testInterruptLatency(void) { UINT32 freq = sysTimestampFreq(); irqTriggered = FALSE; /* Replace 0x60 with the vector appropriate to your BSP or use a hardware timer to trigger an external interrupt. */ intConnect(INUM_TO_IVEC(0x60), (VOIDFUNCPTR)latencyISR, 0); intEnable(0x60); irqStartTime = vxTimestamp(); /* Trigger interrupt in a BSP-specific way; sysIntGen shown as example */ sysIntGen(0x60); while (!irqTriggered) taskDelay(1); double latency_us = ((double)(irqEndTime - irqStartTime) / freq) * 1e6; printf(\u0026#34;Interrupt Latency: %.2f microseconds\\n\u0026#34;, latency_us); } /* Context switch tasks */ void highPriorityTask(void) { while (1) { semTake(sem1, WAIT_FOREVER); UINT64 t1 = vxTimestamp(); semGive(sem2); double switchTime = ((double)(vxTimestamp() - t1) / sysTimestampFreq()) * 1e6; printf(\u0026#34;Context Switch Time: %.2f microseconds\\n\u0026#34;, switchTime); } } void lowPriorityTask(void) { while (1) { semGive(sem1); semTake(sem2, WAIT_FOREVER); } } /* Timer callback to measure period */ void timerCallback(timer_t timerId, int arg) { static UINT64 lastTime = 0; UINT64 now = vxTimestamp(); if (lastTime != 0) { double period_us = ((double)(now - lastTime) / sysTimestampFreq()) * 1e6; printf(\u0026#34;Timer Period: %.2f microseconds\\n\u0026#34;, period_us); } lastTime = now; } void testTimerPrecision(void) { struct sigevent evp; timer_t tid; struct itimerspec ts; evp.sigev_notify = SIGEV_THREAD; evp.sigev_value.sival_int = 0; evp.sigev_notify_function = (void (*)(union sigval))timerCallback; evp.sigev_notify_attributes = NULL; timer_create(CLOCK_REALTIME, \u0026amp;evp, \u0026amp;tid); ts.it_value.tv_sec = 0; ts.it_value.tv_nsec = 1000000; // 1 ms ts.it_interval = ts.it_value; timer_settime(tid, 0, \u0026amp;ts, NULL); } /* Entry: run the tests */ void vxworksPerformanceTest(void) { if (vxTimestampEnable() != OK) { printf(\u0026#34;Timestamp not supported on this platform\\n\u0026#34;); return; } printf(\u0026#34;VxWorks Real-Time Performance Test\\n\u0026#34;); /* 1) Interrupt latency (single-shot) */ testInterruptLatency(); /* 2) Context switch test */ sem1 = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY); sem2 = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY); taskSpawn(\u0026#34;tHigh\u0026#34;, 100, 0, 4096, (FUNCPTR)highPriorityTask, 0,0,0,0,0,0,0,0,0,0); taskSpawn(\u0026#34;tLow\u0026#34;, 101, 0, 4096, (FUNCPTR)lowPriorityTask, 0,0,0,0,0,0,0,0,0,0); /* 3) Timer precision: periodic prints */ testTimerPrecision(); } Python Plotting Script (plot_vxworks_performance.py) Copy the VxWorks console output into vxworks_performance.log. Then run this on your host machine to generate histograms and a timer-accuracy plot.\nimport re import matplotlib.pyplot as plt LOG_FILE = \u0026#34;vxworks_performance.log\u0026#34; interrupt_latencies = [] context_switch_times = [] timer_periods = [] re_interrupt = re.compile(r\u0026#34;Interrupt Latency:\\s*([\\d.]+)\\s*microseconds\u0026#34;) re_context = re.compile(r\u0026#34;Context Switch Time:\\s*([\\d.]+)\\s*microseconds\u0026#34;) re_timer = re.compile(r\u0026#34;Timer Period:\\s*([\\d.]+)\\s*microseconds\u0026#34;) with open(LOG_FILE, \u0026#34;r\u0026#34;) as f: for line in f: if m := re_interrupt.search(line): interrupt_latencies.append(float(m.group(1))) elif m := re_context.search(line): context_switch_times.append(float(m.group(1))) elif m := re_timer.search(line): timer_periods.append(float(m.group(1))) plt.figure(figsize=(8, 5)) plt.hist(interrupt_latencies, bins=20) plt.title(\u0026#34;Interrupt Latency Distribution\u0026#34;) plt.xlabel(\u0026#34;Latency (microseconds)\u0026#34;) plt.ylabel(\u0026#34;Frequency\u0026#34;) plt.grid(True, linestyle=\u0026#34;--\u0026#34;, alpha=0.6) plt.savefig(\u0026#34;interrupt_latency_histogram.png\u0026#34;, dpi=300) plt.close() plt.figure(figsize=(8, 5)) plt.hist(context_switch_times, bins=20) plt.title(\u0026#34;Context Switch Time Distribution\u0026#34;) plt.xlabel(\u0026#34;Time (microseconds)\u0026#34;) plt.ylabel(\u0026#34;Frequency\u0026#34;) plt.grid(True, linestyle=\u0026#34;--\u0026#34;, alpha=0.6) plt.savefig(\u0026#34;context_switch_histogram.png\u0026#34;, dpi=300) plt.close() plt.figure(figsize=(8, 5)) plt.plot(timer_periods, marker=\u0026#39;o\u0026#39;, markersize=3, linewidth=1) plt.title(\u0026#34;Timer Period Accuracy (1 ms Target)\u0026#34;) plt.xlabel(\u0026#34;Sample Number\u0026#34;) plt.ylabel(\u0026#34;Period (microseconds)\u0026#34;) plt.grid(True, linestyle=\u0026#34;--\u0026#34;, alpha=0.6) plt.savefig(\u0026#34;timer_period_plot.png\u0026#34;, dpi=300) plt.close() print(\u0026#34;Plots saved.\u0026#34;) Comparing with Linux \u0026amp; FreeRTOS # Linux (no RT patch)\nInstall rt-tests and use cyclictest:\nsudo apt install rt-tests sudo cyclictest -t1 -p99 -n -i1000 -l10000 Expect occasional spikes (50–200 µs or larger under heavy load). Linux (PREEMPT-RT)\nBoot a PREEMPT-RT kernel and run cyclictest again.\nTypical improvement: 10–20 µs ranges, still higher jitter than hard RTOSes. FreeRTOS\nOn bare-metal MCUs, reimplement the semaphore / ISR tests:\nUse hardware microsecond timer. Use xSemaphoreTake/xSemaphoreGive for context-switch timing. Typical FreeRTOS numbers vary by MCU clock — often in the low microseconds, but more variable under load. Representative Results\nThese are representative/sample numbers used in the example plots and table to help readers compare systems. Actual numbers depend heavily on hardware, BSP, and system load.\nOS Interrupt Latency (avg) Max Jitter Context Switch Time (avg) VxWorks 1.3 µs ±0.1 µs 3.8 µs FreeRTOS 2–5 µs ±1 µs 4–8 µs Linux (no RT) 50–200 µs ±100 µs 5–20 µs Linux RT 10–20 µs ±5 µs 5–10 µs Visuals\nThe two plots I generated for comparison (based on representative/simulated datasets):\nInterrupt Latency Histogram Latency \u0026amp; Jitter Box Plot If you’d like datasets that precisely reflect your hardware, run the VxWorks test, save vxworks_performance.log, and re-run the Python plot script above.\nTips \u0026amp; Best Practices for Reproducible Results # Run tests on an idle system for baseline numbers; then repeat under controlled load to show robustness. Use a hardware trigger + logic analyzer for the most accurate interrupt timing. Make sure timestamps use a high-resolution hardware timer (vxTimestamp() on VxWorks). Document the exact BSP, CPU model, kernel/firmware versions, and compile flags. Conclusion # This combined kit (VxWorks C test + Python plotter + comparison guide) gives you everything you need to measure and publish credible real-time performance results. The generated visuals make it easy to show how VxWorks compares to Linux and FreeRTOS in terms of latency and jitter.\n","date":"2025-08-10","externalUrl":null,"permalink":"/app/measuring-real-time-performance-with-vxworks/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThis post shows how to measure and visualize the real-time performance of VxWorks, explains why those measurements matter, and walks you through reproducing the tests yourself. You’ll get:\u003c/p\u003e","title":"Measuring Real Time Performance With VxWorks","type":"app"},{"content":"","date":"2025-08-10","externalUrl":null,"permalink":"/tags/real-time-performance/","section":"Tags","summary":"","title":"Real Time Performance","type":"tags"},{"content":"In the rapidly evolving automotive industry, the concept of \u0026ldquo;software-defined vehicles\u0026rdquo; (SDVs) is reshaping how cars are designed, manufactured, and experienced. As vehicles become increasingly intelligent, connected, and autonomous, software emerges as the core differentiator for automakers. This shift is driven by technological advancements and market demands, but it also introduces significant challenges. Drawing from insights in a Wind River presentation on SDVs, this article explores the key drivers, hurdles, and effective strategies to address them, highlighting how embedded operating systems and virtualization technologies play pivotal roles.\nThe Drivers Behind Software-Defined Vehicles # The transition to SDVs is fueled by the need for automakers to enhance business capabilities and engineering prowess through software. At its essence, SDVs redefine vehicle functionality and business models:\nSoftware-Defined Business Models: Traditional revenue streams from car sales and manufacturing are giving way to data-driven services. Projections indicate that by 2025, a significant portion of OEM (Original Equipment Manufacturer) revenue and EBITDA (Earnings Before Interest, Taxes, Depreciation, and Amortization) will stem from data and mobility services, rather than just hardware like white-body manufacturing or financial services. For instance, charts from industry analyses show a shift from 100% reliance on car sales in 2015 to a diversified model where services contribute substantially. Software-Defined Functionality: Hardware integration in electronic architectures is intensifying, leveraging Moore\u0026rsquo;s Law, which predicts that semiconductor performance doubles every 18 months while costs halve. This enables more powerful, efficient computing in vehicles, supporting features like advanced driver-assistance systems (ADAS), infotainment, and over-the-air (OTA) updates. These drivers align with broader trends encapsulated in the acronym CASE: Connected, Autonomous, Shared, and Electric vehicles. Software is the glue that binds these elements, allowing for seamless integration and innovation.\nKey Challenges in Implementing SDVs # While the benefits are compelling, realizing SDVs comes with formidable challenges that span technical, operational, and economic dimensions:\nComplexity: Modern vehicles can contain over 100 million lines of code, compounded by model variations. Collaboration with independent software vendors adds layers of intricacy, necessitating robust development ecosystems. Maintainability and Testability: Ensuring software reliability often requires sacrificing performance for better code management. Validation processes must be rigorous to handle this scale. Diverse Requirements: Software must balance real-time performance, safety, and ecosystem compatibility—especially in autonomous driving, where delays can be catastrophic. Dynamism: Rapid advancements in technology, semiconductor upgrades, and consumer-oriented development cycles accelerate changes in software needs. Total Cost of Ownership (TCO): Software\u0026rsquo;s long lifecycle demands ongoing maintenance and updates, offering improvement opportunities but also incurring sustained costs. Product Management: Treating software as a product involves cost accounting, supplier management, development oversight, and business definition—areas where traditional automotive firms may lack expertise. These challenges underscore the need for strategic tools and platforms to manage software effectively.\nStrategies for Overcoming Challenges: Choosing the Right Operating System # A foundational strategy involves selecting an appropriate embedded operating system (OS) that aligns with project needs. The presentation contrasts real-time operating systems (RTOS) with general-purpose ones like Linux, offering guidance on trade-offs.\nReal-Time vs. Non-Real-Time Systems # Hard Real-Time OS: Essential for deterministic tasks where missing deadlines renders outcomes worthless (e.g., sensor updates within 10ms). Predictability is key, though it comes at the expense of efficiency. Soft Real-Time OS: More flexible, with probabilistic constraints (e.g., 95% chance of completion within 1s), suitable for less critical applications. Kernel architectures also matter:\nMicro-Kernel (Common in RTOS): Small kernel for core functions, with services as independent processes. Pros: Fast boot, isolation; Cons: Performance dips in complex scenarios due to frequent context switches. Macro-Kernel (e.g., Linux): Larger kernel integrating scheduling, memory, file systems, and networking. Pros: High performance, rich ecosystem; Cons: Complexity and potential for system-wide crashes. Wind River\u0026rsquo;s VxWorks exemplifies a flexible \u0026ldquo;Flex Kernel\u0026rdquo; approach, blending micro and macro benefits. It supports kernel-mode (DKM) and user-mode (RTP) programming, ensuring real-time capabilities while allowing customization.\nWind River VxWorks: A Proven RTOS Solution # As the world\u0026rsquo;s leading RTOS provider, VxWorks powers billions of devices with features like:\nFunctional safety certifications (e.g., ISO 26262 ASIL-D for automotive, DO-178C Level A for avionics). POSIX compatibility, support for modern languages (C++17, Python 3.8), ROS 2.0, TSN, and full IPv4/IPv6 stacks. Security enhancements: Secure boot, encrypted storage, and TPM support. Extensive hardware ecosystem and source code access for tailoring. Linux: The Versatile Powerhouse # Linux dominates embedded systems (62% market share), smartphones (82%), and supercomputers (100%), thanks to its open-source robustness. For SDVs, Yocto-based distributions allow custom builds for real-time needs, small footprints, and high reliability. Wind River\u0026rsquo;s commercial Yocto Linux stands out as the #1 embedded commercial Linux, offering:\nValidated cybersecurity with timely patches. Long-term support (5-15+ years), IP compliance, and local expertise. Scalability to Wind River\u0026rsquo;s edge cloud platforms. Balancing Needs: RTOS vs. Linux # Demand Preferred OS Challenges Real-Time \u0026amp; Determinism RTOS Weaker ecosystem, lower performance Safety RTOS Weaker ecosystem, lower performance High-Performance Computing Linux Safety, security, IP compliance, maintenance High Throughput Linux Safety, security, IP compliance, maintenance Ecosystem Diversity Linux Safety, security, IP compliance, maintenance A common misconception is that automotive software mandates RTOS, with Linux relegated to prototypes. In reality, suitability trumps absolutes—often requiring a hybrid approach.\nVirtualization: The Future-Proof Solution # To reconcile conflicting demands, virtualization emerges as a game-changer. It enables multiple OSes on multi-core hardware, providing:\nSoftware Integration: Run diverse OSes (e.g., VxWorks, Linux, Android) side-by-side. Hardware Abstraction: Isolate resources for safety and scalability. Extensibility: Facilitate updates and expansions. Examples include software-defined avionics (IMA architecture) and networking (SDN/NFV). In automotive, hypervisors manage complex setups like ADAS, infotainment, and body controls on a single SoC.\nHypervisor types: # Type 1 (Bare-Metal): Direct hardware access for isolation and compatibility. Type 2 (Hosted): Runs atop a base OS for quick starts and dynamic allocation. Wind River\u0026rsquo;s Helix Virtualization Platform combines these, supporting unmodified guests, certifications, and industry frameworks (e.g., ARINC 653, AUTOSAR). It powers heterogeneous systems, blending safety-critical RTOS partitions with high-performance Linux ones.\nWind River: A Leader in Embedded Solutions # Founded in 1981, Wind River has pioneered mission-critical software for over 40 years, powering 2 billion+ devices. As #1 in RTOS and embedded Linux markets (per VDC Research), it holds 600+ certifications. In China since 1996, Wind River boasts a 300-person team, R\u0026amp;D center, and successes in aviation, telecom, and industrial sectors. Their portfolio includes VxWorks, commercial Linux, Helix, and services like BSP development, security consulting, and long-term maintenance—spanning the full lifecycle from design to operations.\nConclusion # Software-defined vehicles represent a paradigm shift, promising innovation but demanding careful navigation of complexities. By leveraging robust OSes like VxWorks and Linux, combined with virtualization, automakers can address challenges head-on. Wind River\u0026rsquo;s expertise offers a comprehensive pathway, ensuring safety, performance, and future-readiness. As the industry accelerates toward CASE trends, embracing these strategies will define the winners in the mobility landscape.4.2s\n","date":"2025-08-09","externalUrl":null,"permalink":"/industries/navigating-the-era-of-software-defined-vehicles/","section":"Industries","summary":"\u003cp\u003eIn the rapidly evolving automotive industry, the concept of \u0026ldquo;software-defined vehicles\u0026rdquo; (SDVs) is reshaping how cars are designed, manufactured, and experienced. As vehicles become increasingly intelligent, connected, and autonomous, software emerges as the core differentiator for automakers. This shift is driven by technological advancements and market demands, but it also introduces significant challenges. Drawing from insights in a Wind River presentation on SDVs, this article explores the key drivers, hurdles, and effective strategies to address them, highlighting how embedded operating systems and virtualization technologies play pivotal roles.\u003c/p\u003e","title":"Navigating the Era of Software-Defined Vehicles","type":"industries"},{"content":"","date":"2025-08-09","externalUrl":null,"permalink":"/tags/over-the-air/","section":"Tags","summary":"","title":"Over the Air","type":"tags"},{"content":"","date":"2025-08-09","externalUrl":null,"permalink":"/tags/software-defined-vehicles/","section":"Tags","summary":"","title":"Software-Defined Vehicles","type":"tags"},{"content":"","date":"2025-08-09","externalUrl":null,"permalink":"/tags/total-cost-of-ownership/","section":"Tags","summary":"","title":"Total Cost of Ownership","type":"tags"},{"content":" Introduction # The Board Support Package (BSP) acts as the hardware abstraction layer for VxWorks. It is responsible for initializing the CPU, memory, clocks, interrupt controllers, and peripherals during system boot before handing control over to the OS kernel. Without a proper BSP, VxWorks cannot run on your hardware.\nBSPs are generally highly hardware-specific but share some common components like:\nEarly CPU initialization Memory management (MMU setup) Device initialization and configuration Bringing up interrupt controllers Support for device drivers via VxBus Because BSP development involves low-level programming often in C and assembly, understanding processor manuals and board schematics is essential.\nBSP Development Workflow # Hardware Documentation # Start by collecting:\nCPU/SoC reference manuals Board schematics for memory maps and pin multiplexing Peripheral datasheets for registers and interrupts Selecting a Starting BSP # VxWorks BSPs for similar CPUs are often available. For example, a Cortex-A9 BSP can be adapted for a new A9-based board by updating memory and device tree entries.\nPorting the BSP # Memory Map: Adjust physical and virtual memory ranges, ensure proper MMU settings. Clock \u0026amp; PLL Setup: Initialize board clocks as required by peripherals. UART/Console Setup: For early debug output. Interrupt Controller: Initialize the interrupt controller to handle device IRQs. Device Tree: Describe all hardware peripherals. Build \u0026amp; Test # Build BSP using Wind River’s make or vxprj tools. Use JTAG or serial console to debug boot. Use VxWorks shell commands (devs, i, ld) for runtime diagnostics. BSP Directory Structure # Example layout:\nyour_bsp/ ├── Makefile # Build rules and compiler flags ├── config.h # BSP-wide defines (CPU freq, memory sizes) ├── sysLib.c # System initialization functions ├── sysClk.c # System clock (timer) support ├── sysSerial.c # Serial port driver interface ├── hwconf.c # Hardware resource configuration tables ├── device-tree/ # Device tree source files (*.dts) │ ├── myboard.dts │ └── ... └── README.md sysLib.c # Contains CPU setup, memory initialization, and system boot entry points such as:\nvoid sysHwInit(void) { /* Disable interrupts */ vxCpuIntDisable(); /* Initialize memory controller */ sysMemInit(); /* Initialize UART for early debug */ sysSerialHwInit(); /* Setup interrupt controller */ sysIntInit(); /* Setup system timer */ sysClkInit(); /* Enable interrupts */ vxCpuIntEnable(); } config.h # Defines board parameters such as clock frequencies, memory sizes, and BSP configuration macros. Example:\n#define SYS_CLK_RATE 100 /* 100 ticks per second */ #define LOCAL_MEM_LOCAL_ADRS 0x80000000 #define LOCAL_MEM_SIZE 0x10000000 /* 256MB */ #define UART_BASE_ADDR 0x10000000 #define UART_BAUD_RATE 115200 Essential BSP Components # Boot Loader Overview # The boot loader’s job is to perform very early system initialization and load the VxWorks image into memory. Often, this is a minimal program or U-Boot variant that:\nConfigures CPU mode (cache, MMU off or on) Sets up initial DRAM controller Initializes UART for serial debug output Loads kernel image from flash, network, or SD card Jumps to sysStart() entry in VxWorks kernel Early Initialization Code Example # void sysHwInit0(void) { /* Disable interrupts globally */ vxCpuIntDisable(); /* Initialize clocks */ clkInit(); /* Initialize UART for early console */ uartInit(UART_BASE_ADDR, UART_BAUD_RATE); /* Print boot message */ printf(\u0026#34;BSP early initialization complete. \u0026#34;); } Boot Loader Early Initialization # void sysHwInit0(void) { vxCpuIntDisable(); *(volatile uint32_t *)0xF8006000 = 0x12345678; // DDR timing *(volatile uint32_t *)0xF8006004 = 0x0000AABB; pllConfig(0x1F, 0x2A); uartInit(0x9000000, 115200); printf(\u0026#34;Board early init done, UART ready. \u0026#34;); } sysStart() Entry Point # The function sysStart() is the kernel start routine invoked by the boot loader after loading the OS image. Typically it performs further hardware initialization and then calls usrRoot() which is the user application entry.\nDevice Tree Configuration # What is a Device Tree? # The device tree (DT) is a data structure for describing hardware components in a system in a platform-independent way. Instead of hardcoding hardware parameters in BSP code, the DT allows the OS and drivers to discover and configure devices dynamically at boot.\nVxWorks uses device tree blobs (.dtb) compiled from .dts source files to initialize hardware resources and bind drivers via VxBus.\nBasic Device Tree Syntax Example # / { uart0: serial@10000000 { compatible = \u0026#34;ns16550\u0026#34;; reg = \u0026lt;0x10000000 0x1000\u0026gt;; interrupts = \u0026lt;5\u0026gt;; clock-frequency = \u0026lt;24000000\u0026gt;; }; timer0: timer@10002000 { compatible = \u0026#34;arm,armv7-timer\u0026#34;; reg = \u0026lt;0x10002000 0x1000\u0026gt;; interrupts = \u0026lt;30\u0026gt;; }; }; compatible: identifies the device type or driver to bind reg: base address and size of the device registers interrupts: IRQ number Other properties (e.g., clock frequency) configure the device Integrating Device Tree in BSP # Place .dts files in bsp/your_bsp/device-tree/ Add device tree compilation to the BSP Makefile using dtc (device tree compiler) In BSP init code, load and parse the device tree blob before probing devices Example in hwconf.c (pseudocode):\nvoid hwconfInit(void) { dtb = loadDeviceTreeBlob(\u0026#34;/boot/myboard.dtb\u0026#34;); vxBusInit(dtb); } Complex Device Tree Fragment # i2c1: i2c@40800000 { compatible = \u0026#34;arm,my-i2c\u0026#34;; reg = \u0026lt;0x40800000 0x1000\u0026gt;; interrupts = \u0026lt;23\u0026gt;; clock-frequency = \u0026lt;100000\u0026gt;; temp_sensor@48 { compatible = \u0026#34;ti,tmp102\u0026#34;; reg = \u0026lt;0x48\u0026gt;; }; eeprom@50 { compatible = \u0026#34;at,24c256\u0026#34;; reg = \u0026lt;0x50\u0026gt;; }; }; MMU \u0026amp; Cache Setup # Importance of MMU Setup # The Memory Management Unit (MMU) controls virtual memory translation, access permissions, and cache attributes. Proper MMU configuration is essential for:\nProtecting memory regions Enabling cache for performance Mapping peripherals as non-cacheable Defining Physical Memory Regions # Use VM_REGION structs to describe memory layout in sysPhysMemDesc[]. Example:\nVM_REGION sysPhysMemDesc[] = { { (VIRT_ADDR) LOCAL_MEM_LOCAL_ADRS, (PHYS_ADDR) LOCAL_MEM_LOCAL_ADRS, LOCAL_MEM_SIZE, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE, VM_STATE_VALID | VM_STATE_WRITABLE }, { (VIRT_ADDR) PERIPH_BASE_ADDR, (PHYS_ADDR) PERIPH_BASE_ADDR, PERIPH_SIZE, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE /* no cache */ } }; Enabling Caches # Enable instruction and data cache early in the boot code:\nvoid cacheEnable(void) { cacheEnable(INSTRUCTION_CACHE); cacheEnable(DATA_CACHE); } Cache Management for DMA Buffers # For buffers shared between CPU and DMA devices, flush or invalidate caches to ensure coherency:\nvoid prepareDmaBuffer(void *buffer, size_t size) { cacheFlush(DATA_CACHE, buffer, size); } Interrupt \u0026amp; Timer Initialization # Interrupt Controller Setup # The BSP must initialize the interrupt controller (e.g., GIC on ARM) to:\nRoute device IRQs Enable/disable interrupts Set interrupt priorities Example in sysIntInit():\nvoid sysIntInit(void) { gicInit(); gicEnableDistributor(); } Connecting Interrupt Service Routines (ISRs) # Use intConnect() to associate an interrupt vector with an ISR:\nSTATUS sysSerialIntConnect(void) { return intConnect(INUM_TO_IVEC(UART_INT_VEC), (VOIDFUNCPTR)sysSerialIntHandler, 0); } System Clock Initialization # The system clock drives OS ticks and timing. Typical BSP setup:\nSTATUS sysClkConnect(FUNCPTR routine, int arg) { sysClkRoutine = routine; sysClkArg = arg; return OK; } void sysClkInt(void) { if (sysClkRoutine) sysClkRoutine(sysClkArg); } STATUS sysClkEnable(void) { timerEnable(TIMER0, SYS_CLK_RATE); intConnect(INUM_TO_IVEC(TIMER0_INT_VEC), sysClkInt, 0); intEnable(TIMER0_INT_VEC); return OK; } ARM GIC Interrupt Setup # void sysIntInit(void) { gicDistInit(); gicCpuInit(); gicDistEnable(); gicSetPriority(UART_INT_VEC, 0x80); gicEnableInterrupt(UART_INT_VEC); intConnect(INUM_TO_IVEC(UART_INT_VEC), (VOIDFUNCPTR)uartIsr, 0); intEnable(UART_INT_VEC); } Adding Device Drivers # VxBus Framework # VxWorks drivers are managed by VxBus, which uses device tree information to probe and attach drivers dynamically.\nExample: UART Driver Initialization # #include \u0026lt;vxBusLib.h\u0026gt; #include \u0026lt;hwif/vxbus/vxBus.h\u0026gt; LOCAL VXB_DEV_ID uartDev; STATUS sysSerialHwInit(void) { uartDev = vxbInstByNameFind(\u0026#34;ns16550\u0026#34;, 0); if (!uartDev) return ERROR; return OK; } Driver Probe \u0026amp; Attach Methods # Drivers define probe and attach callbacks that VxBus calls during device enumeration:\nLOCAL STATUS myUartProbe(VXB_DEV_ID pDev) { /* Verify hardware presence */ return OK; } LOCAL STATUS myUartAttach(VXB_DEV_ID pDev) { /* Map registers, initialize device */ return OK; } LOCAL VXB_DRV_METHOD myUartMethods[] = { { VXB_DEVMETHOD_CALL(vxbDevProbe), (FUNCPTR)myUartProbe }, { VXB_DEVMETHOD_CALL(vxbDevAttach), (FUNCPTR)myUartAttach }, VXB_DEVMETHOD_END }; VXB_DRV_DEF(myUartDrv, myUartMethods, \u0026#34;My UART Driver\u0026#34;); UART Driver Probe and Attach # LOCAL STATUS uartProbe(VXB_DEV_ID pDev) { volatile uint32_t *reg = (volatile uint32_t *)vxbRegBaseAddr(pDev); if ((*reg \u0026amp; 0xFF) != EXPECTED_UART_ID) return ERROR; return OK; } LOCAL STATUS uartAttach(VXB_DEV_ID pDev) { volatile uint32_t *base = (volatile uint32_t *)vxbRegBaseAddr(pDev); base[UART_BAUD_REG] = UART_BAUD_115200; base[UART_CTRL_REG] = UART_ENABLE | UART_RX_INT_ENABLE; return OK; } Debugging \u0026amp; Testing BSP # Using the VxWorks Shell # VxWorks shell provides commands to inspect and debug BSP and drivers:\ndevs — List devices recognized by VxBus i — Show active interrupts ld — List loaded modules/drivers sp — Spawn tasks for testing drivers Example:\n-\u0026gt; devs ns16550@10000000 (serial) timer@10002000 WindView Event Tracing # WindView allows tracing events such as interrupts and context switches to profile BSP performance. Integrate WindView macros in critical BSP code sections for fine-grained analysis.\nHardware Debuggers # Use JTAG or BDI to:\nStep through boot code Inspect registers and memory Set breakpoints in BSP code (e.g., sysHwInit) Best Practices # Start from a close BSP: saves time and reduces bugs Incremental testing: test each stage separately — memory, console, interrupts, timers Use Device Tree: avoids hardcoded hardware descriptions, easier to maintain Document everything: memory maps, IRQs, clock settings Isolate BSP from application code: maintain a clean modular design Advanced BSP Topics # Multi-Core (SMP) Bring-Up # Enabling SMP in VxWorks # Define number of CPUs and enable SMP config macros:\n#define _WRS_CONFIG_SMP 1 #define VX_SMP_NUM_CPUS 4 Starting Secondary CPUs # The BSP must boot secondary cores and initialize their kernel data:\nvoid sysSecondaryCpuStart(void) { sysSecondaryCpuInit(); kernelCpuInit(); } Each secondary CPU runs this code to join the SMP kernel.\nAdding Custom Peripheral Drivers # Device Tree Example # spi1: spi@40013000 { compatible = \u0026#34;myvendor,myspi\u0026#34;; reg = \u0026lt;0x40013000 0x1000\u0026gt;; interrupts = \u0026lt;12\u0026gt;; bus-frequency = \u0026lt;48000000\u0026gt;; }; Driver Skeleton # LOCAL STATUS myspiProbe(VXB_DEV_ID pDev) { return OK; } LOCAL STATUS myspiAttach(VXB_DEV_ID pDev) { return OK; } LOCAL VXB_DRV_METHOD myspiMethods[] = { { VXB_DEVMETHOD_CALL(vxbDevProbe), (FUNCPTR)myspiProbe }, { VXB_DEVMETHOD_CALL(vxbDevAttach), (FUNCPTR)myspiAttach }, VXB_DEVMETHOD_END }; VXB_DRV_DEF(myspiDrv, myspiMethods, \u0026#34;MyVendor SPI Driver\u0026#34;); Performance Tuning # Enable caches and manage coherency explicitly for DMA buffers Use fast interrupt connect (intConnect) and enable only needed IRQs Map devices as non-cacheable memory regions to avoid stale data Minimize ISR latency by keeping handlers short and deferring work Booting Secondary CPU (ARM Cortex-A9) # void sysSecondaryCpuStart(void) { *(volatile uint32_t *)CPU_RELEASE_ADDR = SECONDARY_CPU_START_ADDR; while(!secondaryCpuReady()); kernelCpuInit(); } Debugging Advanced BSP Issues # Multi-Core Debugging: Use JTAG tools capable of multi-core debugging; watch for synchronization issues Driver Debugging: Use VxBus commands like vxbDevShow() and check driver probe/attach return values Memory Issues: Check MMU mapping carefully; use VxWorks memory tools to monitor heap/stack Advanced Best Practices # Bring up SMP incrementally, test each CPU individually Use device tree overlays to test new hardware without recompiling BSP Design ISRs to be deterministic and use kernel-safe APIs Maintain detailed API documentation for BSP driver interfaces Conclusion # Mastering BSP development in VxWorks unlocks full control over your embedded system hardware. From basic boot initialization through advanced SMP support and custom driver integration, a well-crafted BSP is foundational to reliable, high-performance real-time applications.\nWith modular design, proper documentation, and thorough testing, your BSP can support complex hardware platforms and enable your VxWorks system to meet demanding real-time requirements.\n","date":"2025-08-09","externalUrl":null,"permalink":"/bsp/vxworks-bsp-development-handbook/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThe \u003cstrong\u003eBoard Support Package (BSP)\u003c/strong\u003e acts as the hardware abstraction layer for VxWorks. It is responsible for initializing the CPU, memory, clocks, interrupt controllers, and peripherals during system boot before handing control over to the OS kernel. Without a proper BSP, VxWorks cannot run on your hardware.\u003c/p\u003e","title":"VxWorks BSP Development Handbook: Boot, Drivers, MMU, and SMP","type":"bsp"},{"content":"","date":"2025-08-09","externalUrl":null,"permalink":"/tags/soc-e/","section":"Tags","summary":"","title":"SOC E","type":"tags"},{"content":"I’m excited to announce that SOC-E is partnering with Wind River to bring SOC-E’s advanced Time-Sensitive Networking (TSN) solutions directly to the VxWorks® real-time operating system (RTOS).\nVxWorks is the platform of choice for organizations that require deterministic performance and robust reliability. Together, VxWorks and SOC-E will enable a new generation of intelligent software-defined platforms across multiple mission-critical use cases.\nWhy This Partnership Matters # VxWorks is renowned for its deterministic performance, modularity, and support for complex, safety-critical applications. By integrating SOC-E’s TSN technology, organizations can deploy Ethernet networks on a proven, certifiable RTOS platform — crucial for applications in sectors such as aerospace, defense, and industrial, where timing, reliability, and security are nonnegotiable.\nKey Benefits: # Deterministic, low-latency networking: SOC-E’s TSN solutions ensure sub-microsecond synchronization and guaranteed data delivery, even in congested environments, directly addressing the stringent requirements of flight control, mission systems, and real-time cybersecurity. Mixed-criticality traffic management: TSN allows critical and noncritical data to coexist on the same network, with advanced scheduling and prioritization to ensure that safety-critical traffic always takes precedence. Reduced weight and complexity: By consolidating multiple legacy networks onto a single TSN-enabled Ethernet backbone, aircraft and vehicles can achieve up to 50% wiring reduction, translating to lower weight, improved fuel efficiency, and easier maintenance. Interoperability and scalability: TSN’s standards-based approach ensures seamless integration with existing infrastructure and supports future upgrades, essential for evolving defense architectures such as NATO Generic Vehicle Architecture (NGVA). Powering Innovation Together # By providing a scalable, secure, and certifiable foundation, VxWorks and SOC-E enable aerospace and defense organizations to accelerate innovation, reduce program risk, and deploy future-ready capabilities across air, land, and space platforms.\nOur partnership powers innovations such as these:\nIn aircraft avionics, VxWorks provides the deterministic real-time performance and safety certification support needed for precision flight controls, autopilot, and collision avoidance, all while enabling simplified and lighter wiring harnesses through integrated modular avionics architectures. For defense vehicle networks, the combination of VxWorks and SOC-E supports real-time video streaming and unified subsystem integration, which enhances situational awareness and operational effectiveness. In spacecraft avionics, VxWorks and SOC-E facilitate converged onboard data handling and reduce subsystem weight by streamlining system architecture, leading to more efficient and reliable missions. For uncrewed systems, such as drones, VxWorks delivers the synchronized communication and real-time sensor fusion required for coordinated autonomous operations, supporting advanced mission management and rapid response to dynamic environments. Paving the Way for Next-Gen Platforms # The integration of SOC-E TSN with VxWorks is a catalyst for modular open architectures in aerospace and defense, enabling digital backbones and zonal avionics that are more efficient, scalable, and ready for stringent certifications such as DO-178C DAL A. As the TSN market is projected to expand rapidly by 2028, this partnership positions both companies — and their customers — at the forefront of innovation in high-stakes environments.\nLearn more about SOC-E TSN solutions.\nLearn more about VxWorks from Wind River.\nBy Eric Levander, Vice President, Global Alliances, Wind River\n","date":"2025-08-09","externalUrl":null,"permalink":"/news/soc-e-and-wind-river-partner-to-deliver-tsn-solutions-on-vxworks/","section":"News","summary":"\u003cp\u003eI’m excited to announce that SOC-E is partnering with Wind River to bring SOC-E’s advanced Time-Sensitive Networking (TSN) solutions directly to the VxWorks® real-time operating system (RTOS).\u003c/p\u003e","title":"SOC E and Wind River Partner to Deliver TSN Solutions on VxWorks","type":"news"},{"content":" 🧭 Introduction # VxWorks is a highly reliable, real-time operating system (RTOS) designed for embedded systems. It\u0026rsquo;s used extensively in aerospace, automotive, industrial, and networking systems where deterministic performance and robustness are crucial.\nThis blog post is a complete VxWorks programming guide. Whether you\u0026rsquo;re new to the platform or transitioning from bare-metal or Linux-based embedded development, this guide walks you through:\nVxWorks architecture Development environment and tools Programming paradigms (tasking, inter-process communication, memory, etc.) Sample code using POSIX APIs and native VxWorks APIs Best practices 🏗️ VxWorks Architecture Overview # VxWorks 7 introduced a modular architecture and Real-Time Processes (RTPs), allowing user-space application development with memory protection.\nKey Architectural Components # Component Description Kernel Core scheduler and services (interrupts, tasking, timers, semaphores) RTP User-mode applications with memory protection Device Drivers Handle hardware I/O, configured via VxBus MMU Support Enabled for memory protection and address space isolation Wind River Workbench Eclipse-based IDE for development and debugging ⚙️ Development Workflow # Setup Toolchain: Install Workbench or use diab/gcc cross-toolchains. Create VxWorks Image: Select OS components in VSB (VxWorks Source Build). Develop RTP or Kernel Module: Choose whether your application runs in user space (RTP) or as part of the kernel. Build and Deploy: Load the image to your target via JTAG, network, or serial. Debug: Use Workbench or target server for live symbol debugging. 🧪 Sample Application – Hello World (RTP) # // hello.c #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; int main(void) { printf(\u0026#34;Hello from VxWorks RTP!\\n\u0026#34;); sleep(1); return 0; } Compile: # ccpentium -o hello.vxe hello.c Run on target: # -\u0026gt; rtpSpawn(\u0026#34;/ram0/hello.vxe\u0026#34;, 0, 100, 0, 0) 🧵 Multitasking in VxWorks # VxWorks provides both POSIX threads and native tasks (taskSpawn).\nUsing POSIX Threads # #include \u0026lt;pthread.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; void* task_func(void* arg) { printf(\u0026#34;Task running\\n\u0026#34;); return NULL; } int main() { pthread_t tid; pthread_create(\u0026amp;tid, NULL, task_func, NULL); pthread_join(tid, NULL); return 0; } Using VxWorks Native Tasks # #include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; void task_func(int arg) { printf(\u0026#34;VxWorks task running\\n\u0026#34;); } int main() { taskSpawn(\u0026#34;tMyTask\u0026#34;, 100, 0, 4096, (FUNCPTR)task_func, 0,0,0,0,0,0,0,0,0,0); return 0; } 📬 Inter-Task Communication # VxWorks supports:\nMessage Queues (msgQCreate, msgQSend, msgQReceive) Semaphores (semBCreate, semGive, semTake) Shared Memory Pipes and POSIX message queues Example: Message Queue # MSG_Q_ID msgQId; void senderTask() { msgQSend(msgQId, \u0026#34;Hello\u0026#34;, 6, WAIT_FOREVER, MSG_PRI_NORMAL); } void receiverTask() { char buf[32]; msgQReceive(msgQId, buf, sizeof(buf), WAIT_FOREVER); printf(\u0026#34;Received: %s\\n\u0026#34;, buf); } void initTasks() { msgQId = msgQCreate(10, 32, MSG_Q_PRIORITY); taskSpawn(\u0026#34;sender\u0026#34;, 100, 0, 4096, (FUNCPTR)senderTask, 0,0,0,0,0,0,0,0,0); taskSpawn(\u0026#34;receiver\u0026#34;, 100, 0, 4096, (FUNCPTR)receiverTask, 0,0,0,0,0,0,0,0,0); } 💾 File System and I/O # VxWorks supports DOSFS, HRFS, and raw block I/O.\nMount a USB stick # usrUsbInit(); usrFsLibInit(); dosFsDevCreate(\u0026#34;/usb0\u0026#34;, \u0026#34;usbMassStorageDevice\u0026#34;, 0); Basic File I/O # #include \u0026lt;fcntl.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; int fd = open(\u0026#34;/usb0/log.txt\u0026#34;, O_CREAT | O_WRONLY, 0666); write(fd, \u0026#34;Log Entry\\n\u0026#34;, 10); close(fd); 🌐 Networking # VxWorks provides IPv4/IPv6 stacks, DHCP, SNTP, FTP, Telnet, and SSH.\nExample: Send HTTP GET using BSD Sockets # #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;string.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; #include \u0026lt;arpa/inet.h\u0026gt; #include \u0026lt;netdb.h\u0026gt; void httpGet() { int sock = socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in addr; struct hostent* server = gethostbyname(\u0026#34;example.com\u0026#34;); addr.sin_family = AF_INET; addr.sin_port = htons(80); memcpy(\u0026amp;addr.sin_addr, server-\u0026gt;h_addr, server-\u0026gt;h_length); connect(sock, (struct sockaddr*)\u0026amp;addr, sizeof(addr)); write(sock, \u0026#34;GET / HTTP/1.0\\r\\n\\r\\n\u0026#34;, 18); char buf[512]; read(sock, buf, sizeof(buf)); printf(\u0026#34;Response: %s\\n\u0026#34;, buf); close(sock); } 🔒 Memory Management # malloc, calloc, free (RTP) memPartAlloc, memPartFree (Kernel) vmLib, vmCreate, vmMap (MMU control) Stack Overflow Protection # taskStackGuardPageEnable(TRUE); ✅ Best Practices # Use RTPs for modularity and isolation Enable MMU for memory safety Avoid busy-wait loops; use semaphores or message queues Use POSIX APIs for portability Instrument with windview or logs for performance tuning Use static analysis tools to verify safety-critical code 🔚 Conclusion # VxWorks is a robust and modular RTOS that allows deep control over real-time embedded applications. With RTP support, POSIX compliance, and a modern development environment, it bridges traditional RTOS features with modern embedded system demands.\n📚 Further Reading # VxWorks Application Programmer’s Guide (PDF) Wind River Docs VxWorks Programmer’s Guide ","date":"2025-08-08","externalUrl":null,"permalink":"/app/the-ultimate-vxworks-programming-guide/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003e🧭 Introduction \n    \u003cdiv id=\"-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://www.windriver.com/products/vxworks\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e is a highly reliable, real-time operating system (RTOS) designed for embedded systems. It\u0026rsquo;s used extensively in aerospace, automotive, industrial, and networking systems where deterministic performance and robustness are crucial.\u003c/p\u003e","title":"The Ultimate VxWorks Programming Guide","type":"app"},{"content":" Introduction # The S3C2440, a 32-bit RISC microcontroller based on the ARM920T core, is widely used in embedded systems due to its performance and versatility. VxWorks, a real-time operating system (RTOS), is favored in embedded applications for its deterministic behavior and robust feature set. Implementing a boot mechanism for VxWorks using NandFlash memory on the S3C2440 presents unique challenges and opportunities, as NandFlash offers high storage capacity but requires careful management due to its complex read/write characteristics. This article explores the design, implementation, and verification of a NandFlash-based boot system for VxWorks on the S3C2440, highlighting key technical considerations and practical applications.\nSystem Architecture # The S3C2440 processor supports multiple boot options, including NOR Flash, NAND Flash, and SD cards. NandFlash is preferred for its cost-effectiveness and large storage capacity, making it ideal for storing the VxWorks kernel and application code. The boot process involves several components:\nBootloader: A lightweight program stored in the S3C2440’s Steppingstone (a 4KB internal SRAM) initializes the hardware, configures the NandFlash controller, and loads the VxWorks image into SDRAM. NandFlash Controller: The S3C2440’s integrated NandFlash controller manages data transfer between the NandFlash and system memory, handling error correction and bad block management. VxWorks Image: The VxWorks kernel, drivers, and application code are stored in NandFlash and loaded into SDRAM during boot. The boot sequence begins with the S3C2440 executing the bootloader from Steppingstone, which initializes the CPU, memory, and NandFlash controller. The bootloader then reads the VxWorks image from NandFlash, decompresses it if necessary, and transfers control to the VxWorks kernel.\nDesign Considerations # Designing a NandFlash boot system for VxWorks on the S3C2440 requires addressing several challenges:\nNandFlash Characteristics: Unlike NOR Flash, NandFlash has a block-based structure, requiring error correction codes (ECC) and bad block management. The bootloader must implement algorithms to skip bad blocks and verify data integrity. Memory Constraints: The S3C2440’s Steppingstone has limited capacity (4KB), necessitating a compact bootloader that can initialize hardware and load the VxWorks image efficiently. Performance Optimization: Minimizing boot time is critical for real-time systems. Techniques such as data compression and optimized read algorithms reduce the time required to load the VxWorks image. Reliability: The boot process must be robust against power failures and data corruption, incorporating mechanisms like redundant boot images or checksum verification. Implementation # The implementation process involves the following steps:\nBootloader Development:\nA custom bootloader is written in C and ARM assembly, tailored for the S3C2440. It initializes the PLL, sets the CPU clock, configures the memory controller, and enables the NandFlash interface. The bootloader reads the first few pages of NandFlash to locate the VxWorks image, using ECC to ensure data integrity. The VxWorks image is copied to SDRAM, and the bootloader jumps to the kernel’s entry point. NandFlash Management:\nThe S3C2440’s NandFlash controller is configured to handle page sizes (typically 2KB) and ECC requirements. A bad block table is maintained in a reserved NandFlash area to track defective blocks, ensuring reliable data storage. Wear-leveling algorithms are implemented to extend the NandFlash lifespan. VxWorks Configuration:\nThe VxWorks kernel is built with drivers for the S3C2440’s peripherals, including UART, timers, and interrupts. The kernel is linked to run from SDRAM, with the bootloader passing control via a predefined memory address. A file system (e.g., TrueFFS) is integrated to manage application data stored in NandFlash post-boot. Image Storage:\nThe VxWorks image is compiled, compressed (using gzip or similar), and written to NandFlash using a programming tool or JTAG interface. A header containing metadata (e.g., image size, checksum) is prepended to the image for bootloader verification. System Verification # Verification ensures the boot system operates reliably under various conditions. The process includes:\nFunctional Testing: The bootloader is tested to confirm it correctly initializes hardware and loads the VxWorks image. Test cases include booting with different NandFlash configurations and image sizes. Stress Testing: The system is subjected to repeated power cycles and simulated NandFlash failures to verify robustness. Performance Testing: Boot time is measured to ensure it meets real-time requirements, typically achieving a boot time of under 2 seconds for a minimal VxWorks image. Error Handling: The bootloader’s ability to handle bad blocks, ECC errors, and corrupted images is validated using fault injection techniques. Testing was conducted on an S3C2440 development board with a 256MB NandFlash chip. The system successfully booted VxWorks in all test cases, with an average boot time of 1.8 seconds and no failures during 1000 power cycles.\nApplications # The NandFlash boot system for VxWorks on the S3C2440 has applications in various embedded domains:\nIndustrial Automation: Real-time control systems benefit from VxWorks’ deterministic performance and the S3C2440’s low cost. Consumer Electronics: Devices like set-top boxes and IoT gateways leverage NandFlash for cost-effective storage of firmware and applications. Automotive Systems: The robust boot mechanism supports infotainment and telematics systems requiring reliable startup. Medical Devices: The system’s reliability ensures consistent operation in critical applications like patient monitoring. Conclusion # Implementing a NandFlash-based boot system for VxWorks on the S3C2440 combines the processor’s hardware capabilities with VxWorks’ real-time performance. By addressing NandFlash’s unique challenges through careful bootloader design, robust error handling, and thorough verification, the system achieves reliable and efficient booting. This approach enables cost-effective, high-performance embedded solutions for a range of applications, demonstrating the synergy between the S3C2440 and VxWorks.\n","date":"2025-08-05","externalUrl":null,"permalink":"/bsp/design-and-implementation-of-vxworks-nandflash-boot-on-s3c2440/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThe S3C2440, a 32-bit RISC microcontroller based on the ARM920T core, is widely used in embedded systems due to its performance and versatility. VxWorks, a real-time operating system (RTOS), is favored in embedded applications for its deterministic behavior and robust feature set. Implementing a boot mechanism for VxWorks using NandFlash memory on the S3C2440 presents unique challenges and opportunities, as NandFlash offers high storage capacity but requires careful management due to its complex read/write characteristics. This article explores the design, implementation, and verification of a NandFlash-based boot system for VxWorks on the S3C2440, highlighting key technical considerations and practical applications.\u003c/p\u003e","title":"Design and Implementation of VxWorks NandFlash Boot on S3C2440","type":"bsp"},{"content":" A Comparative Analysis of BSP Development: VxWorks vs. Linux\nAs embedded systems evolve with increasing complexity, real-time demands, and heterogeneous hardware, the choice of operating system becomes crucial—especially when dealing with low-level integration like Board Support Package (BSP) development. This article presents a detailed comparison between two dominant platforms in the embedded space: VxWorks, a commercial real-time operating system (RTOS), and Linux, the most popular open-source OS.\nBy examining the structure and methodology of BSP development in both systems, we uncover key architectural differences, development workflows, and implications on system performance and maintainability.\nWhy Compare VxWorks and Linux? # Both VxWorks and Linux power a vast range of embedded systems—from industrial control units to automotive ECUs and network infrastructure devices. However, their philosophies diverge significantly:\nVxWorks is engineered for determinism, safety, and certification. It’s commonly used in aerospace, telecom, defense, and medical applications. Linux, especially embedded distributions like Yocto, OpenWrt, and Buildroot, prioritizes flexibility, scalability, and ecosystem integration, often seen in consumer electronics, routers, infotainment systems, and IoT devices. Understanding how BSP development differs between the two helps engineers choose the right platform for their product requirements.\nBSP Development in VxWorks # A VxWorks BSP (Board Support Package) serves as the interface between the operating system and the hardware platform. It typically includes:\nSystem Boot Components # Implemented in assembly and C, executed immediately upon power-on. Responsible for: CPU state configuration (mode, frequency, cache setup) Memory initialization (DRAM controller, address mapping) Peripheral clocks, interrupt controllers Delivered as BOOTROM, often integrated into the system image. ✅ Key Feature: Bootloader and runtime drivers share the same OS kernel, allowing for tight integration and simplified maintenance.\nDevice Drivers # Drivers in VxWorks are classified by function:\nCharacter Devices (e.g., UART, GPIO):\nFollow standard I/O interfaces (open(), read(), write(), ioctl()). Managed through the I/O system with customizable driver routines. Block Devices (e.g., Flash, SSD):\nInterfaced via the file system (DOSFS, HRFS). Require routines like blkRead(), blkWrite(), reset(), status(). Network Devices (e.g., Ethernet MACs):\nUse the END (Enhanced Network Driver) interface. Implement callbacks like start(), send(), pollReceive(), and ioctl(). 🔧 Optimization Tip: For real-time applications, some device drivers can be tightly coupled to application tasks to eliminate OS scheduling latency.\nBSP Development in Linux # Linux BSPs involve additional moving parts and complexity due to its separation of concerns:\nBootloader Layer # Linux relies on external bootloaders (e.g., U-Boot, Barebox, GRUB, LILO). Bootloader functions: Early hardware initialization (CPU, DRAM, UART, Ethernet) Fetching and loading the Linux kernel image into RAM Passing boot arguments to the kernel 📌 Bootloaders are modular and processor-specific, typically built separately from the OS kernel.\nLinux Kernel Device Drivers # Linux categorizes devices into:\nCharacter Devices (e.g., UART, watchdog):\nRepresented by /dev/ entries, accessed via standard file operations. Require open(), release(), read(), write(), and ioctl(). Block Devices (e.g., eMMC, SD cards):\nManaged via block_device_operations, handled by kernel block I/O layers. Interaction with user space is buffered and deferred by the Virtual File System (VFS). Network Devices:\nDefined using the net_device structure. Integrated with the Linux networking stack (TCP/IP, IPv6, bridging). Employ socket buffers (sk_buff) for packet transmission and reception. ⚙️ Driver Deployment Options:\nBuilt-in (compiled into the kernel) Loadable Kernel Modules (inserted via insmod/modprobe at runtime) Development Workflow Comparison # Feature VxWorks Linux Bootloader Integrated (BOOTROM) Separate (e.g., U-Boot) Device Tree Support Optional (Board-specific headers) Mandatory for ARM, RISC-V Kernel/User Separation No Yes (requires copy_to_user() / copy_from_user()) Build System Tornado / Workbench Make, KBuild, Yocto, Buildroot Driver Debugging Shell (-\u0026gt; prompt), WDB, ICE printk, GDB, ftrace, perf Footprint Small (typ. \u0026lt;2MB) Larger (compressed kernel ~1–4MB, rootfs required) Certification DO-178C, IEC 61508 supported Limited RT patches, hard to certify Licensing Proprietary GPL/LGPL (licensing implications for kernel modules) Performance and Maintainability # VxWorks drivers run in the same memory space as applications, enabling zero-copy data sharing. This results in lower latency but requires rigorous validation to avoid instability. Linux uses a protected memory model, improving stability and isolating faults but incurring context switch overhead during I/O operations. From a maintainability standpoint:\nLinux\u0026rsquo;s open ecosystem provides vast driver libraries, community patches, and SoC vendor SDKs. VxWorks offers long-term stability and well-defined APIs, essential for products with extended life cycles (e.g., avionics or medical devices). Real-World Application Use Cases # Domain VxWorks Linux Aerospace / Avionics ✔ (real-time certifiable) ✖ (complex to certify) Consumer Electronics ✖ (cost/licensing) ✔ (smart TVs, routers) Automotive (IVI/ADAS) ✔ (ISO 26262 RT variants) ✔ (via AGL, Yocto) Industrial Automation ✔ (determinism) ✔ (cost and vendor support) Networking / 5G ✔ (Wind River Studio) ✔ (DPU, open networking) Conclusion # Both VxWorks and Linux are highly capable platforms for embedded BSP development, but they serve different design philosophies:\nChoose VxWorks if you need deterministic timing, tight integration, and certification-ready features. Choose Linux if your project demands flexibility, cost-efficiency, broad hardware support, and access to a vibrant open-source ecosystem. Understanding their BSP architectures not only helps in faster development but also aids in long-term scalability and system robustness.\n","date":"2025-08-04","externalUrl":null,"permalink":"/bsp/a-comparative-analysis-of-bsp-development-vxworks-vs-linux/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eA Comparative Analysis of BSP Development: VxWorks vs. Linux\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eAs embedded systems evolve with increasing complexity, real-time demands, and heterogeneous hardware, the choice of operating system becomes crucial—especially when dealing with low-level integration like \u003cstrong\u003eBoard Support Package (BSP)\u003c/strong\u003e development. This article presents a detailed comparison between two dominant platforms in the embedded space: \u003cstrong\u003eVxWorks\u003c/strong\u003e, a commercial real-time operating system (RTOS), and \u003cstrong\u003eLinux\u003c/strong\u003e, the most popular open-source OS.\u003c/p\u003e","title":"A Comparative Analysis of BSP Development: VxWorks vs. Linux","type":"bsp"},{"content":"","date":"2025-08-04","externalUrl":null,"permalink":"/tags/embedded-os/","section":"Tags","summary":"","title":"Embedded OS","type":"tags"},{"content":" Abstract # The rapid development of software systems in modern avionics equipment poses serious challenges to existing mainstream avionics software architectures both in China and abroad. Thus, it is necessary to explore and design a next-generation architecture for avionics software. This paper analyzes the evolution of avionics software architectures, studies the latest software technologies in the computing industry, and proposes a technical approach and design scheme for the next-generation avionics software architecture. Performance comparisons with other architectures validate the effectiveness of the proposed solution.\nKeywords\nAvionics equipment; software architecture; embedded real-time operating system; virtualization; containers\nDevelopment and Current State of Avionics Software Architecture # Evolution of Avionics Software Architecture # Avionics software architecture has gone through three generations:\nFirst-generation: No OS, only a simple real-time monitor for booting, hardware initialization, and debugging. Applications were functionally modularized. Second-generation: Flat embedded OS (e.g., VxWorks 5.5, Tianmai 1). Provided hardware isolation and real-time multitasking, simplifying development. Third-generation: Partitioned OSs (e.g., VxWorks 653 2.4, DeltaSVM, Tianmai 2) and middleware. Multiple applications run on one device with functional integration. Current Mainstream Architectures # Most new avionics systems use third-generation architecture: Partitioned OS + Middleware + Partitioned Applications, leveraging high-performance processors, high-speed buses, and static configuration. In systems like Vehicle Management Systems (VMS), middleware integrates traditional flight control with electromechanical management functions.\nIn avionics systems using Integrated Modular Avionics (IMA), all avionics applications are consolidated on Integrated Center Processors (ICPs) using ARINC 653-compliant partitioned OSs and middleware.\nArchitectural Challenges in Future Avionics # Modern warfare\u0026rsquo;s information-centric, autonomous, and networked nature demands smart, integrated, and networked electronics. Technologies like cloud computing, AI, and big data are being introduced into avionics. While multicore processors improve hardware performance, software functionality and complexity are exploding. Current architectures face several issues:\nLow hardware resource utilization: Partitioned OSs use static configurations. Unused resources are wasted. High configuration complexity: As software functions increase, defining and allocating fixed resources for each application becomes geometrically harder. Limited reconfigurability: Current architectures bind applications tightly to fixed partitions, hindering flexible reconfiguration. Trends in International Avionics Architectures # To address these challenges, major vendors have adopted virtualization:\nWindRiver\u0026rsquo;s VxWorks 653 3.0/3.1 uses virtualization to run multiple guest OSs (e.g., CretOS for ARINC653, POSIX-based Linux). DDCI DeOS and GreenHills Integrity-178 have also introduced virtualized, multicore-supporting versions for civil and military use. Designing the Next-Generation Architecture # Architecture Concept # In commercial computing, similar problems are tackled using virtualization:\nVirtual Machines (hard virtualization): Simulate multiple OS environments on one physical machine. Containers (soft virtualization): Provide lightweight, isolated user-space environments that behave like separate systems but share the host OS kernel. Compared to VMs, containers eliminate hypervisors and redundant OS layers, improving performance and reducing resource usage (2× better performance, ¼ the resource usage). Since avionics systems don\u0026rsquo;t require multiple OSs, containerization aligns better with avionics needs.\nSystem Composition and Runtime # The container-based avionics platform includes an embedded OS with container engine, middleware, and multiple application containers:\nContainers are type-specific: development/debugging containers for profiling, production containers with strict resource limits, or dynamic containers for low-security apps. The container engine allocates resources and instantiates container images based on configuration, then loads applications into them for execution. Technical Feasibility # Though mainstream container tools target Linux/Windows and adapting them for real-time embedded use is difficult, Chinese vendors have already developed soft-virtualization in avionics systems.\nGiven widespread adoption of domestic avionics OSs and deep expertise in the field, there\u0026rsquo;s strong potential for adapting containers into embedded real-time environments with supporting toolchains and middleware.\nImplementation \u0026amp; Performance Comparison # Based on DeltaSVM, a prototype implementation of the new architecture (DeltaSVM-C) was created. Tests were conducted using three architectures on the same hardware:\nStandard partitioned OS (DeltaSVM) Virtual Machine-based system using DaOS 8 with real-time VMs running DeltaSVM Container-based architecture with DeltaSVM-C Test system: Intel i5-2500k (4-core, 3.3GHz, VT enabled, 4GB DDR3). Software was memory-resident.\nMetrics tested:\nInterrupt response time Partition/container/VM switching time Memory usage Results Summary:\nMetric Partitioned OS Virtual Machine Container Avg. Interrupt Time Low High Moderate Partition Switch Time Low High Moderate Memory Usage Baseline +300–600% +50% Containers perform nearly as well as traditional RTOS partitions and far outperform virtualization. Their memory overhead is significantly lower than virtual machines while maintaining reasonable real-time performance.\nConclusion # The proposed container-based avionics software architecture meets future system demands and offers several advantages over third-generation architectures:\nHigher resource utilization: Static app configurations within dynamically managed containers enable efficient resource sharing and instantiation. Simplified configuration and integration: Resource profiling containers and toolchain automation reduce the complexity of large system integration. Flexible reconfigurability: Containers support controlled resource allocation and dynamic replacement or restart—offering both determinism and adaptability. *(This article is from Journal of Nanjing University of Aeronautics and Astronautics by Zhang Junhong and Tong Qiang, affiliated with AVIC First Aircraft Institute and Beijing Huazhixin Technology. Shared for educational purposes. Contact us for copyright.)\n","date":"2025-08-04","externalUrl":null,"permalink":"/industries/next-gen-avionics-software-design-based-on-software-virtualization/","section":"Industries","summary":"\u003ch2 class=\"relative group\"\u003eAbstract \n    \u003cdiv id=\"abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThe rapid development of software systems in modern avionics equipment poses serious challenges to existing mainstream avionics software architectures both in China and abroad. Thus, it is necessary to explore and design a next-generation architecture for avionics software. This paper analyzes the evolution of avionics software architectures, studies the latest software technologies in the computing industry, and proposes a technical approach and design scheme for the next-generation avionics software architecture. Performance comparisons with other architectures validate the effectiveness of the proposed solution.\u003c/p\u003e","title":"Next Generation Avionics Software Design Based on Software Virtualization","type":"industries"},{"content":"","date":"2025-08-04","externalUrl":null,"permalink":"/tags/software-architecture/","section":"Tags","summary":"","title":"Software Architecture","type":"tags"},{"content":"","date":"2025-07-29","externalUrl":null,"permalink":"/tags/elxr/","section":"Tags","summary":"","title":"ELxr®","type":"tags"},{"content":"As artificial intelligence dominates headlines, success in industrial automation requires a broader, more holistic approach. From managing distributed, heterogeneous edge environments to closing talent gaps and meeting security demands, the key to transformation lies beyond AI alone.\nWind River experts offer a clear path forward — one that unlocks innovation at the industrial edge.\n1. Securing the Distributed Edge # As computing shifts closer to the source of data — on factory floors, oil rigs, or wind turbines — new security risks emerge. Traditional IT security practices, designed for centralized, high-bandwidth environments, fall short in edge deployments that are offline, distributed, physically exposed, and sometimes unattended.\nTo address this, many organizations are adopting defense-in-depth strategies:\nZero Trust architectures: Enforce strict security using secure boot, TPMs, and root-of-trust hardware. Every connection is untrusted by default and subject to least-privilege access. Immutable infrastructure with signed updates: Prevent configuration drift and tampering by deploying non-modifiable base images. End-to-end encryption: Protect sensitive data with TLS for data in transit and LUKS for data at rest. Identity and access management (IAM): Robust controls ensure only authorized users and systems can interact with edge assets. 2. Scaling Risk \u0026amp; Compliance Management # In large-scale industrial systems, managing thousands of edge devices brings complexity. Devices often run different software versions, collect sensitive data, and operate under varying regulations — making security consistency and auditability a challenge.\nTo simplify compliance at scale, organizations are implementing:\nInfrastructure as Code (IaC) and GitOps: Automate configuration and policy enforcement across environments. Automated compliance monitoring and reporting: Detect and remediate drift in real time. Open frameworks and standards: Use initiatives like LF Edge and LF Energy to ensure interoperability and avoid vendor lock-in. By embedding security and compliance into the platform layer, enterprises can drive innovation while minimizing risk.\n3. Applying AI \u0026amp; ML Effectively # AI is undeniably powerful. In industrial use cases, it’s driving predictive maintenance, real-time quality control, and energy optimization.\nBut delivering AI value at the edge is hard. Challenges include fragmented, low-quality data, limited compute capacity, and inconsistent environments. Deploying large models at the edge means balancing latency, energy use, and cost — all of which can impact ROI.\nTo succeed, organizations must focus on:\nData access and governance: Define clear policies and integrate OT systems (SCADA, PLCs) with IT platforms. Efficient AI methods: Use techniques like semi-supervised learning, synthetic data, and transfer learning — and know when to apply them. Secure, updatable models: Ensure models can be audited, validated, and patched quickly. Continuous improvement: Retrain models centrally to improve accuracy over time. Optimized edge inference: Deploy lightweight, accelerated models (e.g., GPU-powered) at the edge, while offloading heavy training to centralized data centers. As AI scales from pilot projects to production, organizations must focus on tangible results and clear business cases to prove ROI.\n4. Bridging the Talent Gap # Technology doesn’t create value — people do.\nAs IT and OT converge, employees must develop cross-domain skills and embrace technologies like AI, cloud, and automation.\nTo drive adoption and value, organizations must:\nInvest in training for IT and OT teams Embed change management practices to overcome resistance and support new workflows Redefine roles — shifting from “control participants” to “supervisory orchestrators” who oversee autonomous systems with human judgment Without a strong human strategy, even the best technology will stall.\n5. Enter eLxr®: Enabling Industrial Innovation at the Edge # We’re at a pivotal moment in industrial edge transformation. With the right tools, organizations can embrace cloud-native orchestration, security-by-design, and human-centric operations — all while managing massive complexity.\nWind River enables this future through the eLxr® portfolio.\neLxr® Pro, a commercial-grade Debian® Linux, connects and manages heterogeneous edge workloads with flexibility and scale. Partnering with companies like Avassa, it supports orchestration of both containers and VMs across diverse edge environments.\nIn collaboration with Zededa and NVIDIA, eLxr® Pro also addresses real-world AI challenges — from model development and deployment to secure, zero-touch management across rugged edge locations.\nSecurity is core to Wind River’s DNA. With eLxr® Pro, enterprises can deploy hardened, minimal OS builds, enable over-the-air (OTA) updates, and monitor compliance with global standards — including NIST, GDPR, and the upcoming EU Cyber Resilience Act.\nBeyond the platform, Wind River delivers professional services to bridge the human gap — from consulting hours to training and security workshops that boost technical proficiency.\nThe Future Is Intelligent, Secure, and Human-Centered # As the industrial automation market continues to expand, the winners will be organizations that align technology, processes, and people.\nWith solutions like eLxr® Pro, industrial leaders aren’t just modernizing operations — they’re building resilient, intelligent ecosystems centered on long-term innovation and human impact.\nAbout Wind River # Wind River is a global leader in intelligent edge software. For over four decades, it has supported mission-critical systems that demand the highest levels of security, safety, and reliability. From aerospace and automotive to industrial, medical, and telecom sectors, Wind River accelerates digital transformation through a robust product portfolio, world-class support, and a trusted partner network.\n","date":"2025-07-29","externalUrl":null,"permalink":"/industries/enterprises-need-critical-capabilities-beyond-just-ai/","section":"Industries","summary":"\u003cp\u003eAs artificial intelligence dominates headlines, success in industrial automation requires a broader, more holistic approach. From managing distributed, heterogeneous edge environments to closing talent gaps and meeting security demands, the key to transformation lies beyond AI alone.\u003c/p\u003e","title":"Enterprises Need Critical Capabilities Beyond Just AI","type":"industries"},{"content":"","date":"2025-07-25","externalUrl":null,"permalink":"/tags/ftp-server/","section":"Tags","summary":"","title":"FTP Server","type":"tags"},{"content":"VxWorks, the real-time operating system from Wind River, is well-known for its reliability in embedded systems. One practical feature it supports is an FTP server, which enables efficient file transfers between a VxWorks target and a host machine. This guide walks through setting up and configuring an FTP server on VxWorks, with notes on compatibility, troubleshooting, and security.\nPrerequisites # Before you begin:\nVxWorks development setup (e.g., VxWorks 7 SDK or legacy versions like 5.5.1) A target image with networking support enabled An FTP client on your host (e.g., FileZilla, ws_ftp) Familiarity with VxWorks Workbench or Tornado Step 1: Add FTP Server Components to the Image # Open your VxWorks development IDE (Workbench or Tornado). Configure your VIP (VxWorks Image Project): Add: network components → networking protocols → network filesystem → ftp server Rebuild your VSB (VxWorks Source Build) and VIP to include the FTP server. Deploy the new image to your target (e.g., QEMU, i.MX6 SabreLite). Not all FTP clients work smoothly with VxWorks; FileZilla and ws_ftp are recommended for compatibility.\nStep 2: Configure the FTP Server # Set the FTP root directory:\nUse the symbol FTPS_ROOT_DIR to specify the accessible directory. For instance: #define FTPS_ROOT_DIR \u0026#34;/ata0b\u0026#34; // Maps to the second partition To serve multiple paths (e.g., ata0a, ata0b), ensure your image mounts both. Start the FTP server:\nIf configured to start automatically, it launches on boot. Otherwise, use: ftpServerStart(); Configure credentials:\nDefaults are often: Username: target Password: vxTarget Customize for better security (if supported by your version). Step 3: Access the FTP Server from a Host # Install an FTP client on your host (e.g., FileZilla).\nConnect using:\nHost: \u0026lt;VxWorks_Target_IP\u0026gt; Port: 21 Username/Password: target/vxTarget Browse and transfer files:\nYou can now upload, download, or even load applications like hello.vxe from the target. Step 4: Access Host FTP Server from VxWorks # Host-side FTP server setup (Linux example):\nsudo pip install pyftpdlib python -m pyftpdlib -u target -p vxTarget -d $HOME From VxWorks shell, mount the remote server:\nnetDevCreate(\u0026#34;wrs:\u0026#34;, \u0026#34;192.168.1.100\u0026#34;, 1); // Replace with your host IP cd \u0026#34;wrs:/home/your_user\u0026#34; Access remote files like:\nsp \u0026#34;hello.vxe\u0026#34; Optional: Use ftpLib for Programmatic File Transfers # For embedded apps needing file transfers:\n#include \u0026#34;ftpLib.h\u0026#34; int ctrlSock, dataSock; ftpXfer(\u0026#34;192.168.1.100\u0026#34;, \u0026#34;target\u0026#34;, \u0026#34;vxTarget\u0026#34;, \u0026#34;\u0026#34;, \u0026#34;RETR %s\u0026#34;, \u0026#34;\u0026#34;, \u0026#34;data.txt\u0026#34;, \u0026amp;ctrlSock, \u0026amp;dataSock); Suggested snapshot: Terminal output showing successful file transfer using ftpXfer.\nTroubleshooting Tips # Can\u0026rsquo;t connect? Check port 21, firewalls, or DHCP-assigned IPs. Large file failures? Try smaller files or switch to FileZilla Server on the host. Command errors? Use ftpCommand() return codes for insight. Security Considerations # Avoid default credentials in production. No built-in FTPS/SFTP: consider firewalls and limiting external access. Disable FTP when idle to reduce attack surface. Summary # Setting up FTP on VxWorks can streamline file operations for embedded systems. With correct configuration and security hygiene, you can:\nShare files between host and target efficiently Automate transfers with ftpLib Access remote data on demand For more details, check:\nVxWorks Network Programmer’s Guide (Chapter 8) ftpLib API documentation ","date":"2025-07-25","externalUrl":null,"permalink":"/app/setting-up-and-configuring-an-ftp-server-on-vxworks-7/","section":"Apps","summary":"\u003cp\u003e\u003cstrong\u003eVxWorks\u003c/strong\u003e, the real-time operating system from Wind River, is well-known for its reliability in embedded systems. One practical feature it supports is an FTP server, which enables efficient file transfers between a VxWorks target and a host machine. This guide walks through setting up and configuring an FTP server on \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e, with notes on compatibility, troubleshooting, and security.\u003c/p\u003e","title":"Setting Up and Configuring an FTP Server on VxWorks 7","type":"app"},{"content":"In embedded systems development, platform independence and hardware abstraction are increasingly important. VxWorks 7.0 introduces support for the Device Tree (DT) mechanism, significantly improving driver portability and system configuration flexibility. This article explains how to develop drivers based on Device Tree in VxWorks 7.0, helping developers support diverse hardware platforms more efficiently.\n1. What is Device Tree? # The Device Tree (DT) is a hardware description format that uses .dts source files to define system hardware such as peripheral addresses, interrupts, clocks, and GPIO mappings. VxWorks uses the compiled binary form .dtb during boot to dynamically parse the hardware structure and build the system device model.\n2. Role of Device Tree in VxWorks # In VxWorks 7.0, the device tree primarily serves to:\nDescribe peripheral information: e.g., I2C, SPI, UART, and GPIO controllers; Replace hard-coded hardware parameters: such as fixed addresses or register definitions in drivers or BSPs; Support the VxBus device model: using APIs like vxbFdtDevCreate() and vxbDevRegister() to bind DT nodes to drivers. 3. Overview of the Driver Development Process # We\u0026rsquo;ll now use a GPIO controller and device as an example to demonstrate the driver development process based on Device Tree in VxWorks.\n4. GPIO Controller \u0026amp; Device Example # 4.1 Writing the Device Tree Node # Assume we have an integrated GPIO controller and a connected LED. The .dts configuration might look like this:\ngpio@ff0a0000 { compatible = \u0026#34;xlnx,zynq-gpio-1.0\u0026#34;; reg = \u0026lt;0xff0a0000 0x1000\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; interrupts = \u0026lt;0 45 4\u0026gt;; interrupt-controller; #interrupt-cells = \u0026lt;2\u0026gt;; status = \u0026#34;okay\u0026#34;; }; led@0 { compatible = \u0026#34;mycompany,gpio-led\u0026#34;; gpios = \u0026lt;\u0026amp;gpio 12 0\u0026gt;; // GPIO12, active high label = \u0026#34;status-led\u0026#34;; }; 4.2 Matching the Device in the Driver # In the GPIO LED driver, define a compatible match:\nLOCAL const VXB_FDT_DEV_MATCH_ENTRY gpioLedMatch[] = { { .compatible = \u0026#34;mycompany,gpio-led\u0026#34; }, { NULL } }; LOCAL STATUS gpioLedProbe(VXB_DEV_HANDLE pDev) { if (vxbFdtDevMatch(pDev, gpioLedMatch) == NULL) return ERROR; return OK; } 4.3 Extracting Device Tree Properties # Retrieve the gpios property (controller + pin + flags):\nVXB_DEV_HANDLE pDev = ...; VXB_FDT_DEV * pFdtDev = vxbFdtDevGet(pDev); VXB_DEV_HANDLE gpioCtrl; UINT32 pin, flags; vxbFdtDevGetGpios(pDev, \u0026#34;gpios\u0026#34;, 0, \u0026amp;gpioCtrl, \u0026amp;pin, \u0026amp;flags); vxbGpioModeSet(gpioCtrl, pin, GPIO_DIR_OUTPUT); vxbGpioWrite(gpioCtrl, pin, 1); // Turn on LED 4.4 Registering the Driver # VXB_DRV_DEF gpioLedDrv = { .name = \u0026#34;gpioLed\u0026#34;, .probe = gpioLedProbe, .attach = gpioLedAttach, .devMatch = gpioLedMatch, }; VXB_DRV_DEF_INSTALL(gpioLedDrv) VxBus will automatically invoke this driver during system initialization based on the DT bindings.\n5. Debugging and Verification # Use vxbFdtShow() to view parsed device tree info; Use devs, gpioShow, or other commands to confirm driver is loaded; Add log output in attach() to verify pin and label values. 6. Summary and Best Practices # Device Tree-based driver development significantly enhances code maintainability and reusability. Recommended practices include:\nConsolidate all hardware configurations in the .dts file; Use standard compatible strings to support multiple devices; Leverage vxbFdtDevGet*() APIs to read DT properties cleanly; Reuse existing VxBus controller drivers (e.g., GPIO controller) whenever possible. By adopting the Device Tree mechanism in VxWorks 7.0, driver development becomes more modular and platform-independent. This approach is especially effective for edge AI, industrial automation, and communication systems—where hardware abstraction and rapid deployment are key.\n","date":"2025-07-25","externalUrl":null,"permalink":"/bsp/device-tree-based-driver-development-in-vxworks-7.0/","section":"Bsps","summary":"\u003cp\u003eIn embedded systems development, \u003cstrong\u003eplatform independence\u003c/strong\u003e and \u003cstrong\u003ehardware abstraction\u003c/strong\u003e are increasingly important. VxWorks 7.0 introduces support for the Device Tree (DT) mechanism, significantly improving driver portability and system configuration flexibility. This article explains how to develop drivers based on Device Tree in VxWorks 7.0, helping developers support diverse hardware platforms more efficiently.\u003c/p\u003e","title":"Device Tree-Based Driver Development in VxWorks 7.0","type":"bsp"},{"content":"","date":"2025-07-25","externalUrl":null,"permalink":"/tags/gpio/","section":"Tags","summary":"","title":"GPIO","type":"tags"},{"content":"This talk explores SDV and ADAS and outlines the path forward—highlighting emerging enablers such as cooperative driving, cellular vehicle-to-everything (C-V2X), and cloud-native vehicle (CNV) architectures. These advancements point toward a future where vehicles act as dynamic, connected computing platforms within a broader mobility ecosystem.\n","date":"2025-07-24","externalUrl":null,"permalink":"/video/adas-in-a-modern-vehicle/","section":"Videoes","summary":"\u003cp\u003eThis talk explores SDV and ADAS and outlines the path forward—highlighting emerging enablers such as cooperative driving, cellular vehicle-to-everything (C-V2X), and cloud-native vehicle (CNV) architectures. These advancements point toward a future where vehicles act as dynamic, connected computing platforms within a broader mobility ecosystem.\u003c/p\u003e","title":"ADAS in a Modern Vehicle","type":"video"},{"content":"","date":"2025-07-24","externalUrl":null,"permalink":"/tags/c-v2x/","section":"Tags","summary":"","title":"C-V2X","type":"tags"},{"content":"","date":"2025-07-24","externalUrl":null,"permalink":"/tags/modern-vehicle/","section":"Tags","summary":"","title":"Modern Vehicle","type":"tags"},{"content":"Andrei Kholodnyi, Wind River’s principal technologist, spoke at the recent Embedded Computing Conference about the future of software-defined vehicles (SDVs). This recording is an opportunity to hear about the subject from a technical expert – in the depth you’ve been yearning for.\n","date":"2025-07-24","externalUrl":null,"permalink":"/video/defining-the-software-defined-vehicle/","section":"Videoes","summary":"\u003cp\u003eAndrei Kholodnyi, Wind River’s principal technologist, spoke at the recent Embedded Computing Conference about the future of software-defined vehicles (SDVs). This recording is an opportunity to hear about the subject from a technical expert – in the depth you’ve been yearning for.\u003c/p\u003e","title":"Defining the Software Defined Vehicle","type":"video"},{"content":"","date":"2025-07-24","externalUrl":null,"permalink":"/tags/embedded-computing-conference/","section":"Tags","summary":"","title":"Embedded Computing Conference","type":"tags"},{"content":"","date":"2025-07-18","externalUrl":null,"permalink":"/tags/ml403/","section":"Tags","summary":"","title":"ML403","type":"tags"},{"content":"","date":"2025-07-18","externalUrl":null,"permalink":"/tags/vxworks-6.x/","section":"Tags","summary":"","title":"VxWorks 6.x","type":"tags"},{"content":" Overview # Xilinx\u0026rsquo;s Application Note XAPP947 provides a comprehensive walkthrough for running Wind River VxWorks 6.x on the ML403 Embedded Development Platform. This blog summarizes the key steps in setting up the VxWorks environment, configuring a board support package (BSP), building a kernel image, and programming a bootloader into flash memory. While based on VxWorks 6.x and Xilinx\u0026rsquo;s legacy tools, the insights remain useful for modern BSP developers working with PowerPC targets and FPGA-based systems.\nHardware and Software Requirements # To follow the original setup, the following tools and components are used:\nXilinx ML403 Evaluation Board (Virtex-4 FX with PPC405) Xilinx Platform Studio (XPS) 10.1i and ISE 10.1i Wind River Workbench 2.5 Wind River ICE/Probe (with JTAG adapter) RS232 cable, Ethernet cable, and terminal software (e.g., HyperTerminal) Flash memory programming utilities A license for Wind River multi-core debugging Step 1: Build the Base System in XPS # The ML403 system is built using Xilinx\u0026rsquo;s Base System Builder. Key peripherals included:\nPowerPC 405 processor DDR SDRAM (via MPMC) GPIO (LEDs, push buttons) UART 16550 TriMode Ethernet MAC (TEMAC) Flash interface (XPS MCH EMC) On-chip BRAM for boot An address map is defined for all peripherals, and the bitstream is generated using XPS.\nStep 2: Create and Modify the VxWorks BSP # Using XPS:\nSet OS to vxworks6_3 in the Software Platform Settings.\nConfigure STDIN/STDOUT to use RS232 UART.\nInclude UART and Ethernet MAC in the \u0026ldquo;connected peripherals\u0026rdquo; list.\nGenerate the BSP and copy it to a new directory (modified_vxworks_bsp).\nEdit config.h and Makefile to match the platform\u0026rsquo;s memory map:\nROM_BASE_ADRS = 0xFF000000 ROM_TEXT_ADRS = ROM_BASE_ADRS + 0x100 RAM_LOW_ADRS = 0x00010000 RAM_HIGH_ADRS = 0x00C00000 Update the MAC address in sysNet.c and optionally customize the model string in sysLib.c.\nStep 3: Build the VxWorks Kernel Image # In Wind River Workbench:\nCreate a new \u0026ldquo;VxWorks Image Project\u0026rdquo; using the modified BSP. Set toolchain to sfgnu or sfdiab. Configure kernel components (e.g., WDB agent, kernel shell). Build the project to produce the vxWorks kernel image. Download the bitstream to the ML403 using XPS. Use the Wind River Probe to connect via JTAG and download the image. Step 4: Create and Program the Bootloader # In Workbench, create a new \u0026ldquo;VxWorks Boot Loader Project\u0026rdquo; using the same BSP. Use uncompressed image format and output as BIN file. Build the bootloader (bootrom_uncmp.bin). Use the On-Chip Debug (OCD) Flash Programmer in Workbench: Flash base address: 0xFF000000 File address offset: 0xFF000100 Flash device: Intel 28F320Jx (2 devices) Program the bootloader into flash and verify success.\nStep 5: Configure and Test Standalone Boot # A small application (VxWorks_Start) runs from BRAM and branches to the bootloader in flash:\nSet the flash address in code to 0xFF000100. Update the bitstream to include this BRAM-based application. Program the FPGA with this bitstream using iMPACT. Switch board to boot from flash. Power up and watch for the VxWorks boot prompt. Step 6: Boot and Load the VxWorks Kernel # Set up an FTP server on the host PC (e.g., IP: 192.168.0.1). Target board uses IP 192.168.0.2. Place the vxWorks image in the FTP directory. From the bootloader prompt: Press p to print settings. Press c to configure (user/pass: my_ftp_user / pass). Press @ to boot and load kernel via FTP. You can verify kernel status using i (task list) and version commands in the shell.\nConclusion # XAPP947 provides a hands-on foundation for VxWorks developers working on FPGA platforms, particularly those targeting PowerPC processors and flash-bootable systems. While VxWorks 6.x and the ML403 board are dated, the workflow for customizing BSPs, building kernel images, and deploying bootloaders remains highly relevant — especially for developers working with Wind River tools on embedded targets today.\nReferences # XAPP947 PDF ML403 Evaluation Platform Manual (UG080) Getting Started with VxWorks and EDK (XAPP548) ","date":"2025-07-18","externalUrl":null,"permalink":"/bsp/vxworks-6.x-on-the-ml403-embedded-development-platform/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003eOverview \n    \u003cdiv id=\"overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eXilinx\u0026rsquo;s Application Note XAPP947 provides a comprehensive walkthrough for running Wind River \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks 6.x\u003c/a\u003e on the ML403 Embedded Development Platform. This blog summarizes the key steps in setting up the VxWorks environment, configuring a board support package (BSP), building a kernel image, and programming a bootloader into flash memory. While based on VxWorks 6.x and Xilinx\u0026rsquo;s legacy tools, the insights remain useful for modern BSP developers working with PowerPC targets and FPGA-based systems.\u003c/p\u003e","title":"VxWorks 6.x on the ML403 Embedded Development Platform","type":"bsp"},{"content":"","date":"2025-07-18","externalUrl":null,"permalink":"/tags/xilinx/","section":"Tags","summary":"","title":"Xilinx","type":"tags"},{"content":"","date":"2025-07-16","externalUrl":null,"permalink":"/tags/virtualized-workloads/","section":"Tags","summary":"","title":"Virtualized Workloads","type":"tags"},{"content":"","date":"2025-07-16","externalUrl":null,"permalink":"/tags/vmware-vsphere/","section":"Tags","summary":"","title":"VMware VSphere","type":"tags"},{"content":"","date":"2025-07-16","externalUrl":null,"permalink":"/tags/wind-river-cloud/","section":"Tags","summary":"","title":"Wind River Cloud","type":"tags"},{"content":"Wind River® helps enterprises smoothly migrate virtual machine and container workloads from VMware vSphere to the Wind River Cloud Platform. This platform integrates OpenStack and Kubernetes, enabling both types of workloads to run in a single, unified environment.\nWith its unique automation capabilities, Wind River continuously supports many enterprises in seamlessly migrating virtual machines (VMs) and container workloads from VMware in complex and demanding cloud network environments. The Wind River Cloud Platform is designed to be open, flexible, and cost-effective, providing enterprises with the tools needed to deploy and manage private cloud infrastructure globally—effectively supporting both operational technology (OT) and information technology (IT) workloads across geographically distributed networks.\nThe entire migration process is designed to minimize business disruption and help enterprises achieve value quickly. The platform allows VM migration during scheduled maintenance windows, and even supports live migration with minimal downtime, providing the flexibility needed to meet diverse business requirements.\nWind River’s professional services team offers full support for complex migration projects, delivering end-to-end migration solutions that ensure efficient infrastructure deployment, smooth workload transition, and reliable Day 2 Operations. Throughout the process, the Wind River Cloud Platform tools, expert support, and professional services work together to help enterprises achieve migration goals with confidence.\nWind River has years of experience offering OpenStack-based solutions and has continued to evolve its architecture—now seamlessly integrating Kubernetes into a unified technology stack. This modernized platform is powered by StarlingX, an open-source project designed for edge and cloud-native deployments.\nWith its integrated platform, automated orchestration, and built-in analytics, enterprises can optimize their private cloud environments while ensuring low-latency performance for edge and near-edge use cases. Whether migrating from traditional VM workloads or enhancing existing private cloud operations, the Wind River Cloud Platform delivers the reliability, flexibility, and cost-efficiency enterprises need.\nLooking for VMware alternatives? Visit the Wind River site:\nhttps://www.windriver.com/studio/vmware/\nAbout Wind River\nWind River is a global leader in intelligent edge software. For over 40 years, the company has been pioneering innovation to support billions of devices and systems that require the highest levels of safety, security, and reliability. Wind River\u0026rsquo;s software and expertise are accelerating digital transformation across industries such as automotive, aerospace, defense, industrial, medical, and telecommunications. The company offers a comprehensive product portfolio, world-class global professional services and support, and a broad partner ecosystem.\n","date":"2025-07-16","externalUrl":null,"permalink":"/news/wind-river-cloud-platform-helps-you-smoothly-migrate-virtualized-workloads/","section":"News","summary":"\u003cp\u003eWind River® helps enterprises smoothly migrate virtual machine and container workloads from VMware vSphere to the Wind River Cloud Platform. This platform integrates OpenStack and Kubernetes, enabling both types of workloads to run in a single, unified environment.\u003c/p\u003e","title":"Wind River Cloud Platform Helps You Smoothly Migrate Virtualized Workloads","type":"news"},{"content":"","date":"2025-07-12","externalUrl":null,"permalink":"/tags/edge-impulse/","section":"Tags","summary":"","title":"Edge Impulse","type":"tags"},{"content":"The Intelligent Edge: AI \u0026amp; Edge Solutions for Industrial Safety—Next-Gen Protection for Manufacturing Industrial accidents remain a serious challenge, causing injuries, operational disruptions, and financial losses. See how AI and Edge technologies from Wind River, ZEDEDA and Edge Impulse are transforming workplace safety.\n","date":"2025-07-12","externalUrl":null,"permalink":"/video/the-intelligent-edge-webinar-wind-river-zededa-and-edge-impulse/","section":"Videoes","summary":"\u003cp\u003eThe Intelligent Edge: AI \u0026amp; Edge Solutions for Industrial Safety—Next-Gen Protection for Manufacturing Industrial accidents remain a serious challenge, causing injuries, operational disruptions, and financial losses. See how AI and Edge technologies from Wind River, ZEDEDA and Edge Impulse are transforming workplace safety.\u003c/p\u003e","title":"The Intelligent Edge Webinar Wind River ZEDEDA and Edge Impulse","type":"video"},{"content":"","date":"2025-07-12","externalUrl":null,"permalink":"/tags/zededa/","section":"Tags","summary":"","title":"ZEDEDA","type":"tags"},{"content":" Software-Defined Vehicles: A Paradigm Shift # Today, there is a widespread consensus in the automotive industry: the core value of future vehicles is shifting from traditional mechanical performance and hardware configurations to software technologies powered by artificial intelligence. Competition around intelligent driving software is expanding on broader and deeper dimensions. This competition is critical because, in the era of Software-Defined Vehicles (SDVs), software is the primary source of value for users.\nA modern “digital” car can contain nearly 700 million lines of code. The core that supports such a vast software system is the underlying operating system. As Linux gradually becomes the mainstream OS in the field of automotive intelligent driving, its position in the industry is becoming increasingly prominent.\nLooking back, during the early development of Linux, the embedded market was led by VxWorks from Wind River. The coexistence of diverse hardware architectures such as ARM, StrongARM, and MIPS created space for Linux to grow and evolve from a \u0026ldquo;guerrilla\u0026rdquo; role into the mainstream. So, how did Linux achieve this transformation in automotive intelligent driving, and what critical thresholds did it have to cross?\nCore Requirements for Automotive OS in Smart Driving # Safety, Efficiency, Stability\nThe operating system plays a pivotal role in the intelligent vehicle ecosystem — managing vehicle resources internally and enabling external interaction; supporting application ecosystems above and coordinating hardware performance below. Its stability directly affects overall vehicle performance. In the smart driving domain, three key requirements stand out:\nEfficient Development Capabilities # The volume of code in intelligent vehicles is growing explosively — from around 100 million lines in 2015 to an estimated 700 million by 2025, a nearly 7x increase in just a decade. The demand for rapid development has reached a fever pitch.\nReliable Security # More code means a broader attack surface — every line of code is a potential vulnerability. Since early 2022, malicious attacks on vehicle network platforms have surpassed one million, prompting unprecedented demands for OS-level security.\nExceptional Stability # As the \u0026ldquo;central nervous system\u0026rdquo; of the vehicle, the OS must be rock-solid. Any instability could lead to serious consequences, jeopardizing safety and reliability.\nOnly by meeting these three criteria — efficiency, security, and stability — can an operating system be widely adopted and sustainably developed in the intelligent driving domain.\nLinux: Opportunities and Challenges # Strong advantages, but safety hurdles remain\nFaced with the demanding requirements of smart driving, Linux offers many natural advantages but also faces key challenges:\nFoundation for Efficient Development # Rich support for programming languages and development tools High flexibility in adapting to various platform interfaces A C-based kernel that adheres to Unix-standard APIs Naturally suited for embedded automotive control These attributes establish Linux as a robust foundation for fast development.\nEnsuring Stable Operation # A true multi-tasking, multi-user system that allows applications to share resources without interference Code optimized for standard 32-bit systems, delivering high stability and low crash risk Real Security Challenges # GPL License as a Double-Edged Sword: While it grants users great freedom (to run, modify, and distribute code), it may also introduce unstable or flawed code from the open-source community — which poses a challenge to meeting functional safety (FuSa) standards.\nMonolithic Kernel Limitations: Linux’s monolithic design brings challenges in hard real-time performance and long-term maintainability across various branches. Without deep customization, it is difficult to meet strict requirements for exposure, severity, and controllability under functional safety standards.\nHigh Customization Threshold: With around 25 million lines of kernel code, deep customization and trimming require strong technical expertise and significant resources, posing a barrier for typical smart driving development teams and increasing complexity in secure architecture design.\nRise of Open Source Power # The fusion of “Bazaar” and “Cathedral” models\nThe Linux community thrives on the open and collaborative “bazaar” model, driving innovation and adoption. However, sectors like automotive often need products with guaranteed quality, long-term support, and professional services — a “cathedral” style approach.\nThis need has given rise to companies that transform open-source “raw materials” into high-quality, domain-ready “finished products.” Wind River is a key force driving Linux toward mainstream use in embedded systems.\nUnlike the open \u0026ldquo;bazaar\u0026rdquo;, Wind River — with over 40 years of history — is renowned for robust and reliable products. Its early solutions supported critical infrastructure like nuclear power and were integral to NASA space missions via VxWorks. This deep-rooted focus on safety and reliability is Wind River’s core DNA.\nIn 2005, Wind River launched its first complete Linux platform (PNE), praised for integrating rich networking middleware and application components — a prime example of merging the bazaar\u0026rsquo;s innovation with the cathedral’s rigor.\nWind River Linux # A secure and reliable foundation for automotive smart driving\nTo address Linux’s safety challenges in automotive applications, Wind River offers powerful solutions backed by decades of embedded system expertise and robust process control:\nDeep Customization and Hardening # Wind River is capable of deep customization and trimming of the Linux kernel, overcoming limitations in real-time performance and meeting stringent functional safety demands. Its rigorous process management helps avoid the instability issues sometimes found in community editions.\nFull Lifecycle Security (Wind River Studio Linux Services) # In the world of rapidly evolving automotive software, bug fixes and security maintenance are as critical as developing new features. Wind River’s Studio Linux Services provide essential support:\nCVE Lifecycle Management: Identification, prioritization, patching, and tracking Automated Tools: Wind River Studio Security Scanning can detect large numbers of CVEs (e.g., one customer identified 1,500+ CVEs, including over 80 high-risk issues) Ongoing Maintenance \u0026amp; Quality Assurance: Continuous security updates, daily builds, testing, and validation for OS platforms and BSPs Visualization \u0026amp; Reporting: Online dashboards provide visibility into patch progress, reducing technical debt and improving maintenance efficiency A global network equipment vendor once faced major delays in Linux platform maintenance, hampering software releases. Wind River stepped in with full-lifecycle security services, fixing critical vulnerabilities quickly and re-establishing a stable platform — freeing up their dev team to focus on innovation and lowering costs significantly.\nDriving the Future Through Ecosystem Collaboration # With Wind River Linux combining stability, performance, and security, its adoption in the automotive industry is accelerating. Leading domestic automakers such as Hozon Auto, Zeekr, and NETA have chosen Wind River Linux to develop their next-gen SDV platforms, E/E architectures, and intelligent domain controllers — clear endorsements of its value.\nEven more importantly, Wind River is expanding beyond the OS layer into the entire automotive software stack, covering key areas like High-Performance Computing (HPC), V2X, and Advanced Driver Assistance Systems (ADAS).\nMuch like the LAMP stack (Linux, Apache, MySQL, PHP/Python/Perl) revolutionized web infrastructure, Linux’s success in automotive will also depend on a strong platform and ecosystem. Wind River is playing a vital role in reducing the barriers and risks of adopting open-source technologies in critical domains through certified Linux distributions and expert services.\nBy helping Linux evolve from “guerrilla” to “mainstream army” in the automotive world, Wind River is laying the software foundation for the future of smart driving — a future driven by the synergy of platform and ecosystem.\nAbout Wind River # Wind River is a global leader in intelligent edge software. For over 40 years, it has continuously innovated to support billions of devices and systems demanding the highest levels of safety, security, and reliability. Wind River is accelerating digital transformation across automotive, aerospace, defense, industrial, medical, and telecom sectors. The company offers a comprehensive product portfolio backed by world-class services, support, and a global partner ecosystem.\nLearn more: www.windriver.com\n","date":"2025-07-05","externalUrl":null,"permalink":"/news/how-linux-drives-the-future-of-smart-driving/","section":"News","summary":"\u003ch2 class=\"relative group\"\u003eSoftware-Defined Vehicles: A Paradigm Shift \n    \u003cdiv id=\"software-defined-vehicles-a-paradigm-shift\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#software-defined-vehicles-a-paradigm-shift\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eToday, there is a widespread consensus in the automotive industry: the core value of future vehicles is shifting from traditional mechanical performance and hardware configurations to software technologies powered by artificial intelligence. Competition around intelligent driving software is expanding on broader and deeper dimensions. This competition is critical because, in the era of \u003cstrong\u003eSoftware-Defined Vehicles (SDVs)\u003c/strong\u003e, software is the primary source of value for users.\u003c/p\u003e","title":"How Linux Operating System Drives the Future of Smart Driving","type":"news"},{"content":"","date":"2025-07-05","externalUrl":null,"permalink":"/tags/smart-driving/","section":"Tags","summary":"","title":"Smart Driving","type":"tags"},{"content":"","date":"2025-06-22","externalUrl":null,"permalink":"/tags/deepx/","section":"Tags","summary":"","title":"DEEPX","type":"tags"},{"content":"DEEPX, a leading edge AI semiconductor company, has announced a collaboration with Wind River, a global leader in intelligent edge software, to jointly develop next-generation edge AI hardware and software solutions. This partnership integrates DEEPX’s on-device AI semiconductor technology with Wind River’s VxWorks® real-time operating system (RTOS) and Wind River® Helix™ virtualization platform. The goal is to deliver cutting-edge solutions for mission-critical industries such as aerospace, defense, industrial automation, and robotics.\n“The evolution of real-time physical AI presents enormous potential for mission-critical environments while also introducing new complexities. By combining DEEPX’s advanced AI semiconductors with Wind River’s proven edge technologies, we can drive impactful AI innovation across applications and industries.”\n— Avijit Sinha, SVP of Strategy and Global Business Development, Wind River\nEdge AI is creating immense opportunities across numerous industries. Leveraging Wind River’s deep software expertise in markets that demand high levels of functional safety, cybersecurity, reliability, and edge computing, DEEPX is able to offer innovative edge AI platforms that deliver excellent performance, cost-effectiveness, and energy efficiency.\n— Lokwon Kim, CEO of DEEPX\nBy enabling DEEPX’s Neural Processing Unit (NPU) on Wind River technologies, enterprises can easily add AI acceleration to their real-time or edge systems at lower costs. DEEPX and Wind River are committed to delivering pre-validated solution stacks that address security concerns, helping organizations significantly reduce complexity and shorten development cycles.\nAbout DEEPX # DEEPX is an innovative company in the field of on-device AI, dedicated to developing advanced AI semiconductors that optimize performance, reduce power consumption, and enhance cost efficiency. These semiconductors are widely used in smart camera modules, intelligent mobility, smart factories, consumer electronics, smart cities, surveillance systems, and AI servers. DEEPX\u0026rsquo;s state-of-the-art AI chips are designed for exceptional energy efficiency and seamless integration into a wide range of devices.\nAbout VxWorks and Helix Platform # VxWorks, the market-leading real-time operating system (RTOS), is a trusted solution with wide deployment in systems requiring the highest levels of safety and reliability. As the first commercial RTOS to support containers compliant with the Open Container Initiative (OCI) standard, VxWorks helps organizations rapidly deploy new software-defined features. The Helix Platform is a hypervisor-based solution that allows engineering teams to consolidate multiple systems into a single high-performance embedded platform, simplifying functional safety certification, reducing project risk, and accelerating time-to-market.\nAbout Wind River # Wind River is a global leader in intelligent edge software. For over 40 years, the company has been pioneering technologies that support billions of devices and systems requiring the highest levels of safety, security, and reliability. Wind River’s software and expertise are driving digital transformation across industries such as automotive, aerospace, defense, industrial, medical, and telecommunications. The company offers a comprehensive product portfolio, world-class global professional services and support, and a broad partner ecosystem.\nTo learn more, visit www.windriver.com.\nAbout DEEPX # As an innovative company in on-device AI, DEEPX develops advanced AI semiconductors optimized for performance, power efficiency, and cost. These chips are widely used across smart camera modules, intelligent transportation, smart manufacturing, consumer electronics, smart cities, surveillance systems, and AI servers. DEEPX’s cutting-edge chips are designed to deliver best-in-class energy efficiency and are easily integrable into various devices. With a strong portfolio of over 300 global patent applications and more than 70 granted patents, DEEPX holds world-class proprietary AI semiconductor technologies. The company has been featured in EE Times\u0026rsquo; “Silicon 100” list for two consecutive years and recognized by market research firm Frost \u0026amp; Sullivan as a leading company in the AI semiconductor space. DEEPX continues to strengthen its position in the global AI semiconductor market through innovation and technological leadership.\n","date":"2025-06-22","externalUrl":null,"permalink":"/news/deepx-and-wind-river-join-forces-to-advance-mission-critical-edge-ai-applications/","section":"News","summary":"\u003cp\u003e\u003cstrong\u003eDEEPX\u003c/strong\u003e, a leading edge AI semiconductor company, has announced a collaboration with \u003cstrong\u003eWind River\u003c/strong\u003e, a global leader in intelligent edge software, to jointly develop next-generation edge AI hardware and software solutions. This partnership integrates DEEPX’s on-device AI semiconductor technology with Wind River’s \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks®\u003c/a\u003e real-time operating system (RTOS) and Wind River® Helix™ virtualization platform. The goal is to deliver cutting-edge solutions for mission-critical industries such as aerospace, defense, industrial automation, and robotics.\u003c/p\u003e","title":"DEEPX and Wind River Join Forces to Advance Mission-Critical Edge AI Applications","type":"news"},{"content":"","date":"2025-06-22","externalUrl":null,"permalink":"/tags/mission-critical/","section":"Tags","summary":"","title":"Mission-Critical","type":"tags"},{"content":"","date":"2025-06-22","externalUrl":null,"permalink":"/tags/npu/","section":"Tags","summary":"","title":"NPU","type":"tags"},{"content":"","date":"2025-06-17","externalUrl":null,"permalink":"/tags/astroscale/","section":"Tags","summary":"","title":"Astroscale","type":"tags"},{"content":"","date":"2025-06-17","externalUrl":null,"permalink":"/tags/elsa-m/","section":"Tags","summary":"","title":"ELSA-M","type":"tags"},{"content":"Wind River VxWorks® Powers Astroscale’s Groundbreaking ELSA-M Space Debris Removal Mission\nALAMEDA, Calif. – Wind River®, a global leader in software for mission-critical intelligent systems, today announced that its real-time operating system, VxWorks®, is at the heart of Astroscale’s latest space sustainability initiative. The ELSA-M Servicer spacecraft, designed to capture and deorbit defunct satellites, relies on VxWorks in its On-Board Computer (OBC) for high-precision guidance and control.\nAstroscale is pioneering solutions to combat the escalating threat posed by space debris. Its ELSA-M (End-of-Life Services by Astroscale – Multiple) mission aims to safely capture and retire multiple non-functional satellites within a single flight—an essential step toward a more sustainable orbital environment.\n“Astroscale is tackling the critical challenge of space debris, and we’re proud to support their mission,” said Avijit Sinha, Chief Product Officer at Wind River. “Our cutting-edge technology underpins the world’s most demanding aerospace systems. VxWorks continues to be a trusted platform for precision, reliability, and performance in space.”\n“ELSA-M addresses the growing pressure on satellite operators to responsibly manage end-of-life disposal,” added Stephen Wokes, Director of Engineering at Astroscale Ltd. “Given the complexity of autonomous rendezvous and capture operations, it is vital to work with proven, dependable technology. VxWorks delivers the real-time performance required for our robotics and vision processing systems.”\nThe VxWorks-powered OBC plays a central role in orchestrating rendezvous maneuvers and robotic operations. Astroscale’s onboard software applications—running on VxWorks—handle advanced computer vision and control tasks essential to tracking, approaching, and capturing retired satellites.\nA landmark in-orbit demonstration (IOD) is scheduled for 2025, marking the first commercial active debris removal (ADR) mission to complete a full capture and deorbit sequence with a full-scale client satellite. This mission is part of Astroscale’s collaboration with OneWeb and the European Space Agency (ESA).\nProven Software for Space Innovation # For more than 30 years, Wind River’s software has powered critical systems in space, supporting some of the most ambitious missions in history. VxWorks offers unmatched deterministic performance and a robust, scalable architecture built for safety, security, and reliability—making it the platform of choice for mission-critical aerospace applications.\nAbout Wind River # Wind River is a global leader in software for mission-critical intelligent systems. For over four decades, Wind River has been at the forefront of innovation, powering billions of devices across industries such as aerospace, automotive, defense, industrial, medical, and telecommunications. The company delivers a comprehensive portfolio supported by global professional services, technical support, and a broad partner ecosystem. Learn more at www.windriver.com.\nAbout Astroscale # Astroscale is the first private company fully dedicated to on-orbit servicing across all orbital regimes. Founded in 2013, it is leading efforts to secure sustainable space operations for future generations. Astroscale is advancing technologies for life extension, in-space situational awareness, active debris removal, and end-of-life disposal. Headquartered in Japan, the company has subsidiaries in the UK, US, and Israel. Visit www.astroscale.com for more information.\nAbout ELSA-M # ELSA-M is the follow-up to Astroscale’s ELSA-d demonstration mission. It aims to prove the commercial viability of removing multiple defunct satellites using in-orbit rendezvous and magnetic capture. Developed and operated from Astroscale’s Zeus facility at the Harwell Science and Innovation Campus in the UK, ELSA-M is scheduled to launch in 2025. The mission is backed by the UK Space Agency, ESA, and OneWeb under the Sunrise Programme, a public-private partnership supporting innovative space sustainability initiatives.\n","date":"2025-06-17","externalUrl":null,"permalink":"/news/vxworks-serves-as-software-foundation-for-astroscale-sustainable-space-systems/","section":"News","summary":"\u003cp\u003eWind River VxWorks® Powers Astroscale’s Groundbreaking ELSA-M Space Debris Removal Mission\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eALAMEDA, Calif.\u003c/strong\u003e – Wind River®, a global leader in software for mission-critical intelligent systems, today announced that its real-time operating system, \u003cstrong\u003eVxWorks®\u003c/strong\u003e, is at the heart of Astroscale’s latest space sustainability initiative. The \u003cstrong\u003eELSA-M Servicer\u003c/strong\u003e spacecraft, designed to capture and deorbit defunct satellites, relies on VxWorks in its On-Board Computer (OBC) for high-precision guidance and control.\u003c/p\u003e","title":"VxWorks Powers Astroscale’s Groundbreaking ELSA-M Space Debris Removal Mission","type":"news"},{"content":"Using Device-Specific Parameters for Flexible Driver Configuration in VxWorks 7\nDevice-specific parameters offer a robust mechanism to fine-tune driver behavior for particular hardware configurations—without relying on hard-coded values. This guide illustrates how to implement this flexibility using a real-world example from a PCIe controller driver developed for the Renesas R-Car H3 SIP evaluation board.\nBackground # We developed a VxWorks 7 BSP for the Renesas R-Car H3, including drivers for key peripherals: serial, Ethernet, MMC, I2C, GPIO, and PCI Express. To validate the PCI Express driver, we inserted an Intel i210 PCIe card into the board’s slot, loaded the VxWorks 7 Intel gigabit Ethernet driver, and verified successful detection and integration into the network stack.\nThis BSP was shared across our development teams globally. Eventually, a problem surfaced: a PCIe-based CAN controller wasn’t initializing on boot. Investigation showed that the PCIe link between root complex and endpoint wasn’t forming in time.\nIdentifying the Issue # The issue stemmed from a hardcoded 1 ms timeout for link establishment in the PCIe driver. However, the CAN controller card needed up to 5 ms. Simply increasing the timeout would negatively affect boot time in cases where no PCIe peripherals were present.\nSolution: Device-Specific Parameters # Instead of a global timeout change, we made the timeout configurable per device through the device tree.\nStep 1: Define the Driver Parameter Table # We created a parameter table with a default value:\n/* R-Car H3 PCIe controller driver parameter table */ LOCAL VXB_PARAMS rcarH3PcieParams[] = { { DLLACT_TIMEOUT_PARAM, VXB_PARAM_INT32, { (void *)DLLACT_TIMEOUT_US } }, { NULL, VXB_PARAM_END_OF_LIST, { NULL } } }; Step 2: Declare the Parameter Table in the Driver Definition # Use the VXB_DRVFLAG_PARAM flag to declare the parameter table:\n/* R-Car H3 PCIe controller VxBus driver definition */ VXB_DRV vxbFdtRcarH3PcieDrv = { { NULL }, // list node RCAR_H3_PCIE_DRV_NAME, // Name \u0026#34;Renesas R-Car H3 PCIe driver\u0026#34;, // Description VXB_BUSID_FDT, // Class VXB_DRVFLAG_PARAM, // Flags 0, // Reference count rcarH3PcieMethodList, // Method table rcarH3PcieParams // Parameter defaults }; Step 3: Update Driver Initialization to Use the Parameter # Retrieve the parameter during initialization:\n/* Get the DLL activation timeout from the driver parameter table */ if (vxbParamGet (pDev, DLLACT_TIMEOUT_PARAM, VXB_PARAM_INT32, \u0026amp;param) == OK) { dllActTimeoutUs = (unsigned)param.int32Val; } else { PCIEC_DBG (PCIEC_DBG_ERR, \u0026#34;%s: pDev %p: Failed to get DLL timeout parameter - using default\\n\u0026#34;, __FUNCTION__, pDev); } The driver uses the default value unless overridden in the device tree.\nStep 4: Override with Device Tree Parameters # We added a devparam node to the chosen section of the device tree. This allows specific parameters to be set per device.\nExample Format (from VxWorks 7 documentation): # chosen { ... devparam { \u0026lt;devName\u0026gt;@\u0026lt;devUnit\u0026gt; { \u0026lt;parameter name\u0026gt; = \u0026lt;parameter value\u0026gt;; ... }; }; }; Example Override for R-Car H3 # To set a 5000 μs timeout:\nchosen { bootargs = \u0026#34;etherAvb(0,0) host:vxWorks h=192.168.0.2 e=192.168.0.20 u=target pw=vxTarget\u0026#34;; devparam { renesas,rcar-h3-pcie@0 { dllActTimeoutUs = \u0026lt;5000\u0026gt;; }; }; }; Debug Output When No Card Is Present # rcarH3PcieHwInit: pDev 0xffff80000011f980: PCIe DLL not ready after 5000us rcarH3PcieAttach: pDev 0xffff80000011f980: error exit This confirmed the timeout override was active and functional.\nConclusion # Using device-specific parameters allowed teams using the PCIe CAN controller to fine-tune their configuration through the device tree, improving reliability without negatively impacting other systems.\nThis approach provides flexibility and avoids embedding assumptions directly into driver code. For more details, refer to the VxBus Driver Tunables section in the VxWorks 7 BSP and Driver Guide.\n","date":"2025-06-14","externalUrl":null,"permalink":"/bsp/vxworks-7-vxbus-device-specific-parameters/","section":"Bsps","summary":"\u003cp\u003e\u003cstrong\u003eUsing Device-Specific Parameters for Flexible Driver Configuration in VxWorks 7\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eDevice-specific parameters offer a robust mechanism to fine-tune driver behavior for particular hardware configurations—without relying on hard-coded values. This guide illustrates how to implement this flexibility using a real-world example from a PCIe controller driver developed for the Renesas R-Car H3 SIP evaluation board.\u003c/p\u003e","title":"VxWorks 7 vxbus Device Specific Parameters","type":"bsp"},{"content":"This guide walks you through building and deploying the Python runtime in Wind River VxWorks 7.\nOverview # VxWorks is a real-time operating system (RTOS) developed by Wind River. Python is a widely-used open-source programming language maintained by the Python Software Foundation.\nWind River provides Python support for PowerPC, ARM, and Intel architectures.\nPrerequisites # Ensure you have the following before starting:\nWind River VxWorks 7 SR0620 Intel target with UEFI BIOS boot support USB flash drive (minimum 4 GB) Step 1: Create and Build the VSB (VxWorks Source Build) Project # Open a DOS shell and set up your environment:\ncd \u0026lt;WIND_HOME\u0026gt; # Your VxWorks installation directory wrenv -p vxworks-7 cd \u0026lt;YOUR_WORKSPACE\u0026gt; # Your workspace directory vxprj vsb create python_vsb -bsp itl_generic -smp -force -S cd python_vsb vxprj vsb add PYTHON # Add the Python layer make -j 32 # Build the VSB After the build, verify that the Python runtime exists:\n\u0026lt;YOUR_WORKSPACE\u0026gt;/python_vsb/usr/3pp/deploy Step 2: Create and Build the VIP (VxWorks Image Project) # Now create the VIP:\ncd .. vxprj create -smp itl_generic python_vip -profile PROFILE_INTEL_GENERIC -vsb python_vsb cd python_vip vxprj vip component add INCLUDE_MULTI_STAGE_WARM_REBOOT vxprj vip bundle add BUNDLE_STANDALONE_SHELL vxprj parameter set DOSFS_COMPAT_NT TRUE vxprj build Note: At this stage, Python support has not yet been added to the image.\nStep 3: Boot VxWorks on the Target # Deploy the Bootloader and Kernel # Follow the itl_generic BSP readme for bootloader deployment:\n\u0026lt;WIND_HOME\u0026gt;/vxworks-7/pkgs_v2/os/board/intel/itl_generic-a.b.c.d/itl_generic_readme.md Files expected on USB:\nEFI/ BOOT/ bootapp.sys BOOTIA32.EFI BOOTX64.EFI Prepare the Target # Configure BIOS to boot from USB. Insert the USB flash drive. Power on the target to enter the kernel shell: -\u0026gt; Step 4: Identify the USB Device in VxWorks # Run the following:\n-\u0026gt; devs -\u0026gt; cd \u0026#34;/bd0a\u0026#34; -\u0026gt; ls Note the USB device path (e.g., /bd0a). Power off and return the USB drive to your workstation.\nStep 5: Copy Python Runtime to USB # Copy this directory to the root of the USB drive:\n\u0026lt;YOUR_WORKSPACE\u0026gt;/python_vsb/usr/3pp/deploy Step 6: Add Python to the VxWorks Image # Return to your VIP project and configure Python support:\ncd \u0026lt;YOUR_WORKSPACE\u0026gt;/python_vip vxprj component add INCLUDE_PYTHON_SUPPORT vxprj component add INCLUDE_FILESYSTEM_SYMLINK_CONFIG vxprj parameter setstring FILESYSTEM_SYMLINK_CONFIG_STR \u0026#34;\u0026lt;def\u0026gt;=/bd0a/deploy;/bin=\u0026lt;def\u0026gt;/bin;/usr=\u0026lt;def\u0026gt;/usr;/etc=\u0026lt;def\u0026gt;/etc;/lib=\u0026lt;def\u0026gt;/lib;\u0026#34; vxprj build Step 7: Update the Boot Image # Copy the new VxWorks image to your USB drive:\n\u0026lt;YOUR_WORKSPACE\u0026gt;/python_vip/default/vxWorks → EFI/BOOT/bootapp.sys Step 8: Create a Python Hello World Script # Save the following as helloworld.py at the root of the USB flash drive:\n# helloworld.py import os import sys print(\u0026#34;Hello World!\u0026#34;) Step 9: Run Python on the Target # Reboot the target and run the script:\n-\u0026gt; cd \u0026#34;/bd0a\u0026#34; -\u0026gt; ls -\u0026gt; cmd [vxWorks *]# python3 helloworld.py Launching process \u0026#39;python3\u0026#39; ... Process \u0026#39;python3\u0026#39; (process Id = 0x809aa340) launched. Hello World! You may also run Python interactively:\n[vxWorks *]# python3 Python 3.8.0 (default, Apr 27 2020) \u0026gt;\u0026gt;\u0026gt; import os \u0026gt;\u0026gt;\u0026gt; import sys \u0026gt;\u0026gt;\u0026gt; print(\u0026#34;Hello World!\u0026#34;) Hello World! \u0026gt;\u0026gt;\u0026gt; This completes the Python deployment process on a VxWorks 7 target.\n","date":"2025-06-14","externalUrl":null,"permalink":"/bsp/integrate-python-with-vxworks-7/","section":"Bsps","summary":"\u003cp\u003eThis guide walks you through building and deploying the Python runtime in Wind River VxWorks 7.\u003c/p\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eOverview \n    \u003cdiv id=\"overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eVxWorks is a real-time operating system (RTOS) developed by Wind River. Python is a widely-used open-source programming language maintained by the \u003ca href=\"http://www.python.org\" target=\"_blank\"\u003ePython Software Foundation\u003c/a\u003e.\u003c/p\u003e","title":"Integrate Python With VxWorks 7","type":"bsp"},{"content":"","date":"2025-06-14","externalUrl":null,"permalink":"/tags/python/","section":"Tags","summary":"","title":"Python","type":"tags"},{"content":"From powering life-critical medical devices to guiding spacecraft on interplanetary missions, real-time operating systems (RTOS) form the invisible foundation of our modern world. At the forefront of this technology stands VxWorks, a software marvel developed by Wind River that has continually adapted to meet the complex demands of the embedded systems landscape.\nProven Performance, Mission-Critical Reliability # VxWorks ensures deterministic behavior: given the same input, it delivers the same result, at the same time, every time. It’s the RTOS behind countless innovations — from driver assistance systems and robotic surgery to planetary rovers and aerospace defense systems.\nAs embedded computing evolved from isolated systems to intelligent edge platforms, VxWorks has kept pace, incorporating cutting-edge features without compromising its core: predictable, high-performance real-time execution.\nInnovation Across the Stack # Enabling AI and ML at the Edge # Once exclusive to the cloud, artificial intelligence (AI) and machine learning (ML) now operate directly on edge devices. VxWorks enables this shift by supporting modern data science libraries:\nNumPy (2020) and Pandas (2021) for data processing TensorFlow Lite (2021) for lightweight ML model deployment These capabilities empower edge applications like image recognition in defense, predictive maintenance in vehicles, and faster diagnostics in healthcare.\nTime-Sensitive Networking (TSN) # To address the limitations of traditional Ethernet in real-time environments, VxWorks introduced TSN support in 2016, enabling:\nTime synchronization Bounded latency Deterministic packet delivery The RTOS now supports TSN across Intel® and Arm® platforms, as well as deployment within virtual machines (VMs) via Wind River Helix™ Virtualization Platform, validated with no performance degradation (2024 milestone).\n💡 Industry 4.0 integration was further enhanced by adding the open62541 OPC UA stack over TSN in 2020.\nDesigned for Certification and Multicore Scale # Functional Safety at Scale # VxWorks supports high-assurance certification standards across industries:\nAerospace: DO-178C DAL A Automotive: ISO 26262 ASIL D Medical: IEC 62304 Class C Industrial: IEC 61508 SIL 3 Over 600 projects have leveraged VxWorks\u0026rsquo; pre-certified components to streamline safety certification. It provides comprehensive tooling to address interference challenges in multicore processors, based on techniques published in collaboration with Rapita Systems.\nMulticore and 64-bit Support # Since 2014, VxWorks has supported multi-core and 64-bit architectures while maintaining low and predictable system overhead—crucial for high-performance real-time workloads.\nBuilt for Developer Agility # Extensive BSP Ecosystem # With support for Arm, RISC-V, x86, PPC and more, VxWorks offers an extensive library of Board Support Packages (BSPs). In 2020, VxWorks added RISC-V support, enabling development on open silicon without vendor lock-in or royalties.\nCustom BSPs are also available through Wind River Professional Services for projects with unique hardware needs.\nModern Language Support # VxWorks embraces modern software practices by supporting popular programming languages:\nPython (2020): rapid scripting and modular design Rust (2019): memory-safe concurrency and robust security GNAT Pro for Rust (2024): added via AdaCore partnership These enable teams to build secure, maintainable systems more efficiently.\nCloud-Native Development and DevSecOps # With the release of Wind River Studio Developer in 2021, VxWorks became the first RTOS to offer a cloud-native DevSecOps toolchain. Features include:\nIntegrated CI/CD pipelines Cloud-based debugging and testing Secure deployment and updates Containers and Kubernetes # VxWorks leads the embedded space in containerization:\nOCI container support (2021) Kubernetes orchestration (2023) This allows embedded teams to standardize their workflows, minimize errors, and deploy updates faster.\nSecuring the Intelligent Edge # Security is not optional — it’s fundamental. Since 2022, Wind River has applied a Secure Development Lifecycle (SDL) based on NIST SP 800-218 (SSDF), ensuring product integrity from design to deployment. VxWorks is also backed by Wind River Security Center for vulnerability tracking and mitigation.\nLooking Ahead # The journey of VxWorks is far from over. As the embedded systems industry confronts new frontiers — AI at the edge, TSN evolution, increasing safety demands, and ever-more powerful multicore architectures — VxWorks remains a trusted partner.\nWhether you’re building next-gen medical devices, smart vehicles, or aerospace platforms, when it matters, it runs on VxWorks.\nReferences # VxWorks Product Page Wind River Studio Developer Mitigation of Interference in Multi-core Processors TSN White Paper ","date":"2025-06-06","externalUrl":null,"permalink":"/industries/vxworks-a-journey-of-innovation/","section":"Industries","summary":"\u003cp\u003eFrom powering life-critical medical devices to guiding spacecraft on interplanetary missions, \u003cstrong\u003ereal-time operating systems (RTOS)\u003c/strong\u003e form the invisible foundation of our modern world. At the forefront of this technology stands \u003cstrong\u003eVxWorks\u003c/strong\u003e, a software marvel developed by \u003cstrong\u003eWind River\u003c/strong\u003e that has continually adapted to meet the complex demands of the embedded systems landscape.\u003c/p\u003e","title":"VxWorks: A Journey of Innovation","type":"industries"},{"content":"","date":"2025-06-06","externalUrl":null,"permalink":"/tags/device-model/","section":"Tags","summary":"","title":"Device Model","type":"tags"},{"content":"","date":"2025-06-06","externalUrl":null,"permalink":"/tags/simics/","section":"Tags","summary":"","title":"Simics","type":"tags"},{"content":"See how to build a new device, add it to an existing target system, and experience the Simics modeling process from creation to completion of the device.\nIn the video, we show how this device is built using the Simics Eclipse GUI, via the stages laid out in the Simics modeling white paper:\nWe have an ARM-based QSP machine with two cores and a basic set of peripherals, and add a new device which is a controller for a simple user-facing panel. The panel itself has four colored LEDs that can be turned on and off from the device, and a button input that should cause the device to send an interrupt to the processors of the machine (via the interrupt controller). We also assume that there is a software stack in place that contains a driver for the device, and that the end goal is to make that software driver happy with our virtual platform. This situation is representative for much of real Simics usage and modeling.\nAt the beginning, we have the QSP machine along with the user-facing panel. Set up a skeleton of the programming register map of the device (using DML) Add the device to the machine setup (system memory map) Test run with software (ending in a failure since there is no functionality) Set up unit tests to describe the functionality of the device (test-driven development, essentially) Fill in most of the functionality (we do a fast forward here, just like in a cooking show where you cut from putting a cake in the oven to it being done) Rerun unit tests and retest with software to show the device is still slightly incomplete Fill in the last piece of functionality Rerun unit tests and software test, showing that the device now works as it should ","date":"2025-06-06","externalUrl":null,"permalink":"/video/simics-device-model-building/","section":"Videoes","summary":"\u003cp\u003eSee how to build a new device, add it to an existing target system, and experience the Simics modeling process from creation to completion of the device.\u003c/p\u003e","title":"Simics Device Model Building","type":"video"},{"content":"","date":"2025-06-05","externalUrl":null,"permalink":"/tags/generative-ai/","section":"Tags","summary":"","title":"Generative AI","type":"tags"},{"content":"","date":"2025-06-05","externalUrl":null,"permalink":"/tags/nota-ai/","section":"Tags","summary":"","title":"Nota AI","type":"tags"},{"content":"Wind River, a global leader in delivering software for the intelligent edge, has signed a strategic partnership program agreement (PPA) with Nota AI, a pioneering company specializing in on-device AI optimization. This agreement aims to integrate the capabilities of Nota AI\u0026rsquo;s NetsPresso® platform into Wind River\u0026rsquo;s Wind River Studio Developer platform.\n\u0026ldquo;AI model optimization and software-defined automation will be key to unlocking rich edge applications and new scenarios. This collaboration combines Nota AI\u0026rsquo;s AI innovation capabilities with Wind River\u0026rsquo;s deep expertise in mission-critical and edge computing, enabling development teams to more effectively unleash the potential of physical AI and build efficient workflows to explore new possibilities for generative AI at the edge.\u0026rdquo;\n— by Avijit Sinha | SVP, Strategy and Global Business Development, Wind River\n\u0026ldquo;Wind River\u0026rsquo;s technology and its expertise in mission-critical edge computing, combined with our proprietary AI model optimization platform NetsPresso, will unleash new potential for AI optimization and on-device generative AI across industries, opening up paths for growth and innovation. Through our collaboration with Wind River, we are accelerating the time-to-market for edge AI applications and significantly expanding the scale of AI technology adoption in sectors such as automotive, mobile, and IoT.\u0026rdquo;\n— by Myungsu Chae | CEO, Nota AI\nThe interoperability between Studio Developer functionalities and the NetsPresso AI/ML framework enables a simplified workflow from AI model training, compression, conversion, and benchmarking to deployment – realizing integrated model optimization, testing, and deployment in real edge environments.\nKey areas of collaboration between Studio Developer and NetsPresso include:\nWind River Studio Digital Feedback Loop: Enables data-centric AI through real-time feedback collection, with feedback data flowing back to the NetsPresso platform for continuous model improvement and fine-tuning. Wind River Studio Test Automation: Significantly reduces costs by minimizing manual effort and accelerating iterations; AI workflows powered by NetsPresso enable automated testing. Wind River Studio Virtual Lab: Supports remote deployment of NetsPresso-trained AI models and testing on virtual devices or remotely connected physical edge devices. Customers can validate models on specific hardware configurations without shipping physical boards. About Wind River # Wind River is a global leader in software for the intelligent edge. For over four decades, the company has provided software validated for performance, reliability, and security to mission-critical domains worldwide. Wind River\u0026rsquo;s technology is widely used across various industries, including aerospace, defense, automotive, industrial, medical, and telecommunications. Its product portfolio includes the industry-leading real-time operating system VxWorks®, Helix™ Virtualization Platform, Wind River Studio, simulation and test solutions, and world-leading professional services and enterprise support. Wind River is committed to helping customers accelerate the development, deployment, and operation of mission-critical intelligent systems.\nAbout Nota AI # Nota AI (Nota Inc.) is a leading on-device AI company focused on AI model optimization and on-device generative AI. Leveraging its proprietary NetsPresso® platform, Nota AI provides high-performance AI capabilities for various industries, including transportation, automotive, mobile, and IoT. The company has presences in the United States and Germany and is actively expanding its global footprint, particularly in key markets such as the Middle East and Southeast Asia. Nota AI\u0026rsquo;s technological leadership has been globally recognized, having recently been listed in CB Insights\u0026rsquo; \u0026ldquo;Global 100 Most Innovative AI Startups.\u0026rdquo;\n","date":"2025-06-05","externalUrl":null,"permalink":"/news/wind-river-collaborates-with-nota-ai-to-deliver-on-device-generative-ai-solutions/","section":"News","summary":"\u003cp\u003eWind River, a global leader in delivering software for the intelligent edge, has signed a strategic partnership program agreement (PPA) with Nota AI, a pioneering company specializing in on-device AI optimization. This agreement aims to integrate the capabilities of Nota AI\u0026rsquo;s NetsPresso® platform into Wind River\u0026rsquo;s Wind River Studio Developer platform.\u003c/p\u003e","title":"Wind River Collaborates With Nota AI to Deliver on Device Generative AI Solutions","type":"news"},{"content":"","date":"2025-06-03","externalUrl":null,"permalink":"/tags/hypervisor/","section":"Tags","summary":"","title":"Hypervisor","type":"tags"},{"content":"Seamlessly Integrating a Windows User Interface with a Safety-Critical VxWorks System\nWhen developing systems that combine safety-critical functionality with a rich user experience, the Wind River® VxWorks® Hypervisor offers a powerful solution. By leveraging the hypervisor to run Microsoft Windows alongside VxWorks on a single hardware platform, developers can deliver intuitive graphical interfaces while maintaining real-time, deterministic control over critical processes.\nOne of our customers - a medical device manufacturer - faced exactly this challenge. Their product needed to maintain a human organ in a viable state, which demanded a safety-certified, real-time OS. Simultaneously, it had to present clear, actionable information to clinicians through a modern touchscreen interface. The solution: run a Windows GUI in parallel with safety-critical VxWorks logic, powered by the VxWorks Hypervisor.\nSystem Architecture Overview # Below is a high-level diagram of the VxWorks Hypervisor Reference Platform:\nVxWorks 7 Hypervisor Reference System This architecture includes:\nA VxWorks Root OS to manage the hypervisor. A VxWorks Guest OS responsible for real-time control, medical device communication, and data transmission. A Windows Guest OS hosting the graphical user interface. A Virtual Network Interface (vNIC) to facilitate internal communication between the VxWorks and Windows partitions. Custom VxWorks communication tasks that manage socket-based data exchange between system components. Each operating system runs independently, thanks to the strict partitioning enforced by the hypervisor. This means that if Windows were to fail or reboot, the VxWorks Guest OS would continue uninterrupted—ensuring the organ remains safe and viable.\nDevelopment and Configuration # Building this hybrid platform involved configuring multiple software components within the Wind River Workbench environment, including:\nVxWorks Base OS (VSB) and Project (VIP) builds for each guest. Startup scripts to initialize the system and launch custom tasks. vNIC drivers to support internal Ethernet-style communication. Custom VxWorks tasks to handle socket communication across OS partitions. The setup also required sourcing compatible hardware. The hypervisor demands an x86 processor with Intel VT-d (virtualization support), and all components must boot securely from internal flash storage.\nHardware Platform: Kontronn KCP312 # The reference system runs on the KCP312, a compact, fanless 3.5” x86 embedded motherboard powered by an Intel® Pentium® N4200 or Celeron® N3350 (Apollo Lake). It offers:\nOperating temperature range of -20°C to +60°C (up to +70°C optional) +12V DC power input Dual PCI Express Mini Card slots Rich I/O and multiple display interfaces Designed for rugged, industrial environments, the KCP312 is ideal for applications in IoT, medical systems, kiosks, automation, and more.\nReference Platform Offering # To help developers jumpstart their own hypervisor-based systems, we offer a complete VxWorks Hypervisor Reference Platform, including:\nPre-configured hardware and OS images All software components and custom tasks Full system documentation and startup scripts Optional on-site or remote consultancy for customization and training This platform dramatically reduces development time and risk, while giving you the flexibility to update user-facing software independently of your certified safety-critical logic.\nIdeal Use Cases # This architecture is perfect for any application that needs a robust user interface backed by real-time reliability, including:\nMedical devices Industrial automation systems IoT gateways Robotics and AI systems Secure defense applications Whether you’re building a life-saving instrument or an intelligent kiosk, the VxWorks Hypervisor Reference Platform provides the foundation to bring your vision to life—securely, safely, and efficiently.\n","date":"2025-06-03","externalUrl":null,"permalink":"/industries/vxworks-hypervisor-reference-platform/","section":"Industries","summary":"\u003cp\u003e\u003cstrong\u003eSeamlessly Integrating a Windows User Interface with a Safety-Critical VxWorks System\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eWhen developing systems that combine safety-critical functionality with a rich user experience, the Wind River® VxWorks® Hypervisor offers a powerful solution. By leveraging the hypervisor to run Microsoft Windows alongside \u003ca href=\"https://www.vxworks.net\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e on a single hardware platform, developers can deliver intuitive graphical interfaces while maintaining real-time, deterministic control over critical processes.\u003c/p\u003e","title":"VxWorks Hypervisor Reference Platform","type":"industries"},{"content":"","date":"2025-06-03","externalUrl":null,"permalink":"/tags/ai-assistant/","section":"Tags","summary":"","title":"AI Assistant","type":"tags"},{"content":"Use natural language to find and resolve issues with the Wind River AI Assistant.\n","date":"2025-06-03","externalUrl":null,"permalink":"/video/wind-river-ai-assistant/","section":"Videoes","summary":"\u003cp\u003eUse natural language to find and resolve issues with the Wind River AI Assistant.\u003c/p\u003e\n\u003clite-youtube videoid=\"DsMQ4Nz4258\" playlabel=\"DsMQ4Nz4258\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"Wind River AI Assistant","type":"video"},{"content":"Understanding Basic RTOS Functions in VxWorks: A Practical Guide for Engineers\nVxWorks, developed by Wind River, is a widely adopted real-time operating system (RTOS) in mission-critical embedded systems. This article walks through the foundational functions of VxWorks, including task control, inter-process communication (IPC), signals, and virtual devices, offering practical code examples throughout.\nWhy VxWorks? # VxWorks provides a Unix-like multitasking environment with:\nHard real-time performance Modular and scalable architecture POSIX compliance SMP/AMP support Rich networking and file system APIs Support for modern processor families (ARM, Intel, MIPS, etc.) It uses a host-target model: development happens on a host (e.g., Linux/Windows), with deployment to an embedded target.\nSystem Initialization and Configuration # Typical startup involves setting system clock, initializing device drivers, and spawning initial tasks.\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;sysLib.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; void sysInit() { sysClkRateSet(100); // Set system tick rate to 100 Hz } Task Management # VxWorks tasks are lightweight threads with distinct states: ready, running, suspended, etc.\nCreate and Start a Task # void myWorker() { while (1) { printf(\u0026#34;Task running\\n\u0026#34;); taskDelay(100); // 1 second if tick rate is 100 Hz } } void startTask() { int tid = taskSpawn(\u0026#34;tWorker\u0026#34;, 100, 0, 8192, (FUNCPTR)myWorker, 0,0,0,0,0,0,0,0,0,0); if (tid == ERROR) perror(\u0026#34;taskSpawn failed\u0026#34;); } Suspend and Resume a Task # void pauseTask(int tid) { taskSuspend(tid); } void resumeTask(int tid) { taskResume(tid); } Inter-Process Communication (IPC) # Semaphores # Semaphores are used for mutual exclusion and synchronization.\nBinary Semaphore Example # #include \u0026lt;semLib.h\u0026gt; SEM_ID sem; void initSem() { sem = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY); } void taskUsingResource() { semTake(sem, WAIT_FOREVER); // critical section semGive(sem); } Mutex (Priority Inheritance) # SEM_ID mutex = semMCreate(SEM_Q_PRIORITY | SEM_INVERSION_SAFE); Message Queues # Queues support structured, FIFO or priority-based message passing.\n#include \u0026lt;msgQLib.h\u0026gt; MSG_Q_ID msgQ; void setupQueue() { msgQ = msgQCreate(10, sizeof(int), MSG_Q_PRIORITY); } void producer() { int value = 123; msgQSend(msgQ, (char*)\u0026amp;value, sizeof(int), WAIT_FOREVER, MSG_PRI_NORMAL); } void consumer() { int rcv; msgQReceive(msgQ, (char*)\u0026amp;rcv, sizeof(int), WAIT_FOREVER); printf(\u0026#34;Received: %d\\n\u0026#34;, rcv); } Signal Handling (Software Interrupts) # Signals are used for asynchronous notification.\n#include \u0026lt;signal.h\u0026gt; #include \u0026lt;sigLib.h\u0026gt; void signalHandler(int sigNum) { printf(\u0026#34;Signal %d received\\n\u0026#34;, sigNum); } void setupSignal() { sigset(SIGUSR1, signalHandler); kill(taskIdSelf(), SIGUSR1); // Send signal to self } Virtual Devices # Pipes and network sockets act like file descriptors.\nPipe as I/O Channel # #include \u0026lt;ioLib.h\u0026gt; #include \u0026lt;pipeDrv.h\u0026gt; void setupPipe() { pipeDevCreate(\u0026#34;/pipe/test\u0026#34;, 1024, 1024); int fd = open(\u0026#34;/pipe/test\u0026#34;, O_RDWR, 0); write(fd, \u0026#34;hello\u0026#34;, 5); char buffer[6] = {0}; read(fd, buffer, 5); printf(\u0026#34;Received: %s\\n\u0026#34;, buffer); } Networking Basics # VxWorks supports Berkeley Sockets API with IPv4/IPv6:\n#include \u0026lt;sockLib.h\u0026gt; #include \u0026lt;inetLib.h\u0026gt; #include \u0026lt;netinet/in.h\u0026gt; void openSocket() { int sock = socket(AF_INET, SOCK_STREAM, 0); // bind, listen, connect, etc. } File System API Example # Using RAM disk:\n#include \u0026lt;ramDrv.h\u0026gt; #include \u0026lt;dosFsLib.h\u0026gt; #include \u0026lt;ioLib.h\u0026gt; void setupRamDisk() { ramDevCreate(\u0026#34;/ram0\u0026#34;, 512, 100); // 100 blocks of 512 bytes dosFsVolFormat(\u0026#34;/ram0\u0026#34;, DOS_OPT_BLANK, NULL); int fd = open(\u0026#34;/ram0/file.txt\u0026#34;, O_CREAT | O_RDWR, 0666); write(fd, \u0026#34;VxWorks\u0026#34;, 7); close(fd); } Common Header Files # Header File Description vxWorks.h Core definitions taskLib.h Task control functions semLib.h Semaphore support msgQLib.h Message queues sigLib.h Signal handling pipeDrv.h Pipe virtual device interface inetLib.h IP address and networking utilities Safety Features # Priority Inheritance in mutexes Task deletion protection Watchdog timers Virtual memory and MMU support Power management APIs Summary # VxWorks gives engineers precise control over task execution, synchronization, and inter-task communication. Key takeaways:\nUse taskSpawn, taskSuspend, taskResume for managing execution. Apply semaphores and queues for IPC. Leverage virtual devices for modular I/O. Use signals for exception-like events. Extend systems with power management and network stacks. Mastering these APIs empowers developers to design robust and responsive embedded applications.\nReferences # Wind River VxWorks Documentation VxWorks 6 on-line Documents ","date":"2025-06-02","externalUrl":null,"permalink":"/app/understanding-basic-rtos-functions-in-vxworks/","section":"Apps","summary":"\u003cp\u003e\u003cstrong\u003eUnderstanding Basic RTOS Functions in VxWorks: A Practical Guide for Engineers\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eVxWorks, developed by Wind River, is a widely adopted real-time operating system (RTOS) in mission-critical embedded systems. This article walks through the foundational functions of \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e, including task control, inter-process communication (IPC), signals, and virtual devices, offering practical code examples throughout.\u003c/p\u003e","title":"Understanding Basic RTOS Functions in VxWorks","type":"app"},{"content":"","date":"2025-06-01","externalUrl":null,"permalink":"/tags/ai/ml/","section":"Tags","summary":"","title":"AI/ML","type":"tags"},{"content":"Recently, SiMa.ai, a software-centric embedded edge machine learning system-on-chip (MLSoC) company, and Wind River, a global leader in intelligent edge software, announced a partnership to jointly launch an integrated hardware and software solution for next-generation edge AI.\nSiMa.ai\u0026rsquo;s MLSoC platform integrates eLxr, an enterprise-grade Debian derivative, and is commercially supported by Wind River eLxr Pro. This solution provides developers with a convenient and seamless experience, enabling them to easily customize and accelerate product deployment. This integrated solution retains the flexibility of open-source technology while offering enterprise-grade security, stability, and compliance, meeting diverse industry needs.\n\u0026ldquo;As the complexity of the intelligent edge increases, AI and software-defined automation technologies will be key to unlocking its potential,\u0026rdquo; said Avijit Sinha, Senior Vice President of Strategy and Global Business Development at Wind River. \u0026ldquo;SiMa.ai\u0026rsquo;s advanced MLSoC platform combined with Wind River\u0026rsquo;s proven edge technology in critical mission environments will accelerate the development of real-time physical AI in cross-industry applications.\u0026rdquo;\n\u0026ldquo;Edge AI is the new \u0026lsquo;gold rush,\u0026rsquo; creating tremendous opportunities in robotics, industrial automation, healthcare, automotive, aerospace, and defense,\u0026rdquo; said Krishna Rangasayee, Founder and CEO of SiMa.ai. \u0026ldquo;Combining Wind River\u0026rsquo;s deep expertise and market achievements in the intelligent edge, we have jointly launched an industry-leading edge AI platform. This platform offers exceptional performance, ultra-low power consumption, and ease of use, fully supporting all AI requirements, including generative AI. We look forward to working together to promote the scaled deployment of AI technology on devices across various physical industries.\u0026rdquo;\nThe SiMa.ai MLSoC platform is a complete full-stack hardware and software solution. Its unified software development environment, Palette™, simplifies the entire ML application development process, from creation and building to deployment.\nTechnical Highlights and Demonstrations # The joint solution was demonstrated at SiMa.ai\u0026rsquo;s booth (#603) at the Embedded Vision Summit, held from May 20-22 in Santa Clara. In this demonstration, the SiMa.ai platform utilized eLxr, a stable Debian derivative, showcasing how it provides efficient and reliable underlying support for edge AI. This version is also at the core of Wind River eLxr Pro\u0026rsquo;s commercial-grade Debian support solution.\nAbout Wind River eLxr Pro # Wind River eLxr Pro, based on the open-source enterprise-grade Debian derivative project eLxr, provides enterprise customers with commercial-grade support and maintenance services. It helps build scalable, highly secure, and highly reliable Linux solutions to address complex challenges in cloud-to-edge deployments. eLxr Pro is a vital part of Wind River\u0026rsquo;s intelligent edge product portfolio, which also includes real-time operating systems (RTOS), embedded Linux, enterprise Linux, private cloud platforms, virtualization technologies, and cloud-native DevOps tools.\nAbout SiMa.ai # SiMa.ai is a software-centric embedded edge machine learning system-on-chip (MLSoC) technology leader. Its \u0026ldquo;ONE Platform for Edge AI\u0026rdquo; offers flexible adaptability across various frameworks, networks, models, sensors, and modalities. Edge ML applications running on SiMa.ai MLSoC and the Modalix series products achieve significant improvements in performance and energy efficiency, providing high-precision intelligent support for scenarios ranging from computer vision to generative AI. This empowers customers in industries such as industrial manufacturing, retail, aerospace, defense, agriculture, and healthcare to achieve innovative breakthroughs and cost reduction. Founded in 2018, the company has raised $270 million in funding from renowned institutions including Fidelity Investments, Maverick Capital, Point72, MSD Partners, and VentureTech Alliance.\n©2025 SiMa Technologies, Inc. All rights reserved. SiMa.ai logo and related brand names are registered trademarks in the U.S. and other countries.\n","date":"2025-06-01","externalUrl":null,"permalink":"/news/sima.ai-and-wind-river-create-ai-ml-experience-for-intelligent-edge-application/","section":"News","summary":"\u003cp\u003eRecently, SiMa.ai, a software-centric embedded edge machine learning system-on-chip (MLSoC) company, and Wind River, a global leader in intelligent edge software, announced a partnership to jointly launch an integrated hardware and software solution for next-generation edge AI.\u003c/p\u003e","title":"SiMa.ai and Wind River Create AI/ML Experience for Intelligent Edge Application","type":"news"},{"content":"","date":"2025-05-10","externalUrl":null,"permalink":"/tags/capgemini/","section":"Tags","summary":"","title":"Capgemini","type":"tags"},{"content":"","date":"2025-05-10","externalUrl":null,"permalink":"/tags/elxr/","section":"Tags","summary":"","title":"ELxr","type":"tags"},{"content":"","date":"2025-05-10","externalUrl":null,"permalink":"/tags/private-cloud-solutions/","section":"Tags","summary":"","title":"Private Cloud Solutions","type":"tags"},{"content":"Introduction\nThe collaboration integrates Wind River Cloud Platform and eLxr Pro with Capgemini\u0026rsquo;s system integration, business transformation, and application modernization capabilities. The joint solution aims to help enterprises achieve infrastructure and application modernization upgrades, workload and data migration management, and accelerate digital transformation.\nOn April 30th, Wind River announced that it will deepen its collaboration with Capgemini to jointly provide enterprises with infrastructure and application modernization, workload and data migration management, and digital transformation services, while improving cost efficiency and meeting data sovereignty compliance requirements.\nAs costs rise and compliance requirements continue to change, enterprises are actively seeking alternatives to traditional infrastructure. The collaboration between Wind River and Capgemini precisely addresses this demand by integrating Wind River\u0026rsquo;s technologies in AI and mission-critical workloads, including its Wind River Cloud Platform private cloud solution and eLxr Pro enterprise-grade Linux solution, with Capgemini\u0026rsquo;s deep system integration, business transformation, and application modernization capabilities.\nThis collaboration will create a highly attractive value proposition for enterprises across industries such as aerospace, automotive, defense, financial services, manufacturing, and retail, helping them shorten time-to-market and achieve more impactful business outcomes. The joint solution will provide enterprises with three core values:\nNext-Generation Private Cloud Platform: Secure, flexible, and cost-optimized Customized Infrastructure and Application Stack: Meeting industry-specific and compliance requirements Centralized Infrastructure Management and Automation: Simplifying operations and reducing total cost of ownership \u0026ldquo;Combining Capgemini\u0026rsquo;s deep experience in software, product platforms, and infrastructure transformation with Wind River\u0026rsquo;s technology stack, we are creating differentiated solutions for customers across industries, helping them build intelligent, compliant, and cost-effective digital infrastructure.\u0026rdquo; — Raj Nath, Managing Director, Manufacturing, Aerospace, Defense, Automotive and Life Sciences, North America at Capgemini and Group Executive Committee Member\n\u0026ldquo;Enterprises need scalable, secure, and economical alternatives to traditional infrastructure. Our collaboration with Capgemini will help customers build future-proof, customized solutions that meet the compliance and performance demands of complex industries. From edge to core to cloud, customers will enjoy a seamless modernization upgrade experience.\u0026rdquo; — Jay Bellissimo, President of Wind River\n","date":"2025-05-10","externalUrl":null,"permalink":"/news/wind-river-expands-partnership-with-capgemini/","section":"News","summary":"\u003cp\u003e\u003cstrong\u003eIntroduction\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe collaboration integrates Wind River Cloud Platform and eLxr Pro with Capgemini\u0026rsquo;s system integration, business transformation, and application modernization capabilities. The joint solution aims to help enterprises achieve infrastructure and application modernization upgrades, workload and data migration management, and accelerate digital transformation.\u003c/p\u003e","title":"Wind River Expands Partnership with Capgemini","type":"news"},{"content":" Introduction to VxWorks RTOS # VxWorks is a high-performance, reliable, and secure real-time operating system (RTOS) designed for embedded systems. Trusted in millions of devices worldwide, it powers applications in safety-critical industries such as industrial automation, aerospace and defense, medical devices, and consumer electronics. This post introduces the key features and strengths of the VxWorks RTOS.\nVxWorks equips developers with a robust suite of tools to build embedded solutions quickly and efficiently. It features:\nA high-performance kernel with preemptive multitasking Advanced memory management Full networking support including a TCP/IP stack A wide range of device drivers for components like sensors and displays Support for file systems such as FAT32 and UFS2 Integrated debugging and development tools, including the Wind River Workbench IDE These capabilities make VxWorks especially well-suited for complex projects where timing, reliability, and resource efficiency are critical.\nThe RTOS architecture is modular, allowing developers to include only the components they need, which helps reduce both system complexity and cost. Its configurability also supports various design strategies—whether your priority is deterministic behavior or ultra-fast response times. Security is another core strength of VxWorks, with built-in mechanisms that ensure safe and reliable operation even in environments exposed to potential threats.\nIf you\u0026rsquo;re new to VxWorks RTOS, our tutorial is a great place to start learning the essentials of real-time embedded system development.\nHistory and Innovations of VxWorks RTOS # VxWorks has a rich history that began in the 1980s as an evolution of VRTX, an early RTOS developed by Ready Systems. Wind River Systems, the company behind VxWorks, initially distributed VRTX and enhanced it with additional capabilities like a file system and integrated development tools. Anticipating the end of its distribution agreement, Wind River developed its own kernel to replace VRTX, giving birth to VxWorks.\nA notable reference for understanding the platform is the 2003 textbook Real-Time Concepts for Embedded Systems, written by Wind River engineers and introduced by co-founder Jerry Fiddler. While the book offers a valuable overview of VxWorks, it should be used alongside official Wind River documentation for professional development.\nKey Milestones in VxWorks History # 1981: Wind River Systems is founded by Jerry Fiddler and Dave Wilner in Berkeley, California, initially developing software for VAX systems. 1987: The first version of VxWorks is released, targeting embedded and real-time applications. 1990s: VxWorks pioneers the use of a microkernel architecture, enhancing modularity and flexibility. Wind River expands its offerings with development tools and middleware. 1997: Wind River becomes a publicly traded company and continues its growth through acquisitions and product diversification. 2018: Wind River is acquired by Intel Corporation, bringing VxWorks into Intel’s software and hardware ecosystem. Today: VxWorks continues to be a dominant RTOS, used in aviation, telecommunications, medical systems, automotive platforms, and more. Core Features and Innovations # Microkernel Architecture: Enables a modular system design, where components can be independently included or excluded. Real-Time Performance: Offers fast interrupt handling, low latency, and efficient context switching. POSIX Compliance: Supports industry standards to improve software portability and integration. Comprehensive Tooling: Includes compilers, debuggers, performance analyzers, and the Wind River Workbench IDE. Safety and Security: Built-in protections like memory isolation and fault tolerance ensure secure and robust system behavior. Features of VxWorks RTOS # VxWorks is a real-time operating system (RTOS) developed and marketed by Wind River Systems. Some of the key features of VxWorks RTOS include:\nReal-Time Performance: VxWorks is designed to deliver deterministic performance and low-latency task scheduling. This ensures high-priority tasks are executed promptly, meeting the strict timing requirements of real-time applications. Scalability: VxWorks offers a scalable architecture, allowing developers to tailor the system to various application requirements. This makes it suitable for resource-constrained devices as well as powerful multicore processors. Multitasking: VxWorks supports preemptive multitasking, enabling multiple tasks to run concurrently. The scheduler manages tasks based on their priority and state, ensuring critical tasks are executed in a timely manner. Inter-Task Communication and Synchronization: VxWorks provides several mechanisms for tasks to communicate and synchronize with each other, including message queues, semaphores, and mutexes. These features enable efficient coordination of tasks and help maintain the correct order of operations in the system. Memory Management: VxWorks includes a memory management subsystem that supports both fixed-size and dynamic memory allocation. This allows developers to manage memory usage effectively based on their application’s needs. Networking and Connectivity: VxWorks offers extensive support for various networking protocols and communication standards, such as TCP/IP, IPv6, USB, Bluetooth, and Wi-Fi. This enables seamless integration of embedded devices into connected systems. File Systems and Data Storage: VxWorks supports a variety of file systems, including FAT, NFS, and journaling file systems. This provides flexible options for data storage and management in embedded applications. Security Features: VxWorks incorporates various security features, such as secure boot, secure update mechanisms, and cryptographic libraries. These help protect devices against unauthorized access and tampering. Extensive Hardware Support: VxWorks supports a wide range of processor architectures and hardware platforms, including ARM, Intel, PowerPC, MIPS, and RISC-V. This offers developers flexibility in choosing the right hardware for their application. Development Tools: VxWorks is supported by the Wind River Workbench, an integrated development environment (IDE) that includes compilers, debuggers, and performance analysis tools. This simplifies the development and debugging process. Architecture of VxWorks RTOS # The architecture of VxWorks RTOS is designed to provide a highly modular, scalable, and flexible platform for embedded and real-time systems. The key components of the VxWorks architecture are:\nKernel: The VxWorks kernel provides the core functionality of the operating system, including task scheduling, intertask communication, and memory management. It is a preemptive, priority-based kernel that provides deterministic performance and real-time response. File System: VxWorks supports a range of file systems, including FAT, NFS, and ROMFS. These file systems provide access to storage devices and allow applications to read and write data to persistent storage. Networking Stack: VxWorks includes a full-featured networking stack that provides support for a wide range of networking protocols, including TCP/IP, UDP, ICMP, and SNMP. Device Drivers: VxWorks supports a wide range of device drivers, including drivers for serial ports, Ethernet controllers, USB devices, and custom hardware. Libraries: VxWorks includes a range of libraries that provide additional functionality to applications, such as math libraries, C libraries, and POSIX-compliant libraries. Board Support Package (BSP): VxWorks BSP provides a layer of abstraction between the operating system and the hardware platform. It includes device drivers, initialization routines, and configuration files for a specific hardware platform. Application Programming Interface (API): VxWorks API provides a set of standard interfaces for applications to interact with the operating system. The API includes functions for task creation, intertask communication, synchronization, and memory management. Working Principle of VxWorks RTOS # VxWorks RTOS operates by providing a real-time kernel that manages the system resources and provides a set of services that applications can use to interact with the operating system. The kernel provides a preemptive, priority-based scheduling algorithm that ensures that high-priority tasks are executed first and that low-priority tasks do not starve for CPU time.\nApplications running on VxWorks can create and manage tasks, which are independent threads of execution that run in their own address space. Tasks can communicate with each other using various intertask communication mechanisms, such as message queues, semaphores, and shared memory.\nVxWorks also provides a range of services for memory management, including virtual memory support and the ability to allocate and deallocate memory dynamically. This allows applications to manage their own memory usage and helps to prevent memory leaks and other memory-related errors.\nIn addition to task and memory management, VxWorks provides a range of other services, including interrupt handling, device drivers, and networking support. VxWorks also supports a variety of development tools, such as compilers, debuggers, and performance analysis tools, that allow developers to write and debug applications running on VxWorks.\nSupported Hardware Platforms by VxWorks RTOS # VxWorks RTOS supports a wide range of processor architectures and hardware platforms, offering flexibility to developers in choosing the right hardware for their applications. Some of the supported hardware platforms and processor architectures include:\nARM: VxWorks supports various ARM processor families, such as ARM Cortex-A, Cortex-R, and Cortex-M series. This includes processors from manufacturers like NXP, Texas Instruments, and STMicroelectronics. Intel: VxWorks supports Intel x86 and x86_64 (Intel 64) architectures, including Intel Atom, Core, and Xeon processors. This enables VxWorks to be used in devices ranging from low-power embedded systems to high-performance server-grade applications. PowerPC: VxWorks supports PowerPC processors from manufacturers like NXP and IBM. This includes the e200, e300, e500, e600, and e5500 series, among others. MIPS: VxWorks provides support for MIPS processor families, such as MIPS32 and MIPS64, from manufacturers like Broadcom, Cavium, and Microchip. RISC-V: VxWorks has added support for the open-source RISC-V architecture, enabling it to be used on processors that implement the RISC-V instruction set. SH: VxWorks supports the Renesas SuperH (SH) family of processors, such as the SH-2, SH-3, and SH-4 series. SPARC: VxWorks supports the SPARC architecture, including processors from manufacturers like Fujitsu and Oracle. Devices used with VxWorks RTOS # VxWorks RTOS is used in a wide range of devices across various industries, thanks to its robustness, real-time performance, and scalability. Some notable devices and applications that use VxWorks RTOS include:\nAerospace and Defense Systems: Mars rovers (Spirit, Opportunity, and Curiosity) by NASA Mars Pathfinder mission’s onboard computer Boeing 787 Dreamliner aircraft subsystems European Robotic Arm (ERA) on the International Space Station (ISS) Japanese Experiment Module (JEM) on the ISS Industrial Automation and Control Systems: Programmable logic controllers (PLCs) Industrial robots Distributed control systems (DCS) Automotive Systems: Engine control units (ECUs) Advanced driver assistance systems (ADAS) Infotainment systems Networking Equipment: Routers and switches Network security appliances (firewalls, intrusion detection systems) Wireless access points Medical Devices: Patient monitoring systems Diagnostic imaging systems (CT, MRI, ultrasound) Robotic surgical systems Telecommunications: Base stations and radio network controllers for cellular networks Satellite communication systems Media gateways and session border controllers Consumer Electronics: Set-top boxes Smart TVs Digital video recorders (DVRs) Scientific Research and Exploration: Control systems for the Large Hadron Collider at CERN Various deep space communication systems as part of NASA’s Deep Space Network (DSN) Applications of VxWorks RTOS # VxWorks RTOS is widely used across multiple industries due to its real-time performance, reliability, and versatility. Some key applications of VxWorks RTOS include:\nAerospace and Defense: VxWorks is extensively used in various aerospace and defense applications, such as avionics systems, satellite communication systems, unmanned aerial vehicles (UAVs), and ground control systems. Its real-time performance and reliability are critical for mission-critical systems in these industries. Industrial Automation: VxWorks is used in industrial automation and control systems, including programmable logic controllers (PLCs), distributed control systems (DCS), and industrial robots. Its real-time capabilities and deterministic performance are essential for ensuring precise control and responsiveness in these applications. Automotive Systems: VxWorks is employed in a range of automotive applications, such as engine control units (ECUs), advanced driver assistance systems (ADAS), and infotainment systems. Its real-time performance and reliability are crucial for ensuring safety and a seamless user experience in vehicles. Networking Equipment: VxWorks is used in networking equipment like routers, switches, network security appliances, and wireless access points. Its real-time performance and scalability enable efficient handling of network traffic and secure communication. Medical Devices: VxWorks is employed in various medical devices, such as patient monitoring systems, diagnostic imaging systems, and robotic surgical systems. Its real-time capabilities and reliability ensure accurate data processing and patient safety. Telecommunications: VxWorks is utilized in telecommunications equipment, including base stations, radio network controllers, satellite communication systems, and media gateways. Its real-time performance and robustness are essential for maintaining reliable communication networks. Consumer Electronics: VxWorks is used in consumer electronics, such as set-top boxes, smart TVs, and digital video recorders (DVRs). Its real-time performance and support for various hardware platforms make it suitable for delivering high-quality multimedia experiences. Scientific Research and Exploration: VxWorks is employed in control systems for scientific research and exploration projects, such as the Large Hadron Collider at CERN and various deep space communication systems. Advantages of VxWorks RTOS # VxWorks RTOS has several advantages that make it a popular choice for embedded and real-time systems. Some of the key advantages of VxWorks include:\nHigh Performance and Determinism: VxWorks is designed for real-time and embedded systems, and it provides high performance and deterministic behavior. Its preemptive, priority-based scheduling algorithm ensures that high-priority tasks are executed first, and its low-latency interrupt handling ensures that critical events are processed quickly. Scalability and Flexibility: VxWorks is highly modular and can be customized to meet the specific requirements of a system. Its architecture supports a wide range of hardware platforms, from small embedded devices to large multi-core systems. Reliability and Safety: VxWorks has a proven track record of reliability and safety, and it is used in many mission-critical and safety-critical systems, such as aerospace and defense systems, medical devices, and industrial control systems. Rich Set of Services and Tools: VxWorks provides a comprehensive set of services, such as intertask communication, memory management, device drivers, and networking support, as well as a range of development tools, such as compilers, debuggers, and performance analysis tools. Broad Ecosystem: VxWorks has a broad ecosystem of third-party tools and services, such as middleware, protocols, and libraries, that can be used to enhance the functionality and performance of a system. Longevity and Support: VxWorks has been in use for over three decades and is backed by Wind River Systems, a leading provider of software for intelligent systems. Wind River provides long-term support and maintenance for VxWorks, ensuring that systems can be supported for many years. Disadvantages of VxWorks RTOS # While VxWorks RTOS has many advantages, there are also some potential disadvantages to consider. Here are a few:\nProprietary: VxWorks is a proprietary RTOS, which means that its source code is not publicly available. This can limit the ability of developers to modify and customize the system to meet their specific needs. Cost: VxWorks is a commercial product, and it requires a license to use. The cost of the license can be a significant factor for some projects, especially for small or non-profit organizations. Steep Learning Curve: VxWorks has a complex architecture and a steep learning curve, especially for developers who are new to real-time systems or who have not worked with VxWorks before. Limited Community Support: While VxWorks has a broad ecosystem of third-party tools and services, it has a smaller community of developers compared to open-source RTOSes like FreeRTOS or Linux. This can limit the availability of community support and resources for developers. Limited Hardware Support: While VxWorks supports a wide range of hardware platforms, it may not support all the hardware that a developer may want to use in their project. This can limit the ability of developers to choose the hardware that best fits their requirements. Limited Development Environment: While VxWorks provides a range of development tools, it may not integrate well with all the development tools that a developer may want to use in their project. This can limit the ability of developers to choose the tools that best fit their workflow. Future Development and Enhancement of VxWorks RTOS # As a leading RTOS, VxWorks continues to evolve and adapt to the changing landscape of embedded systems. Some possible future development and enhancement areas for VxWorks RTOS include:\nImproved Security: As embedded systems become more connected and critical, ensuring robust security is essential. VxWorks will likely continue to strengthen its security features, including secure boot, secure update mechanisms, and cryptographic libraries, to protect devices from unauthorized access and tampering. Enhanced Support for Multicore Processors: With the growing trend of multicore processors in embedded systems, VxWorks may focus on improving its support for multicore architectures, optimizing task scheduling, and load balancing to make the most of multicore hardware. Expanded IoT Support: As the Internet of Things (IoT) continues to grow, VxWorks may enhance its support for IoT applications, including better integration with IoT protocols, cloud services, and edge computing platforms. Support for Emerging Hardware Platforms: As new processor architectures and hardware platforms emerge, VxWorks will likely continue to expand its hardware support, ensuring compatibility with the latest technologies. AI and Machine Learning Integration: With the increasing adoption of artificial intelligence (AI) and machine learning (ML) in embedded systems, VxWorks may incorporate support for AI and ML frameworks, making it easier for developers to integrate these advanced capabilities into their applications. Enhanced Development Tools: To streamline the development process, VxWorks may focus on improving its development tools, such as the Wind River Workbench, with features like better debugging, performance analysis, and code generation capabilities. Increased Modularity and Customization: VxWorks may continue to enhance its modular architecture, enabling developers to easily include or exclude specific components based on their application requirements, further optimizing resource usage and performance. Support for Emerging Communication Technologies: As new communication technologies and standards emerge, such as 5G and beyond, VxWorks may expand its networking stack to include support for these new technologies, ensuring seamless integration with future communication networks. VxWorks RTOS Usage, Availability, Licensing, and Pricing Details # VxWorks RTOS is a very popular RTOS and it has a lot of features, so let us discuss about it for how to use it with details.\nVxWorks RTOS Usage and Availability Details # VxWorks RTOS is available for purchase and download on the Wind River Systems website. Interested users can visit the website to learn more about the product, its features, and licensing options. Wind River Systems also offers a free trial version of VxWorks RTOS, which can be downloaded from their website for evaluation purposes. In addition, the company provides support and training services to help users get started with the RTOS and develop real-time embedded applications using VxWorks.\nVxWorks RTOS Licensing Details # VxWorks RTOS is a proprietary software product developed and licensed by Wind River Systems. The licensing of VxWorks RTOS depends on several factors, such as the number of seats, deployment options, and support requirements. Wind River Systems offers flexible licensing options to meet the needs of various users, including perpetual, term, and subscription-based licenses. The company also provides customized licensing options for specific applications or projects. Interested users can contact Wind River Systems directly to discuss their licensing needs and get more information about pricing and licensing options. Additionally, Wind River Systems also offers a free trial version of VxWorks RTOS, which can be used for evaluation purposes before purchasing the full version.\nVxWorks RTOS Pricing Details # The pricing of VxWorks RTOS is determined by several factors, such as the number of seats, deployment options, and support requirements. Wind River Systems offers flexible pricing options to meet the needs of various users, including perpetual, term, and subscription-based licenses. The company also provides customized pricing options for specific applications or projects. Interested users can contact Wind River Systems directly to get more information about pricing and licensing options. The company also offers a free trial version of VxWorks RTOS, which can be downloaded from their website for evaluation purposes. The pricing of VxWorks RTOS is not publicly available, as it depends on the specific requirements of each user.\nVxWorks RTOS Download Details # If you’re looking for a VxWorks RTOS software free download of the full version of VxWorks RTOS, unfortunately, it is not available for free. However, Wind River Systems, the developer of VxWorks RTOS, does offer a free trial version of the software for evaluation purposes. The trial version provides users with access to all of the features of the RTOS, but is limited in terms of time and usage. Interested users can visit the Wind River Systems website to learn more about the trial version of VxWorks RTOS and download it for evaluation. It’s important to note that the trial version is intended for evaluation purposes only and cannot be used for commercial or production purposes without purchasing a valid license from Wind River Systems. While a full version of VxWorks RTOS is not available for free download, the trial version offers users an opportunity to explore the features and capabilities of the software before making a purchase decision.\n","date":"2025-05-04","externalUrl":null,"permalink":"/industries/vxworks-a-high-performance-rtos-designed-for-embedded-systems/","section":"Industries","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction to VxWorks RTOS \n    \u003cdiv id=\"introduction-to-vxworks-rtos\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction-to-vxworks-rtos\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eVxWorks\u003c/strong\u003e is a high-performance, reliable, and secure real-time operating system (RTOS) designed for embedded systems. Trusted in millions of devices worldwide, it powers applications in safety-critical industries such as industrial automation, aerospace and defense, medical devices, and consumer electronics. This post introduces the key features and strengths of the VxWorks RTOS.\u003c/p\u003e","title":"VxWorks a High Performance RTOS Designed for Embedded Systems","type":"industries"},{"content":"","date":"2025-05-03","externalUrl":null,"permalink":"/tags/access-device-registers/","section":"Tags","summary":"","title":"Access Device Registers","type":"tags"},{"content":"When working with memory-mapped hardware, the ability to read and write registers from the kernel shell is a powerful tool-especially useful during device driver development and hardware bring-up. In this post, we’ll walk through how to access device registers from the VxWorks 7 kernel shell, and how this process differs from earlier versions like VxWorks 6.9.\nAccessing Registers in VxWorks 6.9 # If you’ve used VxWorks 6.9 before, you might remember using the d and m commands in the kernel shell to inspect and modify device registers directly:\n-\u0026gt; d 0xffd02000, 8, 4 NOTE: memory values are displayed in hexadecimal. 0xffd02000: 00000001 000000ee 3fe449ea 00000000 *.........I.?....* 0xffd02010: 00000000 00000000 3130362a 00000000 *........*601....* value = 0 = 0x0 -\u0026gt; This dumps eight 4-byte registers starting at the physical address 0xffd02000.\nTo modify register values:\n-\u0026gt; m ffd02000, 4 0xffd02000: 00000001- 0xffd02004: 000000ee-ff 0xffd02008: 3e63054e-. value = 0 = 0x0 Or, using pointer syntax:\n-\u0026gt; *0xffd02000 = 0 value = 0 = 0x0 These examples access the L4 Watchdog Timer on the Cyclone V HPS.\nWhat’s Different in VxWorks 7 # Trying the same approach in VxWorks 7 often results in an exception:\n-\u0026gt; d 0xffd02000, 32, 4 Data abort Exception address: 0x003736a8 Data Fault Address Register: 0xffd02000 ... Shell task \u0026#39;tShell0\u0026#39; restarted... Why? Because VxWorks 7 handles memory management very differently. Specifically, address translation between virtual and physical addresses is no longer guaranteed to be one-to-one.\nUnderstanding Virtual vs. Physical Addresses # Modern processors use Memory Management Units (MMUs) to manage memory. VxWorks leverages this to define separate virtual and physical address spaces:\nVirtual addresses: Used by software (e.g., pointers in C) Physical addresses: Used by hardware to route memory accesses In VxWorks 7, only regions explicitly mapped from physical to virtual memory are accessible. Attempting to use an unmapped physical address as a virtual address will trigger a data abort.\nInspecting the Address Map # To inspect the current memory mappings, use vmContextShow in the shell:\n-\u0026gt; vmContextShow VIRTUAL ADDR BLOCK LENGTH PHYSICAL ADDR PROT CACHE SPECIAL 0x22000000 0x00004000 0xffd08000 RW- OFF/CO/G ... 0x22008000 0x00001000 0xffd05000 RW- OFF/CO/G ... ... The physical address 0xffd02000 doesn’t appear—hence, attempts to access it cause an exception.\nWhy Are Some Devices Mapped, But Not Others # The answer lies in the device tree. When VxWorks boots, it parses the device tree, initializes device drivers, and maps required physical regions to virtual memory. Devices not claimed by drivers may remain unmapped.\nManually Mapping a Device Register # If a device isn’t mapped automatically, you can manually map it using the pmapGlobalMap() function:\nvoid* pmapGlobalMap (PHYS_ADDR addr, size_t len, UINT attrs); addr: Physical address len: Length in bytes (rounded up to at least a memory page) attrs: Memory attributes (e.g., cache settings, access permissions) Example: Mapping the L4 Watchdog Timer # -\u0026gt; l4wd0 = pmapGlobalMap (0xffd02000ULL, 0x1000, 0x483) New symbol \u0026#34;l4wd0\u0026#34; added to kernel symbol table. l4wd0 = 0x228f7000 The 0x483 attribute enables read/write access (0x3), disables caching (0x80), and ensures guarded access (0x400). These are derived from MMU_ATTR_* constants in vmLibCommon.h.\nYou can now access the device via the mapped virtual address:\n-\u0026gt; d l4wd0, 32, 4 0x228f7000: 00000001 000000ff 7b02c5be 00000000 ... To confirm the mapping:\n-\u0026gt; vmContextShow ... 0x228f7000 0x00001000 0xffd02000 RW- OFF/CO/G ... Conclusion # To access hardware registers in VxWorks 7:\nMap the register\u0026rsquo;s physical address using pmapGlobalMap(). Use the virtual address returned to read or write registers using the usual shell commands. While this is a bit more involved than in VxWorks 6.9, it provides much better control and memory protection.\n","date":"2025-05-03","externalUrl":null,"permalink":"/bsp/accessing-device-registers-with-the-vxworks-7-kernel-shell/","section":"Bsps","summary":"\u003cp\u003eWhen working with memory-mapped hardware, the ability to read and write registers from the kernel shell is a powerful tool-especially useful during device driver development and hardware bring-up. In this post, we’ll walk through how to access device registers from the VxWorks 7 kernel shell, and how this process differs from earlier versions like \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks 6.9\u003c/a\u003e.\u003c/p\u003e","title":"Accessing Device Registers With the VxWorks 7 Kernel Shell","type":"bsp"},{"content":"","date":"2025-05-03","externalUrl":null,"permalink":"/series/bsp/","section":"Series","summary":"","title":"BSP","type":"series"},{"content":"","date":"2025-05-03","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":" 1. Introduction # VxWorks is a real-time operating system (RTOS) developed by Wind River, widely used in embedded systems. U-Boot (Universal Boot Loader) is a flexible, open-source bootloader commonly used on ARM, PowerPC, and other non-x86 architectures that lack a BIOS.\nWhile VxWorks includes its own bootloader options(namely BootROM or BootApp), U-Boot is often preferred for its extensive feature set, especially when already bundled with the target hardware.\nWith VxWorks 7, Wind River has significantly improved U-Boot integration compared to earlier versions (e.g., the cumbersome VxWorks 6.9 experience). This guide outlines how to use U-Boot as the bootloader for VxWorks 7, based on a real-world BSP project.\nWe’ll focus on using a separate Device Tree Blob (DTB) rather than embedding it within the VxWorks image, which allows runtime modifications via U-Boot without requiring a full image rebuild.\n2. Building a U-Boot-Compatible VxWorks Image # To boot VxWorks from U-Boot, the image must include a U-Boot header. You can generate this using the uVxWorks target from Wind River Workbench or the command line.\nBuild Instructions # Open a terminal and configure the environment:\ncd \u0026lt;WIND_HOME\u0026gt; wrenv -p vxworks-7 Navigate to your VxWorks Image Project (VIP):\ncd \u0026lt;YOUR_VIP\u0026gt; Build the image with U-Boot header:\nvxprj vip build uVxWorks This produces two key files for TFTP transfer:\nuVxWorks: VxWorks image with U-Boot header \u0026lt;yourboard\u0026gt;.dtb: Device Tree Blob file 3. U-Boot Configuration for VxWorks Boot # Set the required U-Boot environment variables to configure bootline arguments and MAC addresses.\nSet Bootline (bootargs) # setenv bootargs memac(2,0)host:vxWorks h=192.168.1.101 e=192.168.1.50:ffffff00 g=192.168.1.254 u=vxworks pw=harmonic f=0x0 saveenv printenv bootargs Set MAC Addresses # setenv ethaddr 00:00:13:3a:ad:00 setenv eth1addr 00:00:13:3a:ad:01 setenv eth2addr 00:00:13:3a:ad:02 setenv eth3addr 00:00:13:3a:ad:03 saveenv 4. Loading and Booting the VxWorks Image # Use a TFTP server to transfer the VxWorks image and DTB file to the target board.\nA reliable TFTP server for Windows: TFTPD32\n4.1 Load VxWorks Image # tftp 0x100000 uVxWorks Example output:\nTFTP from server 192.168.1.101; our IP address is 192.168.1.50 Filename \u0026#39;uVxWorks\u0026#39;. Load address: 0x100000 Bytes transferred = 2861632 (2baa40 hex) 4.2 Load Device Tree Blob # tftp 0xe00000 t4240qds.dtb 4.3 Boot the Image # bootm 0x100000 - 0xe00000 Expected output:\n## Booting kernel from Legacy Image at 00100000 ... Image Name: vxWorks Image Type: PowerPC VxWorks Kernel Image (uncompressed) Data Size: 2861568 Bytes = 2.7 MiB 4.4 Automate with U-Boot Script # Define a reusable U-Boot command:\nsetenv vxboot \u0026#39;tftp 0x100000 uVxWorks; tftp 0xe00000 t4240qds.dtb; bootm 0x100000 - 0xe00000\u0026#39; saveenv To boot:\nrun vxboot 5. Passing MAC Addresses from U-Boot to VxWorks # Properly passing MAC addresses from U-Boot is essential for manufacturing and deployment. Each board typically has factory-assigned MACs that must be preserved.\nIf you\u0026rsquo;re using a separate DTB file, U-Boot can patch the MAC addresses dynamically into the device tree at boot, avoiding the need to rebuild the DTB for each board.\nRequirements # Define Ethernet aliases in the device tree:\naliases { ethernet0 = \u0026amp;enet0; ethernet1 = \u0026amp;enet1; ethernet2 = \u0026amp;enet2; ethernet3 = \u0026amp;enet3; }; Provide local-mac-address placeholders in the DT nodes:\nfman0: fman@400000 { ... enet0: ethernet@e0000 { compatible = \u0026#34;fsl,fman-memac\u0026#34;; reg = \u0026lt;0xe0000 0x1000\u0026gt;; phy-handle = \u0026lt;\u0026amp;dummy_phy0\u0026gt;; phy-connection-type = \u0026#34;sgmii\u0026#34;; cell-index = \u0026lt;0\u0026gt;; local-mac-address = [ 00 04 9F 03 0A 5C ]; }; ... }; Ensure corresponding U-Boot environment variables (ethaddr, eth1addr, etc.) are set.\nU-Boot will then automatically overwrite the local-mac-address fields in the DTB before passing it to VxWorks.\nSummary # Integrating U-Boot with VxWorks 7 allows you to take advantage of a powerful, flexible bootloader that supports runtime configuration of bootlines, MAC addresses, and more. By using a separate DTB file and properly setting environment variables, you streamline board bring-up, testing, and manufacturing.\n","date":"2025-05-02","externalUrl":null,"permalink":"/bsp/integrating-u-boot-with-vxworks-7/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003e1. Introduction \n    \u003cdiv id=\"1-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#1-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eVxWorks is a real-time operating system (RTOS) developed by Wind River, widely used in embedded systems. U-Boot (Universal Boot Loader) is a flexible, open-source bootloader commonly used on ARM, PowerPC, and other non-x86 architectures that lack a BIOS.\u003c/p\u003e","title":"Integrating U-Boot With VxWorks 7","type":"bsp"},{"content":"","date":"2025-05-02","externalUrl":null,"permalink":"/tags/command-line-rebuild/","section":"Tags","summary":"","title":"Command Line Rebuild","type":"tags"},{"content":" Introduction # During VxWorks development, it\u0026rsquo;s common to modify parts of the kernel(such as drivers or boot code) to add debugging information or update functionality. Rebuilding the entire system can be time-consuming, but using the VSB_DIR variable allows you to selectively recompile just the modified source files quickly and efficiently.\nRebuilding for Single Processor (UP) # To rebuild a specific source file using the command line, open a VxWorks development shell and navigate to the relevant source directory (e.g., boot code):\ncd C:/WindRiver/vxworks-6.9/target/src/boot Then run make, specifying your target CPU, toolchain, and custom VSB directory:\nmake CPU=PENTIUM4 ADDED_CFLAGS+=\u0026#34;-g -O0\u0026#34; TOOL=gnu VSB_DIR=\u0026lt;MY-VSB\u0026gt; -g -O0 enables debugging with no optimization for GNU toolchain. Replace with the full path to your custom VSB. After compiling, rebuild your VxWorks Image Project to include the updated components.\nFor Diab Toolchain # If you\u0026rsquo;re using the Diab compiler instead of GNU, use the following flags to enable debugging:\nmake CPU=PENTIUM4 ADDED_CFLAGS+=\u0026#34;-g -Xoptimized-debug-off\u0026#34; TOOL=diab VSB_DIR=\u0026lt;MY-VSB\u0026gt; This method is valid for both VxWorks 6 and 7, assuming you\u0026rsquo;re working with a custom-built VSB.\nRebuilding for Symmetric Multiprocessing (SMP) # VxWorks distinguishes between two kernel types: UP (Uniprocessor) and SMP (Symmetric Multiprocessing). To rebuild for SMP, include the VXBUILD=SMP option:\nmake CPU=PENTIUM4 ADDED_CFLAGS+=\u0026#34;-g -O0\u0026#34; TOOL=gnu VSB_DIR=\u0026lt;MY-VSB\u0026gt; VXBUILD=SMP Building a VSB Layer in VxWorks 7 # The VSB_DIR method is effective for rebuilding source files but not for building UI layers or specific VSB components. For those cases, use the vxprj command:\ncd C:/WindRiver/workspace/your_VSB_project vxprj vsb build FBDEV To list all available layers in your VSB:\nvxprj vsb listAll Summary # Using the command line for partial kernel rebuilds is a time-saving technique for VxWorks developers. By leveraging VSB_DIR, make, and vxprj, you can efficiently recompile individual components without waiting for a full system rebuild.\n","date":"2025-05-02","externalUrl":null,"permalink":"/bsp/command-line-rebuild-of-vxworks-kernel-source/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eDuring VxWorks development, it\u0026rsquo;s common to modify parts of the kernel(such as drivers or boot code) to add debugging information or update functionality. Rebuilding the entire system can be time-consuming, but using the \u003ccode\u003eVSB_DIR\u003c/code\u003e variable allows you to selectively recompile just the modified source files quickly and efficiently.\u003c/p\u003e","title":"Command Line Rebuild of VxWorks Kernel Source","type":"bsp"},{"content":"","date":"2025-05-02","externalUrl":null,"permalink":"/tags/vxworks-kernel-source/","section":"Tags","summary":"","title":"VxWorks Kernel Source","type":"tags"},{"content":"","date":"2025-05-01","externalUrl":null,"permalink":"/tags/emacs/","section":"Tags","summary":"","title":"Emacs","type":"tags"},{"content":"VxWorks is a real-time operating system (RTOS) developed by Wind River. While Wind River provides its Workbench Eclipse-based IDE for VxWorks development, many developers prefer the speed and flexibility of Emacs. This guide outlines how to configure Emacs for building and navigating VxWorks code-specifically VxWorks 7-though most instructions also apply to earlier versions (6.x, 653, and Tornado).\nBy using Emacs, you benefit from a more responsive, keyboard-driven development workflow and a rich ecosystem of tools like Semantic, GNU Global, and auto-complete—all contributing to faster development and reduced costs.\n1. Prerequisites # This guide assumes familiarity with:\nVxWorks development and the Wind River Workbench. VSB (VxWorks Source Build), VIP (VxWorks Image Project), and DKM (Downloadable Kernel Module). Emacs and basic Emacs Lisp customization (editing .emacs or init.el). Note: This is a living document. Additional features (like GDB integration) may be added in future versions.\nPortions of this document were inspired by Bernt Hansen’s excellent org-mode reference.\n2. License # © 2025 Kontronn\nThis document is licensed under the GNU Free Documentation License v1.3 or later. All code examples and CSS are released under the GNU General Public License v3 or later.\n3. What\u0026rsquo;s New # v0.01 – Initial release.\n4. Getting Started: Emacs and VxWorks on Windows # This setup has been tested on Windows hosts. While not tested on Linux, most of the steps should be portable.\nVxWorks 7 builds require a native Windows command shell (not Cygwin). To integrate Emacs with VxWorks:\n4.1 Install GNU Global # Download a Windows build of GNU Global and install it (e.g., under Program Files (x86)), making sure the binary is available in your system PATH.\n4.2 Generate GTAGS # Create a batch file generate-gtags.bat to scan your VxWorks source files:\nREM Generate list of source files for GTAGS dir /S /A-D /B vxworks-7*.c \u0026gt; gtags-files.txt dir /S /A-D /B vxworks-7*.h \u0026gt;\u0026gt; gtags-files.txt dir /S /A-D /B vxworks-7*.cdf \u0026gt;\u0026gt; gtags-files.txt dir /S /A-D /B vxworks-7*.vsbl \u0026gt;\u0026gt; gtags-files.txt dir /S /A-D /B vxworks-7*.s \u0026gt;\u0026gt; gtags-files.txt dir /S /A-D /B workspace*.c \u0026gt;\u0026gt; gtags-files.txt dir /S /A-D /B workspace*.h \u0026gt;\u0026gt; gtags-files.txt dir /S /A-D /B workspace*.cdf \u0026gt;\u0026gt; gtags-files.txt gtags -v -f gtags-files.txt Run this from your WINDBASE (Wind River base installation directory).\n4.3 Configuring Emacs # 4.3.1 Emacs Build # Download a 64-bit Windows build of Emacs from:\nhttps://emacsbinw64.sourceforge.net/\n4.3.2 Emacs Code Browser (ECB) # Install ECB for structured code navigation:\n(add-to-list \u0026#39;load-path \u0026#34;~/.emacs.d/lisp/ecb-master\u0026#34;) (require \u0026#39;ecb) (Manual install recommended from https://github.com/alexott/ecb/)\n4.3.3 gtags Support # Enable gtags for fast source navigation:\n(setq gtags-suggested-key-mapping t) (setq load-path (cons \u0026#34;~/.emacs.d/lisp\u0026#34; load-path)) (autoload \u0026#39;gtags-mode \u0026#34;gtags\u0026#34; \u0026#34;\u0026#34; t) (add-hook \u0026#39;c-mode-hook (lambda () (gtags-mode 1))) (global-set-key \u0026#34;M-]\u0026#34; \u0026#39;gtags-find-tag-from-here) (global-set-key \u0026#34;M-[\u0026#34; \u0026#39;gtags-pop-stack) (global-set-key \u0026#34;M-#\u0026#34; \u0026#39;gtags-find-rtag) Optional: auto-update GTAGS on file save:\n(defun gtags-root-dir () ...) (defun gtags-update-single(filename) ...) (defun gtags-update-current-file() ...) (defun gtags-update-hook() ...) (add-hook \u0026#39;after-save-hook \u0026#39;gtags-update-hook) TODO: Update this section to use ggtags for better robustness.\n4.3.4 Semantic \u0026amp; Auto-complete # Enable Semantic and IntelliSense-like features:\n(semantic-mode 1) (global-ede-mode 1) (global-semantic-idle-scheduler-mode 1) (global-semantic-idle-completions-mode 1) (defun ed-add-semantic-to-autocomplete () (add-to-list \u0026#39;ac-sources \u0026#39;ac-source-semantic)) (add-hook \u0026#39;c-mode-common-hook \u0026#39;ed-add-semantic-to-autocomplete) (semanticdb-enable-gnu-global-databases \u0026#39;c-mode) (semanticdb-enable-gnu-global-databases \u0026#39;c++-mode) (defvar semantic-tags-location-ring (make-ring 20)) (defun semantic-goto-definition (point) ...) (defun semantic-pop-tag-mark () ...) (global-set-key \u0026#34;M-.\u0026#34; \u0026#39;semantic-goto-definition) (global-set-key \u0026#34;M-,\u0026#34; \u0026#39;semantic-pop-tag-mark) (global-set-key \u0026#34;M-/\u0026#34; \u0026#39;semantic-ia-show-doc) (global-set-key \u0026#34;C-c/\u0026#34; \u0026#39;semantic-ia-show-summary) (ac-config-default) 4.3.5 Wind River Code Style # Apply Wind River formatting:\n(defconst wrs-c-style \u0026#39;((c-tab-always-indent . t) ...)) (defun my-c-mode-common-hook () (c-add-style \u0026#34;WRS\u0026#34; wrs-c-style t) (setq tab-width 4 indent-tabs-mode nil) (define-key c-mode-base-map \u0026#34;C-m\u0026#34; \u0026#39;c-context-line-break)) (add-hook \u0026#39;c-mode-common-hook \u0026#39;my-c-mode-common-hook) 5. Automating VSB and VIP Builds # 5.1 Setup # Two Lisp files are needed:\nvxworks.el: General build helpers. vxworks7env.el: Your local environment setup. Run wrenv -p vxworks-7 -o print_env in a VxWorks shell and ensure your environment matches vxworks7env.el.\n5.2 .emacs Setup # (load-file \u0026#34;~/.emacs.d/lisp/vxworks.el\u0026#34;) (setq vxworks-install-dir \u0026#34;C:/WindRiver_vxw7.0/\u0026#34;) (setq vxworks-workspace-dir \u0026#34;C:/WindRiver_vxw7.0/workspace/\u0026#34;) (setup-vxworks-7-env) Note： If vxworks-install-dir is not set, Emacs will prompt you at startup.\n","date":"2025-05-01","externalUrl":null,"permalink":"/app/using-emacs-with-vxworks/","section":"Apps","summary":"\u003cp\u003eVxWorks is a real-time operating system (RTOS) developed by Wind River. While Wind River provides its Workbench Eclipse-based IDE for VxWorks development, many developers prefer the speed and flexibility of Emacs. This guide outlines how to configure Emacs for building and navigating VxWorks code-specifically VxWorks 7-though most instructions also apply to earlier versions (6.x, 653, and Tornado).\u003c/p\u003e","title":"Using Emacs With VxWorks","type":"app"},{"content":"A modern approach to embedded software application development, based on popular tools and environments, empowers developers to collaborate and generate new levels of efficiency and effectiveness.\n","date":"2025-04-26","externalUrl":null,"permalink":"/video/application-development-environment-with-wind-river-studio/","section":"Videoes","summary":"\u003cp\u003eA modern approach to embedded software application development, based on popular tools and environments, empowers developers to collaborate and generate new levels of efficiency and effectiveness.\u003c/p\u003e","title":"Application Development Environment With Wind River Studio","type":"video"},{"content":"","date":"2025-04-26","externalUrl":null,"permalink":"/series/vxworks-demonstration-videos/","section":"Series","summary":"","title":"VxWorks Demonstration Videos","type":"series"},{"content":"","date":"2025-04-26","externalUrl":null,"permalink":"/tags/wind-river-studio/","section":"Tags","summary":"","title":"Wind River Studio","type":"tags"},{"content":"","date":"2025-04-26","externalUrl":null,"permalink":"/tags/authentication/","section":"Tags","summary":"","title":"Authentication","type":"tags"},{"content":"","date":"2025-04-26","externalUrl":null,"permalink":"/tags/vxworks-binary/","section":"Tags","summary":"","title":"VxWorks Binary","type":"tags"},{"content":"A demonstration of how VxWorks® real-time operating system (RTOS) prevents the loading of malicious runtimes using Wibu-Systems\u0026rsquo; tools.\n","date":"2025-04-26","externalUrl":null,"permalink":"/video/vxworks-binary-authentication-deep-dive/","section":"Videoes","summary":"\u003cp\u003eA demonstration of how \u003ca href=\"https://www.vxworks.net\" target=\"_blank\"\u003eVxWorks®\u003c/a\u003e real-time operating system (RTOS) prevents the loading of malicious runtimes using Wibu-Systems\u0026rsquo; tools.\u003c/p\u003e\n\u003clite-youtube videoid=\"BLKw0W3oOw4\" playlabel=\"BLKw0W3oOw4\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"VxWorks Binary Authentication Deep Dive","type":"video"},{"content":"","date":"2025-04-26","externalUrl":null,"permalink":"/tags/analysis/","section":"Tags","summary":"","title":"Analysis","type":"tags"},{"content":"A demonstration showing how easy it is to analyze the performance of a real-time application using VxWorks.\n","date":"2025-04-26","externalUrl":null,"permalink":"/video/wind-river-workbench-analysis-tools-overview-demo/","section":"Videoes","summary":"\u003cp\u003eA demonstration showing how easy it is to analyze the performance of a real-time application using VxWorks.\u003c/p\u003e\n\u003clite-youtube videoid=\"C3oacIL8-XI\" playlabel=\"C3oacIL8-XI\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"Wind River Workbench Analysis Tools Overview Demo","type":"video"},{"content":"","date":"2025-04-26","externalUrl":null,"permalink":"/tags/layer-frameworkr/","section":"Tags","summary":"","title":"Layer Frameworkr","type":"tags"},{"content":"This video explains how the VxWorks® layer framework enables component level upgrades and easy third-party integration for applications using the VxWorks real-time operating system (RTOS).\n","date":"2025-04-26","externalUrl":null,"permalink":"/video/vxworks-layer-framework/","section":"Videoes","summary":"\u003cp\u003eThis video explains how the VxWorks® layer framework enables component level upgrades and easy third-party integration for applications using the VxWorks real-time operating system (RTOS).\u003c/p\u003e","title":"VxWorks Layer Framework","type":"video"},{"content":"","date":"2025-04-26","externalUrl":null,"permalink":"/tags/intelligent-mobility/","section":"Tags","summary":"","title":"Intelligent Mobility","type":"tags"},{"content":"","date":"2025-04-26","externalUrl":null,"permalink":"/tags/noa/","section":"Tags","summary":"","title":"NOA","type":"tags"},{"content":"During the 21st Shanghai International Auto Show, Wind River Kaiwu, in collaboration with Aptiv, for the first time launched its locally developed Wind River Real-Time Operating System (RTOS) and Wind River Hypervisor with Chinese intellectual property. These two localized products do not contain any foreign-controlled components and are not subject to export control restrictions. Related engineering services and technical support are also fully localized. While supporting the automotive industry, they also focus on emerging industries such as low-altitude flight and embodied robots, creating solutions that follow the Chinese pace and are tailored for the Chinese market.\nCurrently, during the Shanghai Auto Show, a low-power domain controller solution supporting City NOA (Navigate on Autopilot) developed based on the CV3 SoC and Wind River RTOS is being exhibited at the booth. On-site real vehicle demonstrations and technical analysis will comprehensively showcase the application potential of its next-generation high-level intelligent driving solution.\n","date":"2025-04-26","externalUrl":null,"permalink":"/news/wind-river-build-a-solid-foundation-for-intelligent-mobility/","section":"News","summary":"\u003cp\u003eDuring the 21st Shanghai International Auto Show, Wind River Kaiwu, in collaboration with Aptiv, for the first time launched its locally developed Wind River \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eReal-Time Operating System\u003c/a\u003e (RTOS) and Wind River Hypervisor with Chinese intellectual property. These two localized products do not contain any foreign-controlled components and are not subject to export control restrictions. Related engineering services and technical support are also fully localized. While supporting the automotive industry, they also focus on emerging industries such as low-altitude flight and embodied robots, creating solutions that follow the Chinese pace and are tailored for the Chinese market.\u003c/p\u003e","title":"Wind River Build a Solid Foundation for Intelligent Mobility","type":"news"},{"content":" 1. Introduction # Inter-Integrated Circuit (I²C) is a widely used, low-speed, two-wire communication protocol designed for communication between integrated circuits. In embedded systems, it\u0026rsquo;s common to connect sensors, EEPROMs, ADCs, and other peripherals via I²C.\nVxWorks 7 introduces a modern, scalable, and modular driver framework built around VxBus, enabling dynamic driver registration, device tree integration, and power management. For BSP (Board Support Package) developers, understanding how to create a robust I²C device driver is essential for supporting a wide range of I²C-connected peripherals on custom hardware platforms.\nThis article is designed for experienced VxWorks BSP developers who are already familiar with the BSP architecture, memory mapping, and device trees. It aims to demonstrate how to develop an I²C master controller driver, along with a basic I²C peripheral driver example using VxWorks 7’s driver model.\nWe\u0026rsquo;ll use a generic memory-mapped I²C master controller as a reference to illustrate key concepts and provide real-world code snippets to build upon.\n2. VxWorks 7 I2C Driver Architecture # 2.1 VxBus Overview # VxBus is VxWorks\u0026rsquo; device driver framework that abstracts hardware details and provides a modular, hierarchical way to manage drivers and devices. It supports automatic device matching through the device tree and manages lifecycle callbacks such as probe, attach, and detach.\nFor I²C, VxBus distinguishes between two types of drivers:\nI²C Controller Driver (Master/Bus Driver):\nInterfaces directly with the hardware (I²C controller). Registers as a bus and implements the vxbI2cDevXfer() API.\nI²C Peripheral Driver (Client/Slave Driver):\nCommunicates with devices on the I²C bus using the API exposed by the controller driver.\n2.2 Key Components and Interfaces # vxbI2cLib.h: I²C messaging and controller API VXB_I2C_BUS_METHODS: Method table for I²C bus drivers vxbFdtLib.h: Device tree parsing utilities 2.3 Typical Call Flow # Device tree parsing at boot Controller driver probed and attached Bus is registered using vxbI2cBusDevRegister() Peripheral drivers use vxbI2cDevXfer() to communicate 3. Example I²C Controller: Generic I²C Master # 3.1 Controller Register Layout # Register Offset Description CTRL 0x00 Control register STATUS 0x04 Status register DATA 0x08 Data register CLK_DIV 0x0C Clock divider register 3.2 Register Bit Definitions # #define I2C_CTRL_START (1 \u0026lt;\u0026lt; 0) #define I2C_CTRL_STOP (1 \u0026lt;\u0026lt; 1) #define I2C_CTRL_READ (1 \u0026lt;\u0026lt; 2) #define I2C_CTRL_WRITE (1 \u0026lt;\u0026lt; 3) #define I2C_STATUS_BUSY (1 \u0026lt;\u0026lt; 0) #define I2C_STATUS_ACK (1 \u0026lt;\u0026lt; 1) #define I2C_REG_CTRL 0x00 #define I2C_REG_STATUS 0x04 #define I2C_REG_DATA 0x08 #define I2C_REG_CLK_DIV 0x0C 4. Writing the I²C Controller Driver # 4.1 Register Access Helpers # #define I2C_READ_REG(base, offset) (*(volatile UINT32 *)((UINT8 *)(base) + (offset))) #define I2C_WRITE_REG(base, offset, v) (*(volatile UINT32 *)((UINT8 *)(base) + (offset)) = (v)) 4.2 Data Structures # typedef struct i2cGenDrvCtrl { VXB_DEV_ID dev; void *regBase; VXB_RESOURCE *pRes; } I2C_GEN_DRV_CTRL; LOCAL VXB_DRV_METHOD i2cGenDrvMethods[] = { { VXB_DEVMETHOD_CALL(vxbDevProbe), i2cDrvProbe }, { VXB_DEVMETHOD_CALL(vxbDevAttach), i2cDrvAttach }, { 0, NULL } }; 4.3 Probe and Attach # LOCAL STATUS i2cDrvProbe(VXB_DEV_ID pDev) { return vxbFdtDevMatch(pDev, NULL); } LOCAL STATUS i2cDrvAttach(VXB_DEV_ID pDev) { I2C_GEN_DRV_CTRL *pDrvCtrl; void *regBase; pDrvCtrl = (I2C_GEN_DRV_CTRL *) vxbMemAlloc(sizeof(I2C_GEN_DRV_CTRL)); if (pDrvCtrl == NULL) return ERROR; pDrvCtrl-\u0026gt;dev = pDev; regBase = (void *)vxFdtRegGet(pDev, 0); if (regBase == NULL) { vxbMemFree(pDrvCtrl); return ERROR; } pDrvCtrl-\u0026gt;regBase = regBase; vxbDevSoftcSet(pDev, pDrvCtrl); return vxbI2cBusDevRegister(pDev); } 4.4 Implement vxbI2cDevXfer() # LOCAL STATUS i2cDevXfer(VXB_DEV_ID dev, VXB_I2C_MSG *msgs, int num) { I2C_GEN_DRV_CTRL *pDrvCtrl = vxbDevSoftcGet(dev); void *base = pDrvCtrl-\u0026gt;regBase; for (int i = 0; i \u0026lt; num; i++) { VXB_I2C_MSG *msg = \u0026amp;msgs[i]; for (int j = 0; j \u0026lt; msg-\u0026gt;len; j++) { I2C_WRITE_REG(base, I2C_REG_DATA, msg-\u0026gt;buf[j]); UINT32 ctrl = (msg-\u0026gt;flags \u0026amp; VXB_I2C_M_RD) ? I2C_CTRL_READ : I2C_CTRL_WRITE; if (j == 0) ctrl |= I2C_CTRL_START; if (j == msg-\u0026gt;len - 1) ctrl |= I2C_CTRL_STOP; I2C_WRITE_REG(base, I2C_REG_CTRL, ctrl); while (I2C_READ_REG(base, I2C_REG_STATUS) \u0026amp; I2C_STATUS_BUSY); if (!(I2C_READ_REG(base, I2C_REG_STATUS) \u0026amp; I2C_STATUS_ACK)) return ERROR; if (msg-\u0026gt;flags \u0026amp; VXB_I2C_M_RD) msg-\u0026gt;buf[j] = I2C_READ_REG(base, I2C_REG_DATA); } } return OK; } LOCAL VXB_I2C_BUS_METHODS i2cBusMethods = { .i2cDevXfer = i2cDevXfer, .i2cDevXferTimeout = NULL }; 5. Device Tree Integration # 5.1 Example Device Tree Snippet # i2c@4000f000 { compatible = \u0026#34;generic,i2c-master\u0026#34;; reg = \u0026lt;0x4000f000 0x1000\u0026gt;; #address-cells = \u0026lt;1\u0026gt;; #size-cells = \u0026lt;0\u0026gt;; status = \u0026#34;okay\u0026#34;; eeprom@50 { compatible = \u0026#34;atmel,24c32\u0026#34;; reg = \u0026lt;0x50\u0026gt;; }; }; 6. Writing a Sample I²C Peripheral Driver: EEPROM # 6.1 Attach Routine # LOCAL STATUS eepromAttach(VXB_DEV_ID pDev) { VXB_I2C_MSG msg[2]; UINT8 addr = 0x00; UINT8 data; msg[0].addr = 0x50; msg[0].flags = 0; msg[0].buf = \u0026amp;addr; msg[0].len = 1; msg[1].addr = 0x50; msg[1].flags = VXB_I2C_M_RD; msg[1].buf = \u0026amp;data; msg[1].len = 1; if (vxbI2cDevXfer(pDev, msg, 2) == OK) printf(\u0026#34;EEPROM read success: 0x%02x\\n\u0026#34;, data); else printf(\u0026#34;EEPROM read failed\\n\u0026#34;); return OK; } 7. Testing and Debugging # Useful commands:\ni2cShow: Display registered I²C buses and devices. vxbDevShow: Display all VxBus devices. Debugging tips:\nVerify device tree compatibility strings Check ACK and STOP conditions Use logic analyzer for signal tracing 8. Conclusion # In this article, we walked through the process of designing a generic I²C device driver for VxWorks 7, covering:\nVxBus and I²C driver structure Register-level I²C controller driver implementation Device tree bindings Peripheral device communication Testing and debugging This basic foundation can be extended with:\nRepeated START support Interrupt/DMA integration Multi-bus support Complex peripheral drivers (e.g., sensors, codecs) Happy hacking with VxWorks! 🔧🛠️\n","date":"2025-04-25","externalUrl":null,"permalink":"/bsp/design-an-i2c-device-driver-for-vxworks-7/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003e1. Introduction \n    \u003cdiv id=\"1-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#1-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eInter-Integrated Circuit (I²C) is a widely used, low-speed, two-wire communication protocol designed for communication between integrated circuits. In embedded systems, it\u0026rsquo;s common to connect sensors, EEPROMs, ADCs, and other peripherals via I²C.\u003c/p\u003e","title":"Design an I2C Device Driver for VxWorks 7","type":"bsp"},{"content":"","date":"2025-04-25","externalUrl":null,"permalink":"/tags/eeprom/","section":"Tags","summary":"","title":"EEPROM","type":"tags"},{"content":"","date":"2025-04-24","externalUrl":null,"permalink":"/tags/memory-analyzer/","section":"Tags","summary":"","title":"Memory Analyzer","type":"tags"},{"content":"A demonstration of how Workbench\u0026rsquo;s CPU Profiler on VxWorks® real-time operating system (RTOS) helps detect software problems.\n","date":"2025-04-24","externalUrl":null,"permalink":"/video/memory-analyzer-for-vxworks-platform-deep-dive/","section":"Videoes","summary":"\u003cp\u003eA demonstration of how Workbench\u0026rsquo;s CPU Profiler on VxWorks® real-time operating system (RTOS) helps detect software problems.\u003c/p\u003e\n\u003clite-youtube videoid=\"CwNRY8tOgOo\" playlabel=\"CwNRY8tOgOo\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"Memory Analyzer for VxWorks Platform Deep Dive","type":"video"},{"content":"","date":"2025-04-24","externalUrl":null,"permalink":"/tags/cpu-profiler/","section":"Tags","summary":"","title":"CPU Profiler","type":"tags"},{"content":"A demonstration of how Workbench\u0026rsquo;s CPU Profiler on VxWorks® real-time operating system (RTOS) helps detect software problems.\n","date":"2025-04-24","externalUrl":null,"permalink":"/video/cpu-profiler-for-vxworks-platforms-deep-dive/","section":"Videoes","summary":"\u003cp\u003eA demonstration of how Workbench\u0026rsquo;s CPU Profiler on VxWorks® real-time operating system (RTOS) helps detect software problems.\u003c/p\u003e\n\u003clite-youtube videoid=\"qeMIAgHj8sM\" playlabel=\"qeMIAgHj8sM\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"CPU Profiler for VxWorks Platforms Deep Dive","type":"video"},{"content":" Introduction # In fields like industrial control, data acquisition, and communications, PCIe controllers from PLX (now part of Broadcom) are widely used. VxWorks 7, the latest real-time operating system from Wind River, introduces a modernized and modular driver framework called VxBus 2.0. This article walks through the process of developing a PCIe device driver for VxWorks 7 using a PLX controller such as the PLX8725, including practical code examples.\nOverview of the VxBus 2.0 Driver Model # VxBus is the official driver framework in VxWorks. VxBus 2.0, introduced in VxWorks 7, brings several improvements:\nObject-oriented and layered architecture Dynamic device plug-and-play support Better SMP (multi-core) support Compatibility with Flattened Device Tree (FDT) A typical driver in VxBus 2.0 includes:\nA probe function to match supported devices An attach function to map hardware resources and register interrupts A detach function (optional) to release resources Public API functions for application interaction About the PLX PCIe Controller (e.g., PLX8725) # PLX PCIe switches and bridges, such as the PLX8725 or PLX8749, offer:\nMultiple BARs (Base Address Registers) for register mapping MSI/MSI-X interrupt support A built-in DMA engine Hot-plug capabilities and event signaling These devices are typically detected and initialized via PCI configuration space in VxWorks.\nOptional Device Tree Configuration # When using Device Tree (FDT), a PCIe node can be described like this:\npcie@0x80000000 { compatible = \u0026#34;plx,pcie8725\u0026#34;; reg = \u0026lt;0x80000000 0x1000\u0026gt;; // BAR region interrupts = \u0026lt;32\u0026gt;; // IRQ number }; In the driver, APIs such as vxbFdtDevGet() and vxbResourceAlloc() are used to retrieve these resources.\nVxBus Driver Code Framework # Header File: plxPcieDrv.h\n#define PLX_VENDOR_ID 0x10B5 #define PLX_DEVICE_ID 0x8725 typedef struct { VXB_DEV_ID dev; void * barBase; int irq; VXB_RESOURCE * pResBar; VXB_RESOURCE * pResIrq; } PLX_PCIE_DRV_CTRL; Driver Implementation: plxPcieDrv.c\nLOCAL STATUS plxPcieProbe(VXB_DEV_ID dev) { UINT16 vendorId, deviceId; vxbPciConfigRead16(dev, PCI_CFG_VENDOR_ID, \u0026amp;vendorId); vxbPciConfigRead16(dev, PCI_CFG_DEVICE_ID, \u0026amp;deviceId); return (vendorId == PLX_VENDOR_ID \u0026amp;\u0026amp; deviceId == PLX_DEVICE_ID) ? OK : ERROR; } LOCAL STATUS plxPcieAttach(VXB_DEV_ID dev) { PLX_PCIE_DRV_CTRL *pCtrl = vxbMemAlloc(sizeof(*pCtrl)); if (!pCtrl) return ERROR; pCtrl-\u0026gt;dev = dev; pCtrl-\u0026gt;pResBar = vxbResourceAlloc(dev, VXB_RES_MEMORY, 0); pCtrl-\u0026gt;barBase = (void *)vxbResourceVirtAdrsGet(pCtrl-\u0026gt;pResBar); pCtrl-\u0026gt;pResIrq = vxbResourceAlloc(dev, VXB_RES_IRQ, 0); pCtrl-\u0026gt;irq = (int)(long)vxbResourceAdrsGet(dev, VXB_RES_IRQ, 0); vxbDevSoftcSet(dev, pCtrl); vxbIntConnect(dev, pCtrl-\u0026gt;pResIrq, plxPcieIsr, pCtrl); vxbIntEnable(dev, pCtrl-\u0026gt;pResIrq); return OK; } LOCAL void plxPcieIsr(void *param) { PLX_PCIE_DRV_CTRL *pCtrl = (PLX_PCIE_DRV_CTRL *)param; UINT32 status = *(volatile UINT32 *)(pCtrl-\u0026gt;barBase + 0x04); *(volatile UINT32 *)(pCtrl-\u0026gt;barBase + 0x04) = status; // Custom interrupt handling here } Driver registration section:\nLOCAL VXB_DRV plxPcieDrv = { {NULL}, \u0026#34;plxPcie\u0026#34;, \u0026#34;PLX PCIe Driver\u0026#34;, VXB_BUSID_PCI, 0, 0, plxPcieProbe, plxPcieAttach, NULL }; VXB_DRV_DEF(plxPcieDrv) VXB_DRV_MOD_INSTALL(plxPcieDrv) Debugging Tips # View PCI configuration: -\u0026gt; vxbPciShow() List registered devices: -\u0026gt; vxbDevShow() Print BAR and IRQ: printf(\u0026#34;BAR0 base: 0x%x, IRQ: %d\\n\u0026#34;, pCtrl-\u0026gt;barBase, pCtrl-\u0026gt;irq); Use WindView to trace interrupt latency Recommended Extensions # Enable DMA transfer using vxbDma* interfaces Add user-space interface via ioctl or shared memory Support for hot-plug events and multiple BARs Conclusion # Combining VxWorks 7 with PLX PCIe controllers enables high-performance, real-time communication. With the modular VxBus 2.0 framework and Device Tree support, driver development becomes clean and scalable. This guide and starter code should serve as a strong foundation for your own PCIe driver development.\n","date":"2025-04-22","externalUrl":null,"permalink":"/bsp/practical-pcie-device-driver-development-on-vxworks-7/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn fields like industrial control, data acquisition, and communications, PCIe controllers from PLX (now part of Broadcom) are widely used. \u003ca href=\"https://www.vxworks7.com\" target=\"_blank\"\u003eVxWorks 7\u003c/a\u003e, the latest real-time operating system from Wind River, introduces a modernized and modular driver framework called VxBus 2.0. This article walks through the process of developing a PCIe device driver for VxWorks 7 using a PLX controller such as the PLX8725, including practical code examples.\u003c/p\u003e","title":"Practical PCIe Device Driver Development on VxWorks 7 with VxBus 2.0","type":"bsp"},{"content":"","date":"2025-04-22","externalUrl":null,"permalink":"/series/app/","section":"Series","summary":"","title":"APP","type":"series"},{"content":"VxWorks 7, a powerful real-time operating system (RTOS), offers a robust environment for developing embedded systems with networking capabilities. Its reliable and deterministic nature makes it ideal for applications ranging from industrial control to aerospace. This article will guide you through the fundamentals of network programming in VxWorks 7, complete with a practical code example and a detailed explanation.\nUnleashing Network Power with the BSD Socket API # At the heart of VxWorks 7\u0026rsquo;s networking stack lies the widely adopted Berkeley Sockets (BSD) API. This familiar interface provides a standardized way for applications to communicate over various network protocols, primarily TCP/IP. Whether you\u0026rsquo;re building a device that needs to send sensor data, receive commands, or interact with cloud services, understanding the BSD socket API is your first step.\nKey concepts within the BSD socket API include:\nSockets: Think of a socket as an endpoint for network communication. It\u0026rsquo;s a combination of an IP address and a port number. Protocols: These are the rules governing data exchange. TCP (Transmission Control Protocol) offers reliable, connection-oriented communication, while UDP (User Datagram Protocol) provides a faster, connectionless alternative. Addresses: Network addresses, typically IPv4 or IPv6, uniquely identify devices on a network. Ports: Ports are virtual channels within a device, allowing multiple applications to share the same network interface. A Practical Example: A Simple UDP Echo Server # Let\u0026rsquo;s illustrate network programming in VxWorks 7 with a basic UDP echo server. This server will listen for incoming UDP packets on a specific port and send the received data back to the sender.\n#include \u0026lt;stdio.h\u0026gt; #include \u0026lt;string.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; #include \u0026lt;sys/socket.h\u0026gt; #include \u0026lt;netinet/in.h\u0026gt; #include \u0026lt;arpa/inet.h\u0026gt; #define SERVER_PORT 12345 #define MAX_BUFFER_SIZE 1024 void udpEchoServer() { int sockfd; struct sockaddr_in serverAddr, clientAddr; socklen_t clientAddrLen = sizeof(clientAddr); char buffer[MAX_BUFFER_SIZE]; ssize_t bytesReceived; // 1. Create a UDP socket if ((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) \u0026lt; 0) { perror(\u0026#34;socket creation failed\u0026#34;); return; } // 2. Configure the server address memset(\u0026amp;serverAddr, 0, sizeof(serverAddr)); serverAddr.sin_family = AF_INET; serverAddr.sin_addr.s_addr = INADDR_ANY; // Listen on all available interfaces serverAddr.sin_port = htons(SERVER_PORT); // Convert port to network byte order // 3. Bind the socket to the server address if (bind(sockfd, (const struct sockaddr *)\u0026amp;serverAddr, sizeof(serverAddr)) \u0026lt; 0) { perror(\u0026#34;bind failed\u0026#34;); close(sockfd); return; } printf(\u0026#34;UDP Echo Server listening on port %d...\\n\u0026#34;, SERVER_PORT); while (1) { // 4. Receive data from a client if ((bytesReceived = recvfrom(sockfd, buffer, MAX_BUFFER_SIZE, 0, (struct sockaddr *)\u0026amp;clientAddr, \u0026amp;clientAddrLen)) \u0026lt; 0) { perror(\u0026#34;recvfrom failed\u0026#34;); continue; } printf(\u0026#34;Received %zd bytes from %s:%d\\n\u0026#34;, bytesReceived, inet_ntoa(clientAddr.sin_addr), ntohs(clientAddr.sin_port)); // 5. Send the received data back to the client if (sendto(sockfd, buffer, bytesReceived, 0, (const struct sockaddr *)\u0026amp;clientAddr, clientAddrLen) != bytesReceived) { perror(\u0026#34;sendto failed\u0026#34;); } else { printf(\u0026#34;Echoed %zd bytes back to the client.\\n\u0026#34;, bytesReceived); } } // 6. Close the socket (this part will likely not be reached in this simple server) close(sockfd); } Detailed Explanation: # Include Headers: We include necessary header files for socket programming (sys/socket.h, netinet/in.h, arpa/inet.h), standard input/output (stdio.h), string manipulation (string.h), and POSIX operating system API (unistd.h).\nDefine Constants: SERVER_PORT specifies the port number the server will listen on (12345 in this case), and MAX_BUFFER_SIZE defines the maximum size of the data buffer.\nudpEchoServer() Function: This function encapsulates the logic of our UDP echo server.\nCreate a Socket: socket(AF_INET, SOCK_DGRAM, 0) creates a socket. AF_INET specifies the Internet Protocol version 4 (IPv4) address family. SOCK_DGRAM indicates that we are using UDP (datagram) sockets. The third argument is the protocol, which is 0 for the default protocol associated with SOCK_DGRAM (which is UDP). The function returns a file descriptor (sockfd) representing the socket. A negative value indicates an error. Configure Server Address: struct sockaddr_in serverAddr; declares a structure to hold the server\u0026rsquo;s address information. memset(\u0026amp;serverAddr, 0, sizeof(serverAddr)); initializes the structure to zero. serverAddr.sin_family = AF_INET; sets the address family to IPv4. serverAddr.sin_addr.s_addr = INADDR_ANY; tells the server to listen on all available network interfaces of the system. serverAddr.sin_port = htons(SERVER_PORT); sets the server\u0026rsquo;s port number. htons() converts the port number from host byte order to network byte order, which is crucial for network communication. Bind the Socket: bind(sockfd, (const struct sockaddr *)\u0026amp;serverAddr, sizeof(serverAddr)) associates the created socket (sockfd) with the configured server address (serverAddr). This step is essential for the server to receive incoming connections or data on the specified address and port. A negative return value indicates an error during the binding process. Receive Data: The while (1) loop makes the server continuously listen for incoming data.\nrecvfrom(sockfd, buffer, MAX_BUFFER_SIZE, 0, (struct sockaddr *)\u0026amp;clientAddr, \u0026amp;clientAddrLen) waits for a UDP packet to arrive on the socket.\nbuffer is the memory area where the received data will be stored. MAX_BUFFER_SIZE is the maximum number of bytes to receive. The flags argument is 0 for basic receiving. (struct sockaddr *)\u0026amp;clientAddr and \u0026amp;clientAddrLen are used to store the address information (IP address and port) of the client that sent the data. recvfrom() returns the number of bytes received or a negative value if an error occurred. Send Data Back (Echo): sendto(sockfd, buffer, bytesReceived, 0, (const struct sockaddr *)\u0026amp;clientAddr, clientAddrLen) sends the received data back to the client from whom it was received. The arguments are similar to recvfrom(), but here clientAddr and clientAddrLen specify the destination address. sendto() returns the number of bytes sent or a negative value on error. Close Socket: close(sockfd) closes the socket, releasing the resources associated with it. In this simple server, this line might not be reached as the while(1) loop runs indefinitely. In a more sophisticated application, you would have mechanisms to gracefully shut down the server. Building and Running on VxWorks 7 # To build and run this code on a VxWorks 7 target, you would typically:\nDevelop on a Host Machine: Write and compile the code on a development host using the appropriate VxWorks 7 development tools and SDK. Ensure your project is configured to include the necessary networking libraries.\nTransfer to Target: Transfer the compiled executable to your VxWorks 7 target system (e.g., via FTP, TFTP, or a debugging interface).\nExecute on Target: Run the executable on the VxWorks 7 target, likely through the VxWorks shell or a custom application launcher.\nYou would then need a separate UDP client application running on another machine or even on the same target (in a different task) to send data to the server\u0026rsquo;s IP address and port (e.g., using tools like netcat or writing a simple client program).\nTCP Communication: A Server and Client Example # TCP (Transmission Control Protocol) provides reliable, ordered, and connection-oriented communication. This makes it suitable for applications where data integrity is paramount, such as file transfer, web services, and remote control.\nTCP Server Code: # #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;string.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; #include \u0026lt;sys/socket.h\u0026gt; #include \u0026lt;netinet/in.h\u0026gt; #include \u0026lt;arpa/inet.h\u0026gt; #define SERVER_PORT 5000 #define MAX_BUFFER_SIZE 1024 void tcpServer() { int serverFd, clientFd; struct sockaddr_in serverAddr, clientAddr; socklen_t clientAddrLen = sizeof(clientAddr); char buffer[MAX_BUFFER_SIZE]; ssize_t bytesReceived, bytesSent; // 1. Create a TCP socket if ((serverFd = socket(AF_INET, SOCK_STREAM, 0)) \u0026lt; 0) { perror(\u0026#34;socket creation failed\u0026#34;); return; } // 2. Configure the server address memset(\u0026amp;serverAddr, 0, sizeof(serverAddr)); serverAddr.sin_family = AF_INET; serverAddr.sin_addr.s_addr = INADDR_ANY; serverAddr.sin_port = htons(SERVER_PORT); // 3. Bind the socket to the server address if (bind(serverFd, (struct sockaddr *)\u0026amp;serverAddr, sizeof(serverAddr)) \u0026lt; 0) { perror(\u0026#34;bind failed\u0026#34;); close(serverFd); return; } // 4. Listen for incoming connections if (listen(serverFd, 5) \u0026lt; 0) { // Listen queue size of 5 perror(\u0026#34;listen failed\u0026#34;); close(serverFd); return; } printf(\u0026#34;TCP Server listening on port %d...\\n\u0026#34;, SERVER_PORT); while (1) { printf(\u0026#34;Waiting for a client connection...\\n\u0026#34;); // 5. Accept a client connection if ((clientFd = accept(serverFd, (struct sockaddr *)\u0026amp;clientAddr, \u0026amp;clientAddrLen)) \u0026lt; 0) { perror(\u0026#34;accept failed\u0026#34;); continue; } printf(\u0026#34;Client connected from %s:%d\\n\u0026#34;, inet_ntoa(clientAddr.sin_addr), ntohs(clientAddr.sin_port)); // 6. Communication loop with the client while ((bytesReceived = recv(clientFd, buffer, MAX_BUFFER_SIZE, 0)) \u0026gt; 0) { printf(\u0026#34;Received %zd bytes: %.*s\u0026#34;, bytesReceived, (int)bytesReceived, buffer); // Echo back the received data bytesSent = send(clientFd, buffer, bytesReceived, 0); if (bytesSent \u0026lt; 0) { perror(\u0026#34;send failed\u0026#34;); break; // Exit inner loop on send error } printf(\u0026#34;Echoed %zd bytes back to the client.\\n\u0026#34;, bytesSent); } if (bytesReceived == 0) { printf(\u0026#34;Client disconnected.\\n\u0026#34;); } else if (bytesReceived \u0026lt; 0) { perror(\u0026#34;recv failed\u0026#34;); } // 7. Close the client socket close(clientFd); } // 8. Close the server socket (this part might not be reached in this simple server) close(serverFd); } TCP Client Code: # #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;string.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; #include \u0026lt;sys/socket.h\u0026gt; #include \u0026lt;netinet/in.h\u0026gt; #include \u0026lt;arpa/inet.h\u0026gt; #define SERVER_IP \u0026#34;127.0.0.1\u0026#34; // Replace with the actual server IP address #define SERVER_PORT 5000 #define MAX_BUFFER_SIZE 1024 void tcpClient() { int clientFd; struct sockaddr_in serverAddr; char buffer[MAX_BUFFER_SIZE]; ssize_t bytesRead, bytesSent; // 1. Create a TCP socket if ((clientFd = socket(AF_INET, SOCK_STREAM, 0)) \u0026lt; 0) { perror(\u0026#34;socket creation failed\u0026#34;); return; } // 2. Configure the server address memset(\u0026amp;serverAddr, 0, sizeof(serverAddr)); serverAddr.sin_family = AF_INET; serverAddr.sin_port = htons(SERVER_PORT); if (inet_pton(AF_INET, SERVER_IP, \u0026amp;serverAddr.sin_addr) \u0026lt;= 0) { perror(\u0026#34;inet_pton failed for IP address\u0026#34;); close(clientFd); return; } // 3. Connect to the server if (connect(clientFd, (struct sockaddr *)\u0026amp;serverAddr, sizeof(serverAddr)) \u0026lt; 0) { perror(\u0026#34;connect failed\u0026#34;); close(clientFd); return; } printf(\u0026#34;Connected to server %s:%d\\n\u0026#34;, SERVER_IP, SERVER_PORT); // 4. Communication loop with the server while (1) { printf(\u0026#34;Enter message to send (or \u0026#39;quit\u0026#39; to exit): \u0026#34;); fgets(buffer, MAX_BUFFER_SIZE, stdin); // Remove trailing newline from fgets size_t len = strlen(buffer); if (len \u0026gt; 0 \u0026amp;\u0026amp; buffer[len - 1] == \u0026#39;\\n\u0026#39;) { buffer[len - 1] = \u0026#39;\\0\u0026#39;; } if (strcmp(buffer, \u0026#34;quit\u0026#34;) == 0) { break; } // Send data to the server bytesSent = send(clientFd, buffer, strlen(buffer), 0); if (bytesSent \u0026lt; 0) { perror(\u0026#34;send failed\u0026#34;); break; } printf(\u0026#34;Sent %zd bytes to server: %s\\n\u0026#34;, bytesSent, buffer); // Receive response from the server bytesRead = recv(clientFd, buffer, MAX_BUFFER_SIZE - 1, 0); if (bytesRead \u0026gt; 0) { buffer[bytesRead] = \u0026#39;\\0\u0026#39;; // Null-terminate the received data printf(\u0026#34;Received %zd bytes from server: %s\\n\u0026#34;, bytesRead, buffer); } else if (bytesRead == 0) { printf(\u0026#34;Server closed the connection.\\n\u0026#34;); break; } else { perror(\u0026#34;recv failed\u0026#34;); break; } } // 5. Close the client socket close(clientFd); printf(\u0026#34;Connection closed.\\n\u0026#34;); } Detailed Explanation: # TCP Server (tcpServer()): # Create a TCP Socket: Similar to UDP, we use socket(), but this time with SOCK_STREAM to indicate a TCP socket.\nConfigure Server Address: The process of setting up the server address structure (serverAddr) is the same as in the UDP example.\nBind the Socket: We associate the socket with the server\u0026rsquo;s IP address and port using bind().\nListen for Connections:\nlisten(serverFd, 5) puts the server socket into a passive listening mode. It tells the operating system to listen for incoming connection requests on the bound address and port. The second argument (5 in this case) specifies the maximum number of pending connection requests that can be queued. Accept a Client Connection: accept(serverFd, (struct sockaddr *)\u0026amp;clientAddr, \u0026amp;clientAddrLen) blocks until a client attempts to connect to the server. When a connection request arrives, accept() creates a new socket (clientFd) specifically for communication with that client. The original serverFd remains listening for further connections. clientAddr and clientAddrLen are populated with the address information of the connecting client. Communication Loop: The while ((bytesReceived = recv(clientFd, buffer, MAX_BUFFER_SIZE, 0)) \u0026gt; 0) loop handles data exchange with the connected client. recv(clientFd, buffer, MAX_BUFFER_SIZE, 0) reads data from the connected client socket. It will block until data is available. If recv() returns a positive value, data was received. If it returns 0, the client has closed the connection gracefully. If it returns a negative value, an error occurred. send(clientFd, buffer, bytesReceived, 0) sends the received data back to the client (echo). Close Client Socket: Once the communication with a client is finished (either the client closed the connection or an error occurred), close(clientFd) closes the socket associated with that specific client.\nClose Server Socket: The outer close(serverFd) would typically be called if the server needs to shut down entirely. In this simple infinite loop server, it might not be reached.\nTCP Client (tcpClient()): # Create a TCP Socket: Similar to the server, the client creates a TCP socket using socket(AF_INET, SOCK_STREAM, 0).\nConfigure Server Address:\nWe set up the serverAddr structure with the server\u0026rsquo;s IP address (SERVER_IP) and port (SERVER_PORT). inet_pton(AF_INET, SERVER_IP, \u0026amp;serverAddr.sin_addr) converts the human-readable IP address string into a binary form suitable for the sockaddr_in structure. Connect to the Server: connect(clientFd, (struct sockaddr *)\u0026amp;serverAddr, sizeof(serverAddr)) attempts to establish a connection with the server at the specified address and port. connect() will block until the connection is established or an error occurs (e.g., the server is not listening). Communication Loop: The while (1) loop allows the client to send messages to the server and receive responses. fgets(buffer, MAX_BUFFER_SIZE, stdin) reads input from the user. The trailing newline character from fgets is removed. If the user enters \u0026ldquo;quit\u0026rdquo;, the loop breaks, and the client closes the connection. send(clientFd, buffer, strlen(buffer), 0) sends the user\u0026rsquo;s message to the connected server. recv(clientFd, buffer, MAX_BUFFER_SIZE - 1, 0) waits for and receives a response from the server. The received data is null-terminated to be treated as a C string. The loop checks for different return values of recv() to handle data received, server disconnection, or errors. Close Client Socket: close(clientFd) closes the client\u0026rsquo;s socket, terminating the connection with the server.\nBuilding and Running: # You would compile these two code snippets separately for your VxWorks 7 environment. Ensure that the server executable is running on your target system before you run the client executable (which might be on the same target in a different task or on a separate machine with network connectivity to the target). Remember to replace \u0026ldquo;127.0.0.1\u0026rdquo; in the client code with the actual IP address of your VxWorks 7 target if the client is running on a different machine.\nThis TCP example provides a fundamental building block for more complex networked applications in VxWorks 7. You can expand upon this by implementing different communication protocols, handling multiple client connections on the server side using threads, and incorporating more sophisticated data processing.\nFurther Exploration # This example provides a basic introduction. Network programming in VxWorks 7 offers a wealth of possibilities:\nTCP Communication: For reliable, connection-oriented communication, explore the socket() with SOCK_STREAM, listen(), accept(), connect(), send(), and recv() functions. Multithreading: For handling multiple client connections concurrently, you\u0026rsquo;ll likely need to use VxWorks threads (taskSpawn()) to manage each connection. Network Protocols: VxWorks 7 supports various network protocols beyond UDP and TCP, such as IPsec, SNMP, and more. Network Interfaces: Understanding how to configure and manage network interfaces on your VxWorks target is crucial. Error Handling: Robust network applications require careful error handling to gracefully manage network issues. Conclusion # Network programming in VxWorks 7 empowers embedded systems to interact with the wider world. By leveraging the familiar BSD socket API and understanding the fundamental concepts, developers can build sophisticated and reliable networked applications on this powerful RTOS. This simple UDP echo server serves as a stepping stone for exploring the exciting possibilities of connecting your VxWorks 7 devices.\n","date":"2025-04-22","externalUrl":null,"permalink":"/app/diving-into-network-programming-with-vxworks-7/","section":"Apps","summary":"\u003cp\u003e\u003ca href=\"https://www.vxworks7.com\" target=\"_blank\"\u003eVxWorks 7\u003c/a\u003e, a powerful real-time operating system (RTOS), offers a robust environment for developing embedded systems with networking capabilities. Its reliable and deterministic nature makes it ideal for applications ranging from industrial control to aerospace. This article will guide you through the fundamentals of network programming in VxWorks 7, complete with a practical code example and a detailed explanation.\u003c/p\u003e","title":"Diving Into Network Programming With VxWorks 7","type":"app"},{"content":"","date":"2025-04-22","externalUrl":null,"permalink":"/tags/socket/","section":"Tags","summary":"","title":"Socket","type":"tags"},{"content":" Introduction # VxWorks, developed by Wind River, is a real-time operating system (RTOS) that supports secure user authentication. This guide outlines the configuration steps required to enable secure user login for a VxWorks 7 target. Once properly configured, users must authenticate with valid credentials before accessing the VxWorks kernel shell.\nPrerequisites # This procedure assumes the following environment:\nWind River VxWorks 7 (SR0620) Host system: Windows workstation Reference Documentation # For more detailed information, refer to the VxWorks 7 Security Programmer’s Guide provided by Wind River.\nCreating and Building the VxWorks Source Build (VSB) Project # Begin by launching a command shell and setting up the build environment:\ncd \u0026lt;WIND_HOME\u0026gt; // Navigate to your Wind River installation directory wrenv -p vxworks-7 cd \u0026lt;YOUR_WORKSPACE\u0026gt; // Navigate to your VxWorks workspace vxprj vsb create users_vsb -bsp vxsim_windows -smp -force -S cd users_vsb // Add required user management components vxprj vsb add USER_MANAGEMENT vxprj vsb add USER_MANAGEMENT_POLICY vxprj vsb add USER_MANAGEMENT_USER_PRIVILEGES make -j 32 // Build the VSB Creating and Building the VxWorks Image Project (VIP) # To create and configure the VIP, follow these steps:\ncd .. vxprj create -smp vxsim_windows users_vip -profile PROFILE_DEVELOPMENT -vsb users_vsb cd users_vip // Add required components to the VIP vxprj vip bundle add BUNDLE_STANDALONE_SHELL vxprj vip component add INCLUDE_USER_DATABASE vxprj vip component add INCLUDE_SHELL_SECURITY vxprj vip component add INCLUDE_LOGIN_POLICY // Set relevant parameters vxprj parameter set UDB_STORAGE_PATH \u0026#34;\\\u0026#34;host:vxUserDB.txt\\\u0026#34;\u0026#34; vxprj parameter set UDB_PROMPT_INITIAL_USER TRUE vxprj parameter set meta_UDB_HASH_KEY \u0026#34;\\\u0026#34;\\x48\\x61\\\u0026#34;\u0026#34; // Replace with your own unique hash key vxprj build Important: Rename meta_UDB_HASH_KEY to UDB_HASH_KEY and ensure that a unique key (preferably 256 bytes) is used for database encryption. This secures the integrity and confidentiality of the user credentials file.\nBooting VxWorks on the Target # Once the build is complete, boot the target using:\ncd default vxsim Upon successful boot, the VxWorks kernel shell will be available.\nInitial User Creation # The system will prompt you to create an initial user upon first boot:\n** Creation of initial user ** Initial user\u0026#39;s login: After providing and confirming the password, you’ll be asked to authenticate using the newly created credentials:\nlogin: From this point forward, access to the kernel shell will require valid login credentials.\nLogging In and Creating Additional Users # Authenticate using the initial user account, then proceed to create a second user from the kernel shell:\n-\u0026gt; userAdd \u0026#34;harmonicss\u0026#34;, \u0026#34;harmonicss\u0026#34; value = 0 = 0x0 -\u0026gt; logout login: You now have two distinct user accounts. The user database (vxUserDB.txt) is located in the VIP’s default directory (users_vip\\default\\vxUserDB.txt) and is referenced during login authentication. VxWorks supports user and group management, login time monitoring, and account maintenance. For further functionality, consult the VxWorks Security Programmer’s Guide.\nOptional: Mitigating a Potential Security Risk # Be aware that if the vxUserDB.txt file is deleted, the system will revert to prompting for the creation of a new initial user upon boot—introducing a potential security vulnerability. To safeguard against this:\nStore the user database on a secure, encrypted local file system partition Restrict access to prevent unauthorized modifications This is particularly critical for secure deployments that utilize the standard VxWorks kernel shell.\nOptional: Defining User-Specific Privileges # VxWorks provides granular control over shell-level permissions via user privilege configurations. To enable this feature:\ncd .. vxprj vip component add INCLUDE_USER_PRIVILEGES vxprj vip parameter set PRIVILEGE_MANIFEST_PATH \u0026#34;\\\u0026#34;host:\\privilege_manifest\\prvlgManifest.txt\\\u0026#34;\u0026#34; Edit the privilege manifest file as directed in its comments to define allowed operations per user. After editing, rebuild the VIP and reboot the target.\nNote: By default, users have no privileges assigned. Unless explicitly configured in the privilege manifest, all shell operations will return a privilege error—even if login succeeds.\n","date":"2025-04-18","externalUrl":null,"permalink":"/bsp/configuring-a-vxworks-7-system-with-secure-user-authentication/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eVxWorks, developed by Wind River, is a \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003ereal-time operating system\u003c/a\u003e (RTOS) that supports secure user authentication. This guide outlines the configuration steps required to enable secure user login for a \u003ca href=\"https://www.vxworks7.com\" target=\"_blank\"\u003eVxWorks 7\u003c/a\u003e target. Once properly configured, users must authenticate with valid credentials before accessing the VxWorks kernel shell.\u003c/p\u003e","title":"Configuring a VxWorks 7 System With Secure User Authentication","type":"bsp"},{"content":"Recently, we successfully assisted a client in integrating their pre-existing, operating system-agnostic middleware and device driver software into a VxWorks 7 project build environment. This integration allowed them to configure and generate various software versions tailored to different target boards and CPU architectures within Wind River Workbench, utilizing their established GNU Make-based build system. We leveraged VxWorks 7 subprojects, a valuable feature of the VxWorks 7 layer and package management system, to achieve this.\nUnderstanding VxWorks 7\u0026rsquo;s Structure: Components and Layers\nThe VxWorks real-time embedded operating system is constructed from distinct components and libraries. These elements are combined to form a kernel image, which the system loads during startup. A VxWorks Source Build (VSB) project is used to create these components and libraries, making them accessible to a VxWorks Image Project (VIP). The VIP, using board-specific configurations, generates a kernel image suitable for one or more target systems.\nThe VSB and VIP project model represents the standard method for building VxWorks images using the Eclipse-based Wind River Workbench development environment and its command-line tools. Workbench also facilitates the creation of application software projects that run on top of the operating system. Projects for software operating within the kernel\u0026rsquo;s address space are known as Downloadable Kernel Modules (DKMs), while those running in their own isolated address spaces are Real-time Process (RTP) projects. This setup is ideal for applications designed specifically for VxWorks and for development teams who rely on Workbench as their primary development platform.\nVxWorks 7\u0026rsquo;s Packaging System\nVxWorks 7 introduced a new source code packaging system, drawing inspiration from the RPM system used in Red Hat Linux distributions. Each OS module is packaged as an RPM with stringent versioning and dependency definitions, enabling effortless OS updates and extensions while minimizing dependency conflicts. Each module RPM defines a VxWorks Layer, which is transformed into a library by a VSB project build.\n(VxWorks Layers and Package Management Guide, copyright Wind River Systems 2021.)\nMany development teams utilize their own build environments with Make or similar tools. When integrating their software with a VxWorks target system, they typically consider these options:\nConstructing one or more VxWorks Layers to build the software into libraries, which are then linked into the kernel during a VIP build. Developing one or more Workbench DKM projects to produce partially-linked object modules, subsequently linked into the final kernel image during a VIP build. Creating one or more Workbench RTP projects to generate fully-linked ELF modules, which the VxWorks kernel loads and initiates at runtime. These options necessitate that the application software be structured in a manner compatible with the Workbench project build system, which may be impractical or undesirable for large codebases.\nThe Advantage of VxWorks 7 Subprojects\nFortunately, VxWorks 7 Subprojects offer an alternative approach. These subprojects, integral to the VxWorks 7 build system, possess properties that are particularly useful for incorporating third-party software with its own Makefiles and build rules.\nSoftware integrated as a VxWorks 7 Subproject:\nIs defined as a VxWorks Layer, complete with metadata for managing dependencies on other packages and layers. Provides VxWorks Component definitions, enabling the software\u0026rsquo;s inclusion in a VIP project, similar to a standard Layer. Is copied in its entirety into the VIP project space, allowing for the inclusion of board-specific definitions and configuration files. This method offers advantages over standard Workbench project types:\nThe existing software organization remains unchanged. The software is built using its native Makefiles within the VIP project build. However, challenges exist. While the VxWorks Layers and Package Management Guide provides an overview and basic examples of the subproject mechanism, it lacks detailed coverage of the use case described here.\nEssential Development Tasks\nThe VxWorks Subproject mechanism is not a simple solution for porting legacy software to VxWorks 7. Developers must still:\nCreate a Layer definition for the software. Ensure the software compiles using the VxWorks 7 compiler. Develop Component Definition Files (CDFs) to enable the selection of individual modules for inclusion in the kernel image. Create initialisation routines for each module (VxWorks 7 configlettes) that are invoked by kernel during startup. Furthermore, debugging the Subproject build can be challenging due to the complexity of the VxWorks 7 build system\u0026rsquo;s rules. In conclusion, while this approach proved effective for our client\u0026rsquo;s specific software porting needs, the standard VxWorks 7 development model remains the preferred method whenever feasible.\n","date":"2025-04-07","externalUrl":null,"permalink":"/app/integrating-existing-software-into-vxworks-7-using-subprojects/","section":"Apps","summary":"\u003cp\u003eRecently, we successfully assisted a client in integrating their pre-existing, operating system-agnostic middleware and device driver software into a VxWorks 7 project build environment. This integration allowed them to configure and generate various software versions tailored to different target boards and CPU architectures within Wind River Workbench, utilizing their established GNU Make-based build system. We leveraged VxWorks 7 subprojects, a valuable feature of the \u003ca href=\"https://www.vxworks7.com\" target=\"_blank\"\u003eVxWorks 7\u003c/a\u003e layer and package management system, to achieve this.\u003c/p\u003e","title":"Integrating Existing Software Into VxWorks 7 Using Subprojects","type":"app"},{"content":"","date":"2025-04-07","externalUrl":null,"permalink":"/tags/subproject/","section":"Tags","summary":"","title":"Subproject","type":"tags"},{"content":"","date":"2025-04-06","externalUrl":null,"permalink":"/tags/defence/","section":"Tags","summary":"","title":"Defence","type":"tags"},{"content":"Wind River®, a global leader in delivering software for the intelligent edge, today announced that Leonardo, one of the world’s leading players in the aerospace, defense, and security sector, has selected VxWorks real-time operating system (RTOS) to deliver software-defined advancements for its state-of-the-art safety-related radio frequency (RF) system on multicore processor architectures.\nTo address the challenge of using different multi-core processor architectures for individual system functions within the Leonardo RF system, the company is using VxWorks to provide a common application runtime environment across processor architectures. Leonardo is developing applications to run on VxWorks and will undergo DO-178C DAL C certification.\n“As multi-core processors drive an increasingly software-defined world, new opportunities are emerging to advance aerospace and defense systems,” said Jay Bellissimo, president, Wind River. “VxWorks delivers unrivaled deterministic high performance, setting the standard for a scalable, safe, secure, and reliable operating environment for mission-critical computing. Together with Leonardo, we can help companies navigate a shifting technology landscape—extending the performance and lifespan of their systems while reducing program and certification risk.”\nVxWorks provides flexible single-core and multi-core support on different architectures, enabling individual systems to be configured depending on application performance requirements and safety certification requirements. Proven in the most challenging safety-critical applications, Wind River technology makes it easier and more cost-effective for organizations to meet the stringent safety certification requirements of EN 50128, IEC 61508, ISO 26262 and DO-178C / ED-12C.\nThe first and only commercial RTOS to support Open Container Initiative (OCI)–compliant containers, VxWorks OCI container implementation uses a lightweight minimal footprint combined with VxWorks Real-Time Processes (RTP). This enables the development of containerized applications on VxWorks and can enable Leonardo to rapidly deploy new software-defined capabilities.\nLeonardo is one of the largest aerospace and defense companies in Europe, investing in innovation within industry, academia and government in capability areas including data and artificial intelligence, sensing and protection, electronic warfare, future aviation, uncrewed systems, and space.\nAbout Wind River\nWind River is a global leader in delivering software for the intelligent edge. For more than four decades, the company has been an innovator and pioneer, powering billions of devices and systems that require the highest levels of security, safety, and reliability. Wind River software and expertise are accelerating digital transformation across industries, including automotive, aerospace, defense, industrial, medical, and telecommunications. The company offers a comprehensive portfolio supported by world-class global professional services and support and a broad partner ecosystem. With technology proven in over 750 safety programs in more than 120 civilian and military aircraft, Wind River is driving the transition to software-defined systems in aerospace and defense.\n","date":"2025-04-06","externalUrl":null,"permalink":"/news/leonardo-selects-wind-river-vxworks-to-deliver-software-defined-advancements/","section":"News","summary":"\u003cp\u003eWind River®, a global leader in delivering software for the intelligent edge, today announced that Leonardo, one of the world’s leading players in the aerospace, defense, and security sector, has selected VxWorks real-time operating system (RTOS) to deliver software-defined advancements for its state-of-the-art safety-related radio frequency (RF) system on multicore processor architectures.\u003c/p\u003e","title":"Leonardo Selects Wind River VxWorks to Deliver Software Defined Advancements","type":"news"},{"content":"","date":"2025-04-04","externalUrl":null,"permalink":"/tags/performance/","section":"Tags","summary":"","title":"Performance","type":"tags"},{"content":" By Benjamin Ip | COMS W4995-2, Languages of Embedded Systems Department of Computer Science, Columbia University, NY\nAbstract # This paper compares and evaluates the suitability of two real-time operating systems, the commercially available VxWorks and the publicly available RTLinux. Holding the hardware constant and using different measurement methodologies, we measured the overheads incurred during operating systems context switching, interrupt processing, object synchronization, and message passing. We also examine their effectiveness in terms of how they handle priority inversion problem.\nOur finding illustrates that both VxWorks and RTLinux provide good raw performance.\nHowever, VxWorks is more predictable and deterministic, thereby making it more suitable as an operating system platform for developing and running soft and hard real-time applications.\nIntroduction # Overview of VxWorks # VxWorks is by far the most widely adopted commercial RTOS in the embedded industry. It is developed by WindRiver with the intention to design an operating system with fast, efficient, and deterministic context switching. Its Wind micro-kernel can support preemptive and round robin scheduling policies, and unlimited number of tasks with a maximum of 256 priority levels. VxWorks is also well known for its rich tool chain and run time library that significantly reduce the amount of time for application development. Despite the extensive features from VxWorks, it bares a high premium for royalty fee.\nOverview of RTLinux # Unlike Linux, RTLinux provides hard real-time capability. It has a hybrid kernel architecture with a small real-time kernel coexists with the Linux kernel running as the lowest priority task. This combination allows RTLinux to provide highly optimized, time-shared services in parallel with the real-time, predictable, and low-latency execution. Besides this unique feature, RTLinux is freely available to the public1. As more development tools are geared towards RTLinux, it will become a dominant player in the embedded market.\n1 RTLinux is distributed by Finite State Machine Performance Metrics # Our project goal is to study the performance analysis of these two operating systems by measuring the following key metrics.\nContext Switch # Both RTOSes are designed to support multitasking. This feature is important for real- time applications that are frequently implemented with multiple asynchronous tasks of execution. During task scheduling, a context switch is needed to suspend one task and immediately resume the other. Therefore, it is fundamental to analyze the average context switch latency in order to measure operating systems responsiveness.\nPriority Inversion # Priority inversion occurs when a high-priority task is blocked, waiting for a low-priority task to release a resource shared by the high priority task. Priority inversion is a serious problem in real-time system since it often leads to deadlock. Both RTOSes incorporate their own priority inheritance protocol and one of the project goals is to examine the effectiveness of these protocols.\nInterrupt Latency # Interrupt Latency is defined as the sum of interrupt blocking time during which the kernel is pending to respond to an interrupt, saving the tasks context, determining the interrupt source, and invoking the interrupt handler. For a particular interrupt, the latency also includes the execution time of other nested interrupt handlers. Since most embedded systems are interrupt-driven, low interrupt latency will drastically increase system throughput.\nSynchronization # A full suite of synchronization methods is provided by VxWorks and RTLinux to allow exclusive access of shared resources. Acquiring and releasing semaphores to protect shared objects do incur penalty. Such penalty is often associated with adding and removing the requested tasks into and out of the object lock queues. As such, measuring synchronization overhead is another way to determine the viability of a real-time operating system.\nInter-Process Communications # Modern real-time applications are constructed as a set of independent, cooperative tasks. Along with high-speed semaphores, VxWorks and RTLinux also provide message queue as higher- level synchronization mechanism to allow cooperating tasks to communicate with each other. Because of the implementation complexity, using this service imposes the greatest amount of latency and thus is a key metric to operating system study.\nMeasurement Process # Measuring the above metric requires certain degree of resolution, accuracy, and granularity. Throughout our project, both hardware and software logic analyzers were used to capture and record measurement samples. We emphasized on the use of the hardware logic analyzer because it gives the finest resolution, least obtrusion to real-time code, and more important it is platform independent. In most test cases the software analyzer was used for verification. We also developed small firmware code to setup the memory maps and interrupt vector tables, tune the system clock, and disable the hardware cache. All test functions and system calls written to initialize tasks, semaphores and message queues are POSIX compliant. Finally, each test was measured with a sample size of 25 to ensure that the data collected are statistically sound.\nTest Environment # Our tests are conducted under VxWorks version 5.4 and RTLinux version 3.0. We executed all of our tests on evaluation boards manufactured and its board support package. These significantly reduce development time spent on configuring the hardware.\nRelated Work # Performance Analysis of operating systems has long been an interesting subject among research groups. Levine [1] and his peers have presented their benchmark results on context switch time and priority inversion protocol latency of a real- time CORBA2 architecture. Levine’s [1] method of detecting and observing priority inversion is complicated. A straightforward way to create a priority inversion scenario is explained in Obenland’s [4] article and will be described in next section.\n2 Common Open Brokerage Architecture Sohal [3] took both the analytical and empirical approaches to measure different phases of interrupt latency of a real-time operating system. Due to time constraint, we chose only one of Sohal’s interrupt tests that typically reveals the performance of interrupt handling. However, we did not apply Sun’s [4] approach to measure interrupt latency because Linux interrupt mechanism is implemented vastly different from RTLinux (with no distinction of top and bottom half of interrupt service routine).\nWe also learnt from Obenland’s [2] experience that prior to executing any IPC test, the message queue should have no message pending and the receiving task must be blocked waiting for the message.\nIn Stewards [4] paper, he devoted much of his time to review and explain various measurement techniques that produce results of different granularity. We are convinced by Stewards [4] that hardware logic analyzer is preferable to other tools and techniques for measurements throughout the project.\nTest Methods and Experimental Results # We modified some of the test methods referenced in the previous section to achieve fair and accurate results. This section describes the measurement outcomes along with the methods that we used to test different metrics.\nContext Switch # We configured both RTOSes to use round-robin scheduling policy to determine context switch time. Figure 1 shows that with round-robin policy, we simply need to create two tasks and let the scheduler to execute them alternately, without the need of prioritizing them.\nFigure 1: Context Switch Test Setup Both tasks under test have the same function; each contains an infinite empty loop to avoid additional computation. Table 1 shows the average (and standard deviation) context switch time measured in microseconds.\nTable 1: Context Switch Time Measurements The context switch time measured on VxWorks is consistently low, with a standard deviation of 0.04. On the contrary, the RTLinux context switch time is 18% higher than and it is not as consistent (with std of 0.6) as VxWorks. Thus, context switch time for VxWorks is more deterministic. The lower score achieved by RTLinux seems to imply that running both real- time and non real-time tasks in parallel may not be the most feasible solution to embedded products.\nPriority Inversion # We created the priority inversion scenario by running three tasks at low, medium, and high priorities, with the low and high priority tasks competing for the same resource. Below is an occurrence of priority inversion (the yellow arrow) that captured from a software analyzer. The tCyclicTask, tWorkTask, and tSlowTask correspond to tasks with high, medium, and low priorities.\nFigure 2: Measuring Priority Inversion Using Software Analyzer We took several time measurements between tCyclicTask requesting the resource and tSlowTask releasing it, and the results are given in the table 2.\nTable 2: Priority Inversion Measurments An important characteristic of RTOSes is predictability. Although RTLinux takes less time to resolve a priority inversion problem, both figures appear to be in an acceptable range. This indicates that both RTOSes have implemented an effective priority inheritance protocol to ensure that critical deadlines are met.\nInterrupt Latency # In this experiment, we configured the MPC8260 hardware timer with a period of 50 MHz to generate a timer interrupt every 20 s. An interrupt service routine that updates a system tick count is hooked to the interrupt vector table. We use the hardware logic analyzer to measure the time between the assertion of the timer interrupt and the execution of the ISR (Figure 3).\nFigure 3: Interrupt Latency Test Setup Noticed that all other system interrupts are disabled so that our measurements are not affected by nested-interrupts. The average and standard deviation of both systems interrupt latencies are recorded in Table 3.\nTable 3: Interrupt Latency Measurements It is not surprised that VxWorks has much lower interrupt latency (35%) than RTLinux.\nTraditional Linux is notorious for having high interrupt latency. It appears that even though RTLinux had been added with real-time capability, it still exhibits some non real-time behaviour.\nSynchronization # In our test, we only focused on measuring the time to acquire a binary semaphore in both systems. To measure the semaphore overhead, we first created and initialized the semaphore itself to make it unavailable.\nFigure 4: Binary Semaphore Test Setup We then spawned two tasks to release and acquire the semaphore respectively, in the exact order. Finally, we measured the time (Figure 4) during which the task made the system call to acquire the semaphore. This task should not be blocked waiting since the first task should release the semaphore prior to execution of the second task. Table 4 shows the average overhead for VxWorks and RTLinux to successfully acquire a semaphore.\nTable 4: Binary Semaphores Take Measurements These figures show that the RTLinux takes slightly longer to obtain a binary semaphore than VxWorks.\nInter-Process Communication # This test is to measure the communication delay necessary for a task to send a message to another task via a message queue as shown in Figure 5.\nFigure 5: Message Queue Test Setup We began this test by creating and activating (or open) a message queue. Next, we spawned a receiving task from which the message receive function is invoked. The receive system call blocks the receiving task and put it in the wait state (since the message queue is empty). While the receiving task was waiting for the message, we spawned a sending task to send a message via the same message queue. The time between the sending task to call the message send function and the receiving task to receive message notification is given in Table 5.\nTable 5: Message Queue Measurements In terms of message send/receive latency, RTLinux achieves a better score than VxWorks by a small margin. As mentioned earlier, these figures can vary greatly depending on the IPC implementation (IPC can be implemented using shared memory).\nConclusions and Future Work # In this project, we measured several real-time operating system key metrics to evaluate the performance of VxWorks and RTLinux. The results presented in this paper roughly matches with the characteristics of the two operating systems. Our overall analysis shows that both operating systems are suitable for real-time application. In particular, VxWorks is more deterministic and predictable, Due to time constraint and limited resources, we can focused only on studying the heart of the operating system – the kernel level performance that unveil the true system behaviour. Modern real-time operating systems often packaged with powerful run-time libraries, scalable networking components and flexible file system. A broad range of tests that cover these aspects will provide us a comprehensive result in terms of performance versus cost. Thereby, it is difficult to conclude which operating system is superior to the other without an exhaustive comparison.\nBibliography # [1] D. Levine, S. Flores-Gaitan, C. D. Dill, and D. C. Schmidt, “Measuring OS Support for Real-Time CORBA ORBs”, in 4th IEEE International Workshop on Object-oriented Real-Time Dependable Systems 00’, Santa Babara, California, Jan. 27-29. [2] K. Obenland, “Real-Time Performance of Standards Based Commercial Operating Systems” [3] V. Sohal, “How To Really Measure Real- Time”, Embedded System Conference, Spring 2001 [4] Jun Sun, ”Interrupt Latency”, Monta Vista Software, https://www.mvista.com/realtime/latency/ [5] D. Stewart, “Measuring Execution Time and Real-Time Performance”, Embedded System Conference, Spring 2001 [6] Real Time magazine, “Evaluation Report Definition”, https://www.realtime-info.de/, March 1999 [7] R. Appleton, “Understanding a Context Switch Benchmark”, Jan. 1997 [8] V. Yodaiken, “An Introduction to Real- Time Linux” [9] Victor Yodaiken, “The RTLunix Approach to Hard Real-Time”, Oct. 1997 [10] P. Wilshire, “Installing RTLinux”, 2000 [11] WindRiver Systems Inc, Tornado User’s Guide, Alameda,CA: WindRiver Systems, Inc, 1999 [12] WindRiver Systems Inc, VxWorks Programmer’s Guide, Alameda,CA: WindRiver Systems, Inc, 1999 ","date":"2025-04-04","externalUrl":null,"permalink":"/app/performance-analysis-of-vxworks-and-rtlinux/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eBy Benjamin Ip | COMS W4995-2, Languages of Embedded Systems Department of Computer Science, Columbia University, NY\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eAbstract \n    \u003cdiv id=\"abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThis paper compares and evaluates the suitability of two real-time operating systems, the commercially available VxWorks and the publicly available RTLinux. Holding the hardware constant and using different measurement methodologies, we measured the overheads incurred during operating systems context switching, interrupt processing, object synchronization, and message passing. We also examine their effectiveness in terms of how they handle priority inversion problem.\u003c/p\u003e","title":"Performance Analysis of VxWorks and RTLinux","type":"app"},{"content":"","date":"2025-03-29","externalUrl":null,"permalink":"/tags/compliance/","section":"Tags","summary":"","title":"Compliance","type":"tags"},{"content":"","date":"2025-03-29","externalUrl":null,"permalink":"/tags/fda/","section":"Tags","summary":"","title":"FDA","type":"tags"},{"content":"","date":"2025-03-29","externalUrl":null,"permalink":"/tags/risk-management/","section":"Tags","summary":"","title":"Risk Management","type":"tags"},{"content":"","date":"2025-03-29","externalUrl":null,"permalink":"/tags/sbom/","section":"Tags","summary":"","title":"SBOM","type":"tags"},{"content":"","date":"2025-03-29","externalUrl":null,"permalink":"/tags/section-524b/","section":"Tags","summary":"","title":"Section 524B","type":"tags"},{"content":" Understanding FDA Section 524B for Medical Device Cybersecurity\nWhat medical device manufacturers need to know about FDA cybersecurity requirements, cyber device compliance, and secure product lifecycle management.\n🏥 Introduction # As healthcare technology becomes increasingly connected, medical devices are evolving into sophisticated cyber-physical systems capable of transmitting patient data, integrating with hospital infrastructure, and supporting remote diagnostics and treatment. While these advancements improve healthcare delivery and patient outcomes, they also introduce significant cybersecurity risks.\nCyberattacks targeting connected medical devices can compromise:\nPatient safety Device functionality Healthcare operations Sensitive medical data Clinical infrastructure Recognizing these growing threats, the United States government amended the Federal Food, Drug, and Cosmetic Act (FD\u0026amp;C Act) in December 2022 by introducing Section 524B. This amendment granted the U.S. Food and Drug Administration (FDA) explicit authority to regulate cybersecurity requirements for medical devices.\nThe result is a major shift in how medical device manufacturers approach:\nProduct design Risk management Software maintenance Vulnerability disclosure Regulatory compliance This article explores the purpose of Section 524B, its cybersecurity requirements, applicable standards, and the broader implications for medical device manufacturers.\n⚖️ What Is FDA Section 524B? # Section 524B was added to the FD\u0026amp;C Act to establish mandatory cybersecurity requirements for cyber-enabled medical devices submitted for FDA premarket approval.\nThe FDA formalized these requirements through the guidance document:\n“Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems Under Section 524B of the FD\u0026amp;C Act.”\nThe guidance was officially published on March 30, 2023.\nPurpose of Section 524B # Section 524B gives the FDA authority to require manufacturers to demonstrate that cybersecurity controls are integrated throughout the product lifecycle of cyber devices.\nThe regulation focuses on ensuring that connected medical devices can:\nResist cyber threats Detect vulnerabilities Receive security updates Protect patient safety and privacy Maintain operational reliability The requirements were phased in during 2023 and are now fully enforceable for applicable devices.\n🌐 Why Cybersecurity Matters for Medical Devices # Modern medical devices increasingly rely on:\nWireless communication Cloud connectivity Remote monitoring Internet-connected software platforms These capabilities improve healthcare efficiency and enable advanced patient care workflows. However, they also create new attack surfaces for malicious actors.\nRisks Introduced by Connected Devices # Cybersecurity vulnerabilities in medical devices can lead to:\nUnauthorized device access Manipulation of device behavior Data theft Operational disruption Patient injury or death Healthcare facilities may also experience broader consequences such as:\nRansomware attacks Clinical downtime Network compromise Regulatory exposure Example: Implantable Cardioverter Defibrillators # Implantable cardioverter-defibrillators (ICDs) demonstrate the importance of medical device cybersecurity.\nModern ICDs can:\nMonitor heart activity Deliver defibrillation therapy Support pacing functionality Transmit patient data wirelessly These devices often communicate with:\nHome docking stations Physician programming systems Remote monitoring infrastructure While these features improve patient care, compromised communications or unauthorized device manipulation could directly threaten patient safety.\n🧩 What Qualifies as a Cyber Device? # Section 524B applies specifically to devices classified as “cyber devices.”\nFDA Definition of a Cyber Device # According to Section 524B(c) of the FD\u0026amp;C Act, a cyber device is a medical device that:\nIncludes software validated, installed, or authorized by the sponsor Has the ability to connect to the internet Contains technological characteristics vulnerable to cybersecurity threats Importantly, devices do not necessarily need direct internet connectivity to fall within the scope of cybersecurity risk.\nFDA Interpretation and Manufacturer Responsibility # The FDA retains final authority in determining whether a product qualifies as a cyber device.\nManufacturers uncertain about device classification should proactively engage with the FDA and prepare to answer detailed questions regarding:\nConnectivity Embedded software Communication pathways Potential attack vectors System dependencies 📋 Core Requirements Under Section 524B # Section 524B requires sponsors submitting premarket applications for cyber devices to demonstrate compliance with several cybersecurity obligations.\nPost-Market Vulnerability Management # Manufacturers must provide a documented plan to:\nMonitor cybersecurity vulnerabilities Identify exploits Respond within a reasonable timeframe Support coordinated vulnerability disclosure The FDA expects manufacturers to maintain active vulnerability management processes throughout the product lifecycle.\nSecure Design and Development Processes # Manufacturers must establish processes ensuring that devices and associated systems are designed and maintained securely.\nThis includes:\nSecure software development practices Security-focused system architecture Ongoing maintenance procedures Post-market security patching The FDA now expects cybersecurity to be integrated into the entire product lifecycle rather than treated as a post-development consideration.\nSoftware Bill of Materials (SBOM) # Manufacturers must provide a Software Bill of Materials (SBOM) containing:\nCommercial software components Open-source dependencies Off-the-shelf software modules SBOM requirements improve software transparency and help healthcare organizations assess supply chain risks and vulnerability exposure.\n📚 Regulations and Standards Relevant to Section 524B # Medical device manufacturers must align cybersecurity efforts with several established industry standards and regulations.\nIEC 62304 # Medical Device Software — Software Lifecycle Processes\nDefines lifecycle requirements for medical device software development and maintenance.\nIEC 82304 # Health Software — General Requirements for Product Safety\nAddresses safety and security considerations for standalone health software.\nIEC 62366 # Application of Usability Engineering to Medical Devices\nFocuses on usability engineering to reduce user-related safety risks.\nISO 14971 # Medical Devices — Application of Risk Management\nProvides a framework for identifying and managing medical device risks throughout the product lifecycle.\nIEC 80001-1 # Risk Management for IT Networks Incorporating Medical Devices\nAddresses risks associated with connected healthcare IT systems.\n21 CFR 820 # Quality System Regulation — Design Validation\nDefines FDA quality system requirements related to medical device design controls.\nAAMI TIR57 # Principles for Medical Device Security — Risk Management\nProvides guidance for integrating security risk management into medical device development.\n🛡️ Cybersecurity Principles for Medical Devices # The FDA expects cybersecurity to be addressed during the earliest stages of device development.\nShared Responsibility Model # Medical device cybersecurity is considered a shared responsibility involving:\nDevice manufacturers Healthcare providers Hospitals Patients IT administrators Manufacturers remain responsible for building secure systems, but healthcare organizations must also maintain secure deployment environments.\n🔍 General Cybersecurity Risk Management Principles # Manufacturers should establish structured cybersecurity risk management processes that include:\nAsset, Threat, and Vulnerability Identification # Organizations should identify:\nCritical assets Threat actors Potential attack vectors Known vulnerabilities Impact Assessment # Manufacturers must evaluate how cybersecurity events could affect:\nDevice functionality Patient safety Clinical workflows Data confidentiality Exploit Likelihood Analysis # Security teams should estimate:\nProbability of exploitation Attack feasibility Exposure level Threat severity Risk Mitigation Planning # Organizations must define:\nRisk levels Security controls Mitigation strategies Residual risk acceptance criteria This process aligns closely with broader secure product lifecycle management practices.\n🧠 NIST Cybersecurity Framework for Medical Devices # The FDA recommends leveraging the National Institute of Standards and Technology (NIST) Cybersecurity Framework.\nThe framework provides a structured model for cybersecurity risk management.\nIdentify # Develop organizational understanding of:\nAssets Systems Risks Capabilities Dependencies Protect # Implement safeguards to ensure secure operation of critical services and devices.\nExamples include:\nAccess control Encryption Authentication Network segmentation Detect # Establish mechanisms capable of identifying cybersecurity incidents and abnormal behavior.\nRespond # Create procedures for responding to detected cybersecurity events, including:\nIncident handling Containment Communication Recovery coordination Recover # Develop resilience and restoration strategies to recover services following cybersecurity incidents.\nThe NIST framework helps manufacturers create comprehensive and repeatable cybersecurity programs.\n📄 Premarket Cybersecurity Documentation # The FDA expects manufacturers to produce detailed cybersecurity documentation as part of the premarket submission process.\nRequired Documentation Areas # Premarket cybersecurity documentation commonly includes:\nThreat modeling Vulnerability and risk assessment Cybersecurity controls Traceability matrices Ongoing support plans Malware-free shipping procedures Cybersecurity labeling These artifacts demonstrate that cybersecurity considerations were incorporated systematically during development.\n🔑 Key Actions Required by Section 524B # Section 524B emphasizes several core operational cybersecurity responsibilities.\nMonitor # Manufacturers must continuously monitor cybersecurity vulnerabilities affecting their products.\nDesign # Devices must be developed using secure-by-design principles.\nPatch # Manufacturers must establish lifecycle patch management strategies to maintain device security after deployment.\nDisclosure # Organizations must support coordinated vulnerability disclosure processes for reporting and resolving security issues responsibly.\nSBOM / CBOM # Cyber devices should include a Software Bill of Materials as part of a broader Cybersecurity Bill of Materials (CBOM) strategy.\n📈 The Growing FDA Focus on Cybersecurity # The FDA’s role in cybersecurity has evolved significantly over time.\nBefore Section 524B # Prior to the amendment:\nCybersecurity was primarily evaluated indirectly through safety and effectiveness reviews SBOM requests were inconsistent Manufacturers mainly documented why vulnerabilities did not impact essential performance After Section 524B # Today, cybersecurity requirements are substantially more comprehensive.\nManufacturers must now demonstrate:\nSecure development processes Patch delivery capability Continuous vulnerability management Lifecycle cybersecurity support Mandatory SBOM generation Cybersecurity is now treated as a core regulatory requirement rather than an optional enhancement.\n🧬 The Evolving Role of Medical Device Manufacturers # Medical device manufacturers now face broader responsibilities extending far beyond initial product release.\nLifecycle Security Ownership # Manufacturers are expected to maintain cybersecurity throughout:\nDesign Development Validation Deployment Maintenance End-of-life support This lifecycle-focused approach reflects the reality that cybersecurity risks evolve continuously after deployment.\nIncreased Engineering and Compliance Demands # Organizations must now invest in:\nSecure software engineering Vulnerability management programs Security testing Supply chain visibility Regulatory documentation Post-market support infrastructure These requirements significantly reshape medical device engineering and operational practices.\n🏁 Conclusion # FDA Section 524B represents a major shift in medical device cybersecurity regulation.\nBy granting the FDA explicit cybersecurity authority, the regulation establishes stronger requirements for:\nSecure device design Vulnerability management Patch deployment Risk assessment Software transparency Lifecycle cybersecurity maintenance Medical device manufacturers must now integrate cybersecurity into every stage of product development and operation while maintaining ongoing support for deployed systems.\nAlthough compliance requirements introduce additional engineering and regulatory complexity, the long-term objective is clear: improving patient safety, protecting healthcare infrastructure, and strengthening trust in connected medical technologies.\nAs cyber threats continue to evolve, Section 524B will remain a foundational framework shaping the future of secure medical device development.\n","date":"2025-03-29","externalUrl":null,"permalink":"/industries/understanding-fda-section-524b-for-medical-device-cybersecurity/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eUnderstanding FDA Section 524B for Medical Device Cybersecurity\u003c/p\u003e\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003eWhat medical device manufacturers need to know about FDA cybersecurity requirements, cyber device compliance, and secure product lifecycle management.\u003c/p\u003e","title":"Understanding FDA Section 524B for Medical Device Cybersecurity","type":"industries"},{"content":" Introduction # Overview # The MVME2500 Single Board Computer (SBC) is a VMEbus board, which features a single-core P2010 or the dual-core P2020 NXP® QorIQ® processors.\nThis document describes the procedure to boot VxWorks 6.8 on the MVME2500 board.\nDeliverables # The following table lists the MVME2500 deliverables.\nName Description vxWorks-2020.st VxWorks boot image file for P2020 blades vxWorks-2010.st VxWorks boot image file for P2010 blades mvme2500_sp1.tar.gz VxWorks 6.8 Board Support Package (BSP) for MVME2500 Booting VxWorks # Introduction # You can boot VxWorks on the MVME2500 board using any of the following methods:\nNetwork Boot Disk Boot USB Boot SPI Flash Boot Network Boot # Prerequisites # You should have connectivity to the TFTP server.\nBooting Procedure # The TFTP server should be configured and started in the connected PC. The VxWorks boot Image file, vxWorks-2020.st or vxWorks-2010.st, should be made available at the standard TFTP boot image path /tftpboot.\nTo boot VxWorks through network, perform the following steps:\nPower up the MVME2500 board. By default, it provides the U-Boot prompt.\nSet the environmental variables at the U-Boot prompt. setenv ipaddr \u0026lt;Board ip address\u0026gt; setenv serverip \u0026lt;TFTP server ip address\u0026gt; setenv gatewayip \u0026lt;Gateway ip address\u0026gt; setenv netmask \u0026lt;Netmask\u0026gt; Example:\nsetenv ipaddr 10.130.101.206 setenv serverip 10.130.101.216 setenv gatewayip 10.130.101.254 setenv netmask 255.255.255.0 Set the VxWorks boot image file name. setenv vxbootfile vxWorks-2020.st setenv vxbootfile vxWorks-2010.st Set the VxWorks bootline arguments. setenv vxbootargs \u0026#39;motetsec(0,0)10.130.101.216:vxWorks h=10.130.101.216 e=10.130.101.206:ffffff00 u=vxworks pw=vxworks f=0x80’ Parameters description:\nmotetsec(0,0) : Ethernet interface 0 on cpu 0 10.130.101.216 : Host Machine IP 10.130.101.206 : Board IP ffffff00 : Netmask u=vxworks : Username on host machine p=vxworks : Password for the above user in host machine f=0x80 : File Transfer Protocol (FTP) Set the VxWorks network boot command. setenv vxboot \u0026#39;tftpboot $vxbootfile \u0026amp;\u0026amp; setenv bootargs $vxbootargs \u0026amp;\u0026amp; bootvx\u0026#39; Save your current environmental variables. saveenv To boot VxWorks through network, execute the following command: run vxboot Disk Boot # Prerequisites # You should have:\nSerial Advanced Technology Attachment (SATA) hard disk with ext2 file system loaded, and VxWorks image loaded to the ext2 file system Booting Procedure # To boot VxWorks using disk, perform the following steps:\nPower up the MVME2500 board. By default, it provides the U-Boot prompt.\nSet the environmental variables at the U-Boot prompt. setenv ipaddr \u0026lt;Board ip address\u0026gt; setenv serverip \u0026lt;TFTP server ip address\u0026gt; setenv gatewayip \u0026lt;Gateway ip address\u0026gt; setenv netmask \u0026lt;Netmask\u0026gt; Example:\nsetenv ipaddr 10.130.101.206 setenv serverip 10.130.101.216 setenv gatewayip 10.130.101.254 setenv netmask 255.255.255.0 Set the VxWorks boot image file name. setenv vxbootfile vxWorks-2020.st setenv vxbootfile vxWorks-2010.st Set the VxWorks bootline arguments. setenv vxbootargs \u0026#39;motetsec(0,0)10.130.101.216:vxWorks h=10.130.101.216 e=10.130.101.206:ffffff00 u=vxworks pw=vxworks f=0x80’ Parameters description:\nmotetsec(0,0) : Ethernet interface 0 on cpu 0 10.130.101.216 : Host Machine IP 10.130.101.206 : Board IP ffffff00 : Netmask u=vxworks : Username on host machine p=vxworks : Password for the above user in host machine f=0x80 : File Transfer Protocol (FTP) Set the VxWorks disk boot command. setenv vxdiskboot \u0026#39;ext2load scsi 0:1 0x1000000 $vxbootfile \u0026amp;\u0026amp; setenv bootargs $vxbootargs \u0026amp;\u0026amp; bootvx\u0026#39; Save your current environmental variables. saveenv To boot VxWorks through hard disk, execute the following command: run vxdiskboot USB Boot # Prerequisites # You should have:\nUSB pen drive with VxWorks image, and vfat or ext2fs file system Booting Procedure # To boot VxWorks using USB, perform the following steps:\nPower up the MVME2500 board. By default, it provides the U-Boot prompt.\nSet the environmental variables. setenv ipaddr \u0026lt;Board IP address\u0026gt; setenv serverip \u0026lt;TFTP server IP address\u0026gt; setenv gatewayip \u0026lt;Gateway IP address\u0026gt; setenv netmask \u0026lt;Netmask\u0026gt; Example:\nsetenv ipaddr 10.130.101.206 setenv serverip 10.130.101.216 setenv gatewayip 10.130.101.254 setenv netmask 255.255.255.0 Set the VxWorks boot image file name. setenv vxbootfile vxWorks-2020.st setenv vxbootfile vxWorks-2010.st Set the VxWorks bootline arguments. setenv vxbootargs \u0026#39;motetsec(0,0)10.130.101.216:vxWorks h=10.130.101.216 e=10.130.101.206:ffffff00 u=vxworks pw=vxworks f=0x80’ Parameters description:\nmotetsec(0,0) : Ethernet interface 0 on cpu 0 10.130.101.216 : Host Machine IP 10.130.101.206 : Board IP ffffff00 : Netmask u=vxworks : Username on host machine p=vxworks : Password for the above user in host machine f=0x80 : File Transfer Protocol (FTP) Set the VxWorks USB boot command. setenv vxusbboot \u0026#39;usb reset \u0026amp;\u0026amp; fatload usb 0:1 0x1000000 $vxbootfile \u0026amp;\u0026amp; setenv bootargs $vxbootargs \u0026amp;\u0026amp; bootvx\u0026#39; Save your current environmental variables. saveenv To boot VxWorks through USB, execute the following command: run vxusbboot SPI Flash Boot # Prerequisites # You should have:\nTFTP server connectivity is required only when you want to copy new VxWorks image to SPI Flash. Booting Procedure # The TFTP server should be configured and started in the connected PC. The VxWorks boot Image file, vxWorks-2020.st or vxWorks-2010.st, should be made available at the standard TFTP boot image path /tftpboot.\nFollow 1 to 8 steps to copy VxWorks image from network to SPI Flash.\nPower up the MVME2500 board. By default, it provides the U-Boot prompt.\nSet the environmental variables at the U-Boot prompt. setenv ipaddr \u0026lt;Board ip address\u0026gt; setenv serverip \u0026lt;TFTP server ip address\u0026gt; setenv gatewayip \u0026lt;Gateway ip address\u0026gt; setenv netmask \u0026lt;Netmask\u0026gt; Example:\nsetenv ipaddr 10.130.101.206 setenv serverip 10.130.101.216 setenv gatewayip 10.130.101.254 setenv netmask 255.255.255.0 Set the VxWorks boot image file name. setenv vxbootfile vxWorks-2020.st setenv vxbootfile vxWorks-2010.st Set the VxWorks bootline arguments. setenv vxbootargs \u0026#39;motetsec(0,0)10.130.101.216:vxWorks h=10.130.101.216 e=10.130.101.206:ffffff00 u=vxworks pw=vxworks f=0x80’ Parameters description:\nmotetsec(0,0) : Ethernet interface 0 on cpu 0 10.130.101.216 : Host Machine IP 10.130.101.206 : Board IP ffffff00 : Netmask u=vxworks : Username on host machine p=vxworks : Password for the above user in host machine f=0x80 : File Transfer Protocol (FTP) Initialize SPI Flash0 device: sf probe 0 Note: To initialize SPI Flash 1, set the command as below:\nsf probe 1 To erase SPI Flash memory region: sf erase 0x200000 0x300000 Note: Maximum space available in SPI Flash for VxWorks image is 5MB (0x500000). Here it is assumed that the VxWorks image size is less than 3MB(0x300000). If the VxWorks image size is more than 3MB, then you can change the image size here accordingly.\nLoad the VxWorks image from network to the memory location (0x1000000): tftpboot VxWorks.st Write to SPI Flash 0 device at location (0x200000) from memory location(0x1000000): sf write 0x1000000 0x200000 0x300000 Note: VxWorks image is loaded permanently to SPI flash 0. To load Vxworks image use SPI Flash device from next time.\nTo boot directly from SPI Flash follow below steps:\nInitialize SPI Flash0 device sf probe 0 Note: To initialize SPI Flash 1, set the command as below:\nsf probe 1 Copy VxWorks image from SPI Flash 0 location (0x200000) to memory location (0x1000000) with 3MB size. read 0x1000000 0x200000 0x300000 Set the VxWorks SPI Flash boot command. setenv vxboot \u0026#39;setenv bootargs $vxbootargs \u0026amp;\u0026amp; bootvx\u0026#39; Save your current environmental variables. saveenv To boot VxWorks through SPI Flash, execute the following command: run vxboot Building Board Support Package # Building Procedure # The mvme2500_sp1.tar.gz contains VxWorks 6.8 BSP source files for the MVME2500 board. Perform the following steps to build the BSP:\nExtract the mvme2500_sp1.tar.gz to any working directory. Start the Wind River VxWorks Workbench by executing the following command: \u0026lt;vxWorks Installation Directory\u0026gt;/startWorkbench.sh Open the Wind River VxWorks Workbench. Select File -\u0026gt; New -\u0026gt; VxWorks Image Project Give a project name and then click Next. Go to BSP and select mvme2500 from the dropdown list. Click Browse and point to the location where you have extracted the BSP. Click Next. Select any configuration profile. Click Finish. Double-click mvme2500.h file. Enable MVME2500_P2020 or MVME2500_P2010 based on the MVME2500 board version. Right-click the project name which you have created, and select Build Project. ","date":"2025-03-29","externalUrl":null,"permalink":"/bsp/deploy-vxworks-6-8-on-mvme2500-sbc/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\n\n\u003ch3 class=\"relative group\"\u003eOverview \n    \u003cdiv id=\"overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h3\u003e\n\u003cp\u003eThe MVME2500 Single Board Computer (SBC) is a VMEbus board, which features a single-core P2010 or the dual-core P2020 NXP® QorIQ® processors.\u003c/p\u003e","title":"Deploy VxWorks 6.8 on MVME2500 SBC","type":"bsp"},{"content":"","date":"2025-03-29","externalUrl":null,"permalink":"/tags/vme/","section":"Tags","summary":"","title":"VME","type":"tags"},{"content":"","date":"2025-03-29","externalUrl":null,"permalink":"/tags/vxworks-6.8/","section":"Tags","summary":"","title":"VxWorks 6.8","type":"tags"},{"content":"","date":"2025-03-29","externalUrl":null,"permalink":"/tags/come/","section":"Tags","summary":"","title":"COMe","type":"tags"},{"content":"","date":"2025-03-29","externalUrl":null,"permalink":"/tags/kontron/","section":"Tags","summary":"","title":"Kontron","type":"tags"},{"content":" Introduction # Welcome to the Wind River VxWorks 6.8 and Kontron COM Express™ Computer-on-Modules LiveUSB Evaluation. Using the specially configured evaluation environment provided in this kit you will quickly be able to use Wind River’s market leading development tools and run VxWorks, the world’s most popular real-time operating system, on the provided Kontron COM Express™ Computer-on-Modules.\nOverview # This evaluation will lead you through the steps required to create VxWorks kernel projects, downloadable kernel modules (DKM), and real-time process projects (RTPs), and outline how Wind River tools can aid in the debugging and analysis of embedded systems based on the Kontron COM Express™ Computer-on-Modules.\nDuring this evaluation you will work with two separate systems:\na host computer on which you will perform tasks such as building VxWorks, analysing test results and debugging code. You will also use the host computer to view Wind River documentation and audio-visual material. You can use almost any modern laptop or desktop PC as a host computer. The preferred specification for the host computer is outlined below.\na Kontron COM Express™ COM, referred to as a target system, on which VxWorks will run.\nDuring the evaluation you will connect these two systems together (using serial and Ethernet connections) and use them in a mode referred to as cross-development. In this mode you will run Wind River Workbench Development Suite on your host computer to write, build, and debug software code which will run on the Kontron Computer-on-Module.\nWhat is included in the Kit # This kit includes the following components:\na Kontron COM Express™ Starterkit Type 2 or a COM Express™ miniStarterkit Type 2, including an COM Express™ minibaseboard Type 2 pre assembled with an ETXexpress® or microETXexpress® Computer-on-Module, a 1GB DDR2 Memory and heatsink. The kit includes power supply, cables and documentations. one 2 GB USB flash drive preloaded with the VxWorks 6.8 operating system one bootable 8 GB Wind River LiveUSB Environment memory stick. This enables users to quickly and easily boot and start working with the Wind River Workbench development suite on a host computer. Its use is fully described in this document. one serial cable to enable connection between the host computer and the Kontron COM Express™ Computer-on- Module one Ethernet cable for communication between the target and the Wind River Workbench Development tools Required Hardware # COM Express™ Starterkit VxWorks Specification # This ETXexpress®-XX or microETXexpress®-XX LiveUSB evaluation is delivered with (and is designed to operate with) a standard Kontron COM Express™ Starterkit Type 2 or a COM Express™ miniStarterkit Type 2 fully assembled with:\nthe selected Kontron COM Express basic or compact Computer-on-Module 1GB Memory Heatsink COM Express™ miniBaseboard Type 2, for COM Express™ modules a fan with a massive copper core that fits on a standard ETXexpress® Heatspreader or microETXexpress® Heatsink a PicoATX 120W and 12 V PSU for running the COM Express™ miniBaseboard Type 2 (COM Express™ miniStarterkit Type 2 version) a Switchable ATX PSU 115V/230V~ (COM Express™ Starterkit Type 2 version) a USB flash drive with manuals and datasheets additional cables Ethernet/serial For these evaluation kits, the Kontron COM Express™ COM boots from a USB flash drive which is pre-loaded with a fully functional VxWorks 6.8 image that boots the board into VxWorks and connects to the Wind River Workbench development tools running on your host PC.\nHost Computer Specification # During this evaluation you will run Wind River Workbench Development Suite, for which you will need a suitable host computer. The host computer may be a laptop or desktop PC with the following specifications:\nHost architecture: Intel® Core™ Duo, 2GHz or greater (recommended) Host memory: 2GB RAM (recommended) USB requirements: USB 2.0 connection (required) Host-target communication: Ethernet, serial You do not need to install any software on your host computer prior to the evaluation.\nLiveUSB Technology # All the software required to run this evaluation on your host computer is delivered on a fully configured, bootable Wind River LiveUSB Environment memory stick (referred to as a LiveUSB) that you can boot on most standard modern PCs. The LiveUSB contains:\na fully configured and bootable version of the Fedora 11 (Linux) operating system Wind River Workbench Development Suite (pre-installed) Wind River VxWorks 6.8 RTOS prepared with a dedicated board support package for the selected COM Express™ COM Wind River documentation, including this Getting Started Guide and the Wind River VxWorks and Tilcon Graphics Suite Kontron COM Express™ Evaluation Tutorial A set of audio-visual guides that will lead you through the VxWorks evaluation Wind River documentation for Workbench and VxWorks The pre-configured LiveUSB environment allows users to use Wind River development tools without the need to install, configure or build anything prior to the evaluation. Your evaluation should begin almost immediately after you have booted the LiveUSB.\nNote that, once booted, the LiveUSB software uses the RAM memory of the host computer and the flash memory available in the LiveUSB stick itself - it does not use the hard drive on the host computer. When used currently, this evaluation will not write to the hard drive of the host computer.\nConnecting the COM Express™ COM # Assembling the COM Express™ COM # Before starting this evaluation you should ensure that your Kontron COM Express™ COM is correctly connected. Ensure that you work within a statically safe area and that you have all the required tools available (a Phillips (crosshead) and a flat-bladed screwdriver). Assemble the board as follows.\nYour COM Express™ COM will normally be delivered fully assembled onto the COM Express™ miniBaseboard Type 2, in which you should begin assembly at step 5 below.\nHowever, if it is necessary to assembly the COM (inclu- ding the heatspreader), you should begin at step 1.\nCarefully remove the Kontron COM, the memory, and the cooling fan and heatsink from its packaging. Place the DDR2 RAM into the memory socket on the COM Express™ COM. Fix the heatsink: Apply the thermal grease to the bottom of the standard CPU cooler (don’t forget to remove the protective film) and carefully place the standard CPU cooler onto the black heatspreader plate on the COM Express™ module. Fix the fan to the COM Express™ module using the four screws and washers provided. Carefully place the COM Express™ COM and fan assembly onto the COM Express™ miniBaseboard, making sure that the COM Express™ connectors are correctly aligned. Using firm but even pressure, squeezes the COM Express™ COM down onto the COM Express™ miniBaseboard until it is securely plugged on. Fix the board down using the three screws provided (from the underside of the board). Connect the ATX power supply respectively plug the three pin power cable from the cooling fan onto the three pin connector beside the power supply connector. Plug the ATX style power adaptor module into the 20 pin power supply connector on the COM Express™ miniBaseboard and plug the four pin additional power cable (attached to the power adaptor) into the adjacent four pin connector. Plug the 9-pin serial cable adaptor into the COM1 connector on the COM Express™ miniBaseboard (close to the reset and power switches). Connecting the COM Express™ miniBaseboard to Your Host Computer # The COM Express™ miniBaseboard (the target) requires two connections to the host computer — a serial connection for the console output and an Ethernet connection for communication between the target and the Wind River Workbench Development tools. Connect these as follows.\nEnsure that your host computer is switched off. Connect the 9-way serial cable between the COM1 socket from the COM Express™ miniBaseboard and the primary serial port on your host machine. Connect an Ethernet cable between the Ethernet port on the COM Express™ miniBaseboard and the primary Ethernet port on your host machine. You can either connect the target and the host computer directly connection, or through a hub or switch. Note that the evaluation host and COM Express™ COM will be assigned pre-configured static IP addresses during the evaluation. Connect a mouse to one of the USB ports on the COM Express™ miniBaseboard. Connect a monitor to the COM Express™ miniBaseboard using a DVI cable. Insert the VxWorks USB flash drive into one of the USB ports on the COM Express™ miniBaseboard. Ensure that the 12V power supply for the COM Express™ miniBaseboard is correctly connected. Powering on the COM Express™ miniBaseboard # Ensure that your COM Express™ miniBaseboard is correctly assembled and is capable of booting. On the COM Express™ miniBaseboard, press the power switch (the blue switch closest to the corner of the board). The board begins to boot within a few seconds. NOTE: The selected COM Express™ COM boots a special version of VxWorks 6.8 that is specifically configured for development purposes. This reference platform was designed for development flexibility, and as such it may take up to 60 seconds to boot. The ROM BIOS detects the VxWorks boot loader on the USB flash drive \u0026ndash;allow the COM to continue. The VxWorks boot loader counts down \u0026ndash;allow the boot loader to continue. After VxWorks boots successfully, the monitor displays the main Wind River Tilcon Graphics Suite Demo screen. Please detect and explore the application videos with OpenGLmedical and industrial solutions. The Wind River Tilcon Graphics Suite demonstration is visible independently from a connection to the host computer as well.\nFrom this point on you can use the Reset button if you need to reset the board. (Note that you can also use the Wind River tools to reset the COM Express™ miniBaseboard).\nStarting the Evaluation Software # Booting the Host Computer # Before booting your host computer, ensure that the USBLive Evaluation stick is correctly plugged into a USB port on the host computer. You should also have a keyboard and mouse connected to the host computer.\nConfigure your hardware as shown in the following figure before you boot your host computer Switch on your host computer. NOTE: You may have to interrupt the boot process to instruct the BIOS to boot from the USB flash drive instead of the internal hard drive. The host computer boots into a preconfigured Fedora (Linux) environment.\nAccepting the Agreements # You will then be presented with a product evaluation license agreement and an object code development license and distribution agreement. Click Accept to accept the agreements and proceed.\nObtaining an Evaluation License # When you start your LiveUSB for the first time, an activation agent automatically attempts to obtain an evaluation license for the software on the LiveUSB stick. This requires an Internet connection.\nNOTE: The host will attempt to connect to the Internet over the first wired Ethernet interface. If your host has multiple interfaces, or if you want to use wireless interfaces, you must make the necessary configuration changes. Follow the on-screen instructions. You must enter your registration details including a valid email address. After a few minutes, the LiveUSB will be activated and ready to use. The license lasts for thirty days from the acceptance of the agreements and is valid for any machine on which the LiveUSB runs.\nStarting Your Evaluation # Change your hardware configuration to match the configuration shown in the following figure.\nAfter the host computer boots into the Fedora 11 Live USB environment, you will be presented with a desktop that includes a number of icons, including a link to this document and quick launches to the tools.\nFor your convenience, there are also a number of pull down menus under Applications \u0026gt; WindRiver at the top of the screen.\nSelect Applications \u0026gt; WindRiver \u0026gt; Documentation \u0026gt; Evaluation Tutorial to open the Wind River VxWorks and Tilcon Graphics Suit, Kontron COM Evaluation Tutorial.\nSelect Applications \u0026gt; WindRiver \u0026gt; Documentation \u0026gt; Getting Started Guide to access the Getting Started Guide. This document displays when you first boot the Fedora Live USB drive.\nSelect Applications \u0026gt; WindRiver \u0026gt; Videos to access videos of the exercises.\nNotes # You can exercise the evaluation in any way you choose—by following the video tutorials, trying your own software, running benchmarks, and so on. The evaluation is safe to use with your existing machine. When correctly used, no data will be written outside of the LiveUSB stick. The evaluation is interruptible—if you stop partway through, you can resume where you stopped. To download updated materials (if available), visit https://www.vxworks6.com. About Wind River # Wind River, Tornado, and VxWorks are registered trademarks of Wind River Systems, Inc. The Wind River logo is a trademark of Wind River Systems, Inc. Any third-party trademarks referenced are the property of their respective owners.\nThis product may include software licensed to Wind River by third parties. Relevant notices (if any) are provided in your product installation at the following location: installDir/product_name/3rd_party_licensor_notice.pdf.\nWind River may refer to third-party documentation by listing publications or providing links to third-party Web sites for informational purposes. Wind River accepts no responsibility for the information provided in such third-party documentation.\nAbout Kontron # Kontron designs and manufactures standards-based and custom embedded and communications solutions for OEMs, systems integrators, and application providers in a variety of markets. Kontron engineering and manufacturing facilities, located throughout Europe, Americas, and Asia-Pacific, work together with streamlined global sales and support services to help customers reduce their time-to-market and gain a competitive advantage. Kontron’s diverse product portfolio includes: boards and mezzanines, Computer-on-Modules, HMIs and displays, systems, and custom capabilities. Kontron is a premier member of the Intel® Embedded and Communications Alliance. For half a decade now, Kontron has been named a VDC Platinum Embedded Board Vendor. Based entirely on user feedback, industry professionals evaluate vendors on over 45 non-product related criteria. Kontron is only one of two companies to receive the platinum award 5-years running.\nAppendix A Troubleshooting Your Evaluation Setup # A.1 Network Topology Overview # For retrieving the evaluation license:\nTo retrieve the evaluation license, the LiveUSB host computer must have access to the Internet. The host computer will attempt to retrieve an IP address on its first wired interface dynamically via DHCP. Although wireless connections may be available on the LiveUSB host computer, they are disabled in the default configuration. If you wish to connect to the Internet over a wireless connection, you must determine the configuration yourself.\nFor running the evaluation:\nThe steps in the tutorial have been tested using wired interfaces only. Both the target and the LiveUSB host computer must be set to their respective static IP address. Before running the evaluation tutorial, you must switch the LiveUSB host computer to its static IP address. The script that sets the static IP address uses the lowest numbered eth interface that it finds. For example, if the host computer has eth1 and eth2 interfaces, then eth1 will be set to the static IP address.\nA.2 Troubleshooting Your License Activation # During the license activation procedure you may see the following Information dialog.\nThis indicates that the license activation agent cannot communicate with the Wind River license server. Perform the following procedure to repair this problem.\nNOTE: Automatic proxy configuration is not supported. If you are using this configuration, contact Wind River licensing (step 5). Configure your system as shown in section 3.1. From the main Fedora menu, select Applications \u0026gt; Wind River \u0026gt; IP Address \u0026gt; Switch to DHCP. From the main Fedora menu, select Applications \u0026gt; Wind River \u0026gt; Evaluation License Activation \u0026gt;Activate 30 Day Evaluation.\nPerform the steps in section 3.3 to complete your license activation.\nIf this procedure does not work, contact Wind River licensing at the appropriate location.\nA.3 Recreating the VxWorks Boot Drive # Before you recreate the VxWorks boot drive, you must boot your host computer from the evaluation LiveUSB.\nNOTE: Perform this procedure only if you lose or damage the VxWorks boot drive (which is normally plugged into your COM Express™ miniBaseboard) delivered with your evaluation kit. Insert a second USB flash drive that is 1 GB or larger into your host computer. NOTE: Copy any data you wish to keep from the flash drive to a protected location before you continue. This procedure will overwrite the USB flash drive with the VxWorks boot image. Open a terminal window.\nExecute the command su to become the root user, then execute the following command to transfer the recovery image to the target device.\ndd if=/WindRiver/workspace/Boot-Image/usb-recovery. img of=/dev/sdX bs=4M NOTE: Replace the placeholder /dev/sdX with the specific device file assigned to your USB flash drive when it was inserted. If the USB drive mounted automatically when you inserted it (that is, if an icon appeared on the desktop or a file manager window opened), you must unmount the device before you proceed to copy the image to the device.\nWhen the command prompt returns, execute the command sync to ensure that all data is written to the USB flash drive.\nWhen the command prompt returns, remove the USB flash drive.\nYou can now use the USB flash drive to boot your Kontron COM Express™ Computer-on-Module.\n","date":"2025-03-29","externalUrl":null,"permalink":"/bsp/wind-river-vxworks-and-kontron-com-express-computer-on-modules-liveusb-evaluation/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eWelcome to the Wind River VxWorks 6.8 and Kontron COM Express™ Computer-on-Modules LiveUSB Evaluation. Using the specially configured evaluation environment provided in this kit you will quickly be able to use Wind River’s market leading development tools and run VxWorks, the world’s most popular real-time operating system, on the provided Kontron COM Express™ Computer-on-Modules.\u003c/p\u003e","title":"Wind River VxWorks and Kontron COM Express Computer on Modules Liveusb Evaluation","type":"bsp"},{"content":"VxWorks, developed by Wind River Systems, is a leading real-time operating system (RTOS) widely used in embedded systems requiring deterministic performance. With the release of VxWorks 7, the OS has been re-engineered for modularity, scalability, and modern hardware support, including advanced graphics capabilities. While WindML—a graphics library prominent in earlier VxWorks versions like 5.x and 6.x—has largely been superseded by standards like OpenGL ES and OpenVG in VxWorks 7, it’s still possible to run WindML-based graphics demos with the right setup. This article provides a step-by-step guide to running a WindML graphics demo (specifically, the classic uglteapot demo) on VxWorks 7, leveraging its backward compatibility and development tools like Wind River Workbench 4.\nPrerequisites # Before diving into the process, ensure you have the following:\nVxWorks 7 Installation: A licensed copy of VxWorks 7 installed on your host machine (Windows or Linux). Wind River Workbench 4: The Eclipse-based IDE for VxWorks 7 development. Target Hardware or Simulator: A supported target board (e.g., Intel x86 or ARM-based) with graphics hardware, or the VxWorks Simulator (vxsim) for testing. WindML Source Files: Access to WindML demo source code (e.g., uglteapot.c) and libraries, typically found in older VxWorks distributions or archived documentation. Graphics Support: Ensure your VxWorks 7 image includes graphics components (e.g., Frame Buffer Driver, OpenVG, or legacy WindML support if ported). Development Environment: A configured VxWorks Source Build (VSB) and VxWorks Image Project (VIP) with necessary graphics libraries. Step 1: Setting Up the VxWorks 7 Environment # VxWorks 7 uses a layered build system with VSB and VIP projects to create a customized kernel image. To run a WindML demo, you need to ensure graphics support is included.\nLaunch Wind River Workbench 4: Start Workbench and select or create a workspace (e.g., C:\\Users\\YourName\\vxworks_workspace on Windows). Ensure your VxWorks 7 installation is registered in Workbench (check under Preferences \u0026gt; Wind River \u0026gt; VxWorks). Create a VxWorks Source Build (VSB) Project: In Workbench, go to File \u0026gt; New \u0026gt; VxWorks Source Build Project. Name it (e.g., vsb_graphics) and select your target architecture (e.g., x86_64 or SIMNT for the simulator). In the configuration wizard, include the following components: INCLUDE_FBDEV (Frame Buffer Driver) INCLUDE_WINDML (if available in your VxWorks 7 distribution; otherwise, you may need to port legacy WindML libraries manually) INCLUDE_OPENGL or INCLUDE_OPENVG (for modern graphics support as a fallback). Build the VSB project by right-clicking it in the Project Explorer and selecting Build Project. This generates libraries for your kernel image. Create a VxWorks Image Project (VIP): Go to File \u0026gt; New \u0026gt; VxWorks Image Project. Name it (e.g., vip_graphics) and link it to your vsb_graphics project. Configure the kernel: Open the Kernel Configuration editor (double-click kernel_config.c in the VIP project). Verify graphics components are enabled (e.g., INCLUDE_FBDEV, INCLUDE_WINDML). Add INCLUDE_VXSIM if using the simulator. Build the VIP project to generate a bootable VxWorks image (e.g., vxWorks in the default directory). Step 2: Obtaining and Preparing the WindML Demo # The uglteapot demo is a classic WindML example that renders a rotating teapot. Since WindML is legacy, you may need to source it from an older VxWorks installation (e.g., VxWorks 6.x) or online archives.\nLocate the Demo Source: Check your VxWorks installation directory (e.g., \u0026lt;VxWorks_Install_Dir\u0026gt;/vxworks-7/target/src/Mesa/windmldemos). If unavailable, search Wind River’s documentation or forums for uglteapot.c. Alternatively, use this minimal example if you can’t find it: #include \u0026lt;ugl/ugl.h\u0026gt; #include \u0026lt;ugl/ugluc.h\u0026gt; void windMLTeapot(UGL_BOOL animate, int argc, char *argv[]) { UGL_ID gc = uglGcCreate(UGL_DEFAULT_DISPLAY); uglGcClear(gc, 0, 0, 640, 480, UGL_RGB(255, 255, 255)); uglTeapot(gc, 200, 200, 100, animate); uglGcDestroy(gc); } void uglteapot(void) { taskSpawn(\u0026#34;tTeapot\u0026#34;, 210, VX_FP_TASK, 100000, (FUNCPTR)windMLTeapot, UGL_TRUE, 0, 0, 0, 0, 0, 0, 0, 0, 0); } Save this as uglteapot.c. Create a Downloadable Kernel Module (DKM) Project: In Workbench, go to File \u0026gt; New \u0026gt; VxWorks Downloadable Kernel Module Project. Name it (e.g., uglteapot_demo) and link it to your vsb_graphics project. Add uglteapot.c to the project by dragging it into the Project Explorer or using Import \u0026gt; File System. Modify the build settings: Right-click the project, select Properties \u0026gt; Build Properties. Under Paths, add include paths for WindML headers (e.g., \u0026lt;VxWorks_Install_Dir\u0026gt;/vxworks-7/target/h/ugl). Under Libraries, add the WindML library (e.g., libwindml.a) if available, or link against Mesa/OpenGL libraries as a substitute. Build the DKM: Right-click the project and select Build Project. This generates an object file (e.g., uglteapot_demo.out). Step 3: Running the Demo on the VxWorks Simulator # For simplicity, we’ll use the VxWorks Simulator (vxsim) to test the demo.\nStart the Simulator: In Workbench, go to Run \u0026gt; Debug Configurations. Create a new VxWorks Simulator Connection: Select your VIP image (e.g., vip_graphics/default/vxWorks). Click Apply and then Debug to launch the simulator. The simulator console should appear, showing the VxWorks boot process. Load and Run the Demo: In the simulator console, load the DKM: ld \u0026lt; uglteapot_demo.out Spawn the demo task: uglteapot If successful, a graphical window should open, displaying the rotating teapot. If no window appears, ensure the simulator is configured for graphics output (see troubleshooting below). Step 4: Running on Target Hardware # To run on real hardware (e.g., an Intel x86 board with a graphics card):\nConfigure the VIP for Hardware: Update the VIP to match your board’s BSP (Board Support Package) instead of the simulator. Rebuild the VIP and transfer the image to the target (e.g., via TFTP or USB). Connect to the Target: Use Workbench’s Target Manager to connect to the board via a target server. Load and run the DKM as in the simulator steps. Verify Output: Connect a monitor to the target’s graphics output. The teapot should render on-screen. Troubleshooting Common Issues # Graphics Window Not Appearing: Ensure INCLUDE_FBDEV and graphics drivers are in the kernel. For the simulator, verify the host machine supports graphical output (e.g., X11 on Linux or a compatible display server on Windows). WindML Not Found: If VxWorks 7 lacks native WindML support, port the library from an older version or adapt the demo to use OpenGL ES (consult Wind River support for legacy compatibility). Linker Errors: Check library paths and ensure all dependencies (e.g., ugl, ugluc) are linked. Use nm or objdump on the .out file to inspect Ascertain that all required libraries are present. Crash on Execution: Increase the task stack size in taskSpawn (e.g., from 100000 to 200000) if the demo crashes due to stack overflow. Modern Alternatives in VxWorks 7 # While WindML demos like uglteapot are educational, VxWorks 7 encourages using modern graphics APIs:\nOpenGL ES: Hardware-accelerated 3D graphics. OpenVG: Vector graphics for 2D interfaces. Tilcon UI: A commercial UI framework for advanced GUIs. To adapt uglteapot for OpenGL ES, replace WindML calls with OpenGL equivalents (e.g., glClear, glRotatef), though this requires more extensive code changes.\nConclusion # Running a WindML graphics demo on VxWorks 7 is a blend of leveraging legacy code and adapting to a modern RTOS environment. By carefully configuring your VSB and VIP projects, integrating the demo into a DKM, and testing on the simulator or hardware, you can successfully visualize the teapot demo. This process not only demonstrates VxWorks 7’s flexibility but also bridges its historical capabilities with contemporary graphics standards. For further assistance, consult the VxWorks 7 documentation or Wind River’s support resources.\n","date":"2025-03-24","externalUrl":null,"permalink":"/app/running-a-windml-graphics-demo-on-vxworks-7/","section":"Apps","summary":"\u003cp\u003eVxWorks, developed by Wind River Systems, is a leading real-time operating system (RTOS) widely used in embedded systems requiring deterministic performance. With the release of VxWorks 7, the OS has been re-engineered for modularity, scalability, and modern hardware support, including advanced graphics capabilities. While WindML—a graphics library prominent in earlier VxWorks versions like 5.x and 6.x—has largely been superseded by standards like OpenGL ES and OpenVG in \u003ca href=\"https://www.vxworks7.com\" target=\"_blank\"\u003eVxWorks 7\u003c/a\u003e, it’s still possible to run WindML-based graphics demos with the right setup. This article provides a step-by-step guide to running a WindML graphics demo (specifically, the classic \u003ccode\u003euglteapot\u003c/code\u003e demo) on VxWorks 7, leveraging its backward compatibility and development tools like Wind River Workbench 4.\u003c/p\u003e","title":"Running a WindML Graphics Demo on Vxworks 7","type":"app"},{"content":" Introduction # VxWorks 7 is a powerful real-time operating system (RTOS) widely used in embedded systems, particularly those requiring high levels of real-time performance and stability. VxWorks 7 supports the TCP/IP protocol stack, making it suitable for network communication and various network applications. In this article, we will explore how to perform TCP network programming on VxWorks 7, helping developers understand and implement TCP-based communication.\nDevelopment Environment Setup # Before diving into TCP network programming on VxWorks 7, we need to ensure that the development environment is set up and configured correctly:\nNecessary Software Tools:\nVxWorks 7: Make sure that VxWorks 7 and Wind River Workbench are installed, as they provide the integrated development environment for application development and debugging. VxWorks Network Protocol Stack: VxWorks 7 comes with an integrated TCP/IP protocol stack, which only needs to be enabled in the Board Support Package (BSP) configuration. Target Hardware: You will need a development board or virtual machine with network interfaces (such as an Ethernet adapter) to test the network functionality. Steps for Setting Up the Environment:\nInstall VxWorks 7 and Workbench: Ensure that you have both VxWorks 7 and Wind River Workbench installed on your development machine. Enable the Network Protocol Stack: By default, VxWorks supports the TCP/IP protocol stack, but you will need to enable this option when creating the BSP for your platform. Connect to a Network: Connect your target device (e.g., development board) to your development host via Ethernet, Wi-Fi, or use a simulator for testing. Basic TCP Network Programming # VxWorks 7 uses the BSD socket API for network programming, which adheres to the standard TCP/IP protocol, allowing you to create both client and server applications.\nKey Socket APIs:\nsocket(): Creates a socket. bind(): Binds a socket to a local address and port. listen(): Prepares the server socket to listen for connection requests. accept(): Accepts a client connection request. connect(): Connects a client to a server. send() and recv(): Send and receive data. close(): Closes the socket. These APIs are available on VxWorks 7 and allow developers to perform TCP socket communication.\nSimple TCP Server Programming Example # Below is a basic TCP server program that demonstrates how to use socket programming to create a simple TCP server on VxWorks 7. The server listens on a specific port, accepts client connection requests, and receives messages from the client.\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;stdlib.h\u0026gt; #include \u0026lt;string.h\u0026gt; #include \u0026lt;netinet/in.h\u0026gt; #include \u0026lt;sys/socket.h\u0026gt; #include \u0026lt;arpa/inet.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; #define SERVER_PORT 12345 #define BUFFER_SIZE 1024 int main() { int server_sock, client_sock; struct sockaddr_in server_addr, client_addr; socklen_t client_len = sizeof(client_addr); char buffer[BUFFER_SIZE]; int n; // Create server socket server_sock = socket(AF_INET, SOCK_STREAM, 0); if (server_sock \u0026lt; 0) { perror(\u0026#34;socket() failed\u0026#34;); return -1; } // Set up server address memset(\u0026amp;server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_addr.s_addr = htonl(INADDR_ANY); // Accept connections from all network interfaces server_addr.sin_port = htons(SERVER_PORT); // Bind socket to the address if (bind(server_sock, (struct sockaddr *)\u0026amp;server_addr, sizeof(server_addr)) \u0026lt; 0) { perror(\u0026#34;bind() failed\u0026#34;); close(server_sock); return -1; } // Listen for incoming client connections if (listen(server_sock, 5) \u0026lt; 0) { perror(\u0026#34;listen() failed\u0026#34;); close(server_sock); return -1; } printf(\u0026#34;Server is listening on port %d...\\n\u0026#34;, SERVER_PORT); // Accept client connection client_sock = accept(server_sock, (struct sockaddr *)\u0026amp;client_addr, \u0026amp;client_len); if (client_sock \u0026lt; 0) { perror(\u0026#34;accept() failed\u0026#34;); close(server_sock); return -1; } printf(\u0026#34;Client connected: %s\\n\u0026#34;, inet_ntoa(client_addr.sin_addr)); // Receive data from client while (1) { memset(buffer, 0, sizeof(buffer)); n = recv(client_sock, buffer, sizeof(buffer), 0); if (n \u0026lt;= 0) { printf(\u0026#34;Connection closed or error occurred\\n\u0026#34;); break; } printf(\u0026#34;Received from client: %s\\n\u0026#34;, buffer); // Send the received message back to the client send(client_sock, buffer, n, 0); } // Close sockets close(client_sock); close(server_sock); return 0; } Code Explanation:\nCreate Socket: The socket() function creates a TCP socket. Bind Address: The bind() function binds the socket to a local IP address and port, so the server can listen on a specific port. Listen for Connections: The listen() function prepares the server socket to listen for incoming client connections. Accept Connection: The accept() function accepts an incoming connection and returns a new socket to communicate with the client. Receive and Send Data: The recv() function receives data from the client, and send() sends the received data back to the client (echo server). Close Socket: After communication ends, the close() function closes both the client and server sockets. TCP Client Programming Example # Next, here’s a simple TCP client program that connects to the server and sends data.\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;stdlib.h\u0026gt; #include \u0026lt;string.h\u0026gt; #include \u0026lt;netinet/in.h\u0026gt; #include \u0026lt;sys/socket.h\u0026gt; #include \u0026lt;arpa/inet.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; #define SERVER_IP \u0026#34;192.168.1.100\u0026#34; // Server IP address #define SERVER_PORT 12345 #define BUFFER_SIZE 1024 int main() { int client_sock; struct sockaddr_in server_addr; char buffer[BUFFER_SIZE]; int n; // Create client socket client_sock = socket(AF_INET, SOCK_STREAM, 0); if (client_sock \u0026lt; 0) { perror(\u0026#34;socket() failed\u0026#34;); return -1; } // Set up server address memset(\u0026amp;server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_port = htons(SERVER_PORT); server_addr.sin_addr.s_addr = inet_addr(SERVER_IP); // Connect to the server if (connect(client_sock, (struct sockaddr *)\u0026amp;server_addr, sizeof(server_addr)) \u0026lt; 0) { perror(\u0026#34;connect() failed\u0026#34;); close(client_sock); return -1; } printf(\u0026#34;Connected to server %s:%d\\n\u0026#34;, SERVER_IP, SERVER_PORT); // Send data to the server while (1) { printf(\u0026#34;Enter message to send: \u0026#34;); fgets(buffer, sizeof(buffer), stdin); if (strcmp(buffer, \u0026#34;exit\\n\u0026#34;) == 0) break; // Exit condition send(client_sock, buffer, strlen(buffer), 0); // Receive echoed message from server memset(buffer, 0, sizeof(buffer)); n = recv(client_sock, buffer, sizeof(buffer), 0); if (n \u0026lt;= 0) { printf(\u0026#34;Server closed connection\\n\u0026#34;); break; } printf(\u0026#34;Received from server: %s\\n\u0026#34;, buffer); } // Close socket close(client_sock); return 0; } Code Explanation:\nCreate Socket: The socket() function creates a TCP socket for the client. Connect to Server: The connect() function connects the client to the server’s IP and port. Send and Receive Data: The send() function sends a message to the server, while the recv() function receives the server\u0026rsquo;s echoed message. Close Socket: After communication ends, the close() function closes the client socket. Conclusion # In this article, we demonstrated how to perform basic TCP socket programming on VxWorks 7, creating a simple TCP server and client. VxWorks 7 provides a robust network protocol stack that allows you to use the BSD socket API for network communication, making it similar to traditional Linux/Unix systems. Developers can easily port existing network code to VxWorks.\nIf you need to implement more complex communication using TCP, you can extend this basic example with features like multithreading, SSL encryption, timeout handling, etc.\n","date":"2025-03-23","externalUrl":null,"permalink":"/app/tcp-socket-programming-on-vxworks-7/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eVxWorks 7 is a powerful real-time operating system (RTOS) widely used in embedded systems, particularly those requiring high levels of real-time performance and stability. \u003ca href=\"https://www.vxworks7.com\" target=\"_blank\"\u003eVxWorks 7\u003c/a\u003e supports the TCP/IP protocol stack, making it suitable for network communication and various network applications. In this article, we will explore how to perform TCP network programming on VxWorks 7, helping developers understand and implement TCP-based communication.\u003c/p\u003e","title":"TCP Socket Programming on VxWorks 7","type":"app"},{"content":"VxWorks 7 is a real-time operating system (RTOS) designed for embedded systems, offering high performance, scalability, and advanced features for demanding applications. Running VxWorks on the Xilinx Zynq 7000 SoC (System on Chip) provides the benefit of combining ARM Cortex-A9 processing power with programmable logic (FPGA), making it ideal for a wide range of embedded applications, from industrial automation to automotive and communications.\nThis guide covers the essential steps for configuring VxWorks 7 to run on the Zynq 7000 series.\nPrerequisites # Before getting started, make sure you have the following:\nVxWorks 7 Development Environment: This includes the VxWorks Workbench and the required BSP (Board Support Package) for Zynq 7000. Xilinx Vivado: For hardware design and configuration of the Zynq 7000. Zynq 7000 Evaluation Kit or your custom hardware setup. Cross-compiler tools for VxWorks 7. Target hardware (ZCU102, ZC702, or custom Zynq 7000-based board). Setting Up the Hardware # Creating a Zynq 7000 Design in Vivado # You’ll need to create a design in Xilinx Vivado that configures the Zynq 7000 SoC to work with VxWorks 7. This step involves designing the programmable logic (FPGA) and defining the processing system.\nOpen Vivado: Create a new project and select your Zynq 7000 target device. Configure the Processing System: In Vivado, use the Zynq 7000 IP block to set up the ARM Cortex-A9 processor cores. Configure peripherals such as UART, Ethernet, GPIO, and timers based on your application requirements. Integrate the Programmable Logic (PL): Use the FPGA fabric to add any necessary custom logic or accelerators. Export the Hardware`: Once your design is complete, export the hardware (including the bitstream file) for use in the VxWorks environment. Exporting the Hardware Platform # After configuring your hardware design in Vivado:\nExport the hardware platform as an XSA (Xilinx Software Archive) file. This file will be used by the VxWorks development environment to integrate the hardware and software. Configuring VxWorks 7 # Setting Up VxWorks Workbench # VxWorks Workbench is the integrated development environment (IDE) that facilitates the development and configuration of VxWorks applications.\nInstall VxWorks Workbench on your development machine. Open Workbench and create a new VxWorks project. Select your target architecture (ARM Cortex-A9 for Zynq 7000) and board configuration. Import the Zynq 7000 BSP (Board Support Package) into your VxWorks Workbench project. This BSP includes drivers for peripherals and other hardware components such as UART, Ethernet, and storage. Building the Bootloader # For Zynq 7000, the bootloader (U-Boot) is used to initialize the system and load the operating system. You need to configure the bootloader for your hardware.\nConfigure U-Boot: You can modify U-Boot to handle the specific configuration of the Zynq 7000. This may include setting up boot devices, loading VxWorks from memory, and initializing peripherals. Build the Bootloader: Use the cross-compiler toolchain provided by Wind River to compile U-Boot. Building the Kernel # The kernel is the core of the VxWorks operating system. In VxWorks 7, you can configure the kernel to match the hardware and software requirements of your application.\nUse the VxWorks Workbench to configure kernel settings such as memory management, interrupt handling, scheduling, and system calls. Compile the kernel for the ARM architecture of the Zynq 7000. Configuring and Building Drivers # VxWorks provides drivers for various hardware components, but for custom peripherals, you may need to configure or write your own drivers.\nEnable Peripherals: Use the BSP to enable peripherals like Ethernet, USB, or UART. This can be done in the Workbench IDE by modifying the configuration files. Custom Drivers: If your application requires specific hardware (such as custom FPGA logic), you can create device drivers for it. Cross-Compiling for ARM Cortex-A9 # The Zynq 7000 uses ARM Cortex-A9 processors, so you need to use a cross-compiler to build your VxWorks applications. VxWorks 7 comes with a cross-compilation toolchain that supports ARM processors.\nSet up the cross-compiler: Configure the VxWorks cross-compilation tools to compile your application for ARM. Develop Your Application: Write the application code in C/C++ for VxWorks, using the APIs and libraries provided by the VxWorks kernel. Compile the Application: Use the Workbench IDE to compile your application code and create the executable. Flashing the System Image # Once you\u0026rsquo;ve compiled the bootloader, kernel, and application, you need to flash the system image to the target device.\nTransfer Files: Copy the bootloader, VxWorks kernel, and application to a storage device (e.g., SD card or NAND flash). Boot from SD Card: Configure U-Boot to boot from the SD card or other storage device where the VxWorks image is stored. Boot the Zynq 7000: Power up your Zynq board, and it should automatically boot into VxWorks. Debugging and Optimization # Once your system is up and running, you can begin debugging and optimizing your VxWorks application.\nUse Workbench Debugger: VxWorks Workbench offers a powerful debugger that can connect to your target system. You can set breakpoints, view variables, and step through code. Profile the System: Use VxWorks performance analysis tools to identify bottlenecks and optimize the application for speed and memory usage. Conclusion # Running VxWorks 7 on the Zynq 7000 series is a powerful solution for embedded systems that require both high-performance processing and custom hardware logic. By following the steps outlined above, you can design, configure, and deploy a robust real-time application that takes full advantage of the ARM Cortex-A9 and FPGA resources in the Zynq 7000.\nWhether you\u0026rsquo;re building a complex industrial system or an automotive application, the combination of VxWorks 7 and Zynq 7000 provides a flexible and reliable platform for embedded development.\n","date":"2025-03-23","externalUrl":null,"permalink":"/bsp/designing-and-configuring-vxworks-7-for-zynq-7000/","section":"Bsps","summary":"\u003cp\u003e\u003ca href=\"https://www.vxworks7.com\" target=\"_blank\"\u003eVxWorks 7\u003c/a\u003e is a real-time operating system (RTOS) designed for embedded systems, offering high performance, scalability, and advanced features for demanding applications. Running VxWorks on the Xilinx Zynq 7000 SoC (System on Chip) provides the benefit of combining ARM Cortex-A9 processing power with programmable logic (FPGA), making it ideal for a wide range of embedded applications, from industrial automation to automotive and communications.\u003c/p\u003e","title":"Designing and Configuring VxWorks 7 for Zynq 7000","type":"bsp"},{"content":"","date":"2025-03-23","externalUrl":null,"permalink":"/tags/zynq-7000/","section":"Tags","summary":"","title":"Zynq-7000","type":"tags"},{"content":"","date":"2025-03-22","externalUrl":null,"permalink":"/tags/arm-cortex-r82/","section":"Tags","summary":"","title":"Arm Cortex-R82","type":"tags"},{"content":"","date":"2025-03-22","externalUrl":null,"permalink":"/tags/armv8-r/","section":"Tags","summary":"","title":"Armv8-R","type":"tags"},{"content":"","date":"2025-03-22","externalUrl":null,"permalink":"/tags/multicore-processing/","section":"Tags","summary":"","title":"Multicore Processing","type":"tags"},{"content":"The Arm Cortex-R82 is a game-changer in the world of real-time processing, blending high-performance 64-bit computing with the deterministic behavior critical for embedded systems. Introduced by Arm in 2020, this processor is the first in the Cortex-R family to support a full Memory Management Unit (MMU), enabling it to run rich operating systems like Linux while maintaining the low-latency, real-time capabilities that the R-series is known for. For developers working on mission-critical applications—such as storage controllers, automotive systems, or industrial automation—pairing the Cortex-R82 with Wind River’s VxWorks real-time operating system (RTOS) offers a compelling solution. This article explores the potential of running VxWorks on the Cortex-R82, highlighting its benefits, challenges, and practical considerations.\nThe Cortex-R82: A New Era for Real-Time Processing # The Cortex-R82 stands out as the highest-performance real-time processor in Arm’s Cortex-R lineup. Built on the Armv8-R AArch64 architecture, it supports up to 1TB of DRAM—far exceeding the 4GB limit of its 32-bit predecessors like the Cortex-R8. This leap in addressable memory, combined with an optional MMU, allows the Cortex-R82 to handle complex workloads that were previously the domain of application-class processors like the Cortex-A series. Additionally, its optional Neon SIMD extension accelerates machine learning (ML) and signal processing tasks, making it ideal for emerging use cases like computational storage and edge AI.\nFor real-time applications, the Cortex-R82 delivers deterministic execution with low interrupt latency, a hallmark of the Cortex-R family. It supports up to eight cores in a cluster, offering scalability while maintaining precise control over thread scheduling and interrupt handling. These features make it a natural fit for an RTOS like VxWorks, which has a long history of powering mission-critical embedded systems.\nVxWorks: The RTOS Titan # VxWorks, developed by Wind River Systems, is a leading RTOS renowned for its reliability, security, and real-time performance. Since its debut in 1987, it has been deployed in diverse applications, from aerospace (e.g., powering the Mars 2020 rover) to industrial control and telecommunications. VxWorks supports a wide range of processor architectures, including Arm, Intel, Power, and RISC-V, and is designed to handle both 32-bit and 64-bit systems. Its flexibility extends to multicore configurations, supporting Asymmetric Multiprocessing (AMP), Symmetric Multiprocessing (SMP), and hybrid modes via its Type 1 hypervisor.\nThe latest iteration, VxWorks 7, emphasizes modularity and scalability, separating the kernel from middleware and applications for easier updates and customization. It also includes advanced features like Time-Sensitive Networking (TSN) for deterministic communication and support for AI/ML frameworks like TensorFlow Lite, aligning well with the Cortex-R82’s capabilities.\nWhy Run VxWorks on Cortex-R82? # Pairing VxWorks with the Cortex-R82 offers several advantages for embedded developers:\nReal-Time Determinism Meets High Performance: The Cortex-R82’s real-time strengths complement VxWorks’ ability to guarantee precise task scheduling and interrupt response times. This is critical for applications like automotive safety systems or high-speed storage controllers, where delays are unacceptable.\n64-Bit Scalability: With support for up to 1TB of DRAM, the Cortex-R82 enables VxWorks to manage larger datasets and more complex applications. This is particularly valuable for computational storage, where local processing of massive data volumes is required.\nMulticore Flexibility: VxWorks’ mature multicore support—spanning AMP, SMP, and CPU affinity—allows developers to fully exploit the Cortex-R82’s multi-core architecture. For example, one core could handle real-time tasks while others process background workloads, all within a single OS instance.\nRich Ecosystem Compatibility: While the Cortex-R82’s MMU enables Linux, VxWorks provides a lighter, more deterministic alternative for embedded use cases. Its integration with Wind River’s development tools, like the Workbench IDE, streamlines development and debugging.\nSafety and Certification: VxWorks offers certification evidence for standards like ISO 26262 (automotive) and DO-178C (avionics), making it a trusted choice for safety-critical systems—a key consideration for Cortex-R82 applications in automotive or industrial domains.\nPractical Considerations and Challenges # While the combination is promising, running VxWorks on the Cortex-R82 requires careful planning:\nBoard Support Package (BSP) Development: VxWorks requires a BSP tailored to the target hardware. Although Wind River provides BSPs for many Arm processors (e.g., Cortex-A53 and Cortex-R5), the Cortex-R82’s unique features—like its MMU and 64-bit architecture—may necessitate custom development. Developers can leverage VxWorks’ platform support layers and device tree framework to accelerate this process.\nMemory Management: The Cortex-R82’s MMU introduces virtual memory capabilities, which VxWorks can utilize for richer software stacks. However, real-time applications often prefer the predictability of physical memory access via the Memory Protection Unit (MPU). Developers must configure VxWorks to balance these options based on their needs.\nPerformance Tuning: To maximize the Cortex-R82’s potential, VxWorks’ scheduler and interrupt handling must be optimized. Features like CPU reservation and interrupt affinity can ensure critical tasks run on dedicated cores, minimizing latency.\nToolchain Compatibility: VxWorks supports multiple compilers (e.g., Diab, GNU, Intel C++), and developers must ensure their toolchain aligns with the Cortex-R82’s 64-bit Armv8-R architecture. Wind River’s continuous updates to VxWorks should mitigate compatibility issues.\nLicensing and Cost: VxWorks is proprietary software, and its licensing costs may be a factor compared to open-source alternatives like Linux. However, its proven track record and support justify the investment for many high-stakes projects.\nUse Case: Computational Storage # One compelling application is computational storage, where the Cortex-R82’s high performance and memory capacity shine. Imagine a solid-state drive (SSD) controller running VxWorks on the Cortex-R82: one core processes real-time I/O requests with deterministic latency, while others use Neon-accelerated ML models to analyze data locally. VxWorks’ TSN support ensures reliable communication with the host, and its small footprint keeps resource usage minimal—an advantage over heavier OSes like Linux in this context.\nGetting Started # To run VxWorks on the Cortex-R82, developers should:\nContact Wind River for the latest VxWorks release and Cortex-R82 support status. Obtain a development board or reference design featuring the Cortex-R82 (e.g., from Arm partners). Build a BSP using VxWorks’ tools, starting with an existing Armv8-R BSP as a template. Test a minimal kernel, then incrementally add drivers and application code. Conclusion # The Arm Cortex-R82 and VxWorks form a powerful duo for next-generation embedded systems, combining cutting-edge hardware with a battle-tested RTOS. Whether powering automotive zone controllers, advanced storage solutions, or industrial automation, this pairing offers unmatched real-time performance, scalability, and reliability. While some customization is required, the investment unlocks a platform capable of meeting the demands of today’s most challenging applications. As embedded systems evolve, VxWorks on Cortex-R82 stands ready to drive innovation at the intelligent edge.\n","date":"2025-03-22","externalUrl":null,"permalink":"/bsp/running-vxworks-on-the-arm-cortex-r82/","section":"Bsps","summary":"\u003cp\u003eThe Arm Cortex-R82 is a game-changer in the world of real-time processing, blending high-performance 64-bit computing with the deterministic behavior critical for embedded systems. Introduced by Arm in 2020, this processor is the first in the Cortex-R family to support a full Memory Management Unit (MMU), enabling it to run rich operating systems like Linux while maintaining the low-latency, real-time capabilities that the R-series is known for. For developers working on mission-critical applications—such as storage controllers, automotive systems, or industrial automation—pairing the Cortex-R82 with Wind River’s VxWorks real-time operating system (RTOS) offers a compelling solution. This article explores the potential of running VxWorks on the Cortex-R82, highlighting its benefits, challenges, and practical considerations.\u003c/p\u003e","title":"Running VxWorks on the Arm Cortex-R82: Architecture, Benefits, and BSP Considerations","type":"bsp"},{"content":"Kontronn Systems is pleased to inform about the VxWorks BSP release for its XILINX UltraScale+ MPSoC System on Modules. VxWorks 21.03 has now been ported on the ik-X30M system on the module, which is powered by the ZU 4/5/7 MPSoC.\nVxWorks is Industry’s leading real-time operating system for building embedded devices\u0026amp; systems.\nThe ZU 4/5/7 System on module, integrated with high-speed interfaces when built with VxWorks BSP, ensures the scalability, safety, and reliability required for mission-critical applications.\nThe Zynq® UltraScale+™ MPSoC series provide 64-bit processor scalability while combining real-time control with soft and hard engines for graphics, video, waveform, and packet processing. These Adaptive SoCs complement the decade-long availability of soft-core CPUs and other soft IPs for building systems on FPGAs. Adaptive SoCs then is particularly useful when high performance is required for a portion of an algorithm that can be implemented in hardware using parallel or pipelined (or a combination) techniques.\nWhy VxWorks on Zynq UltraScale+ MPSoC\nThe combination of VxWorks on the Zynq UltraScale+ MPSoC provides the foundation for secure high-speed high-performance computing applications. Highlighted below are the key features of VxWorks and UltraScale+ MPSoC, together which power devices across verticals.\nVxWorks is ideal for hard real-time embedded applications because it is a deterministic, priority-based, pre-emptive RTOS with low latency and minimal jitter, with a few feature highlights as below:\nRich connectivity and communications: VxWorks has robust IPv4 and IPv6 stacks that are also time-sensitive networking (TSN) capable, guaranteeing real-time communications and packet delivery within a bounded time or latency on a switched Ethernet network\nModularity and Robustness: easy to choose and adapt capabilities as required, changing the modules only as needed.\nFault-tolerant file system: VxWorks supports the Wind River Highly Reliable File System (HRFS) for fault tolerance and recovery of operations in case of system error and shutdown, as well as a FAT-compatible dosFS file system.\nMixed OS support: VxWorks supports communicating with other operating systems in a mixed environment using OpenAMP, allowing developers to build interactive functionality across VxWorks real-time and other non–real-time environments.\nMultimedia: VxWorks offers support for many standard graphic libraries, such as OpenGL, OpenGL ES, OpenCV, and Vulkan, and libraries that handle JPEG and PNG images\nSecurity: VxWorks integrates an extensive and continuously evolving set of security capabilities that allow developers to meet rigorous security requirements and address security threats—from boot-up operation to power down. A few secure capabilities include kernel hardening, cryptography, firewall, TPM 2.0, secure data, and configuration.\nThe true value of Zynq UltraScale+ MPSoC architecture lies in the tight integration of its programmable logic with the processing system, with a few highlights listed below:\nHeterogeneous Processing: Multiple processing engines enable the optimization of functions across an entire application, with programmable hardware providing further performance and safety handling\nIntegrated H.264/H.265 Video Codec: Zynq UltraScale+ EV devices include a video codec capable of low latency simultaneous encode and decode up to 4K resolution at 60 frames per second\nIncreased safety and multiple levels of security Superior processing, I/O, and memory bandwidth Potential application of VxWorks on Zynq UltraScale+ MPSoC\nWith Zynq UltraScale+ MPSoC finding a fit in Industrial networking (time-sensitive networking), high precision test and measurement equipment, medical imaging, and avionics, VxWorks BSP help strengthen the safety, security, and modularity on the device.\nSafety-critical applications like automotive, industrial motor control, avionics, and many others need to have high reliability and required Safety Integrity Levels (ASILs), for which it is necessary to mitigate soft errors and implement redundancy to have better hard fault toleration, where the combination of VxWorks and UltraScale+ MPSoC is an ideal fit.\nVxWorks finds a great fit in embedded applications that require real-time, deterministic performance which requires safety and security certification in industries such as medical, aerospace, robotics, and network infrastructure.\nScalability across the XILINX UltraScale+ MPSoC\nThe SOM approach for the FPGA SoCs further allows greater scalability for the end applications in terms of logic density, FPGA IOs, and a number of transceiver lanes. For example, a well-designed carrier board design architecture can cover system IO ports for multiple end products ranging from the Xilinx Zynq MPSoC UltraScale+ ZU4 with 192K logic cells to ZU19 with 1.1M logic cells. Also, the SOM approach allows migrating new generation SoC solutions without changing the product mechanical architecture.\nAbout Kontronn\nKontronn offers individual solutions in the areas of Internet of Things (IoT) and Industry 4.0 through a combined portfolio of hardware, software and services.\n","date":"2025-03-18","externalUrl":null,"permalink":"/news/vxworks-bsp-for-zynq-ultrascale-mpsoc-powered-system-on-modules/","section":"News","summary":"\u003cp\u003eKontronn Systems is pleased to inform about the VxWorks BSP release for its XILINX UltraScale+ MPSoC System on Modules. VxWorks 21.03 has now been ported on the ik-X30M system on the module, which is powered by the ZU 4/5/7 MPSoC.\u003c/p\u003e","title":"VxWorks BSP for Zynq UltraScale+ MPSoC Powered System on Modules","type":"news"},{"content":"","date":"2025-03-18","externalUrl":null,"permalink":"/tags/zynq-ultrascale+/","section":"Tags","summary":"","title":"Zynq UltraScale+","type":"tags"},{"content":"","date":"2025-03-08","externalUrl":null,"permalink":"/tags/datasheet/","section":"Tags","summary":"","title":"Datasheet","type":"tags"},{"content":"","date":"2025-03-08","externalUrl":null,"permalink":"/series/industries/","section":"Series","summary":"","title":"Industries","type":"series"},{"content":"VxWorks® is the world’s most widely deployed real-time operating system (RTOS) that provides high reliability and determinism with low latency and minimal jitter. Built on a modern, upgradable, future-proof architecture, it helps rapidly address changing market requirements and technology advancements. VxWorks sets the standard for a scalable, safe, secure, and reliable operating environment for running mission-critical computing systems that demand the highest standards. It powers innovative products for aerospace and defense, rail, automobiles, medical devices, manufacturing plants, and communications networks that simply cannot fail.\nVxWorks brings nearly 40 years of leadership and continuous innovation to support modern use cases. The latest releases enable such technologies as cloud convergence, bringing IoT connectivity with major cloud vendors, IT-like applications deployment, and an Open Container Initiative (OCI)–complaint container engine. As the leading RTOS for the intelligent edge, it integrates embedded system–optimized artificial intelligence and machine learning frameworks such as TensorFlow Lite and Python, industry automation with OPC-UA, and deterministic performance Time-Sensitive Networking support. It also packages the software source in a trustworthy, transparent Git repository; offers SBOM support; and includes mitigation processes to counter cybersecurity threats throughout the lifecycle.\nVxWorks gives you the capability to deal with the most demanding time constraints while enabling modern use cases, using the latest available technology that powers the intelligent edge.\nUSE CASES # End-to-End Support for Application Deployment Through Containers\nVxWorks is the first and only RTOS in the world to provide support for OCI containers. This enables the use of IT-like technologies to develop and deploy intelligent edge software better and faster, without compromising determinism and performance.\nFigure 1. End-to-end workflow creating and distributing containers Key outcomes:\nSimplifies application modularization through development and deployment Make software easier to deploy and run reliably when moved Enables software operation and management in the field Provides containerization with no impact on application performance Leverages an OCI-compliant container engine optimized for the mission-critical edge Increase Developer Productivity with a Modernized RTOS Approach\nVxWorks is the only RTOS to support C++17, Boost, Rust, Python, pandas, Time-Sensitive Networking (TSN) and more, as well as cloud IoT connectivity and an edge-optimized, OCI-compliant container engine — enabling you to use the languages, tools, and technologies you love most to innovate where it matters most.\nFigure 2. A complete set of tools for the modern developer’s journey Key outcomes:\nGreater efficiency and portability with overall cost reduction Support for artificial intelligence/machine learning frameworks Complete developer toolset with intelligent automation solutions Comprehensive collection of board support packages Flexible development paradigm Commercial Off-the-Shelf Solution for Safety-Critical Applications\nVxWorks Cert Edition provides a commercial off-the-shelf (COTS) RTOS solution for delivering safety-critical applications that must achieve the highest and most stringent certification levels, such as RTCA DO-178C DAL-A and EUROCAE ED-12C software considerations in airborne systems, IEC 61508 ASIL-3 industrial functional safety, IEC 62304 Class C medical device safety, and ISO 26262 ASIL-D automotive safety. With VxWorks Cert Edition, you can take full advantage of the technological advances in microprocessors that VxWorks enables, while knowing you have a strong operating system foundation to meet the most demanding safety certification standards.\nKey outcomes:\nHelps customers meet safety compliance requirements easily Enables safety use cases with reduced certification costs Optimized for specific hardware Written in lower-level languages such as C/C++ Interacts directly with hardware (e.g., peripherals) Has a long lifecycle and stateful execution CORE CAPABILTIES AND BENEFITS # Industry-leading RTOS Single and multi-core processor support with asymmetric multiprocessing (AMP) and symmetric multiprocessing (SMP) Separated kernel and user space environments Extensive POSIX® API support, including full POSIX PSE52-certified subset Scalable, modular, and high-performance State-of-the-art memory protection and management Delivers the highest levels of performance when and where it is most needed The first RTOS on Earth as well as on Mars, where reliability is a must Figure 3. VxWorks Cert Edition Figure 4. Platform development teams can create images of VxWorks quickly and eficiently using automation with cloud-native Wind River Studio Scheduling: Priority-based preemption with optional round-robin Time and space partitioning Adaptive scheduling offering foreground and background threading Figure 5. VxWorks safety scheduler Extensive processor and board support: 32-bit and 64-bit CPUs Broad spectrum of silicon architectures, including Arm®, Power Architecture®, Intel®, and RISC-V More than 100 different boards supported Figure 6. Broad and robust architecture and hardware support Capable of dealing with the most demanding time constraints: Up to 10% reduction in atomic operations time Network throughput on par with or better than Linux Up to 30% reduction in time spent in spinlocks Sub 3μs TSN interrupt response on selected Intel and Arm hardware Over 2x improvement in entropy collection time Figure 7. Direct interrupts and direct access to devices KEY FEATURES # Modern application development\nC11 and C++17 Boost C++ libraries Rust Python Cloud integration\nAWS IoT device SDK Microsoft Azure IoT SDK AI/ML\nNumPy TensorFlow Lite Virtualization ready\nVirtIO KVM guest support Security\nSecure boot (digitally signed image) Secure ELF loader (digitally signed applications) Secure storage Encrypted container Full disk encryption Kernel hardening Non-executable pages Stack guard pages Optional support for kernel page table isolation (KPTI) Protection of code and read-only data Stack smashing protection (SSP) Address Sanitizer (ASAN) Kernel Address Sanitizer (KASAN) Security events Built-in access controls Advanced user management Login policies Password policies Support for Active Directory/Lightweight Directory Access Protocol (AD/LDAP) Cryptography OpenSSL 3.x FIPS 140-2 Arm TrustZone with OP-TEE support TPM 2.0/TSS support Network security protocols such as SSL, TLS, SSH, IPsec, IKE, GDOI, SCEP, etc. Firewall GE Digital® Achilles Level 2 certified for compliance with IEC 62443-4-2 NIST-conformant Security Requirements Guide (SRG) NIST 800-53 mappings Networking\nIPv4/IPv6 network stack Time-Sensitive Networking (TSN) IEEE 802.1Qbv IEEE 802.1Qbu IEEE 1588 IEEE 802.1AS Connectivity\nUSB (host, target, and OTG) SocketCAN OPC UA (open62541) IEEE 1394 File system\ndosFs (FAT-compatible) Fault-tolerant and certifiable highly reliable file system (HRFS) with configurable commit Read-only ROM file system NFS Lifecycle and management\nOCI-compatible container engine (aligned with runc) Docker Registry HTTP API V2 Docker Hub Amazon ECR Harbor Wind River® Studio Conductor blueprints Multimedia\nSoftware and hardware support for OpenVG™, OpenGL®, OpenGL® ES, Vulkan® Image library (JPEG and PNG) Input device support (mouse, touch screen, keyboard, and others) PCM audio OpenCV Safety certifiable DO-178C DAL A Safety certifiable\nDO-178C DAL A IEC 61508 SIL 3 ISO 26262 ASIL D IEC 62304 Class C Tooling\nIndustry-leading toolchain (LLVM, CMake) Eclipse-based IDE Visual Studio Code (desktop and cloud native) Advanced debugger Real-time system analyzer System monitor Hardware simulation and emulation\nVxSIM (x86 only) QEMU (all architectures) Wind River Simics® STANDARDS AND CERTIFICATIONS # VxWorks Cert Edition is based on the proven standard commercial version of the VxWorks operating system and includes almost 900 kernel mode application programming interfaces (APIs) and more than 420 user mode APIs, all of which are fully deterministic and deployable under guidelines outlined in the DO-178C safety standards. They include cache, clock, event flag, interrupt, memory management, message queue, ring buffer, semaphore, signal, and task management calls, along with a wide array of C library functions.\nDevelopers can also make use of object-oriented programming using the VxWorks Cert Edition C++ language subset, which includes basic C++ constructs such as classes, inheritance, namespaces, polymorphism, and virtual functions. User mode applications are supported with real-time processes (RTPs) to a safety-certifiable environment. The VxWorks Cert Edition RTP API subset allows applications to take advantage of memory protection, thus simplifying software integration between parallel development groups.\nVxWorks Cert Edition delivers the highest levels of certification evidence for avionics, industrial, and automotive critical infrastructure. In all certification evidence packages, the fully hyperlinked content enables rapid traceability analysis of certification data. Certification evidence packages for VxWorks Cert Edition are optionally available for the following:\nDO-178C DAL-A and ED-12C airborne avionics safety IEC 61508 ASIL-3 industrial functional safety ISO 26262 ASIL-D automotive safety IEC 62304 Class C medical device software PARTNER ECOSYSTEM / TECHNOLOGIES # The Wind River partner portfolio includes a large ecosystem of complementary third-party hardware and software solutions. The portfolio helps accelerate time-to-market and differentiate platforms with best-of-breed capabilities, while reducing development costs.\nVisit our partner ecosystem at www.windriver.com/partners for a full list of our partners and their products.\nWIND RIVER PROFESSIONAL SERVICES # The CMMI Level 3–rated Wind River Professional Services organization leverages years of system design and development expertise to work collaboratively with customer design and program teams. Professional Services interprets system requirements; architects platform options; and provides recommendations for meeting business, technical, and program goals.\nFor more information, visit www.windriver.com/services.\nWIND RIVER EDUCATION SERVICES # Wind River offers instructor-led, on-demand, and mentored learning, including our anytime, anywhere access to online subscription-based e-learning.\nFor more information, visit www.windriver.com/education.\nWIND RIVER CUSTOMER SUPPORT # VxWorks is backed by our award-winning global support organization. We offer live help in multiple time zones, the online Wind River Support Network with multifaceted self-help options, and optional premium services to provide developers the fastest possible time-to-resolution.\nFor more information, visit www.windriver.com/services/customer-support.\n","date":"2025-03-08","externalUrl":null,"permalink":"/industries/vxworks-datasheet/","section":"Industries","summary":"\u003cp\u003e\u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks®\u003c/a\u003e is the world’s most widely deployed real-time operating system (RTOS) that provides high reliability and determinism with low latency and minimal jitter. Built on a modern, upgradable, future-proof architecture, it helps rapidly address changing market requirements and technology advancements. VxWorks sets the standard for a scalable, safe, secure, and reliable operating environment for running mission-critical computing systems that demand the highest standards. It powers innovative products for aerospace and defense, rail, automobiles, medical devices, manufacturing plants, and communications networks that simply cannot fail.\u003c/p\u003e","title":"VxWorks Datasheet","type":"industries"},{"content":"Qt, a versatile cross-platform framework, is widely recognized for its ability to create rich graphical user interfaces (GUIs) and robust applications across various operating systems. When paired with VxWorks, a real-time operating system (RTOS) developed by Wind River, Qt becomes a powerful tool for embedded systems development, particularly in industries like aerospace, defense, medical, and industrial automation. This article explores the process of enabling Qt on VxWorks, its benefits, and key considerations for developers.\nWhy Qt on VxWorks? # VxWorks is renowned for its deterministic performance and reliability, making it a staple in mission-critical applications. However, its native tools for GUI development are limited. Qt fills this gap by providing a modern, feature-rich framework that supports everything from basic widgets to advanced OpenGL-accelerated visualizations like Qt Quick. By enabling Qt on VxWorks, developers can create visually appealing, user-friendly interfaces without sacrificing the real-time capabilities of the RTOS.\nQt’s support for VxWorks has evolved significantly over the years. While earlier versions like Qt 4.8 were supported on VxWorks 6.9, recent releases such as Qt 5.15 LTS and Qt 6.8 have been optimized for VxWorks 7 and beyond, leveraging newer hardware capabilities and offering improved performance.\nPrerequisites for Enabling Qt on VxWorks # Before diving into the setup process, ensure you have the following:\nCommercial Qt License: Qt for VxWorks is available only under a commercial license from The Qt Company. Contact their sales team for access to the source packages. VxWorks Development Environment: Install Wind River’s VxWorks SDK, including the VxWorks Development Shell and a compatible toolchain (e.g., for ARM or x86_64 architectures). Supported Hardware: Qt has been verified on platforms like the Freescale i.MX6 (ARM-v7) and Intel NUC (x86_64). Ensure your target hardware aligns with these specifications or is compatible with VxWorks BSPs (Board Support Packages). Host System: A Linux (e.g., Ubuntu) or Windows host is required for building Qt, though Linux is recommended for the latest versions. Steps to Enable Qt on VxWorks # Here’s a high-level guide to setting up Qt on VxWorks, based on typical workflows outlined in Qt’s official documentation:\nObtain Qt Source Code: Log into your Qt Account and download the appropriate VxWorks source package (e.g., Qt 5.15.16 or Qt 6.8.1). Alternatively, request access through Qt Professional Services for the latest supported releases. Set Up the VxWorks Development Shell: On your host machine, navigate to the VxWorks installation directory and launch the development shell: cd \u0026lt;VxWorks_installation_directory\u0026gt; ./wrenv.sh -p vxworks export WIND_CC_SYSROOT=\u0026lt;path_to_VxWorks_VSB_directory\u0026gt; This configures the environment with the necessary compiler and linker tools. Configure Qt for VxWorks: Extract the Qt source package and navigate to its root directory. Run the configure script with options tailored to your device. For example, for an i.MX6 target: ./configure -commercial -confirm-license -device vxworks-imx6 \\ -device-option CROSS_COMPILE=arm -prefix /sd1:1/qt5rtp \\ -sysroot \u0026lt;path_to_vxworks_vsb_dir\u0026gt;/fsl_imx6_1_1_11_0_VSB \\ -no-gcc-sysroot -extprefix \u0026lt;path_to_host_dir\u0026gt;/qt5rtp \\ -hostprefix \u0026lt;path_to_host_dir\u0026gt;/qt5rtp -no-openssl \\ -nomake tools -nomake examples Use -static if you prefer a statically linked build to reduce dependencies. Build and Install Qt: Compile the source using a build tool like ninja or make: ninja ninja install This installs Qt to the specified prefix, ready for deployment to the target. Deploy to the VxWorks Target: Transfer the compiled Qt libraries and your application to the VxWorks filesystem (e.g., via FTP or SD card). Launch the application using the VxWorks shell, ensuring the correct environment variables are set if using shared libraries: putenv \u0026#34;LD_LIBRARY_PATH=/sd0:1/lib\u0026#34; cd \u0026#34;/sd0:1\u0026#34; rtpSp(\u0026#34;\u0026lt;your_qt_app\u0026gt;\u0026#34;, 200, 0x100000, 0, 0x01000000) Test and Debug: Use Qt Creator’s VxWorks plugin (available with newer releases) for seamless deployment and debugging. Configure the target’s IP address in Qt Creator to upload and run the application directly. Key Features and Considerations # Platform Plugins: Qt on VxWorks supports plugins like EGLFS (for GPU-accelerated devices) and VxWorksFB (for non-accelerated setups). EGLFS is recommended for modern devices with OpenGL ES 2.0 support, enabling Qt Quick 2 functionality. Graphics Memory: For high-resolution displays, ensure at least 128 MB of GPU memory is available to avoid performance issues. Module Selection: Exclude unnecessary modules (e.g., -skip ) during configuration to optimize the binary size for embedded constraints. Input Handling: Configure environment variables like QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS for touchscreens or disable built-in input handlers if needed. Benefits of Qt on VxWorks # Rich GUIs: Leverage Qt Quick for dynamic, hardware-accelerated interfaces. Cross-Platform Compatibility: Reuse code across VxWorks and other platforms supported by Qt. Real-Time Performance: Combine VxWorks’ determinism with Qt’s efficient rendering. Ecosystem Support: Access Qt Creator and a vast library of modules for rapid development. Challenges and Solutions # Hardware Variability: Not all VxWorks BSPs include graphics libraries by default. You may need to create a custom CMake toolchain file to integrate them. License Costs: The commercial license requirement may be a barrier for small projects. Evaluate your needs against Qt’s pricing model. Learning Curve: Developers new to VxWorks or Qt may need time to master the configuration process. Refer to Qt’s VxWorks documentation for detailed guidance. Conclusion # Enabling Qt on VxWorks opens the door to sophisticated embedded applications with modern interfaces, all while retaining the RTOS’s real-time strengths. As of March 1, 2025, Qt 6.8.1 is fully supported on VxWorks 24.03, with ongoing enhancements like the Qt Creator plugin improving the development experience. Whether you’re building a medical device or an aerospace control system, this combination offers a compelling solution for today’s embedded challenges. Start by securing your Qt license and experimenting with a supported reference board—your next innovative project awaits!\n","date":"2025-03-02","externalUrl":null,"permalink":"/app/enabling-qt-on-vxworks/","section":"Apps","summary":"\u003cp\u003eQt, a versatile cross-platform framework, is widely recognized for its ability to create rich graphical user interfaces (GUIs) and robust applications across various operating systems. When paired with VxWorks, a real-time operating system (RTOS) developed by Wind River, Qt becomes a powerful tool for embedded systems development, particularly in industries like aerospace, defense, medical, and industrial automation. This article explores the process of enabling Qt on \u003ca href=\"https://www.vxworks7.com\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e, its benefits, and key considerations for developers.\u003c/p\u003e","title":"Enabling Qt on VxWorks","type":"app"},{"content":"VxWorks 7 is a modern real-time operating system (RTOS) launched by Wind River, and its BSP (Board Support Package) development process has seen significant improvements in modularity and tool support. The BSP serves as the bridge between hardware and the operating system, handling hardware initialization, device drivers, and system configuration. This article provides a detailed guide on developing a BSP for VxWorks 7, including technical details and code examples.\nCore Components of a BSP # In VxWorks 7, a complete BSP typically includes the following files and functionalities:\nromInit.s: Assembly-language boot code for the lowest-level hardware initialization. sysLib.c: System library providing hardware-related core functions (e.g., clock and interrupt control). sysALib.s: Assembly utility functions, typically used in conjunction with sysLib.c. config.h: Hardware configuration header file defining compilation options and hardware parameters. Makefile: Build script controlling the BSP compilation process. Preparing the Development Environment # Install Wind River Workbench: Ensure the latest version of Workbench (e.g., 4.6 or higher) is installed, supporting VxWorks 7. Reference BSP: Start with a template provided by Wind River (e.g., wrSbcArmv8 or intel_x86_64) and copy it to a new project directory. Hardware Documentation: Obtain the chipset manual for the target board (e.g., NXP i.MX8 datasheet), clarifying CPU architecture, memory addresses, and peripheral registers. Detailed Development Steps # Creating a BSP Project # In Workbench, select “File \u0026gt; New \u0026gt; VxWorks Board Support Package,” enter the project name (e.g., myBsp) and target architecture (e.g., ARMv8). The generated project includes the following base files:\nromInit.s: Boot entry point. sysLib.c: System functions. config.h: Configuration file. Customizing Hardware Initialization # Modify Boot Code (romInit.s) .section .text .globl romInit romInit: /* Set the exception vector table base address */ ldr x0, =_vector_table msr VBAR_EL1, x0 /* Initialize the stack pointer */ ldr x0, =__stack_top mov sp, x0 /* Configure the clock (PLL) */ ldr x0, =0x40000000 /* Clock control register address */ ldr x1, =0x00001234 /* PLL configuration value */ str x1, [x0] /* Jump to C code */ bl sysInit b . Explanation: This code sets the exception vector table, initializes the stack, and configures the system clock (specific values must be referenced from the hardware manual). It then jumps to the sysInit function. Configure Memory Mapping (sysLib.c) Define the memory layout in sysLib.c: #include \u0026#34;vxWorks.h\u0026#34; #include \u0026#34;sysLib.h\u0026#34; LOCAL char *sysPhysMemTop = (char *)0x80000000; /* Assumed DRAM start address */ LOCAL UINT32 sysMemSize = 0x10000000; /* 256MB memory */ void sysHwInit(void) { /* Initialize memory controller */ *(volatile UINT32 *)0x40001000 = 0x00000101; /* Memory control register */ } char *sysMemTop(void) { return sysPhysMemTop; } Explanation: sysHwInit initializes the hardware, and sysMemTop returns the top memory address. Register addresses and values must be adjusted based on the hardware manual. Interrupt Initialization Configure interrupts for the ARM GIC (Generic Interrupt Controller):\nvoid sysIntInit(void) { /* Enable GIC distributor */ *(volatile UINT32 *)0xF9000000 = 0x1; /* GICD_CTLR */ /* Configure IRQ priority */ *(volatile UINT32 *)0xF9001000 = 0xA0; /* GICD_IPRIORITYR */ } Explanation: Specific addresses and values should refer to the GIC manual (e.g., ARM GICv3 specification). Implementing a Serial Port Driver # Using a UART driver as an example, assume the target hardware uses a 16550-compatible serial port:\n#include \u0026#34;drv/serial/serial.h\u0026#34; #define UART_BASE 0xF8000000 #define UART_THR (UART_BASE + 0x00) /* Transmit register */ #define UART_RBR (UART_BASE + 0x00) /* Receive register */ #define UART_LSR (UART_BASE + 0x14) /* Status register */ void uartInit(void) { /* Set baud rate to 115200, 8N1 */ *(volatile UINT32 *)(UART_BASE + 0x0C) = 0x83; /* LCR */ *(volatile UINT32 *)(UART_BASE + 0x00) = 0x0C; /* DLL */ *(volatile UINT32 *)(UART_BASE + 0x04) = 0x00; /* DLM */ *(volatile UINT32 *)(UART_BASE + 0x0C) = 0x03; /* LCR */ } int uartPutChar(char c) { while (!(*(volatile UINT32 *)UART_LSR \u0026amp; 0x20)); /* Wait for transmit buffer to be empty */ *(volatile UINT32 *)UART_THR = c; return 1; } int uartGetChar(void) { if (*(volatile UINT32 *)UART_LSR \u0026amp; 0x01) /* Check if data is ready */ return *(volatile UINT32 *)UART_RBR; return EOF; } Explanation: This code initializes the UART and provides basic transmit/receive functions. Register offsets and configuration values must match the hardware. Adjusting the Configuration File (config.h) # Enable necessary components and define hardware parameters:\n#define CPU _VX_ARMV8A /* ARMv8-A architecture */ #define SYS_CLK_RATE 1000000 /* System clock 1MHz */ #define INCLUDE_SERIAL /* Enable serial port support */ #define DEFAULT_BOOT_LINE \u0026#34;uart(0,115200)\u0026#34; Compilation and Debugging # In Workbench, select “Build \u0026gt; Build Project” to generate the VxWorks image. Use a JTAG tool (e.g., Segger J-Link) to flash the image onto the target board. Observe the boot log via a serial terminal (e.g., Tera Term or Minicom): VxWorks 7.0 BSP Version: 1.0 CPU: ARMv8-A Memory Size: 256MB Use the Workbench debugger to set breakpoints and verify functions like uartPutChar. Optimization and Testing # Test peripheral functions (e.g., send “Hello, VxWorks!” via the serial port). Use System Viewer to analyze performance bottlenecks and optimize interrupt handling or memory access. Notes on Serial Driver Development # Exception Handling: Properly set exception vectors in romInit.s to avoid system crashes. Driver Reusability: Encapsulate the driver as a VxWorks component (e.g., INCLUDE_MYSERIAL) for reuse across projects. Hardware Debugging: If issues arise, use an oscilloscope or logic analyzer to check signal integrity. Documentation: Record the basis for each register configuration to facilitate team collaboration. Summary # BSP development in VxWorks 7 combines powerful tool support with a flexible modular design. By customizing boot code, implementing drivers, and configuring the system, developers can seamlessly adapt the OS to target hardware. The code examples above are based on the ARMv8 architecture, but the principles apply to other platforms (e.g., PowerPC or x86). With Workbench’s debugging features and Wind River’s documentation, this process is both efficient and manageable.\nImplementing a Network Driver # Network driver development is an advanced task in BSP, typically based on VxWorks’ END (Enhanced Network Driver) framework. The following uses the NXP i.MX8 ENET controller as an example, implemented step-by-step.\nOverview of the Network Driver Framework VxWorks 7 uses the END framework to interface with the network stack (e.g., TCP/IP). An END driver must implement the following core functions:\nxxxInit: Initialize hardware. xxxSend: Send packets. xxxRecv: Receive packets. xxxIoctl: Control interface (e.g., set MAC address). xxxStart/xxxStop: Start/stop the device. Define Driver Data Structure Define private driver data in myEnet.c:\n#include \u0026#34;endLib.h\u0026#34; #include \u0026#34;muxLib.h\u0026#34; #define ENET_BASE 0x5B040000 /* Ethernet base address */ #define ENET_TX_DESC 0x5B041000 /* Transmit descriptor address */ #define ENET_RX_DESC 0x5B042000 /* Receive descriptor address */ typedef struct { END_OBJ endObj; /* END object, must be first */ UINT32 baseAddr; /* Controller base address */ UINT8 macAddr[6]; /* MAC address */ BOOL running; /* Running state */ M_BLK_ID txQueue; /* Transmit queue */ M_BLK_ID rxQueue; /* Receive queue */ } MY_ENET_DEV; Initialize Network Hardware (myEnetInit) LOCAL MY_ENET_DEV *pEnetDev = NULL; STATUS myEnetInit(MY_ENET_DEV *pDev) { /* Allocate device structure */ pDev = (MY_ENET_DEV *)malloc(sizeof(MY_ENET_DEV)); if (!pDev) return ERROR; pDev-\u0026gt;baseAddr = ENET_BASE; pDev-\u0026gt;running = FALSE; /* Set default MAC address */ pDev-\u0026gt;macAddr[0] = 0x00; pDev-\u0026gt;macAddr[1] = 0x1A; pDev-\u0026gt;macAddr[2] = 0x2B; pDev-\u0026gt;macAddr[3] = 0x3C; pDev-\u0026gt;macAddr[4] = 0x4D; pDev-\u0026gt;macAddr[5] = 0x5E; /* Initialize hardware registers */ *(volatile UINT32 *)(ENET_BASE + 0x10) = 0x1; /* Enable controller */ *(volatile UINT32 *)(ENET_BASE + 0x14) = 0x3; /* 100Mbps, full duplex */ /* Initialize descriptor ring (DMA) */ *(volatile UINT32 *)ENET_TX_DESC = 0x80000000; /* Mark descriptor ready */ *(volatile UINT32 *)ENET_RX_DESC = 0x80000000; return OK; } Explanation: Initialization includes setting the MAC address, enabling the controller, and configuring DMA descriptors. Register addresses must be referenced from the hardware manual. Send Packets (myEnetSend) STATUS myEnetSend(MY_ENET_DEV *pDev, M_BLK_ID pMblk) { if (!pDev-\u0026gt;running) return ERROR; /* Write data to transmit buffer */ char *data = netMblkToBufCopy(pMblk, NULL, NULL); *(volatile UINT32 *)(ENET_BASE + 0x20) = (UINT32)data; /* Data address */ *(volatile UINT32 *)(ENET_BASE + 0x24) = pMblk-\u0026gt;mBlkHdr.mLen; /* Data length */ /* Trigger transmission */ *(volatile UINT32 *)(ENET_BASE + 0x28) = 0x1; /* Free M_BLK */ netMblkFree(pMblk); return OK; } Explanation: Extracts data from M_BLK, writes it to the hardware buffer, and triggers transmission. Receive Packets (myEnetRecv) LOCAL void myEnetHandleRecv(MY_ENET_DEV *pDev) { M_BLK_ID pMblk; /* Check receive status */ if (*(volatile UINT32 *)(ENET_BASE + 0x30) \u0026amp; 0x1) { /* Allocate M_BLK */ pMblk = netMblkAlloc(); if (!pMblk) return; /* Read data from hardware */ UINT32 len = *(volatile UINT32 *)(ENET_BASE + 0x34); char *data = (char *)(*(volatile UINT32 *)(ENET_BASE + 0x38)); netMblkFromBufCopy(pMblk, data, len); /* Report to network stack */ muxReceive(\u0026amp;pDev-\u0026gt;endObj, pMblk); /* Clear receive flag */ *(volatile UINT32 *)(ENET_BASE + 0x30) = 0x0; } } Explanation: Detects receive status via interrupt or polling, encapsulates data into M_BLK, and passes it to the network stack. Start Device (myEnetStart) STATUS myEnetStart(MY_ENET_DEV *pDev) { if (pDev-\u0026gt;running) return OK; /* Enable interrupts */ *(volatile UINT32 *)(ENET_BASE + 0x40) = 0x3; /* Enable TX/RX interrupts */ intEnable(IRQ_ENET); /* Enable IRQ, assuming interrupt number is IRQ_ENET */ pDev-\u0026gt;running = TRUE; return OK; } Register Driver with Network Stack END_OBJ *myEnetLoad(char *initString, void *pArg) { MY_ENET_DEV *pDev; if (myEnetInit(pDev) == ERROR) return NULL; /* Bind to MUX */ if (endLoad(initString, \u0026amp;pDev-\u0026gt;endObj, myEnetStart, myEnetStop, myEnetSend, myEnetRecv, myEnetIoctl) == ERROR) { free(pDev); return NULL; } return \u0026amp;pDev-\u0026gt;endObj; } void myEnetRegister(void) { muxDevLoad(0, myEnetLoad, \u0026#34;\u0026#34;, FALSE, NULL); muxDevStart(0); } Explanation: myEnetLoad registers the driver with the MUX (Multiplexer) to interface with the TCP/IP stack. Adjusting the Configuration File (config.h) # Enable network support:\n#define INCLUDE_END /* Enable END framework */ #define INCLUDE_MUX /* Enable MUX layer */ #define INCLUDE_IPV4 /* Enable IPv4 support */ #define INCLUDE_IFCONFIG /* Enable ifconfig command */ #define MY_ENET_UNIT 0 /* Network device unit number */ Compilation and Testing # Compile the BSP to generate the VxWorks image. Flash and boot, then connect an Ethernet cable. Test in the VxWorks shell: -\u0026gt; ifconfig(\u0026#34;myenet0\u0026#34;, \u0026#34;192.168.1.100\u0026#34;, \u0026#34;255.255.255.0\u0026#34;) -\u0026gt; ping(\u0026#34;192.168.1.1\u0026#34;) Check logs to ensure transmission and reception work correctly. Notes on Network Driver Development # DMA Management: Ensure the descriptor ring is properly initialized to avoid data loss. Interrupt Handling: Optimize interrupt frequency for high-throughput scenarios, using NAPI-like polling if necessary. Performance Testing: Use iperf to test bandwidth and verify driver efficiency. Compatibility: Ensure seamless integration with the VxWorks network stack (e.g., LwIP or BSD stack). Summary # Network driver development is a complex task in BSPs, but the END framework and VxWorks’ modular design enable efficient implementation. Ethernet drivers involve hardware initialization, DMA management, and packet transmission/reception, requiring a deep understanding of hardware manuals and network protocols.\n","date":"2025-03-01","externalUrl":null,"permalink":"/bsp/vxworks-7-bsp-development-guide/","section":"Bsps","summary":"\u003cp\u003e\u003ca href=\"https://www.vxworks7.com\" target=\"_blank\"\u003eVxWorks 7\u003c/a\u003e is a modern real-time operating system (RTOS) launched by Wind River, and its BSP (Board Support Package) development process has seen significant improvements in modularity and tool support. The BSP serves as the bridge between hardware and the operating system, handling hardware initialization, device drivers, and system configuration. This article provides a detailed guide on developing a BSP for VxWorks 7, including technical details and code examples.\u003c/p\u003e","title":"VxWorks 7 BSP Development Guide","type":"bsp"},{"content":" Overview # VxWorks, a real-time operating system (RTOS) from Wind River, provides robust support for hardware interfacing, including Peripheral Component Interconnect (PCI) devices. Writing a PCI device driver in VxWorks involves interacting with the PCI bus, configuring the device, managing interrupts, and providing an interface for application-level access. This guide walks you through the process of designing and implementing a PCI driver for a hypothetical device (e.g., a network or storage controller).\nPrerequisites # VxWorks Development Environment: Installed with Workbench or command-line tools. PCI Device Details: Vendor ID, Device ID, and hardware documentation (e.g., register map, interrupt behavior). Hardware Access: A target system with a PCI device for testing. VxWorks BSP: A Board Support Package configured for your hardware, with PCI support enabled. Step-by-Step Guide # Understand the PCI Device and VxWorks PCI Support PCI devices are identified by a Vendor ID and Device ID, stored in the device’s configuration space. VxWorks provides a PCI library (pciConfigLib) to scan the bus, read/write configuration registers, and map device memory. Review your device’s datasheet for: Configuration space layout (e.g., Base Address Registers or BARs). Interrupt assignments. Memory-mapped I/O (MMIO) or port I/O requirements. VxWorks uses the sysBusPci.c file in the BSP to initialize the PCI bus. Ensure your BSP supports PCI by checking for calls like pciConfigLibInit().\nInitialize the PCI Driver Start by defining a structure to hold your driver’s state and writing an initialization routine to locate and configure the PCI device.\n#include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;hwif/vxBusLib.h\u0026gt; #include \u0026lt;hwif/buslib/pciConfigLib.h\u0026gt; #define MY_VENDOR_ID 0x1234 /* Replace with your device\u0026#39;s Vendor ID */ #define MY_DEVICE_ID 0x5678 /* Replace with your device\u0026#39;s Device ID */ typedef struct { UINT32 bar0Addr; /* Base Address Register 0 (example) */ UINT32 irqLine; /* Interrupt line */ BOOL initialized; /* Driver state */ } MyPciDevice; MyPciDevice myDevice = {0}; /* Initialization function */ STATUS myPciDriverInit(void) { int busNo, devNo, funcNo; UINT32 devVendor; /* Scan PCI bus for the device */ if (pciFindDevice(MY_DEVICE_ID, MY_VENDOR_ID, 0, \u0026amp;busNo, \u0026amp;devNo, \u0026amp;funcNo) == ERROR) { printf(\u0026#34;Device not found!\\n\u0026#34;); return ERROR; } /* Read Vendor/Device ID to confirm */ pciConfigInLong(busNo, devNo, funcNo, PCI_CFG_VENDOR_ID, \u0026amp;devVendor); printf(\u0026#34;Found device: Vendor=0x%04X, Device=0x%04X\\n\u0026#34;, devVendor \u0026amp; 0xFFFF, devVendor \u0026gt;\u0026gt; 16); /* Get BAR0 (example memory region) */ pciConfigInLong(busNo, devNo, funcNo, PCI_CFG_BASE_ADDRESS_0, \u0026amp;myDevice.bar0Addr); myDevice.bar0Addr \u0026amp;= PCI_BAR_MEM_ADDR_MASK; /* Mask off flags to get base address */ /* Get IRQ line */ pciConfigInByte(busNo, devNo, funcNo, PCI_CFG_INTERRUPT_LINE, (UINT8*)\u0026amp;myDevice.irqLine); myDevice.initialized = TRUE; return OK; } Map Device Memory PCI devices expose memory regions via BARs. Use pciDevMemMap() or VxWorks’ memory mapping functions to access these regions.\n#include \u0026lt;vmLib.h\u0026gt; void* myPciMapMemory(void) { void* mappedAddr = NULL; if (!myDevice.initialized) { printf(\u0026#34;Device not initialized!\\n\u0026#34;); return NULL; } /* Map the BAR0 memory region (assuming 4KB size as an example) */ mappedAddr = (void*)vxbPciDevMemMap(myDevice.bar0Addr, 0x1000, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE); if (mappedAddr == NULL) { printf(\u0026#34;Failed to map PCI memory!\\n\u0026#34;); } else { printf(\u0026#34;Mapped BAR0 at 0x%08X\\n\u0026#34;, (UINT32)mappedAddr); } return mappedAddr; } Handle Interrupts PCI devices typically use interrupts to signal events. In VxWorks, connect an Interrupt Service Routine (ISR) using intConnect().\n#include \u0026lt;intLib.h\u0026gt; void myPciIsr(void* arg) { MyPciDevice* dev = (MyPciDevice*)arg; /* Example: Clear interrupt flag in device register (device-specific) */ printf(\u0026#34;Interrupt triggered on IRQ %d!\\n\u0026#34;, dev-\u0026gt;irqLine); } STATUS myPciInterruptSetup(void) { if (!myDevice.initialized) return ERROR; /* Connect ISR to IRQ */ if (intConnect(INUM_TO_IVEC(myDevice.irqLine), myPciIsr, (int)\u0026amp;myDevice) == ERROR) { printf(\u0026#34;Failed to connect ISR!\\n\u0026#34;); return ERROR; } /* Enable interrupts (device-specific register write might be needed) */ intEnable(myDevice.irqLine); return OK; } Provide Driver Interface Expose functions for applications to interact with the device (e.g., read/write data).\nSTATUS myPciWrite(UINT32 offset, UINT32 value, void* baseAddr) { if (!myDevice.initialized || baseAddr == NULL) return ERROR; *(volatile UINT32*)((UINT32)baseAddr + offset) = value; return OK; } UINT32 myPciRead(UINT32 offset, void* baseAddr) { if (!myDevice.initialized || baseAddr == NULL) return 0; return *(volatile UINT32*)((UINT32)baseAddr + offset); } Test and Debug Load the Driver: Compile your code into a VxWorks kernel module (.out file) and load it using ld \u0026lt; myDriver.out in the VxWorks shell. Test Commands: Add shell commands (e.g., myPciTest()) to verify functionality: void myPciTest(void) { void* base = myPciMapMemory(); if (base) { myPciWrite(0x10, 0xDEADBEEF, base); /* Example write */ printf(\u0026#34;Read back: 0x%08X\\n\u0026#34;, myPciRead(0x10, base)); } } Debugging: Use printf(), VxWorks’ logMsg(), or Workbench’s debugger to trace execution. Optimize and Finalize Error Handling: Add robust checks for failures (e.g., unmapped memory, device not found). Multitasking: Ensure thread safety with semaphores (semMCreate()) if the driver is accessed by multiple tasks. Power Management: Implement suspend/resume hooks if required by your BSP. Key Considerations # Endianness: PCI devices may use little-endian format; ensure compatibility with VxWorks’ endian settings. Performance: Minimize register accesses and optimize interrupt handling for real-time constraints. Device-Specific Logic: Tailor register accesses and interrupt handling to your device’s specification. Example Integration # In your BSP’s sysLib.c or a custom initialization file, call:\nvoid sysAppInit(void) { if (myPciDriverInit() == OK) { myPciInterruptSetup(); myPciTest(); } } Resources # VxWorks Documentation: Refer to the VxWorks Kernel Programmer’s Guide and API Reference for pciConfigLib and vxbLib. Device Datasheet: Critical for register-level programming. Wind River Support: For BSP-specific quirks or advanced debugging. This guide provides a foundation for PCI driver development in VxWorks. Adapt the code to your specific device by replacing placeholder values (e.g., Vendor/Device IDs, register offsets) with those from your hardware documentation.\n","date":"2025-02-23","externalUrl":null,"permalink":"/bsp/guide-to-pci-device-driver-design-and-programming-in-vxworks/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003eOverview \n    \u003cdiv id=\"overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eVxWorks, a real-time operating system (RTOS) from Wind River, provides robust support for hardware interfacing, including Peripheral Component Interconnect (PCI) devices. Writing a PCI device driver in \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e involves interacting with the PCI bus, configuring the device, managing interrupts, and providing an interface for application-level access. This guide walks you through the process of designing and implementing a PCI driver for a hypothetical device (e.g., a network or storage controller).\u003c/p\u003e","title":"Guide to PCI Device Driver Design and Programming in VxWorks","type":"bsp"},{"content":"","date":"2025-02-23","externalUrl":null,"permalink":"/tags/container/","section":"Tags","summary":"","title":"Container","type":"tags"},{"content":" Introduction # Containers provide a powerful way to package VxWorks applications, isolating them from the rest of the system. With VxWorks, you can transform applications into containers, upload them to DockerHub (a cloud-based repository for container images) and deploy them to VxWorks target boards like the Raspberry Pi 4 Model B.\nIn this guide, I’ll walk you through converting a sample VxWorks Real-Time Process (RTP) into a container, pushing it to DockerHub, and running it on a VxWorks system. VxWorks, developed by Wind River, is a robust Real-Time Operating System (RTOS) with a board support package (BSP) tailored for the Raspberry Pi 4, an affordable, compact single-board computer.\nBefore proceeding, ensure you’ve completed the setup in \u0026lsquo;Using VxWorks 7 Containers With DockerHub on a Raspberry Pi 4 Model B Board\u0026rsquo;.\nPrerequisites # To follow this guide, you’ll need:\nHardware: # Raspberry Pi 4 Model B (4GB RAM) running VxWorks USB-to-Serial TTL cable Micro-SD card Software: # Windows workstation with Wind River VxWorks 7 (SR21.07) installed Accounts and Tools: # DockerHub account (sign up at hub.docker.com) Workstation configured with the buildah utility (see VxWorks Container Programmer’s Guide: Configure the Build Workstation for Containers) Related Resources # For deeper insights, consult:\nVxWorks Container Programmer’s Guide (Wind River documentation) Setting Up Container-Enabled VxWorks Projects # Let’s prepare the VxWorks environment for containers.\nBuild the VxWorks Source Build (VSB) Project # Open a Windows command shell and set up the VxWorks environment:\ncd \u0026lt;WIND_HOME\u0026gt; // Your VxWorks installation directory wrenv -p vxworks\\21.07 cd \u0026lt;YOUR_WORKSPACE\u0026gt; // Your workspace directory Create and configure the VSB project for Raspberry Pi 4:\nvxprj vsb create -S -bsp rpi_4 -smp rpiVSB cd rpiVSB vxprj vsb layer add CONTAINER_RUNTIME vxprj vsb layer add CONTAINER_MANAGER vxprj vsb layer add PYTHON vxprj vsb layer add CONTAINER_EXAMPLES vxprj vsb config -s -add _WRS_CONFIG_CONTAINER_PYTHON_WEB_SERVER=y Build the VSB:\nvxprj vsb build -j 16 cd .. Create the VxWorks Image Project (VIP) # Generate the VIP:\nvxprj vip create -vsb rpiVSB llvm -profile PROFILE_DEVELOPMENT rpiVIP cd rpiVIP Add container and filesystem components:\nvxprj vip component add INCLUDE_CONTAINER_RUNTIME INCLUDE_CONTAINER_SHELL_CMD vxprj vip component add INCLUDE_DISK_UTIL INCLUDE_RAM_DISK INCLUDE_OVERLAY_FS vxprj vip parameter set RAM_DISK_SIZE 0x4000000 vxprj vip component add INCLUDE_STANDALONE_SYM_TBL INCLUDE_STANDALONE_DTB vxprj vip component add INCLUDE_PYTHON_SUPPORT INCLUDE_ROMFS mkdir romfs Enable Public Internet Access # Configure networking:\nvxprj vip component add INCLUDE_CONTAINER_MANAGER INCLUDE_IPDNSC vxprj vip component add INCLUDE_PING INCLUDE_IFCONFIG vxprj vip parameter setstring DNSC_PRIMARY_NAME_SERVER \u0026#34;8.8.8.8\u0026#34; vxprj vip parameter set SEC_VAULT_KEY_ENCRYPTING_PW \u0026#34;vault_passwd\u0026#34; vxprj vip component add INCLUDE_IPCOM_USE_TIME_CMD Note: Use a strong password for SEC_VAULT_KEY_ENCRYPTING_PW (mix of uppercase, lowercase, and numbers). On Linux hosts, escape the string: \\\u0026quot;vault_passwd\\\u0026quot;.\nAdd Raspberry Pi 4 Components # vxprj vip component add DRV_END_FDT_BCM_GENETv5 INCLUDE_XBD_PART_LIB vxprj vip component add DRV_FDT_BRCM_2711_PCIE DRV_FDT_BRCM_2711_EMMC2 vxprj vip component add DRV_SDSTORAGE_CARD Add Container Certificate # mkdir romfs\\vxc\\ca-certs copy ..\\..\\vxworks\\21.07\\os\\container\\manager\\ca-certs\\ca-certificates.crt romfs\\vxc\\ca-certs\\ Configure the Bootline # Edit rpi_4_0_1_2_0\\rpi-4b.dts, locate the chosen node, and update the bootargs. Example:\nbootargs = \u0026#34;genet(0,0)host:vxworks h=192.168.1.105 e=192.168.1.107:ffffff00 g=192.168.1.1 u=target pw=vx tn=RPi4\u0026#34;; Build the VIP # vxprj build Create the Philosophers RTP Project # This example uses the “Dining Philosophers” problem from Wind River Workbench to demonstrate synchronization in VxWorks.\nOpen Wind River Workbench. Go to File \u0026gt; New \u0026gt; Example, select Philosophers Demonstration Program. Set rpiVSB as the VSB and build the RTP. Containerize the Philosophers RTP # Set Up the Container Directory # cd \u0026lt;YOUR_WORKSPACE\u0026gt; mkdir philContainer Copy the RTP Executable # copy philosophers\\rpiVSB_ARMARCH8Allvm_LP64_ld\\philosophers\\Debug\\philosophers.vxe philContainer\\. Create the Dockerfile # In philContainer, create a file named Dockerfile (no .txt extension):\nFROM scratch WORKDIR /vxbin COPY philosophers.vxe /vxbin ENTRYPOINT [\u0026#34;philosophers.vxe\u0026#34;] LABEL com.windriver.vxworks.rtp.rtpStackSize 0x400000 LABEL com.windriver.vxworks.rtp.rtpPriority 50 LABEL com.windriver.vxworks.rtp.rtpOptions 0x80 LABEL com.windriver.vxworks.rtp.rtpTaskOptions 0x00 Note: If your editor adds .txt, rename it: rename Dockerfile.txt Dockerfile.\nBuild the Container Image # In philContainer:\nwsl buildah bud --arch arm64 --os vxworks -f Dockerfile -t philosophers cd .. Push to DockerHub # wsl buildah push philosophers oci:philosophers.oci wsl buildah push --creds \u0026lt;dockerAccountName\u0026gt;:\u0026lt;dockerAccountPassword\u0026gt; philosophers docker://\u0026lt;dockerAccountName\u0026gt;/philosophers.oci Replace \u0026lt;dockerAccountName\u0026gt; and \u0026lt;dockerAccountPassword\u0026gt; with your DockerHub credentials.\nDeploy to the VxWorks Target # Set the Date # On the VxWorks shell:\n-\u0026gt; cmd [vxWorks *]# date 2025-02-22 // Use today\u0026#39;s date ok Verify Connectivity # [vxWorks *]# ping \u0026#34;www.google.com\u0026#34; Wait for the Ethernet LEDs to stabilize if needed.\nPull and Unpack the Container # [vxWorks *]# vxc pull \u0026lt;dockerAccountName\u0026gt;/philosophers.oci -k [vxWorks *]# vxc unpack --image philosophers.oci --rootfs layered /ram0/bundle Create and Inspect the Container # [vxWorks *]# vxc create --bundle /ram0/philosophers phil [vxWorks *]# cd /overlay/phil [vxWorks *]# ls Start the Container # [vxWorks *]# vxc start phil You’ll see output like:\nRunning claim-based solution. Philosopher 1 is thinking... Stop the Container # [vxWorks *]# vxc kill phil ","date":"2025-02-23","externalUrl":null,"permalink":"/app/deploying-a-vxworks-rtp-as-a-container-to-dockerhub-and-raspberry-pi-4/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eContainers provide a powerful way to package VxWorks applications, isolating them from the rest of the system. With \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e, you can transform applications into containers, upload them to DockerHub (a cloud-based repository for container images) and deploy them to VxWorks target boards like the Raspberry Pi 4 Model B.\u003c/p\u003e","title":"Deploying a VxWorks RTP as a Container to DockerHub and Raspberry Pi 4","type":"app"},{"content":"","date":"2025-02-23","externalUrl":null,"permalink":"/tags/raspberry-pi-4/","section":"Tags","summary":"","title":"Raspberry Pi 4","type":"tags"},{"content":"","date":"2025-02-15","externalUrl":null,"permalink":"/tags/can/","section":"Tags","summary":"","title":"CAN","type":"tags"},{"content":" CAN Programming Under VxWorks: A Practical Guide\nIntroduction # CAN bus is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other in applications without a host computer. VxWorks, known for its reliability in embedded systems, supports CAN through various drivers. This article will guide you through setting up, configuring, and programming CAN communications under VxWorks with detailed explanations in code comments.\nUnderstanding CAN in VxWorks # VxWorks provides CAN support through device drivers integrated into the Board Support Package (BSP). These drivers manage low-level CAN controller interactions. Developers use VxWorks\u0026rsquo; CAN API for higher-level tasks.\nStep-by-Step CAN Programming # Initialize CAN Device: #include \u0026lt;vxWorks.h\u0026gt; #include \u0026lt;can.h\u0026gt; int main() { // CAN device identifier - might be different based on your hardware setup CAN_ID canId; // Open the CAN device. \u0026#34;/can/0\u0026#34; represents the first CAN controller on the board. int fd = canDevCreate(\u0026#34;/can/0\u0026#34;, \u0026amp;canId); if (fd \u0026lt; 0) { printf(\u0026#34;Failed to initialize CAN device\\n\u0026#34;); return -1; } // \u0026#39;fd\u0026#39; now holds the file descriptor for this CAN device, used for all subsequent operations. } Configure CAN Bus: // Structure to hold CAN configuration parameters CAN_CONFIG config; // Set the bit rate to 500 kbps (common for many automotive applications) config.bitRate = 500000; // Sample point at 87.5% of the bit time for noise immunity config.samplePoint = 875; // Synchronization jump width - how much the bit timing can be adjusted to synchronize with other nodes config.sjw = 1; // Apply configuration to the CAN device if (canIoctl(fd, CAN_CMD_SET_CONFIG, (int)\u0026amp;config) != OK) { printf(\u0026#34;Failed to configure CAN bus\\n\u0026#34;); return -1; } Send CAN Messages: // Prepare a CAN frame for transmission CAN_FRAME txFrame; txFrame.id = 0x123; // CAN message identifier (arbitrarily chosen here) txFrame.dlc = 8; // Data Length Code, specifying 8 bytes of data // Fill the data bytes. Here, we\u0026#39;re just using a simple increment for demonstration. for (int i = 0; i \u0026lt; 8; i++) { txFrame.data[i] = i; } // Send the CAN frame. The \u0026#39;1\u0026#39; indicates we\u0026#39;re sending one frame. if (canWrite(fd, \u0026amp;txFrame, 1) != 1) { printf(\u0026#34;Failed to send CAN message\\n\u0026#34;); } Receive CAN Messages: CAN_FRAME rxFrame; // Loop to continuously check for received messages while (1) { // Read one CAN frame. \u0026#39;canRead\u0026#39; returns the number of frames read or an error code. int bytesRead = canRead(fd, \u0026amp;rxFrame, 1); if (bytesRead == 1) { printf(\u0026#34;Received CAN message with ID: 0x%X\\n\u0026#34;, rxFrame.id); // Print each byte of the received data for (int i = 0; i \u0026lt; rxFrame.dlc; i++) { printf(\u0026#34;Byte %d: %X\\n\u0026#34;, i, rxFrame.data[i]); } } else if (bytesRead \u0026lt; 0) { printf(\u0026#34;Error reading CAN message\\n\u0026#34;); break; // Exit loop on error } } Cleanup: { // Close the CAN device when done canDevDelete(fd); return 0; } Advanced Considerations # Interrupts # // Define an interrupt handler for CAN events void canInterruptHandler(int vector) { // Check for new messages or handle errors. This might involve reading status registers. } // Connect the ISR to the CAN interrupt vector. CAN_INTERRUPT_VECTOR should be defined according to your hardware setup. intConnect(INUM_TO_IVEC(CAN_INTERRUPT_VECTOR), canInterruptHandler, 0); Error Handling # CAN_ERROR_STATUS errorStatus; // Check for CAN bus errors like bit errors, stuff errors, etc. canIoctl(fd, CAN_CMD_GET_ERROR_STATUS, (int)\u0026amp;errorStatus); if (errorStatus.txErrorCounter \u0026gt; 127 || errorStatus.rxErrorCounter \u0026gt; 127) { printf(\u0026#34;Warning: CAN bus approaching error state\\n\u0026#34;); } Bus Off Recovery # if (errorStatus.busOff) { // If the CAN controller goes into bus off state, reset it canIoctl(fd, CAN_CMD_RESET, 0); printf(\u0026#34;CAN bus reset due to bus off condition\\n\u0026#34;); } Conclusion # This guide provides a thorough introduction to CAN programming under VxWorks, with detailed comments to help understand each step. Keep in mind that real-world applications might require additional considerations like message filtering, priority handling, or dealing with network load to ensure the CAN bus operates correctly and efficiently. Always consult your specific hardware\u0026rsquo;s documentation for any unique requirements or features.\n","date":"2025-02-15","externalUrl":null,"permalink":"/app/can-programming-under-vxworks/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eCAN Programming Under VxWorks: A Practical Guide\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eCAN bus is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other in applications without a host computer. \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e, known for its reliability in embedded systems, supports CAN through various drivers. This article will guide you through setting up, configuring, and programming CAN communications under VxWorks with detailed explanations in code comments.\u003c/p\u003e","title":"CAN Programming Under VxWorks","type":"app"},{"content":"","date":"2025-02-14","externalUrl":null,"permalink":"/tags/development-history/","section":"Tags","summary":"","title":"Development History","type":"tags"},{"content":" Introduction # In the realm of embedded systems, where real-time performance can be a matter of life and death, one name has consistently stood out: VxWorks. Developed by Wind River Systems, VxWorks has become synonymous with reliability and performance in real-time operating systems (RTOS). This article traces the evolution of VxWorks, from its inception to its current status as a leading RTOS in critical applications worldwide.\nThe Birth of VxWorks # VxWorks was conceptualized in 1983, when Wind River Systems was founded by Jerry Fiddler and Dave Wilner in Alameda, California. Initially, the company focused on real-time software consulting, but it wasn\u0026rsquo;t long before they introduced VxWorks in 1987. This RTOS was designed to meet the stringent demands of embedded systems, offering real-time capabilities with minimal latency.\nEarly Milestones # 1987: VxWorks 1.0 was released, establishing Wind River as a player in the RTOS market. 1995: VxWorks made its mark in space exploration when it was used in NASA\u0026rsquo;s Clementine lunar mapping mission, showcasing its robustness in extreme conditions. 1997: Further solidifying its reputation, VxWorks was employed in the Mars Pathfinder mission, a testament to its reliability under harsh extraterrestrial environments. The 2000s: Expansion and Innovation # The new millennium brought significant updates and expansions:\n2001: Wind River launched Tornado, an integrated development environment designed to make VxWorks development more accessible and efficient. 2003: The transition from VxWorks 5.x to 6.x marked enhancements in multi-processor support, introducing features like Symmetric Multiprocessing (SMP) for better utilization of multi-core processors. 2004: VxWorks 6.4 came with enhanced SMP support, and in 2006, version 6.6 added virtualization capabilities, allowing for more complex system designs. VxWorks 7: A New Era # 2014: VxWorks 7 was a landmark release, introducing a new kernel architecture optimized for multi-core and multiprocessing architectures. This version aimed at improving security, scalability, and connectivity, making it suitable for IoT applications and modern, complex systems.\nSecurity Enhancements: With VxWorks 7, there was a significant focus on security, including support for secure boot, digital signatures, and compliance with various safety standards.\nGraphical User Interface: It introduced robust graphics support, enhancing user interface capabilities for devices where this was previously a challenge.\nRecent Developments and Future Outlook # 2019: VxWorks was in the spotlight due to the disclosure of a security vulnerability named \u0026ldquo;Urgent/11,\u0026rdquo; which affected a wide range of IoT devices and critical infrastructure. This event underscored the continuous need for security updates in RTOS environments. 2020s: VxWorks continues to evolve, with updates focusing on supporting new processor architectures, including ARMv8-M and RISC-V, alongside improving performance, safety, and security features. Conclusion # VxWorks has grown from a niche RTOS to a staple in industries requiring high reliability, from aerospace to automotive systems. Its development history is a narrative of technological advancement, adapting to new challenges like multi-core processing, cybersecurity, and the demands of the IoT era. As embedded systems continue to evolve, VxWorks stands ready to meet these challenges, ensuring real-time performance where it matters most.\n","date":"2025-02-14","externalUrl":null,"permalink":"/news/the-development-history-of-vxworks/","section":"News","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn the realm of embedded systems, where real-time performance can be a matter of life and death, one name has consistently stood out: \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e. Developed by Wind River Systems, VxWorks has become synonymous with reliability and performance in real-time operating systems (RTOS). This article traces the evolution of VxWorks, from its inception to its current status as a leading RTOS in critical applications worldwide.\u003c/p\u003e","title":"The Development History of VxWorks","type":"news"},{"content":" Introduction # UART (Universal Asynchronous Receiver/Transmitter) programming is essential for embedded systems, providing a simple, cost-effective way to achieve serial communication. VxWorks 7, renowned for its real-time capabilities, supports UART programming, making it an excellent choice for applications requiring deterministic behavior. This article will guide you through the process of UART programming under VxWorks 7, from setup to debugging.\nUnderstanding UART # VxWorks 7, like many real-time operating systems, treats hardware peripherals such as UART as file descriptors. This abstraction allows developers to interact with hardware using familiar file I/O system calls, simplifying the programming model.\nPrerequisites # VxWorks 7 Development Environment: Ensure you have the VxWorks 7 SDK installed, which includes Wind River Workbench for development. Target Hardware: A board or simulator that supports VxWorks 7 with a UART interface. Basic Knowledge: Understanding of C programming and familiarity with VxWorks concepts like tasks, semaphores, and interrupts. Setting Up the Environment # Board Support Package (BSP): Choose or configure a BSP that supports your target hardware. VxWorks provides BSPs for various platforms, each tailored to specific hardware. Install Drivers: Ensure that UART drivers are included in your VxWorks image. This might involve configuring your VxWorks Image Project (VIP) to include the necessary drivers. Opening and Configuring UART # Open UART Device: Use the open() system call to acquire a file descriptor for the UART. In VxWorks, UART devices are typically represented as /tyCo/x, where \u0026lsquo;x\u0026rsquo; is the number of the COM port. int fd = open(\u0026#34;/tyCo/0\u0026#34;, O_RDWR | O_NOCTTY | O_NDELAY); if (fd \u0026lt; 0) { perror(\u0026#34;Error opening UART\u0026#34;); return -1; } Configure UART Settings: Use ioctl() to set up baud rate, parity, stop bits, etc. Below is a function to set these parameters:\nvoid configureUART(int fd, int baud, int parity, int databits, int stopbits) { struct termios options; tcgetattr(fd, \u0026amp;options); // Set baud rate cfsetispeed(\u0026amp;options, baud); cfsetospeed(\u0026amp;options, baud); // Set parity options.c_cflag \u0026amp;= ~PARENB; options.c_cflag \u0026amp;= ~CSTOPB; options.c_cflag \u0026amp;= ~CSIZE; switch (databits) { case 5: options.c_cflag |= CS5; break; case 6: options.c_cflag |= CS6; break; case 7: options.c_cflag |= CS7; break; case 8: options.c_cflag |= CS8; break; } if (parity == \u0026#39;O\u0026#39;) options.c_cflag |= PARENB | PARODD; else if (parity == \u0026#39;E\u0026#39;) options.c_cflag |= PARENB; else options.c_cflag \u0026amp;= ~PARENB; if (stopbits == 2) options.c_cflag |= CSTOPB; // Apply configuration tcsetattr(fd, TCSANOW, \u0026amp;options); } Reading/Writing to UART # Writing Data: char *message = \u0026#34;Hello, UART!\u0026#34;; write(fd, message, strlen(message)); Reading Data: char buffer[256]; ssize_t ret = read(fd, buffer, sizeof(buffer) - 1); if (ret \u0026gt; 0) { buffer[ret] = \u0026#39;\\0\u0026#39;; // Null-terminate the string printf(\u0026#34;Received: %s\\n\u0026#34;, buffer); } Handling Interrupts # Interrupts are crucial in UART (Universal Asynchronous Receiver/Transmitter) programming, especially within embedded systems where performance and responsiveness are key. Here\u0026rsquo;s how you can approach UART interrupt handling, specifically focusing on general principles and implementation details:\nBasics of UART Interrupts # UART interrupts typically occur for:\nData Reception (RX): When new data is received. Data Transmission (TX): When the transmitter buffer is empty and ready for more data. Errors: Such as framing errors, parity errors, or overflow. Implementing UART Interrupt Handling # Enable UART Interrupts: Configure your UART hardware to enable interrupts for the events you wish to handle. This usually involves setting bits in control registers. Connect Interrupt Handler: In your software, you need to connect an interrupt service routine (ISR) to the UART interrupt vector. Here\u0026rsquo;s a conceptual example: // Example in a generic context, specifics depend on your OS or bare-metal environment void connectUARTInterrupt() { // Assuming INT_UART is the vector for UART interrupts intConnect(INT_UART, uartInterruptHandler, 0); // \u0026#39;0\u0026#39; could be a parameter for the handler } Write the ISR: The ISR should handle the interrupt quickly, acknowledging the interrupt and performing minimal processing to not block the system for too long. void uartInterruptHandler(void *parameter) { // Acknowledge the interrupt uartClearInterruptFlags(); // Check which interrupt occurred (RX, TX, or error) if (uartIsRxInterrupt()) { // Handle received data char receivedChar = uartReadData(); processReceivedChar(receivedChar); } else if (uartIsTxInterrupt()) { // Handle transmitter empty if (thereIsDataToSend()) { uartSendNextByte(); } } else { // Handle errors handleUARTError(); } } Note: Functions like uartClearInterruptFlags, uartIsRxInterrupt, etc., are placeholders for actual hardware-specific operations. Data Buffering: For RX, implement a buffer to store incoming data since interrupts should be short. For TX, if using interrupts, you might buffer data to be sent, triggering the next byte send when the TX interrupt fires. Error Handling: Implement checks for errors in your ISR and handle or log them appropriately. Real-Time Considerations: If working with an RTOS, ensure your ISR is as brief as possible, offloading any heavy processing to a task that can be woken by the ISR. Testing: Test your interrupt handler with different scenarios like high data rates, error conditions, and edge cases like buffer overflows. Considerations: # Priority: UART interrupts might need to have a specific priority, especially if other interrupts are in use. Context Switching: Understand how your system handles context switching in ISRs, particularly if you\u0026rsquo;re using an RTOS like VxWorks. Atomic Operations: Ensure operations within the ISR are atomic if necessary to prevent data corruption. Conclusion # UART interrupt handling allows your system to respond promptly to serial communication events, which is vital for real-time systems or any application where timing is crucial. Always ensure your implementation is tested thoroughly to guarantee reliability under all expected conditions. If you\u0026rsquo;re working with a specific OS or hardware, refer to the detailed documentation for exact register settings and API functions.\nExample code # For real-time applications, managing UART interrupts can enhance performance. VxWorks allows you to attach interrupt handlers:\nvoid uart_interrupt_handler(int arg) { // Handle interrupt logic here } // Attach handler to UART interrupt int vector = ...; // Vector number for UART interrupt void *parameter = ...; int status = intConnect((VOIDFUNCPTR *)INUM_TO_IVEC(vector), uart_interrupt_handler, parameter); if (status == OK) { intEnable(vector); } Debugging and Testing # Use VxWorks Shell: For debugging, run your application in the VxWorks shell on the target hardware where you can interact with your UART directly. Logging: Implement logging within your application to track UART operations and debug communication issues.\nConclusion # UART programming under VxWorks 7 leverages the system\u0026rsquo;s robust real-time features, providing developers with a stable environment for serial communication. By following these steps, you can effectively integrate UART functionality into your embedded system, ensuring reliable data transmission with minimal latency, which is crucial for time-sensitive applications. Remember, the exact implementation might vary slightly depending on your specific hardware and BSP, so always refer to the vendor\u0026rsquo;s documentation for precise configurations.\n","date":"2025-02-09","externalUrl":null,"permalink":"/app/a-step-by-step-guide-on-uart-programming-for-vxworks-7/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eUART (Universal Asynchronous Receiver/Transmitter) programming is essential for embedded systems, providing a simple, cost-effective way to achieve serial communication. VxWorks 7, renowned for its real-time capabilities, supports UART programming, making it an excellent choice for applications requiring deterministic behavior. This article will guide you through the process of UART programming under \u003ca href=\"https://www.vxworks7.com\" target=\"_blank\"\u003eVxWorks 7\u003c/a\u003e, from setup to debugging.\u003c/p\u003e","title":"A Step by Step Guide on UART Programming for VxWorks 7","type":"app"},{"content":"","date":"2025-02-09","externalUrl":null,"permalink":"/tags/isr/","section":"Tags","summary":"","title":"ISR","type":"tags"},{"content":" Porting VxWorks Applications to Linux: A Practical Guide\n🚀 Introduction # Migrating from VxWorks to Linux is a common modernization step in embedded systems. However, this transition is not just a recompile—it often requires architectural redesign, API adaptation, and system-level decisions.\nThis guide provides a structured, engineering-focused approach to porting VxWorks applications to Linux, helping you minimize risk while preserving performance and determinism where needed.\n🧠 VxWorks vs Linux Architecture # Traditional RTOS Architecture # In VxWorks:\nTasks, kernel, and drivers share a single address space Direct hardware access is allowed Interrupt handlers can call application logic Extremely fast and flexible, but fragile ⚠️ Key drawback: Any task can corrupt the entire system.\nLinux Architecture # Linux enforces strict separation:\nEach process has its own virtual address space Hardware access only via kernel drivers Uses MMU-based isolation ✅ Key benefit: Strong fault isolation\n❗ Trade-off: Higher overhead and stricter interfaces\n🔍 Identifying What Needs Porting # Before coding, classify your system into:\nApplication tasks Device drivers Shared utility functions System calls / OS APIs 💡 In VxWorks, these are often tightly coupled. In Linux, they must be cleanly separated.\n🔄 Porting Application Tasks # Task Mapping Strategy # VxWorks Linux Equivalent Task Thread (pthread) or Process Shared memory Threads / IPC Message queues POSIX message queues Choosing Between Threads and Processes # Threads\nFaster context switching Shared memory (easy data sharing) Lower isolation Processes\nBetter fault isolation Higher overhead Require IPC 👉 Rule of thumb:\nUse threads for performance-critical paths Use processes for safety-critical isolation 🔗 Inter-Process Communication (IPC) # Linux requires explicit IPC mechanisms:\nPipes / FIFOs – simple data streams Message Queues – structured communication Shared Memory – fastest, but needs synchronization Signals – asynchronous notifications Mutexes / Condition Variables – thread synchronization 💡 Unlike VxWorks, shared data is no longer implicit.\n🔌 Porting Device Drivers # Key Difference # VxWorks: Application can access hardware directly Linux: Must go through device drivers Decision Flow # Does a Linux driver already exist?\n✅ Yes → Adapt application ❌ No → Port or rewrite driver Can it be user-space?\nIf: No interrupts Single process access\n→ Use mmap()-based driver Otherwise:\nImplement kernel-space driver Interrupt Handling Differences # VxWorks Model # ISR can signal tasks directly Application logic can be tightly coupled Linux Model # ISR stays in kernel Uses: Blocking I/O Wake-up mechanisms Worker threads/processes ⚠️ Often requires architectural redesign\n🧩 Handling Shared Utility Code # RTOS Model # Single global copy of functions Shared across all tasks Linux Options # Static Library # Simple to use Duplicates memory across processes Shared Library # One copy in memory Requires Position Independent Code (PIC) ⚠️ Global Variable Pitfall # In RTOS:\nOne global variable shared by all tasks In Linux:\nEach process gets its own copy 👉 Solutions:\nUse threads, or Move shared state into: Shared memory Device drivers 🔧 System Calls and API Migration # Each VxWorks API falls into:\nIdentical (POSIX-compliant)\nMinimal changes Similar\nUse: Wrappers (abstraction layer), or Rewrite code No Equivalent\nRequires redesign 🧭 Recommended Porting Strategy # Map tasks → threads/processes Identify hardware access → drivers Convert shared code → libraries Replace OS APIs → Linux equivalents Refactor architecture where needed ✅ Key Takeaways # VxWorks → performance + flexibility Linux → robustness + scalability Porting is not just code migration—it’s system redesign 🏁 Summary # Porting from VxWorks to Linux is an iterative engineering process:\nStart with architecture Then tasks and drivers Finally APIs and optimizations ✅ Success factor:\nUnderstand why the original RTOS design worked—and adapt it thoughtfully to Linux’s model instead of forcing a one-to-one mapping.\n","date":"2025-01-31","externalUrl":null,"permalink":"/app/porting-vxworks-applications-to-linux-a-practical-guide/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003ePorting VxWorks Applications to Linux: A Practical Guide\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🚀 Introduction \n    \u003cdiv id=\"-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eMigrating from \u003cstrong\u003eVxWorks\u003c/strong\u003e to Linux is a common modernization step in embedded systems. However, this transition is not just a recompile—it often requires \u003cstrong\u003earchitectural redesign, API adaptation, and system-level decisions\u003c/strong\u003e.\u003c/p\u003e","title":"Porting VxWorks Applications to Linux: A Practical Guide","type":"app"},{"content":"Kontronn provides comprehensive custom VxWorks BSP development tailored to customer project requirements across various industries, including automotive, medical, aerospace, defense, industrial automation, and consumer electronics.\nHow It works # We cover all aspects of custom Board Support Package (BSP) development, including custom bootloader integration, device driver development, and middleware library/tool integration for application development. This allows our customers to focus solely on their custom applications, adding significant value to their product. We offer both complete BSP solutions and partial support, including sub-component development and assistance for application developers.\nBootloader development # We develop bootloaders from scratch or integrate existing bootloaders onto custom embedded platforms such that the operating system can boot and update itself according to strict application requirements. Our team uses state of art proprietary and complementary tools for implementing, testing and profiling all aspects related to the bootloaders on an embedded platform.\nStartup code development # Our team of engineers have a rich experience in developing startup codes for various embedded systems that execute immediately after booting and include the booting vectors, codes to setup the system and bus configuration registers, codes to clear de memory and codes to initialize global variables.\nHardware configurations # We develop solutions that meet the requirements in all aspects, including hardware, software and design, taking into account components and peripherals energy profiles. We also integrate various features such as real time clocks and hardware watchdog timers, that monitor the execution time and reset the processor in the event of a software crash.\nSystem profiling and optimization # With the use of specific code profilers and specific analysis algorithms, our engineers perform various test cases in order to generate runtime and memory usage data required for system optimization. By improving the quality and efficiency of the code, we offer optimized solutions for loading time, running time and CPU usage.\nDevice tree development # As part of developing complete Board Support Packages for VxWorks, we ensure that the device tree files are implemented according to the features of the SoC used and its pinout on the PCB. We implement device tree files from scratch or adapt existing ones when the hardware being used is already supported by VxWorks and it needs only customization according to specific application needs.\nDevice drivers # In order to facilitate the porting of VxWorks to customs SoCs and boards our team develops device drivers for various hardware accelerators, peripheral interfaces, external devices such as display, camera, networking, or wireless so that VxWorks can successfully run on a custom embedded board and provide to the application the interfaces that it needs to successfully process and stream the data.\nHardware bring-up and testing # Our team takes care of all aspects related to the initial bring-up and testing of an embedded hardware platform, by performing all required debugging and testing activities for bringing the board to boot up successfully, so that the system achieves readiness for further development.\nRoot file system # As part of developing complete BSP Solutions, we develop all the software components needed to support an application such as installable files, patches, programming languages, coding frameworks, database tools, runtime environment, client interface tools and other software products.\n","date":"2025-01-29","externalUrl":null,"permalink":"/bsp/vxworks-bsp-development/","section":"Bsps","summary":"\u003cp\u003eKontronn provides comprehensive custom VxWorks BSP development tailored to customer project requirements across various industries, including automotive, medical, aerospace, defense, industrial automation, and consumer electronics.\u003c/p\u003e","title":"VxWorks BSP Development","type":"bsp"},{"content":"","date":"2025-01-29","externalUrl":null,"permalink":"/tags/amp/","section":"Tags","summary":"","title":"AMP","type":"tags"},{"content":" Introduction # Asymmetric Multi-Processing (AMP) allows a multi-core system to run multiple independent operating systems (OSs) concurrently. In this model, each CPU has its own private memory region containing its OS and applications, although shared memory regions can also be used for inter-CPU communication. This is in contrast to Symmetric Multi-Processing (SMP), where a single OS spans multiple CPUs using a common memory space.\nThis guide is based on work with the Freescale P4080, an 8-core processor in the PowerPC family. The P4080 is a powerful and complex chip—with documentation exceeding 3500 pages.\nThe diagram below (not shown here) represents a typical AMP system. CPU0 boots first, and the wrload utility is used to load VxWorks images into the memory regions of the remaining CPUs. Typically, CPU0 is allocated more memory than the others.\nVxWorks AMP System showing private and shared memory allocation We focus here on unsupervised AMP. (Supervised AMP using a hypervisor is outside the scope of this article.)\nWhy Use AMP? # AMP is especially useful for:\nModular application design: e.g., separating control plane and data plane tasks in a router. Enhanced security: isolating secure applications and I/O to specific CPUs via the MMU. Mixed OS environments: each CPU can run a different OS instance, such as a mix of Linux and VxWorks. Legacy system consolidation: old applications from separate boards can be ported individually to CPUs in a single multi-core board. Existing Ethernet-based connections can be preserved using MIPC Network Devices (MND), avoiding codebase mergers. Building AMP Images in VxWorks # There are two options:\nWorkbench GUI (tedious for 8 CPUs) Command-line Makefile (recommended) Here\u0026rsquo;s a sample Makefile for the Vadatech AMC718 board (Freescale P4080):\n############################################################################### # # makefile for AMC718 AMP builds # # Kontronn # # https://www.kontronn.com # # This makefile demonstrates how to build an AMP system for the # Kontronn AMC718 board. This board uses an 8 core Freescale P4080 Chip # # From a vxWorks development shell, type make amp. VxWorks images will be copied # into FTP_DIR # # for Windows hosts, fix slashes WIND_HOME := $(subst \\,/,$(WIND_HOME)) WIND_BASE := $(subst \\,/,$(WIND_BASE)) WIND_USR := $(subst \\,/,$(WIND_USR)) TOOL = gnu # all vxWorks images will get copied here for pickup FTP_DIR = C:/temp/incoming AMP0_DIR = amc718_gnu_amp0 AMP0_PROJ = $(AMP0_DIR)/$(AMP0_DIR).wpj AMP1_DIR = amc718_gnu_amp1 AMP1_PROJ = $(AMP1_DIR)/$(AMP1_DIR).wpj AMP2_DIR = amc718_gnu_amp2 AMP2_PROJ = $(AMP2_DIR)/$(AMP2_DIR).wpj AMP3_DIR = amc718_gnu_amp3 AMP3_PROJ = $(AMP3_DIR)/$(AMP3_DIR).wpj AMP4_DIR = amc718_gnu_amp4 AMP4_PROJ = $(AMP4_DIR)/$(AMP4_DIR).wpj AMP5_DIR = amc718_gnu_amp5 AMP5_PROJ = $(AMP5_DIR)/$(AMP5_DIR).wpj AMP6_DIR = amc718_gnu_amp6 AMP6_PROJ = $(AMP6_DIR)/$(AMP6_DIR).wpj AMP7_DIR = amc718_gnu_amp7 AMP7_PROJ = $(AMP7_DIR)/$(AMP7_DIR).wpj amp: amp0 amp1 amp2 amp3 amp4 amp5 amp6 amp7 amp0: vxprj create -force $(BSP) $(TOOL) $(AMP0_PROJ) vxprj bundle add $(AMP0_PROJ) BUNDLE_STANDALONE_SHELL vxprj bundle add $(AMP0_PROJ) BUNDLE_AMP_PRI vxprj component add $(BSP_PROJ) INCLUDE_PCI_BUS vxprj build $(AMP0_PROJ) cp $(AMP0_DIR)/default/vxWorks $(FTP_DIR)/vxWorks.0 amp1: vxprj create -force $(BSP) $(TOOL) $(AMP1_PROJ) vxprj bundle add $(AMP1_PROJ) BUNDLE_STANDALONE_SHELL vxprj bundle add $(AMP1_PROJ) BUNDLE_AMP_SEC vxprj component add $(AMP1_PROJ) INCLUDE_AMP_CPU_01 # need to remove INCLUDE_WDB_SYS, incompatible with AMP vxprj component remove $(AMP1_PROJ) INCLUDE_WDB_SYS vxprj build $(AMP1_PROJ) cp $(AMP1_DIR)/default/vxWorks $(FTP_DIR)/vxWorks.1 amp2: vxprj create -force $(BSP) $(TOOL) $(AMP2_PROJ) vxprj bundle add $(AMP2_PROJ) BUNDLE_STANDALONE_SHELL vxprj bundle add $(AMP2_PROJ) BUNDLE_AMP_SEC vxprj component add $(AMP2_PROJ) INCLUDE_AMP_CPU_02 # need to remove INCLUDE_WDB_SYS, incompatible with AMP vxprj component remove $(AMP2_PROJ) INCLUDE_WDB_SYS # remove networking. No devices vxprj component remove $(AMP2_PROJ) INCLUDE_NETWORK vxprj build $(AMP2_PROJ) cp $(AMP2_DIR)/default/vxWorks $(FTP_DIR)/vxWorks.2 amp3: vxprj create -force $(BSP) $(TOOL) $(AMP3_PROJ) vxprj bundle add $(AMP3_PROJ) BUNDLE_STANDALONE_SHELL vxprj bundle add $(AMP3_PROJ) BUNDLE_AMP_SEC vxprj component add $(AMP3_PROJ) INCLUDE_AMP_CPU_03 # need to remove INCLUDE_WDB_SYS, incompatible with AMP vxprj component remove $(AMP3_PROJ) INCLUDE_WDB_SYS # remove networking. No devices vxprj component remove $(AMP3_PROJ) INCLUDE_NETWORK vxprj build $(AMP3_PROJ) cp $(AMP3_DIR)/default/vxWorks $(FTP_DIR)/vxWorks.3 amp4: vxprj create -force $(BSP) $(TOOL) $(AMP4_PROJ) vxprj bundle add $(AMP4_PROJ) BUNDLE_STANDALONE_SHELL vxprj bundle add $(AMP4_PROJ) BUNDLE_AMP_SEC vxprj component add $(AMP4_PROJ) INCLUDE_AMP_CPU_04 # need to remove INCLUDE_WDB_SYS, incompatible with AMP vxprj component remove $(AMP4_PROJ) INCLUDE_WDB_SYS # remove networking. No devices. vxprj component remove $(AMP4_PROJ) INCLUDE_NETWORK vxprj build $(AMP4_PROJ) cp $(AMP4_DIR)/default/vxWorks $(FTP_DIR)/vxWorks.4 amp5: vxprj create -force $(BSP) $(TOOL) $(AMP5_PROJ) vxprj bundle add $(AMP5_PROJ) BUNDLE_STANDALONE_SHELL vxprj bundle add $(AMP5_PROJ) BUNDLE_AMP_SEC vxprj component add $(AMP5_PROJ) INCLUDE_AMP_CPU_05 # need to remove INCLUDE_WDB_SYS, incompatible with AMP vxprj component remove $(AMP5_PROJ) INCLUDE_WDB_SYS # remove networking. No devices. vxprj component remove $(AMP5_PROJ) INCLUDE_NETWORK vxprj build $(AMP5_PROJ) cp $(AMP5_DIR)/default/vxWorks $(FTP_DIR)/vxWorks.5 amp6: vxprj create -force $(BSP) $(TOOL) $(AMP6_PROJ) vxprj bundle add $(AMP6_PROJ) BUNDLE_STANDALONE_SHELL vxprj bundle add $(AMP6_PROJ) BUNDLE_AMP_SEC vxprj component add $(AMP6_PROJ) INCLUDE_AMP_CPU_06 # need to remove INCLUDE_WDB_SYS, incompatible with AMP vxprj component remove $(AMP6_PROJ) INCLUDE_WDB_SYS # remove networking. No devices. vxprj component remove $(AMP6_PROJ) INCLUDE_NETWORK vxprj build $(AMP6_PROJ) cp $(AMP6_DIR)/default/vxWorks $(FTP_DIR)/vxWorks.6 amp7: vxprj create -force $(BSP) $(TOOL) $(AMP7_PROJ) vxprj bundle add $(AMP7_PROJ) BUNDLE_STANDALONE_SHELL vxprj bundle add $(AMP7_PROJ) BUNDLE_AMP_SEC vxprj component add $(AMP7_PROJ) INCLUDE_AMP_CPU_07 # need to remove INCLUDE_WDB_SYS, incompatible with AMP vxprj component remove $(AMP7_PROJ) INCLUDE_WDB_SYS # remove networking. No devices. vxprj component remove $(AMP7_PROJ) INCLUDE_NETWORK vxprj build $(AMP7_PROJ) cp $(AMP7_DIR)/default/vxWorks $(FTP_DIR)/vxWorks.7 This Makefile automates the creation and building of separate VxWorks images for each CPU, reducing manual effort and ensuring consistent configuration.\nUsing wrload to Launch Images # wrload runs on CPU0’s VxWorks shell. It loads the VxWorks image for each target CPU from the mounted filesystem, initializes memory, and sets up the .bss segment. Be aware:\nInsert taskDelay() between wrload calls to avoid timing issues. Provide a valid bootline using -tsym or boot may fail. Example:\nwrload (\u0026#34;-file host:/vxWorks.1 -cpu 1 -tsym \\\u0026#34;*sysBootLine=dtsec(1,1) host:/vxWorks.1 h=192.168.1.100 e=192.168.1.51\\\u0026#34;\u0026#34;); taskDelay (60); wrload (\u0026#34;-file host:/vxWorks.2 -cpu 2 -tsym \\\u0026#34;*sysBootLine=dtsec(2,2)\\\u0026#34;\u0026#34;); taskDelay (60); Using tip to Access Shells on Other CPUs # When physical serial connections are unavailable, tip connects to other CPUs via MIPC Serial Devices (MSDs). The BSP auto-generates /ttyMsdX entries.\nExample output from devs:\n-\u0026gt; devs drv name 0 /null 1 /tyCo/0 1 /ttyMsd0 1 /ttyMsd1 ... To open a shell on CPUs 1 and 2:\ntip (\u0026#34;dev=/ttyMsd0\u0026#34;, \u0026#34;dev=/ttyMsd1\u0026#34;) ~? # Available commands: # ~.: Exit # ~l: List sessions # ~s: Switch session # ~?: Help Conclusion # This article introduced key concepts and setup procedures for running AMP systems using VxWorks 6.9. If you need help configuring multiprocessor BSPs, MIPC/MSD setup, or working with the P4080 architecture, feel free to reach out.\n","date":"2025-01-29","externalUrl":null,"permalink":"/app/asymmetric-multi-processing-with-vxworks-6-9/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eAsymmetric Multi-Processing (AMP) allows a multi-core system to run multiple independent operating systems (OSs) concurrently. In this model, each CPU has its own private memory region containing its OS and applications, although shared memory regions can also be used for inter-CPU communication. This is in contrast to Symmetric Multi-Processing (SMP), where a single OS spans multiple CPUs using a common memory space.\u003c/p\u003e","title":"Asymmetric Multi Processing With VxWorks 6.9","type":"app"},{"content":"","date":"2025-01-29","externalUrl":null,"permalink":"/tags/vxworks-6.9/","section":"Tags","summary":"","title":"VxWorks 6.9","type":"tags"},{"content":"","date":"2025-01-26","externalUrl":null,"permalink":"/tags/mils/","section":"Tags","summary":"","title":"MILS","type":"tags"},{"content":"Q. What is 8500.1?\nA. Dated October 24, 2002, 8500.1 is a Department of Defense (DoD) Directive on Information Assurance (IA) that states:\nAll IA or IA-enabled products incorporated into DoD IA systems must comply with NSTISSP 11 Products must be satisfactorily evaluated prior to purchase Purchase contracts shall specify that product evaluation will be maintained for subsequent releases See http://west.dtic.mil/whs/directives/corres/pdf/d85001_102402/d85001p.pdf for a complete copy of this directive.\nQ. What is 8500.2?\nA. Dated February 12, 2003, 8500.2 is a DoD Instruction for Information Assurance Implementation that states:\nIf a Protection Profile (PP) exists for a specific technology, then products must be evaluated against this PP A robustness level will be assigned—medium or high— which must be achieved See www.dtic.mil/whs/directives/corres/pdf/850002p.pdf for a complete copy of this DoD instruction.\nQ. What is ACTS?\nA. ACTS stands for Advanced Extremely High-Frequency COMSEC/TRANSEC System. ACTS systems are usually involved in highly secure military command and control systems, like missile and satellite weapons systems.\nQ. What is AR 25-2?\nA. Dated November 14, 2003, AR 25-2 is the Army Regulation\n25-2 that establishes an IA policy for the Army. This regulation:\nSpecifies and defines roles and responsibilities. The Chief Information Officer, level G-6 (CIO/G-6) is the person responsible for execution of this regulation Is implemented by Army Certification Authorities (two) and Combined Test Support Facility (Ft. Hood, TX) Has general applicability to a broad range of technology: IT, water, power, and other infrastructure Incorporates 8500.1 and 8500.2 for software IA See www.army.mil/usapa/epubs/pdf/r25_2.pdf for more information.\nQ. What is Assurance?\nA. Assurance is the confidence (medium or high) that a component or system will meet security objectives.\nQ. What is CCEVS?\nA. CCEVS stands for Common Criteria Evaluation and Validation Scheme. This scheme:\nTests Security Properties of COTS products-these tests are performed by Accredited Commercial Laboratories Validates the results underwritten by NIAP-these results are posted for public access CCEVS is, in effect, the U.S. Government version of the Common Criteria for certification of critical systems at high EAL.\nSee http://niap.bahialab.com/cc-scheme for more information.\nSee also What is NIAP?, below.\nQ. What is a CCTL?\nA. CCTL stands for Common Criteria Testing Lab. These testing labs are information technology (IT) computer security testing laboratories accredited to conduct IT security evaluations for conformance to the Common Criteria.\nIn the United States, the National Institute of Standards and Technology (NIST) National Voluntary Laboratory Accreditation Program (NVLAP) accredits CCTLs to meet National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS) requirements and conduct IT security evaluations for conformance to the Common Criteria.\nA list of all CCTLs is located at www.commoncriteriaportal.org/public/developer/index.php?menu=9.\n“Common Criteria Testing Lab” is the U.S. term; similar terms are used in other countries. See http://en.wikipedia.org/wiki/Common_Criteria_Testing_Laboratory for more information.\nQ. What is Common Criteria/ISO-15408?\nA. Common Criteria/ISO-15408 is the standard for Common Criteria for Information Technology Security Evaluation, an international security certification standard for IT products. This Common Criteria standard describes a framework in which IT users specify security requirements for a product, and vendors implement products and make claims about their products’ security. Authorized Common Criteria Testing Laboratories (CCTLs) evaluate the submitted products to determine if they actually meet the claims.\nFormally, Common Criteria (CC) is “a common language and structure for expressing IT security requirements in a manner that allows those requirements to be used to evaluate allegedly conforming products.”\nThere is an international CC Recognition Arrangement for EAL1-4 systems. There are currently 12 issuing countries:\nAustralia, Canada, France, Germany, Japan, the Netherlands, New Zealand, Norway, the Republic of Korea, Spain, the UK, and the USA. These countries will also accept EAL1-4 certificates from 12 accepting countries: Austria, Czech Republic, Denmark, Finland, Greece, Hungary, India, Israel, Italy, Singapore, Sweden, and Turkey.\nA current list of participating countries can be found at www.commoncriteriaportal.org/public/content/natscheme.html.\nCurrently, there is no CC recognition arrangement at EAL5-7. Without this agreement in place, each country must establish its own scheme for high-level (EAL5-7) evaluation. See What is CCEVS?, above.\nQ. Is there a Common Criteria/ISO-15408 primer available?\nA. Yes. The Common Criteria Introduction document is available at www.commoncriteriaportal.org/public/files/ccintroduction.pdf.\nQ. Where can I get the latest copy of the Common Criteria?\nThe latest version of Common Criteria and the Common Evaluation Methodology documents is available at www.commoncriteriaportal.org/public/developer/index.php?menu=2.\nQ. Which products have been evaluated by the Common Criteria?\nA. The full list of all products evaluated by the Common Criteria standard is available at www.commoncriteriaportal.org/public/developer/index.php?menu=6.\nQ. When was the Common Criteria published?\nA. Version 1.0 of the Common Criteria was published for comment in January 1996. After two years of reviews and trials were incorporated, version 2.0 was published in May 1998. The official version of the Common Criteria and the Common Evaluation Methodology is v3.1. It consists of three parts:\nIntroduction and General Model Security and Functional Requirements Security Assurance Requirements CC documents are available at www.commoncriteriaportal.org/public/consumer/index.php?menu=2.\nQ. What is DCID 6/3?\nA. DCID 6/3 is a standard for Protecting Sensitive Compartmented Information Within Information Systems created by the Director of Central Intelligence. The DCID 6/3 document describes the following security issues:\nRoles and Responsibilities Levels of Concern and Protection Levels Confidentiality System Security Features and Assurances Systems Integrity Security Features and Assurances System Availability Security Features and Assurances Requirements for Interconnected Information Systems and Advanced Technology Administrative Security Requirements Risk Management, Certification, and Accreditation This document is available at www.fas.org/irp/offdocs/DCID_6-3_20Manual.htm.\nQ. What is Defense-in-Depth?\nA. Defense-in-Depth is a strategy that integrates people, operations, and technology capabilities to establish information assurance (IA) protection across multiple layers and dimensions. Successive layers of defense will cause an adversary who penetrates or breaks down one barrier to promptly encounter another Defense-in-Depth barrier, and then another, until the attack ends. [NSA]\nQ. What is DITSCAP?\nA. DITSCAP stands for DoD Information Technology Security Certification and Accreditation Process. This process:\nHelps ensure that information systems operate at an acceptable level of risk Provides a system that meets customer needs while adhering to risk guidelines Note that DITSCAP was replaced by DIACAP on July 6, 2006.\nFor more information on DITSCAP, see http://iase.disa.mil/ditscap/DitscapFrame.html.\nFor DITSCAP to DIACAP Transition Guidelines, see http://iase.disa.mil/ditscap/diacap-transition-encl6.pdf.\nQ. What is DIACAP?\nA. DIACAP stands for DoD Information Assurance Certification and Accreditation Process. This process:\nUpdates key elements of DITSCAP with a focus on Information Assurance Replaced DITSCAP processes as of July 6, 2006 Now accepts NIAP CC certificates without additional review For more information on DIACAP, see http://iase.disa.mil/ditscap/interim-ca-guidance.pdf.\nFor DITSCAP to DIACAP Transition Guidelines, see http://iase.disa.mil/ditscap/diacap-transition-encl6.pdf.\nQ. What are Evaluation Assurance Levels (EALs)?\nA. Evaluation Assurance Levels (EALs) define a scale for measuring the criteria for evaluation of Protection Profiles (PPs) and Security Targets (STs). The following table provides a summary of EAL levels:\nQ. What is a Foundational Threat?\nA. A Foundational Threat is a threat that attacks the foundation of a secure application platform, rendering it ineffective from a security standpoint. Foundational threats include Bypasses, Compromises, Tamperings, Cascades, Covert Channels, Viruses, and Subversions.\nQ. What is HAIPE?\nA. HAIPE stands for High Assurance Internet Protocol Encryptor, an NSA crypto device. These devices are built by network vendors like Cisco, General Dynamics, Mitre, Harris, ViaSat, and other companies that use the HAIPE crypto system and APIs.\nQ. What is Information Assurance (IA)?\nA. Information Assurance is a strategy to insure that systems incorporate protection, detection, and availability, with the objective to reduce amount of security critical code and increase examination of security-critical code. [NSA]\nIA is defined as the set of measures intended to protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and nonrepudiation. This includes providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. These measures are planned and executed by the Information Assurance Directorate (IAD) of the National Security Agency/Central Security Service (NSA/CSS). [NSA]\nThere are five IA pillars:\nAvailability Integrity Authentication Confidentiality Nonrepudiation These pillars and any measures taken to protect and defend information and information systems, and to provide for the restoration of information systems, constitute the essential underpinnings for ensuring trust and integrity in information systems.\nQ. What is MILS?\nA. MILS stands for Multiple Independent Levels of Security (or Safety or Separation). MILS is a layered software architecture (kernel, middleware, applications, and communications) for building “multilevel secure (MLS) systems” with high assurance that multiple separated entities (kernel, middleware, applications) will be able to operate and communicate exactly as dictated by specified safety and security policies, each at its own safety or security classification level as required, and all certified under Common Criteria to the appropriate Evaluation Assurance Level (EAL6 or higher for the OS).\nMILS is a system that supports multiple, separated entities, each operating at a different classification level (safety/security/domains). MILS systems enforce:\nSoftware architecture that supports MLS and MSLS Robust time and space partitioning scheduler Secure information flow, data isolation, periods processing, and damage limitation (safety/security/domains) Q. What is MLS?\nA. MLS stands for Multilevel Security. An MLS system securely processes data of differing classifications, such as guards, downgraders, firewalls, data fusion, and databases. Prior to MILS, in most cases, an MLS systems required redundant hardware for each classification of data.\nQ. What is MSLS?\nA. MSLS stands for Multi-Single-Level Security. An MSLS system securely separates data of differing classifications—such as communications platforms and infrastructures—one level at a time. Prior to MILS, in most cases, an MSLS required redundant hardware for each classification of data.\nQ. What is NEAT?\nA. NEAT stands for Non-Bypassable, Evaluatable, Always Invoked, and Tamper-Proof. This term describes the fundamental characteristics of a separation kernel (SK).\nQ. What is NIAP?\nA. NIAP stands for National Information Assurance Partnership, a partnership of the National Security Agency and the National Institutes of Technology, and is the U.S. Government organization that administers the CCEVS in the U.S. See What is CCEVS?, above.\nQ. What is NIAS?\nA. In moving Information Assurance (IA) forward to protect the National Information Infrastructure (NII), a National Information Assurance Strategy (NIAS) was formed to encourage mutual cooperation and acceptance of common objectives. This strategy, built on the following five cornerstones, articulated the IA pillar concepts as a national framework that unified the U.S. Government’s IA efforts:\nCyber-security awareness and education Strong cryptography Good security-enabled commercial information technology An enabling global Security Management Infrastructure A civil defense infrastructure equipped with an attack sensing and warning capability and coordinated response mechanisms Q. What is NSTISSP 11?\nA. NSTISSP 11 stands for National Security Telecommunications and Information Systems Security Policy. This national policy governs the acquisition of Information Assurance (IA) and\nIA-enabled information technology products that protect national security information. This policy states that:\nEffective July 1, 2002, all COTS IA and IA-Enabled products must be evaluated Evaluation must be done by the NIAP Evaluation and Validation Program (CCEVS) Evaluation will be conducted by an accredited commercial laboratory (a CCTL in the U.S.; see What is a CCTL?, above) Evaluation must be done using an NSA or NSA-approved process Waivers have been granted in the past, but Daniel Wolf, Director of IAD for the NSA, stated in 2003: “No more waivers.” (quoted from DHS-OSD Software Assurance Workshop, October 3, 2005).\nFor more information, see http://niap.bahialab.com/ccscheme/nstissp-faqs.cfm.\nQ. What is PCS?\nA. PCS stands for Partitioning Communication System. PCSexpress is a product from Objective Interface Systems (OSI) that enables trusted communication between partitions. More information is available at www.ois.com.\nQ. What is a Protection Profile (PP)?\nA. A Protection Profile (PP) is a standard set of security requirements for a category of products. Examples of Protection Profiles are the Separation Kernel Protection Profile (SKPP), File System Protection Profile (FSPP), and the MILS Network Stack Protection Profile (MNSPP).\nA complete list of Protection Profiles is available at www.commoncriteriaportal.org/public/developer/index.php?menu=7.\nQ. What is robustness?\nA. The robustness of an evaluated product is the level of confidence in the protection provided to the security services it supports. [NIAP]\nIn addition, robustness is to the level of security functionality, level of assurance, and level of security application in a communications product. NIAP categorizes products into three groups: basic, medium, and high robustness. These are categories of environment for which a Target of Evaluation(TOE) can exist.\nQ. What is a Security Policy Manager?\nA. A Security Policy Manager controls data flow using Security Policies, typically in a MILS separation kernel.\nQ. What is a Security Target (ST)?\nA. A Security Target (ST) describes the security claims made for the Target of Evaluation (TOE) and how the TOE meets those requirements (often by claiming conformance to Protection Profiles (PPs)). The TOE security threats, objectives, requirements, and summary specification of security functions and assurance measures together form the primary inputs to the ST.\nQ. What is a Target of Evaluation (TOE)?\nA. A Target of Evaluation (TOE) is the actual target (processor/hardware/BSP/operating system/applications) that will be evaluated in a security analysis.\nQ. Where can I find additional security resources?\nA. Additional CCEVS resources are available at www.nsa.gov/ia/industry/niap.cfm. Click on “CCEVS” for more information on Common Criteria.\nAdditional NIAP resources are available at www.nsa.gov/ia/industry/niap.cfm. Click on “NIAP” for more information.\nA list of NSA acronyms is available at www.nsa.gov/ia/acronyms.cfm?MenuID=10.\nComplete Common Criteria information is available at www.commoncriteriaportal.org.\nDownload the complete Document: Security FAQ on MILS\n","date":"2025-01-26","externalUrl":null,"permalink":"/app/security-faq-about-mils-multiple-independent-levels-of-security/","section":"Apps","summary":"\u003cp\u003eQ. What is 8500.1?\u003c/p\u003e\n\u003cp\u003eA. Dated October 24, 2002, 8500.1 is a Department of Defense (DoD) Directive on Information Assurance (IA) that states:\u003c/p\u003e","title":"Security Faq About Mils Multiple Independent Levels of Security","type":"app"},{"content":"","date":"2025-01-26","externalUrl":null,"permalink":"/tags/database/","section":"Tags","summary":"","title":"Database","type":"tags"},{"content":" Raima Releases RDM v14.1 embedded database with support for VxWorks.\nRaima provides an enterprise caliber database with a small footprint, perfectly designed for the Wind River® VxWorks® real-time operating system and Wind River Linux. In this release, clients will find a new set of features which will enable IoT and IIoT applications that need performance within self-maintained applications.\nThese instructions are for RDM targeting VxWorks 7 and later using VxWorks kernel modules or VxWorks RTP. In the following we will explains these topics:\nA Quick Overview of VxWorks Task Priorities for RDM on Real Time OSs How to Do a VxWorks Source Build How to Compile a VxWorks Kernel for RDM How to Compile a VxWorks Bootloader How to Develop an Application for VxWorks Using RDM Native Build for the Host Development Platform A Quick Overview of VxWorks # VxWorks Kernel Modules\nVxWorks kernel modules do not use ordinary executables as most other operating systems do. Instead, they use relocatable objects which can be compiled into the kernel or loaded during run time on a running target. The VxWorks loader is just a runtime link loader which is capable of both loading and unloading these objects on a running VxWorks kernel. For this to work, these relocatable files must fulfill some important requirements:\nThe C library must not be linked in Startup code must not be linked in Unresolved symbols in these relocatable files must either be entry points into VxWorks, entry points into libraries already loaded or entry points that are not used during execution. No PIC (position independent code) should be used. Applications can be prepared for execution on the target in principally two ways:\nCompile the application without linking against any library. On the target, we load RDM libraries and then the application. Compile the application by linking against RDM libraries. On the target, we load our linked application. With the first approach, it is possible to load more than one application that uses the same library. The second approach does not have that capability, but it is more convenient by only having to load one module.\nVxWorks RTP\nVxWorks Real Time Processes (RTPs) are running executables. With a Memory Management Unit (MMU) each of these processes run in their own address space protected from other processes and the kernel. The executables can be absolutely linked or relocatable.\nHardware without a MMU or where the MMU have been disable will run each RTP with its own region of virtual memory. In this mode, there is no protection between the RTPs and the kernel, but since no MMU need to be updated context switching is faster.\nIn any case, each process can contain several tasks similar to the kernel. It is the tasks within the RTPs that are scheduled and not the RTPs themselves. The RTPs communicate with the kernel through operating system calls.\nTask Priorities for RDM on Real Time OSs # RDM is implemented using one or more tasks under VxWorks. How many tasks are required depends on how RDM is used.\nThe tfs_embed configuration has one server task (assuming \u0026ldquo;threaded\u0026rdquo; is specified) and one vacuum task. The server task will initialize the TFS, spawn a connection task for each client, and perform some cleanup upon termination.\nEach of these tasks can run at the same or different priority levels. A higher priority task (lower numerical value under VxWorks) is guaranteed to run before a lower priority task (higher numerical value under VxWorks) if the higher priority task is ready to run. Assigning priorities is crucial for proper operation of the system. Incorrectly assigned priorities can lead to starvation, resource exhaustion, or unresponsive systems. There is also often a trade-off between these objectives which make the priority assignment even more difficult.\nFor a system consisting of one producer and one consumer where we optimize for responsiveness of the producer, the producer is assigned a higher priority than the consumer. This may, under certain conditions, exhaust resources and starve the consumer. The consumer is assigned a higher priority than the producer if we instead want to minimize the amount of resources used and protect against starvation. This will, however, make the producer less responsive. There is therefore, often a trade-off among responsiveness of a system, resource allocation, and starvation. Exactly how this plays out depends on the application, and how priorities should be assigned depends on your requirements.\nIn general, the priorities of RDM tasks are set by giving priority to the consumer. This minimizes the amount of resource used but may result in less responsive systems. These priorities are defined in include/pspvxworks.h. You may change these priorities based on your requirements. If you are new to real-time system programming and wish to familiarize yourself with this or rate-monotonic scheduling, you may want to consider reading the article \u0026ldquo;What Every Engineer Needs To Know About Rate-Monotonic Scheduling: A Tutorial\u0026rdquo; by Janusz Zalewski.\nHow to Do a VxWorks Source Build # The first step before compiling a VxWorks Kernel or compiling RDM for VxWorks is to set up a VxWorks Source Build (VSB). Set up the VxWorks environment as follows, where {WindRiver} is the location of the VxWorks 7 host installation:\n$ {WindRiver}/wrenv.sh -p vxworks-7 Or,\nc:\u0026gt; {WindRiver}/wrenv.exe -p vxworks-7 You can use Workbench to set up a VxWorks Source Build. However in the following we will use the command line.\nAfter you have installed RDM, locate the appropriate target directory for your platform. In the following we assume you are using vxworks7-x86_32_core.\n$ cd {targetdir}/target/vxworks7-x86_32_core where {targetdir} is the location where RDM have been installed. In this directory you find a number of files. Consult setup.sh and make sure that the following two environment variables have been set as documented in this script:\nLM_LICENSE_FILE WIND_HOME wrenv.sh that you ran first will set the second environment variable. The script uses a number of other environment variables. Some of them are relevant for the VxWorks Source Build while other variables are needed for later steps. Please consult this script for further details.\nWhen you are satisfied with the content of setup.sh run the script as follows:\n$ sh ./setup.sh --vsb VSB for other targets\nA VSB for other targets can also be set up. This is only applicable with a RDM source package.\nIn the source for RDM, create a target directory under target similar to target/vxworks7-x86_32_core for VxWorks downloadable kernel modules (DKM) or a target directory like target/vxworks7-rtp-x86_32_core for VxWorks real time processes (RTP). Edit the files to matches the target directory and the desired target platform. Edit the setup.sh according to the instructions in that file.\nWhen you are satisfied with the content of setup.sh run the scrip as follows:\n$ sh ./setup.sh --vsb And then:\n$ sh ./setup.sh --template to generate the template needed for building RDM in later steps.\nHow to Compile a VxWorks Kernel for RDM # The next step is to build a VxWorks Kernel or A VxWorks Image Project (VIP) targeting VxWorks 7. The description here is for RDM using VxWorks kernel modules or VxWorks RTP.\nPlease note that this step is also needed when using the VxWorks Simulator (vxsim) as the default VIP for the simulator does not include the required components for RDM. Make sure you have followed the instruction above for setting up and building a VxWorks Source Build (VSB) unless you are using one of the VxWorks prebuilt targets.\nSet up the VxWorks environment as follows, where {targetdir} is the location of the VxWorks 7 install:\n$ {targetdir}/wrenv.sh -p vxworks-7 c:\u0026gt; {targetdir}/wrenv.bat -p vxworks-7 You can use Workbench to set up a VxWorks Image Project. However in the following we will use the command line similar to previous section.\nAssuming you also have set LM_LICENSE_FILE, run the commands below. Here we assume you are using the vxworks7-x86_32_core target:\n$ cd {targetdir}/target/vxworks7-x86_32_core $ sh ./setup.sh --vip where {targetdir} is the location of the RDM install. You can do this build in any directory as long as you specify the path to the setup script.\nThe script above sets up a RAM file system under /ram0. You may want to use some other persistent storage. The details for this will depend on your hardware and is beyond the scope of this document.\nThe script also include components required for RDM. The vxworks7-[rtp-]x86_[32|64]_core targets uses the itl_generic driver with DRV_VGA_M6845 and INCLUDE_FEI8255X_VXB_END. You may need to edit this to match the actual board you are using. Please consult this script for further details. You may also want to include other components depending on how you do your development, debugging, QA, or deployment. This is beyond the scope of this document.\nHow to Compile a VxWorks Bootloader # This is a VIP similar to a VxWorks kernel except that it is set up to boot another VxWorks Kernel. Follow the instructions above but instead run the setup.sh script as follows:\n$ sh ./setup.sh --bootapp If you are using this on a host where you for example have Linux installed using Grub2 to boot you can install the above boot loader as follows.\nStart by copying the above bootloader to a file system available to Grub2:\n$ sudo cp bootapp_.../default/vxWorks /boot/BootApp Add the following file to Grub2\u0026rsquo;s configuration:\n$ cat \u0026gt;07_BootApp \u0026lt;\u0026lt;-EOF exec tail -n +3 $0 # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the \u0026#39;exec tail\u0026#39; line above. menuentry \u0026#34;VxWorks BootApp\u0026#34; { multiboot /boot/BootApp sysbootline:fei(0,0)my_host:/home/my_user/workspace/vip_x86_32_core/default/vxWorks h=192.168.1.244 e=192.168.1.174 g=192.168.1.1 u=my_user pw=my_password f=0x8 tn=my_target } EOF Edit the file where:\nfei(0,0) is the ethernet device my_host is the development host name The h parameter is the IP address of the host where you have a ftp server running (192.168.1.244) The e parameter is the IP address of the target board (192.168.1.174) The g parameter is the gateway (192.168.1.1) The u parameter is the ftp user (my_user) The pw parameter is the ftp password (my_password) The f parameter is the boot flags (0x8) The tn parameter is the target name (my_target) Copy the configuration file, update grub, and halt the system:\n$ sudo mv /etc/grub.d/07_BootApp $ sudo update-grub $ shutdown -h now Power the target and it should now boot into VxWorks.\nHow to Develop an Application for VxWorks Using RDM # RDM examples written in C use the RDM_STARTUP_EXAMPLE macro. The argument to this macro must match the name of a named main function as shown below. The tims example uses this macro as follows:\nint32_t EXTERNAL_FCN tims_main( int32_t argc, const char *const *argv) { ... } RDM_STARTUP_EXAMPLE(tims) You also have the option of compiling in a hook for the RDM_STARTUP_EXAMPLE. Compile in a hook like this:\n-DPSP_STARTUP_HOOK=chdir(\u0026#34;/ram0\u0026#34;); This will change the current working directory. This is most convenient when we launch this from WorkBench using a debug connection. WorkBench does not give you the option of specifying a current working directory for downloadable kernel modules. It must always be set programmatically.\nUsing VxWorks Kernel Modules\nThe RDM_STARTUP_EXAMPLE macro as used above expands to a function with the following signature (this signature matches the requirements for sp and taskSpawn):\nint32_t tims( int32_t a1, int32_t a2, int32_t a3, int32_t a4, int32_t a5, int32_t a6, int32_t a7, int32_t a8, int32_t a9, int32_t a10); Use this function as the entry point to the tims example. The tims example does not take any argument. You should therefore pass in 0 as the first and only argument to this function.\ntims 0 This function takes care of initializing the RDM platform support layer (psp_init ()), builds up the argument list for the named main function, calls the named main function, and terminates the platform support layer (psp_term ()).\nExamples and tools that do take arguments should have the arguments passed in as strings - one string for each parameter. You always need to pass in 0 after the last argument unless all ten arguments are specified.\nUsing VxWorks RTP The RDM_STARTUP_EXAMPLE macro as used above expands to a normal main function under VxWorks RTP. This is just like many other host operating systems.\nNative Build for the Host Development Platform # Compiling RDM for VxWorks kernel modules consist of a native build for your host development platform and a cross compiled build for your VxWorks target.\nNative Build for the Host Development Platform\nBefore you can compile RDM for VxWorks kernel modules or VxWorks RTP, you need a native build for your host development platform.\nNative build for Linux\nPlease follow the steps outlined in Using \u0026ldquo;configure\u0026rdquo; and Using \u0026ldquo;make\u0026rdquo;. Pay special attention to that you need to provide the command line option \u0026ndash;enable-vxworks7-project-files or \u0026ndash;enable-vxworks7-rtp-project-files when running configure for the VxWorks project files to be configured.\nSetting up project files for Wind River Workbench\nAssuming you have done a native build for your host development platform using the configure script and make on UNIX or the Visual Studio project files on Windows, you are now ready to set up the project files for Wind River Workbench.\nOn GNU/Linux the following is relative to the top build directory. On Windows it is relative to the top source or install directory:\n$ cd target/vxworks7-... $ {wind_host}/workbench-4/wrtool -data . wrtool.txt $ cd ../.. Cross Compiled Build for VxWorks Assuming you have set up the project files as explained above.\nStart WorkBench Select the target/vxworks7-\u0026hellip; as the work space. You should now have one project file for each example and tutorial that you can build and run on your target.\n","date":"2025-01-26","externalUrl":null,"permalink":"/app/deploy-rdm-embedded-database-on-vxworks/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eRaima Releases RDM v14.1 embedded database with support for VxWorks.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eRaima provides an enterprise caliber database with a small footprint, perfectly designed for the Wind River® VxWorks® real-time operating system and Wind River Linux. In this release, clients will find a new set of features which will enable IoT and IIoT applications that need performance within self-maintained applications.\u003c/p\u003e","title":"Deploy RDM Embedded Database on VxWorks","type":"app"},{"content":"","date":"2025-01-26","externalUrl":null,"permalink":"/tags/rdm/","section":"Tags","summary":"","title":"RDM","type":"tags"},{"content":"","date":"2025-01-24","externalUrl":null,"permalink":"/tags/targetrts/","section":"Tags","summary":"","title":"TargetRTS","type":"tags"},{"content":"VxWorks is a Real-Time Operating System (RTOS) built by Wind River. It is a licensed RTOS designed for industrial equipment, aerospace and defense, network infrastructure, consumer electronics, etc. VxWorks RTOS provides a complete development environment with an Eclipse-based IDE called the Wind River Workbench. The RTOS also provides a simulator that can help you virtualize your hardware and make the development process easier. The VxWorks development tools also let you use modern programming frameworks including the C++ 17 standard.\nThe TargetRTS C++ library can be used to develop any type of embedded or real-time applications on VxWorks RTOS. The Operating System supports C++ in its user space on 32/64-bit ARM and Intel architecture devices. Hence, you can create complex software applications with much ease while working with the TargetRTS library on RTOS.\nThis article covers how to build Model RealTime applications for VxWorks 7 from a Windows host machine:\nNote: VxWorks support is available from the 7.1.11 version of TargetRTS.\nSetting Environment Variables # Let\u0026rsquo;s say, you have created the WindRiver folder in the C drive and installed the complete VxWorks package in the C:\\WindRiver directory on a Windows host. Then, you will get the VxWorks RTOS, Clang compiler and WorkBench in this folder. To build TargetRTS on VxWorks, you need to set the following three VxWorks-specific environment variables.\nVariables Values WIND_BASE install-dir\\vxworks\\version WIND_CC_SYSROOT install-dir\\workspace\\VSB WIND_HOME install-dir Here the install-dir is the directory where VxWorks is installed (by default, which is C:\\WindRiver) and version is the VxWorks version.\nCreating and Building VxWorks Source Build (VSB) Project # The VxWorks RTOS installs a command-line interface called the wrenv.exe to set up the environment for accessing VxWorks tools.\nA VSB project specifies the CPU or board support package (BSP) associated with your target. A BSP is nothing but a set of code that provides a standard interface between the target hardware and the VxWorks RTOS.\nOpen the wrenv.exe shell and configure the VSB as shown below:\ncd workspace vxprj vsb create -bsp vxsim_windows_2_0_1_2 -S VSB vxprj build VSB You can also create the VSB project using the VxWorks Workbench.\nCreating and Building VxWorks Image Project (VIP) # VxWorks compiles the BSP source files from the BSP selected in the VSB and generates a VxWorks image file, which is VxWorks Image Project.\nIn the wrenv.exe shell, configure the VIP as shown below:\nvxprj create -vsb VSB llvm VIP cd VIP vxprj build You can also create the VIP project using the VxWorks Workbench.\nBuilding TargetRTS Static Library # You can run the following command to create and build the TargetRTS library. This command must be issued from TargetRTS/src folder using wrenv.exe. This build command should work if you have already created the VSB and VIP projects.\nrtperl Build.pl VxWorks7T.simnt-Clang-15.x make all Note: The rtperl utility can be found inside the plugin com.ibm.xtools.umldt.rt.core.tools in the Model RealTime installation. Locate the version under \u0026rsquo;tools\u0026rsquo; that matches your operating system and add its folder to your PATH variable before running the command.\nBuilding Model RealTime Hello World Application # Start Model RealTime by running Eclipse.exe from the wrenv.exe present in the WindRiver folder.\nCreate a \u0026lsquo;Hello World\u0026rsquo; application on Eclipse with the following configuration:\nConfiguration Values TargetRTS Configuration VxWorks7T.simnt-Clang-15.x Make type GNU_make Build the application to see the executable.vxe file, which will be recognized by the VxWorks RTOS.\nRunning VxWorks Simulator # You can run the VxWorks simulator to run the \u0026lsquo;Hello World\u0026rsquo; application. For this, open the wrenv.exe command line from the WindRiver folder and change the directory to locate the simulator. VxWorks simulator will be present in VIP project inside default folder.\n\u0026gt;C:\\WindRiver\u0026gt;cd workspace\\VIP\\default C:\\WindRiver\u0026gt;cd workspace\\VIP\\default\n\u0026gt;C:\\WindRiver\\workspace\\VIP\\default\u0026gt;vxsim Wait for the simulator to start. You have to run the executable on a simulator. Copy the \u0026lsquo;Hello World\u0026rsquo; executable path and use the cd command on simulator to change the directory to the path of the executable.vxe of the \u0026lsquo;Hello World\u0026rsquo; application. Ensure that the double quotes are present for the path.\ncd \u0026#34;/host.host/C:/ModelRealTime/vs/HelloWorld_target/default\u0026#34; To run the executable.vxe, you can call the following command in the simulator. Here also, ensure that the double quotes are present.\nrtpSp \u0026#34;executable.vxe -URTS_DEBUG=quit\u0026#34; This command spawns an RTP application, that is, it creates and initializes a Real Time Process in the system with the specified .vxe file as the executable for the RTP.\n","date":"2025-01-24","externalUrl":null,"permalink":"/app/vxworks-integration/","section":"Apps","summary":"\u003cp\u003e\u003ca href=\"https://www.vxworks.net\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e is a Real-Time Operating System (RTOS) built by Wind River. It is a licensed RTOS designed for industrial equipment, aerospace and defense, network infrastructure, consumer electronics, etc. VxWorks RTOS provides a complete development environment with an Eclipse-based IDE called the Wind River Workbench. The RTOS also provides a simulator that can help you virtualize your hardware and make the development process easier. The VxWorks development tools also let you use modern programming frameworks including the C++ 17 standard.\u003c/p\u003e","title":"VxWorks Integration","type":"app"},{"content":"","date":"2025-01-23","externalUrl":null,"permalink":"/tags/manage-projects/","section":"Tags","summary":"","title":"Manage Projects","type":"tags"},{"content":"This article gives introduction to managing projects from the command-line interface for VxWorks development.\nExploring the Environment # Setting the Build Environment\nEnvironment variables must be configured so that you can build from the workstation command line.\nWIND_HOME is installation dir (installDir) WIND_BASE is vxworks-7 (or vxworks-6) dir From WIND_HOME:\nLinux:\n$ ./wrenv.sh –p vxworks-7 (or vxworks-6) OR to preserve existing bash shell:\n$ eval `./wrenv.sh -p vxworks-7 -o print_env -f sh Windows:\n\u0026gt; wrenv.exe -p vxworks-7 (or vxworks-6) Setting the Workspace\nLinux:\n$ export WIND_WRTOOL_WORKSPACE=installDir/workspace Windows:\n\u0026gt; set WIND_WRTOOL_WORKSPACE=installDir\\workspace Exploring VxW Source Projects (VSB)\nList VSB layers:\n\u0026gt; wrtool prj vsb list vsbName List All CPU Architectures Supported in this VxWorks Installation:\n\u0026gt; wrtool vsb listcpus Get VSB Configuration:\n\u0026gt; wrtool prj vsb value get vsbParam vsbName Exploring VxW Image Projects (VIP)\nWhich BSP + VSB is the VIP based on?\n\u0026gt; wrtool prj vip info vipName Which components are included in this VIP?\n\u0026gt; wrtool prj vip component list vipName Where are this component’s source files?\n\u0026gt; wrtool prj vip component info vipName componentName What is the VIP’s default bootline?\n\u0026gt; wrtool prj vip parameter value vipName DEFAULT_BOOT_LINE Creating New Projects # Create a VSB\nwrtool vxprj vsb create -S -force -bsp bspName -lp64 -cpu cpuName -smp myVSB e.g. bspName = itl_generic, cpuName = NEHALEM Add “-debug” to enable debug symbols Remove “-lp64” for 32-bit VSB\nAdd a VSB Layer\nwrtool vxprj vsb add vsbName layerName Build a VSB\ncd myVSB; make -j 32 Create a VIP\nwrtool vxprj create -smp bspName vipName -profile profileName -vsb vsbName e.g. bspName = itl_generic, profileName = PROFILE_INTEL_GENERIC Add “-debug” to enable debug symbols\nAdd a VIP Component\nwrtool vxprj component add vipName componentName Add a VIP Bundle\nwrtool vxprj bundle add vipName bName\ne.g. bName = BUNDLE_STANDALONE_SHELL\nWhich bundle is added to a VIP ?\nwrtool vxprj bundle list vipName Create a downloadable kernel module (DKM)\nprj dkm create -vsb vsbName dkmName Create a real-time process (RTP)\nprj rtp create -vsb vsbName rtpName Add a File to a Project\nprj file add fileName prjName Add “-link” to link to, not copy the file\nDebugging Drivers # Exploring Exceptions\nINCLUDE_EDR_ERRLOG:\nSTATUS edrShow (int start, int count, int facility, int severity) From the kernel shell:\n-\u0026gt; edrShow() Exploring Fatal Exceptions\nSet a breakpoint in sysToMonitor(). When target breaks, examine the CPU link register to get the calling address. Set a new breakpoint there and re-run. Keep working back till you find the problem. Deferring Driver Startup (VxBus 2 / SR0660 and later)\nINCLUDE_VXBUS_DRIVER_DEFER\nList the driver names to be deferred separated by a colon (:) in VIP parameter VXBUS_DRIVER_DEFER_LIST_STR.\nManually Deferring and Initializing a Network Driver (VxBus 2)\nConvert network driver from static to dynamic driver registration. For example:\nLocate VXB_DRV_DEF (VXB_DRV_structure_name) and comment line out. Create a new function in the driver: void addMyEnetDrv() { vxbDrvAdd(\u0026amp;VXB_DRV_structure_name); } Reboot target and from the kernel shell: -\u0026gt; addMyEnetDrv() -\u0026gt; ipcom_drv_eth_init(“drv_name”, 0, 0) -\u0026gt; ifconfig (“drv_name0 ip_address netmask net- mask up”) VxWorks API Calls # VxWorks Message Queue Library\nINCLUDE_MSG_Q:\nMSG_Q_ID msgQOpen (const char * name, size_t maxMsgs, size_t maxMsgLength, int options, int mode, void * context) STATUS msgQClose (MSG_Q_ID msgQId) MSG_Q_ID msgQCreate (size_t maxMsgs, size_t maxMsgLength, int options) STATUS msgQDelete (MSG_Q_ID msgQId) ssize_t msgQNumMsgs (MSG_Q_ID msgQId) STATUS msgQSend (MSG_Q_ID msgQId, char * buffer, size_t nBytes, _Vx_ticks_t timeout, int priority) ssize_t msgQReceive (MSG_Q_ID msgQId, char * buffer, size_t maxNBytes, _Vx_ticks_t timeout) STATUS msgQInfoGet (MSG_Q_ID msgQId, MSG_Q_INFO * pInfo) VxWorks Pipe I/O Driver\nINCLUDE_PIPES:\nSTATUS pipeDevCreate (const char * name, size_t nMessages, size_t nBytes) STATUS pipeDevDelete (const char * name, BOOL force) STATUS pipeAnonCreate (size_t nMessages, size_t nBytes, unsigned flags, int * pFd) VxWorks I/O Library\nint open (const char * name, int flags, ...) int creat (const char * name, mode_t mode) int remove (const char * name) ssize_t write (int fd, const void * buffer, size_t nbytes) int close (int fd) ssize_t read (int fd, void * buffer, size_t max- bytes) int ioctl (int fd, int function, …) VxWorks Show Routines\nINCLUDE_DOSFS_SHOW:\nSTATUS dosFsShow (void * pDevName, u_int level) INCLUDE_POOL_SHOW:\nvoid poolShow (POOL_ID poolId, int level) INCLUDE_SHOW_ROUTINES:\nSTATUS objShowAll (OBJ_ID objId, int showType) INCLUDE_WATCHDOGS_SHOW:\nSTATUS wdShow (WDOG_ID wdId) INCLUDE_TASK_SHOW:\nSTATUS taskShow (TASK_ID tid, int level) INCLUDE_SYM_TBL_SHOW:\nSTATUS symShow (SYMTAB_ID pSymTbl, char * substr) INCLUDE_STDIO_SHOW:\nSTATUS stdioShow (FAST_FILE * fp, int level) INCLUDE_MODULE_MANAGER:\nSTATUS moduleShow (char * modNameorId, int options) INCLUDE_MEM_SHOW:\nSTATUS memShow (int type) STATUS memPartShow (PART_ID partId, int type) INCLUDE_TASK_SHOW:\nvoid envShow (TASK_ID taskId) INCLUDE_MSG_Q_SHOW:\nSTATUS msgQShow (MSG_Q_ID msgQId, int level) INCLUDE_POSIX_TIMER_SHOW:\nInt timer_show (timer_t timerId, int verbose) INCLUDE_SEM_SHOW:\nSTATUS semShow (SEM_ID semid, int level) INCLUDE_HW_FP_SHOW:\nvoid fppCtxShow (FP_CONTEXT * pFpContext) INCLUDE_EDR_SHOW:\nSTATUS memEdrPartShow (PART_ID partId) INCLUDE_VM_SHOW:\nSTATUS vmContextShow (VM_CONTEXT_ID context) INCLUDE_VXBUS_SHOW:\nvoid vxbDevShow (VXB_DEV_ID pRoot, int toggle) void vxbDrvShow (void)\nINCLUDE_PCI_SHOW:\nvoid vxbPciCtrlShow (void) STATUS vxbPciDeviceShow (VXB_DEV_ID busCtrlID, UINT8 busNo) void vxbPciTopoShow (VXB_DEV_ID busCtrlID) STATUS vxbPciFuncShow (VXB_DEV_ID busCtrlID, UINT8 bus, UINT8 device, UINT8 function) VxWorks Logging and kprintf Library\nINCLUDE_LOGGING:\nint logmsg (char * fmt, _Vx_usr_arg_t arg1, _Vx_usr_arg_t arg2, _Vx_usr_arg_t arg3, _Vx_usr_arg_t arg4, _Vx_usr_arg_t arg5, _Vx_usr_arg_t arg6) INCLUDE_DEBUG_KPRINTF:\nint kprintf (const char * fmt, ...) ssize_t kputs (char * buffer) VxWorks Events Library\nINCLUDE_VXEVENTS:\nSTATUS eventClear (void) STATUS eventReceiveEx (UINT32 events, UINT32 options, _Vx_ticks_t timeout, UINT32 * pEventsReceived) STATUS eventReceive (UINT32 events, UINT8 options, _Vx_ticks_t timeout, UINT32 * pEventsReceived) STATUS eventSend (TASK_ID taskId, UINT32 events) VxWorks Semaphore Library\nINCLUDE_SEM_LIB:\nSEM_ID semBCreate (int options, SEM_B_STATE ini- tialState) SEM_ID semCCreate (int options, int initialCount) SEM_ID semMCreate (int options) SEM_ID semOpen (const char * name, SEM_TYPE type, int initState, int options, int mode, void * con- text) STATUS semClose (SEM_ID semId) STATUS semDelete (SEM_ID semId) STATUS semFlush (SEM_ID semId) STATUS semGive (SEM_ID semId) STATUS semTake (SEM_ID semId, _Vx_ticks_t timeout) ","date":"2025-01-23","externalUrl":null,"permalink":"/bsp/managing-projects-from-the-command-line-interface-for-vxworks-development/","section":"Bsps","summary":"\u003cp\u003eThis article gives introduction to \u003ca href=\"https://www.vxworks6.com/bsp/managing-projects-from-the-command-line-interface-for-vxworks-development/\" target=\"_blank\"\u003emanaging projects from the command-line interface\u003c/a\u003e for VxWorks development.\u003c/p\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eExploring the Environment \n    \u003cdiv id=\"exploring-the-environment\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#exploring-the-environment\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003e\u003cb\u003eSetting the Build Environment\u003c/b\u003e\u003c/p\u003e","title":"Managing Projects From the Command Line Interface for VxWorks Development","type":"bsp"},{"content":"Japan is emerging as a global leader in industrial automation. Japanese original equipment manufacturers (OEMs) are at the forefront of this trend, with unique attention to efficient, intelligent, and automated industrial processes.\nChisa Nakata, president of Wind River® Japan since 2020, has helped Japanese customers with their mission-critical infrastructure across several industries, including aerospace and defense, industrial, medical, and automotive. That’s given her unique insight into the region’s embedded systems and automation development trends.\nWhat industrial automation trends are you paying attention to? # Chisa Nakata: The initial convergence of IT and operational technology (OT) had little effect on industrial automation, but that’s no longer true. In the last five to eight years, embedded automation has adopted edge computing and complex software systems.\nUntil a decade ago, industrial automation systems equipment relied on hardware computer boards with embedded technology that could not be upgraded without changing boards. Industrial automation OEMs kept their equipment the same for 15 to 20 years without updating them, due to heavy cost and new design efforts. Only in the last decade have industrial automation OEMs begun to use software technology in their equipment design to make faster upgrades/updates, and that continues as the OEMs go to their next generation of industrial automation equipment. Japan has been an industrial automation leader for many years, but now it is leading efforts to adopt software and modern software development methods.\nThe new IT/OT convergence fosters synergy across vertical industries, such as real-time collaboration in manufacturing and operations. The result is faster, more efficient decision-making and the creation of new services.\nThe machine economy is gaining momentum. Autonomous machines are improving at communicating, making decisions, and carrying out economic activities independently, without human intervention. This trend has enormous potential.\nFinally, the edge has become a critical area of focus, with DevOps and DevSecOps methodologies changing how edge systems integrate with real-time operations. The explosion of data, the demand for real-time processing at the edge, and network bandwidth limitations are driving significant financial investments. For instance, the global market for edge data centers is expected to grow from $13 billion in 2023 to $39.8 billion by 2030, according to a November 2024 Global Industry Analysts report.\nHow has software development changed? # Software development has a new focus on flexibility, agility, scalability, and automation.\nAgile and DevOps: Agile methodologies and DevOps once were initiatives without corporate buy-in. Today, they are expected. These methodologies proved themselves with rapid, iterative software releases in embedded systems as well as other application domains. Teams work closely to integrate automation tools that speed up development cycles and enhance feedback loops. Everyone agrees on the principles of these long-popular methodologies, but OEM product development teams often encounter difficulties in implementation.\nCloud-native technologies: Cloud-native techniques promise loosely coupled systems that are resilient, manageable, and observable, emphasizing open source and vendor neutrality. The adoption of cloud-native tenets in the embedded development community has resulted in scalable, flexible systems that expand and adapt to business needs.\nAI and automation: Automation has increased the efficiency of software development processes such as testing, deployment, and monitoring, particularly as tools and processes adopt AI and machine learning.\nUser-centric design: Developers are paying more attention to user experience. Software in both general and embedded markets is designed with better interfaces, ease of use, and frequent updates.\nSecurity and DevSecOps: As security demands grow, DevOps is becoming DevSecOps, where security is integrated into every software development lifecycle stage.\nThe result: Companies can (and do) respond faster to market demands, with innovative applications that solve user needs as well as the flexibility to rapidly and easily change production to meet new orders and customer trends.Japan’s industrial automation segment is leading the charge in adopting these advancements by strategically moving away from waterfall methods to DevSecOps.\nIncorporating DevSecOps ensures security from the start of the development process. For example, Omron, a Japanese industrial automation company, streamlined its global software development by sharing a common infrastructure across multiple teams.\nWhich industrial automation market segments are changing fastest? # The industrial automation segment has improved its processes, particularly in Japan. Japan’s global presence in this sector is influenced by the adoption of technologies such as industrial IoT, edge computing, robotics, and AI and machine learning (ML), which make real-time data collection, analysis, and rapid decision-making possible for manufacturing systems. Edge computing processes data closer to where it is generated before sending data to the cloud. That means critical decisions are made faster.\nThe most obvious trend is AI and ML. Japan is adopting AI-based machinery and plant network optimization at 63%. That’s significantly higher than the global rate of 40% adoption as reported by Markets \u0026amp; Markets. AI and ML are having an impact everywhere, of course, but their use in edge computing means industrial systems can make autonomous, accurate, real-time decisions without human intervention. That moves us all closer to the machine economy, where machines communicate and make decisions independently.\nJapan is the second largest global market for industrial robotics, second only to China. Its robotics usage is due to Japan’s manufacturing infrastructure and leadership in automation technologies. One reason for the growth in automation and robotics is Japan’s aging population and declining birthrate, leading to a shortage of Japanese workers. However, a bottleneck for the introduction of industrial robots into new customers is the time required for teaching the system. Software solutions via a DevOps environment using AI are an important element in reducing this teaching time.\nThe use of digital twin technology is also growing in industrial automation. This technology allows companies to create simulations and models of physical systems so that everyone involved understands how the system works before deployment. Many industrial automation companies use digital twins to optimize production and operational processes, with the happy outcome of improved quality and fewer surprises.\nAdditionally, cybersecurity has become more important in industrial automation as systems become more connected. Securing these systems from potential cyberthreats is critical, especially in protecting sensitive data.\nFinally, safety certification is no longer optional; it is essential for developing safety-compliant products in highly regulated sectors. It is also more complex. In the past, certification was simpler because embedded systems had fewer software components and the systems operated in controlled environments. However, with a growing software stack and more critical applications, achieving safety certification now requires more extensive effort.\nHow does Wind River Studio Developer help industrial automation OEMs and developers? # Wind River Studio Developer helps OEMs address critical challenges such as increasing software complexity, edge data management, security, and lifecycle management. It also facilitates modern practices such as DevOps and DevSecOps, which are essential for meeting customer needs.\nStudio Developer supports real-time operating systems and edge computing, offering security, cloud-native development, and ML integration.\nIn Japan, test automation is critical due to the emphasis on quality. Studio Test Automation simplifies the testing process, saving significant time. OEMs are also highly interested in over-the-air (OTA) updates for post-launch software management, making Wind River Studio Developer’s OTA update feature particularly appealing.\nWIND RIVER STUDIO DEVELOPER KEY FEATURES # Wind River Studio Pipelines: Accelerate time-to-market and reduce costs through automation and orchestration of continuous build, test, integration, and deployment.\nWind River Studio Virtual Lab: Speed development cycles with earlier, more frequent and consistent testing. Use uniform, cloud-based management of simulated and physical hardware resources to automate testing and to maximize costly development resources.\nWind River Studio Test Automation: Simplify, expedite, and automate the testing, verification, and validation of embedded operating systems (OS) platforms and applications using cloud-hosted platforms.\nWind River Studio Over-the-Air Updates: Use remote and secure orchestration and automation of multi-device software updates to help manage fleets of devices through the cloud.\nWind River Studio Digital Feedback Loop: Gain real-time analytics and insights from combined OS-level and application-specific data to make data-driven decisions and optimize health, performance, and maintenance of assets deployed at the edge.\nWind River Studio Workspace: Enable instant, on-demand provisioning of preconfigured development environments in your public or private cloud.\nIntroduction to Chisa Nakata # Chisa Nakata has been the president of Wind River Japan since 2020. She has previously headed Wind River Japan distributor sales and the sales department. She has been helping Japanese customers across industries such as aerospace and defense, industrial, medical, and automotive to accelerate their digital transformation with Wind River software, especially for missioncritical infrastructure.\n","date":"2025-01-21","externalUrl":null,"permalink":"/news/japanese-industrial-automation-and-devops-trends/","section":"News","summary":"\u003cp\u003eJapan is emerging as a global leader in industrial automation. Japanese original equipment manufacturers (OEMs) are at the forefront of this trend, with unique attention to efficient, intelligent, and automated industrial processes.\u003c/p\u003e","title":"Japanese Industrial Automation and Devops Trends","type":"news"},{"content":" Executive Summary # Digital transformation offers industrial manufacturers the promise of business advantages and efficiencies through the use of data analytics and advanced control systems. To retain their market position and stay ahead of agile competitors, enterprises are embracing the era of Industrial IoT and investing in new capabilities. But realizing this vision of digital transformation is complex, with many challenges along the path to success. Adding network connectivity to your existing systems introduces more opportunity for cybersecurity threats, while opting to isolate your systems for safety and security reasons can mean missing out on some of the key benefits of IoT.\nThis paper examines how companies can establish a digital transformation strategy, realizing business value by creating data-enabled intelligent systems that are protected from cybersecurity threats while reducing total IoT critical infrastructure lifecycle cost and risk. We will look at the use of virtualization to consolidate core safety-certified applications and non-safe applications, separate IoT communications from legacy applications, and enable huge benefits in the use of advanced technologies to implement IoT capabilities. Finally, we will examine how virtualization can maximize product safety, using various types of partitioning in IoT design that lead to reductions in overall design cost and risk.\nSee how VxWorks® has evolved to be the real-time operating system (RTOS) for IoT, providing the reliability, safety, and security capabilities to successfully power IoT critical infrastructure systems into the future.\nAs the ARC Advisory Group states, “The risk of being a late adopter now exceeds the risk of being an early adopter.”\nThe Opportunity # Across many industries, one common theme is digital business transformation. The rationale for implementing digital transformation is that it will lead to business goals of improved operations, profits, and competitiveness. A Tata Consultancy Services (TCS) 2015 report looking at the impact of IoT technologies, based on a survey of 795 executives from large multinational corporations who already had implemented IoT technologies or solutions, found that 19% of respondents from industrial manufacturing were already seeing more than 30% in revenue gains. Other key findings:\nIn 2014, the average increase in revenue as a result of their IoT investment was 15.6%. Almost 1 in 10 (9%) saw a rise of at least 30% in revenue. The top 8% of respondents, based on ROI from IoT, reported a staggering 64% average revenue gain in 2014 as a direct result of these investments. In the TCS 2015 survey looking at the impact of IoT technologies, executives in the industrial manufacturing sector are reporting the largest increase in revenue from IoT investments, with an average 28.5% ROI.\nLet’s take a look at three key areas of digital transformation enabled by IoT: new approaches to business strategy; increased efficiency, safety, and resource sustainability; and consideration of product lifecycles.\nNew Approaches to Business Strategy\nAs you investigate new and improved revenue streams, look to maximize your customers’ experience by changing your strategy from a product-centric approach to a services approach. The idea is to ensure that you are resilient against digital competition and disruptive new competitors, while providing valuable services to your customers.\nIncreased Efficiency, Safety, and Resource Sustainability\nThe need to increase efficiency requires you to look at how you can continuously improve manufacturing processes and reduce energy and other resource usage, while at the same time ensuring safe manufacturing processes.\nConsideration of Product Lifecycles\nIoT is driving digital transformation by providing connected intelligent devices. For your company to be successful in connecting to the IoT, key decision makers like you must do more than recognize the general opportunity that is inherent in the digital transformation trend. You need to identify specific products, services, and business models that can drive “profitable outcomes” for example, improving your customer engagement and experience, product or technology innovation, or business or product efficiency; or transforming your business entirely.\nPart of this process is to determine what data must be gathered to drive these outcomes and enable better business decisions. In other words, the data being generated and the purposes it serves must add value to both you and your customers. Solutions that are simply intriguing without justifying their cost to your customers will not provide you long-term market traction, and implementations that are not profitable will not drive business success. Likewise, you need to look at how possible solutions fit into your overall company IoT strategy, and charting your IoT course requires defining offerings that are a suitable fit within the rest of your business.\nUntil this point, the discussion has focused on designing new critical infrastructure systems and services to fulfill a business need. But sometimes you need consider how to migrate and manage your legacy critical infrastructure systems to connect to the IoT, since these systems may not have been designed for the IoT era due to their traditionally long product lifecycle. And it is just too expensive to build from scratch an entirely new IoT critical infrastructure system. As Table 1 shows, businesses planning to connect to IoT must consider the longer lifecycles for critical infrastructure, future system obsolescence, and the ability to periodically update both the software application and the underlying hardware platforms.\nTable 1. Typical lifecycle of devices The Business Drivers\nImproving operational efficiency and productivity are the most critical business drivers among manufacturers moving into the IoT. In order to implement systems that fulfill these requirements and provide positive business outcomes, you need data-enabled intelligent systems that are protected from cybersecurity threats and are more affordable.\nFigure 1. Benefits of IIoT: Industrial Internet of Things drivers Data-Enabled Intelligent Systems\nYour ultimate goal is to have all systems connected to the overall IoT environment, so that you can make business decisions based on the big-picture analysis of that data. Although this sounds simple, it is usually slower to implement than originally predicted, and there are other consequences that you need to consider as well. First, the data volume involved is substantial, so it is useful to do some preprocessing of data before the transition. This allows you to choose which data to transmit and preformat if needed. Second, you are now connecting systems to the network, and that exposes you to cybersecurity threats.\nFigure 2. The expanding digital universe, 2013–2020 As our goal is to collect data from all systems, those that have a functional safety requirement are included. These systems control machines that could cause injury or death in the event of a software or hardware failure. In these cases, government regulations man- date certain requirements. A good example of these can be found in IEC 61508, which defines “functional safety of electrical/electronic/ programmable electronic safety-related systems.” Any additional code added to these systems to data-enable them could be costly due to the test and validation requirements of these regulations.\nFunctional safety is the part of overall safety that depends on a system or equipment operating correctly in response to its inputs. It includes the detection of a potentially dangerous condition, resulting in the activation of a protective or corrective device or mechanism to prevent hazardous events arising or to provide mitigation to reduce the consequence of the hazardous event.\nProtection from Cybersecurity Threats\nGiven the goals of digital transformation, you know your organization will use data to make business decisions, so any impact on the validity of that data could lead to unwanted circumstances. Data becomes the most important part of your system and so must be protected from cyberattacks, as with any other asset. This leads to the second requirement: cybersecurity.\nConnecting devices to the Internet, or to systems that connect to the Internet, will expose them to threats and vulnerabilities that they originally were not designed to cope with. However, cybersecurity is now vital throughout the life of the system, and therefore mechanisms should be provided to address cybersecurity throughout the life of the device, including remote monitoring and updates for already-deployed devices.\nGreater Affordability\nManaging costs for software development projects has always been challenging, mainly because the capability or feature required tends to expand during the development process. For IoT systems, this challenge expands to include devices that have been out in the field for many years. This is because your goal is to generate revenue from these devices through a service-based model, so you must consider lifecycle costs, including how to diagnose, fix, and update their software.\nThis drives new technologies and software architecture changes to allow for these updates and to maintain security protection. Typically, embedded systems are developed for a single purpose: to control a machine, for example, or operate a safety feature. Often this is handled by a single block of code, fully integrated into the system’s hardware. This can be difficult to maintain, update, and enhance with new capabilities without a complete rewrite of the software.\nGiven the need to improve efficiencies, there is a trend toward consolidation of these systems onto a single, more powerful platform running a virtual machine to host “applications.” These platforms support use of virtualization and multi-core processors to provide flexible, high-performance systems that can lower lifecycle costs and improve operational expenses by allowing easy maintenance, updating, and management of software applications.\nThe data collected and analyzed can also change throughout the device lifecycle (this often occurs following analysis of the overall system data), requiring additional data to be collected or requiring the frequency of collection to change. This depends on the ability to rapidly adapt or expand existing applications, through adaptable applications or update services. These advanced services and updates can also be used to maintain device security.\nVirtualization of safety functions also allows a consolidation strategy to isolate them from the connectivity and control of IoT. This means you can maintain functional safety aspects while simultaneously providing the back-office connectivity needed to fulfill your IoT requirements.\nSolutions for implementing IoT Systems # In order to solve these challenging requirements, businesses need to consider new approaches to system level architecture and use the latest technology. Systems must not only meet the data-enabled intelligent systems requirement for IoT but also provide reduced lifecycle costs, while remaining safe and secure. Add in the existing requirements of scalability and modularity to cover the broad range of devices and sensors needed across systems as well as the continuing need for absolute reliability and the need for a new approach is clear.\nVxWorks supports the broadest spectrum of 32-bit, 64-bit, and multi-core processors, including Arm®, Intel®, and Power® architectures. Its portfolio of additional middleware and advanced technology components, as well as a large ecosystem of validated complementary third-party hardware and software solutions, enables you to differentiate your platforms with best-of-breed capabilities, and provide systems that can meet the demands of the Internet of Things.\nThe Foundation of Data-Enabled Intelligent Systems\nThe operating system is the foundation for enabling intelligent systems and has to provide real-time performance because it is controlling expensive, long lifecycle equipment (often with human life dependencies) and cannot afford to miss any deadlines. VxWorks is a fully deterministic real-time operating system that has been deployed in the industry controlling embedded systems for nearly 40 years.\nTo provide value, you need connectivity to ensure that the data from such systems is transmitted reliably over a variety of protocols to where it’s needed. With VxWorks, right out of the box you have the support of industry-leading connectivity standards and networking protocols such as CAN and Ethernet, the MQTT IoT connectivity middleware protocol, and high-performance networking capabilities such as Precision Time Protocol (PTP) and Time-Sensitive Networking (TSN). Through the vast VxWorks partner ecosystem, you can add additional protocols such as Bluetooth, ZigBee, Wi-Fi, DDS, and CoAP, among others. The modular nature of VxWorks also allows you to add connectivity and networking capabilities after the fact, so you can bring many previously disconnected devices online without reworking the core of your embedded software.\nCompatible Software and Hardware Ecosystem\nIn addition to delivering rock-solid real-time performance and other cutting-edge features, an RTOS for IoT must support a broad ecosystem of tested and verified complementary hardware and software solutions. This broad feature set delivered by VxWorks and its ecosystem of compatible third-party applications is essential to enabling you to create a differentiated product offering and secure a sustainable competitive advantage. VxWorks delivers the most exhaustive library of off-the-shelf board support packages, allowing you to begin development immediately, with your project leveraging significant COTS technology. This means you can focus on differentiating your product offering with leading-edge features and capabilities, accelerate your time-to-market through rapid, lower-risk integration using best-in-class third-party technology, and cut costs by deploying systems integrated and validated out of the box.\nThe edge devices in IoT are also likely to be very small scale, due to cost and power constraints. But these devices still require the security and connectivity offered by VxWorks in order to satisfy IoT requirements.\nCybersecurity Protection\nAs described, data-enabled intelligent systems must be designed, built, and deployed with security in mind, as pervasive IoT connectivity exposes them to increasingly numerous and complex threats. The software platform for IoT provides the flexibility to design embedded systems to the necessary level of security by leveraging a comprehensive set of built-in features covering all areas where IoT data is touched:\nDesign Boot Data in use Data in transit Data at rest Table 2. VxWorks RTOS IoT security VxWorks supports these security features not only to protect against malware and unwanted or rogue applications but also to deliver secure data storage, data transmission, and tamper-proof designs. OS-level support for these features is critical, since adding them at the user or application level is ineffective, expensive, and risky. Security threats and vulnerabilities evolve and become more complex over time. VxWorks adapts to this complex threat scenario and supports the secure upgrade, download, and authentication of applications to help keep your devices secure throughout their lifecycle.\nCreating More Affordable Systems\nOver the years, VxWorks has driven many systems that have a long lifecycle, usually in fixed static roles, running single functions or driving single devices. In an IoT environment, you need to be able to update and manage these systems as well as support your legacy applications already deployed. A gateway can act as an interface between legacy and IoT systems, protecting the earlier investment; or you can consider a partial migration through the use of virtualization technology and new multi-core processors.\nVirtualization allows creation of virtual machines that can efficiently isolate and duplicate the computing requirements of legacy and new applications. This can support migration of legacy applications and also future-proof your platform by providing the ability to upgrade applications. This capability provides a method of isolating applications, which enables the following:\nSupport for legacy applications Isolation of functional safety code Isolation of data for security Application sandbox for future capabilities Figure 4. Migrating your legacy system to IoT securely with virtualization When combined with modern multi-core processors, this capability also provides the performance necessary to run both new capabilities and legacy applications, without loss of performance.\nAdvanced Real-time Capabilities # In the previous section, we discussed how VxWorks can help satisfy the basic requirements of IoT systems, meeting the demands of digital transformation to provide business value. But is this enough? You need to consider that these devices will be deployed in the field for many years, and requirements could change. To help with your IoT needs going forward, VxWorks provides advanced real-time capabilities that can help future-proof your designs.\nSafety While Enabling Connectivity to the IoT\nSafety is paramount in many embedded operating systems, because they control machines that can endanger life, or whose malfunction can cause injury or death. Although well established in aerospace, medical, and industrial markets, regulators are now applying safety standards to new markets, such as the automobile and energy industries. Additionally, better applications of existing standards are being sought for such systems as smart grid meters and medical devices. As standards evolve, manufacturers increasingly look to Wind River to deliver the appropriate capabilities to more easily obtain required safety and security certifications for their end products.\nOf course, these safety features and requirements also have to be evaluated against the required benefits of IoT, and against increased security threats. Safety must remain the highest-priority requirement, as these systems could endanger human lives.\nFor manufacturers of industrial control and automation systems that require IEC 61508 functional safety certification, auto manufacturers that require ISO 26262 ASIL D hazard and risk assessment, or avionics manufacturers that require DO-178C DAL A safety certification, VxWorks Cert Edition and its optional certification evidence packages deliver a rich real-time operating environment that enables flexible system design options and reduces cost, risk, and lead time for full system certification.\nMulti-core\nAs embedded systems grow in complexity and capability, and as the need increases for cost-reducing consolidation, multi- core processors are becoming the platform of choice. VxWorks delivers comprehensive multi-core processor support, including asymmetric multiprocessing (AMP) and symmetric multiprocessing (SMP) OS configurations and hardware-optimized multi-core acceleration.\nThe VxWorks 653 Multi-core Edition COTS platform enables even greater flexibility in harnessing the power of multi-core, as well as additional consolidation options to reduce size, weight, and power (SWaP) consumption.\n64-bit Processing\nMany embedded systems today have already reached the limitations of 32-bit processors, especially when implementing a strategy of consolidation using virtualization, and so the 64-bit processor era is emerging. VxWorks supports the broadest spectrum of 64-bit and multi-core silicon architectures, including Arm, Power, and Intel architectures.\nConclusion # Digital transformation and the Internet of Things require you to build data-enabled intelligent systems, but also to provide reduced lifecycle cost and risk while retaining safety and security. Reliability, scalability, and modularity are also vital for an IoT RTOS to cover the broad range of devices and sensors that you require across your IoT systems.\nThe VxWorks RTOS product family supports the broadest spectrum of processors. Its portfolio of additional middleware and advanced technology components, as well as a large ecosystem of validated complementary third-party hardware and software solutions, enables you to differentiate your platforms with best-of-breed capabilities and provide systems that meet the demands of the Internet of Things.The RTOS of the future is here now: VxWorks gives you, as a manufacturer of embedded systems, a competitive edge in the world of IoT by enabling you to bring industry-leading devices to market faster, while reducing development and maintenance costs and project risk.\n","date":"2025-01-15","externalUrl":null,"permalink":"/industries/the-rtos-as-the-engine-powering-iot-critical-infrastructure/","section":"Industries","summary":"\u003ch2 class=\"relative group\"\u003eExecutive Summary \n    \u003cdiv id=\"executive-summary\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#executive-summary\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eDigital transformation offers industrial manufacturers the promise of business advantages and efficiencies through the use of data analytics and advanced control systems. To retain their market position and stay ahead of agile competitors, enterprises are embracing the era of Industrial IoT and investing in new capabilities. But realizing this vision of digital transformation is complex, with many challenges along the path to success. Adding network connectivity to your existing systems introduces more opportunity for cybersecurity threats, while opting to isolate your systems for safety and security reasons can mean missing out on some of the key benefits of IoT.\u003c/p\u003e","title":"The RTOS as the Engine Powering IoT Critical Infrastructure","type":"industries"},{"content":" INDUSTRIAL SYSTEM CHALLENGES # Develop modern, software-defined systems Satisfy real-time performance requirements Lower the cost of safety certification Implement better security to safeguard systems Why VxWorks # Leading RTOS with cutting-edge features and developer tools Proven track record in safety-critical applications Various safety certifications Built-in support for the latest security technologies Industry Snapshot # Global competition makes it critical for industrial system manufacturers to refresh their products, some of which are 15–20 years old, to make them more flexible and easier to upgrade and patch through software updates than legacy, fixed hardware systems. They also need software developers who know the latest programming and tools and can continuously improve product security, safety, and reliability. Add to this list the need to enable easy software updates, remain price competitive, and, in some cases, minimize the time and cost of certifying systems.\nSuccess requires agility and innovation, and this is why Wind River® invests heavily in its VxWorks® real-time operating system (RTOS). VxWorks delivers hard real-time performance, determinism, and low latency along with the scalability, security, and safety required for industrial applications, such as robotics, control automation, manufacturing and transportation systems. It is the world’s most widely used commercial RTOS, with more than 35 years in the field and billions of deployments.\nVXWORKS: PIVOTAL TO SUCCESS # Utilize Modern Software Development Techniques and Tools # The new crop of software developers wants to use the modern programming languages and tools they learned in school, not to have to train on old or proprietary software environments. This is why VxWorks leverages low-level virtual machine (LLVM) as a tools foundation to support current popular languages and libraries such as C++17, Rust, Boost libraries, and Python 3.8. Developers can be productive on Day One, not needing to know what’s under the hood of VxWorks.\nIncrease Reliability with Safety Software Protection # Many connected industrial systems require an RTOS that offers flexibility and scalability while maintaining the determinism and low latency required by mission- and safety-critical applications. One of the ways VxWorks achieves high reliability is by enforcing time and space partitioning, which can isolate safety-critical and non-safety-critical code, helping to prevent reliability and performance issues due to unintended interactions between applications. For instance, the enhanced scheduler implements time partitioning to prevent applications from overloading the CPU, and space partitioning isolates user-mode application memory from kernel-mode memory.\nReduce Cost and Risk with a Pre-certified RTOS # When developing safety-critical systems, avoid the cost and time associated with creating the binaries and artifacts needed to certify the RTOS you’re using. VxWorks Cert Edition provides all the information you need to obtain a range of certifications, including IEC 61508 SIL 3, DO-178C DAL A, ISO 26262 ASIL D, and IEC 62304. Since VxWorks is certified for various standards, system manufacturers do not have to retest or recertify the code for those standards areas for which VxWorks has been certified thus saving time and money and speeding up the development process. Furthermore, the RTOS code has been thoroughly vetted by more than 600 safety certification programs over the last 20 years.\nSecure Data and Systems from Boot-Up to Power Down # Every day new security threats arise, making it critical to have a strategy for safeguarding systems, software, network connections, and data. To address rising threats from the growth of connected devices, VxWorks comes with comprehensive security capabilities, such as a hardened kernel, secure communications, and data protection. Design your embedded system to the necessary level of security at every stage of operation: boot-up, app execution, data transmission, idle, and power down.\nTRUSTED SOFTWARE SOLUTIONS # VxWorks and its tools suite provide industrial system developers with a complete solution for transforming the most demanding environments. With more than 30 years of experience building safe and secure embedded systems, Wind River is well versed in satisfying the real-time requirements of industrial applications and enabling the next generation of highly competitive systems.\nVxWorks has been chosen by global industry leaders as the trusted foundation to power billions of safety-critical intelligent devices, machines, and systems. Currently running on the Red Planet on the InSight Mars lander, VxWorks is the secure, safe, reliable, and certifiable RTOS for medical infusion pumps and imaging systems, energy production automation, manufacturing robots, train control systems, and other safety-critical devices in the Internet of Things.\n","date":"2025-01-11","externalUrl":null,"permalink":"/industries/vxworks-for-industrial/","section":"Industries","summary":"\u003ch2 class=\"relative group\"\u003eINDUSTRIAL SYSTEM CHALLENGES \n    \u003cdiv id=\"industrial-system-challenges\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#industrial-system-challenges\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDevelop modern, software-defined systems\u003c/li\u003e\n\u003cli\u003eSatisfy real-time performance requirements\u003c/li\u003e\n\u003cli\u003eLower the cost of safety certification\u003c/li\u003e\n\u003cli\u003eImplement better security to safeguard systems\u003c/li\u003e\n\u003c/ul\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eWhy VxWorks \n    \u003cdiv id=\"why-vxworks\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#why-vxworks\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eLeading RTOS with cutting-edge features and developer tools\u003c/li\u003e\n\u003cli\u003eProven track record in safety-critical applications\u003c/li\u003e\n\u003cli\u003eVarious safety certifications\u003c/li\u003e\n\u003cli\u003eBuilt-in support for the latest security technologies\u003c/li\u003e\n\u003c/ul\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eIndustry Snapshot \n    \u003cdiv id=\"industry-snapshot\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#industry-snapshot\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eGlobal competition makes it critical for industrial system manufacturers to refresh their products, some of which are 15–20 years old, to make them more flexible and easier to upgrade and patch through software updates than legacy, fixed hardware systems. They also need software developers who know the latest programming and tools and can continuously improve product security, safety, and reliability. Add to this list the need to enable easy software updates, remain price competitive, and, in some cases, minimize the time and cost of certifying systems.\u003c/p\u003e","title":"VxWorks for Industrial","type":"industries"},{"content":" VxWorks for Automotive: RTOS for ADAS and Safety-Critical Systems\n🚗 Automotive Industry Snapshot # The automotive industry is rapidly evolving toward connected, electrified, and autonomous systems. This shift significantly increases software complexity and compute demands, requiring robust embedded platforms capable of handling mixed-criticality workloads.\nModern vehicles must balance:\nHigh-performance computing for AI and ADAS Deterministic real-time behavior for safety-critical control Strict isolation between system components Constraints on cost, power consumption, and system weight As artificial intelligence becomes integral to vehicle operation, traditional safety models based on fixed-function systems are being redefined. New architectures must ensure that data-driven systems behave predictably and meet deterministic safety expectations.\n⚠️ Automotive Challenges # Maintain high reliability despite increasing system complexity Reduce space, weight, cost, and power consumption Lower safety certification costs and effort Guarantee deterministic real-time performance Implement end-to-end cybersecurity Increase computing flexibility and scalability 🧠 Why VxWorks # VxWorks is a mature, production-proven RTOS designed for safety-critical environments. It provides the foundational capabilities required for modern automotive platforms.\nKey Advantages # Strong time and space isolation for mixed-critical workloads Workload consolidation to reduce hardware footprint Pre-certified components for safety compliance Integrated security architecture Broad support for processors and BSP ecosystems With over 30 years of deployment and billions of devices shipped, VxWorks delivers predictable, low-latency performance required in automotive systems.\n🚀 VxWorks: Pivotal to Automotive Success # 🔒 Protect Safety-Critical Code from Compute-Intensive Workloads # ADAS and AI-based applications demand significant compute resources. Without proper isolation, these workloads can interfere with critical control functions.\nVxWorks addresses this through:\nTime partitioning: Guarantees CPU allocation per task Space partitioning: Isolates memory regions between applications This ensures that safety-critical tasks maintain deterministic execution regardless of system load.\n🔄 Reduce System Complexity with Workload Consolidation # Traditional automotive architectures often assign one ECU per function, leading to inefficient hardware usage.\nVxWorks supports consolidation through virtualization:\nMultiple workloads run on a single multi-core platform Safety-critical and general-purpose systems coexist Reduced hardware, wiring, and maintenance costs When combined with virtualization platforms, VxWorks enables both static (safety-focused) and dynamic (general-purpose) partitioning strategies.\n📜 Accelerate Certification with ASIL D Compliance # Safety certification is a major cost driver in automotive development.\nVxWorks is certified to:\nISO 26262 ASIL D Benefits include:\nReduced validation effort Pre-certified components (e.g., networking stack) Faster time-to-market Supported applications:\nAutonomous driving ADAS Digital instrument clusters Telematics systems In-vehicle infotainment (IVI) ⚡ Deliver Deterministic Real-Time Performance # VxWorks achieves predictable execution through architectural separation:\nCore kernel runs independently from optional subsystems Reduced jitter and latency Enhanced scheduler enforces strict CPU allocation This guarantees bounded response times required by safety-critical automotive functions.\n🔐 Strengthen Automotive Cybersecurity # Connected vehicles are increasingly exposed to cybersecurity threats. VxWorks provides built-in protections across the system lifecycle:\nSecure boot chain Trusted Platform Module (TPM) integration Data encryption and secure communication Kernel hardening and memory protection Security is enforced from power-on through runtime and shutdown.\n🧩 Enable Flexible Hardware Selection # Automotive platforms span a wide range of performance and cost requirements. VxWorks supports diverse processor architectures and vendors:\nArm PowerPC Intel x86 NXP, Renesas, Xilinx platforms This flexibility enables:\nRapid prototyping Optimized cost-performance tradeoffs Scalable deployment across vehicle segments 🏁 Trusted Software Foundation # VxWorks, combined with Wind River’s tools and ecosystem, provides a comprehensive platform for developing next-generation automotive systems.\nWith decades of experience in safety-critical embedded software, VxWorks enables developers to:\nBuild deterministic and reliable systems Meet strict safety and certification requirements Secure connected vehicle platforms Scale across evolving automotive architectures As vehicles continue to evolve into software-defined platforms, VxWorks remains a proven foundation for delivering safe, secure, and high-performance automotive systems.\n","date":"2025-01-06","externalUrl":null,"permalink":"/industries/vxworks-for-automotive-rtos-for-adas-and-safety-critical-systems/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks for Automotive: RTOS for ADAS and Safety-Critical Systems\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🚗 Automotive Industry Snapshot \n    \u003cdiv id=\"-automotive-industry-snapshot\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-automotive-industry-snapshot\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThe automotive industry is rapidly evolving toward connected, electrified, and autonomous systems. This shift significantly increases software complexity and compute demands, requiring robust embedded platforms capable of handling mixed-criticality workloads.\u003c/p\u003e","title":"VxWorks for Automotive: RTOS for ADAS and Safety-Critical Systems","type":"industries"},{"content":" VxWorks Solutions Have Been Used in More than 600 Safety Certification Programs by More than 350 Customers Across Industries\nSector Challenges # Reduce development costs across multiple projects Streamline regulatory compliance Satisfy real-time performance requirements Implement robust system and data security Simplify software integration Manage risks associated with obsolescence of components throughout the product lifecycle Hire talented software developers Why VxWorks # Software reuse and portability support Comprehensive packages of certification evidence Hard real-time performance, determinism, and low latency Best-in-class, pre-integrated security capabilities Secure application software isolation Modern software development environment Industry Snapshot # With most governments aiming to streamline procurement processes and spending, aerospace and defense OEMs are feeling the pressure to cut costs. One avenue is to maximize software reuse. Another costsaving opportunity is to reduce the resources and time needed for system certification. Despite ever-increasing system complexity, key requirements still need to be met, such as delivering real-time performance, securing systems against escalating security threats, safely integrating software from a wide variety of sources, and recruiting enough software developers to get the job done right and on time.\nThese challenges and others are why many companies turn to Wind River®. With more than 25 years of experience in space missions and more than 35 years in the aerospace and defense market, Wind River solves the challenges of developing today’s modern systems by relying on a legacy of successful projects and ongoing product innovations. VxWorks®, the most widely deployed real-time operating system (RTOS), rode on a NASA probe as part of one of the avionics packages—a star scanner—that helped keep the spacecraft Clementine on course. VxWorks is also part of many active space-bound projects, including NASA’s InSight Mars lander.\nWind River invests heavily in its VxWorks software portfolio, adding new features while maintaining its very high level of security, safety, and reliability.\nFigure 1. VxWorks: The number-one commercially deployed RTOS VxWorks: Pivotal to success # Save Money by Protecting Software Investments # One of the biggest investments in most aerospace and defense systems is in application software, so finding ways to reuse it in future systems can significantly reduce development costs. To maximize portability, VxWorks is designed to be backward compatible; therefore, the lat- est version is capable of running applications written for earlier releases.\nStreamline Certification with Pre-certified RTOS # Using a pre-certified RTOS can significantly reduce the effort and cost to certify safety-critical applications running on avionics and defense systems. Likewise, VxWorks Cert Edition provides all the information needed to obtain a range of certifications, including EN 50128, IEC 61508 SIL 3, ISO 26262 ASIL-D, DO-178C DAL A, ED-12C, and IEC 62304. When using a subset of the VxWorks code base, developers can easily run validation and obtain proof of test, giving them certification evidence. VxWorks Cert Edition also includes expanded support for ARINC 653 (Part 1, Supplement 4; Part 2, Supplement 3), extended services, symmetric multiprocessing (SMP) guests, and FACE™ 3.0 for the safety base and security profiles.\nDeliver Proven Real-Time Performance # Real-time performance is crucial for safety-critical sys- tems, such as a digitally connected aircraft that requires deterministic and low-latency performance. Leading the industry in this area for more than 25 years, Wind River has provided NASA with the most proven software platform to bring dozens of unmanned systems to space. VxWorks has been certified in more than 600 safety programs and more than 100 civilian and military aircraft, demonstrating the performance, determinism, reliability, safety, and security capabilities needed to satisfy the highest standards for mission-critical systems.\nIn addition, VxWorks has enhanced real-time features for the Portable Operating System Interface (POSIX®), Precision Time Protocol (PTP), and Time-Sensitive Networking (TSN).\nProtect Systems and Data from Boot-Up to Shutdown # Digitally connected systems increase the risk of malicious hacking, requiring avionics and defense OEMs to carefully consider system and data security at various product life phases, including design, testing, and ongoing maintenance. Designed with comprehensive, built-in security capabilities, VxWorks safeguards devices and data during boot-up, app execution, data transmission, idle, and power down. Developers can implement protec- tion at every stage of operation by taking advantage of secure boot, data encryption, kernel hardening, updated OpenSSL, enhanced Trusted Platform Module (TPM2), trusted software stacks TSS, tools for optimizing security, and many other features.\nPrevent Ill-Behaving Software from Compromising Performance # Many avionics and defense systems have a mix of safety- critical and non–safety-critical applications—some homegrown and others from third parties. Helping to prevent reliability and performance issues due to unin- tended interactions between applications, the enhanced scheduler in VxWorks prevents any single application from overloading the CPU, thus keeping applications from overusing shared computing resources.\nInspire Software Developers with Modern Tools and Ease Engineering Onboarding # There is fierce competition for talented software develop- ers who want to apply the latest techniques they learned in school and not be forced to use outdated software environments. VxWorks can help attract software devel- opers by leveraging low-level virtual machine (LLVM) as a tools foundation to support current popular languages and libraries such as C++17, Rust, Boost libraries, and Python. One can easily write high-performance, safety- critical code in a modern language without knowing the inner workings of VxWorks.\nTRUSTED SOFTWARE SOLUTIONS # VxWorks and its tools suite provide system developers with a complete solution for developing advanced and innovative solutions. With more than 30 years of experience building safe and secure embedded systems, Wind River is well versed in satisfying the real-time requirements of the aerospace and defense industry and enabling the next generation of computing technology.\n","date":"2025-01-05","externalUrl":null,"permalink":"/industries/vxworks-for-aerospace-and-defense/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Solutions Have Been Used in More than 600 Safety Certification Programs by More than 350 Customers Across Industries\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eSector Challenges \n    \u003cdiv id=\"sector-challenges\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#sector-challenges\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eReduce development costs across multiple projects\u003c/li\u003e\n\u003cli\u003eStreamline regulatory compliance\u003c/li\u003e\n\u003cli\u003eSatisfy real-time performance requirements\u003c/li\u003e\n\u003cli\u003eImplement robust system and data security\u003c/li\u003e\n\u003cli\u003eSimplify software integration\u003c/li\u003e\n\u003cli\u003eManage risks associated with obsolescence of components throughout the product lifecycle\u003c/li\u003e\n\u003cli\u003eHire talented software developers\u003c/li\u003e\n\u003c/ul\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eWhy VxWorks \n    \u003cdiv id=\"why-vxworks\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#why-vxworks\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eSoftware reuse and portability support\u003c/li\u003e\n\u003cli\u003eComprehensive packages of certification evidence\u003c/li\u003e\n\u003cli\u003eHard real-time performance, determinism, and low latency\u003c/li\u003e\n\u003cli\u003eBest-in-class, pre-integrated security capabilities\u003c/li\u003e\n\u003cli\u003eSecure application software isolation\u003c/li\u003e\n\u003cli\u003eModern software development environment\u003c/li\u003e\n\u003c/ul\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eIndustry Snapshot \n    \u003cdiv id=\"industry-snapshot\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#industry-snapshot\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eWith most governments aiming to streamline procurement processes and spending, aerospace and defense OEMs are feeling the pressure to cut costs. One avenue is to maximize software reuse. Another costsaving opportunity is to reduce the resources and time needed for system certification. Despite ever-increasing system complexity, key requirements still need to be met, such as delivering \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003ereal-time\u003c/a\u003e performance, securing systems against escalating security threats, safely integrating software from a wide variety of sources, and recruiting enough software developers to get the job done right and on time.\u003c/p\u003e","title":"VxWorks for Aerospace and Defense","type":"industries"},{"content":"","date":"2025-01-04","externalUrl":null,"permalink":"/tags/medical/","section":"Tags","summary":"","title":"Medical","type":"tags"},{"content":"","date":"2025-01-04","externalUrl":null,"permalink":"/tags/medtech/","section":"Tags","summary":"","title":"Medtech","type":"tags"},{"content":" Proven, Secure, Safe, Reliable, and Certifiable RTOS\nMEDICAL SECTOR CHALLENGES # Accelerate next-generation device time-to-market Meet stringent regulation compliance requirements Drive modern software development capabilities and tools Satisfy real-time medical application requirements Simplify and speed up software updates Implement robust cybersecurity WHY VXWORKS # Mature, proven, and compre- hensive RTOS solution IEC 62304 medical device software certification Modern tools and support for modern development languages OCI container support for ease in deployment of software Guaranteed latency and determinism Medical device update support Best-in-class, pre-integrated security capabilities INDUSTRY SNAPSHOT # The medical technology (medtech) industry, which includes devices for diagnosis of health conditions, patient care, medical treatment, and health improvement, went through 10 years of major innovation and growth prior to 2019, according to McKinsey’s report “Medtech Pulse: Thriving in the Next Decade” (2023). Medtech is working to bring further innovation and value to hospitals, healthcare, patient care, and the home to result in a new period of medical and healthcare advancements across the world.\nMedical device manufacturers and the medtech industry are changing from “doing digital” to “being digital.” Rather than trying to update medical tech- nology and devices to digital, Deloitte notes, now new medical technology must be digital from the original design, tying together hardware, software, and the healthcare ecosystem (“Navigating the Future of the Medtech Industry”). Software is the major growth factor in medical innovation, with data analytics, artificial intelligence, machine learning, and the adoption of modern software development processes and tools. This is driving medi- cal advancements such as the growth of digital robotic surgery, diagnostic imaging, radiotherapy devices, remote patient monitoring, and more for patients in medical facilities and at home.\nThe ongoing challenges continue to be decreasing time- and cost-to- market; certification of systems to meet safety and security mandates; and systems update processes to meet regulatory requirements and to keep patients alive, safe, and secure. On the software side, many of the needs for new innovative medical technology, such as digital robotic surgery and automated treatment responses, require real-time and deterministic per- formance. For example, a surgical robot must be able to reactively restrict where scalpel cuts are made based on preoperative programming by the surgeon. Next-generation device designs are driven more by a software than a hardware focus, so that new capabilities and improved treatment methods can be quickly implemented. To accomplish this, software developers need modern software programming methods and tools. In addition to real-time and deterministic performance, they need the flexibility and the power of technologies such as containerization, AI, machine learning, and new programming languages.\nVXWORKS: PIVOTAL TO SUCCESS # To equip medical technology and device manufacturers to resolve these challenges, Wind River® invests heavily in its VxWorks® real-time operating system (RTOS), adding new features and maintaining its high level of security, safety, and reliability. VxWorks delivers hard real-time performance, determinism, and low latency, along with the scalability required for medical applications. It is the first RTOS to utilize OCI containers, and it supports the widest range of modern programming languages. It is the world’s most widely used commercial RTOS, with 40+ years in the field and billions of deployments.\nFASTER TIME-TO-MARKET WITH A MODERN RTOS PLATFORM\nShortening time-to-market and lowering costs is one key to success for medtech and medical device manufacturers. On average, it takes three to seven years to bring a new medical device to market, a period that device manufacturers are striving to reduce. VxWorks Cert Edition helps shorten two of the longer phases, software development and device certification, by providing modern languages and tools and pre-certification of safety standards. For example, VxWorks Cert Edition is pre-certified for medical applications — e.g., IEC 62304 — as well as for safety-critical applications in other industries, such as IEC 61508 SIL 3, DO-178C DAL A, and ISO 26262 ASIL-D.\nREAL-TIME PERFORMANCE\nFor medical devices, reliable response time is key to providing effective procedures and treatment for patients. Reaction time for many medical devices, such as surgical robots, MRI/CAT scanners, and blood filters, is critical to ensure patient health and safety. The VxWorks enhanced scheduler can guarantee that safety-critical applications have sufficient CPU cycles and memory for latency and determinism. This capability helps prevent a faulty application from adversely impacting the rest of the platform.\nMODERN SOFTWARE DEVELOPMENT TOOLS\nWith more focus on software to design next-generation medical devices, modern software programming methods and tools are required to gain a competitive advantage. To enable leading-edge software development, VxWorks leverages low-level virtual machine (LLVM) as a tools foundation to support current popular languages and libraries such as C++17, Rust, Boost libraries, and Python for more efficiency. VxWorks is also the only RTOS supporting application deployment with OCI container support. Developers benefit from the continuous feature and performance optimizations made in VxWorks to support the most advanced processors and SoCs.\nAPPLICATIONS DEPLOYED AT THE SPEED OF IT\nAs the only RTOS supporting OCI container support, VxWorks can package and deploy all applications using IT-like tools and methods. This easily allows the management and deployment of software on VxWorks, leveraging existing cloud infrastructure. Medtech and medical device manufacturers can push their applications to standard container registries (such as Docker Hub, Amazon ECR, or Harbor) and pull them from deployed VxWorks-based devices. Native support for kubelets enables VxWorks-based devices to be seen as nodes in a Kubernetes cluster so that the containers in deployed pods are running and healthy, vastly improving device management in the near and far edge.\nSIMPLIFIED DELIVERY OF SOFTWARE UPDATES\nWith the introduction of 5G wireless technology and more devices being connected to networks, the FDA and other regula- tory agencies are mandating quick and timely software updates to address software issues and bugs that impact medical device safety and security. VxWorks, Wind River Helix™ Virtualization Platform and the VxWorks OCI container capability, and Wind River Studio Over-the-Air (OTA) Updates enable manufacturers and their medical and healthcare customers to update firmware and software safely and promptly through the simple and cost-effective creation of update functions.\nUpdating and testing functions can be loaded into virtual machines that isolate them so they cannot negatively impact other application workloads, helping to improve the safety and reliability of the system. Update deployments can be automated and timed to occur during device downtime, with rollbacks possible when updates do not complete correctly.\nDECREASED DEVICE CERTIFICATION COST AND RISK\nMedical device certification helps provide required assurance that safety and security are built into a device to safeguard patients and their health. Certification is a complex process, especially for device manufacturers introducing new medi- cal functions with real-time requirements. To help streamline certification processes, VxWorks Cert Edition provides documentation (e.g., binaries and artifacts) for inclusion in IEC 62304 compliance-related vendor qualification and for use in premarket submission to the FDA and other international regulatory offices. This follows the FDA guidance in “Off- the-Shelf Software Use in Medical Devices” and “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software,” as well as IEC 62304 software of unknown provenance (SOUP) requirements.\nPERSISTENT DATA AND DEVICE PROTECTION\nThe increase in device connectivity risks elevating the risk of malicious hacking, with potentially threatening consequences for privacy and life. With deep concern for patient safety and security, the FDA has issued strict guidance on cybersecurity for medical devices. To assist device manufacturers and address growing security threats, VxWorks integrates an extensive and continuously evolving set of security capabilities that safeguard device and data during powerup, app execution, data transmission, idle, and power down. Capabilities such as secure boot, Trusted Platform Module (TPM), data encryption, and kernel hardening allow developers to implement protection at every stage of operation.\nTRUSTED SOFTWARE SOLUTIONS\nVxWorks and its tools suite provide medical device developers with a complete solution for developing advanced and innovative solutions. With more than 40 years of experience building safe and secure embedded systems, Wind River is well versed in satisfying the real-time requirements of the medical technology industry and enabling the next generation of highly competitive medical devices.\n","date":"2025-01-04","externalUrl":null,"permalink":"/industries/vxworks-for-medical/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003eProven, Secure, Safe, Reliable, and Certifiable RTOS\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eMEDICAL SECTOR CHALLENGES \n    \u003cdiv id=\"medical-sector-challenges\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#medical-sector-challenges\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eAccelerate next-generation device time-to-market\u003c/li\u003e\n\u003cli\u003eMeet stringent regulation compliance requirements\u003c/li\u003e\n\u003cli\u003eDrive modern software development capabilities and tools\u003c/li\u003e\n\u003cli\u003eSatisfy real-time medical application requirements\u003c/li\u003e\n\u003cli\u003eSimplify and speed up software updates\u003c/li\u003e\n\u003cli\u003eImplement robust cybersecurity\u003c/li\u003e\n\u003c/ul\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eWHY VXWORKS \n    \u003cdiv id=\"why-vxworks\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#why-vxworks\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMature, proven, and compre- hensive RTOS solution\u003c/li\u003e\n\u003cli\u003eIEC 62304 medical device software certification\u003c/li\u003e\n\u003cli\u003eModern tools and support for modern development languages\u003c/li\u003e\n\u003cli\u003eOCI container support for ease in deployment of software\u003c/li\u003e\n\u003cli\u003eGuaranteed latency and determinism\u003c/li\u003e\n\u003cli\u003eMedical device update support\u003c/li\u003e\n\u003cli\u003eBest-in-class, pre-integrated security capabilities\u003c/li\u003e\n\u003c/ul\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eINDUSTRY SNAPSHOT \n    \u003cdiv id=\"industry-snapshot\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#industry-snapshot\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThe medical technology (medtech) industry, which includes devices for diagnosis of health conditions, patient care, medical treatment, and health improvement, went through 10 years of major innovation and growth prior to 2019, according to McKinsey’s report “Medtech Pulse: Thriving in the Next Decade” (2023). Medtech is working to bring further innovation and value to hospitals, healthcare, patient care, and the home to result in a new period of medical and healthcare advancements across the world.\u003c/p\u003e","title":"VxWorks for Medical","type":"industries"},{"content":" Abstract # The main objective of a scheduler in a hard real-time system is that tasks are finished before their deadline. A secondary objective is to do this as effective as possible. This comparison will look into how the two well known hard real-time systems; VxWorks and LynxOS handle the CPU scheduling problem. This comparison will also look into reason to why some problems are solved in similar ways and why some are solved in different ways.\nIntroduction # The CPU scheduling problem in hard real-time systems consists of a few smaller problems, to most of the problems there is a few standardised robust solutions all with their pros and cons. With this knowledge we can assume that the solutions will be quite similar and the differences will depend on the fact that the two products to some extent have different definitions of what are the most important things in a real-time operating system. The algorithms that we describe for each of the real-time operating systems will be described as clear as possible so we can see the differences that are expected to be quite small. Also reason for these differences will be explained as clearly as possible. Another interesting side of this comparison is if there are any significant differences that can be important to take into consideration when choosing a hard real-time operating system for a project with real-time requirements.\nLynxOS # The details of the algorithms presented here are based on version 4.2 of LynxOS which conceptually should be the same as version 4.0 but with minor improvements and bug fixes.\nThe scheduler of LynxOS is preemptive and priority based, this is that the current process is preempted as soon as a higher priority thread is ready to run. If two or more processes have the same priority there is three different ways of handling this; Round-robin, Quantum and FIFO. Round-robin is when all processes get small time-slices of the processor over and over again until all processes is completed. Quantum is very similar to round-robin the only difference is that the length of the time-slice is not fixed; it is a variable for each priority level. FIFO is the first-in-first-out principle that let the processes run until completion; the run order is determined by the time a process became ready to run. The scheduler works with a total of 512 priority levels, 256 for user tasks and 256 for kernel threads.\nThe LynxOS scheduler schedules both user tasks and kernel tasks together. The kernel tasks are called kernel threads. Kernel threads usually are handlers of different device drivers and their interrupts. Because interrupts have the highest priority in the system they will preempt and block any user task running until the interrupt handler has completed. So having fast interrupt-processing is very important for having a responsive real-time system. So if interrupt handlers can be reduced to spawning kernel threads and then having them scheduled as any other task this will improve system correctness. The main problem with interrupts that take long time to complete is that they might be working for a low priority user task and by working in a interrupt they will steal time from higher priority tasks. By using kernel threads the drawbacks of interrupt handling can be reduced to a minimum. This is because the processing time used on the behalf of other tasks than the highest priority task is reduced to a minimum.\nBecause user tasks often rely on the work of device drivers they should not block device drivers that it need, this is not having higher priority than the device driver. Still device drivers should not have too high priority so that they block user tasks that are more important than a particular device driver. LynxOS solves this problem with what is called priority tracking. Priority tracking is the method for dynamically changing the priority of kernel threads so that they have a slightly higher priority than the user task with the highest priority that is waiting for the kernel thread. This is done by having one extra priority level attached to every user task priority level and treating that extra level as higher than its parent but lower than the user priority level above the parent. In practice this is done by having 512 priorities where even priority numbers are used by user tasks and odd priority numbers are used for kernel threads. The mapping of the 256 user tasks priorities to the internal 512 priorities is done by simply multiplying the user task priority by two.\nA multiprogramming environment needs synchronization mechanisms, LynxOS mainly rely on semaphores, disabling of interrupts and disabling of preemption. Semaphores are used to protect resources by only letting one process at a time work with a resource and having all other process waiting for it to complete. The process with the highest priority that is waiting on the semaphore will be the next to have access to the protected resource. This is the basics of semaphores which introduce a problem with a priority based scheduler; the problem is known as priority inversion. Priority inversion occurs when a resource is held by a low priority task when a high priority task needs the same resource, what happens is that the high priority task have to wait for all processes with higher priority than the low priority task that\nholds the resource. This will have the effect that the high priority task will have the same priority as the low priority task while the low priority task holds the resource. The solution to this problem is to give the low priority task the same priority as the high priority task until it releases the resource; this is known as priority inheritance. Priority inheritance will enforce that processes is run in the order of priority as much as possible. Also disabling of interrupts and preemption can be used to protect resources. If interrupts and preemption is disabled during the critical-section that uses a resource the access to the resource will be atomic; which will ensure a predictable usage of the resource. Even though it is safe to disable interrupts and preemption to access a critical-section this should be avoided because it might introduce unwanted delays for interrupts, this is especially true when a critical-section is takes long time to execute. This kind of blocking is even worse when a low priority process blocks the whole system; the main reason to why this is so bad is that it severely violates the prioritization.\nWhen using two or more semaphores there is a risk for so called dead locks, this occurs when two process want to use the same semaphores and does it in different order. What can happen is that process one holds resource A and process two holds resource B, while both gets to a state where they are waiting for the resource held by the other process. This situation can be solved in two ways either by some dead lock detection and recovery method or requiring that semaphores always is accessed in the same order when multiple semaphores is needed.\nLynxOS rely on that semaphores always are accessed in the same order in all processes. So there is a risk for dead locks with this approach, but it can only happen if the software running is badly written, but if software is well written (dead lock free at least) everything should work well. The upside of not having dead lock detection and recovery is that there will be no processing overhead and the system should still be dead lock free as long as software is written correctly.\nVxWorks # VxWorks is a commercial real time OS and are the most popular RTOS in the world for embedded systems. It is used widely in many different embedded systems like in automobiles, switches and routers and also in two rovers exploring Mars since 2004. The OS was created at Wind River in the early 1980s and are now 20 years later in use in an estimate of more than 350 million devices around the world.\nVxWorks is centered around the Wind microkernel. The microkernel has a very little footprint. In VxWorks are processes and threads both refered as tasks. The task model of VxWorks consists of four states: READY, PEND, DELAY and SUSPEND.\nFigur 1 Task model states of VxWorks [4].\nThe VxWorks microkernel uses priority based scheduling with two types of scheduling models with 256 priority levels: preemptive and nonpreemptive round-robin (RR) scheduling. Priority 0 is highest and 255 is the lowest. When a task with a higher priority is ready to run the current task running is preempted. The lower priority tasks context is saved and the kernel loads the context of the new task. In preemptive priority based scheduling the FCFS rule is used when tasks with the same priority want to use the CPU while in RR ready tasks with the same priority share the CPU equally.\nRR solves the problem with several tasks of same priority wanting to get hold of the CPU. The Round Robin method uses time-slicing to equally share the CPU among tasks with the same priority level. Each task belongs to a group of tasks with the same priority and each of the groups has a defined time slice for CPU-allocation. When a task has consumed its time slice the CPU is relinquished to another ready task in the priority group and the old task moves to the tail of the group queue. This ensures that all tasks of the same priority are allowed to run before a task gets another time slice. When a task is pre-empted by a higher\npriority task while it is running in its time slice interval the time count is saved before the context switch so it later can be restored to allow the low priority task to consume the remaining of its time slice.\nThe scheduler of VxWorks can be explicitly disabled and enabled by the programmer if desired. Interrupt- and preempt locks, and semaphores with priority inheritance are used for synchronization. Semaphores are the fastest method for synchronization and VxWorks provides not only the Wind Semaphores but also the POSIX semaphores for portability reasons.\nSimilarities # The algorithms and solutions used in both operating systems that are similar will be listed here together with some kind of explanation to why both systems use the same solution.\nBoth systems has chosen to use a preempting priority-based scheduler, also the available policies for tasks with the same priority is almost the same the only difference is that LynxOS has the Quantum policy which is very similar to round-robin that both systems support, so the difference is neglect able. The reason to why both systems solve this problem in basically the same way is because this solution gives the best CPU utilization in most cases compared to other known robust scheduling solutions.\nDifferences # The only major difference between the two systems scheduling methods seems to be dynamic time-slicing in LynxOS which VxWorks don’t use.\nConclusion # VxWorks and LynxOS have very similar scheduling algorithms, the differences are few and where they differ the effects of the differences are in most cases small to neglect able. This isn’t that surprising because both products is supposed to be very high quality hard real-time operating systems and to achieve top performance and quality it looks like it isn’t much room for differences in this type of CPU scheduling. This can be view as there isn’t any clear reason to choose one or another of these two operating systems when building a hard real- time operating system when considering the scheduling of the operating system. But there might of course be a clear choice if taking other aspects in to consideration that this report doesn’t take into consideration.\nReferences # Wind River: https://www.windriver.com VxWorks Net: https://www.vxworks.net By Henrik Carlgren, Ranjdar Ferej\n","date":"2025-01-01","externalUrl":null,"permalink":"/app/comparison-of-cpu-scheduling-in-vxworks-and-lynxos/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003eAbstract \n    \u003cdiv id=\"abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThe main objective of a scheduler in a hard real-time system is that tasks are finished before their deadline. A secondary objective is to do this as effective as possible. This comparison will look into how the two well known hard real-time systems; \u003ca href=\"https://www.vxworks.net\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e and LynxOS handle the CPU scheduling problem. This comparison will also look into reason to why some problems are solved in similar ways and why some are solved in different ways.\u003c/p\u003e","title":"Comparison of CPU Scheduling in VxWorks and LynxOS","type":"app"},{"content":"","date":"2025-01-01","externalUrl":null,"permalink":"/tags/cpu-scheduling/","section":"Tags","summary":"","title":"CPU Scheduling","type":"tags"},{"content":"","date":"2025-01-01","externalUrl":null,"permalink":"/tags/lynxos/","section":"Tags","summary":"","title":"LynxOS","type":"tags"},{"content":"","date":"2024-12-10","externalUrl":null,"permalink":"/tags/cortex-a53/","section":"Tags","summary":"","title":"Cortex A53","type":"tags"},{"content":" VxWorks real-time operating system (RTOS) is a small deterministic operating system known for its security, reliability, and robustness. Linux, an open-source operating system, can host a rich set of server technologies. By running VxWorks and Linux side by side on the same system, a device can use VxWorks to manage mission-critical functions, and use Linux to manage human-interactive functions and network cloud connection functions. Guest blog written by Ka Kay Achacoso.\nVxWorks has been running alongside Linux for years now over several virtualisation technologies. Wind River Virtualisation Profile includes a hypervisor that can host Linux, Windows, and other OSes alongside VxWorks as guest OSes. On Intel architectures, VxWorks can run unmodified on KVM, VMware, Oracle Virtual Box, and the Xen Project Hypervisor.\nOn ARM Cortex A53, beyond the Wind River Virtualisation Profile, the latest hypervisor to host VxWorks alongside with Linux is the Xen Project Hypervisor, an open-source virtualisation platform from the Linux Foundation. DornerWorks enables the Xen Project Hypervisor to run on the Xilinx Zynq UltraScale+ MPSoC in their release of Virtuosity (formerly Xen Zynq Distribution).\nWind River has partnered with DornerWorks to provide a Xen Project Hypervisor solution for VxWorks and Linux on the Xilinx Zynq ZCU102 evaluation board.\nWith VxWorks and Linux running on the same system, developers can create hybrid devices like one that can collect sensor data, process the data, and then host a web server for small data visualisation. As a quick experiment with the new Xen solution on ARM Cortex A53, I use a simple example of VxWorks processing audio input to detect hand-clapping rhythms, and Ubuntu hosting a web server that displays the rhythms detected.\nFigure 1. Device example: A hand-clapping rhythm is analysed by the device. Analysis results are available via a web server on the device. Software Structure # The DornerWorks Xen solution runs Xilinx Petalinux as the domain 0 guest OS that serves as a launching point for all other guest OSes, which are called domains in Xen terms. Thus, when Xen first boots up, Petalinux starts up right away. From the Petalinux shell, the VxWorks and Ubuntu guest OSes is launched.\nXen provides a virtual network to its guest OSes that bridge to the physical network interface and out to external networks. Both VxWorks and Ubuntu have drivers that connect to the virtual network. VxWorks and Ubuntu communicate with each other over this virtual network, and connect to external networks through the bridged connection.\nIn this example, VxWorks runs signal processing and spectrum analysis applications. The results are compiled into a JSON string and sent through the virtual network to Ubuntu. On Ubuntu, the Apache2 HTTP server sends results to a browser using Node.js and Chart.js to format the data display.\nFigure 2. Software block diagram of VxWorks and Linux guest OSes running on Xen. Development Process # Virtuosity, which is Xen for Xilinx Zynq UltraScale+, is easily downloaded from DornerWorks website. The instructions to boot up the Xilinx Zynq board into Xen and its domain 0 Petalinux are well documented in the manual downloaded from the same page.\nVirtuosity comes with an Ubuntu 14.04 LTS distribution that can run as a guest OS, and the documentation describes how to start up this guest OS. The default Xen domain configuration file is then modified for Ubuntu to increase its memory in order to install the extra software components onto Ubuntu.\nVxWorks guest OS runs on top of the downloaded unmodified Virtuosity. To create the guest OS, we use the VxWorks board support package for Virtuosity available in VxWorks Core or VxWorks Plus. The process is pretty much the same as creating a VxWorks OS binary image for any other hardware. Once the VxWorks guest OS binary image is copied into the domain 0 Petalinux file system and a simple VxWorks-Xen domain configuration file is created, VxWorks guest OS is easily launched from the shell.\nResults # The end result of this simplified experimentation demonstrates VxWorks as a real-time sensor application and Ubuntu Linux as a server application, with communication between the two running over virtual network. When hands clap a certain rhythm, the browser connected to the device displays the clapping rhythm. Figure 3 shows the clapping rhythm of the theme song for popular British television series Sherlock.\nFigure 3. Web page served by Ubuntu HTTP server displaying the rhythm of the Sherlock theme as detected by VxWorks. With Xen as an additional virtualisation option for VxWorks, device developers using ARM Cortex A53 based hardware can take advantage of the deterministic real-time properties of VxWorks and the human interface and networking capabilities of Linux.\nAdditional information about VxWorks is available here. For Virtuosity, see DornerWorks. Xen hypervisor information is available at the Xen Project website.\nCourtesy of Wind River.\n","date":"2024-12-10","externalUrl":null,"permalink":"/bsp/vxworks-on-xen-on-arm-cortex-a53/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks real-time operating system (RTOS) is a small deterministic operating system known for its security, reliability, and robustness. Linux, an open-source operating system, can host a rich set of server technologies. By running VxWorks and Linux side by side on the same system, a device can use VxWorks to manage mission-critical functions, and use Linux to manage human-interactive functions and network cloud connection functions.\nGuest blog written by Ka Kay Achacoso.\u003c/p\u003e","title":"VxWorks on Xen on Arm Cortex A53","type":"bsp"},{"content":"","date":"2024-12-10","externalUrl":null,"permalink":"/tags/xen/","section":"Tags","summary":"","title":"Xen","type":"tags"},{"content":"","date":"2024-12-09","externalUrl":null,"permalink":"/tags/network/","section":"Tags","summary":"","title":"Network","type":"tags"},{"content":" Introduction # VxWorks Networking # Network programming allows users to: Build services. Create distributed applications. VxWorks network programming tools: Berkeley sockets. zbuf Socket API. Sun RPC (Remote Procedure Call). Network Components # Ports # Abstract destination point within a node. TCP/UDP intertask communication: Data is sent by writing to a remote port. Data is received by reading from a local port. Packet Encapsulation # Sockets # Socket Overview # Programmatic interface to internet protocols. Protocol specified when socket created (e.g., UDP or TCP). Server binds its socket to a well known port. Client’s port number dynamically assigned by the system. Ports # Socket address consists of: An internet address (node socket is on). A port number (destination within that node). Port identified by a short integer. VxWorks port usage conventions: ```bash * 0 - 1023 Reserved for system services (e.g.,rlogin, telnet, etc.). * 1024 - 5000 Dynamically allocated. * \u003e 5000 User defined. ``` Unique to each machine and protocol. Socket Address # Generic socket address: struct\tsockaddr { u_short\tsa_family;\t/* address family */ char\tsa_data[14];\t/* protocol specific address data */ }; Socket address structure used by Internet Protocol: struct sockaddr_in { short\tsin_family;\t/* AF_INET */ u_short\tsin_port;\t/* port number */ struct\tin_addr sin_addr;\t/* internet address */ char\tsin_zero[8];\t/* padding, must be zeroed out */ }; VxWorks supports only Internet sockets.\nNetwork Byte Ordering # Fields in the struct sockaddr_in must be put in network byte order (big-endian). Macros to convert long/short integers between the host and the network byte ordering: htonl( ) host to network long. htons( ) host to network short. ntohl( ) network to host long. ntohs( ) network to host short. Caveat - User Data # To send data in a system independent way: Sender converts data from its system-dependent format to some standard format. Receiver converts data from the standard format to its system-dependent format. The standard format used must handle: Any standard data types used (e.g., int, short, float, etc.). Data structure alignment. One such facility, XDR, will be discussed in the RPC section of this chapter. Creating a Socket # int socket (domain, type, protocol) domain Must be PF_INET. type Typically SOCK_DGRAM (UDP) or SOCK_STREAM (TCP). protocol Socket protocol (typically 0). Opens a socket (analogous to open( ) for files). Returns a socket file descriptor or ERROR. Binding a Socket # To bind a socket to a well known address: STATUS bind (sockFd, pAdrs, adrsLen) sockFd Socket descriptor returned from socket() pAdrs Pointer to a struct sockaddr to which to bind this socket adrsLen sizeof (struct sockaddr) Typically only called by server Example Server Stub # 1 #define PORT_NUM (USHORT)5001; 2 struct sockaddr_in myAddr; 3 int mySocket; 4 ... 5 mySocket = socket (PF_INET, SOCK_DGRAM,0); 6 if (mySocket == ERROR) 7 return (ERROR); 8 9 bzero (\u0026amp;myAddr, sizeof (struct sockaddr_in)); 10 myAddr.sin_family\t= AF_INET; 11 myAddr.sin_port\t= htons (PORT_NUM); 12 myAddr.sin_addr.s_addr = INADDR_ANY; 13 14 if (bind (\tmySocket, (struct sockaddr *)\u0026amp;myAddr, 15 sizeof (myAddr)) == ERROR) 16 { 17 close (mySocket); 18 return (ERROR); 19 } UDP Sockets Programming # UDP Socket Overview # Sending Data on UDP Sockets # int sendto (sockFd, pBuf, bufLen, flags, pDestAdrs, destLen) sockFd Socket to send data from pBuf Address of data to send bufLen Length of data in bytes flags Special actions to be taken pDestAdrs Pointer to struct sockaddr containing destination address destLen sizeof (struct sockaddr) Returns the number of bytes sent or ERROR. Receiving Data on UDP Sockets # int recvfrom (sockFd, pBuf, buflen, flags, pFromAdrs, pFromLen) sockFd Socket to receive data from. pBuf Buffer to hold incoming data. buflen Maximum number of bytes to read. flags Flags for special handling of data. pFromAdrs Pointer to struct sockaddr. Routine supplies internet address of sender. pFromLen Pointer to integer. Must be initialized to sizeof (struct sockaddr). Blocks until data available to receive. Returns number of bytes received or ERROR. TCP Sockets Programming # TCP Socket Overview # TCP is connection based (like making a phone call). Concurrent servers are often implemented: TCP Server Overview # 1 /* master server */ 2 masterFd = socket (PF_INET, SOCK_STREAM, 0) 3 /* fill in server’s sockaddr struct */ 4 bind (...) /* bind to well-known port */ 5 listen (...) /* configure request queue */ 6 FOREVER 7 { 8 clientFd = accept (masterFd, ...) 9 taskSpawn (..., slaveSrv, clientFd, ...) 10 } 1 /* slave server */ 2 slaveSrv(clientFd, ...) 3 { 4 read (clientFd, ...) /* read request */ 5 serviceClient () 6 write (clientFd, ...) /* send reply */ 7 close (clientFd) 8 } TCP Client Overview # 1\t/* TCP Client */ 2 fd = socket (PF_INET, SOCK_STREAM, 0) 3 4 /* fill in sockaddr with server’s address */ 5 6 connect (fd, ...) /* request service */ 7 8 write (fd, ...) /* send request */ 9 read (fd, ...) /* read reply */ 10 11 close (fd) /* terminate connection */ Server Initialization # Before accepting connections, server must: Create a socket (socket( )). Bind the socket to a well known address (bind( )). Establish a connection request queue: STATUS listen (sockFd, queueLen) sockFd Socket descriptor returned from socket( ). queueLen Nominal length of connection request queue. Accepting Connections # int accept (sockFd, pAdrs, pAdrsLen) sockFd Servers socket (returned from socket( )). pAdrs Pointer to a struct sockaddr through which the client’s address is returned. pAdrsLen Pointer to length of address. Blocks until connection request occurs. Returns new socket file descriptor (connected to the client) or ERROR. Original socket, sockFd, is unconnected and ready to accept other connection requests. Requesting Connections # To connect to the server, the client calls: STATUS connect (sockFd, pAdrs, adrsLen) sockFd Client’s socket descriptor. pAdrs Pointer to server’s socket address. adrsLen sizeof (struct sockaddr) Blocks until connection is established or timeout. Returns ERROR on timeout or if no server is bound to pAdrs. Exchanging Data # read()/write() may be used to exchange data: Caveat: TCP is stream oriented. write( ) may write only part of message if I/O is nonblocking. read( ) may read more or less than one message. Cleaning up a Stream Socket # When done using a socket, close( ) it: Frees resources associated with socket. Attempts to deliver any remaining data. Causes read( ) from peer socket to return 0. Can also use shutdown( ) to terminate output, while still receiving data from peer socket. Setting Socket Options # Options can be enabled on a per socket basis, including: Don’t delay write( )’s to coalesce small TCP packets. Enable UDP broadcasts. Linger on close( ) until data is sent. bind( ) to an address already in use. Change the size of the send/receive buffers. Consult UNIX man pages on setsockopt( ) for details. To make a socket non-blocking: int val = 1; /* Set to 0 for blocking I/O */ ioctl (sock, FIONBIO, \u0026amp;val); zbuf Socket API # Improves application performance by minimizing data copies through buffer loaning. Application must manage buffers. zbuf application can communicate with a standard socket application. Supports TCP and UDP protocols. See zbufLib and zbufSockLib for details. Proprietary API. RPC # RPC Overview # RPC (Remote Procedure Call) provides a standard way to invoke procedures on a remote machine. For more information about RPC, see: Appendix. TCP/IP Illustrated Volume I (Stevens). Power Programming with RPC (O’Reilly \u0026 Associates). Documentation and source code can be found in wind/target/unsupported/rpc4.0 RPC Client - Server Model # VxWorks and rpcgen # rpcgen is a RPC protocol compiler. From a specification of the remote procedures, rpcgen creates: A client stub. A server stub. The XDR routines for packing/unpacking data structures. Not created if all parameters/return values are standard data types. A header file for inclusion by client and server. Each VxWorks task accessing RPC calls using code produced by rpcgen must first initialize access. STATUS rpcTaskInit( ) Summary # Transport layer network Protocols: ```c TCP Stream-oriented, reliable port-to-port communication. UDP Packet-oriented, non-reliable port-to-port communication. ``` Sockets as the interface to network protocols: UDP transport protocol TCP transport protocol Configurable socket options zbuf socket API. Client/server programming strategies for distributed applications. ","date":"2024-12-09","externalUrl":null,"permalink":"/app/vxworks-network-programming/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003eIntroduction \n    \u003cdiv id=\"introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\n\n\u003ch3 class=\"relative group\"\u003eVxWorks Networking \n    \u003cdiv id=\"vxworks-networking\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#vxworks-networking\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eNetwork programming allows users to:\n\u003cul\u003e\n\u003cli\u003eBuild services.\u003c/li\u003e\n\u003cli\u003eCreate distributed applications.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003eVxWorks network programming tools:\n\u003cul\u003e\n\u003cli\u003eBerkeley sockets.\u003c/li\u003e\n\u003cli\u003ezbuf Socket API.\u003c/li\u003e\n\u003cli\u003eSun RPC (Remote Procedure Call).\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\n\n\u003ch3 class=\"relative group\"\u003eNetwork Components \n    \u003cdiv id=\"network-components\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#network-components\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h3\u003e\n\u003cp\u003e\n    \u003cfigure\u003e\n      \u003cimg class=\"my-0 rounded-md\" loading=\"lazy\" src=\"./network-component.png\" alt=\"Network Components\" /\u003e\n      \n    \u003c/figure\u003e\n\u003c/p\u003e","title":"VxWorks Network Programming","type":"app"},{"content":"","date":"2024-10-07","externalUrl":null,"permalink":"/tags/altera/","section":"Tags","summary":"","title":"Altera","type":"tags"},{"content":" Purpose of this Article # This article describes how to take a VxWorks® bootrom that is built using the Wind River® BSP, alt_soc_gen5, combine it with a preloader built from an Altera® FPGA design, and boot the Altera Cyclone® V and Arria® V SoC development boards using QSPI or SD/MMC.\nNote: This document does not cover how to configure or build the Altera preloader or VxWorks bootrom. What is Needed to Build this System # The following is needed to build this system:\nAn Altera Cyclone V or Arria V SoC development board to run the software. A Wind River workbench development environment and license to build the VxWorks bootrom. An SD/MMC card to hold the boot software for SD/MMC or help program QSPI. Alternatively, you can use the Altera Quartus programmer to program QSPI instead of programming through the SD/MMC. The Win32 Disk Imager program to write the image to an SD/MMC card. You can also use the Linux program dd, but be careful with the device name. You can download the Windows tool from the Sourceforge® website. This package contains pre-built binaries to get started, including:\nPrebuilt SD/MMC images for Cyclone V and Arria V development boards. Prebuilt preloader images for both QSPI and SD/MMC and for both Cyclone V and Arria V development boards. Prebuilt version of the linux utility mkimage for Windows, used to wrap the VxWorks bootrom with the proper header. This release also contains a script, make_sdimage.sh, to help create a new SD/MMC image on a linux system.\nThese instructions are tested with, the following:\nAltera Cyclone V SoC Revision C development board Wind River Workbench version 3.3.4 and VxWorks versions 6.9.3.2 alt_soc_gen5 BSP from Wind River, version 6.9/1 Altera SoC EDS, version 14.0 Altera Quartus Programmer, version 14.0 Ubuntu 12.04 LTS, running as a virtual machine on Windows using Oracle’s® VirtualBox® 4.2.6 with VBoxGuestAdditions installed to share files between Windows and Linux The mkimage binary and all of the preloader binaries are built from GPL licensed open source software included with Altera’s SoC EDS product. This product and the source can be downloaded for free from the Altera Software Depot download page.\nRelated Information\nWin32 Disk Imager Altera Software Depot website Instructions on booting VxWorks # In order to boot VxWorks, you can use these instructions to build a bootable system using a preloader and u-boot, and then replace the u-boot bootloader with a VxWorks bootrom.\nFor SD/MMC boot: You can use the pre-built SD/MMC images to create a bootable system using u-boot in place of the VxWorks bootrom to see your board boot. You can then replace the provided u-boot bootloader with a VxWorks bootrom and see VxWorks boot using the same SD card. For QSPI boot: You can use the provided SD/MMC images to boot u-boot, then use u-boot to program the binaries into QSPI. You can then boot from QSPI. Note: Optionally, you can program QSPI binaries using the Altera Quartus programmer. This method does not require SD/MMC but does require a USB Blaster connection and the free Altera programmer. What is New for 14.0 # The preloader has a new feature that allows you to program the FPGA. These instructions contain SD images with a preloader that programs the FPGA on boot from a FAT partition on the SD card. This makes FPGA programming much easier.\nNote: All preloaders and bootloaders are updated so that they can be built with the Altera 14.0 tools. Configuring the Altera Cyclone V Development Board # Set up the board as shown in the Factory Default Switch and Jumper Settings section located in chapter 3: Development Board Setup, in the Cyclone V SoC Development Kit User Guide.\nIn particular, ensure that SW2 and SW3 are set correctly, they are important to FPGA programming.\nIf you position the development board so that you can read the \u0026ldquo;ALTERA\u0026rdquo; logo on the board, SW2 should have the settings right-right-left-right, reading from the top. If you plan to program the FPGA, SW3 (MSEL) should have all switches set to the positions up-down- up-down-up-up, reading from left to right. Note: These MSEL switch positions are related to how the FPGA is built, either with or without compres‐ sion and in a particular format. Related Information\n*Factory Default Switch and Jumper Settings\nHow the Boot Process Works # The Altera SoC product goes through different boot stages, shown below:\nFigure 1: VxWorks Boot Flow The BootROM is hard coded into the chip and cannot be changed. Upon boot, the BootROM loads the preloader into on-chip RAM, and hands control to it after loading. This BootROM is not the same as the VxWorks BootROM, which is often refered to in the Wind River documentation as \u0026ldquo;bootrom\u0026rdquo;.\nThe second phase of the boot process is the preloader. The preloader completes the initial boot sequence, by setting up the clocks, the external RAM, and the pin configuration of the Altera SoC device. The preloader finishes initial configuration and then loads the VxWorks bootrom into external RAM. It then hands control to the VxWorks bootrom or some other bootloader like u-boot. The preloader can also program the FPGA.\nThe VxWorks bootrom then loads the VxWorks application into external RAM, and hands control of the system to the final application.\nAbout the VxWorks BootROM and Preloader # Both the preloader and the VxWorks bootrom can be built from source and must include a header portion that allows the previous boot stage to validate each boot stage. This package contains prebuilt versions of the preloader for the Cyclone V and Arria V SoC development boards that were built using Altera’s SoC EDS environment.\nThe preloader is typically built by the FPGA designer. This person determines the correct PIN configura‐ tion using Altera’s Quartus and Qsys tools, designs the FPGA portion of the system, and generates the preloader using the preloader Generator, which is part of Altera’s SoC EDS tools.\nThe VxWorks bootrom is built by a software engineer using Wind River\u0026rsquo;s development tools. This engineer configures the VxWorks BootROM and builds it in Wind River’s tool, then uses mkimage from Altera\u0026rsquo;s SoC EDS to put the proper header on the bootrom. For the Cyclone V and Arria V boards, the preloader is board specific and the VxWorks BootROM is not.\nThe preloader and bootrom are then combined into an SD/MMC image or programmed into QSPI to boot the system.\nThe Altera SoC EDS tool includes a pre-configured preloader that works with Altera’s development board. Custom boards may require their own preloader configured for their board.\nSuggested Ways to Build the VxWorks BootROM # There are two standard ways of building the VxWorks BootROM:\nUse the Command Line BootROM Build a BootROM from a VxWorks Image Project (VIP) Use the Command Line BootROM # Build the default bootrom from the BSP.\nOpen a VxWorks 6.9 Development Shell from within Workbench. In the shell, change to the Wind River install directory. Entercd vxworks_6.9/target/config/alt_soc_gen5 at the prompt. Build the default bootrom by entering: make bootrom.bin. For this method, the starting address used with mkimage should be something other than the starting address of the binary. This bootrom uncompresses itself to RAM, so it is best to load it somewhere else in memory so that it can be uncompressed to the starting address. For our testing, we used the value 0x08000040 with mkimage.\nBuild a BootROM from a VxWorks Image Project # Create a VxWorks Image Project and build it.\nCreate a VxWorks Image Project with the profile PROFILE_BOOTAPP. Set the build spec to default_rom. Build the vxworks.bin target in the project. Use the vxWorks_rom.bin file in the default_rom build directory in the project. For this method, the starting address used with mkimage should be the address shown when you run objdump -f on the vxworks_rom file in the same directory. For our testing, this value is 0x3f000000.\nBoth of these binaries still need to be wrapped using the mkimage program described in the following sections before they can be used with the preloader.\nBoth of these binaries properly initialize RAM with boot values so that you can change boot parameters and then use them to start vxWorks.\nCustom Preloader Settings Used for VxWorks # These instructions contain preloaders built from Altera’s SoC EDS tool, version 14.0. You do not have to build the preloader if you plan to use the included binaries, but the source to the preloader and the mkimage program are included in the SoC EDS.\nThe sofware can be downloaded from the Altera Software Depot webpage using the free web edition.\nYou can select and download just the SoC EDS. If you plan to program QSPI using the USB Blaster connection on the development board, you may wish to also install the Quartus II Programmer and SignalTap II software.\nThe pre-built preloaders included in this package work with the Altera development boards. Other boards may require starting with an FPGA design, as described in the HPS Preloader User Guide section of the Altera SoC Embedded Design Suite User Guide.\nOn Windows, you can get to the preloader code through a windows command shell by starting an Altera command shell from: Start \u0026gt; All Programs \u0026gt; Altera \u0026lt;version\u0026gt; \u0026gt; SoCEmbedded Design Suite (EDS) \u0026lt;version\u0026gt; \u0026gt; SoCEDS 14.0 Command Shell.\nThis will start a shell with two important variables:\nQUARTUS_ROOTDIR='C:\\altera\\14.0\\qprogrammer' SOCEDS_DEST_ROOT=C:/altera/14.0/embedded The preloader is located at $SOCEDS_DEST_ROOT/examples/hardware/cv_soc_devkit_ghrd/software/preloader/.\nNote: Several changes were made to the standard preloader configuration to create the included binaries. Related Information\nAltera Software Depot website Altera SoC Embedded Design Suite User Guide Preloader Changes Made for SD/MMC # The SD/MMC boot contains two preloader changes. The first change modified the preloader to load the bootloader from the FAT partition of the SD/MMC card rather than the RAW partition. This allows you to store your VxWorks bootrom on the FAT partition. In the second change, the name of the file that is loaded by the preloader is no longer set to u-boot by default. This file name needs to be the name of the VxWorks bootrom, wrapped by mkimage.\nThe modifications made to the uboot-socfpga/board/altera/socfpga/build.h file are shown below in bolded text:\n/* Enable FAT partition support when booting from SDMMC. */ #define CONFIG_PRELOADER_FAT_SUPPORT (1) /* * When FAT partition support is enabled, this specifies the * FAT partition where the boot image is located. */ #define CONFIG_PRELOADER_FAT_BOOT_PARTITION (1) /* * When FAT partition supported is enabled, this specifies the * boot image filename within a FAT partition to be used as * fatload payload. */ #define CONFIG_PRELOADER_FAT_LOAD_PAYLOAD_NAME \u0026#34;bootloader.bin\u0026#34; Another change where the preloader loads the FPGA file was made to the uboot-socfpga/include/configs/socfpga_common.h file.\n/* * FPGA programming support with SPL * FPGA RBF file source (with mkimage header) is located within the same * boot device which stored the subsequent boot image (U-Boot). */ /* enabled program the FPGA */ #define CONFIG_SPL_FPGA_LOAD Preloader Changes Made for QSPI # The QSPI boot contains one preloader change. This change made modifications to the preloader to load the VxWorks bootrom from QSPI rather than from the SD/MMC. In another change, the preloader now loads the FPGA. With this change, the preloader now programs the FPGA from a known QSPI address during boot.\nThe modifications made to the uboot-socfpga/board/altera/socfpga/build.h file are shown below in bolded text:\n/* * Boot option. 1 means that particular boot mode is selected. * Only 1 boot option to be enabled at any time */ #define CONFIG_PRELOADER_BOOT_FROM_QSPI\t(1) #define CONFIG_PRELOADER_BOOT_FROM_SDMMC (0) /*#define CONFIG_PRELOADER_BOOT_FROM_NAND (0)*/ #define CONFIG_PRELOADER_BOOT_FROM_RAM\t(0) Another change where the preloader loads the FPGA file is shown in the uboot-socfpga/include/configs/socfpga_common.h file in bolded text:\n/* * FPGA programming support with SPL * FPGA RBF file source (with mkimage header) is located within the same * boot device which stored the subsequent boot image (U-Boot). */ /* enabled program the FPGA */ #define CONFIG_SPL_FPGA_LOAD /* location of FPGA RBF image within QSPI */ #define CONFIG_SPL_FPGA_QSPI_ADDR (0x800000) Note: The last line of the code above sets the address in QSPI to program the FPGA binary file. In this example, the default value is used. Creating a Bootable Environment Using SD/MMC # Set up the board for SD/MMC boot. With the Altera Cyclone V SoC board oriented so that you can read the Altera Cyclone V SoC logo, set the following jumpers:\nSet jumper BootSEL0: Closed to the right: .[..] Set jumper BootSEL1: Closed to the right: .[..] Set jumper BootSEL2: Closed to the left: [..]. The sequence for boot selects 0..2 should look like: .[..] .[..] [..].\nCreate an SD/MMC card. Unzip the provided binary file for your development board and use the Win32 Disk Imager program to write it to an SD card. Start from the correct image for your development board:\nsdmmc/av_140_fat_sdmmc.zip for Arria V sdmmc/cv_140_fat_sdmmc.zip for Cyclone V Load the card into your development board and power up. Connect a USB cable between the serial port on the Altera development board and a USB port on your Windows computer. Verify that you see a COM port on your Windows computer. Apply power to the development board and connect to the COM port at a baud rate of 115200. Verify that you see the COM port in the Devices and Printers control panel on your Windows computer. You should see the output of the preloader, followed by the output of u-boot. This verifies that you can boot your board with the pre-built image and see serial output. The pre-built images include a copy of u-boot that has been renamed to bootloader.bin as a stand-in for your VxWorks bootrom. Build the VxWorks Bootrom. Build your VxWorks bootrom file using Wind River tools and the `alt_soc_gen5` BSP. You can build a command line bootrom, or build a bootrom from a VxWorks Image Project.\nFor more information on how to build a VxWorks bootrom, contact Wind River or read the BSP documentation.\nAdd the Altera header to the VxWorks Bootrom. Use mkimage to wrap the VxWorks bootrom file with the proper header image. A Windows binary for this tool is included in this package. The mkimage tool is available for linux, as well, but is not included in this package.\nThis header image contains the address that the preloader uses to load the bootrom. The value 0x08000040 is a good default choice for the compressed bootrom built from the command line. This bootrom will relocate itself to a different area of RAM. Other bootroms may have a different starting address. You can discover the starting address for an ELF version of a bootrom by using this command from a VxWorks development shell:\nobjdumparm –f \u0026lt;yourfilename\u0026gt; For Windows, use the mkimage program, as shown in the following command, for the default bootrom.bin file:\nmkimage.exe -A arm -T firmware -C none -O vxworks -a 0x08000040 - e 0 -n \u0026#34;vxWorks bootloader for SoC FPGA\u0026#34; -d bootrom.bin bootloader.bin In the other files, use an appropriate starting address for the -a option, as determined from the objdumparm command. The mkimage command is similar for Linux, but without the .exe extension.\nPut the VxWorks bootrom on the FAT partition. Power off the board, remove the SD/MMC card from the board and put it back in your PC. On Windows, you should see a new removable drive appear. Copy the file bootloader.bin created in the previous step to the SD/MMC card, eject the card from the PC, and insert it into the development board. Boot the board with the VxWorks Bootrom. Turn on the development board while monitoring the serial port. You should see the preloader boot first, followed by the VxWorks bootrom. You can stop the VxWorks bootrom to change the boot parameters, or allow it to continue to boot. Related Information\nWind River Board Support Packages\nCreating a Bootable Environment for QSPI Using the SD/MMC Card # First, create a bootable SD/MMC image with u-boot and then use the u-boot to program the VxWorks bootrom into QSPI. This avoids the use of the Altera Quartus programmer, but requires an SD/MMC card instead.\nPerform step 1 - 5 of the Creating a Bootable Environment Using SD/MMC method. Rename and copy the VxWorks bootrom to the SD/MMC card. On your host system, rename your bootloader.bin file to vxworksqspi.bin, so that it will not be confused with the bootrom on the SD/MMC card. Power off the board and remove the SD/MMC card from the board and put it back in the PC. On Windows, you should see a new removable drive appear. Copy the file vxworksqspi.bin to the SD/MMC card. Locate the pre-built QSPI specific preloader binary for your development board. This file is included in this package at: qspi/cv/preloader-mkpimage.bin For Cyclone V qspi/av/preloader-mkpimage.bin For Arria V Copy your vxworksqspi.bin file and the appropriate preloader-mkpimage.bin file to the SD/MMC card. Eject the card from the PC and insert it into the development board. Copy the FPGA binary to the SD/MMC card. The SD FAT partition already includes the correct fpga.rbf file, but it is also included in the instruc‐ tions at:\nghrd_fpga/cv/fpga.rbf For Cyclone V ghrd_fpga/av/fpga.rbf For Arria V You must convert this file using mkimage for use with QSPI. This is not required when the file is on the SD/MMC FAT partition. In order to do this, you must copy the fpga.rbf file to a directory and run this mkimage command:\nmkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n \u0026#34;FPGA\u0026#34; – d fpga.rbf fpga.img When done, copy the fpga.img file to the FAT partition on the SD card.\nUse u-boot to program QSPI. Turn on the development board and make sure the u-boot booted. The board boots up to a u-boot prompt and stops. Your QSPI preloader and VxWorks bootrom are now on the FAT partition of the SD/MMC card. Load the preloader file from the SD/MMC card into a temporary RAM location. Partially erase the QSPI flash and program the preloader into QSPI: % fatload mmc 0:1 0x2000000 preloader-mkpimage.bin % sf probe % sf erase 0x0 0x40000 % sf write 0x2000000 0x0 $filesize Load the VxWorks bootrom file from the SD/MMC card into a temporary RAM location. Partially erase the QSPI flash and program the bootrom into QSPI. You must erase on 64K boundaries (rounding up to the boundary past your file size): % fatload mmc 0:1 0x2000000 vxworksqspi.bin % printenv filesize Note: If the filesize is on a 64K boundary, like 0x40000, you can use that number for the erase command in the next sequence. If not, you must erase up to the next 64K boundary.\nFor example, if the file size is 0x5a360, you must use the value 0x60000 as the last argument to the erase command. Use this value for \u0026lt;your-erase-value\u0026gt; in the commands below:\n% sf probe % sf erase 0x60000 \u0026lt;your-erase-value\u0026gt; % sf write 0x2000000 0x60000 $filesize Load the FPGA binary from the SD/MMC card into a temporary RAM location. Partially erase the QSPI flash and program the FPGA into QSPI. You must erase on 64K boundaries (rounding up to the boundary beyond your file size): % fatload mmc 0:1 0x2000000 fpga.img % printenv filesize Note: Like the last example, you must erase up to the next 64K boundary. For example, if the filesize is 0x5a360, you must use the value 0x60000 as the last argument to the erase command. Use this value for \u0026lt;your-erase-value\u0026gt; in the commands below:\n% sf probe % sf erase 0x800000 \u0026lt;your-erase-value\u0026gt; % sf write 0x2000000 0x800000 $filesize In the above examples, 0x2000000 is a random RAM location, and can be replaced with any other RAM location that is not in use. The value 0x800000 is the starting address in QSPI for the FPGA image.\nTurn off the development board and remove the SD/MMC card. It is OK to leave the card in if you wish, but removing it verifies that you are no longer booting from SD/MMC.\nWith the Altera Cyclone V SoC board oriented so that you can read the \u0026ldquo;Altera Cyclone V SoC\u0026rdquo; logo, set the following jumpers for QSPI boot:\nSet jumper BootSEL0: Closed to the right: .[..] Set jumper BootSEL1: Closed to the left: [..]. Set jumper BootSEL2: Closed to the left: [..].\nThe entire sequence for boot selects 0..2 should look like: .[..] [..]. [..].\nBootup, monitoring the serial port to see if it worked. Turn on the development board while monitoring the serial port or connect to it quickly after power- up if the terminal emulator does not allow connecting before power-up. You should see the output of the preloader, followed quickly by the output of the VxWorks bootrom. If you miss these messages, then press the warm reset button to reboot.\nCreating a QSPI Bootable Environment with the Quartus Programmer # If you choose not to create an SD/MMC card, first, in order to boot QSPI, then the Altera quartus_hps programmer can be used with the USB blaster connector to load the preloader and VxWorks bootrom into the QSPI.\nFor this method, the QSPI preloader from this package and the VxWorks bootrom you created in the previous section are needed. Also the fpga.img file created from the fpga.rbf file in the previous section is needed.\nCollect the files that are needed. Follow the steps from the Creating a Bootable Environment for QSPI Using the SD/MMC Card section to:\nCreate a VxWorks bootrom. Wrap the bootrom using the mkimage program. Get the correct fpga.rbf file for your board (Cyclone V or Arria V). Wrap the fpga.rbf file using the mkimage program to create the fpga.img. Get the correct QSPI preloader for your board (Cyclone V or Arria V). After these steps you should have these files:\nFile Description preloader-mkpimage.bin The QSPI preloader from this package for your board. fpga.img The fpga.rbf from this package, wrapped with mkimage. vxworksqspi.bin The VxWorks bootrom you built, wrapped with mkimage. Set up the board for QSPI boot. With the Altera Cyclone V SoC board oriented so that you can read the “Altera Cyclone V SoC” logo, set the following jumpers for QSPI boot:\nSet jumper BootSEL0: Closed to the right: .[..] Set jumper BootSEL1: Closed to the left: [..]. Set jumper BootSEL2: Closed to the left: [..]. The entire sequence for boot selects 0..2 should look like: .[..] [..]. [..].\nGet Altera's Quartus II Programmer tool. For more information on how to download and install version 14.0 of Altera’s Quartus Programmer tool, navigate to the Quartus II Programmer and SignalTap II install under the Additional Software tab on Altera\u0026rsquo;s Software Depot website.\nOn Windows, create an embedded command shell. Start an Altera command shell from Start \u0026gt; All Programs \u0026gt; Altera \u0026lt;version\u0026gt; \u0026gt; SoC Embedded Design Suite (EDS) \u0026lt;version\u0026gt; \u0026gt; SoC EDS 14.0 Command Shell.\nThis will start a shell with two important variables:\nQUARTUS_ROOTDIR=\u0026#39;C:\\altera\\14.0\\qprogrammer\u0026#39; SOCEDS_DEST_ROOT=C:/altera/14.0/embedded Connect a USB cable to the USB blaster port. Connect a USB cable from a USB port on your Windows PC to the port labeled \u0026ldquo;USB Blaster\u0026rdquo; on the board to be programmed.\nDiscover your JTAG cable name. From your embedded command shell, power on your board and run the jtagconfig command.\n1) USB-BlasterII [USB-1] 4BA00477 SOCVHPS 02D020DD 5CS(EBA6ES|XFC6C6ES)/.. 020A40DD 5M(1270ZF324|2210Z)/EPM2210 In this example, the cable is 1. Use this value for all calls to quartus_hps as the parameter .\nProgram the preloader, VxWorks bootrom and FPGA image into QSPI. Program the preloader file into QSPI: quartus_hps -c \u0026lt;cable\u0026gt; -o P -a 0 -s 0x40000 preloader-mkpimage.bin Program the VxWorks bootrom into QSPI at address 0x60000. This address is from the preloader build.h file in the define CONFIG_PRELOADER_QSPI_NEXT_BOOT_IMAGE:\nquartus_hps -c \u0026lt;cable\u0026gt; -o P -a 0x60000 vxworksqspi.bin Program the FPGA image file into QSPI at address 0x800000. This address is from the preloader socfpga_common.h file in the define CONFIG_SPL_FPGA_QSPI_ADDR:\nquartus_hps -c \u0026lt;cable\u0026gt; -o P -a 0x800000 fpga.img Boot up, monitoring the serial port to see if it worked. After programming these files, it is important to remove power from the board for about ten seconds. The user may see a CRC error upon load if the board is not powered down for enough time. This can be resolved by removing power, waiting, and trying again.\nTurn on the development board while monitoring the serial port at 115200 baud. You should see the output of the preloader, followed by the output of the VxWorks bootrom.\nRelated Information\nAltera\u0026rsquo;s Software Depot website Configuring VxWorks using the Bootloader # From the VxWorks bootlooader, you can use the p command to print the boot settings and the c command to change them. The M command can be used to change the MAC address of the emac1 port.\nConfiguring for Boot with the VxWorks Image on an FTP Server # Use the following boot parameters:\nTable 1: Boot Parameters\nParameter Value boot device emac1 unit number 1 processor number 0 host name host file name C:/WindRiver/vxworks-6.9/target/config/alt_soc_gen5/vxWorks inet on ethernet (e) 192.168.1.2:ffffff00 host inet (h) 192.168.1.20 gateway inet (g) 192.168.1.1 user (u) target ftp password (pw) vxTarget flags (f) 0x0 target name (tn) alt_soc_gen5 other (o) - For Ethernet boot, the \u0026ldquo;inet on Ethernet\u0026rdquo; address should be a static IP address assigned to the board. The hex code after the address is a network mask. The \u0026ldquo;host inet\u0026rdquo; address is the address of the machine with the VxWorks application.\nMost developers use Ethernet boot when developing code, then copy their code to the SD card for booting without using a host.\nConfiguring for Boot with the VxWorks Image on the SD Card FAT Partition # VxWorks can also be booted from the FAT partition on the SD/MMC card. To do so, edit the config.h file in the BSP directory to add the following options:\n/* Add this to end of config.h to boot vxworks from the SD flash file system */ #define DRV_STORAGE_ALT_SOC_GEN5_DW_MSHC #define INCLUDE_BOOT_FILESYSTEMS #define INCLUDE_DOSFS Next:\nBuild bootrom.bin from a VxWorks development shell. Use mkimage.exe to create the bootloader.bin file as described in Step 5 of the Creating a Bootable Environment Using SD/MMC section. Copy the bootloader.bin and your VxWorks image to the FAT partition of your SD card. Use the following boot parameters listed in the following table:\nTable 2: Boot Parameters\nParameter Value boot device fs unit number 0 processor number 0 host name host file name /sd0:1/vxWorks inet on ethernet (e) 192.168.1.2:ffffff00 host inet (h) 192.168.1.20 gateway inet (g) 192.168.1.1 user (u) target ftp password (pw) vxTarget flags (f) 0x0 target name (tn) alt_soc_gen5 other (o) emac1 Optionally, specifying \u0026ldquo;emac1\u0026rdquo; in the other field, will configure and enable the Ethernet port even though it is not actually booting over Ethernet. The VxWorks BSP target.ref file has more information on SD support.\nThis boot method cannot be used in conjunction with the boot method in the following DHCP section.\nConfiguring for Boot Using DHCP and FTP # VxWorks can also use DHCP to get an IP address before retrieving the VxWorks image via FTP. To do so, edit the config.h file in the BSP directory to add the following options:\n/* Add this to end of config.h to boot vxworks using DHCP */ #define INCLUDE_BOOT_DHCPC #define INCLUDE_IPDHCPC #define DHCPC_OPTION_MAX_MESSAGE_SIZE \u0026#34;576\u0026#34; #define DHCPC_TTL \u0026#34;1\u0026#34; #define DHCPC_FLAGS_BIT_BROADCAST \u0026#34;0\u0026#34; #define DHCPC_IF_INFORMATION_ONLY_LIST \u0026#34;\u0026#34; #define INCLUDE_IPNET_IFCONFIG_1 #define IFCONFIG_1 \\ \u0026#34;ifname\u0026#34;,\u0026#34;devname driver\u0026#34;,\u0026#34;inet dhcp\u0026#34;,\u0026#34;gateway dhcp\u0026#34;,\u0026#34;inet6 3ffe:1:2:3::4/64\u0026#34; Next:\nBuild bootrom.bin from a VxWorks development shell. Use mkimage.exe to create the bootloader.bin file as described in Step 5 in the Creating a Bootable Environment Using SD/MMC section. Copy the bootloader.bin and your VxWorks image to the FAT partition of your SD card. Uset the following boot parameters:\nTable 3: Boot Parameters\nParameter Value boot device emac1 unit number 1 processor number 0 host name host file name C:/WindRiver/vxworks-6.9/target/config/alt_soc_gen5/vxWorks inet on ethernet (e) - host inet (h) 192.168.1.20 gateway inet (g) 192.168.1.1 user (u) target ftp password (pw) vxTarget flags (f) 0x40 target name (tn) alt_soc_gen5 other (o) - This boot method cannot be used in conjunction wit the boot method in the previous SD section.\nSample Images # This package comes with prebuilt images that have been tested with the development boards.\nThe ghrd_fpga directory contains FPGA binaries for the Altera Golden Hardware Reference Design:\nav - contains the GHRD binary for the Arria V SoC product cv - contains the GHRD binary for the Cyclone V SoC product The qspi and sdmmc directories each contain subdirectories for each target board:\nav - support for the Arria V SoC development board cv - support for the Cyclone V SoC development board Each of the av and cv directories contains preloader (spl) code specific to qspi or sdmmc:\nu-boot-spl - an ELF version of the preloader that can be used with DS-5 Altera Edition u-boot-spl.bin - the preloader u-boot-spl.map - a map file for the preloader preloader-mkpimage.bin - the four-copy preloader with the proper header image The sdmmc directory additionally contains these files:\nmake_sdimage.sh - a Linux script for creating SD/MMC images av_140_fat_sdmmc.zip - a prebuilt SD/MMC image for the Arria V board cv_140_fat_sdmmc.zip - a prebuild SD/MMC image for the Cyclone V board The sample SD/MMC images were created on a Linux system, running as root, using the following command:\n./make_sdimage.sh -p preloader-mkpimage.bin -b u-boot.img –k bootloader.bin,u-boot.img,fpga.rbf,readme.txt –o cv_140_fat_sdmmc.img -g 512M The preloader and FPGA files were built specifically for the development board and are different between Cyclone V and Arria V. The u-boot.img file included on the RAW partition is not used and is just there to satisfy the make_sdimage.sh script. The preloader is configured to boot the file bootloader.bin on the FAT partition. For SD/MMC, the preloader loads the fpga.rbf file from the FAT partition on the SD card. The SD card images include a version of u-boot that can be used to program the QSPI.\nOther Resources # For more Altera documentation, you can visit the Altera SoC Embedded Software Tools documentation page and the Altera SoC Embedded Design Suite User Guide.\nFor more information on using Linux with the Altera SoC or how to set up the development board, refer to the Rocketboards website.\nRelated Information\nAltera SoC Embedded Software Tools Altera SoC Embedded Design Suite User Guide Rocketboards ","date":"2024-10-07","externalUrl":null,"permalink":"/bsp/booting-vxworks-with-altera-cyclone-v/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003ePurpose of this Article \n    \u003cdiv id=\"purpose-of-this-article\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#purpose-of-this-article\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThis article describes how to take a VxWorks® bootrom that is built using the Wind River® BSP, alt_soc_gen5, combine it with a preloader built from an Altera® FPGA design, and boot the Altera Cyclone® V and Arria® V SoC development boards using QSPI or SD/MMC.\u003c/p\u003e","title":"Boot VxWorks With Altera Cyclone V","type":"bsp"},{"content":"","date":"2024-10-07","externalUrl":null,"permalink":"/tags/cyclone-v/","section":"Tags","summary":"","title":"Cyclone V","type":"tags"},{"content":"","date":"2024-10-05","externalUrl":null,"permalink":"/tags/vxworks-5.4/","section":"Tags","summary":"","title":"VxWorks 5.4","type":"tags"},{"content":" Preface # This guide is for device driver developers, who have general background in real time operating systems. This guide addresses device driver development using VxWorks 5.4/Tornado 2.0.\nWe referred to VxWorks 5.4 programmers manual and other VxWorks website to make sure the content is as accurate as possible.\nReal Time Operating System and VxWorks # Operating systems can be categorized into real-time and non-real-time systems. A real-time system is defined as a system where the response time for an event is predictable and deterministic with minimal latency. The architecture of the operating system\u0026rsquo;s scheduler, also referred to as the dispatcher, has a significant impact on the responsiveness of the OS. Preemptive scheduling ensures the highest priority task/thread always runs and doesn’t relinquish the CPU until its work is done or a higher priority task becomes available. A preemptive scheduler also implies a real-time kernel. Several aspects to consider when selecting a real-time OS are:\nFoot print of the kernel Interrupt latency Interrupt response time Interrupt recovery Multi-tasking Task context switching Virtual memory support VxWorks provides a real-time kernel that interleaves the execution of multiple tasks employing a scheduling algorithm. Thus the user sees multiple tasks executing simultaneously. VxWorks uses a single common address space for all tasks thus avoiding virtual-to-physical memory mapping. Complete virtual memory support is available with the optional vxMem library.\nTour of VxWorks # Tasks # A task is an independent program with its own thread of execution and execution context. Every task contains a structure called the task control block that is responsible for managing the task\u0026rsquo;s context. A task\u0026rsquo;s context includes\nprogram counter or thread of execution CPU registers Stack of dynamic variables and function calls Signal handlers IO assignments Kernel control structures Every task has a name and an ID associated with it. Each task is assigned a default priority as well. A task has four states as shown below.\nA task can be created with taskInit() and then activated with taskActivate() routine or both these actions can be performed in a single step using taskSpawn(). Once a task is created it is set to the suspend state and suspended until it is activated, after which it is added to the ready queue to be picked up by the scheduler and run. A task may be suspended by either the debugging your task, or the occurrence an exception. The difference between the pend and suspend states is that a task pends when it is waiting for a resource. A task that is put to sleep is added to delay queue.\nScheduler # VxWorks scheduler determines which task to own the CPU time. By default, the scheduler runs a preemptive algorithm. Preemptive scheduler guarantees that the highest priority task preempts a lower priority task. There are some special cases called priority inversion which is discussed in advanced concepts.\nThe scheduler can be set to run round robin algorithm which is a time slicing algorithm.\nMutual Exclusion # Mutual exclusion can be implemented in VxWorks in the following three ways.\nSemaphores Disabling Interrupts Disabling the scheduler using taskLock() Semaphores # VxWorks supports three types of semaphores, binary, mutual exclusion, and counting, each of which is optimized for a specific application. Semaphores are generally used for task synchronization and communication, and protection of shared resources also referred to as concurrency control or mutual exclusion.\nBinary semaphores are the fastest and are best suited for basic task synchronization and communication. Mutual exclusion semaphores are sophisticated binary semaphores that are designed to address the issues relating to task priority inversion and semaphore deletion in a multitasking environment. Counting semaphores maintain a count of the number of times a resource is given. This is useful when an action is required for each event occurrence. For example if you have ten buffers, and multiple tasks can grab and release the buffers, then you want to limit the access to this buffer pool using a counting semaphore. Message Queues # VxWorks supports messages queues for inter task communication. A variable number of messages, each of variable length, can be sent to any task. ISRs and tasks can send messages but only tasks can receive messages.\nMultiple tasks can wait on a single message queue and can be ordered by their priority. Messages can be marked urgent for faster delivery.\nNetwork Intertask Communication # VxWorks supports general facilities like pipes, sockets, RPC and signals for network inter task communications.\nAdditional Facilities # VxWorks provides facilities like Asynchronous IO and buffered IO for application and driver development. It is also POSIX library.\nInterrupts and Interrupt handling # Interrupt is the mechanism by which a device seeks the attention of CPU. The piece of user code that the CPU executes on interrupt is called interrupt service routine (ISR). The Kernel doesn\u0026rsquo;t transfer execution to the ISR immediately. It does some house keeping before the ISR is executed. The delay between the occurrence of interrupt and time spent by the kernel before it executes the first ISR instruction is called Interrupt response time. This equals the sum of interrupt latency and time to save CPU\u0026rsquo;s context and execution time of kernel ISR entry function.\nVxWorks provides a special context for interrupt service code to avoid task context switching, and thus renders fast response. VxWorks supplies interrupt routines which connect to C functions and pass arguments to the functions to be executed at interrupt level. To return from an interrupt, the connected function simply returns. A routine connected to an interrupt in this way is referred to as an interrupt service routine (ISR) or interrupt handler. When an interrupt occurs, the registers are saved, a stack for the arguments to be passed is set up, then the C function is called. On return from the ISR, stack and registers are restored.\nIntConnect(INUM_TO_IVEC(intNum), intHandler, argToHandler) allows C functions to be connected to any interrupt. The first argument to this routine is the byte offset of the interrupt vector to connect to. The second argument is the interrupt handler and the last is any argument to this handler.\nOne can disable interrupts using intLock() for synchronization. Care should be taken to re-enable the interrupts using intUnlock(). If you are planning for nested interrupts, you should not disable interrupts using intLock(). Also make sure that your code is reentrant and you allocate enough stack resources for nesting.\nPoints to remember Within an ISR, limited capabilities exist for the user code. Not all library functions are available. Since memory facilities malloc() and free() take semaphores, they cannot be called within ISR. Any blocking call is to be avoided. Semaphores can be given, but not taken from an ISR. Points to remember ISR can communicate with user tasks via\nshared memory and ring buffers release of semaphores signal tasks writing to pipes sending messages using message queue Understanding ISR and what goes on within interrupt handler is the key to designing your driver. Many real world drivers just have an interrupt handler and interact with user and device without the rest of the interfaces. Please refer to 7) for examples.\nDevices and Drivers # A driver supplies a uniform device independent logical interface to the user to interact with a device. A device can be a piece of hardware such as your hard drive or can be a piece of software such as a pipe or a socket, but a driver is always a software module. A driver can control multiple devices. If the architecture allows virtual memory, driver works in a logical/virtual address space, but a device works in a physical address space.\nAll interactions with devices in VxWorks are performed through the IO sub-system. VxWorks treats all devices as files. Devices are opened just like normal files are for IO operations. An example device is /tyCo/0 that represents a serial channel. When a filename is specified in an IO call by the user task, the IO system searches for a device with a name that matches the specified filename. Two most important devices are character devices or non-block and block devices. Character devices perform IO operations character by character. Block devices are used for storing file systems. Block devices perform IO in blocks of characters and can support complicated operations such as random access. Block devices are accessed via file system routines as shown in the above figure. The driver interface to character devices are not filesystem routines.\nPoints to remember A character device is named usually at the system initialization Block devices are always associated with a file system like raw file system, dos file system. They are named when initialized for a specific file system. Drivers can be loaded and unloaded dynamically. Drivers work in thee context of the task invoked an interface routine. Hence drivers are preemptable and should be designed as such. Character Drivers # creat(), remove(), open(), close(), read(), write(), ioctl() are the seven standard driver interfaces that can be exposed to the user. Not all of the interfaces are mandatory.\nFour steps are involved in the driver design and install process.\nStep 1: Decide the interfaces you want to expose and install the driver The following piece of code is the driver initialization routine.\nSTATUS myDrv() { myDrvNum = iosDrvInstall(myDevCreate /* create */ , 0 /* remove() is null */ , myDevOpen /* open() */ , 0 /* close() */ , myDevRead /* read() */ , myDevWrite /* write() */ , myDevIoctl /* ioctl() */ ); /* connect the ISR */ intConnect(intvec, myIntHandler, 0); } As shown in the above piece of code, we can skip the driver interface routines like remove and close. But it is always a good practice to include them and return an error. VxWorks returns an error on your behalf, if it doesn\u0026rsquo;t find a particular interface. Also you can initialize any relevant data structures in the myDrv routine.\nPoints to remember myDrvNum is used by the IO subsystem in locating your device. The device driver gets installed into a driver table. The index is based on driver number. Since a driver can service more then one device, a list of devices are tied together in a linked list, with the same driver number, but different device names and device descriptors. Step 2: Create your device descriptor structure Capture the essence of your device in a structure. This structure will hold all the information related to your device. This structure will be passed back by the IO subsystem, as a parameter to the rest of the interfaces like read(), write(), ioctl() etc., You can even get this structure within your ISR.\ntypedef struct { DEV_HDR myDevHdr; BOOL isDevAvailable; Semaphore getAccess; } MY_DEV; If you are using semaphores to control the access to your device, make sure you create and initialize them before you make use of them.\nOnce you are ready with your structure, pass it as an address to iosDevAdd as shown in the below piece of code.\nSTATUS myDevCreate(char *name, …) { MY_DEV *pMyDevice; status = iosDevAdd(pMyDevice, /* pointer to MY_DEV device */ name, /* input param */ myDrvNum /* return value from iosDrvInstall */ ); /* do other work as necessary */ } iosDevAdd takes three arguments. The first argument is the address of device descriptor structure. A device descriptor structure always starts with DEV_HDR structure as it\u0026rsquo;s first member. It can contain any other private data structures for your own use. The second argument is the name of the device. The third argument is the driver number, the return value of iosDrvInstall.\nPoints to remember IO subsystem searches the correct device based on device name and driver number. They are held in a header structure DEV_HDR.\nStep 3: Finish the definitions of all other interfaces STATUS myDevOpen(MY_DEV * pMyDev, char *additionalInfo, int mode) { } STATUS myDevRead(MY_DEV * pMyDev, char *buffer, int nBytes) { /* read nBytes from the device and put them into the buffer*/ } STATUS myDevWrite(MY_DEV * pMyDev, char *buffer, int nBytes) { /* write to the device from buffer if the device has room*/ } IOCTL needs some explanation. It is through IOCTL that a user can control the device. This the preferred way of controlling the device. The code within the IOCTL depends upon the way your device perform and the way you want to control the device.\nSTATUS myDevIoctl(MY_DEV * pMyDev, int request, int arg) { switch (request) { CASE SET_DEVICE: /* set the device */ CASE MODIFY_PARAM: } } Step 4: Complete your interrupt handler Void myIntHandler(arg) { /* disable any further interrupts */ intLock(); // now read the interrupt register and indicate to the other tasks that you received an interrupt. // You can do this in multiple ways. Refer to \u0026#39;Tour of VxWorks\u0026#39; // One easy way is to give a semaphore semGive(getAccess); /* re-enable interrupts*/ intUnlock(); return; } Once your interrupt handler has been installed using intConnect(), the kernel will call your ISR when the CPU receives an interrupt from the device.\nBlock Drivers # A block device is a device that is organized as a sequence of individually accessible blocks of data. A block is the smallest addressable unit on a block device. Block devices have a slightly different interface than that of other IO drivers. Rather than interacting directly with the IO system, block drivers interact via file-system. The file system in turn interacts with the IO system. Every block device is typically associated with a specific file system. DOS, SCCI, and raw file systems are supported.\nBlock devices are divided into two categories based on their write capabilities. Direct Access BLOCK Devices are slightly different from SEQUENTIAL Devices in that data can be written only to the end of written medium for sequential devices, where as for true block devices, data can be written any where randomly.\nThere is no difference between BLOCK and Sequential devices as far as reading from the device is concerned.\nA device driver for a block device must provide a means for creating logical device structure, a BLK_DEV for direct access block devices and SEQ_DEV for sequential block devices. BLK_DEV/SEQ_DEV structures describe the device, contain routines to access the device, describe the device in a general fashion so that the underlying file system that serves this device can know about this device.\nPoints to remember When the driver creates the block device, the device has no name or file system associated with it. These are assigned during the device initialization routine for the specific file system (example dosFsDevInit()). The low-level driver is not installed in the IO system driver table. Instead the underlying file system is installed as an entry into the driver table. Only one entry of file system is installed even if multiple devices are using this file system. The following three steps are involved in writing a Block device driver. I shall explain this example by using ram driver with DOS as the underlying file system.\nRam driver emulates a disk driver, but actually keeps all data in memory. The memory location and size are specified when the \u0026ldquo;disk\u0026rdquo; is created. The RAM disk feature is useful when data must be preserved between boots of VxWorks or when sharing data between CPUs. The RAM driver is called in response to ioctl() codes in the same manner as a normal disk driver. When the file system is unable to handle a specific ioctl() request, it is passed to the ramDrv driver. Although there is no physical device to be controlled, ramDrv does handle a FIODISKFORMAT request, which always returns OK. All other ioctl() requests return an error and set the task\u0026rsquo;s errno to S_ioLib_UNKNOWN_REQUEST.\nStep 1: Initialize and finish the interfaces within BLK_DEV structure Declare all your data structures, create your semaphores, initialize the interrupt vectors and enable the interrupts just as been discussed for character devices. This step is required, only when you are creating your own device and not making use of existing block devices (like ram drive, scsi device etc.,) supported by VxWorks. Check VxWorks reference manual and programmers guide before you fill out the interfaces.\nPoints to remember If these interfaces are filled, the file system will call them for you, if not it will call the default routines of the file system itself.\nBLK_DEV is a structure that has the address of certain routines. If you decided to fill the structure, just declare the required interfaces and pass the address of the interfaces to BLK_DEV.\nDeclare your private device descriptor structure. Or you can directly use BLK_DEV structure.\ntypedef struct { BLK_DEV myDev; Bool privateData; Semaphore giveAccess; } DEVICE; The various fields within BLK_DEV structure are\nbd_blkRd: Address of driver routine that reads blocks from the device, if your device is myBlkDevice, then call this routine as myBlkDevRd.\nSTATUS myBlkDevRd( DEVICE * pDev,\t/* pointer to driver\u0026#39;s device descriptor. * The file system passes the address of BLK_DEV structure. * These two are equivalent because BLK_DEV is the first item of DEVICE structure */ Int startBlk, Int numBlks, Char * pBuf\t/*the address where data read is copied to */ ); bd_blkWrt: Address of driver routine that writes blocks to the device\nSTATUS myBlkDevWrt( DEVICE * pDev,\t/* pointer to driver\u0026#39;s device descriptor. */ Int startBlk, Int numBlks, Char * pBuf\t/*the address where data is copied from and written to the device */ ); bd_ioctl: Address of driver routine that performs the device IO control\nSTATUS myBlkDevIoctl( DEVICE * pDev,\t/* pointer to driver’s device descriptor. */ Int functioncode, /* ioctl function code */ Int arg ); bd_reset: Address of driver routine that performs the device reset. Null if none\nSTATUS myBlkDevReset( DEVICE * pDev,\t/* pointer to driver’s device descriptor. */ ); bd_statusChk: Address of driver routine that checks the device status. Null if none\nSTATUS myBlkDevStatus( DEVICE * pDev, /* pointer to driver’s device descriptor. */ ); bd_removable: TRUE if the device is removable(like floppy)\nbd_nBlocks: Total number of blocks on the device\nbd_nbytesPerBlk\nbd_lksPerTrack\nbd_nHeads\nbd_retry: Number of times to retry failed reads or writes\nbd_mode: Deice mode (write protected etc.,), typically set to O_RDWR\nbd_readyChanged: True if the device ready status has changed. Defaults to true\nA similar structure SEQ_DEV needs to be filled if your device is sequential.\nStep 2: Create your device Include your header files for the file system library. In our case it is dos file system. The libaray is dosFsLib.\nBLK_DEV *pBlkDev;\t// declare your BLK_DEV structure DOS_VOL_DESC *pVolDesc; PBlkDev = ramDevCreate(0, 512, 400, 400, 0); PvolDesc = dosFsMkfs(\u0026#34;DEV1:\u0026#34;, PblkDev); Explanation about the above code.\nBLK_DEV *ramDevCreate ( char * ramAddr, /* where it is in memory (0 = malloc) */ int bytesPerBlk, /* number of bytes per block */ int blksPerTrack, /* number of blocks per track */ int nBlocks, /* number of blocks on this device */ int blkOffset /* no. of blks to skip at start of device */ } if you have already pre-allocated memory, pass the address as the first argument. If not, VxWorks will allocate memory on your behalf using malloc, if you pass zero as the first argument.\nDOS_VOL_DESC *dosFsMkfs ( char * volName, /* volume name to use */ BLK_DEV * pBlkDev /* pointer to block device struct */ ) dosFsMkfs routine calls dosFsDevInit() with default parameters and initializes the file system on the disk by calling ioctl() with FIODISKINIT.\nDOS_VOL_DESC *dosFsDevInit ( char * devName, /* device name */ BLK_DEV * pBlkDev, /* pointer to block device struct */ DOS_VOL_CONFIG * pConfig /* pointer to volume config data */ ) This routine takes a block device structure (BLK_DEV) created by a device driver and defines it as a dosFs volume. As a result, when high-level I/O operations (e.g., open(), write()) are performed on the device, the calls will be routed through dosFsLib. The pBlkDev parameter is the address of the BLK_DEV structure which describes this device. This routine associates the name devName with the device and installs it in the VxWorks I/O system’s device table. The driver number used when the device is added to the table is that which was assigned to the dosFs library during dosFsInit(). (The driver number is placed in the global variable dosFsDrvNum.)\nThe BLK_DEV structure contains configuration data describing the device and the addresses of five routines which will be called to read sectors, write sectors, reset the device, check device status, and perform other control functions (ioctl()). These routines will not be called until they are required by subsequent I/O operations.\nThe pConfig parameter is the address of a DOS_VOL_CONFIG structure. This structure must have been previously initialized with the specific dosFs configuration data to be used for this volume. This structure may be easily initialized using dosFsConfigInit(). If the device being initialized already has a valid dosFs (MS-DOS) file system on it, the pConfig parameter may be NULL. In this case, the volume will be mounted and the configuration data will be read from the boot sector of the disk. (If pConfig is NULL, both change-no-warn and auto-sync options are initially disabled. These can be enabled using the dosFsVolOptionsSet() routine.)\nStep 3: Finish your ISR Finish your interrupt handler routine. You just need to connect the ISR using intConnect.\nReal World Scenarios # I will cover two sample drivers. The first one is a standard serial driver. The second one is a hypothetical network processor driver, which doesn\u0026rsquo;t follow the required conventions. Both of these are character drivers.\nSerial Driver # This driver deals with PowerPC 8245 DUART. You can download PPC 8245 manual online from here MPC8245. Look into chapter 11 and 12 of this manual. This example deals with NS16550 or equivalent UART (Universal Asynchronous Receiver Transmitter).\n// forward declare our interrupt handler void DuartISRHandler(); #define EUMBARR_BASE\tDEFINE_YOUR_OWN #define DUART_CH1_IVR\tEUMBARR_BASE+0x51120 #define IACK_REG\tEUMBARR_BASE+0x600A0 #define EOI_REG\tEUMBARR_BASE+0x600B0 Embedded utilities Block(EUMBARR) holds the EPIC register definition. It serves as an offset for the rest of the registers within EPIC unit. The programming model of EPIC is as follows.\nset the required interrupt vector/priority register. In this case we are interested in DUART channel 1 IVR. Once an interrupt occurs, EPIC will notify the CPU. CPU has to read the interrupt acknowledge register to determine the interrupt source. Most of the times this portion will be taken care for your by the BSP(Board support package) and the kernel. But I will show you how to do this. Typically your kernel will determine the source and call the installed interrupt handler. Once you have finished your work within ISR, you have to return. Your kernel will typically write to EOI register. I will show this step too. #define\tDCR\tEUMBARR_BASE+0x4511 #define\tULCR\tEUMBARR_BASE+0x4503 #define\tUFCR\tEUMBARR_BASE+0x4502 #define\tUIIR\tUFCR #define\tURBR\tEUMBARR_BASE+0x4500 #define\tUTHR\tURBR #define\tUDLB\tURBR #define\tUIER\tEUMBARR_BASE+0x4501 #define\tUDMB\tUIER #define\tULSR\tEUMBARR_BASE+0x4505 #define\tUDSR\tEUMBARR_BASE+0x4510 Let us get into details about the DUART itself . Refer to 12.3 DUART initialization sequence.\n/* * declare buffersize to be greater then 14. * This the value we set for FIFO capacity, 14 bytes of data. * We make use of a ring buffer to handle the incoming and out going data. * A ring Buffer is a circular array (liner array around which we wrap around). * */ #define BUF_SIZE 141 typedef struct { DEV_HDR DuartHdr; Char readBuf[BUF_SIZE]; Char writeBuf[BUF_SIZE]; Int readCount; Int readPtr; Int writePtr; Int writeCount; Int mode; BOOL intUse; Semaphore getRDAccess; Semaphore getWRAccess; } MY_DEV; /* some global definitions */ MY_DEV gDuartStruct; Static int gDuartDrvNum; STATUS DuartInit() { *ULSR = 0;\t/* This lets access to UDLB, UAFR and UDMB. */ *UDLB = 1; *UDMB = 0; /* we have set divisor to be 16, the max baud rate allowed. */ *UAFR = 0;\t/* disable concurrent writes */ *ULSR = (1 \u0026lt;\u0026lt; 1) | 1;\t/* set bit 8 bit characters (bits 0 and 1) */ *DCR = 0; /* route the interrupts to EPIC in four signal mode */ *UIER = (1 \u0026lt;\u0026lt; 2) | (1 \u0026lt;\u0026lt; 1) | 1; /* we are not setting modem status. We program assuming no modem is going to be connected. */ *UFCR = (1 \u0026lt;\u0026lt; 7) | (1 \u0026lt;\u0026lt; 6) | (1 \u0026lt;\u0026lt; 3) | (1 \u0026lt;\u0026lt; 2) | (1 \u0026lt;\u0026lt; 1) | 1; /* enable the FIFO Tx and Rx for 14 bytes */ *DUART_CH1_IVR = 0; /* clear it first; */ int priority = 16; /* actual priority will be 1 */ int vector = 0x7; /* the vector number associated with UART interrupt. * make sure no one else has this vector already taken. * It returns vector 128 when IACK register is read. * */ *DUART_CH1_IVR = (1 \u0026lt;\u0026lt; priority) | (1 \u0026lt;\u0026lt; vector); gDuartDrvNum = iosDrvInstall(myDevCreate /* create */ , 0 /* remove() is null */ , DuartOpen /* open() */ , DuartClose /* close() */ , DuartRead /* read() */ , DuartWrite /* write() */ , DuartIoctl /* ioctl() */ ); // register our ISR intConnect(128, DuartISRHandler, 0); gDuartStruct.getWRAccess = semBCreate(SEM_Q_PRIORITY, SEM_FULL); gDuartStruct.getRDAccess = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY); } Inside the DuartInit routine, we initialized various registers. One point to note is we created two semaphores, one for read and one for write. They protect the read and write buffers readBuf and writeBuf. getWRAccess has been created full, meaning the write semaphore is available immediately for access, which indicates that the user can write to the DUART and writeBuf can hold bytes. getRDAccess has been created empty, meaning there is no data available for reading immediately from readBuf, until someone gives the semaphore.\nSemaphores are taken in read and write routines and given in the ISR. ISR can modify readPtr and writeCount. It doesn\u0026rsquo;t modify writePtr and readCount. DuratRead() routines modifies readCount and doesn\u0026rsquo;t modify readPtr. DuratWrite() routine modifes writePtr and doesn\u0026rsquo;t modify writeCount. This way, I am making sure that no race conditions exisit.\nSTATUS DuartCreate(char *name, …) { MY_DEV *pDuart = \u0026amp;gDuartStruct; status = iosDevAdd(pDuart, /* pointer to MY_DEV device */ name, /* input param */ gDuartDrvNum /* return value from iosDrvInstall */ ); } STATUS DuartOpen(MY_DEV * pDuart, char *remainder, int mode) { /* serial devices should have no file name remainder */ /* if multiple opens occur, we reject, note that I have not protected inUse variable here. They should be protected */ if (remainder[0] != 0 || pDuart-\u0026gt;intUse) { return ERROR; } else { pDuart-\u0026gt;intUse = true; // only one access at a time pDuart-\u0026gt;mode = mode; return (int)pDuart; } } STATUS DuartClose(char *name, …) { pDuart-\u0026gt;intUse = false; return OK; } // read from the DUART and Put it into the buffer // here we will not always be able to read the required number of bytes for two reasons. // 1) Not enough data is available // 2) We code it little lazy, and the user has to do one more read to get the data, if readPtr has wrapped around // we manipulate pDuart-\u0026gt;readPtr only in the ISR and pDuart-\u0026gt;readCount from this code to avoid race conditions STATUS DuartRead(MY_DEV * pDuart, char *buffer, int nBytes) { /* read nBytes from the device and put them into the buffer */ /* define RDMASK and WRITEMASK */ if (pDuart-\u0026gt;mode \u0026amp; RDMASK) // if it is readable { } /* this is a blocking call. * If there is no data available, we cannot proceed further, * until data arrives and we release the semaphore from the ISR. */ semTake(pDuart-\u0026gt;getRDAccess, WAIT_FOREVER) /* grab whatever data is available and return it, * don\u0026#39;t wait till you get all the required nBytes data. */ int NumBytestoRead = 0; int I = 0; int readPtr = pDuart-\u0026gt;readPtr; NumBytestoRead = readPtr - pDuart-\u0026gt;readCount; if (pDuart-\u0026gt;readCount \u0026gt;= readPtr) { // no race condition detected while ((NumBytestoRead \u0026gt; 0) \u0026amp;\u0026amp; (pDuart-\u0026gt;readCount \u0026gt; readPtr)) { buffer[I] = pDuart-\u0026gt;readBuf[pDuart-\u0026gt;readCount++]; I++; pDuart-\u0026gt;readCount %= BUF_SIZE; NumBytestoRead--; } } if (pDuart-\u0026gt;readCount \u0026lt; readPtr) { while ((NumBytestoRead \u0026gt; 0) \u0026amp;\u0026amp; (pDuart-\u0026gt;readCount \u0026lt; readPtr)) { buffer[I] = pDuart-\u0026gt;readBuf[pDuart-\u0026gt;readCount++]; I++; NumBytestoRead--; } } return I; } /* write to the device from buffer if the device has room */ // We manipulate the writePtr from here and writeCount from the ISR STATUS DuartWrite(MY_DEV * pDuart, char *buffer, int nBytes) { // define RDMASK and WRITEMASK if (pDuart-\u0026gt;mode \u0026amp; WRITEMASK) // if it is writeable mode { } Int NumBytestoWrite = nBytes; Int I = 0; Int writeCount = pDuart-\u0026gt;writeCount; if (pDuart-\u0026gt;writePtr \u0026gt;= writeCount) { // no race condition detected while ((NumBytestoWrite \u0026gt; 0) \u0026amp;\u0026amp; (pDuart-\u0026gt;writePtr \u0026gt;= writeCount)) { pDuart-\u0026gt;writeBuf[pDuart-\u0026gt;writePtr++] = buffer[I]; I++; pDuart-\u0026gt;writePtr %= BUF_SIZE; NumBytestoWrite--; } } if (pDuart-\u0026gt;writePtr \u0026lt; writeCount) { while ((NumBytestoWrite \u0026gt; 0) \u0026amp;\u0026amp; (writeCount \u0026gt;= pDuart-\u0026gt;writePtr)) { pDuart-\u0026gt;writeBuf[pDuart-\u0026gt;writePtr++] = buffer[I]; I++; NumBytestoWrite--; } } return I; } IOCTL requires some explanation. IOCTL provides an interface for a user to control the device, and is the preferred way of controlling the device. The implementation of IOCTL is dependant upon the way your device performs and how you want to control the device.\nSTATUS DuartIoctl(MY_DEV* pDuart, int command, int baudrate) { switch(command) { CASE SET_DEVICE: /* set the device*/ break; CASE MODIFY_BAUD: // our argument has the new baud rate. // we will have to modify the registers to set the baud rate // you need to know the clock frequency of your CPU. // assume it is a global value int divisor = clock_frequency/ (baud* 16); // UDLB is the least significant byte register and UDMB is the most significant. // each register is 8 bits wide, so the max value for 8 bits of data is 255. // if divisor is less then 256, we assign it to UDLB and make UDMB zero. If(divisor \u0026lt; 256) { *UDLB = divisor; } else { *UDMB = divisor - 255; *UDLB = 255; } break; default: break; } } Let us finish the interrupt handler routine. We enter into the handler after the kernel has determined that the vector within IACK register matches to DuartISRHandler.\n// The logic for the code is as follows\nread interrupt read register UIIR if error occurred, read ULSR read URBR, if data is recd. This will clear the UIIR write to UTHR, if FIFO is empty. This will clear the UIIR #define lastThreeBits\t(1 \u0026lt;\u0026lt; 3) | (1 \u0026lt;\u0026lt; 2) | (1 \u0026lt;\u0026lt; 1) #define RxLineError\t(1 \u0026lt;\u0026lt; 2) | (1 \u0026lt;\u0026lt; 1) #define RxDataAvailable\t(1 \u0026lt;\u0026lt; 2) #define charTimeOut\t(1 \u0026lt;\u0026lt; 3) | (1 \u0026lt;\u0026lt; 2) #define uthrEmpty\t(1 \u0026lt;\u0026lt; 1) #define RFE\t(1 \u0026lt;\u0026lt; 7) #define FE\t(1 \u0026lt;\u0026lt; 3) #define TxEmpty (1 \u0026lt;\u0026lt; 6) #define TxHrEmpty (1 \u0026lt;\u0026lt; 5) void DuartISRHandler() { int oldlevel = intLock();\t// let us lock interrupts unsigned char regUIIR = *UIIR; switch(regUIIR \u0026amp; lastThreeBits) { // we handle both cases in the same fashion CASE RxLineError: CASE uthrEmpty: // ULSR gives us the status of the interrupt that just occurred on the DURAT. unsigned char regULSR = *ULSR; if(regULSR \u0026amp; RFE) { // Framing Error logMsg(\u0026#34;Framing Error DUART\u0026#34;); } if((regULSR \u0026amp; TxEmpty) || (regULSR \u0026amp; TxHrEmpty)) { // Tx is empty, we can write more to the device. if(gDuartStruct.writeCount \u0026gt; gDuartStruct.writePtr) { While(!(*UDSR \u0026amp; 2) \u0026amp;\u0026amp; (gDuartStruct.writeCount \u0026gt;= gDuartStruct.writePtr)) { *UTHR = writeBuf[gDuartStruct.writeCount++]; gDuartStruct.writeCount %= BUF_SIZE; } } if(gDuartStruct.writeCount \u0026lt;= gDuartStruct.writePtr) { while(!(*UDSR \u0026amp; 2) \u0026amp;\u0026amp;(gDuartStruct.writeCount \u0026lt;= gDuartStruct.writePtr)) { *UTHR = writeBuf[gDuartStruct.writeCount++]; } } // indicate to the user that write buffer can be filled. semGive(gDuartStruct.getWRAcess); } break; // end case CASE RxDataAvailable: if(gDuartStruct.readPtr \u0026gt; gDuartStruct.readCount) { while(!(*UDSR \u0026amp; 1) \u0026amp;\u0026amp; (gDuartStruct.readPtr \u0026gt; gDuartStruct.readCount)) { readBuf[gDuartStruct.readPtr++] = *URBR; gDuartStruct.readPtr %= BUF_SIZE; } } if(gDuartStruct.readPtr \u0026lt; gDuartStruct.readCount) { while(!(*UDSR \u0026amp; 1) \u0026amp;\u0026amp; (gDuartStruct.readCount \u0026gt;= gDuartStruct.readPtr)) { readBuf[gDuartStruct.readPtr++] = *URBR; } } // indicate to the user that read buffer has more data. semGive(gDuartStruct.getRDAcess); } intUnlock(oldlevel); // re-enable interrupts } Once we left the ISR, the kernel will call EOI (end of Interrupt) and will notify the CPU.\nIn the real world however, many times you will not be using all the interface functions. So your design will not involve adding a device (iosDevAdd), installing interfaces (iosDrvInstall) etc,.\nYou directly declare your ISR and connect it to a particular vector. After that you can communicate to your device back and forth via interrupts and via user task that processes the responses from the ISR.\nHere is a diagram which helps you understand more clearly.\nUser Interaction with a driver # Once you have compiled your driver module, you can link it statically or load it dynamically.\nFor the DUART driver to be used, you have to install the device and add the device. You can modify your DuartInit routine to automatically call DuartCreate function.\nfd = DuartCreate(\u0026#34;/duart0\u0026#34;); Make sure your DuartInit is called during your system initialization, say at the end of SysHardwareInit()\nWrite a user application to use the duart by using the following code.\nOpen the device with required permissions.\nif((fd=open(\u0026#34;/duart0\u0026#34;, O_RDWR, 0666)) == ERROR) { } else { // you can read and write to the device write(fd, buf, size); read(fd, buf, size); close(fd); } For debugging your driver, connect your Tornado and use GDB.\nAdvanced Topics # Context Switching # When the scheduler preempts a task it has to store the current state of the task in task\u0026rsquo;s context storage area and will retrieve it later when the task is resumed. The current runnable tasks context is retrieved. This process of switching the contexts is called task switching or context switching.\nThe highest priority task always runs till it requires no CPU time. Higher priority tasks that are made ready preempt the currently executing task. A context switch can occur by the currently executing task relinquishing control, or a higher priority task becoming ready. A currently executing task can relinquish control via a blocking call, which suspends task execution until the blocking requirement is met, or if a timeout of a blocking call invoked by a higher priority task occurs. A higher priority task may become available also via a blocking call requirement fulfilled resulting in the operating system performing a context switch, or a timeout on a blocking call occurring as previously mentioned. Interrupt handlers and currently executing tasks are common ways to initiate a context switch that results in the execution of a higher priority task. Interrupt Service Routines (ISR) do not have a persistent context. ISRs have a transient execution context that executes at a higher priority than a task. Therefore, interrupt handlers preempt a task irrespective of the task\u0026rsquo;s priority. Due to the transient nature of ISRs, they should not perform any blocking operation and therefore can not invoke a system call, or any routine, that does such. An ISR that attempts to block will more than likely result with the system in a deadlock state. Therefore special attention should be given to any calls made, or actions taken, from within the context of an ISR. It is possible for an ISR to preempt another ISR, however this is board dependent and may not be allowed. The handling of the hardware interrupt, that in turn invokes the ISR registered for the interrupt, is board specific and is performed by the board support package software (BSP). VxWorks provides an API that allows the developer to register an ISR with the BSP\u0026rsquo;s board specific handler. This abstraction layer allows for board specific code to be segregated from the remainder of the application thus allowing for easier porting to new board types. You can tell the system not to preempt your code by using taskLock() and release it later once you finished your critical section code using taskUnlock(). Note this is not a suggested mechanism, as your code cannot be interrupted. Also this might lead to unacceptable real time behavior, because a higher priority task can preempt a lower priority task that locked itself. Reentrancy # If a piece of code can be used by more then one task without the fear of data corruption, then it is said to be Reentrant. A reentrant function can be interrupted at any time and resumed latter without loss or corruption of data.\nTo achieve reentrancy, use either local variables (i.e variables on stack rather then on heap, and CPU registers etc.,) or treat the code as critical section and protect the data. Most library routines are reentrant within VxWorks. If a function ends with _r(), then it is non reentrant.\nPriority inheritance # Assume three tasks t1, t2, t3 with task priorities p1, p2, p3 such that p1 \u0026gt; p2 \u0026gt; p3. If task t3 is currently executing and holds access to shared resource s1 (ex. by holding a semaphore sem1), and if t1 preempts t3 and wants to access s1 via the sem1, t1 will be suspended as soon as it wants to access sem1, which is held by t3. So to prevent deadlock, priority of task t3 will be made greater than or equal to that of t1 (i.e p3 \u0026gt;= p1) till t3 gives the semaphore and relinquishes it\u0026rsquo;s access to s1. Tasks t2 and t1 cannot preempt t3 until t3 gives sem1.\nTo support priority inversion, RTOS should support dynamic priorities.\nAddress space # In VxWorks, all code and text live together in a single address space. (VxWorks has come up with new version called AE which has different user and kernel address spaces). So if your code is poorly written, it can actually enter the kernel text and corrupt the OS, which can cause some serious problems. Having a single common address space improves the performance of your system. When you are using virtual memory, you still have to map between virtual and physical memory within your driver.\nCache Coherency # Depending upon your processor and BSP design, typically CPU caches data and instructions for improved performance. If you are DMAing data between your device and RAM, then your driver should guarantee cache coherency. This is typically done in two ways.\nMark a portion of memory within your RAM as non-cachable. Allocate cache safe buffers from this memory. Alternatively, use cacheFlush() and cacheInvalidate() routines provided by VxWorks. If Device is reading data from RAM, first flush the cache and then read data. If Device is writing to RAM, write to RAM and then invalidate the cache immediately. This way CPU\u0026rsquo;s cache will be in sync with RAM. Implementing Select Call # Select call lets your driver support multiple devices and a task can wait on all or some of these devices at the same time for at least one of the devices to be ready for IO. These tasks can specify timeout period for the devices to become ready.\nMost of the functionality for select call is supported in selectLib library. Your ioctl() is called whenever user calls select() with an argument FIOSELECT. To support select() call,\nDeclare SEL_WAKEUP_LIST as part of your device descriptor structure and initialize it by calling selWakeupList within your xxDevCreate() routine. Add SEL_WAKEUP_NODE, which is the third argument to your ioctl(), to the wakeup list. Use selWakeupType to determine if the task is waiting for read or write. If the device is ready, call selWakeupAll, to unblock all tasks waiting. Implement FIOUNSELECT to delete a node ","date":"2024-10-05","externalUrl":null,"permalink":"/bsp/vxworks-5-4-device-driver-development/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003ePreface \n    \u003cdiv id=\"preface\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#preface\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThis guide is for device driver developers, who have general background in real time operating systems. This guide addresses device driver development using VxWorks 5.4/Tornado 2.0.\u003c/p\u003e","title":"VxWorks 5.4 Device Driver Development","type":"bsp"},{"content":" Running VxWorks on Zynq-7000: BSP Setup and Boot Process\nThe Zynq-7000 All Programmable SoC integrates a dual-core ARM Cortex-A9 processing system with FPGA programmable logic. This architecture allows developers to combine software and hardware acceleration in a single device.\nVxWorks provides a stable real-time operating system platform for Zynq devices, supporting both SMP and AMP configurations. With the appropriate BSP and boot configuration, VxWorks can run efficiently on Zynq development boards such as the ZC702.\nThis guide explains how to build and run the VxWorks 6.9 BSP for the Zynq-7000 platform, including:\nZynq boot architecture Building the VxWorks kernel and bootloader Booting from SD card and FTP Building and debugging applications Accessing peripherals in both the Processing System (PS) and Programmable Logic (PL) 🎯 Learning Objectives # After completing this guide, you will be able to:\nUnderstand the Zynq-7000 boot architecture Build a VxWorks kernel image using the Zynq BSP Configure a bootloader and boot image Boot VxWorks from SD card or FTP Build and deploy kernel modules Access memory-mapped peripherals in both PS and PL 📋 Overview of VxWorks on Zynq-7000 # VxWorks from Wind River is a high-performance real-time operating system designed for embedded systems.\nKey characteristics include:\nDeterministic real-time scheduling Modular architecture with configurable components Support for multiple processor architectures Built-in networking, storage, and debugging tools For the Zynq-7000 platform, VxWorks supports:\nARM Cortex-A9 dual-core processors Symmetric Multiprocessing (SMP) Asymmetric Multiprocessing (AMP) Integration with FPGA-based peripherals This document serves as a practical starting point for developers deploying VxWorks on Zynq hardware.\n🧩 Hardware and Software Requirements # Software Requirements # You will need the following development tools:\nXilinx ISE Design Suite 14.6 or Vivado 2013.2 Wind River Workbench with VxWorks 6.9.3 Serial terminal software (for example Tera Term) Hardware Requirements # The reference platform used in this guide:\nXilinx ZC702 development board Ethernet cable USB-UART cable SD card 🏗️ Zynq-7000 Boot Architecture # Unlike traditional FPGA devices, the Zynq architecture uses the ARM processing system to control device configuration.\nBooting a Zynq device typically involves three stages.\nStage 0 — BootROM # After power-on reset, the CPU executes code stored in the on-chip BootROM.\nBootROM responsibilities include:\nSelecting the boot device Loading the first boot image Supporting secure and non-secure boot Providing basic drivers for NAND, NOR, QSPI, and SD Boot mode is determined by hardware configuration pins, which are sampled during reset and stored in the BOOT_MODE register.\nSupported boot sources include:\nNAND NOR Quad-SPI SD card JTAG BootROM loads the First Stage Bootloader (FSBL) into on-chip memory before transferring control.\nStage 1 — First Stage Bootloader (FSBL) # The FSBL is responsible for initializing the system hardware.\nTypical FSBL responsibilities include:\nInitializing DDR memory Configuring the processing system Programming the programmable logic (bitstream) Loading the second-stage bootloader or application Before transferring control, the FSBL disables the cache and MMU to ensure compatibility with operating systems such as Linux or VxWorks.\nStage 2 — VxWorks Bootloader # The VxWorks bootloader loads the operating system image into memory.\nFeatures of the VxWorks bootloader include:\nInteractive boot configuration Network boot support File system loading Boot parameter configuration Unlike self-booting images used in production systems, a bootloader is particularly useful during development because it allows the OS image to be downloaded from a host system.\n⚙️ Preparing the Development Environment # Install the VxWorks development environment and ensure the Zynq BSP is available.\nSteps:\nInstall the VxWorks 6.9.3.1 toolchain Install the Base Tools Package Use the Product Maintenance tool to update installed components Verify that the Zynq-7000 BSP is installed Apply the latest BSP patches provided by Wind River Keeping BSP patches up to date is important because vendor BSPs often receive asynchronous driver updates.\n🛠️ Enabling SD Card Support in the BSP # The default BSP configuration does not enable SD card storage.\nEdit the BSP configuration file:\ntarget/config/xlnx_zynq7k/config.h Locate the following line:\n#undef DRV_STORAGE_SDHC Enable SD storage and DOS file system support:\n#define DRV_STORAGE_SDHC #define INCLUDE_DOSFS #define INCLUDE_DOSFS_MAIN #define INCLUDE_DOSFS_CHKDSK #define INCLUDE_DOSFS_FMT #define INCLUDE_DOSFS_FAT #define INCLUDE_DOSFS_SHOW #define INCLUDE_DOSFS_DIR_VFAT #define INCLUDE_DOSFS_DIR_FIXED #define INCLUDE_FS_MONITOR #define INCLUDE_FS_EVENT_UTIL #define INCLUDE_ERF #define INCLUDE_XBD #define INCLUDE_XBD_BLKDEV #define INCLUDE_XBD_TRANS #define INCLUDE_DEVICE_MANAGER #define INCLUDE_XBD_BLK_DEV #define INCLUDE_XBD_PART_LIB #define INCLUDE_DISK_UTIL This configuration enables:\nSDHC storage driver FAT file system support Disk management utilities 🧱 Building the VxWorks Kernel Image # To create a VxWorks kernel image using Wind River Workbench:\nLaunch Wind River Workbench Select File → New → Project Choose VxWorks Image Project Select the BSP: xlnx_zynq7k Choose the PROFILE_DEVELOPMENT configuration Enable symbol table support in the kernel configuration Build the project The resulting VxWorks kernel image is generated in:\n\u0026lt;project\u0026gt;/default/ 🔧 Building the BootROM Image # Next, build the VxWorks bootloader.\nFrom a VxWorks development shell:\ncd \u0026lt;install_dir\u0026gt;/vxworks-6.9/target/config/xlnx_zynq7k make clean make bootROM Rename the output file:\nbootROM → bootROM.elf 📦 Creating the Boot Image # Create a boot.bif file that defines the boot image layout.\nZC702_boot_image: { [bootloader] zynq_fsbl_0.elf bootROM.elf } Generate the final boot image using the Xilinx bootgen tool:\nbootgen -image boot.bif -o BOOT.BIN -w Copy the following files to the SD card:\nBOOT.BIN vxWorks 💾 Booting VxWorks from SD Card # To boot the ZC702 board from an SD card:\nInsert the SD card into the board Configure the board boot switches for SD boot Connect UART and Ethernet cables Open a serial terminal: Baud rate: 115200 Power on the board Interrupt the boot process by pressing Enter The bootloader prompt appears.\nConfigure boot parameters:\nboot device: fs file name: /sd0:1/vxWorks Start the boot process:\n@ To verify system operation, display running tasks:\n-\u0026gt; i 🌐 Booting VxWorks Using FTP # VxWorks can also load the kernel image from a host machine.\nConfigure the host network:\nHost IP: 192.168.1.1 Target IP: 192.168.1.2 Start an FTP server and create a user account.\nAt the boot prompt configure parameters:\nboot device: gem0 file name: vxWorks inet on ethernet: 192.168.1.2:ffffff00 host inet: 192.168.1.1 Start the boot process:\n@ The kernel image will be downloaded from the FTP server.\n🧪 Building and Running a Hello World Application # Create a Downloadable Kernel Module (DKM) project in Workbench.\nExample source file:\n#include \u0026lt;stdio.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; void helloTask(void) { printf(\u0026#34;Hello Wind River\\n\u0026#34;); } void helloStart(void) { taskSpawn( \u0026#34;tHello\u0026#34;, 100, 0, 4096, (FUNCPTR)helloTask, 0,0,0,0,0,0,0,0,0,0); } After building the module, load and execute it from the target shell:\n-\u0026gt; ld \u0026lt; hello.out -\u0026gt; helloStart Expected output:\nHello Wind River 💡 Accessing Processing System GPIO # Peripherals in the Zynq Processing System are memory mapped.\nExample: toggle LED connected to MIO pin 10.\n#include \u0026lt;stdio.h\u0026gt; #include \u0026lt;unistd.h\u0026gt; #include \u0026lt;sysLib.h\u0026gt; #define GPIO_BASE 0xE000A000 #define GPIO_DIRM_0 0x204 #define GPIO_OEN_0 0x208 #define GPIO_DATA_0 0x040 #define LED_MASK (1 \u0026lt;\u0026lt; 10) void gpioBlink(void) { UINT32 val = LED_MASK; sysOutLong(GPIO_BASE + GPIO_DIRM_0, LED_MASK); sysOutLong(GPIO_BASE + GPIO_OEN_0, LED_MASK); while (1) { sysOutLong(GPIO_BASE + GPIO_DATA_0, val); taskDelay(sysClkRateGet()); val ^= LED_MASK; } } This example toggles the LED once per second.\n🔌 Accessing Programmable Logic Peripherals # Custom peripherals implemented in FPGA logic are accessed through AXI memory regions.\nExample AXI GPIO driver:\n#include \u0026lt;stdio.h\u0026gt; #include \u0026lt;taskLib.h\u0026gt; #include \u0026lt;sysLib.h\u0026gt; #define AXI_GPIO_BASE 0x41200000 #define AXI_GPIO_DATA 0x00 #define AXI_GPIO_TRI 0x04 void axiGpioDemo(void) { UINT32 val = 0; sysOutLong(AXI_GPIO_BASE + AXI_GPIO_TRI, 0x0); while (1) { sysOutLong(AXI_GPIO_BASE + AXI_GPIO_DATA, val); printf(\u0026#34;GPIO value: %u\\n\u0026#34;, val); val++; taskDelay(sysClkRateGet()); } } Before accessing this peripheral, its address range must be added to the BSP MMU configuration.\nExample MMU mapping entry:\n{ 0x41200000, 0x41200000, PAGE_SIZE, MMU_ATTR_VALID_MSK | MMU_ATTR_PROT_MSK | MMU_ATTR_DEVICE_SHARED_MSK, MMU_ATTR_VALID | MMU_ATTR_SUP_RWX | MMU_ATTR_DEVICE_SHARED }, After rebuilding the kernel, the PL peripheral becomes accessible to VxWorks applications.\n🧾 Conclusion # Running VxWorks on the Zynq-7000 platform involves several coordinated steps:\nUnderstanding the BootROM → FSBL → Bootloader startup sequence Building the VxWorks kernel and bootloader Generating a boot image using bootgen Booting the system from SD card or FTP Developing applications using Downloadable Kernel Modules Once the environment is configured, developers can leverage both the ARM processing system and FPGA programmable logic to build powerful real-time embedded systems.\nThis combination of VxWorks reliability and Zynq heterogeneous architecture provides a flexible platform for advanced embedded designs.\n","date":"2024-10-05","externalUrl":null,"permalink":"/bsp/using-vxworks-bsp-with-zynq-7000-ap-soc/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eRunning VxWorks on Zynq-7000: BSP Setup and Boot Process\u003c/p\u003e\u003c/blockquote\u003e\n\u003cscript async src=\"https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1543398821442998\"\n     crossorigin=\"anonymous\"\u003e\u003c/script\u003e\n\u003c!-- vxworks6_ads_1 --\u003e\n\u003cp\u003e\u003cins class=\"adsbygoogle\"\nstyle=\"display:block\"\ndata-ad-client=\"ca-pub-1543398821442998\"\ndata-ad-slot=\"7693617958\"\ndata-ad-format=\"auto\"\ndata-full-width-responsive=\"true\"\u003e\u003c/ins\u003e\u003c/p\u003e\n\u003cscript\u003e\n     (adsbygoogle = window.adsbygoogle || []).push({});\n\u003c/script\u003e\n\u003cp\u003eThe \u003cstrong\u003eZynq-7000 All Programmable SoC\u003c/strong\u003e integrates a dual-core ARM Cortex-A9 processing system with FPGA programmable logic. This architecture allows developers to combine software and hardware acceleration in a single device.\u003c/p\u003e","title":"Running VxWorks 6.9 on Zynq-7000: BSP Setup and Boot Guide","type":"bsp"},{"content":"All product names, logos, brands, trademarks (®), and service marks (SM) appearing on this website are the property of their respective owners.\nWind River and VxWorks are registered trademarks of Wind River Systems, Inc. The Wind River logo is a trademark of Wind River Systems, Inc. Any other trademarks, registered trademarks, product names, or company names mentioned on this site are the property of their respective owners. Use of these names, logos, and brands does not imply endorsement or affiliation with their respective owners. They are referenced only for identification and informational purposes.\nThis website is an independent resource and is not affiliated with, sponsored by, or endorsed by Wind River Systems, Inc. or any other trademark holder.\nPlease check below Legal Disclaimer for more.\n","date":"2024-10-04","externalUrl":null,"permalink":"/compliance/","section":"Compliance and Trademark Declaration","summary":"\u003cp\u003eAll product names, logos, brands, trademarks (®), and service marks (SM) appearing on this website are the property of their respective owners.\u003c/p\u003e","title":"Compliance and Trademark Declaration","type":"compliance"},{"content":"","date":"2024-10-04","externalUrl":null,"permalink":"/tags/copyright/","section":"Tags","summary":"","title":"Copyright","type":"tags"},{"content":"","date":"2024-10-04","externalUrl":null,"permalink":"/tags/developer-community/","section":"Tags","summary":"","title":"Developer Community","type":"tags"},{"content":"","date":"2024-10-04","externalUrl":null,"permalink":"/tags/trademark/","section":"Tags","summary":"","title":"Trademark","type":"tags"},{"content":"","date":"2024-10-04","externalUrl":null,"permalink":"/tags/vxworks-5/","section":"Tags","summary":"","title":"VxWorks 5","type":"tags"},{"content":"","date":"2024-10-04","externalUrl":null,"permalink":"/tags/vxworks-6/","section":"Tags","summary":"","title":"VxWorks 6","type":"tags"},{"content":" vxworks.net is a worldwide community for VxWorks enthusiasts, where users and developers come together to share experiences, discuss technical challenges, and collaborate on innovative solutions. ","date":"2024-10-04","externalUrl":null,"permalink":"/","section":"WHEN IT MATTERS, IT RUNS ON RTOS.","summary":"\u003cblockquote\u003e\nvxworks.net is a worldwide community for VxWorks enthusiasts, where users and developers come together to share experiences, discuss technical challenges, and collaborate on innovative solutions.\n\u003c/blockquote\u003e","title":"WHEN IT MATTERS, IT RUNS ON RTOS.","type":"page"},{"content":" 🚗 VxWorks \u0026amp; TI Boost Automotive Edge AI # Artificial Intelligence (AI) and Machine Learning (ML) are redefining the automotive industry. As vehicles evolve into intelligent, software-defined systems, real-time operating systems (RTOS) like VxWorks and high-performance processors such as Texas Instruments’ TDA4VH-Q1 are driving the next leap forward in automotive edge AI computing. Together, they enable advanced driver-assistance systems (ADAS), autonomous navigation, and real-time perception with unparalleled reliability and speed.\n🌐 The Rise of AI/ML in Automotive Embedded Systems # Modern vehicles rely on dozens of sensors—cameras, radar, lidar, and ultrasonic systems—generating massive volumes of data. To process this data instantly and safely, automakers are embedding AI/ML algorithms directly into edge devices.\nThese technologies power:\nADAS and autonomous driving systems Predictive maintenance and condition monitoring Personalized vehicle experiences and smart insurance Real-time video analytics and sensor fusion Edge-to-cloud data optimization and decision-making As the automotive landscape moves toward autonomy and intelligence, edge AI becomes essential for reducing latency, enhancing safety, and ensuring deterministic performance.\n⚙️ VxWorks — The Real-Time Foundation for Intelligent Mobility # Wind River VxWorks is the most widely deployed real-time operating system for mission-critical embedded systems. Known for its deterministic performance, scalability, and safety certifications, VxWorks provides a robust foundation for automotive AI and ML integration.\nKey Features for AI/ML Development # TensorFlow Lite integration – Efficiently deploy ML models in constrained environments Python-based analytics libraries – Includes Pandas and NumPy for data processing Cloud-ready design – Runs on Amazon Cloud and supports containerized deployment with Kubernetes DevSecOps and CI/CD integration – Streamlines secure, agile software delivery By bridging the gap between embedded performance and modern cloud workflows, VxWorks empowers developers to innovate faster while maintaining safety and reliability.\n🔩 TI TDA4VH-Q1 — The Power Behind Automotive Edge AI # At the hardware layer, the Texas Instruments (TI) TDA4VH-Q1 System-on-Chip (SoC) delivers the performance needed for autonomous and ADAS systems. Featuring integrated graphics, AI acceleration, and vision coprocessing, it supports sensor fusion and real-time decision-making at the edge.\nTechnical Highlights # 8× Arm® Cortex®-A72 cores for application-level processing 6× Arm® Cortex®-R5F coprocessors for real-time operations Built-in deep learning accelerators for efficient ML inference TIOVX (OpenVX-compliant) framework for optimized vision workloads High-speed interfaces: CAN, Ethernet, PCIe, USB This architecture enables Level 2/3 autonomous driving capabilities, supporting energy-efficient computation and seamless connectivity with automotive peripherals.\n🚘 VxWorks + TI: A Platform for Automotive AI Innovation # The latest version of VxWorks adds integrated support for the TI Deep Learning (TIDL) library, empowering developers to deploy Convolutional Neural Networks (CNNs) for computer vision directly on TI hardware. Alongside TIOVX, this enables high-efficiency, low-latency AI acceleration.\nReal-World Applications # ADAS and Autonomous Driving – Real-time image recognition, obstacle detection, and decision-making Advanced Imaging – Surround-view, driver monitoring, and 3D vision systems Automotive Connectivity – Robust integration of CAN, Ethernet, and PCIe networks Functional Safety and Security – ASIL-D certified safety features and secure boot mechanisms Automotive-Grade Reliability – Meets strict standards for temperature, endurance, and quality By combining VxWorks’ real-time precision with TI’s hardware intelligence, developers gain a complete, scalable platform for next-generation automotive AI and ML applications.\n🔗 Learn More # Explore resources to get started with VxWorks and TI automotive AI solutions:\nWind River VxWorks Texas Instruments Automotive Processors VxWorks and TI Collaboration News TensorFlow Lite VxWorks + TI = Real-Time Intelligence for the Autonomous Era.\nTogether, they are shaping the future of connected, intelligent, and software-defined vehicles.\n","date":"2024-08-19","externalUrl":null,"permalink":"/news/vxworks-and-ti-boost-automotive-edge-ai/","section":"News","summary":"\u003ch2 class=\"relative group\"\u003e🚗 VxWorks \u0026amp; TI Boost Automotive Edge AI \n    \u003cdiv id=\"-vxworks--ti-boost-automotive-edge-ai\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-vxworks--ti-boost-automotive-edge-ai\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eArtificial Intelligence (AI) and Machine Learning (ML) are redefining the automotive industry. As vehicles evolve into intelligent, software-defined systems, real-time operating systems (RTOS) like \u003cstrong\u003eVxWorks\u003c/strong\u003e and high-performance processors such as \u003cstrong\u003eTexas Instruments’ TDA4VH-Q1\u003c/strong\u003e are driving the next leap forward in \u003cstrong\u003eautomotive edge AI computing\u003c/strong\u003e. Together, they enable advanced driver-assistance systems (ADAS), autonomous navigation, and real-time perception with unparalleled reliability and speed.\u003c/p\u003e","title":"VxWorks \u0026 TI Boost Automotive Edge AI","type":"news"},{"content":" Key Topics:\nOverview of Wind River VxWorks capabilities and advantages Comparison of QNX and VxWorks features and architecture Step-by-step migration strategies and methodologies Real-world case studies and success stories Q\u0026amp;A session with our migration experts ","date":"2024-08-14","externalUrl":null,"permalink":"/video/seamless-rtos-transition-migrating-to-vxworks/","section":"Videoes","summary":"\u003clite-youtube videoid=\"kU2Vkz53l9A\" playlabel=\"kU2Vkz53l9A\" params=\"\"\u003e\u003c/lite-youtube\u003e\n\n\u003cp\u003e\u003cb\u003eKey Topics:\u003c/b\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eOverview of Wind River VxWorks capabilities and advantages\u003c/li\u003e\n\u003cli\u003eComparison of QNX and VxWorks features and architecture\u003c/li\u003e\n\u003cli\u003eStep-by-step migration strategies and methodologies\u003c/li\u003e\n\u003cli\u003eReal-world case studies and success stories\u003c/li\u003e\n\u003cli\u003eQ\u0026amp;A session with our migration experts\u003c/li\u003e\n\u003c/ul\u003e","title":"Seamless RTOS Transition - Migrating to VxWorks","type":"video"},{"content":"For embedded systems development teams, a real-time operating system (RTOS) is a major investment — in cost, in training for developers, and in maintenance and upgrades. A decision to migrate from one RTOS to another is obviously not a step undertaken lightly. Here we briefly examine some of the dynamics in modern embedded systems development and how catering to these is crucial in the forward thinking needed for a migration decision.\nOur webinar “Seamless RTOS Transition: Migrating to VxWorks” explores the case for migration, its key technical considerations, and the world beyond migration with ongoing Wind River support.\nReal-Time Embedded Systems Development: A Changing World # QNX and VxWorks® are both stalwarts in the embedded systems domain, each with strengths and a dedicated user base, and both are navigating a modern embedded systems development world that is undergoing change.\nTime-to-Market Is Crucial # Modern embedded systems engineering teams are increasingly adopting IT-like methodologies and approaches, such as “shift-left” to bring software testing into the development lifecycle earlier while also minimizing dependence on difficult-to-procure hardware. DevSecOps principles are becoming more commonplace, ensuring a strong security focus, improved team collaboration and efficiencies, and streamlined delivery and deployment. Additionally, the use of OCI-compliant containers and container orchestration helps remove manual errors, standardize tools, and accelerate the rate of product iterations.\nThe RTOS for these modern teams must have all these capabilities, via the appropriate cloud-based technologies. These are key aspects of VxWorks with AWS Graviton support for shift-left, Wind River® Studio Developer for DevSecOps, and OCI-compliant container and Kubernetes support for efficient deployment and operation.\nTeams considering migration need to factor in these forward-looking methods of achieving improved time-to-market.\nEnabling High-Performance Functions Is Key # Intelligent edge systems increasingly require high-performance capabilities. Cost-effective integration of AI/ML capability is one such requirement. Another is Time-Sensitive Networking (TSN), which ensures that high-priority mission-critical data is not delayed or dropped when combined with lower-priority data on the Ethernet network that connects system modules, components, and devices.\nSupporting this natively in the RTOS is the approach taken with VxWorks, which facilitates this without relying on third-party support. With TSN capability rapidly becoming a default requirement, development teams need to carefully consider how their RTOS provides it.\nScalability Is a Norm # Advances in silicon technology not only bring multi-core processors but also new processor architectures. It’s important that an RTOS vendor maintains and grows its list of supported boards from major vendors.\nThe need for a system to scale for mixed-criticality use cases (performing safety-critical and non–safety-critical functions while isolating them from each other) has become common. High-performance hypervisor technology, such as Wind River Helix™ Virtualization Platform, allows VxWorks and other guest operating systems to meet the demands of mixed criticality.\nThe Emphasis on Safety and Security Will Only Increase # The engineering lifecycle of the RTOS itself needs close consideration. A secure development lifecycle, enforced by policy and implemented with processes and procedures such as those defined by NIST SP800-218, fosters trust in a product that is considered secure by design. CVE tracking and mitigation of vulnerabilities is also critical for ongoing use.\nFunctional safety certification per the relevant industry, be it aerospace and defense, automotive, medical, or wider industrial safety, are crucial for any RTOS. Engineering teams must be able to achieve certification of their designs cost-effectively.\nThese safety and security design considerations are front and center in every release of VxWorks.\n​​​​​​​It’s No Longer Only About Real Time # Embedded systems increasingly are also running Linux operating systems for non–real-time applications. A one-stop shop that brings industry-leading RTOS and Linux products into one portfolio is increasingly attractive. A migration decision should factor in the potential savings in cost and engineering time when dealing with a single-vendor solution.\n​​​​​​​Old School Hype: A Thing of the Past # It’s important to put some modern-day context around certain well-worn phrases and debates, to ensure that these do not influence decisions about RTOS migration.\n​​​​​​​Determinism Is Table Stakes # The very nature of a real-time embedded system for mission-critical deployment — the braking system in a car, controlling robotic movement on a factory floor, aircraft or spacecraft flight/weapons control — these all demand a repeatable, predictable response within strictly defined time parameters, for a given set of conditions. Nothing else is acceptable. So determinism, while essential, is a much-marketed phrase in the RTOS world and really isn’t a topic of debate.\n​​​​​​​RTOS Architecture Is Largely Irrelevant # Seasoned embedded systems developers know well the “microkernel versus monolithic” debate when it comes to RTOS architectures. Arguments will always be made as to which is superior, and an opinionated, computer science-oriented debate often ensues. At such times it can be argued that the VxWorks monolithic architecture is superior. In reality, however, it is the system specification, deployment, application software design, and silicon/electronics that determine system performance. That’s what matters, not what’s under the hood of the RTOS. That’s a topic very much past its sell-by date.\nA New World Awaits: A Time to Explore # Our experts delve into technical detail in the above areas and more, including libraries and dependencies, system services, and hardware drivers. They explain how seamless the migration process can be, with Wind River backing you every step of the way.\nWhether you’re an embedded systems engineer, project manager, or decision-maker, this webinar will help you understand the benefits migration could bring to your teams. Further, it will equip you with practical knowledge and strategies to ensure a successful migration and maximized performance of your embedded applications.\n","date":"2024-07-15","externalUrl":null,"permalink":"/news/switching-gears-moving-systems-to-vxworks-from-qnx/","section":"News","summary":"\u003cp\u003eFor embedded systems development teams, a real-time operating system (RTOS) is a major investment — in cost, in training for developers, and in maintenance and upgrades. A decision to migrate from one RTOS to another is obviously not a step undertaken lightly. Here we briefly examine some of the dynamics in modern embedded systems development and how catering to these is crucial in the forward thinking needed for a migration decision.\u003c/p\u003e","title":"Switching Gears Moving Systems to VxWorks From QNX","type":"news"},{"content":"","date":"2024-05-04","externalUrl":null,"permalink":"/tags/assessment/","section":"Tags","summary":"","title":"Assessment","type":"tags"},{"content":"","date":"2024-05-04","externalUrl":null,"permalink":"/tags/simulation-training/","section":"Tags","summary":"","title":"Simulation Training","type":"tags"},{"content":"","date":"2024-05-04","externalUrl":null,"permalink":"/tags/training-systems/","section":"Tags","summary":"","title":"Training Systems","type":"tags"},{"content":" VxWorks Simulation Training System Using VMware Virtualization\nTraining engineers on embedded VxWorks systems deployed in real-world platforms presents significant operational and logistical challenges. Physical hardware is costly, difficult to maintain, and often unsuitable for large-scale or distributed training.\nThis article presents a virtualization-based simulation training system that replicates real VxWorks environments using VMware, enabling scalable, cost-effective, and realistic training and assessment.\n⚙️ Background and Challenges # As VxWorks-based systems become widely deployed across vehicle platforms, demand has increased for:\nSoftware installation and maintenance training Operator skill development Joint operational exercises Limitations of Hardware-Based Training # Complex installation and maintenance procedures Limited accessibility due to harsh operating environments High equipment and maintenance costs Restricted training scale and geographic reach Difficulty in standardizing training content and evaluation These constraints necessitate a more flexible and scalable training solution.\n🧩 System Architecture # The simulation training system adopts a client-server architecture.\nCore Components # Server # Manages training templates and scenarios Distributes simulation data to terminals Collects training results Generates performance evaluation reports Simulation Training Terminals # Each terminal runs on a standard PC and includes:\nVirtualized VxWorks environment Operational application modules Training support system (guidance, simulation data) Evaluation system (automated and manual assessment) All components are interconnected via a network to support synchronized training.\n🖥️ Virtualization with VMware # Cross-Platform Execution # VMware enables VxWorks to run on standard Windows hosts by simulating a compatible hardware environment.\nKey benefits:\nEliminates dependency on physical target hardware Simplifies deployment and setup Ensures consistent training environments Virtual Machine Image Deployment # Pre-configured VxWorks images are created Images can be replicated across multiple machines Rapid provisioning of training environments Network Configuration # Bridged mode allows each VM to function as an independent node on the network Unique MAC addresses are assigned per VM instance Ensures reliable communication between training terminals 📚 Digitized Training Content # Training scenarios are standardized and managed centrally.\nWorkflow # Server generates scenario-specific data Data is distributed to training terminals Terminals execute simulation tasks Results are fed back to the server This approach ensures:\nConsistency across training sessions Repeatable and controlled exercises Easy updates to training content 📊 Assessment and Evaluation System # The system integrates automated and manual evaluation mechanisms.\nAutomatic Assessment # Captures user operations and system events Records input/output interactions Evaluates performance against predefined criteria Generates detailed feedback reports Manual Assessment # Supports record-and-replay functionality Enables expert review of training sessions Provides deeper qualitative analysis This hybrid approach ensures both objective scoring and expert validation.\n🚀 System Advantages # High Realism # Closely replicates actual VxWorks operational environments Supports real application workflows Scalability # Easily deployable across multiple terminals Supports distributed and large-scale training Cost Efficiency # Reduces reliance on expensive hardware Minimizes maintenance and operational costs Training Effectiveness # Accelerates learning through interactive simulation Enables full coverage of system functionalities Provides measurable performance feedback Flexibility # Rapid updates to training scenarios Adaptable to different platforms and use cases 🧾 Conclusion # The VxWorks simulation training system built on VMware virtualization provides a practical solution to the limitations of hardware-based training.\nBy combining virtualized environments, centralized scenario management, and integrated assessment tools, the system delivers:\nScalable and cost-effective training Realistic operational simulation Comprehensive performance evaluation This approach significantly enhances training efficiency and readiness for embedded VxWorks systems, particularly in complex deployment environments.\n","date":"2024-05-04","externalUrl":null,"permalink":"/training/vxworks-simulation-training-system-using-vmware-virtualization/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Simulation Training System Using VMware Virtualization\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eTraining engineers on embedded VxWorks systems deployed in real-world platforms presents significant operational and logistical challenges. Physical hardware is costly, difficult to maintain, and often unsuitable for large-scale or distributed training.\u003c/p\u003e","title":"VxWorks Simulation Training System Using VMware Virtualization","type":"training"},{"content":"","date":"2024-04-09","externalUrl":null,"permalink":"/tags/edge-to-cloud/","section":"Tags","summary":"","title":"Edge-to-Cloud","type":"tags"},{"content":"Wind River announced the latest release of Wind River Studio Developer, an edge-to-cloud DevSecOps platform that accelerates development, deployment, and operation of mission-critical systems.\nThe new enhancements and delivery models for Wind River Studio are designed to help software teams more easily and successfully adopt cloud-native development capabilities that match their ongoing journey toward DevSecOps approaches.\n“Wind River Studio Developer delivers a flexible and collaborative platform that addresses the dynamic needs surrounding the software driving the intelligent systems of the future. It helps solve the challenges of managing complexity in modern software development environments, using a cloud-native platform that helps improve efficiency, manage costs, increase quality, and accelerate delivery timeframes,” said Avijit Sinha, president, Wind River. “Unlike other DevSecOps platforms, Studio Developer was designed specifically for software teams developing embedded/edge software, saving them the time and hassle of adopting and maintaining generic software tools to fit their specific needs.”\nThe modular architecture of Studio Developer allows software teams to use Studio with the software tools, operating systems, containers, and middleware that they have today, integrating them with the Studio DevSecOps environment. The modules that are now available either adopted individually or as part of a complete solution, include the following:\nWind River Studio Pipelines: Enables automation and orchestration of continuous build, test, integration, and deployment processes using multi-stage pipelines.\nWind River Studio Virtual Lab: Provides cloud-based access and sharing of virtual and physical development devices for testing and debugging.\nWind River Studio Test Automation: Standardizes and shares test suites and plans for systems, applications, and components so that teams can easily automate and scale the execution of existing test suites across environments.\nWind River Studio Over-the-Air Updates: Manages multi-tier update campaigns for over-the-air deployment to fielded devices.\nWind River Studio Digital Feedback Loop: Establishes reliable connectivity between edge and cloud systems for real-time data collection and analytics.\nStudio Developer delivers improvements in software workflow productivity and efficiency by leveraging scalable cloud resources (on-demand)​, standardizing automation pipelines, allowing cloud-based collaboration on a shared platform, easy on-boarding​, and enhanced traceability throughout the software development process.\nStudio Developer can be hosted on public cloud or on-premises infrastructure. It is optimized to be installed and operated in an Amazon Web Services (AWS) environment, and Studio Developer is currently being showcased at the Santa Clara AWS Prototyping and Innovation Lab. It can also be deployed on other cloud services and on-premises infrastructure that provide a Kubernetes environment.\nAdditionally, Studio Developer is offered with a set of managed services that leverage the expertise and experience of the Wind River Professional Services team to accelerate the adoption and integration of Studio Developer, as well as manage cloud infrastructure, operate the environment, and maintain the security of the development platform through updates and upgrades.\n","date":"2024-04-09","externalUrl":null,"permalink":"/news/latest-release-of-wind-river-studio-developer-released/","section":"News","summary":"\u003cp\u003eWind River announced the latest release of \u003ca href=\"https://www.vxworks6.com/news/latest-release-of-wind-river-studio-developer-released/\" target=\"_blank\"\u003eWind River Studio Developer\u003c/a\u003e, an edge-to-cloud DevSecOps platform that accelerates development, deployment, and operation of mission-critical systems.\u003c/p\u003e","title":"Latest Release of Wind River Studio Developer Released","type":"news"},{"content":"","date":"2024-04-09","externalUrl":null,"permalink":"/series/news/","section":"Series","summary":"","title":"News","type":"series"},{"content":"","date":"2024-04-09","externalUrl":null,"permalink":"/tags/wind-river-studio-developer/","section":"Tags","summary":"","title":"Wind River Studio Developer","type":"tags"},{"content":"","date":"2024-04-02","externalUrl":null,"permalink":"/tags/opengl-es/","section":"Tags","summary":"","title":"OpenGL ES","type":"tags"},{"content":"","date":"2024-04-02","externalUrl":null,"permalink":"/tags/qt-6.7/","section":"Tags","summary":"","title":"Qt 6.7","type":"tags"},{"content":" Qt 6.7 on VxWorks 7: Architecture, EGLFS, and Build Guide\nQt 6.7 was released on April 2, 2024, introducing verified support for VxWorks 7 and providing an updated foundation for deploying Qt applications on embedded real-time systems.\nFor VxWorks developers, the key addition is support verified on VxWorks SR 23.09 with ARM-v7. Qt Widgets applications can run with POSIX and C++17 support, while Qt Quick 2 additionally requires GPU support compatible with OpenGL ES 2.0 through the VxWorks GPUDEV framework.\nThis article covers the supported VxWorks configuration, Qt modules, EGLFS platform integration, cross-compilation requirements, device-specific configuration, and deployment considerations for Qt 6.7.\n🧩 VxWorks Architecture and Version Support # Qt 6.7 has been verified against VxWorks SR 23.09 with the following architecture:\nComponent Supported Configuration Operating System VxWorks 7 VxWorks Release SR 23.09 Architecture ARM-v7 C++ Standard C++17 Graphics API for Qt Quick 2 OpenGL ES 2.0 Platform Plugin EGLFS The supported configuration is particularly relevant to embedded devices that need Qt\u0026rsquo;s application and UI framework while retaining VxWorks\u0026rsquo; real-time operating-system characteristics.\n⚙️ VxWorks System Requirements # Qt Widgets applications # Qt Widgets applications require:\nPOSIX support C++17 compiler support Qt Widgets can operate without a GPU because widget content can be rendered through the CPU when used with the appropriate platform configuration.\nQt Quick 2 applications # Qt Quick 2 requires all dependencies of Qt Widgets applications plus:\nA GPU device compatible with OpenGL ES 2.0 VxWorks GPUDEV support Appropriate EGL/OpenGL ES integration for the target hardware GPU availability is therefore an important distinction when selecting Qt Widgets versus Qt Quick for a VxWorks-based product.\n📦 Supported Qt Modules # Qt 6.7 provides support for the essential Qt modules required by typical application, networking, UI, QML, and testing workloads.\nEssential modules # Qt Module Supported Qt Core Yes Qt GUI Yes Qt Network Yes Qt Qml Yes Qt Quick Yes Qt Quick Controls Yes Qt Quick Dialogs Yes Qt Quick Layouts Yes Qt Quick Test Yes Qt Test Yes Qt Widgets Yes Add-on modules # The following Qt add-ons are also supported:\nQt Add-On Supported Qt Concurrent Yes Qt GRPC/Protobuf Yes Qt Graphs Yes Qt Image Formats Yes Qt Multimedia Yes Qt Native Interfaces Yes Qt OpenGL Yes Qt Quick 3D Yes Qt Quick Compiler Yes Qt Quick Effects Yes Qt SQL Yes Qt SVG Yes Qt Virtual Keyboard Yes Not every project needs the complete Qt module set. For embedded deployments, excluding unnecessary modules can reduce build time, storage requirements, and the resulting runtime footprint.\nThe Qt configuration system supports explicit module exclusion with:\n-skip \u0026lt;module\u0026gt; For example, an application that does not use Qt Multimedia can omit that module during configuration rather than building it into the target Qt installation.\n🖥️ Qt Platform Integration on VxWorks # Qt\u0026rsquo;s platform architecture changed substantially after Qt 5.0. Qt no longer provides its former QWS window-system implementation, and QWS is not supported in Qt 6.\nFor single-process embedded deployments, Qt Platform Abstraction (QPA) provides the appropriate integration layer.\nEGLFS # Qt 6 provides the EGLFS platform plugin for VxWorks devices.\nEGLFS allows Qt applications to operate directly on top of EGL and OpenGL ES without requiring a conventional windowing system such as X11 or Wayland. This makes it particularly suitable for embedded devices that boot directly into a dedicated graphical application.\nEGL provides the interface between OpenGL ES and the native platform, including graphics context and surface management. However, EGL does not define every platform-specific operation required to create and manage native display resources.\nConsequently, VxWorks boards and GPUs require platform-specific integration code.\nThis integration can be implemented through:\nEGLFS hooks compiled directly into the platform plugin Dynamically loaded EGL device integration plugins Vendor-specific EGL/OpenGL ES porting code The availability of EGLFS depends on how Qt is configured and built for the target platform.\nEGLFS rendering model # EGLFS is designed for devices where Qt controls the display directly rather than relying on a desktop-style window manager.\nIt supports:\nQt Quick 2 applications Native OpenGL applications CPU-rendered QWidget applications For software-rendered widgets, Qt can render widget content into an image using the CPU. EGLFS can then upload that content as a texture and composite it through the graphics pipeline.\nFor modern VxWorks devices equipped with a supported GPU, EGLFS is the recommended Qt 6 platform plugin.\n🔧 Preparing the Qt 6 VxWorks Build Environment # Building Qt 6 for a VxWorks target requires a cross-compilation environment containing:\nA Qt 6 build host A VxWorks-compatible compiler toolchain A target sysroot VxWorks Board Support Package (BSP) components Device-specific EGL/OpenGL ES integration where required For graphics-enabled targets, the vendor-provided porting layer must expose the necessary EGL and OpenGL ES 2.0 functionality.\nBefore configuring or compiling Qt 6, open the VxWorks Development Shell so that the required compiler, environment variables, SDK components, and VxWorks tooling are available.\nLinux host # On a Linux build host:\ncd \u0026lt;VxWorks installation directory\u0026gt; ./wrenv.sh -p vxworks Windows host # On Windows, use the VxWorks environment command:\ncd \u0026lt;VxWorks installation directory\u0026gt; wrenv -p vxworks The exact VxWorks installation path depends on the local development environment.\n🛠️ Configuring Qt 6 for a VxWorks Device # The following configuration illustrates a Qt 6 build for a BD-SL-i.MX6 development board.\nThe configuration pattern is representative of other VxWorks development boards, although the target sysroot, GPU integration library, and platform-specific options may need to be adjusted for the selected BSP.\n./configure \\ -cmake-generator \u0026#34;Ninja\u0026#34; \\ -icu \\ -no-feature-timezone \\ -no-feature-vulkan \\ -platform vxworks-clang \\ -qt-host-path \u0026lt;path-to-qt-host\u0026gt; \\ -sysroot /fsl_imx6__VSB \\ -qpa \u0026#34;eglfs\u0026#34; \\ -DQT_QPA_EGLFS_INTEGRATION=eglfs_viv \\ -prefix /sd0:1/qt6rtp \\ -extprefix /qt6rtp \\ -nomake tools \\ -nomake examples Several options are especially relevant to an embedded VxWorks build:\nOption Purpose -cmake-generator \u0026quot;Ninja\u0026quot; Uses Ninja as the Qt build backend -icu Enables ICU integration -no-feature-timezone Disables the timezone feature when it is unnecessary or unsupported -no-feature-vulkan Excludes Vulkan support -platform vxworks-clang Selects the VxWorks Clang platform configuration -qt-host-path Specifies the host-side Qt installation -sysroot Points to the target VxWorks sysroot -qpa \u0026quot;eglfs\u0026quot; Selects EGLFS as the QPA platform plugin -DQT_QPA_EGLFS_INTEGRATION=eglfs_viv Selects the Vivante EGLFS integration -prefix Defines the target installation location -extprefix Defines the external installation prefix -nomake tools Avoids building unnecessary Qt tools -nomake examples Avoids building Qt examples The eglfs_viv integration shown above is specific to the Vivante graphics stack used by the example target. Other VxWorks boards may require a different vendor-specific integration.\nShared versus static Qt builds # Qt 6 is configured for shared libraries by default.\nTo build Qt as static libraries, add:\n-static Static builds can simplify deployment by reducing runtime shared-library dependencies, but they also change application linking, update, and licensing considerations. The appropriate choice depends on the target product architecture and deployment model.\n🏗️ Building and Installing Qt 6 # After configuration completes successfully, use Ninja to compile and install Qt:\nninja ninja install The resulting installation contains the Qt runtime and selected modules configured for the target VxWorks environment.\nFor embedded products, it is generally preferable to exclude unused modules, examples, and development tools during configuration rather than carrying unnecessary components into the target filesystem.\n🎨 EGLFS and GPU Integration # EGLFS provides the bridge between Qt\u0026rsquo;s QPA architecture and the graphics stack on a VxWorks target.\nThe integration chain can be viewed conceptually as:\nQt Application | v Qt GUI / Qt Quick | v Qt Platform Abstraction (QPA) | v EGLFS | v EGL / OpenGL ES 2.0 | v VxWorks GPUDEV | v Vendor GPU Driver / Hardware The exact lower-level implementation depends on the VxWorks BSP and GPU vendor.\nFor a Qt Quick application, the GPU path is particularly important because Qt Quick relies on hardware-accelerated rendering capabilities provided through the OpenGL ES stack.\nA board that satisfies the CPU, POSIX, and C++ requirements for Qt Widgets may therefore still require additional BSP and GPU integration work before Qt Quick can be deployed successfully.\n🚀 Running Qt Applications on VxWorks # When Qt 6 is built using shared libraries, the target runtime must be able to locate the required Qt and VxWorks shared libraries.\nThe LD_LIBRARY_PATH environment variable can be configured to include the directory containing the Qt runtime libraries and other required VxWorks libraries.\nFor example:\nexport LD_LIBRARY_PATH=/qt6rtp/lib:$LD_LIBRARY_PATH The exact runtime path depends on the installation layout selected through -prefix and -extprefix.\nShared-library deployments may require additional runtime libraries from the VxWorks system, including components associated with:\nVxWorks C runtime OpenGL ES EGL Vendor GPU integration For a statically built Qt configuration, Qt\u0026rsquo;s static libraries are linked into the application and therefore do not require the Qt shared-library path in LD_LIBRARY_PATH.\nHowever, static linking does not eliminate all runtime dependencies. The application can still depend on VxWorks-provided shared libraries, including graphics and system libraries, depending on the target configuration.\n📋 Deployment Considerations # A production Qt 6 application on VxWorks should be treated as a target-specific cross-compilation product rather than a generic desktop Qt build.\nThe main dependencies to validate are:\nVxWorks release — verify compatibility with the target SR release. CPU architecture — Qt 6.7\u0026rsquo;s verified configuration targets ARM-v7. Compiler/toolchain — use the VxWorks-supported Clang environment. Sysroot — ensure headers, libraries, and BSP components correspond to the target. QPA integration — configure EGLFS for direct embedded display operation. GPU stack — verify EGL, OpenGL ES 2.0, GPUDEV, and vendor integration for Qt Quick. Qt modules — remove unnecessary modules to control image size and build complexity. Runtime libraries — ensure all required shared libraries are available on the target. Static versus shared linking — select the deployment model based on update, footprint, and dependency requirements. 🔍 Summary # Qt 6.7 provides a practical Qt 6 foundation for VxWorks 7 systems, with verified support for VxWorks SR 23.09 on ARM-v7. Qt Widgets requires POSIX and C++17 support, while Qt Quick 2 additionally depends on a compatible OpenGL ES 2.0 GPU stack.\nFor embedded graphical systems, EGLFS is the key QPA integration layer. It allows Qt applications to use EGL and OpenGL ES without requiring a traditional windowing system, making it well suited to dedicated VxWorks devices.\nA successful Qt 6 VxWorks deployment ultimately depends on more than the Qt framework itself. The target BSP, sysroot, compiler, GPU driver, EGL/OpenGL ES implementation, and EGLFS integration must all align with the selected hardware platform.\n","date":"2024-04-02","externalUrl":null,"permalink":"/app/qt-6.7-on-vxworks-7-architecture-eglfs-and-build-guide/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eQt 6.7 on VxWorks 7: Architecture, EGLFS, and Build Guide\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eQt 6.7 was released on April 2, 2024, introducing verified support for VxWorks 7 and providing an updated foundation for deploying Qt applications on embedded real-time systems.\u003c/p\u003e","title":"Qt 6.7 on VxWorks 7: Architecture, EGLFS, and Build Guide","type":"app"},{"content":"","date":"2024-03-27","externalUrl":null,"permalink":"/tags/amazon-ec2/","section":"Tags","summary":"","title":"Amazon EC2","type":"tags"},{"content":"","date":"2024-03-27","externalUrl":null,"permalink":"/tags/aws/","section":"Tags","summary":"","title":"AWS","type":"tags"},{"content":"Wind River®, a global leader in software for mission-critical intelligent systems, today announced the availability of its Wind River Studio Developer platform on Amazon Web Services (AWS), further accelerating innovation in software-defined vehicles. The platform is currently being showcased at the AWS Prototyping and Innovation Lab in Santa Clara.\nWind River Studio Developer is a comprehensive, edge-to-cloud DevOps platform designed to enhance developer productivity, improve operational quality, and accelerate time-to-market. Now deployable on AWS, the platform enables cloud-scale automated build and test capabilities for safety-critical embedded edge applications. Leveraging AWS infrastructure, Wind River Studio provides a scalable, collaborative development environment with a robust suite of tools for full lifecycle management.\nThe joint demonstration at the AWS Prototyping and Innovation Lab highlights the cloud-native development and deployment of software updates for connected vehicles. The automotive showcase illustrates an optimized, end-to-end embedded software development experience—from application development and testing to deployment in a software-defined vehicle environment. Utilizing Amazon Elastic Compute Cloud (Amazon EC2), the demo features capabilities such as test automation, remote access to test devices, and over-the-air (OTA) update functionality.\nDemonstrating the extensibility of Wind River Studio, the solution integrates Amazon Q, a generative AI-powered assistant, to enhance developer productivity. This integration connects Studio to Amazon CodeWhisperer, AWS’s AI-powered code generation tool, enabling real-time code recommendations and AI-assisted development within the platform.\n“The automotive industry is undergoing a transformative shift toward software-defined systems,” said Avijit Sinha, President of Wind River. “Our collaboration with AWS enables us to deliver a turnkey, cloud-based solution that supports the entire product lifecycle for automotive and other mission-critical systems. We\u0026rsquo;re proud to showcase this innovation at the AWS Prototyping and Innovation Lab.”\nAs a member of the AWS Partner Network (APN), Wind River is making its technologies more accessible through Amazon Machine Images (AMIs) available on AWS Marketplace. These offerings allow developers to quickly launch a cloud-based development environment without the need for complex local setup. The following Wind River technologies are now available in AWS Marketplace:\nVxWorks® – The industry’s leading real-time operating system (RTOS), now running natively in the cloud on AWS Graviton2. Wind River Linux – A powerful embedded Linux development platform equipped with a full suite of tools and lifecycle services for intelligent edge devices. Wind River DevSecOps for the Intelligent Edge – A specialized workshop designed for AWS customers exploring Wind River’s advanced edge software solutions. To schedule a live demonstration of the Wind River Studio and AWS connected vehicle solution at the AWS Prototyping and Innovation Lab, please contact: StudioAWSdemo@windriver.com.\nFor more information about Wind River’s automotive solutions, visit: www.windriver.com/solutions/automotive\nAbout Wind River\nWind River is a global leader in software for mission-critical intelligent systems. For over 40 years, Wind River has been at the forefront of innovation, powering billions of devices and systems that demand the highest levels of safety, security, and reliability. The company supports digital transformation across key industries, including automotive, aerospace, defense, industrial, medical, and telecommunications. Its comprehensive software portfolio is backed by industry-leading services and a broad ecosystem of partners. Learn more at www.windriver.com.\n","date":"2024-03-27","externalUrl":null,"permalink":"/news/wind-river-advances-software-defined-vehicle-innovation-on-aws/","section":"News","summary":"\u003cp\u003eWind River®, a global leader in software for mission-critical intelligent systems, today announced the availability of its Wind River Studio Developer platform on Amazon Web Services (AWS), further accelerating innovation in software-defined vehicles. The platform is currently being showcased at the AWS Prototyping and Innovation Lab in Santa Clara.\u003c/p\u003e","title":"Wind River Advances Software Defined Vehicle Innovation on AWS","type":"news"},{"content":" VxWorks Platforms 3.8: Architecture, Features, and RTOS Capabilities\nModern embedded systems demand deterministic performance, strong security, and scalable connectivity. As device complexity increases, developers must balance real-time constraints with networking, safety, and lifecycle management.\nVxWorks Platforms 3.8 provides a fully integrated development and runtime environment that combines a commercial-grade RTOS, development tooling, and production-ready middleware into a unified solution for embedded systems.\n🧩 Platform Overview # VxWorks Platforms deliver a complete develop-and-run stack:\nReal-time operating system (VxWorks 6.8) Integrated development environment (Workbench 3.2) Pre-integrated middleware (networking, security, management) This integration reduces system complexity, shortens development cycles, and improves system reliability.\nTarget Application Domains # Aerospace and defense Industrial automation Automotive systems Networking infrastructure Medical devices Consumer electronics 🏗️ Platform Variants # VxWorks Platforms 3.8 includes multiple domain-specific configurations:\nGeneral Purpose Platform # Broad applicability across industries Balanced performance and flexibility Automotive Platform # Optimized for low power and small footprint Suitable for ECUs, dashboards, and telematics Consumer Devices Platform # Fast boot and memory-efficient runtime Designed for multimedia and handheld devices Industrial Devices Platform # Strong connectivity and multimedia support Used in factory automation and instrumentation Network Equipment Platform # High-performance packet processing Extensive security and protocol support 🚀 What’s New in Version 3.8 # This release focuses on multicore scalability, networking enhancements, and toolchain improvements.\nCore Updates # VxWorks 6.8 RTOS enhancements Improved memory protection and scalability Integrated hypervisor support Toolchain Enhancements # Updated compilers (Wind River Compiler, GNU) VxWorks Simulator improvements Enhanced debugging and analysis tools Networking Improvements # Zero-copy socket support Updated SSL with FIPS 140-2 compliance Enhanced web services (SOAP stack) Multicore Communication # MIPC 2.0 for high-speed inter-core messaging Improved AMP/SMP coordination ⚙️ VxWorks 6.8 RTOS Architecture # VxWorks is designed for deterministic, low-latency execution with high configurability.\nKey Capabilities # Memory Protection # Kernel and user-space isolation Real-Time Processes (RTPs) with independent memory spaces Support for multiple virtual memory models Device Driver Framework # VxBus standardizes driver development Simplifies BSP portability and maintenance Error Detection and Recovery # Stack overflow detection Memory corruption checks Configurable fault handling policies File Systems # FAT-compatible dosFs Highly Reliable File System (HRFS) with transactional safety Scalability # Source build system for footprint optimization Minimal kernel footprint (~75 KB) 🌐 Networking Stack # VxWorks includes a production-grade networking stack supporting modern protocols and high-performance data paths.\nCore Features # Dual-stack IPv4/IPv6 Zero-copy networking (zbuf) SCTP, MPLS, DiffServ QoS Virtual routing and redundancy (VRRP) Performance Optimizations # Hardware acceleration support Fast-path packet forwarding Embedded-ready protocol implementations 🧠 Multiprocessing Support (SMP \u0026amp; AMP) # VxWorks 6.8 provides flexible multicore execution models.\nSymmetric Multiprocessing (SMP) # Single OS instance across multiple cores Shared memory model Priority-based preemptive scheduling Key features:\nCPU affinity and task pinning Spinlocks and memory barriers Deterministic real-time scheduling Asymmetric Multiprocessing (AMP) # Multiple OS instances per system Supports mixed OS environments (e.g., VxWorks + Linux) Key features:\nInter-core communication via shared memory MIPC 2.0 for low-latency messaging Independent fault isolation Virtualization Support # Compatible with Wind River Hypervisor Enables partitioned systems with strong isolation 🔐 Middleware Capabilities # VxWorks Platforms include pre-integrated middleware to accelerate development.\nSecurity # IPsec and IKE (v1/v2) SSL/TLS with FIPS 140-2 support Firewall and NAT capabilities Wireless security (WPA/WPA2, 802.1X) Device Management # SNMP (v1/v2c/v3) Web-based management interfaces CLI integration Unified management backplane Distributed Services # Embedded web services (SOAP/XML) Interoperable messaging frameworks 🛠️ Development Environment: Workbench 3.2 # Workbench is an Eclipse-based IDE tailored for embedded development.\nCore Features # Integrated build system Cross-debugging support VxWorks Simulator Multicore debugging (SMP/AMP aware) Analysis Tools # System Viewer (timing analysis) Performance Profiler Memory Analyzer Code Coverage tools Extensibility # On-chip debugging support Integration with testing tools (e.g., unit testing frameworks) 📦 System Integration and Ecosystem # Hardware Support # Multiple CPU architectures (ARM, x86, PowerPC, MIPS) Extensive BSP availability Host Environments # Windows Linux Ecosystem # Broad partner network Third-party middleware and tools Professional services and training 📈 Engineering Value # VxWorks Platforms 3.8 delivers:\nDeterministic real-time performance Scalable multicore support Integrated security and networking Reduced integration complexity Faster time-to-market 🧾 Conclusion # VxWorks Platforms 3.8 provides a mature, production-ready foundation for building high-performance embedded systems. By integrating RTOS capabilities, middleware, and development tools into a unified platform, it enables teams to focus on application-level innovation rather than infrastructure.\nIts support for SMP, AMP, and virtualization—combined with a robust networking and security stack—positions it as a strong choice for next-generation embedded systems requiring both real-time determinism and modern connectivity.\n","date":"2024-01-01","externalUrl":null,"permalink":"/training/vxworks-platforms-3.8-architecture-features-and-rtos-capabilities/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks Platforms 3.8: Architecture, Features, and RTOS Capabilities\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eModern embedded systems demand deterministic performance, strong security, and scalable connectivity. As device complexity increases, developers must balance real-time constraints with networking, safety, and lifecycle management.\u003c/p\u003e","title":"VxWorks Platforms 3.8: Architecture, Features, and RTOS Capabilities","type":"training"},{"content":"","date":"2023-12-26","externalUrl":null,"permalink":"/tags/mesa/","section":"Tags","summary":"","title":"Mesa","type":"tags"},{"content":"","date":"2023-12-26","externalUrl":null,"permalink":"/tags/opengl/","section":"Tags","summary":"","title":"OpenGL","type":"tags"},{"content":" VxWorks下基于WindML与Mesa的雷达三维仿真界面设计与实现\n摘要 # 雷达仿真界面是显示雷达信息最直观的图形界面。本文针对以往雷达二维图形仿真界面存在俯仰角参数表示不直观、运动目标状态显示不准确、人机操作界面不友好等问题，以VxWorks实时多任务操作系统为应用平台，通过在WindML3.0中应用Mesa4.0技术实现图形三维显示效果，创新性地设计实现了一套高稳定性、高可靠性和强实用性的雷达三维仿真界面。该界面改进了以往二维图形显控界面的缺点，同时兼顾二维仿真界面显示，实现了二维和三维雷达仿真界面的完美兼容。\n关键词：VxWorks；Mesa；雷达仿真界面；三维\nAbstract # Radar system is based on radar simulation interfaces. According to the disadvantages of former radar two-dimensional simulation interfaces, such as unintuitive representation of pitch angle, inaccurate display of moving targets, and unfriendly man-machine interface, the author presents a stable and high-performance radar three-dimensional simulation interface in the VxWorks real-time multitask operating system by applying Mesa4.0 in WindML3.0. The new interface is well compatible with the former interface and improves it to achieve the expected effect.\n0 引言 # 雷达显控仿真界面是显示雷达信息最直观的图形界面，是雷达信息系统与操作员之间最重要的人机交互手段。因此，雷达仿真界面的视觉效果对操作员及时准确地进行数据判断具有很大影响。\n雷达仿真界面设计任务主要包括：\n显示雷达威力范围信息，供雷达操作员观察； 对雷达目标航迹进行可视化显示，显示目标运动的全过程； 通过观察视角的旋转、缩放、拉近、延伸等交互操作，使目标航迹能完整反映雷达目标的运动信息。 传统的雷达图像仿真界面一般为二维显示界面，通过PPI圆显示。这种显示方式存在以下问题：\n对于具备三坐标信息的某些型号雷达，目标方位显示不准确； 俯仰角度变化体现不直观。 本文基于VxWorks实时多任务操作系统，通过将Mesa4.0裁剪移植至WindML3.0，设计实现了一套雷达三维仿真界面。该软件设计不仅充分满足了雷达仿真界面的功能性，并可与传统二维仿真界面进行无缝转换，充分考虑了人性化设计，具有友好、直观的人机界面。\n1 WindML3.0及Mesa4.0简介 # 本文软件在VxWorks实时多任务嵌入式操作系统下开发，通过在WindML3.0下移植及裁剪Mesa4.0，实现了雷达三维图形的仿真显示功能。下面分别对WindML3.0以及Mesa4.0进行介绍。\n1.1 WindML3.0简介 # WindML（Wind Media Library）是嵌入式实时操作系统VxWorks中的一个多媒体组件库，为其提供了图形图像、字体、视音频等多媒体功能。\nWindML3.0沿用了WindML2.0的基本2D图形库，包含点、直线、矩形、椭圆、多边形这五种基本的2D图形绘制API。但WindML3.0仍存在部分缺陷，例如：\n在图形绘制上仍没有得到根本上的改观； 不支持三维显示； 不支持反走样处理等高级图像处理功能。 本文利用Mesa4.0在WindML3.0中的移植来弥补这些缺陷。\n1.2 Mesa4.0简介 # Mesa是一个基于OpenGL规范开发的3D图形库开源库，用于渲染交互式三维图形系统。Mesa自发布以来已经得到成熟应用，各种设备驱动程序允许Mesa库在许多不同的环境中使用（从软件仿真到GPU硬件加速）。同时，也可以很好地应用在不同的操作系统中，如Linux、Windows、Unix等。\n相对于Mesa的最新版本，Mesa4.0版本对VxWorks系统提供了更加完整的适配支持，因此在WindML的应用中具有良好的兼容性。\n2 雷达三维仿真界面设计实现 # 雷达三维仿真界面是在以往传统的雷达二维仿真界面设计的基础上，对雷达显示区域进行改进，使二维与三维仿真界面良好兼容，更形象直观地体现俯仰角和目标运动状态变化信息。该设计实现的关键在于将Mesa4.0移植入WindML3.0中，并合理裁剪应用。\n2.1 WindML3.0下移植Mesa4.0 # Mesa4.0的移植原理主要为：利用其开源特性，将Mesa4.0源码编译成用户所需的WindML3.0下的链接库。示例编译步骤如下：\n在Tornado平台下，建立Toolchain为SIMNTgnu的Download工程； 添加文件，将Mesa4.0的源文件添加到工程目录中； 在C:\\Tornado2.0\\target\\h下建立GL文件夹，将gl.h、glext.h、glu.h、uglglutshapes.h、uglMesa.h拷贝至GL文件夹下； 设置Builds选项卡中的C/C++编译器选项，添加Mesa的include和src路径，并编译生成.a文件； 将生成的.a文件链接到PRJ_LIBS选项卡中，编译工程，生成.out下载文件，完成WindML3.0下Mesa4.0的移植。 2.2 Mesa4.0在WindML3.0中的使用 # 《WindML Driver for Mesa 4.0》中可以找到在WindML中使用Mesa的典型应用示例。示例步骤流程图如图1所示。\n图 1 WindML中使用Mesa应用流程图\n2.3 Mesa4.0的裁剪 # Mesa4.0三维图形库是针对WindML2.0开发的，能够正确地应用于WindML2.0的开发应用。当应用于WindML3.0的窗口系统时，容易出现窗口失去响应的问题。因此，针对窗口问题，需要对Mesa4.0源码进行裁剪。\n对于Mesa4.0的裁剪，主要需要修改更改绘图页面的选择和图形上下文的相应代码。\n2.3.1 更改绘图页面 # 在Mesa4.0对于WindML的程序中，使用了两个变量firstPage和secondPage分别表示绘图页和显示页。当处于直接绘图模式时，firstPage = secondPage；当处于双缓冲模式时，firstPage和secondPage轮流维护绘图页和缓冲页。\n由于WindML3.0的双缓冲模式，其页面处理由窗口系统自行完成，这对Mesa4.0来说相当于直接绘图模式。因此，Mesa4.0的双缓冲绘图方法不适用于WindML3.0的窗口系统。\n为实现该功能，需要手动更改Mesa中有关直接绘图模式的代码。具体为：在创建UGL/Mesa环境的函数中，设置firstPage的pageId为绘图页面的pageId；设置firstPage所维护的缓冲区地址为绘图页面的地址，如图2所示。\n图 2 firstPage的更改\n2.3.2 更改图形上下文的相应代码 # 在Mesa4.0对于WindML的程序中，创建了一个图形上下文。在某个窗口界面绘图时，会与WindML3.0的窗口系统所创建的图形上下文产生冲突。因此，需要修改Mesa4.0中有关图形上下文的代码。\n具体做法：在直接绘图模式设置绘图页面之前，销毁Mesa创建的图形上下文，并将Mesa图形上下文赋值为UGL的图形上下文。\n2.3.3 销毁保护 # 由于销毁了Mesa创建的图形上下文，因此在销毁Mesa前（uglMesaDestroyContext），必须对Mesa图形上下文的有效性进行判断。当Mesa上下文中的图形上下文与UGL中的不同时，方可进行销毁。\n2.4 界面效果图 # 利用VxWorks在Windows下的模拟器对二维和三维仿真界面效果图做了对比（如图3所示）。相比于二维界面，三维界面能更直观地体现运动目标信息和俯仰角变化状态，在视觉效果和界面上也更加友好。并且，通过按键控制，可以实现三维和二维图像的渐进转换，良好兼容了这两种显示模式（如图4所示）。\n图 3 雷达二维/三维仿真界面实现效果对比图\n图 4 三维界面转换至二维界面效果图\n3 结语 # 本文针对传统雷达二维仿真界面显示中存在的不直观、反映目标运动过程不准确等问题，应用Mesa4.0在WindML3.0中的移植实现了三维界面仿真效果以及雷达目标航迹的仿真。结果十分清晰直观地反映了参数的变化情况并模拟了目标的运动过程，并且和二维仿真界面有着良好的兼容性，取得了令人满意的效果。\n参考文献 # [1] 秦啸, 宋慧娟, 穆朝义. 基于WindML媒体库的图形界面开发[J]. 电子技术与软件工程, 2013(17): 100-101.\n[2] 练学辉, 朱佳丽, 乔大雷. 基于WindML的图形开发与应用[J]. 雷达与对抗, 2015, 35(1): 65-68.\n[3] 章国华. 基于VxWorks的图形软件WindML3.0的研究[J]. 武汉船舶职业技术学院学报, 2014, 13(2): 68-71.\n[4] 毛子鹰, 高贵明. WindML中Mesa的应用[J]. 雷达与对抗, 2009(3): 67-70.\n作者：朱长发 蒋昕祎 李兴 王宝欣 王嘉颖\n（上海航天技术研究院，上海 201100）\n","date":"2023-12-26","externalUrl":null,"permalink":"/windml/1193-realizing-a-radar-three-dimensional-simulation-interfaces-under-vxworks-system-based-on-mesa-40/","section":"Windmls","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks下基于WindML与Mesa的雷达三维仿真界面设计与实现\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e摘要 \n    \u003cdiv id=\"%E6%91%98%E8%A6%81\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#%E6%91%98%E8%A6%81\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003e雷达仿真界面是显示雷达信息最直观的图形界面。本文针对以往雷达二维图形仿真界面存在俯仰角参数表示不直观、运动目标状态显示不准确、人机操作界面不友好等问题，以VxWorks实时多任务操作系统为应用平台，通过在WindML3.0中应用Mesa4.0技术实现图形三维显示效果，创新性地设计实现了一套高稳定性、高可靠性和强实用性的雷达三维仿真界面。该界面改进了以往二维图形显控界面的缺点，同时兼顾二维仿真界面显示，实现了二维和三维雷达仿真界面的完美兼容。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e关键词\u003c/strong\u003e：VxWorks；Mesa；雷达仿真界面；三维\u003c/p\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eAbstract \n    \u003cdiv id=\"abstract\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#abstract\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eRadar system is based on radar simulation interfaces. According to the disadvantages of former radar two-dimensional simulation interfaces, such as unintuitive representation of pitch angle, inaccurate display of moving targets, and unfriendly man-machine interface, the author presents a stable and high-performance radar three-dimensional simulation interface in the VxWorks real-time multitask operating system by applying Mesa4.0 in WindML3.0. The new interface is well compatible with the former interface and improves it to achieve the expected effect.\u003c/p\u003e","title":"VxWorks下基于WindML与Mesa的雷达三维仿真界面设计与实现","type":"windml"},{"content":"","date":"2023-12-26","externalUrl":null,"permalink":"/windml/","section":"Windmls","summary":"","title":"Windmls","type":"windml"},{"content":"","date":"2023-12-26","externalUrl":null,"permalink":"/tags/%E9%9B%B7%E8%BE%BE%E4%BB%BF%E7%9C%9F/","section":"Tags","summary":"","title":"雷达仿真","type":"tags"},{"content":"","date":"2023-12-26","externalUrl":null,"permalink":"/tags/%E9%9B%B7%E8%BE%BE%E6%98%BE%E6%8E%A7/","section":"Tags","summary":"","title":"雷达显控","type":"tags"},{"content":"","date":"2023-12-26","externalUrl":null,"permalink":"/tags/%E5%B5%8C%E5%85%A5%E5%BC%8Fgui/","section":"Tags","summary":"","title":"嵌入式GUI","type":"tags"},{"content":"","date":"2023-12-26","externalUrl":null,"permalink":"/tags/%E4%B8%89%E7%BB%B4%E5%9B%BE%E5%BD%A2/","section":"Tags","summary":"","title":"三维图形","type":"tags"},{"content":"","date":"2023-12-26","externalUrl":null,"permalink":"/tags/%E5%AE%9E%E6%97%B6%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F/","section":"Tags","summary":"","title":"实时操作系统","type":"tags"},{"content":" Wind River, a global leader in software for mission- and safety-critical systems, has announced new enhancements to its VxWorks platform with added support for Sigstore Cosign and broader availability of its real-time container engine. These updates further strengthen the security and manageability of containerized applications on VxWorks-based devices.\nVxWorks remains the first and only RTOS to support Open Container Initiative (OCI)–compliant containers, enabling cloud-native workflows at the intelligent edge without compromising real-time determinism, performance, or certification readiness.\n⚙️ Foundation and Open-Standard Compliance # Wind River’s container strategy builds on its real-time embedded container engine, first introduced in 2021, and has continued to mature with a focus on standards compliance and zero-overhead design.\nOCI Compliance: The VxWorks real-time container engine strictly adheres to OCI specifications for container packaging, distribution, and runtime, as defined by the Cloud Native Computing Foundation (CNCF). Zero-Overhead Design: Containers are implemented without sacrificing real-time performance, preserving VxWorks’ deterministic behavior. Application Isolation: In 2022, Wind River added support for overlay file systems, a critical capability for isolating application software and managing independent updates. VxWorks also supports Kubernetes through a true embedded kubelet, allowing development teams to use familiar cloud-native tools and workflows. This eliminates the need for custom, proprietary tooling and enables teams to develop, deploy, manage, and update real-time RTOS software using the same infrastructure and practices commonly used with Linux—while reducing cost, risk, and operational complexity.\nVxWorks is the first and only RTOS to support OCI-compliant containers, simplifying software deployment and management, lowering operational costs, and enabling faster development of intelligent edge software without sacrificing determinism and performance. The addition of Cosign support further strengthens secure deployment and update workflows for critical systems.\n— Avijit Sinha, Chief Product Officer, Wind River\n✈️ Industry Adoption and Real-World Benefits # Containerized microservices architectures provide significant advantages over traditional monolithic application models, particularly in systems that combine mixed-criticality workloads.\nAerospace (Collins Aerospace):\nContainers allow microservices of different criticality levels to coexist safely. High Design Assurance Level (DAL) components can remain isolated and stable, while lower-DAL components can evolve rapidly. This separation helps reduce certification cost and complexity, while enabling the use of open-source software and agile development methods for non-critical functions.\nAutomotive (Aptiv):\nContainerization accelerates the transition to the software-defined vehicle by simplifying software updates and modernizing legacy applications.\nEmerging containerized software enables developers to work efficiently and modernize legacy applications easily. VxWorks can significantly reduce the effort and cost of software updates and unlock new business models, delivering substantial value to automotive Tier 1s and OEMs.\n— Benjamin Lyon, Senior Vice President and CTO, Aptiv\nAcross industries such as automotive, aerospace, defense, and industrial systems, containers are becoming a key enabler for modular software architectures that support faster innovation while maintaining strict safety and reliability requirements.\n🔐 Strengthening Container Security with Cosign # To further enhance container security, Wind River has added support for Sigstore Cosign, complementing its existing secure registry access and secure software development capabilities.\nSigned Containers: Cosign enables cryptographic signing and verification of container images, ensuring software authenticity and integrity. Infrastructure Reuse: Developers can leverage existing cloud-managed Key Management Systems (KMS) and container registries, avoiding the need to introduce new security tooling. Simplified Compliance: Image verification becomes a natural part of the deployment pipeline, helping teams meet security and compliance requirements for safety- and mission-critical systems. These capabilities reinforce VxWorks’ position as a secure, cloud-native RTOS for the intelligent edge.\nWind River’s continued investment in real-time containers has been recognized with the 2023 Container Support Platinum Innovation Award, underscoring the company’s leadership in bringing modern, secure, and standards-based container technology to safety- and mission-critical environments.\n","date":"2023-12-22","externalUrl":null,"permalink":"/news/wind-river-expands-vxworks-leadership-in-real-time-containers/","section":"News","summary":"\u003c!--# Wind River Expands VxWorks Leadership in Real-Time Containers--\u003e\n\u003cp\u003e\u003cstrong\u003eWind River\u003c/strong\u003e, a global leader in software for mission- and safety-critical systems, has announced new enhancements to its \u003cstrong\u003eVxWorks\u003c/strong\u003e platform with added support for \u003cstrong\u003eSigstore Cosign\u003c/strong\u003e and broader availability of its \u003cstrong\u003ereal-time container engine\u003c/strong\u003e. These updates further strengthen the security and manageability of containerized applications on VxWorks-based devices.\u003c/p\u003e","title":"Wind River Expands VxWorks Leadership in Real-Time Containers","type":"news"},{"content":" Wind River Hypervisor: Powering Digital Transformation at the Network Edge\nHypervisors first transformed cloud computing by enabling efficient virtualization and higher resource utilization. Today, that same technology is reshaping embedded and edge systems—from aircraft and automobiles to industrial machines and robots. At the network edge, virtualization is becoming a foundational enabler of security, flexibility, and cost efficiency.\nWind River Hypervisor extends these cloud-proven concepts into safety-critical environments, where determinism, certification, and long product lifecycles are non-negotiable.\n🛡️ Security, Integrity, and Safety Certification # For systems that directly affect human safety, software integrity is paramount. Wind River designs its hypervisor and operating systems with certification and compliance as first-class requirements.\nCertified Foundations: Wind River Hypervisor and related platforms are developed to support compliance with DO-178C (aerospace), ISO 26262 (automotive), and IEC 61508 (industrial). Type-1 Hypervisor Architecture: The Wind River Helix Virtualization Platform uses a bare-metal (Type-1) hypervisor, minimizing attack surface and reducing system complexity. Mixed-Criticality Isolation: Multiple operating systems—certified, non-certified, or mixed-criticality—can run concurrently while remaining strictly isolated. Fault Containment: If one application or guest OS fails, it does not propagate faults to other workloads. Failed partitions can be restarted independently, improving system resilience and availability. This strong isolation model enables developers to integrate innovation without compromising safety guarantees.\n🔄 Flexibility and Over-the-Air Updates # Beyond safety, virtualization unlocks significant architectural flexibility for edge system designers.\nDynamic Resource Allocation: CPU cores, memory, and devices can be allocated per guest OS and adjusted as system requirements evolve—an essential capability for workloads such as automotive computer vision and real-time analytics. Hardware Abstraction: By virtualizing hardware dependencies, the hypervisor decouples software from physical platforms. OTA Enablement: Software updates that previously required physical access or hardware replacement can now be delivered via Over-The-Air (OTA) updates, reducing operational disruption and accelerating deployment cycles. This flexibility allows manufacturers to adapt systems long after deployment, without redesigning hardware.\n💰 Cost Efficiency and Lifecycle Extension # Wind River Hypervisor also delivers tangible economic benefits across the product lifecycle.\nSystem Consolidation: Multiple functions can be consolidated onto fewer computing modules, reducing wiring complexity and bill-of-materials cost. Reduced Weight and Power: Fewer electronic control units translate into lower weight and improved energy efficiency—critical in automotive and aerospace platforms. Longer Product Lifespan: New software capabilities can be introduced while retaining existing, validated applications. This avoids costly re-certification cycles and can extend system lifetimes by years or even decades. By enabling incremental evolution rather than disruptive replacement, virtualization significantly lowers total cost of ownership.\n🌐 Enabling the Next Generation of Edge Systems # The Wind River Helix Virtualization Platform demonstrates how a Type-1 hypervisor can safely bring cloud-style agility to the edge. It enables:\nFault tolerance in aircraft systems Safer, software-defined vehicles More reliable and adaptable robotics Remote software deployment across distributed edge devices Together, these capabilities make edge systems safer, more flexible, and more economical, supporting digital transformation without sacrificing determinism or certification requirements.\n","date":"2023-12-15","externalUrl":null,"permalink":"/news/wind-river-hypervisor-powers-secure-digital-transformation-at-the-edge/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eWind River Hypervisor: Powering Digital Transformation at the Network Edge\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eHypervisors first transformed cloud computing by enabling efficient virtualization and higher resource utilization. Today, that same technology is reshaping \u003cstrong\u003eembedded and edge systems\u003c/strong\u003e—from aircraft and automobiles to industrial machines and robots. At the network edge, virtualization is becoming a foundational enabler of \u003cstrong\u003esecurity, flexibility, and cost efficiency\u003c/strong\u003e.\u003c/p\u003e","title":"Wind River Hypervisor Powers Secure Digital Transformation at the Edge","type":"news"},{"content":" VxWorks 6.9 配置 WindML 5.3 详细教程（DKM与RTP模式）\n添加组件代码 # 将 components 目录下的内容拷贝到 VxWorks 开发环境的同级目录下。\n示例路径：\nF:\\vxworks6911\\components 1 DKM 模式 # 1.1 创建 WindML 库工程 # 首先创建一个 DKM 工程。 给工程起一个名字。 编译选项选择 ARMARCH7gnu_SMP。 将 Build tool 改为 Librarian，这样编译结果就是后缀为 .a 的库文件。 点击 Finish。然后在建立的 DKM 工程上右键 → New → Other\u0026hellip;。 在弹出的窗口中选择 Middleware Component，点击下一步。 选择 windml，点击下一步。 选择 Media Library 5.3，点击下一步。 选择 Media Library Component Configuration，点击 Finish 完成。此时已将 WindML 组件加入到 DKM 工程中。 1.2 WindML 工程配置 # 新建工程中会出现 config.windml 配置界面，该配置文件可在工程的 windml-5.3 文件夹下找到。\n按以下步骤进行配置：\n右键 Media Library → New Child → Display，添加 Display 组件。 右键 Display → New Child → Graphics，添加图形组件。 同样方法添加鼠标和键盘组件。\n打开 Graphic 配置，在 Device 选项中选择 ft。 Graphic Mode 选择一个合适的分辨率。 鼠标和键盘都选择使用 USB2。 右键 Display → New Child → BMF Fonts，添加字库组件，然后在右侧选择一个字库。 右键此工程，选择 Properties（属性） → Build Properties → Variables → New\u0026hellip;。\n在 Variables 界面新建一个宏：\nName：VXBUILD Value：SMP 完成上述工作后，编译此 WindML 工程。\n1.3 编译 VxWorks 镜像 # 创建一个 VxWorks Image Project（VIP） 工程（可参考创建 VxWorks 镜像工程的方法），或者在现有的 VIP 工程中的 Kernel Configuration 中添加以下组件：\nINCLUDE_WINDML INCLUDE_RTP INCLUDE_SHARED_DATA INCLUDE_USB_XHCI_HCD_INI INCLUDE_USB-GEN2_KEYBOARD_INIT INCLUDE_USB-GEN2_MOUSE_INIT 编译 VxWorks 镜像工程。编译时会自动链接前面 WindML 工程编译出来的库文件，无需其他操作。\n测试方法 # 可将以下路径下的测试文件复制到 VxWorks 镜像工程中：\nF:\\vxworks6911\\components\\windml-5.3\\samples\\demo\\ugldemo.c 编译完成后上机测试，测试接口：\nugldemo(0, 1); 2 RTP 模式 # 2.1 创建和配置 WindML RTP 库工程 # 第一步先创建一个 RTP 工程。创建时选择 RTP 工程类型，其余操作均与 DKM 模式相同，请参考本文档中的 1.1 创建 WindML 库工程 和 1.2 WindML 工程配置。\n2.2 创建 RTP APP # 创建一个 RTP APP 工程。 给工程起一个名字。 点几次下一步，选择编译选项。 Build tool 选择 Linker，这样编译出来的结果是 .vxe 程序。 点击 Finish，完成 RTP APP 工程的创建。\n在工程中添加 WindML 模块：右键刚建立的工程 → New → Other\u0026hellip;，选择 Middleware Component。\n选择刚才创建的 RTP APP 工程。 选择 Media Library 5.3。 注意：下一步这里要选择 Media Library application support（此选项是为编译 APP 准备的，另一个选项是为编译 WindML 库准备的）。 点击 Finish，完成 RTP APP 工程的创建。\n同样需要在工程属性中添加 SMP 编译选项：\n右键此工程 → Properties（属性） → Build Properties → Variables → New\u0026hellip;\n新建宏：\nName：VXBUILD Value：SMP 添加 APP 文件。将需要使用的文件添加到 RTP APP 工程中，例如测试文件： F:\\vxworks6911\\components\\windml-5.3\\samples\\demo\\ugldemo.c 添加完成后编译，即可生成 .vxe 文件。\n运行测试 # 在系统中执行以下命令即可启动测试用例：\nrtpSp \u0026#34;/bd0/app_name.vxe\u0026#34; ","date":"2023-12-11","externalUrl":null,"permalink":"/windml/1161-configure-windml-5-3-based-on-vxworks-6-9/","section":"Windmls","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 6.9 配置 WindML 5.3 详细教程（DKM与RTP模式）\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e\n  \u003cfigure\u003e\n    \u003cimg class=\"my-0 rounded-md\" loading=\"lazy\" src=\"https://assets.gaitpu.com/images/windml/WINDML-5-3.png\" alt=\"VxWorks 6.9 WindML 5.3\" /\u003e\n    \n  \u003c/figure\u003e\n\u003c/p\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e添加组件代码 \n    \u003cdiv id=\"%E6%B7%BB%E5%8A%A0%E7%BB%84%E4%BB%B6%E4%BB%A3%E7%A0%81\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#%E6%B7%BB%E5%8A%A0%E7%BB%84%E4%BB%B6%E4%BB%A3%E7%A0%81\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003e将 \u003ccode\u003ecomponents\u003c/code\u003e 目录下的内容拷贝到 VxWorks 开发环境的同级目录下。\u003c/p\u003e","title":"VxWorks 6.9 配置 WindML 5.3 详细教程","type":"windml"},{"content":"","date":"2023-12-11","externalUrl":null,"permalink":"/tags/windml-5.3/","section":"Tags","summary":"","title":"WindML 5.3","type":"tags"},{"content":"","date":"2023-12-11","externalUrl":null,"permalink":"/tags/%E5%A4%9A%E5%AA%92%E4%BD%93%E5%BA%93/","section":"Tags","summary":"","title":"多媒体库","type":"tags"},{"content":"","date":"2023-10-17","externalUrl":null,"permalink":"/tags/riverfield/","section":"Tags","summary":"","title":"Riverfield","type":"tags"},{"content":" Wind River has announced that Riverfield is using VxWorks to develop the Saroa Surgical System, a surgical assist robot.\n“Riverfield is an incredible pioneer with the Saroa Surgical System and its sense-of-force capability,” said Avijit Sinha, chief product officer, Wind River. “We are excited to have VxWorks help Riverfield develop high-performance robotic systems that will improve surgical precision and safety.”\n“Riverfield is dedicated to solving social issues through the power of robotics,” said Kotaro Tadano, CEO, RIVERFIELD. “Surgical procedures in which human lives are at stake demand extreme precision. VxWorks has an extensive track record in the field of medical devices that require a high level of control and real-time performance. It is essential to us to work with reliable, proven solutions.”\nRiverfield is a robotics research and development company with a strong focus on medical devices. The Saroa Surgical System is the world’s first surgical assist robot that successfully reproduces the sense-of-force tactile sensation using pneumatic pressure when driving its robotic forceps. The precision control technology of the pneumatic system realises a sense of force that is essential for precise surgical procedures, such as gripping, grasping, and pulling.\nUnlike conventional surgical robots that lack the sense-of-force capability, the Saroa Surgical System allows the doctor operating the robot to feel as though he or she is operating directly with his or her own hands. This can improve the precision of delicate manoeuvres during surgery.\nPneumatic systems provide the advantage of being cost-effective, as they can provide force feedback without requiring a force sensor. However, they are typically complex, with many components, and they are difficult to control. Riverfield selected VxWorks as its real-time OS because it combines fast response performance, high reliability, and high safety, all of which are critical requirements for surgery. With VxWorks, Riverfield can conduct real-time processing with consistent sub-microsecond response time. This allows control of pneumatic forces and other applications that are required at high speed and with high precision.\nVxWorks is the industry’s most trusted and widely deployed real-time operating system (RTOS) for mission-critical embedded systems that must be secure and safe. It delivers a proven, real-time, and deterministic runtime combined with a modern approach to development.\nWritten by Harry Fowle\n","date":"2023-10-17","externalUrl":null,"permalink":"/news/riverfield-selects-vxworks-from-wind-river/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eWind River has announced that Riverfield is using VxWorks to develop the Saroa Surgical System, a surgical assist robot.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e“Riverfield is an incredible pioneer with the Saroa Surgical System and its sense-of-force capability,” said Avijit Sinha, chief product officer, Wind River. “We are excited to have VxWorks help Riverfield develop high-performance robotic systems that will improve surgical precision and safety.”\u003c/p\u003e","title":"Riverfield Selects VxWorks From Wind River","type":"news"},{"content":"","date":"2023-10-17","externalUrl":null,"permalink":"/tags/surgical/","section":"Tags","summary":"","title":"Surgical","type":"tags"},{"content":"","date":"2023-07-31","externalUrl":null,"permalink":"/tags/horizon/","section":"Tags","summary":"","title":"Horizon","type":"tags"},{"content":" Wind River has announced a strategic collaboration with Horizon Robotics to advance automated driving solutions.\nHorizon is a provider of energy-efficient computing solutions for advanced driver assistance systems (ADAS) for consumer vehicles in China.\nThe collaboration between the two companies will enable OEMs to leverage a fully integrated ADAS hardware/software solution based on Horizon’s Journey series computing solutions and Wind River’s cloud-to-edge portfolio. This will effectively reduce time to market, and cost by simplifying development and integration. The high-performance and cost-effective technologies are ideally suited for next-generation applications such as automated driving and powering the software-defined vehicle.\nAs a pioneer in commercialising embedded passenger-vehicle ADAS and AD products in China, Horizon’s self-developed Journey series computing solutions can cover all scenarios of automated driving. Through the partnership, Horizon and Wind River will enable Wind River software, including VxWorks, the world’s most performant, safe, and secure real-time operating system (RTOS), Wind River Helix Virtualisation Platform, a safety-certified type 1 hypervisor-based multi-tenant platform, Wind River Linux, and Wind River Studio on Horizon’s Journey series product.\n“The auto industry in China is transforming tremendously, and Horizon continues to create the computational foundation for the era of smart vehicles,” said Dr. Kai Yu, Founder and CEO of Horizon, “We are committed to improving the efficiency and enhancement of automated driving by collaborating with upstream and downstream partners, and are honoured to establish this collaboration with Wind River. By leveraging the core capabilities of Horizon and Wind River, we will provide differentiated integrated solutions for OEMs, resulting in safer and optimised mobility for consumers.”\n“Our collaboration with Horizon is an important step in building an open, innovative, and collaborative ecosystem, which is paramount to the development of the smart mobility industry,” said Avijit Sinha, Chief Product Officer of Wind River. “The combination of Wind River software and Horizon hardware will allow OEMs to better leverage the advantages of localised development and delivery for next-generation automotive solutions. Together, we look forward to further advancing the software-defined vehicle and smart driving.”\n","date":"2023-07-31","externalUrl":null,"permalink":"/news/horizon-and-wind-river-to-advance-automated-driving-solutions/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eWind River has announced a strategic collaboration with Horizon Robotics to advance automated driving solutions.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eHorizon is a provider of energy-efficient computing solutions for advanced driver assistance systems (ADAS) for consumer vehicles in China.\u003c/p\u003e","title":"Horizon and Wind River to Advance Automated Driving Solutions","type":"news"},{"content":" 7 Key Features of VxWorks 7\nVxWorks 7, the world’s leading real-time operating system, represents a major step forward in developer productivity, performance, and modern language support. While preserving its four core pillars—security, functional safety, reliability, and certifiability—Wind River has expanded VxWorks to better align with contemporary embedded development practices.\nThe result is an RTOS that remains trusted in safety-critical systems, while becoming more accessible and efficient for both experienced and new embedded developers.\n🚀 Modern Language and Library Support # VxWorks 7 significantly modernizes the developer experience by embracing today’s most widely used programming languages and ecosystems.\nC++17 Support # VxWorks is the first RTOS to support C++17, the most commonly adopted C++ standard in embedded systems.\nDevelopers benefit from cleaner syntax, safer language constructs, and modern abstractions. Teams see reduced maintenance overhead and lower long-term development cost. Applications gain improved runtime performance and stronger security features. Boost 1.71.0 Integration # VxWorks now supports Boost 1.71.0, another RTOS-first milestone.\nBoost provides peer-reviewed, production-grade C++ libraries. VxWorks supports 147 of 159 applicable Boost libraries, including major updates across core components. This dramatically reduces the need for custom utility code and accelerates development timelines. ⚡ High-Performance Networking # Network performance is a critical factor in modern embedded and edge systems.\nUsing the industry-standard iperf3 benchmark, VxWorks outperformed Linux in 75% of test cases across single-core and quad-core configurations. The remaining 25% matched Linux performance, with no regressions. This wire-speed performance directly translates into lower bandwidth cost and more deterministic real-time behavior. No other RTOS currently matches VxWorks in sustained network throughput across such a wide range of configurations.\n🐍 Productivity with Python and Rust # VxWorks 7 recognizes that productivity and safety can coexist.\nPython Support # Developers can now use Python to build applications on VxWorks. This lowers the barrier to entry and accelerates scripting, automation, and rapid prototyping. Rust Support # Rust support brings memory safety, performance, and reliability to real-time systems. Embedded teams benefit from Rust’s strong guarantees while maintaining real-time determinism. Wind River’s commitment ensures developers spend less time debugging and more time innovating. 🔧 Open-Source BSP Expansion # VxWorks continues to lead the RTOS market in hardware enablement.\nHundreds of Board Support Packages (BSPs) are already available—more than any competing RTOS. Wind River is now introducing open-source BSPs for popular platforms such as Raspberry Pi. This initiative encourages community contributions, shortens project bring-up time, and reduces integration effort. 🧪 Wind River Labs: Early Access Innovation # Wind River Labs provides early access to experimental and pre-release technologies.\nDevelopers can explore upcoming runtime projects such as ROS 2, OpenCV, and cloud SDK integrations. Customers are invited to provide direct feedback, influencing future product direction. This creates a collaborative pipeline between users and Wind River’s engineering teams. 🌍 A Modern RTOS Without Compromise # VxWorks 7 successfully bridges two worlds:\nThe certified, deterministic foundation required for safety-critical systems. The modern tooling and languages demanded by today’s embedded developers. With its expanded language support, superior networking performance, open-source initiatives, and early-access innovation programs, VxWorks 7 reinforces its position as the most comprehensive RTOS for the intelligent, connected, and software-defined future.\n","date":"2023-04-12","externalUrl":null,"permalink":"/news/7-key-features-that-make-vxworks-7-the-leading-rtos/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003e7 Key Features of VxWorks 7\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eVxWorks 7\u003c/strong\u003e, the world’s leading real-time operating system, represents a major step forward in developer productivity, performance, and modern language support. While preserving its four core pillars—\u003cstrong\u003esecurity, functional safety, reliability, and certifiability\u003c/strong\u003e—Wind River has expanded VxWorks to better align with contemporary embedded development practices.\u003c/p\u003e","title":"7 Key Features That Make VxWorks 7 the Leading RTOS","type":"news"},{"content":"","date":"2023-03-27","externalUrl":null,"permalink":"/tags/ittia-db/","section":"Tags","summary":"","title":"ITTIA DB","type":"tags"},{"content":" ITTIA has announced the immediate availability of ITTIA DB software for VxWorks RTOS and the Wind River Linux operating system.\nITTIA DB is an embeddable, high-performance database that integrates time series with real-time data processing, where low-footprint transactional and analytical queries are both performed locally on embedded devices. Together, the new software and Wind River software offer a great Edge computing platform for developers of embedded system applications.\nThe recent evolution of embedded systems and the Internet of Things, IoT, has introduced connected embedded systems such as automobiles, factory robots, and consumer electronic products to process data as close to the embedded device as possible, on the IoT Edge. ITTIA DB is a real-time database specifically designed to store, accumulate, process, and analyse data streams. Each data stream is continuously generated from multiple resources. ITTIA DB empowers systems to incrementally process information through stream processing, without the overhead of transmitting the full data set.\nITTIA SDL, a secure development lifecycle, is conformant to the principles of IEC/ISO 62443, and ITTIA security practices assist manufacturers with advanced integrated software development methods, infused by a secure development lifecycle based on zero trust principles, enabling makers of IoT Edge devices to mitigate unpredictability. Data encryption, authentication, and ITTIA DB Security Expert Agent Library, DB-SEAL are among the security features included with the total integration.\nThe software is architected as a time series database that offers embedded applications to quickly add records, process, and manage massive quantities of time series data. Data is ingested efficiently and continuously, with fast speed and high precision. ITTIA DB-specific algorithms and architecture meet the requirements of Edge computing for speed and high data volume. The software handles concurrent time series, measuring many different variables or metrics in parallel.\nITTIA DB’s advanced Multi-Version Concurrency Control (MVCC) diminishes the need for database locks, resulting in fewer database access contention issues, such as deadlocks. Read access performance is greatly improved, without blocking continuous, isolated write operations.\n“ITTIA and Wind River’s partnership means delivering essential embedded software development value to our customers and collectively solving the most complex real-time data computing problems on the IoT Edge. It also means we are continually improving and evolving the ways we work with partners to best support customers,\u0026quot; said Sasan Montaseri, ITTIA president. \u0026ldquo;Our partnership will help enrich the Edge computing experience for our shared customers, and ITTIA and Wind River can provide exciting new capabilities for modern embedded computing.\u0026rdquo;\n“The growth of the intelligent Edge and increasingly complex computing workloads across mission-critical industries create unique sets of requirements and obstacles. Through our collaboration with ITTIA, we can help our mutual customers overcome demanding technology and business challenges in order to reach their objectives,” said Christina Ungaro, Vice President, Corporate Development, Wind River.\n","date":"2023-03-27","externalUrl":null,"permalink":"/news/ittia-db-supports-vxworks-and-wind-river-linux/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eITTIA has announced the immediate availability of ITTIA DB software for VxWorks RTOS and the \u003ca href=\"https://www.vxworks.net/news/961-commercial-grade-support-for-wind-river-linux-binary-distribution\" target=\"_blank\"\u003eWind River Linux\u003c/a\u003e operating system.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eITTIA DB is an embeddable, high-performance database that integrates time series with real-time data processing, where low-footprint transactional and analytical queries are both performed locally on \u003ca href=\"https://www.gaitpu.com\" target=\"_blank\"\u003eembedded\u003c/a\u003e devices. Together, the new software and Wind River software offer a great Edge computing platform for developers of embedded system applications.\u003c/p\u003e","title":"ITTIA DB supports VxWorks and Wind River Linux","type":"news"},{"content":"","date":"2023-03-27","externalUrl":null,"permalink":"/tags/wind-river-linux/","section":"Tags","summary":"","title":"Wind River Linux","type":"tags"},{"content":"","date":"2023-01-24","externalUrl":null,"permalink":"/tags/air-to-air-refulling/","section":"Tags","summary":"","title":"Air-to-Air Refulling","type":"tags"},{"content":"by Wind River\nWind River has announced its cooperation with Airbus to support the A330 Multi-Role Tanker Transport (MRTT) aircraft for automatic air-to-air refuelling (A3R). The MRTT aircraft is the world’s first tanker to be certified for A3R refuelling boom operations in daylight.\nAirbus uses VxWorks 653 for the A330 MRTT air-to-air refuelling boom system (ARBS). This system is comprised of multiple ARINC 653-compliant applications running at multiple levels of safety-criticality and achieved DO-178C DAL A certification.\nWith this development, the Airbus A330 MRTT A3R capability has earned the distinction of being certified by the Spanish National Institute for Aerospace Technology (INTA), involving multiple ED-12C / DO-178C DAL A applications running simultaneously on multiple cores on a multicore processor.\n“A3R is a significant milestone in the evolution of airborne refuelling systems. It is an honour to work with Airbus and play an important role in its latest A3R achievement,” said Avijit Sinha, Chief Product Officer, Wind River. “The use of our industry-leading technology demonstrates continuing Wind River leadership in safety-critical real-time software solutions for mission-critical systems. Wind River is able to help customers successfully navigate the challenges and complexities around certification.”\n“Airbus is the first worldwide company to certify airborne military equipment with an embedded multicore processor to the highest assurance level DAL-A covering CAST-32A requirements. With the support of Wind River, Airbus successfully navigated its multicore certification journey to achieve this impressive milestone. In addition to delivering its proven industry-leading technologies, Wind River was a trusted advisor to help identify milestones, and potential obstacles, and develop key metrics during the process to ensure that the system architecture was on the right track,” said Andrés Morán Valero, Multicore Certification Team Leader, Air Refuelling Software group, Airbus.\nThe automated A3R system enables more efficient operation, reduces Air Refuelling Operator (ARO) workload, reduces the inherent risk of this operation, and optimises the rate of air-to-air refuelling transfer. In A3R, advanced technologies can identify the receiving aircraft’s shape and its refuelling receptacle, then perform automated contact and fuel transfer while flying at a high altitude.\nProven in the most challenging safety-critical applications, VxWorks 653 makes it easier and more cost-effective for technology suppliers to meet the stringent safety certification requirements of EN 50128, IEC 61508, ISO 26262, and ED-12C / DO-178C.\n","date":"2023-01-24","externalUrl":null,"permalink":"/news/wind-river-supports-airbus-for-automatic-air-to-air-refuelling/","section":"News","summary":"\u003cp\u003e\u003cstrong\u003eby Wind River\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eWind River has announced its cooperation with Airbus to support the A330 Multi-Role Tanker Transport (MRTT) aircraft for automatic air-to-air refuelling (A3R). The MRTT aircraft is the world’s first tanker to be certified for A3R refuelling boom operations in daylight.\u003c/p\u003e","title":"Wind River Supports Airbus for Automatic Air-to-Air Refuelling","type":"news"},{"content":" Accessing Device Registers from the VxWorks 7 Kernel Shell\nDirect register access is one of the most useful capabilities available to embedded developers working with hardware bring-up, device drivers, and low-level debugging. In VxWorks 6.9, interacting with memory-mapped hardware through the kernel shell was straightforward because most physical memory regions used identity-mapped addressing.\nVxWorks 7 introduced a significantly more advanced virtual memory architecture. While this improves isolation, scalability, and system security, it also changes how developers access hardware registers from the kernel shell.\nThis article explains why direct register access behaves differently in VxWorks 7 and demonstrates the correct workflow for mapping and accessing memory-mapped devices using the kernel shell.\n⚙️ Register Access in VxWorks 6.9 # Developers familiar with VxWorks 6.9 are accustomed to directly accessing physical addresses from the shell.\nFor example, dumping hardware registers using the d command:\n-\u0026gt; d 0xffd02000, 8, 4 Writing registers interactively using the m command:\n-\u0026gt; m ffd02000, 4 Or directly modifying a register using pointer syntax:\n-\u0026gt; *0xffd02000 = 0 This worked because many physical memory regions in VxWorks 6.9 were effectively identity mapped, meaning:\nVirtual addresses matched physical addresses Hardware registers were directly accessible Minimal MMU translation complexity existed This model simplified low-level debugging but provided limited memory isolation and scalability.\n🧠 Why Direct Register Access Fails in VxWorks 7 # Attempting the same operation in VxWorks 7 often produces a data abort exception:\n-\u0026gt; d 0xffd02000, 32, 4 Result:\nData abort This occurs because VxWorks 7 uses a modern virtual memory architecture where:\nVirtual addresses are separated from physical addresses Physical memory is not automatically identity mapped Only explicitly mapped regions are accessible The MMU enforces address translation rules The physical device address may exist in hardware documentation, but unless the operating system maps that region into virtual memory, the shell cannot access it.\nThis is one of the most important architectural differences between VxWorks 6.9 and VxWorks 7.\n🗂️ Understanding Virtual and Physical Addresses # VxWorks 7 relies heavily on MMU-based memory management.\nTwo address types exist:\nVirtual Address # A virtual address is used by software during memory access operations.\nExamples include:\nC pointers Kernel shell addresses Process memory references Physical Address # A physical address corresponds to actual hardware resources such as:\nRAM Peripheral controllers Memory-mapped devices Register blocks Hardware documentation typically references physical addresses.\nThe MMU translates virtual addresses into physical addresses during runtime.\nThis allows the operating system to provide:\nProcess isolation Memory protection Controlled hardware access Flexible address layouts Improved security However, it also means physical device addresses cannot automatically be accessed directly from the shell.\n🔍 Inspecting Memory Mappings with vmContextShow # VxWorks 7 provides the vmContextShow function for inspecting the active virtual memory mappings.\nExample:\n-\u0026gt; vmContextShow The output displays:\nVirtual address ranges Physical address mappings Access permissions Cache policies MMU attributes Example entry:\n0x22008000 0x00001000 0xffd05000 RW- / --- OFF/CO/G -- This indicates:\nVirtual address 0x22008000 Maps to physical address 0xffd05000 Read/write permissions enabled Cache disabled Guarded access enabled If a physical device address does not appear in the mapping table, attempts to access it will trigger an exception.\nThat is precisely why direct access to 0xffd02000 failed earlier.\n🌲 Device Tree and Automatic Mapping # VxWorks 7 uses the device tree to describe platform hardware.\nThe device tree defines:\nPeripheral locations Interrupt assignments Address ranges Driver associations During boot:\nVxWorks parses the device tree Drivers initialize hardware Required physical regions are mapped into virtual memory Only hardware regions actively mapped by drivers become accessible through virtual addressing.\nThis behavior improves:\nSystem isolation Security Reliability Controlled device ownership but it also means developers occasionally need to manually map hardware during debugging sessions.\n🛠️ Mapping Hardware with pmapGlobalMap # The recommended approach for manual register access in VxWorks 7 is pmapGlobalMap.\nThe function accepts:\nPhysical address Mapping size MMU attributes Example:\n-\u0026gt; vx7wd0 = pmapGlobalMap (0xffd02000ULL, 0x1000, 0x483) This maps the watchdog timer registers into virtual memory and returns a usable virtual address.\nParameter Breakdown # Physical Address # 0xffd02000ULL This is the hardware register base address from the datasheet.\nThe ULL suffix ensures the shell interprets the value as 64-bit.\nThis is important because VxWorks represents physical addresses using 64-bit quantities.\nMapping Length # 0x1000 Defines the mapped region size.\nVxWorks rounds mappings to page boundaries automatically.\nTypical MMU page size:\n4 KiB MMU Attributes # 0x483 Defines access and cache behavior, rerfer to MMU_ATTR_* definitions in \u0026lsquo;vmLibCommon.h\u0026rsquo;.\nThe value includes:\nRead/write permissions Non-cacheable access Guarded memory ordering These attributes are important when accessing hardware registers because cached or reordered accesses can produce invalid behavior.\n🧪 Accessing Registers After Mapping # Once the mapping is created, the returned virtual address can be used exactly like a traditional VxWorks 6.9 address.\nExample register dump:\n-\u0026gt; d vx7wd0, 32, 4 Output:\n0x228f7000: 00000001 000000ff 7b02c5be 00000000 At this point:\nThe MMU translation exists The virtual address is valid Hardware registers become accessible This workflow restores familiar shell-level debugging capabilities while maintaining VxWorks 7 memory protection mechanisms.\n🔎 Verifying the Mapping # The newly created mapping also appears in vmContextShow:\n0x228f7000 0x00001000 0xffd02000 RW- / --- OFF/CO/G -- This confirms:\nVirtual address assignment Physical device mapping MMU access attributes Verifying mappings is useful when debugging:\nDriver initialization MMU configuration Cache coherency issues Peripheral access failures 🚀 Why the VxWorks 7 MMU Model Matters # The VxWorks 7 memory architecture introduces capabilities required by modern embedded systems:\nProcess isolation Enhanced security Scalable address management SMP support Safer driver execution Improved fault containment These capabilities are increasingly important in:\nAerospace systems Industrial automation Autonomous robotics Medical devices Defense platforms Although the additional MMU layer introduces some complexity during debugging, it significantly improves overall system robustness.\nFor embedded developers, understanding virtual memory behavior is now essential when working with modern RTOS platforms.\n📌 Practical Workflow Summary # In practice, accessing hardware registers in VxWorks 7 involves only two steps:\nStep 1 — Map the Physical Device # pmapGlobalMap(...) This creates a valid virtual mapping.\nStep 2 — Access the Virtual Address # Use standard shell commands:\nd m * exactly as in VxWorks 6.9, but using the returned virtual address instead of the physical address.\nOnce understood, the workflow becomes straightforward and extremely powerful for low-level debugging and device-driver development.\n📚 References # VxWorks 7 Kernel Shell Documentation VxWorks Virtual Memory Management APIs Wind River Device Driver Development Guides ARM MMU Architecture Documentation Intel Cyclone V HPS Technical Reference Manual ","date":"2023-01-24","externalUrl":null,"permalink":"/app/accessing-device-registers-from-the-vxworks-7-kernel-shell/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eAccessing Device Registers from the VxWorks 7 Kernel Shell\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eDirect register access is one of the most useful capabilities available to embedded developers working with hardware bring-up, device drivers, and low-level debugging. In VxWorks 6.9, interacting with memory-mapped hardware through the kernel shell was straightforward because most physical memory regions used identity-mapped addressing.\u003c/p\u003e","title":"Accessing Device Registers from the VxWorks 7 Kernel Shell","type":"app"},{"content":"","date":"2023-01-24","externalUrl":null,"permalink":"/tags/hardware-debugging/","section":"Tags","summary":"","title":"Hardware Debugging","type":"tags"},{"content":"","date":"2023-01-24","externalUrl":null,"permalink":"/tags/memory-mapping/","section":"Tags","summary":"","title":"Memory Mapping","type":"tags"},{"content":"","date":"2022-11-07","externalUrl":null,"permalink":"/tags/serial-port/","section":"Tags","summary":"","title":"Serial Port","type":"tags"},{"content":" 💾 Serial Port Programming with Qt on VxWorks 6.8 # This article demonstrates how to implement serial port communication (UART) in VxWorks 6.8 using the Qt framework, combining the strengths of real-time embedded systems with modern UI-based application design.\nFor related topics, see Serial Test Program Design and Source Code for VxWorks.\n🧠 Introduction to VxWorks # VxWorks is an embedded Real-Time Operating System (RTOS) developed by Wind River Systems since 1983. It has become one of the most trusted RTOS platforms, known for its:\nDeterministic performance High reliability Rich development tools VxWorks is used in mission-critical systems, including:\nAerospace and Defense: F-16, FA-18, B-2, Patriot Missiles Space Exploration: Mars Rovers (Sojourner, Phoenix, Curiosity) Industrial and Medical Applications Its robust kernel and proven performance make it an ideal platform for systems that demand precision, safety, and real-time responsiveness.\n🔌 Serial Port Overview # A serial port (often referred to as a COM port) is a communication interface that transfers data bit by bit over a single channel. It’s widely used in embedded systems for connecting sensors, controllers, and peripheral devices.\nAdvantages:\nSimple wiring (only TX/RX lines required) Cost-effective and reliable Ideal for long-distance communication Common standards:\nRS-232 — general PC communication (9-pin or 25-pin) RS-422 / RS-485 — industrial applications, supporting long-distance and multi-drop connections Quick Loopback Test Tip:\nIf using a 9-pin RS-232 connector, connect Pin 2 and Pin 3 together for a simple loopback test. Also connect Pin 5 (ground) to ensure accurate data transmission.\n🧰 RS-232 Wiring Methods # RS-232 cables can be configured in two ways:\nStraight-through: used between a PC and a device Crossover: used between two devices Choose the cable type based on your communication setup.\n💻 VxWorks Serial Programming Essentials # Include Headers # #include \u0026#34;vxWorks.h\u0026#34; #include \u0026#34;stdIo.h\u0026#34; #include \u0026#34;ioLib.h\u0026#34; #include \u0026#34;sysLib.h\u0026#34; #include \u0026#34;string.h\u0026#34; #include \u0026#34;taskLib.h\u0026#34; Serial Port Configuration # ioctl(m_SeriPort, SIO_HW_OPTS_SET, CLOCAL | CS8 | PARODD | PARENB); // 8 data bits | 1 stop bit | even parity ioctl(m_SeriPort, FIOBAUDRATE, 9600); // Baud rate 9600 ioctl(m_SeriPort, FIOSETOPTIONS, OPT_RAW); // Raw mode ioctl(m_SeriPort, FIOFLUSH, 0); // Flush buffers Opening the Serial Port # #define SERI_NAME \u0026#34;/tyCo/0\u0026#34; int m_SeriPort = open(SERI_NAME, O_RDWR, 0); Writing Data # char* sendData; int writeCom = write(m_SeriPort, sendData, strlen(sendData)); Reading Data # char data; int readCom = read(m_SeriPort, \u0026amp;data, 1); 🧩 Integrating Qt with VxWorks UART # Thread Class — Serial Port Handler # #ifndef THREAD_H #define THREAD_H #include \u0026lt;QThread\u0026gt; #include \u0026lt;QDebug\u0026gt; #include \u0026#34;vxWorks.h\u0026#34; #include \u0026#34;stdIo.h\u0026#34; #include \u0026#34;ioLib.h\u0026#34; #include \u0026#34;sysLib.h\u0026#34; #include \u0026#34;string.h\u0026#34; #include \u0026#34;taskLib.h\u0026#34; class Thread : public QThread { Q_OBJECT public: explicit Thread(QObject *parent = 0); ~Thread(); void run(); bool openSeri(QString comPort, int baudRate); void closeSeri(); void writeSeri(char* sendData); void setFlag(bool flag = true); signals: void RecvData(char data); private: bool seriStop; int m_SeriPort; QString m_SeriName; int m_baud; }; #endif // THREAD_H Thread Implementation # #include \u0026#34;thread.h\u0026#34; Thread::Thread(QObject *parent) : QThread(parent) {} Thread::~Thread() {} void Thread::run() { sysClkRateSet(1000); char rData; while (1) { int readCom = read(m_SeriPort, \u0026amp;rData, 1); if (readCom \u0026gt; 0) { printf(\u0026#34;%c\\n\u0026#34;, rData); emit RecvData(rData); if (!seriStop) break; } else { taskDelay(10); } } } bool Thread::openSeri(QString comPort, int baudRate) { this-\u0026gt;m_SeriName = comPort; this-\u0026gt;m_baud = baudRate; m_SeriPort = open(comPort.toUtf8().data(), O_RDWR, 0); if (m_SeriPort == ERROR) { qDebug() \u0026lt;\u0026lt; \u0026#34;Open failed:\u0026#34; \u0026lt;\u0026lt; comPort; return false; } ioctl(m_SeriPort, SIO_HW_OPTS_SET, CLOCAL | CS8 | PARODD | PARENB); ioctl(m_SeriPort, FIOBAUDRATE, baudRate); ioctl(m_SeriPort, FIOSETOPTIONS, OPT_RAW); ioctl(m_SeriPort, FIOFLUSH, 0); qDebug() \u0026lt;\u0026lt; \u0026#34;Open succeeded:\u0026#34; \u0026lt;\u0026lt; comPort; return true; } void Thread::closeSeri() { if (!seriStop) { close(m_SeriPort); } } void Thread::writeSeri(char* sendData) { if (m_SeriPort == ERROR) openSeri(m_SeriName, m_baud); write(m_SeriPort, sendData, strlen(sendData)); } void Thread::setFlag(bool flag) { seriStop = flag; } Seri Class — User Interface Layer # #ifndef SERI_H #define SERI_H #include \u0026lt;QObject\u0026gt; #include \u0026lt;QDebug\u0026gt; #include \u0026#34;thread.h\u0026#34; class Seri : public QObject { Q_OBJECT public: explicit Seri(QObject *parent = 0); ~Seri(); bool open_Seri(QString comName, int comBaud); void write_Seri(QByteArray comData); void close_Seri(); signals: void send_Seri(char data); private: Thread* m_pThread; }; #endif // SERI_H #include \u0026#34;Seri.h\u0026#34; Seri::Seri(QObject *parent) : QObject(parent) { m_pThread = new Thread; } Seri::~Seri() { delete m_pThread; } bool Seri::open_Seri(QString comName, int comBaud) { if (m_pThread-\u0026gt;openSeri(comName, comBaud)) { m_pThread-\u0026gt;setFlag(true); m_pThread-\u0026gt;start(); return true; } return false; } void Seri::write_Seri(QByteArray comData) { m_pThread-\u0026gt;writeSeri(comData.data()); } void Seri::close_Seri() { if (m_pThread-\u0026gt;isRunning()) { m_pThread-\u0026gt;setFlag(false); m_pThread-\u0026gt;closeSeri(); m_pThread-\u0026gt;quit(); m_pThread-\u0026gt;wait(); } } 🧩 Code Structure Summary # Class Purpose Description Thread Serial Communication Thread Handles UART configuration, data transmission, and reception. Seri Application Interface Layer Manages thread lifecycle and integrates with Qt’s signals and slots. 🧭 Conclusion # This example shows how Qt and VxWorks can be combined to handle UART serial communication in embedded environments. By separating the serial logic (Thread) from the user interface (Seri), developers can build responsive, multi-threaded, and reliable communication applications on real-time systems.\n","date":"2022-11-07","externalUrl":null,"permalink":"/app/serial-port-programming-with-qt-on-vxworks-6.8/","section":"Apps","summary":"\u003ch2 class=\"relative group\"\u003e💾 Serial Port Programming with Qt on VxWorks 6.8 \n    \u003cdiv id=\"-serial-port-programming-with-qt-on-vxworks-68\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-serial-port-programming-with-qt-on-vxworks-68\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThis article demonstrates how to implement \u003cstrong\u003eserial port communication (UART)\u003c/strong\u003e in \u003cstrong\u003eVxWorks 6.8\u003c/strong\u003e using the \u003cstrong\u003eQt\u003c/strong\u003e framework, combining the strengths of real-time embedded systems with modern UI-based application design.\u003c/p\u003e","title":"Serial Port Programming with Qt on VxWorks 6.8","type":"app"},{"content":" 🎨 Qt 5.15.10 Released for VxWorks # Qt, a leading cross-platform C++ graphical user interface framework, provides developers with the essential tools to build modern and efficient UI applications. Known for its object-oriented design, Qt allows easy extensibility and supports modular, component-based development.\nFor related articles on VxWorks and Qt, see Installation, Setup, and Running of Qt on the VxWorks 6.8 Operating System.\n🎉 New Release: Qt 5.15.10 LTS for VxWorks # The commercial Long-Term Support (LTS) release of Qt 5.15.10 for VxWorks is now available as a source code distribution. Based on the latest Qt 5.15.10 LTS release, this update formally extends Qt’s compatibility with VxWorks, the industry-leading real-time operating system (RTOS).\nThis release marks a major step forward in providing reliable, long-term UI development tools for industries such as:\nAerospace and Defense Industrial Control Medical Systems It not only upgrades the Qt framework to a newer version but also introduces VxWorks-specific optimizations and fixes, ensuring smooth operation in time-critical and safety-focused environments.\n🧩 Supported Platforms # The release currently supports an Ubuntu host environment targeting i.MX6 hardware, with support for x86 and Windows hosts under preparation.\nLicensed Qt commercial users can access the package through their Qt Account or directly from the Git repository.\nFor access or licensing information, please contact the Qt sales team.\n🚀 Getting Started # Developers can refer to official documentation and community resources to begin building Qt-based applications on VxWorks:\nQt for VxWorks Documentation Qt 5.15 Reference Manual Getting Commercial Qt Sources 🧠 Summary # The release of Qt 5.15.10 for VxWorks bridges the gap between modern user interface frameworks and real-time operating environments.\nBy combining Qt’s rich UI capabilities with VxWorks’ deterministic performance, this integration empowers developers to create visually appealing, reliable, and responsive embedded systems across critical industries.\n","date":"2022-10-06","externalUrl":null,"permalink":"/news/qt-5.15.10-released-for-vxworks/","section":"News","summary":"\u003ch2 class=\"relative group\"\u003e🎨 Qt 5.15.10 Released for VxWorks \n    \u003cdiv id=\"-qt-51510-released-for-vxworks\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-qt-51510-released-for-vxworks\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eQt\u003c/strong\u003e, a leading cross-platform C++ graphical user interface framework, provides developers with the essential tools to build modern and efficient UI applications. Known for its object-oriented design, Qt allows easy extensibility and supports modular, component-based development.\u003c/p\u003e","title":"Qt 5.15.10 Released for VxWorks","type":"news"},{"content":"","date":"2022-10-06","externalUrl":null,"permalink":"/tags/ui-framework/","section":"Tags","summary":"","title":"UI Framework","type":"tags"},{"content":" VxWorks 7: Safe, Secure, and Reliable RTOS for Critical Systems\nAs intelligent systems become increasingly connected, autonomous, and software-defined, the demand for deterministic, secure, and safety-certified operating systems continues to grow. From commercial aircraft and industrial control systems to autonomous vehicles, medical devices, and defense platforms, modern embedded applications require an operating system capable of delivering predictable performance under the most demanding conditions.\nFor nearly four decades, VxWorks has been one of the most trusted names in embedded computing. Developed by Wind River, VxWorks 7 represents the latest evolution of the industry\u0026rsquo;s most widely deployed real-time operating system (RTOS), powering billions of devices worldwide across aerospace, defense, automotive, industrial, communications, and healthcare sectors.\nDesigned for the intelligent edge, VxWorks 7 combines deterministic real-time performance, advanced security capabilities, comprehensive safety certification support, and modern development tools within a highly scalable architecture.\n🚀 Built for the Intelligent Edge # The rise of edge computing has transformed embedded system requirements. Devices must now process data locally, make real-time decisions, support artificial intelligence workloads, and communicate securely across distributed networks.\nVxWorks 7 addresses these challenges through a modular and scalable architecture optimized for modern embedded platforms.\nKey design objectives include:\nDeterministic real-time performance High availability and reliability Safety certification readiness Cybersecurity resilience Multi-core scalability Long-term maintainability Support for heterogeneous hardware platforms These capabilities make VxWorks 7 suitable for applications where reliability and predictability are essential.\n⚙️ Advanced RTOS Architecture # At its core, VxWorks 7 delivers the low-latency scheduling and deterministic behavior required by mission-critical systems.\nFlexible Multi-Core Processing # Modern processors increasingly rely on multiple cores to deliver performance and efficiency.\nVxWorks 7 supports several execution models:\nAsymmetric Multiprocessing (AMP) Symmetric Multiprocessing (SMP) Bound Multiprocessing (BMP) BMP extends traditional multiprocessing by allowing applications to bind tasks to specific processor cores, enabling greater control over performance isolation and workload management.\nSophisticated Scheduling Capabilities # The operating system provides a range of scheduling mechanisms designed for real-time environments.\nSupported models include:\nPriority-based preemptive scheduling Round-robin scheduling Time partitioning Space partitioning Adaptive foreground/background execution These capabilities allow developers to optimize system responsiveness while maintaining deterministic behavior.\nBroad Processor Architecture Support # VxWorks 7 supports a diverse set of processor architectures, including:\nArm Arm64 Intel x86 Intel x86-64 Power Architecture RISC-V The platform also includes support for more than 80 Board Support Packages (BSPs), accelerating deployment across a wide range of embedded hardware platforms.\n🧩 Modern Software Development Environment # VxWorks 7 provides a contemporary software development ecosystem that supports both legacy and modern programming approaches.\nStandards-Based Development # Developers can leverage familiar standards and languages, including:\nPOSIX PSE52 C11 C++17 Boost Libraries Rust Python 3.8 This flexibility enables organizations to adopt modern software engineering practices while maintaining compatibility with existing codebases.\nMemory Protection and Isolation # A key architectural enhancement in VxWorks 7 is the separation of kernel and user space.\nBenefits include:\nImproved fault isolation Enhanced system stability Reduced attack surface Stronger security posture Applications execute within protected memory regions, minimizing the risk of system-wide failures caused by software defects.\nBackward Compatibility # Many organizations maintain long-lived embedded systems with extensive software investments.\nTo simplify migration, VxWorks 7 preserves compatibility with many VxWorks 6.x applications, helping organizations modernize without requiring complete software rewrites.\n🌐 High-Performance Networking and Connectivity # Connectivity has become a foundational requirement for modern embedded systems.\nVxWorks 7 includes a comprehensive networking stack designed for performance, scalability, and reliability.\nIPv4 and IPv6 Networking # The platform provides:\nFull IPv4 support Full IPv6 support High-performance network processing Enterprise-grade networking capabilities These features enable deployment across both legacy and next-generation network infrastructures.\nTime-Sensitive Networking (TSN) # Industrial and mission-critical applications increasingly require deterministic Ethernet communications.\nVxWorks 7 supports major TSN standards, including:\nIEEE 1588 Precision Time Protocol (PTP) IEEE 802.1AS IEEE 802.1Qbv IEEE 802.1Qbu These technologies enable precise synchronization and predictable network behavior across distributed systems.\nBroad Connectivity Options # Additional communication technologies include:\nIEEE 1394 Socket CAN USB Host USB Target USB OTG OPC UA This broad connectivity support simplifies integration into industrial, automotive, aerospace, and communications environments.\n💾 Reliable Storage and Multimedia Support # Embedded systems frequently require robust storage capabilities that can withstand unexpected power interruptions and harsh operating conditions.\nIndustrial-Grade File Systems # VxWorks 7 includes multiple file system options:\ndosFS # A FAT-compatible file system suitable for interoperability with external devices and removable media.\nHighly Reliable File System (HRFS) # Designed for mission-critical applications, HRFS provides:\nPower-fail protection Transaction-based operations NAND flash support NOR flash support Enhanced data integrity These capabilities help ensure data reliability in demanding deployment environments.\nMultimedia Frameworks # For systems requiring graphical interfaces or multimedia processing, VxWorks supports:\nOpenVG OpenGL ES JPEG libraries PNG libraries Touch and input devices PCM audio OpenCV integration This functionality enables sophisticated human-machine interfaces and edge vision applications.\n🔒 Security by Design # Cybersecurity is no longer optional for connected embedded systems. Critical infrastructure, transportation systems, and industrial platforms increasingly face sophisticated threats that demand a comprehensive security strategy.\nVxWorks 7 incorporates multiple layers of security protection throughout the software stack.\nSecure Boot and Trusted Execution # Platform integrity begins during system startup through:\nSecure boot mechanisms Secure ELF loading Trusted execution workflows These capabilities help prevent unauthorized software from executing on deployed systems.\nData Protection # VxWorks 7 supports:\nEncrypted storage Full disk encryption Secure key management Protected application data These features help safeguard sensitive operational information.\nKernel Hardening # Several kernel-level protections are available, including:\nNon-executable memory pages Stack protection mechanisms Kernel Page Table Isolation (KPTI) Memory access controls Together, these technologies reduce the likelihood of successful exploitation attempts.\nIdentity and Access Management # The operating system provides enterprise-grade authentication capabilities such as:\nUser account management Password enforcement policies Active Directory integration LDAP integration These features simplify deployment within regulated and security-sensitive environments.\nCryptography and Secure Communications # Security services include:\nOpenSSL integration FIPS 140-2 cryptographic support SSL/TLS protocols Secure Shell (SSH) IPsec networking Arm TrustZone support OP-TEE integration These technologies enable secure communications and trusted device operation.\nIndustrial Security Compliance # VxWorks 7 has achieved GE Digital Achilles Level II certification, demonstrating alignment with cybersecurity requirements associated with IEC 62443 industrial security frameworks.\n🛡️ Engineered for Functional Safety # Many VxWorks deployments operate within highly regulated environments where safety certification is mandatory.\nVxWorks 7 is designed to support certification efforts across multiple industries.\nAerospace Certification # The platform supports compliance activities associated with:\nDO-178C Design Assurance Level A (DAL A) This level is commonly required for software whose failure could contribute to catastrophic aircraft conditions.\nIndustrial Safety # Support is available for:\nIEC 61508 SIL 3 This standard is widely used in industrial automation and process control systems.\nAutomotive Functional Safety # Automotive developers can leverage support for:\nISO 26262 ASIL D This represents the highest automotive integrity level defined by the standard.\nMedical Device Software # The platform also supports:\nIEC 62304 This standard governs software development processes for medical devices and healthcare systems.\n🛠️ Development Tools and DevOps Integration # Modern embedded development requires more than a capable operating system. Efficient workflows, automation, and continuous validation have become essential.\nWind River Workbench # The primary development environment for VxWorks 7 is Wind River Workbench, an Eclipse-based integrated development environment.\nCapabilities include:\nProject management Source-level debugging Build automation Performance analysis System profiling Remote target management Compiler Support # Developers can leverage multiple compiler toolchains, including:\nLLVM-based toolchains for Arm and Intel architectures GCC toolchains for Power Architecture platforms This flexibility supports a wide range of deployment requirements.\nIntegrated Simulation # VxWorks includes a built-in simulator that enables:\nEarly software development Functional validation Regression testing Rapid prototyping Simulation can significantly reduce development costs and accelerate project timelines.\nDevOps and Quality Engineering # Wind River employs extensive automation throughout the VxWorks development lifecycle.\nKey practices include:\nContinuous integration workflows Automated regression testing Nightly validation testing Vulnerability monitoring Continuous quality assessment The platform reportedly benefits from highly automated testing processes, helping ensure reliability across releases.\n🌎 Enterprise Services and Global Support # Beyond the operating system itself, organizations gain access to a comprehensive ecosystem of services and support.\nProfessional Services # Wind River Professional Services provides expertise in:\nSystem architecture Board Support Package development Platform customization Migration projects Certification assistance The organization maintains a CMMI Level 3 appraisal, reflecting mature engineering processes.\nEducation and Training # Training programs support:\nDeveloper onboarding Advanced RTOS development Safety certification preparation System optimization These services help organizations maximize the value of their VxWorks deployments.\n🔍 Conclusion # VxWorks 7 continues to set the benchmark for real-time operating systems in mission-critical environments. By combining deterministic performance, multi-core scalability, advanced security capabilities, functional safety support, and modern development workflows, the platform provides a comprehensive foundation for intelligent edge computing.\nWhether deployed in aircraft flight control systems, autonomous vehicles, industrial automation platforms, medical devices, telecommunications infrastructure, or defense applications, VxWorks 7 delivers the reliability, safety, and security that critical systems demand.\nAs edge computing continues to expand and embedded systems become increasingly connected and autonomous, VxWorks 7 remains one of the industry\u0026rsquo;s most trusted platforms for building secure, resilient, and certifiable software solutions.\nWhen it matters, it runs on VxWorks.\n","date":"2022-06-21","externalUrl":null,"permalink":"/training/vxworks-7-safe-secure-and-reliable-rtos-for-critical-systems/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 7: Safe, Secure, and Reliable RTOS for Critical Systems\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eAs intelligent systems become increasingly connected, autonomous, and software-defined, the demand for deterministic, secure, and safety-certified operating systems continues to grow. From commercial aircraft and industrial control systems to autonomous vehicles, medical devices, and defense platforms, modern embedded applications require an operating system capable of delivering predictable performance under the most demanding conditions.\u003c/p\u003e","title":"VxWorks 7: Safe, Secure, and Reliable RTOS for Critical Systems","type":"training"},{"content":" VxWorks is a hard real-time operating system known for its outstanding real-time performance — but what makes it stand out compared to other RTOS options?\nThis article explores the real-time characteristics of VxWorks, developed by Wind River, and compares its performance with other popular real-time operating systems (RTOS).\n🧠 Understanding Real-Time Concepts # Real-time performance is fundamentally about response time — how quickly the system reacts to an event. Before diving into comparisons, it’s important to understand how time is measured in computing systems.\n1 second = 1000 milliseconds = 1,000,000 microseconds = 1,000,000,000 nanoseconds.\nThat’s a lot of precision to manage!\nLet’s examine time units in computing:\nClock Cycle (Period):\nA CPU running at 4 GHz has a clock cycle of 1 / 4 GHz = 0.25 ns — the smallest unit of work the CPU can perform.\nCPU Cycle (Machine Cycle):\nThe time needed to execute a basic instruction stage. It’s typically the minimum time to fetch an instruction word from memory.\nInstruction Cycle:\nThe total time required to fetch and execute one instruction. Complex instructions may require multiple cycles.\nMemory Clock Cycle:\nDDR memory typically runs around 400 MHz (2.5 ns per cycle). With bus latency, total access time often reaches tens of nanoseconds.\n→ CPU to memory speed ratio ≈ 100:1.\nDisk Access Time:\nMechanical hard disks operate in milliseconds, combining seek time and rotational latency.\n→ Memory to disk speed ratio ≈ 1000:1.\nThese relationships show that hardware access times differ drastically across system components. In a real-time system, minimizing these latencies is key to predictability and performance.\n⚙️ Real-Time Performance Metrics # Two core metrics define the real-time performance of an RTOS:\nTask Switching Time (Context Switch Time) # When multitasking, the OS saves the state of the current task and loads the next task’s state before execution.\nThis process — known as context switching — must be extremely fast and deterministic in a real-time system.\nInterrupt Response Time # The time elapsed between the arrival of an interrupt signal and the moment the CPU starts executing the Interrupt Service Routine (ISR).\nThis determines how quickly the OS can respond to external events.\n📊 Comparing RTOS Performance # Below is a benchmark comparison of task switching and interrupt response times across several RTOS:\nVxWorks uCOS-II RT-Linux 2.0 QNX 6.0 Hardware Platform MC68000 33MHz 486 66MHz 486 33MHz 486 Task context Switch Time 3.8 us \u0026lt; 9 us unknown 12.57 us Interrupt respone Time \u0026lt; 3 us \u0026lt; 7.5 us 25 us 7.54 us Observation:\nVxWorks consistently leads in both task switching and interrupt response performance — albeit at a higher licensing cost than most competitors.\nTypical results show both metrics in the microsecond (µs) range — equating to only a few thousand CPU clock cycles, depending on frequency.\n🧪 Measuring Execution Time in Practice # Here’s a simple example measuring the time taken to execute a basic loop 1 million times:\nint i = 1000000; int j = 0; while (i) { j += 0; i--; } timer = 2033 us; // Time consumed to execute this loop 1 million times The measured execution time (about 2033 µs) is comparable to the task switching time observed in VxWorks, illustrating just how fast these real-time operations can occur.\n🏁 Conclusion # VxWorks demonstrates exceptional real-time determinism and low latency, outperforming most competing RTOS in both interrupt and context switch performance. While its licensing costs are higher, the performance and reliability make it the platform of choice for mission-critical applications — from aerospace and defense to industrial automation and networking.\n","date":"2022-06-02","externalUrl":null,"permalink":"/industries/vxworks-real-time-performance-explained/","section":"Industries","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eVxWorks\u003c/strong\u003e is a hard real-time operating system known for its outstanding real-time performance — but what makes it stand out compared to other RTOS options?\u003c/p\u003e","title":"VxWorks Real-Time Performance Explained","type":"industries"},{"content":" VxWorks UART Programming: Serial Port Configuration and I/O\nUART (Universal Asynchronous Receiver/Transmitter) remains a fundamental interface for debugging, control, and device communication in embedded systems. While the programming model is broadly consistent across operating systems, VxWorks exposes UART functionality through its I/O system and ioctl interface.\nThis guide provides a practical walkthrough of configuring serial ports, performing read/write operations, and implementing a complete UART task in VxWorks.\n🛠️ Serial Port Configuration # Opening the Serial Device # Serial ports in VxWorks are exposed as device files:\nfd = open(\u0026#34;/tyCo/0\u0026#34;, O_RDWR, 0); /tyCo/0: First serial device O_RDWR: Enables both read and write access Device naming may vary depending on BSP and hardware configuration.\nConfiguring Mode and Buffers # Basic configuration is performed using ioctl():\nioctl(fd, FIOSETOPTIONS, OPT_RAW); ioctl(fd, FIOFLUSH, 0); OPT_RAW: Disables line processing (raw data mode) FIOFLUSH: Clears input/output buffers Common ioctl Commands # Command Purpose FIOBAUDRATE Set baud rate FIOGETOPTIONS Retrieve current options FIOSETOPTIONS Apply device options FIOREAD Query unread bytes FIOWRITE Query pending output FIOFLUSH Clear buffers FIOCANCEL Cancel I/O operations Setting Line Parameters # Hardware-level configuration is applied using:\nioctl(fd, SIO_HW_OPTS_SET, CS8 | PARENB | CLOCAL | CREAD); Key flags:\nCS8: 8 data bits PARENB: Enable parity PARODD: Odd parity (optional) CLOCAL: Ignore modem control CREAD: Enable receiver 🔄 UART Read and Write Operations # Once configured, UART communication uses standard POSIX-style APIs:\nint read(int fd, char *buffer, size_t maxbytes); int write(int fd, char *buffer, size_t nbytes); Parameters # fd: File descriptor from open() buffer: Data buffer maxbytes / nbytes: Transfer size These APIs integrate seamlessly with the VxWorks I/O system.\n💻 Complete UART Example # The following example demonstrates a UART task that periodically sends data while coordinating access via shared memory and semaphores.\n#include \u0026#34;vxWorks.h\u0026#34; #include \u0026#34;stdio.h\u0026#34; #include \u0026#34;ioLib.h\u0026#34; #include \u0026#34;taskLib.h\u0026#34; #include \u0026#34;sioLib.h\u0026#34; #include \u0026#34;sdLib.h\u0026#34; #include \u0026#34;semLib.h\u0026#34; #include \u0026#34;msgQLib.h\u0026#34; #define DEV_NAME \u0026#34;/tyCo/2\u0026#34; #define MAX_BUF_SIZE 20 #define SHARE_DATA_LENGTH 20 typedef struct unix_clock_struct { UINT32 sec; UINT32 msec; UINT8 quality; } UNIX_CLOCK_STRUCT; char *comdata; SEM_ID mutexComdata; int set_serial(int fd); void taskUart(void) { int ret; int fd = open(DEV_NAME, O_RDWR, 0); UNIX_CLOCK_STRUCT w_buff; if (fd \u0026lt; 0) printf(\u0026#34;open failed.\\n\u0026#34;); if (set_serial(fd) \u0026lt; 0) printf(\u0026#34;serial config failed.\\n\u0026#34;); while (1) { semTake(mutexComdata, WAIT_FOREVER); ioctl(fd, FIOFLUSH, 0); bzero(\u0026amp;w_buff, sizeof(w_buff)); memcpy(\u0026amp;w_buff, comdata, sizeof(w_buff)); if (write(fd, \u0026amp;w_buff.sec, sizeof(w_buff.sec)) \u0026lt; 0) printf(\u0026#34;write failed.\\n\u0026#34;); else printf(\u0026#34;write success: %d\\n\u0026#34;, w_buff.sec); semGive(mutexComdata); taskDelay(sysClkRateGet() * 2); } } int set_serial(int fd) { if (fd \u0026lt; 0) return -1; if (ioctl(fd, FIOBAUDRATE, 9600) \u0026lt; 0) return -1; if (ioctl(fd, SIO_HW_OPTS_SET, CREAD | CS8 | CLOCAL) \u0026lt; 0) return -1; return 0; } 🔍 Key Implementation Insights # Synchronization # Use semaphores (semTake, semGive) to protect shared data Prevent concurrent access to UART resources Buffer Management # Clear buffers before transmission (FIOFLUSH) Avoid stale or partial data reads Task-Based Design # Run UART logic in a dedicated task Control execution rate using taskDelay() ⚠️ Common Pitfalls # Incorrect Device Name # /tyCo/x mapping depends on BSP configuration Verify using system device listing Misconfigured Line Settings # Incorrect parity or data bits can corrupt communication Ensure both ends match configuration Blocking Behavior # read() may block if no data is available Consider non-blocking modes or timeouts ✅ Best Practices # Always validate file descriptors and return values Use raw mode for binary communication Encapsulate configuration into reusable functions Separate UART logic from application logic Log errors for easier debugging in production systems 📌 Conclusion # UART programming in VxWorks builds on a familiar POSIX-style model while leveraging powerful configuration via ioctl. By combining proper device setup, robust synchronization, and task-based design, developers can implement reliable serial communication for debugging, control, and data exchange.\nThis foundation can be extended to support interrupt-driven drivers, DMA-based transfers, or higher-level communication protocols in more advanced embedded systems.\nReference: VxWorks UART Programming: Serial Port Configuration and I/O\n","date":"2022-04-25","externalUrl":null,"permalink":"/app/vxworks-uart-programming-serial-port-configuration-and-read-write/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks UART Programming: Serial Port Configuration and I/O\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eUART (Universal Asynchronous Receiver/Transmitter) remains a fundamental interface for debugging, control, and device communication in embedded systems. While the programming model is broadly consistent across operating systems, VxWorks exposes UART functionality through its I/O system and \u003ccode\u003eioctl\u003c/code\u003e interface.\u003c/p\u003e","title":"VxWorks UART Programming: Serial Port Configuration and I/O","type":"app"},{"content":"","date":"2021-10-17","externalUrl":null,"permalink":"/tags/graphics/","section":"Tags","summary":"","title":"Graphics","type":"tags"},{"content":"","date":"2021-10-17","externalUrl":null,"permalink":"/tags/gui/","section":"Tags","summary":"","title":"GUI","type":"tags"},{"content":"","date":"2021-10-17","externalUrl":null,"permalink":"/tags/tilcon/","section":"Tags","summary":"","title":"Tilcon","type":"tags"},{"content":" Wind River Tilcon Adds OpenGL 3D Graphics for Embedded GUIs\nWind River, a wholly owned subsidiary of Intel, introduced a new version of the Wind River Tilcon Graphics Suite with support for 3D OpenGL (Open Graphics Library), extending its embedded GUI development capabilities to increasingly sophisticated visualization and control applications.\nTilcon is designed for embedded device manufacturers that need highly customized graphical interfaces without building the entire graphics stack from scratch. The new OpenGL capability targets demanding applications in aerospace and defense, industrial control, medical devices, transportation, and other embedded markets where responsive, graphics-rich user interfaces are becoming an important part of the product architecture.\nBy combining a visual development environment with a reusable GUI engine and OpenGL-based graphics acceleration, the suite aims to reduce GUI development effort while enabling richer interfaces across multiple hardware and operating-system configurations.\n🎨 3D OpenGL Support for Embedded Interfaces # The addition of 3D OpenGL provides Tilcon with a standardized graphics API for developing more sophisticated embedded interfaces.\nRather than limiting applications to conventional 2D widgets and static graphics, developers can use OpenGL-based rendering capabilities to build interfaces with richer visual effects and more complex graphical content.\nTarget applications include:\nMedical monitoring equipment Clinical and surgical system interfaces Railway operation and control panels Retail terminal interfaces Industrial control systems Aerospace and defense equipment These applications often combine real-time system information with graphical visualization, requiring the GUI layer to remain responsive while presenting increasingly complex information to operators.\nGraphics requirements in embedded systems # Embedded GUI workloads differ from desktop applications because the graphics subsystem must operate within constrained CPU, memory, storage, and power budgets.\nOpenGL provides a vendor-neutral graphics programming model that can take advantage of available hardware acceleration while allowing the application-level graphics code to remain relatively independent of the underlying GPU implementation.\nFor embedded products, this separation can simplify portability across supported processor and graphics platforms.\n🛠️ Tilcon Development Environment # The Wind River Tilcon Interface Development Tool provides a visual environment for constructing embedded user interfaces.\nIts drag-and-drop workflow allows developers to assemble interface components and rapidly create complete GUI applications without manually implementing every low-level graphics operation.\nThe approach is intended to reduce both development time and the engineering effort associated with maintaining custom graphics code.\nWind River Tilcon GUI Engine # At the center of the Tilcon architecture is the Wind River Tilcon GUI Engine, which abstracts many of the implementation details required by an embedded graphical interface.\nThe engine manages core GUI resources and rendering-related elements, including:\nGraphics primitives Fonts Text Images Colors Interface components Underlying graphics code This architecture allows application developers to focus more heavily on interface behavior and product-specific functionality rather than repeatedly implementing low-level GUI infrastructure.\nVisual development workflow # The Interface Development Tool provides a graphical authoring model that can accelerate common development activities:\nGUI Design | v Tilcon Interface Development Tool | v Tilcon GUI Engine | +-------------------+ | | v v Graphics / Rendering Fonts / Text / Images | v OpenGL / Platform Graphics Layer | v Embedded Hardware The separation between visual design, GUI services, and the underlying graphics implementation also makes the architecture more suitable for maintaining interfaces across multiple embedded product generations.\n💻 Operating System Support # The Tilcon Graphics Suite supports both Wind River operating systems and several third-party operating environments.\nWind River operating systems # The suite supports current versions of:\nVxWorks Wind River Linux This combination covers both real-time embedded systems and Linux-based embedded platforms.\nVxWorks is particularly relevant for deterministic embedded applications such as industrial control, aerospace, transportation, and other systems with real-time requirements.\nThird-party operating systems # The announced platform support also includes:\nWindows CE Windows XP Fedora Red Hat Enterprise Linux Ubuntu Supporting multiple operating systems allows organizations to reuse development concepts and GUI assets across different embedded product architectures.\n🧩 Hardware Platform Support # The release expanded hardware coverage to include several processor and embedded computing platforms:\nFreescale i.MX31 Intel Atom processors Texas Instruments OMAP platforms These platforms represented important embedded processing architectures for graphics-enabled devices, particularly where a product required a combination of application processing and hardware-accelerated graphics.\nOpenGL\u0026rsquo;s standardized programming model also helps separate higher-level GUI development from the implementation details of individual graphics processors.\n🌐 OpenGL as a Cross-Platform Graphics Layer # OpenGL is an open and vendor-neutral graphics standard designed to provide a consistent programming interface across different graphics implementations.\nFor embedded GUI development, this abstraction can be valuable because the application should not need to directly depend on the low-level details of every supported GPU.\nA simplified architecture is:\nApplication GUI | v Tilcon GUI Engine | v OpenGL API | v Platform Graphics Driver | v GPU / Graphics Hardware The underlying graphics driver remains responsible for translating OpenGL operations into hardware-specific commands.\nThis architecture provides a clearer separation between GUI application logic and platform-specific graphics implementation, which can improve portability when deploying similar interfaces across different embedded hardware.\n🚀 Accelerating Embedded GUI Development # One of Tilcon\u0026rsquo;s primary objectives is reducing the engineering effort required to develop and maintain sophisticated embedded interfaces.\nTraditional embedded GUI development can require substantial manual work across several layers:\nUser-interface design Widget implementation Graphics rendering Font and text handling Image management Input processing Platform integration Hardware-specific graphics acceleration Tilcon centralizes many of these responsibilities within its development tools and GUI engine.\nThe visual development workflow further reduces the amount of handwritten GUI implementation required for common interface components, potentially shortening development cycles and helping manufacturers bring graphics-intensive products to market faster.\n✈️ Industry Applications # The expanded graphics capabilities are particularly relevant to industries where the GUI is part of the operator\u0026rsquo;s primary interaction with the embedded system.\nAerospace and defense # Aerospace and defense systems can require dense displays containing status information, navigation data, system diagnostics, and other operational information.\nA graphics framework with OpenGL support provides a foundation for implementing richer visualization while retaining the deterministic characteristics required by embedded operating environments such as VxWorks.\nIndustrial control # Industrial control systems increasingly rely on graphical operator interfaces rather than simple text-based or static control panels.\nOpenGL-enabled graphics can support more sophisticated visualization of machine states, process information, alarms, and system diagnostics.\nMedical devices # Medical equipment requires interfaces that can present complex information clearly and efficiently.\nApplications such as patient monitoring systems and clinical equipment can benefit from graphical rendering capabilities while retaining a controlled embedded software architecture.\nTransportation # Railway control panels and other transportation systems require operators to interpret large amounts of system information quickly.\nRich graphical interfaces can provide more effective visualization of operational state, equipment status, alarms, and control functions.\n🗣️ Wind River\u0026rsquo;s Industry Position # Wind River positioned the OpenGL enhancement as a response to the growing complexity of embedded graphical interfaces.\nThe company\u0026rsquo;s product strategy emphasized the need for graphics frameworks that could help embedded developers create sophisticated user experiences without assuming the development model of a desktop operating system.\nThis was particularly important in vertical markets such as aerospace and defense, industrial control, and medical imaging, where the GUI is closely integrated with specialized hardware and operating-system requirements.\n🖥️ Wind River Hypervisor Adds Windows XP Guest Support # Alongside the Tilcon Graphics Suite update, Wind River announced additional functionality for the Wind River Hypervisor.\nThe update enabled Windows XP to run concurrently as a guest operating system alongside other operating systems, including VxWorks.\nA hypervisor-based architecture allows multiple operating environments to share a single hardware platform while maintaining separation between guest operating systems.\nA simplified configuration can be represented as:\n+--------------------------------------+ | Embedded Applications | +------------------+-------------------+ | VxWorks | Windows XP | | Guest | Guest | +------------------+-------------------+ | Wind River Hypervisor | +--------------------------------------+ | Embedded Hardware | +--------------------------------------+ This capability can be useful for systems that need to consolidate different software environments onto a single processor platform.\nFor example, a product could use VxWorks for real-time control functions while hosting an existing Windows-based application that depends on Windows XP compatibility.\n🔍 Architectural Significance # The combination of Tilcon\u0026rsquo;s OpenGL support and Wind River Hypervisor\u0026rsquo;s expanded guest operating-system capabilities reflects a broader trend in embedded computing: increasingly sophisticated application requirements are being combined with specialized real-time and hardware constraints.\nFrom the graphics perspective, Tilcon provides an abstraction layer between GUI development and platform-specific rendering implementations.\nFrom the virtualization perspective, Wind River Hypervisor provides isolation between different operating environments running on the same hardware.\nTogether, these technologies address two different layers of embedded-system complexity:\nLayer Technology Primary Role GUI development Tilcon Interface Development Tool Visual interface design GUI runtime Tilcon GUI Engine Rendering and interface management Graphics API OpenGL Standardized graphics interface Operating system VxWorks / Wind River Linux Embedded runtime environment Virtualization Wind River Hypervisor Multi-OS execution and isolation Hardware i.MX31 / Intel Atom / OMAP Target processing platform 📌 Summary # The updated Wind River Tilcon Graphics Suite introduced 3D OpenGL support to Wind River\u0026rsquo;s embedded GUI development platform, extending its capabilities for graphics-intensive applications in aerospace, defense, industrial control, medical, transportation, and retail systems.\nThe combination of the Tilcon Interface Development Tool and Tilcon GUI Engine provides a higher-level development model for creating customized embedded interfaces, while OpenGL supplies a standardized graphics layer capable of supporting hardware-accelerated rendering.\nThe release also expanded platform coverage across VxWorks, Wind River Linux, several third-party operating systems, and embedded hardware platforms including Freescale i.MX31, Intel Atom, and TI OMAP.\nAt the same time, the Wind River Hypervisor update added Windows XP guest support, enabling Windows XP to run concurrently with operating systems such as VxWorks. Together, these capabilities strengthened Wind River\u0026rsquo;s platform for developing graphics-rich, multi-OS embedded systems.\n","date":"2021-10-17","externalUrl":null,"permalink":"/news/wind-river-tilcon-adds-opengl-3d-graphics-for-embedded-guis/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eWind River Tilcon Adds OpenGL 3D Graphics for Embedded GUIs\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eWind River, a wholly owned subsidiary of Intel, introduced a new version of the \u003cstrong\u003eWind River Tilcon Graphics Suite\u003c/strong\u003e with support for 3D OpenGL (Open Graphics Library), extending its embedded GUI development capabilities to increasingly sophisticated visualization and control applications.\u003c/p\u003e","title":"Wind River Tilcon Adds OpenGL 3D Graphics for Embedded GUIs","type":"news"},{"content":"","date":"2021-10-17","externalUrl":null,"permalink":"/tags/3d%E5%9B%BE%E5%BD%A2/","section":"Tags","summary":"","title":"3D图形","type":"tags"},{"content":"","date":"2021-10-17","externalUrl":null,"permalink":"/tags/simnt/","section":"Tags","summary":"","title":"SIMNT","type":"tags"},{"content":"","date":"2021-10-17","externalUrl":null,"permalink":"/tags/uglteapot/","section":"Tags","summary":"","title":"Uglteapot","type":"tags"},{"content":" VxWorks下编译运行Mesa OpenGL入门教程\n一、前言 # OpenGL 是著名的图形 API，其主要作用是依据照相机的设置，将指定图元绘制到帧缓冲中去。\nMesa 是 OpenGL 的一个具体实现，目前版本是 7.0.2。\nDRI（Direct Render Infrastructure，直接渲染架构）包含了诸如 ATI r300 显卡的子项目。\nMesa 原先是为 UNIX/X11 设计的。Mesa 对于 OpenGL 的实现是纯软件的，不含硬件加速，所以跑 3D 图形时帧率较低。\nDRI 提供了一个安全的接口，让 Mesa（以及其他 OpenGL 实现）可以安全地使用显卡提供的硬件加速功能。\n风河对于 Mesa 的支持貌似在 5.0 就停止更新了，现在 Mesa 7.0.2 中关于 WindML 中跑 3D 的代码还是很多年前的。\n但对于入门 OpenGL，学习空间、投影变换、光照、纹理、显示列表等概念，这已经足够了。\n所以写这个帖子只是让大家知道如何在 VxWorks 下开始步入 OpenGL 世界，学习 OpenGL 基本概念。\n而要真正开发应用程序，就一定要用 DRI 了，这不在本文范围内。\n二、准备工作 # 我的开发环境是：\nTornado 2.2 VxWorks 5.5 WindML 3.0 Mesa 4.0（后面提供下载） 三、编译 Mesa for WindML 3D 图形库 # 下载 Mesa 4.0 后，解压到 C:\\Tornado2.2\\target\\src 下。\n3.1 创建工程并添加源文件 # 在 Tornado 下建立一个可下载工程（基于 SIMNTgnu），然后添加以下所有源文件到工程中（不要遗漏）。\nGL（最主要的图形库） # GL_SOURCES = \\ api_arrayelt.c \\ （在 C:\\Tornado2.2\\target\\src\\Mesa\\src 下） api_loopback.c \\ api_noop.c \\ api_validate.c \\ accum.c \\ attrib.c \\ blend.c \\ buffers.c \\ clip.c \\ colortab.c \\ config.c \\ context.c \\ convolve.c \\ debug.c \\ depth.c \\ dispatch.c \\ dlist.c \\ drawpix.c \\ enable.c \\ enums.c \\ eval.c \\ extensions.c \\ feedback.c \\ fog.c \\ get.c \\ glapi.c \\ glthread.c \\ hash.c \\ hint.c \\ histogram.c \\ image.c \\ imports.c \\ light.c \\ lines.c \\ matrix.c \\ mem.c \\ mmath.c \\ pixel.c \\ points.c \\ polygon.c \\ rastpos.c \\ state.c \\ stencil.c \\ texformat.c \\ teximage.c \\ texobj.c \\ texstate.c \\ texstore.c \\ texutil.c \\ varray.c \\ vtxfmt.c \\ X86/x86.c \\ （C:\\Tornado2.2\\target\\src\\Mesa\\src\\X86 下） X86/common_x86.c \\ X86/3dnow.c \\ X86/sse.c \\ math/m_debug_clip.c \\ （C:\\Tornado2.2\\target\\src\\Mesa\\src\\math 下） math/m_debug_norm.c \\ math/m_debug_vertex.c \\ math/m_debug_xform.c \\ math/m_eval.c \\ math/m_matrix.c \\ math/m_translate.c \\ math/m_vector.c \\ math/m_vertices.c \\ math/m_xform.c \\ array_cache/ac_context.c \\（C:\\Tornado2.2\\target\\src\\Mesa\\src\\array_cache 下） array_cache/ac_import.c \\ swrast/s_aaline.c \\ （C:\\Tornado2.2\\target\\src\\Mesa\\src\\swrast 下） swrast/s_aatriangle.c \\ swrast/s_accum.c \\ swrast/s_alpha.c \\ swrast/s_alphabuf.c \\ swrast/s_bitmap.c \\ swrast/s_blend.c \\ swrast/s_buffers.c \\ swrast/s_copypix.c \\ swrast/s_context.c \\ swrast/s_depth.c \\ swrast/s_drawpix.c \\ swrast/s_feedback.c \\ swrast/s_fog.c \\ swrast/s_histogram.c \\ swrast/s_imaging.c \\ swrast/s_lines.c \\ swrast/s_logic.c \\ swrast/s_masking.c \\ swrast/s_pb.c \\ swrast/s_pixeltex.c \\ swrast/s_points.c \\ swrast/s_readpix.c \\ swrast/s_scissor.c \\ swrast/s_span.c \\ swrast/s_stencil.c \\ swrast/s_texture.c \\ swrast/s_texstore.c \\ swrast/s_triangle.c \\ swrast/s_zoom.c \\ swrast_setup/ss_context.c \\ swrast_setup/ss_triangle.c \\ swrast_setup/ss_vb.c \\ tnl/t_array_api.c \\ （C:\\Tornado2.2\\target\\src\\Mesa\\src\\tnl 下） tnl/t_array_import.c \\ tnl/t_context.c \\ tnl/t_eval_api.c \\ tnl/t_imm_alloc.c \\ tnl/t_imm_api.c \\ tnl/t_imm_debug.c \\ tnl/t_imm_dlist.c \\ tnl/t_imm_elt.c \\ tnl/t_imm_eval.c \\ tnl/t_imm_exec.c \\ tnl/t_imm_fixup.c \\ tnl/t_pipeline.c \\ tnl/t_vb_fog.c \\ tnl/t_vb_light.c \\ tnl/t_vb_normals.c \\ tnl/t_vb_points.c \\ tnl/t_vb_render.c \\ tnl/t_vb_texgen.c \\ tnl/t_vb_texmat.c \\ tnl/t_vb_vertex.c UGL # UGL_SOURCES = \\ windml/ugl_api.c \\ （C:\\Tornado2.2\\target\\src\\Mesa\\src\\windml 下） windml/ugl_dd.c \\ windml/ugl_span.c \\ windml/ugl_line.c \\ windml/ugl_tri.c \\ windml/tornado/torMesaUGLInit.c （C:\\Tornado2.2\\target\\src\\Mesa\\src\\windml\\tornado 下） OS # OS_SOURCES = \\ OSmesa/osmesa.c \\ （C:\\Tornado2.2\\target\\src\\Mesa\\src\\OSmesa 下） windml/tornado/torMesaOSInit.c （C:\\Tornado2.2\\target\\src\\Mesa\\src\\windml\\tornado 下） GLUTSHAPES # GLUTSHAPES_SOURCES = \\ windml/ugl_glutshapes.c \\ （C:\\Tornado2.2\\target\\src\\Mesa\\src\\windml 下） windml/tornado/torGLUTShapesInit.c （C:\\Tornado2.2\\target\\src\\Mesa\\src\\windml\\tornado 下） GLU # GLU_SOURCES = \\ glu.c \\ （在 C:\\Tornado2.2\\target\\src\\Mesa\\src-glu 下） mipmap.c \\ nurbs.c \\ nurbscrv.c \\ nurbssrf.c \\ nurbsutl.c \\ polytest.c \\ project.c \\ quadric.c \\ tess.c \\ tesselat.c \\ ../src/windml/tornado/torMesaGLUInit.c （在 C:\\Tornado2.2\\target\\src\\Mesa\\src\\windml\\tornado 下） 3.2 准备头文件 # 在 C:\\Tornado2.2\\target\\h 下建立 GL 文件夹（存放 OpenGL 头文件）。\n将以下文件从 C:\\Tornado2.2\\target\\src\\Mesa\\include\\ 拷贝到刚建立的 GL 文件夹下：\ngl.h glext.h glu.h osmesa.h uglglutshapes.h uglmesa.h 3.3 配置工程并编译 # 更改 Tornado 工程 Builds 选项卡中的 C/C++ Compiler 选项，添加 include path： C:\\Tornado2.2\\target\\src\\Mesa\\include C:\\Tornado2.2\\target\\src\\Mesa\\src 更改 Rules 选项卡，改为 archive（生成 .a 文件）。\n编译工程。编译成功后会在工程目录下生成 .a 文件。\n四、建立一个 VxWorks 工程 # 4.1 新建基于 simpc BSP 的 VxWorks 工程 # 将 WindML 的以下组件包含到 VxWorks：\ncomplete 2D 图形库 simulator host devices Simulator graphics 4.2 编译 VxWorks # 如果对这一步不熟悉，可以搜索论坛中关于 WindML 的安装及编译相关文章，这里不再赘述。\n五、运行 DEMO 程序 # 建立一个可下载工程（基于 SIMNTgnu 工具链）。 以 uglteapot 为例，将以下文件添加到工程： C:\\Tornado2.2\\target\\src\\Mesa\\windmldemos\\uglteapot.c 把 taskSpawn 中的 UGL_FALSE 修改为 UGL_TRUE，如下： void uglteapot (void) { taskSpawn (\u0026#34;tTeapot\u0026#34;, 210, VX_FP_TASK, 100000, (FUNCPTR)windMLTeapot, UGL_TRUE, 1, 2, 3, 4, 5, 6, 7, 8, 9); } 更改 Tornado 工程 Builds 选项卡中的 Macros 选项。\n在 PRJ_LIBS 中把生成的 .a 路径添加进去。\n示例：\nC:/Tornado2.2/target/proj/MesaLib/SIMNTgnu/MesaLib.a 编译工程，生成 .out 文件。 运行刚才生成的 VxWorks。 开启一个 Shell，下载 .out 文件。 在 Shell 下输入命令： uglteapot 运行结果说明 # 可按左右键旋转茶壶 按 K 键打开/关闭光照 按 ESC 退出 也可在 VMware 下的 VxWorks 中测试 DEMO。\n注意：\n由于不支持双缓冲，图形显示时会有一些问题。 在 simpc 下显示正常，但速度较慢。 六、总结 # 环境搭建好后，大家可以参考 DEMO 里的流程来写自己的 Demo，学习 OpenGL。\n","date":"2021-10-17","externalUrl":null,"permalink":"/windml/912-setup-programming-environment-for-open-gl-in-vxworks/","section":"Windmls","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks下编译运行Mesa OpenGL入门教程\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e一、前言 \n    \u003cdiv id=\"%E4%B8%80%E5%89%8D%E8%A8%80\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#%E4%B8%80%E5%89%8D%E8%A8%80\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eOpenGL 是著名的图形 API，其主要作用是依据照相机的设置，将指定图元绘制到帧缓冲中去。\u003c/p\u003e","title":"VxWorks下编译运行Mesa OpenGL入门教程","type":"windml"},{"content":"","date":"2021-10-17","externalUrl":null,"permalink":"/tags/%E5%B5%8C%E5%85%A5%E5%BC%8Fopengl/","section":"Tags","summary":"","title":"嵌入式OpenGL","type":"tags"},{"content":"Find out how the VxWorks real-time operating system can meet your intelligent systems needs.\n","date":"2021-10-04","externalUrl":null,"permalink":"/video/meet-the-vxworks-rtos/","section":"Videoes","summary":"\u003cp\u003eFind out how the VxWorks real-time operating system can meet your intelligent systems needs.\u003c/p\u003e\n\u003clite-youtube videoid=\"7D6XuIMz9mA\" playlabel=\"7D6XuIMz9mA\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"Meet the VxWorks RTOS","type":"video"},{"content":"","date":"2021-02-13","externalUrl":null,"permalink":"/tags/ieee-802.3/","section":"Tags","summary":"","title":"IEEE 802.3","type":"tags"},{"content":"","date":"2021-02-13","externalUrl":null,"permalink":"/tags/mdio/","section":"Tags","summary":"","title":"MDIO","type":"tags"},{"content":"","date":"2021-02-13","externalUrl":null,"permalink":"/tags/phy/","section":"Tags","summary":"","title":"PHY","type":"tags"},{"content":" RTOS Clause 45 PHY Support in QNX and VxWorks\nModern Ethernet PHY devices have evolved far beyond the simple 10/100 Mbit/s transceivers originally envisioned by early IEEE 802.3 specifications. As network speeds increased and PHY functionality expanded, vendors introduced increasingly sophisticated devices requiring larger register spaces, proprietary initialization sequences, and advanced management interfaces.\nSupporting these newer PHYs in embedded real-time operating systems can become surprisingly complex, particularly when combining:\nClause 45 PHY devices Legacy Clause 22 MAC interfaces Vendor-specific register models RTOS-specific network driver architectures Recently, two separate projects required adding support for a new IEEE 802.3 Clause 45 PHY:\nOne targeting QNX One targeting VxWorks Although the underlying hardware requirements were similar, the networking architectures of the two RTOSes led to very different implementation strategies.\nThis article explores how Clause 45 PHY management works and compares how QNX and VxWorks approach Ethernet PHY integration.\n🌐 Understanding IEEE 802.3 Clause 22 # The Ethernet PHY (physical layer device) is responsible for transmitting and receiving Ethernet signals between the MAC (Media Access Controller) and the physical medium.\nTypical media include:\nTwisted-pair Ethernet CAT-5/CAT-6 cabling Fiber optics Backplane interfaces IEEE 802.3 Clause 22 defines the traditional PHY management model, including the MDIO (Management Data Input/Output) interface used for:\nPHY configuration Link management Status reporting Auto-negotiation control Although MDIO is technically distinct from MII, the terms are often used interchangeably in practice.\nClause 22 Addressing Model # Clause 22 provides:\nUp to 32 PHY devices on a shared MDIO bus A 5-bit PHY address space 32 standard registers per PHY This model worked well for early Ethernet hardware but eventually became too limited as PHY devices evolved.\n⚡ Why Clause 45 Was Introduced # As Ethernet PHYs became more advanced, vendors needed:\nLarger register spaces Extended diagnostics Calibration controls Vendor-specific features Multi-gigabit configuration support IEEE 802.3 Clause 45 expanded the management architecture significantly.\nClause 45 defines:\nUp to 32 PHY devices on MDIO Up to 32 MDIO Manageable Devices (MMDs) per PHY A 16-bit register space per MMD Up to 65,536 registers per MMD This dramatically increased management flexibility.\nClause 45 also introduced dedicated MMDs for:\nPMA/PMD management PCS management PHY XS layers Vendor-specific extensions If standard Clause 22 registers exist, they typically appear within:\nMMD 0 🔄 Accessing Clause 45 Devices Through Clause 22 # A practical problem quickly emerged after Clause 45 adoption:\nMany systems still used older Clause 22 MAC controllers.\nThe industry solution was an indirect access mechanism allowing Clause 45 registers to be accessed using standard Clause 22 MDIO operations.\nThe mechanism uses:\nClause 22 Register 13 # Used to:\nSelect the target MMD Define read/write operations Clause 22 Register 14 # Used to:\nSpecify Clause 45 register addresses Read register values Write register values This indirect mechanism allows legacy MAC hardware to communicate with modern Clause 45 PHYs without requiring native Clause 45 controllers.\n⚠️ The Real Problem: Vendor-Specific PHY Behavior # Although Clause 45 standardizes much of the management model, PHY vendors frequently implement proprietary behavior.\nCommon examples include:\nNon-standard status registers Vendor-specific initialization sequences Custom calibration procedures Proprietary link reporting Hidden diagnostic features From a software engineering perspective, this creates substantial complexity.\nTwo PHYs may both claim Clause 45 support while requiring completely different initialization and runtime handling logic.\nMarvell and Broadcom PHYs are particularly well known for requiring extensive vendor-specific handling.\n🧩 QNX PHY Management Architecture # In QNX, the Ethernet MAC driver is responsible not only for MAC management but also for PHY interaction.\nResponsibilities include:\nPHY register access via MDIO PHY initialization Link negotiation Media advertisement Status reporting QNX simplifies this using its MII management library.\nThe library provides APIs for:\nPHY reset Auto-negotiation Link status retrieval Duplex configuration Speed management This avoids duplicating PHY logic across multiple Ethernet drivers.\nHowever, the architecture tightly couples PHY behavior with MAC driver implementation.\n🔧 Clause 45 Support in QNX # Recent QNX releases added Clause 45 support through an updated MII management library.\nQNX SDP 7.1 includes:\nClause 45 MDIO indirection support Limited support for several PHY devices Clause 22-to-Clause 45 register translation However, extending support for new PHYs introduces complications.\nA standard QNX development license typically does not include operating system source code, including networking libraries.\nThis leaves several options:\nPurchase source licenses Use vendor consulting services Implement PHY support inside the MAC driver None of these options were ideal for the customer involved in this project.\n📊 A Data-Driven PHY Abstraction for QNX # Instead of modifying the MII library directly, the solution adopted a data-driven PHY abstraction model.\nThe implementation defined device-specific attributes such as:\nPHY device identifiers Link-speed configuration sequences Link-status register mappings Initialization register sequences The key insight was to emulate a standard Clause 22 PHY interface.\nInternally:\nClause 22 register accesses were intercepted Corresponding Clause 45 operations were performed Results were translated back into Clause 22-compatible values This allowed the existing QNX MII management library to interact with the PHY transparently.\nAdvantages included:\nNo modification to QNX libraries Extensible PHY support Reduced future engineering effort Device support driven by configuration data This approach effectively virtualized Clause 45 PHY behavior behind a Clause 22-compatible interface.\n🚌 VxWorks PHY Management Architecture # VxWorks uses a fundamentally different networking model.\nIn VxWorks:\nThe MAC driver handles MDIO register access A separate PHY driver manages PHY behavior The PHY driver is responsible for:\nLink negotiation Media advertisement PHY configuration Link monitoring Speed and duplex management This separation creates a cleaner driver architecture.\nMost standard PHYs can operate using generic PHY drivers with little additional work.\nOnly more complex devices require dedicated PHY drivers.\n🚀 Clause 45 Support in VxWorks # VxWorks 7 includes native support for:\nClause 45 register indirection PHY driver models VxBus PHY integration MDIO abstraction layers Unlike QNX, VxWorks development licenses typically include:\nKernel source code Driver source code PHY framework implementation As a result, adding support for a new Clause 45 PHY was relatively straightforward.\nThe solution involved:\nImplementing a new PHY driver Integrating it with VxBus Defining Clause 45 access behavior Supporting vendor-specific initialization The existing VxWorks networking infrastructure handled the remaining integration automatically.\nCompared to the QNX implementation, the VxWorks solution was significantly simpler from an architectural perspective.\n🧠 Comparing QNX and VxWorks PHY Models # The two RTOSes illustrate different philosophies in networking subsystem design.\nQNX Approach # Advantages:\nCentralized MII management Shared PHY functionality Reduced duplication Disadvantages:\nTighter MAC/PHY coupling Limited extensibility Difficult vendor-specific integration Restricted library visibility VxWorks Approach # Advantages:\nDedicated PHY driver model Cleaner separation of responsibilities Easier vendor-specific support Better scalability Disadvantages:\nMore individual drivers Potentially greater implementation effort for simple devices For advanced Clause 45 PHYs, the VxWorks model generally scales better.\n📈 The Growing Importance of Advanced PHY Support # Modern embedded networking increasingly relies on sophisticated Ethernet PHY devices supporting:\nMulti-gigabit Ethernet Time-sensitive networking (TSN) Automotive Ethernet Industrial Ethernet Precision timing Advanced diagnostics As embedded systems evolve toward:\nAutonomous platforms Industrial edge computing High-speed networking Distributed real-time systems robust PHY abstraction layers become increasingly important.\nClause 45 support is no longer optional in many modern embedded platforms.\n🔍 Final Thoughts # Although both QNX and VxWorks ultimately support Clause 45 PHY devices, the engineering effort required differs significantly because of their driver architectures.\nThe QNX implementation required:\nProtocol abstraction Clause 22 emulation Data-driven register translation The VxWorks implementation largely involved:\nWriting a conventional PHY driver Integrating with VxBus Leveraging existing PHY infrastructure In many ways, the project highlighted how operating system architecture strongly influences driver complexity, extensibility, and long-term maintainability.\nSometimes the most difficult part of embedded networking is not the protocol itself, but the surrounding software architecture used to support it.\n📚 References # IEEE 802.3 Clause 22 Specification IEEE 802.3 Clause 45 Specification QNX SDP Networking Documentation VxWorks 7 Networking Stack Documentation VxBus Driver Development Guide NetBSD MII/PHY Framework Documentation Reference: RTOS Clause 45 PHY Support in QNX and VxWorks\n","date":"2021-02-13","externalUrl":null,"permalink":"/training/rtos-clause-45-phy-support-in-qnx-and-vxworks/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eRTOS Clause 45 PHY Support in QNX and VxWorks\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eModern Ethernet PHY devices have evolved far beyond the simple 10/100 Mbit/s transceivers originally envisioned by early IEEE 802.3 specifications. As network speeds increased and PHY functionality expanded, vendors introduced increasingly sophisticated devices requiring larger register spaces, proprietary initialization sequences, and advanced management interfaces.\u003c/p\u003e","title":"RTOS Clause 45 PHY Support in QNX and VxWorks","type":"training"},{"content":"","date":"2021-01-20","externalUrl":null,"permalink":"/tags/acquisition/","section":"Tags","summary":"","title":"Acquisition","type":"tags"},{"content":" 💰 The Capital Transaction History of Wind River # In early 2022, Aptiv announced its agreement to acquire Wind River from TPG Capital for $4.3 billion in cash.\nThis acquisition is a strategic move to strengthen Aptiv’s position in critical software across various industries and accelerate its transition toward software-defined, edge-enabled systems.\nAfter completion, Wind River operates as an independent business unit under Aptiv’s Active Safety and User Experience segment, continuing to be led by President and CEO Kevin Dallas.\n⚙️ Wind River and the Real-Time OS Legacy # Wind River Systems is best known for VxWorks, a real-time multitasking operating system (RTOS) that has led the embedded OS market for more than 40 years.\nVxWorks is often hailed as the \u0026ldquo;evergreen RTOS\u0026rdquo;, powering countless mission-critical systems across aerospace, defense, telecommunications, and industrial control.\nWind River maintains two flagship embedded platforms:\nVxWorks — the industry-leading RTOS Wind River Linux — a hardened embedded Linux platform VxWorks provides:\nSupport for multi-core 32/64-bit processors Memory protection and management Connectivity components (USB, IPv4/IPv6, file systems) Advanced network protocols and multimedia Industry-specific variants for industrial, networking, and medical systems 🏗️ From Startup to Space: The Rise of Wind River # Founded in 1981, Wind River grew into the world’s largest embedded RTOS provider and a major embedded Linux vendor.\nKey Milestones # 1987: VxWorks released, based on VRTX 1993: Wind River IPO 1995: VxWorks launched aboard NASA’s Clementine lunar probe 1997: Used on NASA’s Mars Pathfinder mission By 2021, Wind River’s annual revenue was around $400 million with a gross margin above 80%.\nMarket Presence # Wind River’s business spans:\nAerospace \u0026amp; Defense (≈50% of revenue) Industrial \u0026amp; Medical Telecommunications Automotive Major Adopters # VxWorks runs on platforms such as:\nF-16, F/A-18, B-2, Apache, X-47A, Patriot Missiles Boeing 787, Airbus A380 NASA and SpaceX spacecraft Chinese Shenzhou-series systems (inspired by VxWorks 653) 💥 “Buy the Competition, Then Kill It!” # In 1999, Wind River acquired Integrated Systems Inc. (ISI) — the creator of the pSOS RTOS — and subsequently discontinued pSOS, encouraging customers to migrate to VxWorks.\nIn 2004, Wind River expanded into embedded Linux, launching a portable platform targeting the networking and communications market.\n💡 Certification Note:\nVxWorks has achieved ASIL-D automotive safety certification and DO-178C Level A certification — exceeding automotive safety standards and enabling it to challenge new industries with a “dimensionality reduction” advantage.\n🔁 Buy, Sell, Repeat: The Corporate Odyssey # 2009: Intel acquired Wind River for $884 million 2018: Intel sold Wind River to TPG Capital 2022: Aptiv acquired Wind River from TPG for $4.3 billion Intel’s brief ownership reflected the volatile nature of corporate strategy — acquiring innovative software firms only to sell them when they don’t align with changing priorities.\nWind River’s repeated sales mirror broader trends in the embedded systems industry, where software assets are frequently traded between industrial, automotive, and private equity players.\nEven other industry giants like Green Hills Software have been rumored as potential acquisition targets — signaling that the consolidation trend is far from over.\n🧩 Piercing the Real-Time OS Myth # In the Hardware-in-the-Loop (HIL) testing field, failures rarely stem from inadequate RTOS performance.\nInstead, most issues come from:\nPoorly defined functional requirements Incomplete toolchains Integration errors Cabling and automation gaps Even non-real-time systems, like Windows CE (used in some Vector tools), can perform reliably in automotive HIL setups.\nThe industry obsession with “hard real-time” capabilities often overlooks that many failures are caused by process, tooling, and testing issues — not the OS itself.\n💸 The Nature of Capital # Wind River’s acquisition history paints a clear picture of how capital behaves in the tech industry:\n“Buy fast, hype hard, sell early.”\nWhen financial or strategic interests shift, even foundational companies can be quickly divested.\nThis cyclical pattern — rapid acquisition, brief integration, and profitable exit — reveals how modern capital markets often treat innovation as a commodity rather than a long-term commitment.\nWind River, despite being passed from one corporate hand to another, continues to thrive as a core technology provider for industries that demand absolute reliability and real-time performance.\n","date":"2021-01-20","externalUrl":null,"permalink":"/news/the-capital-transaction-history-of-wind-river/","section":"News","summary":"\u003ch2 class=\"relative group\"\u003e💰 The Capital Transaction History of Wind River \n    \u003cdiv id=\"-the-capital-transaction-history-of-wind-river\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-the-capital-transaction-history-of-wind-river\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn early 2022, \u003cstrong\u003eAptiv\u003c/strong\u003e announced its agreement to acquire \u003cstrong\u003eWind River\u003c/strong\u003e from \u003cstrong\u003eTPG Capital\u003c/strong\u003e for \u003cstrong\u003e$4.3 billion in cash\u003c/strong\u003e.\u003cbr\u003e\nThis acquisition is a strategic move to strengthen Aptiv’s position in \u003cstrong\u003ecritical software\u003c/strong\u003e across various industries and accelerate its transition toward \u003cstrong\u003esoftware-defined, edge-enabled systems\u003c/strong\u003e.\u003c/p\u003e","title":"The Capital Transaction History of Wind River","type":"news"},{"content":"","date":"2021-01-20","externalUrl":null,"permalink":"/tags/tpg/","section":"Tags","summary":"","title":"TPG","type":"tags"},{"content":"","date":"2019-12-12","externalUrl":null,"permalink":"/tags/microchip/","section":"Tags","summary":"","title":"Microchip","type":"tags"},{"content":"","date":"2019-12-12","externalUrl":null,"permalink":"/tags/risc-v/","section":"Tags","summary":"","title":"RISC-V","type":"tags"},{"content":"","date":"2019-12-12","externalUrl":null,"permalink":"/tags/sifive/","section":"Tags","summary":"","title":"SiFive","type":"tags"},{"content":"Wind River, a leading provider of software for intelligent edge devices, has announced support for the RISC-V open architecture in its VxWorks Real-Time Operating System (RTOS). VxWorks is the most widely deployed commercial RTOS to embrace the RISC-V instruction set architecture (ISA), expanding its capabilities for embedded developers. Additionally, Wind River has joined the RISC-V Foundation, a non-profit dedicated to advancing the RISC-V ISA and its ecosystem across computing devices.\nVxWorks Enhances Embedded Development # VxWorks strengthens RISC-V’s role in real-time embedded applications\nThis RISC-V support builds on recent VxWorks innovations, including compatibility with C++17, Boost, Python, and Rust. These updates position VxWorks as a versatile RTOS for modern embedded systems.\nCalista Redmond, CEO of the RISC-V Foundation, welcomed Wind River’s contribution: “VxWorks significantly broadens RISC-V’s presence in the embedded developer community. We look forward to Wind River’s ongoing innovations and collaboration within the RISC-V ecosystem.”\nPartnerships with SiFive and Microchip # Wind River is collaborating with SiFive and Microchip to support RISC-V-based hardware, including SiFive’s Unleashed boards and Microchip’s PolarFire SoC FPGA family. “RISC-V’s open architecture brings dynamic innovation to hardware development,” said Michel Genard, vice president of product at Wind River. “Our partnerships with SiFive and Microchip enhance VxWorks’ support for their platforms, driving RISC-V’s success in embedded systems.”\nShakeel Peera, associate vice president of marketing for Microchip’s FPGA business unit, added: “VxWorks support for our PolarFire SoC FPGAs offers embedded designers a powerful, secure, and energy-efficient solution for real-time and Linux-capable applications. Our collaboration with Wind River strengthens the RISC-V ecosystem.”\nSupport for SiFive Core IP # Dr. Naveed Sherwani, president and CEO of SiFive, noted: “Wind River’s adoption of RISC-V in VxWorks is a significant milestone for the ecosystem. Running VxWorks on SiFive Core IP devices opens new opportunities for global application markets.”\n","date":"2019-12-12","externalUrl":null,"permalink":"/news/wind-river-adds-risc-v-support-to-vxworks-rtos/","section":"News","summary":"\u003cp\u003eWind River, a leading provider of software for intelligent edge devices, has announced support for the RISC-V open architecture in its VxWorks Real-Time Operating System (RTOS). VxWorks is the most widely deployed commercial RTOS to embrace the RISC-V instruction set architecture (ISA), expanding its capabilities for embedded developers. Additionally, Wind River has joined the RISC-V Foundation, a non-profit dedicated to advancing the RISC-V ISA and its ecosystem across computing devices.\u003c/p\u003e","title":"Wind River Adds RISC-V Support to VxWorks RTOS","type":"news"},{"content":"Specializing in delivering software for the intelligent network edge, Wind River announces support for the open RISC-V architecture in its VxWorks real-time operating system (RTOS).\nVxWorks is the most widely deployed commercial real-time operating system supporting the RISC-V architecture. The company has also joined the RISC-V Foundation, a nonprofit consortium created to standardize, protect and promote the RISC-V ISA and its associated hardware and software ecosystem for use in all computing devices. Wind River will continue to enhance its RTOS with support for the latest open hardware instruction set architectures.\nThe addition of RISC-V support to VxWorks follows a recent wave of innovations in the real-time operating system, making it the first to support C++17, Boost, Python, and the Rust collection.\n“ We are pleased to welcome Wind River to the RISC-V Foundation and our global ecosystem. VxWorks significantly extends the reach of RISC-V in the embedded world. We look forward to the software developments from Wind River and the RISC-V community ,” said Calista Redmond, Executive Director, RISC-V Foundation.\n“ It’s exciting to see RISC-V gain significant traction in the industry as it brings the dynamism of open architecture development to hardware. Wind River is excited to continue to innovate around VxWorks while contributing to the success of RISC-V with collaborations like the ones we have with SiFive and MicroChip to support their Unleashed and PolarFire SoC FPGA boards ,” said Michel Genard, vice president of products at Wind River.\n“ VxWorks’ support for our RISC-V-based PolarFire SoC FPGA family provides an extremely compelling offering to embedded system designers who increasingly need low-power, thermally efficient and secure, real-time, Linux-compatible solutions. Our partnership with Wind River is important as we work together to advance the RISC-V ecosystem and community ,” said Shakeel Peera, associate vice president of marketing, FPGA Division, Microchip.\n“ VxWorks’ adoption of RISC-V is an important milestone in the continued implementation of the RISC-V ecosystem. The ability to run VxWorks on SiFive Core IP and devices will open new application markets around the world ,” said Naveed Sherwani, president and CEO of SiFive.\n","date":"2019-12-11","externalUrl":null,"permalink":"/news/wind-river-announces-vxworks-support-for-risc-v/","section":"News","summary":"\u003cp\u003eSpecializing in delivering software for the intelligent network edge, Wind River announces support for the open RISC-V architecture in its VxWorks real-time operating system (RTOS).\u003c/p\u003e","title":"Wind River Announces VxWorks Support for RISC-V","type":"news"},{"content":"","date":"2019-07-29","externalUrl":null,"permalink":"/tags/ipnet/","section":"Tags","summary":"","title":"IPnet","type":"tags"},{"content":" Name Wind River VXWorks IPnet TCP/IP STACK Vulnerabilities Tracking Number 2019-001 First Publish Date 29 Jul 2019 Date of Current Status 24 Apr 2020 Next Planned Update N/A Description A number of vulnerabilities in Wind River’s VXWorks IPnet TCP/IP Stack implementation have been reported. These vulnerabilities could allow attackers to hijack existing TCP sessions to inject packets of their choosing or cause Denial of Service attacks. What You Need To Know? Security researchers reported multiple flaws in Wind River’s VXWorks IPnet TCP/IP Stack implementation that might allow an attacker to, among other things, hijack an existing TCP/IP connection, inject invalid TCP-segments, assign improper IP addresses or force transmittal of improperly formed data. This, in turn, can lead to man-in-the-middle, replay, and other network-based attacks.Currently available information suggests potential for buffer/heap overflows, race conditions, and NULL-pointer dereferencing that cause system or applications to crash or network connectivity issues due to improper network packets being sent. Current information also suggests access to the local LAN segment would be necessary for exploitation.The 11 CVEs that were reported for these flaws are CVE-2019-12255 through CVE-2019-12265. Exploitability scores are not yet available for these CVEs.One of more of these 11 vulnerabilities may affect products with the following: * All versions of VxWorks under CURRENT support (6.9.4.11, Vx7 SR540, Vx7 SR610) * Older, End-of-Life versions of VxWorks back to 6.5 * All versions of the discontinued product Advanced Networking Technology (ANT) * IPnet when sold as a standalone TCP/IP network stack * The VxWorks bootrom network stackVXWorks 5.3 through 6.4 and all VXWorks Cert versions are NOT affected by these 11 vulnerabilities. What is Xerox Doing About This? Xerox is working closely with Wind River and we will continue to monitor the situation as more information is provided by Wind River and the security researchers who reported the vulnerabilities. Impact Most Xerox products are not impacted. The following Xerox devices are currently known to be impacted: Phaser 3260, Phaser 3300, Phaser 3320, Phaser 3330, Phaser 3600, Phaser 3635 MFP, Phaser 4600/4620/4622, WorkCentre 3025, WorkCentre 3210/3220, WorkCentre 3215/3225, WorkCentre 3315/3325, WorkCentre 3335/3345, WorkCentre 3550, WorkCentre 4250/4260, WorkCentre 4265, and Xerox B1022/B1025, Xerox Color C60/C70 Printer, Xerox Versant 80 Press, Xerox Versant 180 Press, Xerox Versant 2100 Press, and Xerox Versant 3100 Press. Software releases are available for: * WorkCentre 3335/3345, WorkCentre 3215/3225, WorkCentre 4265, WorkCentre 6605, WorkCentre 3615, WorkCentre 3315/3325, WorkCentre 4250/4260, WorkCentre 3025BI, WorkCentre 3205NI, WorkCentre 3215/3225 * Xerox B1022/B1025 * Xerox Phaser 3635MFP, Xerox Phaser 4600/4620, Xerox Phaser 4622, Xerox Phaser 3330, Xerox Phaser 3320, Xerox Phaser 6600, Xerox Phaser 3610, Xerox Phaser 3020, Xerox Phaser 3052/3060 * Xerox Color C60/C70 * Xerox Versant 80 Press, Xerox Versant 180 Press, Xerox Versant 2100 Press, Xerox Versant 3100 Press. Plans are underway to implement the patches created by Wind River to address the affected Xerox products. Software releases containing the fixes for these vulnerabilities will continue to be rolled out. What Should You Do? Wind River recommends that the following mitigations be performed for all products until patches become available: * Make sure to place your devices behind an external firewall and add a rule to drop/block any TCP-segment where the “Urgent Data” flag URG-flag is set. * If your VXWorks version has an internal firewall, make sure that it is also enabled and add the rule to drop/block any TCP-segment where the “Urgent Data” flag URG-flag is set adding the following rule: ‘block in quick proto tcp all flags U/U’.Always consult your IT department as appropriate.This notice will be updated as further information becomes available. ","date":"2019-07-29","externalUrl":null,"permalink":"/news/wind-river-vxworks-ipnet-tcp-ip-stack-vulnerabilities/","section":"News","summary":"\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003c/th\u003e\n          \u003cth\u003e\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eName\u003c/td\u003e\n          \u003ctd\u003eWind River VXWorks IPnet TCP/IP STACK Vulnerabilities\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eTracking Number\u003c/td\u003e\n          \u003ctd\u003e2019-001\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eFirst Publish Date\u003c/td\u003e\n          \u003ctd\u003e29 Jul 2019\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eDate of Current Status\u003c/td\u003e\n          \u003ctd\u003e24 Apr 2020\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eNext Planned Update\u003c/td\u003e\n          \u003ctd\u003eN/A\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eDescription\u003c/td\u003e\n          \u003ctd\u003eA number of vulnerabilities in Wind River’s VXWorks IPnet TCP/IP Stack implementation have been reported. These vulnerabilities could allow attackers to hijack existing TCP sessions to inject packets of their choosing or cause Denial of Service attacks.\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eWhat You Need To Know?\u003c/td\u003e\n          \u003ctd\u003eSecurity researchers reported multiple flaws in Wind River’s VXWorks IPnet TCP/IP Stack implementation that might allow an attacker to, among other things, hijack an existing TCP/IP connection, inject invalid TCP-segments, assign improper IP addresses or force transmittal of improperly formed data. This, in turn, can lead to man-in-the-middle, replay, and other network-based attacks.\u003c/br\u003eCurrently available information suggests potential for buffer/heap overflows, race conditions, and NULL-pointer dereferencing that cause system or applications to crash or network connectivity issues due to improper network packets being sent. Current information also suggests access to the local LAN segment would be necessary for exploitation.\u003c/br\u003eThe 11 CVEs that were reported for these flaws are CVE-2019-12255 through CVE-2019-12265. Exploitability scores are not yet available for these CVEs.\u003c/br\u003eOne of more of these 11 vulnerabilities may affect products with the following:\u003c/br\u003e * All versions of VxWorks under CURRENT support (6.9.4.11, Vx7 SR540, Vx7 SR610)\u003c/br\u003e * Older, End-of-Life versions of VxWorks back to 6.5\u003c/br\u003e * All versions of the discontinued product Advanced Networking Technology (ANT)\u003c/br\u003e * IPnet when sold as a standalone TCP/IP network stack\u003c/br\u003e * The VxWorks bootrom network stack\u003c/br\u003eVXWorks 5.3 through 6.4 and all VXWorks Cert versions are NOT affected by these 11 vulnerabilities.\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eWhat is Xerox Doing About This?\u003c/td\u003e\n          \u003ctd\u003eXerox is working closely with Wind River and we will continue to monitor the situation as more information is provided by Wind River and the security researchers who reported the vulnerabilities.\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eImpact\u003c/td\u003e\n          \u003ctd\u003eMost Xerox products are not impacted. The following Xerox devices are currently known to be impacted: Phaser 3260, Phaser 3300, Phaser 3320, Phaser 3330, Phaser 3600, Phaser 3635 MFP, Phaser 4600/4620/4622, WorkCentre 3025, WorkCentre 3210/3220, WorkCentre 3215/3225, WorkCentre 3315/3325, WorkCentre 3335/3345, WorkCentre 3550, WorkCentre 4250/4260, WorkCentre 4265, and Xerox B1022/B1025, Xerox Color C60/C70 Printer, Xerox Versant 80 Press, Xerox Versant 180 Press, Xerox Versant 2100 Press, and Xerox Versant 3100 Press.\u003c/br\u003e Software releases are available for:\u003c/br\u003e * WorkCentre 3335/3345, WorkCentre 3215/3225, WorkCentre 4265, WorkCentre 6605, WorkCentre 3615, WorkCentre 3315/3325, WorkCentre 4250/4260, WorkCentre 3025BI, WorkCentre 3205NI, WorkCentre 3215/3225\u003c/br\u003e * Xerox B1022/B1025\u003c/br\u003e * Xerox Phaser 3635MFP, Xerox Phaser 4600/4620, Xerox Phaser 4622, Xerox Phaser 3330, Xerox Phaser 3320, Xerox Phaser 6600, Xerox Phaser 3610, Xerox Phaser 3020, Xerox Phaser 3052/3060\u003c/br\u003e * Xerox Color C60/C70\u003c/br\u003e * Xerox Versant 80 Press, Xerox Versant 180 Press, Xerox Versant 2100 Press, Xerox Versant 3100 Press.\u003c/br\u003e Plans are underway to implement the patches created by Wind River to address the affected Xerox products. Software releases containing the fixes for these vulnerabilities will continue to be rolled out.\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eWhat Should You Do?\u003c/td\u003e\n          \u003ctd\u003eWind River recommends that the following mitigations be performed for all products until patches become available:\u003c/br\u003e * Make sure to place your devices behind an external firewall and add a rule to drop/block any TCP-segment where the “Urgent Data” flag URG-flag is set.\u003c/br\u003e * If your VXWorks version has an internal firewall, make sure that it is also enabled and add the rule to drop/block any TCP-segment where the “Urgent Data” flag URG-flag is set adding the following rule: ‘block in quick proto tcp all flags U/U’.\u003c/br\u003eAlways consult your IT department as appropriate.\u003c/br\u003eThis notice will be updated as further information becomes available.\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e","title":"Wind River VxWorks IPnet TCP/IP Stack Vulnerabilities","type":"news"},{"content":"","date":"2019-05-24","externalUrl":null,"permalink":"/tags/renesas-r-car/","section":"Tags","summary":"","title":"Renesas R-Car","type":"tags"},{"content":" Using VxWorks 7 VxBus Device-Specific Parameters\nEmbedded driver development frequently involves balancing flexibility, portability, and boot-time efficiency across multiple hardware configurations. Hard-coded driver parameters may work well during initial bring-up, but they often become problematic as systems evolve and new peripherals are introduced.\nVxWorks 7 addresses this challenge through VxBus device-specific parameters, allowing driver behavior to be customized dynamically using device tree configuration rather than static source modifications.\nThis article explores how device-specific parameters can be used to improve driver flexibility using a practical PCI Express example from a VxWorks 7 BSP developed for the Renesas R-Car H3 platform.\n⚙️ The Original BSP Environment # The BSP targeted the Renesas R-Car H3 SIP evaluation board and included drivers for several major SoC peripherals:\nSerial interfaces Ethernet controllers MMC storage I2C buses GPIO controllers PCI Express R-Car H3 Block Diagram As part of PCIe validation, an Intel i210 PCIe Ethernet adapter was connected to the board’s PCIe slot.\nThe validation process confirmed:\nPCIe link establishment Endpoint enumeration VxBus device discovery Network stack integration The i210 adapter successfully appeared as a secondary Ethernet interface on the system.\nAt this stage, the PCIe controller driver appeared stable.\n🧩 The Real-World Problem # The BSP was later deployed across multiple engineering teams working in different locations and using different PCIe peripherals.\nOne team reported a failure involving a PCIe CAN controller card.\nSymptoms included:\nPCIe endpoint not detected Link training failures Device initialization timeouts Investigation revealed the root cause:\nThe PCIe root complex driver used a hard-coded link establishment timeout of:\n1 ms This was sufficient for the Intel i210 card but insufficient for the CAN controller hardware, which required up to:\n5 ms to establish the PCIe link reliably.\n🚫 Why Hard-Coding Was the Wrong Solution # The simplest fix would have been increasing the timeout globally.\nHowever, this introduced a tradeoff.\nIf no PCIe endpoint device was installed:\nThe driver would still wait unnecessarily System boot time would increase All deployments would incur the penalty For embedded systems, particularly those with strict startup requirements, unnecessary delays are undesirable.\nThe better solution was making the timeout configurable per target system.\n🔧 Converting the Timeout into a VxBus Parameter # The first step was converting the hard-coded timeout into a VxBus device-specific parameter.\nA parameter table was added to the driver:\nLOCAL VXB_PARAMS rcarH3PcieParams[] = { { DLLACT_TIMEOUT_PARAM, VXB_PARAM_INT32, { (void *)DLLACT_TIMEOUT_US } }, { NULL, VXB_PARAM_END_OF_LIST, { NULL } } }; This table defines:\nParameter name Parameter type Default value The driver now had a configurable timeout rather than relying on a fixed compile-time constant.\n🚌 Enabling Parameter Support in the Driver # Next, the VxBus driver definition was updated to advertise parameter support.\nThis was done using:\nVXB_DRVFLAG_PARAM Example:\nVXB_DRV vxbFdtRcarH3PcieDrv = { { NULL }, RCAR_H3_PCIE_DRV_NAME, \u0026#34;Renesas R-Car H3 PCIe driver\u0026#34;, VXB_BUSID_FDT, VXB_DRVFLAG_PARAM, 0, rcarH3PcieMethodList, rcarH3PcieParams }; This flag tells the VxBus framework that the driver supports configurable runtime parameters.\n📥 Retrieving Parameters During Driver Initialization # The driver initialization logic was then updated to retrieve the parameter dynamically:\nif (vxbParamGet (pDev, DLLACT_TIMEOUT_PARAM, VXB_PARAM_INT32, \u0026amp;param) == OK) { dllActTimeoutUs = (unsigned)param.int32Val; } If the parameter was unavailable, the driver fell back to its default value.\nThis mechanism allows:\nSensible default behavior Optional board-specific overrides Runtime flexibility without source changes The resulting implementation became substantially more portable across hardware variants.\n🌲 Overriding Parameters from the Device Tree # The final step involved overriding the parameter using the device tree.\nVxWorks 7 supports driver parameter overrides inside the chosen node using a devparam section.\nGeneral structure:\nchosen { devparam { \u0026lt;device\u0026gt;@\u0026lt;unit\u0026gt; { \u0026lt;parameter\u0026gt; = \u0026lt;value\u0026gt;; }; }; }; This mechanism allows platform-specific driver tuning without modifying driver source code.\n🛠️ PCIe Timeout Override Example # The R-Car H3 device tree was updated to increase the PCIe DLL activation timeout:\nchosen { devparam { renesas,rcar-h3-pcie@0 { dllActTimeoutUs = \u0026lt;5000\u0026gt;; }; }; }; This changed the timeout from:\n1000 us to:\n5000 us for that specific hardware configuration.\nNo driver recompilation was required.\n🧪 Debug Output and Validation # With no PCIe card installed, the driver produced:\nrcarH3PcieHwInit: pDev 0xffff80000011f980: PCIe DLL not ready after 5000us This confirmed:\nThe parameter override was applied The driver used the new timeout value Device-tree configuration successfully influenced runtime behavior The engineering team using the CAN controller could now tune the timeout independently for their deployment.\n🚀 Why Device-Specific Parameters Matter # Device-specific parameters provide several major advantages in embedded systems development.\nFlexible Hardware Support # Different boards and peripherals often require:\nDifferent timing constraints Alternative initialization sequences Hardware-specific tuning Device parameters allow a single driver binary to support multiple deployment scenarios.\nReduced Source Modifications # Without configurable parameters, teams frequently:\nFork drivers Introduce board-specific patches Create maintenance fragmentation Parameterization reduces long-term maintenance overhead.\nFaster BSP Scalability # As BSPs expand across:\nMultiple boards Multiple customers Multiple peripherals device-specific tuning becomes increasingly important.\nCleaner Separation of Policy and Mechanism # The driver provides:\nMechanism while the device tree provides:\nPolicy This separation is a core principle of modern embedded platform design.\n🧠 VxBus and Modern Embedded Driver Architecture # VxBus provides a modular driver framework designed to support scalable BSP development across modern SoCs and heterogeneous hardware environments.\nCapabilities include:\nDevice tree integration Runtime parameterization Dynamic driver discovery Layered bus management Platform abstraction As embedded systems continue to grow more configurable and modular, runtime tunability becomes increasingly valuable.\nDevice-specific parameters are a small but powerful feature that can dramatically improve BSP portability, maintainability, and deployment flexibility.\n📚 References # VxWorks 7 BSP and Driver Development Guide VxBus Driver Framework Documentation Wind River Device Tree Integration Documentation PCI Express Base Specification Renesas R-Car H3 Technical Documentation ","date":"2019-05-24","externalUrl":null,"permalink":"/bsp/using-vxworks-7-vxbus-device-specific-parameters/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eUsing VxWorks 7 VxBus Device-Specific Parameters\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eEmbedded driver development frequently involves balancing flexibility, portability, and boot-time efficiency across multiple hardware configurations. Hard-coded driver parameters may work well during initial bring-up, but they often become problematic as systems evolve and new peripherals are introduced.\u003c/p\u003e","title":"Using VxWorks 7 VxBus Device-Specific Parameters","type":"bsp"},{"content":"","date":"2019-04-01","externalUrl":null,"permalink":"/tags/opencv/","section":"Tags","summary":"","title":"OpenCV","type":"tags"},{"content":"1. Introduction: Empowering Intelligent Systems with Computer Vision on VxWorks\nThe convergence of machine learning and artificial intelligence (AI) is reshaping industries, driving innovation and automation. At the heart of this transformation lies machine learning, a pivotal subset of AI that enables applications to learn from data and refine their performance without explicit, rule-based programming. A significant modality for data acquisition in intelligent systems is through visual input, where images provide a wealth of information about the environment. Computer vision, a field dedicated to replicating human visual capabilities in machines, plays a crucial role in interpreting and understanding this visual data using advanced computer software and hardware.\nOpenCV (Open Source Computer Vision Library) stands as a cornerstone in the domains of computer vision and machine learning. This versatile, cross-platform library, initially developed by Intel, offers a comprehensive suite of algorithms and tools specifically designed for tasks such as object detection, recognition, and image processing. Its capabilities underpin a wide array of applications, including sophisticated robotics, medical imaging analysis, advanced security systems, automated industrial processes, and autonomous vehicles.\nA significant advancement in embedded systems is the integration of OpenCV within the latest releases of VxWorks 7 (SR0540 onwards). VxWorks, a real-time operating system renowned for its reliability and deterministic behavior, brings a critical dimension of safety and robustness to computer vision applications. This synergy is particularly advantageous in safety-critical industries where dependable and predictable performance is paramount.\nThis article will explore the practical implementation of edge detection, a fundamental image processing technique available within the OpenCV library, within the VxWorks environment. We will provide a detailed, step-by-step guide on how to build and execute an OpenCV-based edge detection application on VxWorks, highlighting the key technical considerations and procedures involved.\n2. Prerequisites: Setting the Stage for OpenCV on VxWorks\nTo follow the steps outlined in this article, you will require the following:\nVxWorks Development Environment (SR540+): A properly installed and configured VxWorks 7 development environment with a software license that supports the necessary components. The SR540 release or later is crucial for native OpenCV support. USB Drive with GRUB Configuration: A USB flash drive configured with the GRand Unified Bootloader (GRUB) to facilitate booting the VxWorks image on the target hardware. This allows for flexible deployment and testing. x86-64 Target PC with Camera: A 64-bit x86 personal computer (the target system) equipped with either an integrated or an external USB camera that is compatible with the UVC (USB Video Class) standard. Network Connectivity (Optional but Recommended): Network access for the target PC can be beneficial for tasks such as transferring files and establishing a Telnet connection for remote interaction. 3. Building the VxWorks Image with OpenCV Support\nThe first critical step involves building a custom VxWorks Source Build (VSB) that incorporates the necessary OpenCV libraries and drivers.\n3.1. VSB Configuration:\nBegin by creating a new VSB project using the Workbench development environment. For this example, we utilized the itl_generic_2_0_0_0 Board Support Package (BSP), configured for a CORE CPU architecture and 64-bit address mode to leverage the processing power of modern x86-64 systems.\nDuring the kernel configuration phase of the VSB, it is essential to include the following components:\nUSB: Enables support for USB devices, including the camera. This typically involves selecting the INCLUDE_USB component and its associated sub-components for host controller and device class support. FBDEV: The Framebuffer Device interface provides an abstraction for graphics hardware, allowing OpenCV to display images on a connected monitor if desired (though not strictly necessary for edge detection processing itself). Include INCLUDE_FBDEV. GPUDEV_ITL915: This component specifically enables support for Intel 915 graphics chipset, which is commonly found in many x86 systems. If your target system has a different GPU, you might need to select the corresponding GPUDEV component. OPENCV: This is the core component that integrates the OpenCV library into your VxWorks image. Selecting this will include the necessary OpenCV modules and dependencies. Once the VSB build process is complete, navigate to the following directory within your VxWorks installation to find the README file containing specific instructions for building the VxWorks Image Project (VIP) and the Real-Time Process (RTP) file that will contain our edge detection application:\n\u0026lt;VSB_file_path\u0026gt;/3pp/OPENCV/opencv-3.3.1/vxworks_examples/ Note: The exact path might vary slightly depending on your VxWorks installation directory and the specific OpenCV version included.\nFollow the instructions in the README file to build the VIP, which creates the bootable VxWorks image, and the RTP, which will contain the compiled edge detection application. This process typically involves compiling the example code provided by Wind River for OpenCV on VxWorks.\n4. Loading and Executing the VxWorks Image\nWith the VxWorks image built, the next step is to load and boot it on the target x86-64 PC.\n4.1. Booting from USB:\nEnsure that your target Dell laptop (or your chosen target hardware) is configured to boot from USB. Connect the USB drive containing the generated VxWorks image and power on the system. The GRUB bootloader on the USB drive should present you with options to boot the VxWorks image. Select the appropriate option to start the VxWorks kernel.\n4.2. Telnet Execution of the RTP:\nOnce VxWorks has successfully booted, you can interact with the target system via a Telnet connection.\nEstablish Telnet Connection: Open a terminal or a Telnet client (like PuTTY on Windows) on your host PC and connect to the IP address of your target VxWorks system. Ensure that the network configuration on both the host and target allows for Telnet communication.\nVerify Device Drivers: After establishing the Telnet connection, you can use the devs command in the VxWorks shell to list the available devices. This helps confirm that the necessary drivers, such as the USB video capture driver (/uvc/0), are loaded correctly. The output you provided shows a typical listing of devices:\n-\u0026gt; devs drv name 0 /null 1 /tyCo/0 2 /pcConsole/0 8 /romfs 9 /input/event 11 host: 4 /bd0:1 12 /uvc/0 6 stdio_pty_0xffff8000006d97a0.S 7 stdio_pty_0xffff8000006d97a0.M value = 35 = 0x23 = \u0026#39;#\u0026#39; The presence of /uvc/0 indicates that the USB Video Class driver has been successfully initialized and is ready to interact with your USB camera. The /romfs entry indicates the RAM-based file system where the RTP executable is likely located.\nExecuting the Edge Detection RTP: To run the edge detection application, which is compiled as a Real-Time Process (RTP), use the rtpSp command followed by the path to the executable file within the ROM file system: -\u0026gt; rtpSp \u0026#34;/romfs/RTP_opencv_edge_detect.vxe\u0026#34; This command will load and execute the RTP_opencv_edge_detect.vxe file. Assuming the application is correctly implemented, it will then access the camera feed via the /uvc/0 device, perform edge detection using OpenCV functions, and potentially display the processed output (if framebuffer support is configured) or send the results elsewhere.\n5. Edge Detection Code (Conceptual Overview)\nWhile the specific C++ code for the edge detection application would be extensive, here\u0026rsquo;s a conceptual overview of the key steps involved within the RTP_opencv_edge_detect.vxe application:\nInclude OpenCV Headers: The code will begin by including the necessary OpenCV header files, such as those for image processing (opencv2/imgproc.hpp) and video capture (opencv2/videoio.hpp).\nOpen Camera Device: It will use OpenCV\u0026rsquo;s cv::VideoCapture class to open and access the camera feed. This typically involves specifying the device index (e.g., cv::VideoCapture(0) for the first camera detected, which often corresponds to /uvc/0 in VxWorks).\nCapture Frames: The application will then enter a loop to continuously capture frames from the camera using the videoCapture.read(frame) method. Each frame will be a cv::Mat object, OpenCV\u0026rsquo;s fundamental data structure for representing images.\nConvert to Grayscale (Optional but Common): Edge detection algorithms often work best on grayscale images. The cv::cvtColor() function can be used to convert the color frame to a grayscale image (cv::COLOR_BGR2GRAY).\nApply Edge Detection Algorithm: OpenCV provides several edge detection algorithms, such as the Canny edge detector (cv::Canny()). This function takes the input image (grayscale or color), threshold values, and potentially an aperture size for the Sobel operator (used internally by Canny).\ncv::Mat edges; cv::Canny(grayFrame, edges, lowThreshold, highThreshold, apertureSize); Display or Process Results: The resulting edges cv::Mat will contain the detected edges in the image. This output can then be displayed on a connected screen (if FBDEV is configured and the application includes display logic using OpenCV\u0026rsquo;s cv::imshow()), further processed for object recognition or other tasks, or transmitted over a network.\nRelease Resources: When the application terminates, it\u0026rsquo;s crucial to release the camera resource using videoCapture.release() and destroy any OpenCV windows that were created using cv::destroyAllWindows().\nBelow is the whole code for reference!\n#include \u0026#34;opencv2/core/utility.hpp\u0026#34; #include \u0026#34;opencv2/imgproc.hpp\u0026#34; #include \u0026#34;opencv2/imgcodecs.hpp\u0026#34; #include \u0026lt;stdio.h\u0026gt; #include \u0026lt;opencv2/videoio.hpp\u0026gt; #include \u0026#34;fboutput/cvVxDisplay.hpp\u0026#34; using namespace cv; using namespace std; Mat blurImage, edge1, edge2, cEdge; int edgeThresh = 50; int edgeThreshScharr = 50; Mat GrayFrame; static void help() { printf(\u0026#34;\\nThis sample demonstrates Canny edge detection\\n\u0026#34; \u0026#34;Call:\\n\u0026#34; \u0026#34; /.edge [image_name -- Default is ../data/fruits.jpg]\\n\\n\u0026#34;); } int main( int argc, const char** argv ) { cv::CommandLineParser parser(argc, argv, \u0026#34;{@input||}{help h||}\u0026#34;); string input = parser.get\u0026lt;string\u0026gt;(\u0026#34;@input\u0026#34;); if (parser.has(\u0026#34;help\u0026#34;)) { help(); return 0; } cvVxInitDisplay(); if (argv[1] != NULL ) { edgeThreshScharr = stoi (argv[1]); if (edgeThreshScharr == 0) { edgeThreshScharr = 50; } } VideoCapture VideoStream(0); VideoWriter out_vid; Mat ReferenceFrame; Mat frame1; if (!VideoStream.isOpened()) { printf(\u0026#34;Error: Cannot open video stream from camera\\n\u0026#34;); return 1; } VideoStream.set(CAP_PROP_FRAME_WIDTH, 640); VideoStream.set(CAP_PROP_FRAME_HEIGHT, 480); VideoStream.set(CAP_PROP_FPS, 30); out_vid.open(\u0026#34;edge.avi\u0026#34;, VideoWriter::fourcc(\u0026#39;M\u0026#39;,\u0026#39;J\u0026#39;,\u0026#39;P\u0026#39;,\u0026#39;G\u0026#39;), 10, Size(VideoStream.get(CAP_PROP_FRAME_WIDTH),VideoStream.get(CAP_PROP_FRAME_HEIGHT)),true); do { VideoStream \u0026gt;\u0026gt; frame1; cvtColor(frame1, ReferenceFrame, COLOR_YUV2BGR_YUY2); cEdge.create(ReferenceFrame.size(), ReferenceFrame.type()); cvtColor(ReferenceFrame, GrayFrame, COLOR_RGB2GRAY); /*convert Image to * Grayscale */ blur(GrayFrame, blurImage, Size(3,3)); #if 0 /* This code would output a low quality edge detection*/ /* Run edge detector on grayscale */ Canny(blurImage, edge1, edgeThresh, edgeThresh*3, 3); cEdge = Scalar::all(0); /* Fill cEdge with Zeros, all black */ ReferenceFrame.copyTo(cEdge, edge1); #endif Mat dx,dy; Scharr(blurImage,dx,CV_16S,1,0); Scharr(blurImage,dy,CV_16S,0,1); Canny( dx,dy, edge2, edgeThreshScharr, edgeThreshScharr*3 ); cEdge = Scalar::all(0); /* Fill cEdge with Zeros, all black */ ReferenceFrame.copyTo(cEdge, edge2); Mat rgb; cvtColor(cEdge, rgb, COLOR_BGR2BGRA); cvVxShow(rgb); if (out_vid.isOpened()) out_vid.write(cEdge); } while (1); return 0; } ","date":"2019-04-01","externalUrl":null,"permalink":"/app/opencv-and-vxworks-7-intergration/","section":"Apps","summary":"\u003cp\u003e\u003cb\u003e1. Introduction: Empowering Intelligent Systems with Computer Vision on VxWorks\u003c/b\u003e\u003c/p\u003e\n\u003cp\u003eThe convergence of machine learning and \u003ca href=\"https://www.kontronn.com/ai/\" target=\"_blank\"\u003eartificial intelligence (AI)\u003c/a\u003e is reshaping industries, driving innovation and automation. At the heart of this transformation lies machine learning, a pivotal subset of AI that enables applications to learn from data and refine their performance without explicit, rule-based programming. A significant modality for data acquisition in intelligent systems is through visual input, where images provide a wealth of information about the environment. Computer vision, a field dedicated to replicating human visual capabilities in machines, plays a crucial role in interpreting and understanding this visual data using advanced computer software and hardware.\u003c/p\u003e","title":"OpenCV and VxWorks 7 Intergration","type":"app"},{"content":"Powering billions of intelligent products, Wind River VxWorks has long been a trusted real-time operating system (RTOS) for deploying embedded products and systems. With wide processor support, broad connectivity, and proven real-time performance and reliability, we are excited that VxWorks is a supported platform for bringing world-class Storyboard applications to market.\nAt Embedded World 2018, we showcased an innovative programmable full-color dashboard display, built by Bosch Motorsport and running on VxWorks. The DDU 10 user interface was developed using Storyboard Suite and has configurable pages for customizing motorsport applications. Check out the video from Embedded World to see it in action.\nWritten by Jennie\nJennie used to dabble in code, but a love for sentences and the oxford comma lured her to pursue a career in writing and storytelling. Although she works primarily as a writer, she also volunteers as a mentor for organizations that teach girls and women the basics of web design, development, and WordPress. She loves cats. ","date":"2018-06-08","externalUrl":null,"permalink":"/news/creating-innovative-user-experiences-for-vxworks-platforms/","section":"News","summary":"\u003cp\u003ePowering billions of intelligent products, Wind River \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks\u003c/a\u003e has long been a trusted real-time operating system (RTOS) for deploying embedded products and systems. With wide processor support, broad connectivity, and proven real-time performance and reliability, we are excited that VxWorks is a supported platform for bringing world-class Storyboard applications to market.\u003c/p\u003e","title":"Creating Innovative User Experiences for VxWorks Platforms","type":"news"},{"content":"Wind River, recently released from Intel, has announced the availability of VxWorks 653 Multi-core Edition on the ARM architecture. The platform offers the highest levels of dependability and security for the most demanding environments. Customers can now quickly adapt to changing business needs and meet the growing need for innovation and consolidation of application workloads – starting with the architecture on which their dependability system is based.\nWhether building a new aircraft or designing new features for industrial or medical control systems, choosing the right software and hardware architectures is critical to success. The aerospace and defense industry and the embedded world are increasingly opting for state-of-the-art hardware to solve complex performance challenges across a variety of application workloads. As a result, avionics manufacturers are increasingly looking to use a mix of COTS hardware platforms and open, industry-standard virtualization platforms to leverage a multitude of product lines, aircraft, and scenarios.\nWith this latest release of VxWorks 653, Wind River is enabling enterprises to access its portfolio of safe and secure platforms across all major hardware architectures. With VxWorks 653’s support for Intel architecture announced earlier this year and the new compatibility introduced today, manufacturers can realize cost savings and reduce time to market (TTM) by consolidating new and legacy applications onto the hardware platform of their choice, while providing a safe and secure software foundation that is open, offers high levels of technology maturity and reuse, and reduces certification risks and costs throughout the product lifecycle.\nEnterprises can now build next-generation avionics and industrial systems on an open, industry-standard virtualization platform that can run a variety of operating environments on ARM, Intel and Power processor architectures. VxWorks 653 is a pre-certified platform that can abstract and run any task, including “legacy” applications, with varying levels of dependability.\nVxWorks 653 has been tested and validated on the ARM Cortex A53 processor ARM Cortex A53 (Xilinx UltraScale + MPSoC). The ARM ecosystem is found in edge computing and high-performance computing, where this technology can enable critical applications to achieve desired performance levels within embedded constraints (limiting size, weight, and power) in a cost-effective manner. The Cortex-A53 is one of the most widely used 64-bit ARM cores and is an ideal choice in terms of maturity for defense and aerospace OEMs and developers of rugged embedded applications.\nThe multi-core VxWorks 653 for Arm architecture provides 64-bit support for both the virtualization layer and guest operating systems such as VxWorks 7 and Linux. As microprocessor technologies evolve, Wind River will continue to integrate the best hardware support options into its products and introduce dependability, security and reliability solutions to help create cost-effective, pre-certified, mission-critical applications.\nThe vendor intends to commit to multi-year customer commitments to ensure that its portfolio of safe and secure software can cover a wide variety of aircraft computers, industrial control systems and architectures. Robust and open multi-core consolidation platforms are already in place. Avionics suppliers and equipment manufacturers can now choose the hardware architecture and open virtualization platform that best meets their needs.\n","date":"2018-05-29","externalUrl":null,"permalink":"/news/introducing-vxworks-653-on-arm-architecture/","section":"News","summary":"\u003cp\u003e\u003ccode\u003eWind River\u003c/code\u003e, recently released from Intel, has announced the availability of \u003ccode\u003eVxWorks 653\u003c/code\u003e Multi-core Edition on the \u003ccode\u003eARM architecture\u003c/code\u003e. The platform offers the highest levels of dependability and security for the most demanding environments. Customers can now quickly adapt to changing business needs and meet the growing need for innovation and consolidation of application workloads – starting with the architecture on which their dependability system is based.\u003c/p\u003e","title":"Introducing VxWorks 653 on Arm Architecture","type":"news"},{"content":"","date":"2018-03-02","externalUrl":null,"permalink":"/tags/pc-pentium/","section":"Tags","summary":"","title":"PC Pentium","type":"tags"},{"content":"","date":"2018-03-02","externalUrl":null,"permalink":"/tags/ugldemo/","section":"Tags","summary":"","title":"Ugldemo","type":"tags"},{"content":" VxWorks WindML 安装与配置教程\n1. WindML 的安装 # 2. WindML 的配置 # 2.1 修改 config.h # 打开文件：\nD:\\Tornado2.2\\target\\config\\pcPentium\\config.h 查找 #include \u0026quot;pc.h\u0026quot;，在这之后添加以下宏定义：\n#define INCLUDE_WINDML #define INCLUDE_WINDML_PS2_POINTER #define INCLUDE_WINDML_PS2_KEYBOARD 然后重新建立 bootrom。\n2.2 配置 WindML # 重新打开 Tornado，加载 WindML 控件。\n路径：Tools → WindML → WindML Configuration\n选择配置：Pentium_VGA_INDEXED4_640×480\n点击 Configure。\n注意：Keyboard Name 填写：\n/pcConsole/0 配置好以上三项后，关闭对话框。在 Build 之前建议先执行 Clean。\nBuild 过程大约需要 10 分钟左右。\n2.3 调试 # 创建一个可下载工程（Downloadable Project）。 添加以下组件： PS2 keyboard WindML graphics support (PCI device) complete 2D library 重新制作 VxWorks 镜像，并拷贝到指定位置（如 D:\\）。 重新制作 bootrom。 启动 Tornado FTP Server，启动 VMware 并 Start。 在 Tornado 中开启 Target Server，点击下载按钮，下载以下文件： D:\\Tornado2.2\\target\\lib\\objPENTIUMgnuApps\\ugldemo.o 下载成功后，运行 Launch Shell，并执行相应任务。 观察虚拟机中的 VxWorks 是否出现 Welcome to WindML 3.0 界面。 ","date":"2018-03-02","externalUrl":null,"permalink":"/windml/52-configuration-and-execution-of-windml-3-0-in-vxworks-5-5/","section":"Windmls","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks WindML 安装与配置教程\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e1. WindML 的安装 \n    \u003cdiv id=\"1-windml-%E7%9A%84%E5%AE%89%E8%A3%85\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#1-windml-%E7%9A%84%E5%AE%89%E8%A3%85\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003e\n  \u003cfigure\u003e\n    \u003cimg class=\"my-0 rounded-md\" loading=\"lazy\" src=\"https://assets.gaitpu.com/images/windml/windml_install.jpg\" alt=\"VxWorks WindML install\" /\u003e\n    \n  \u003c/figure\u003e\n\u003c/p\u003e","title":"VxWorks WindML 安装与配置教程","type":"windml"},{"content":"","date":"2018-03-02","externalUrl":null,"permalink":"/tags/%E5%9B%BE%E5%BD%A2%E9%85%8D%E7%BD%AE/","section":"Tags","summary":"","title":"图形配置","type":"tags"},{"content":"","date":"2018-02-26","externalUrl":null,"permalink":"/tags/ddk/","section":"Tags","summary":"","title":"DDK","type":"tags"},{"content":" VxWorks WindML 完整指南：结构、配置与命令行定制\n1 介绍 # WindML（Wind Media Library，媒体库）支持多媒体程序运行于嵌入式操作系统。风河公司设计它主要是用来提供基本的图形、视频和音频技术，并提供一个设计标准设备驱动程序的框架。\nWindML API 库提供了一个统一的图形硬件接口，以及处理输入设备和输入设备事件的能力。WindML 有以下几个设计目的：\n简单：提供一个灵活的图形原语集、基本的视频和音频功能； 硬件便宜：可以在多种 CPU 体系结构上使用； 操作系统便宜：可以在多种 RTOS 系统上使用； 驱动程序开发容易：提供给开发者一个定制设备驱动程序的机制。 2 WindML 结构 # WindML 包括两个组件——软件开发包（SDK） 和 驱动程序开发包（DDK）。\nSDK 组件用来开发应用程序，它提供了一个全面的 API 集，包括图形、输入处理、多媒体、字体和内存管理。 DDK 组件用来实现驱动程序，它提供了一个完整的驱动程序参考集，包括硬件配置和 API 集，使开发者能够迅速引导和使用自己的驱动程序。 WindML 的结构可概括为如图 1-1 所示：\n图 1-1 WindML 结构\n2.1 SDK # 这一层定义了应用程序代码和硬件驱动程序的接口，因此应用程序可以独立于硬件进行开发。\nSDK 提供了下列 API 集：\n图形芯片的初始化程序 多媒体 API，包括： 2D 图形 区域管理 窗口 颜色管理 视频支持 JPEG 支持 音频 事件服务 内存管理 扩展 API 设备管理 2.2 DDK # DDK 是处于 SDK 和硬件之间的中间层，它直接与应用程序目标硬件设备接口，包括监视器、视频、音频、键盘和指示设备等。\n对于大多数 SDK API 都有相关的驱动程序级结构和 API。例如，SDK 原语 uglRectangle() 用来绘制矩形到显示设备，它访问一个包含 rectangle 域的驱动程序结构，该域就是执行绘制矩形操作的函数指针。\nWindML 中定义了下列驱动程序种类：\ngraphics（图形）\n包含分配颜色的函数指针和变量、执行 drawing 操作、内存分配和覆盖页管理。如 VGA、BIOS、MediaGx 和 IGS 图形驱动程序。\nvideo（视频）\n作为扩展功能，用来实现图形驱动（在驱动程序结构的扩展部分分配空间）。实现视频启动、停止和流操作等功能，例如 IGS 视频扩展。\nfonts（字体）\n包含字体大小和绘制操作的函数指针和变量，使用图形驱动程序来显示信息。如 BMF 和 AGFA 字体引擎。\ninput（输入设备）\n包含获得和格式化输入信息的函数指针和变量。如键盘、指示和触摸屏驱动程序。\naudio（音频）\n音频并不是一个真正的设备驱动程序，但可以通过调用 open()、close() 和 ioctl() 来实现。\n下面几章将详细介绍这些驱动程序的创建和操作。\n第二章 WindML 配置 # 2.1 介绍 # 在第一次使用前，必须首先配置和编译好 WindML 库。WindML 配置包括：\n输出驱动程序的选择和硬件设置； 输入驱动程序的选择和硬件设置（指示、键盘或触摸屏）； 音频驱动程序的选择和硬件设置； 应用程序使用的字体。 除了这些配置需求外，WindML 还可以定制成支持特殊的应用环境，可定制部分包括内存管理和定制硬件。配置好后，WindML 库必须编译并连接到应用程序或连接到 VxWorks Image。\n有两种方法来配置 WindML：\n使用 WindML 配置工具（Tornado → Tools → WindML 菜单选项），这是配置 WindML 和相关驱动程序的主要方法。 通过直接编辑配置头和源文件（命令行方法），实现配置工具无法完成的定制。 根据目标程序所需要的 WindML 内容来决定使用的配置方法。WindML 标准配置包含一个图形设备、一个键盘设备和一个指示设备。配置工具允许配置这个标准设备集；如果要使用多个设备，需要直接修改配置文件。\n一旦 WindML 配置好，就可以使用 Tornado 工程将 WindML 添加到 VxWorks Image。\n2.1.1 配置方法比较 # 表 2-1 总结了这两种配置方法。对第一次安装和配置，推荐使用配置工具。\n表 2-1 配置方法比较\n2.2 基本配置 # 基本配置意味着使用标准的 WindML 配置。标准配置使用 WindML 提供的支持驱动程序，包括：\n一个单一的图形设备 一个指示设备 一个键盘设备 一个音频设备 一个支持的字体引擎 缺省的内存管理器 如果要使用不被支持的硬件或不同于下列所列的配置，就必须做非标准配置。\n如果使用配置工具定义 WindML 配置，配置工具在 build 过程中产生的文件用于编译和连接 WindML。如果不使用配置工具，必须编辑文件 target/src/ugl/config/uglInit.h。\n2.2.1 配置图形设备 # 要配置一个图形设备，必须设置下列基本配置选项：\n图形设备类型（如 MediaGx） 显示分辨率 帧缓冲颜色深度（如 4、8 或 16 位） 显示器的刷新率 输出设备类型（CRT 或平板显示器） 可裁剪的图形驱动功能（取决于硬件设备）：\nsoftware cursors overlay surfaces video JPEG alpha blending double buffers 这些功能都是可裁剪的。\n2.2.2 配置键盘设备 # 要配置键盘设备，设置下列配置选项：\n键盘设备类型 设备名 缺省的设备名是 /keyboard/0。\n2.2.3 配置指示设备 # 要配置指示设备，设置下列选项：\n指示设备类型 设备名 缺省的指示设备名取决于设备类型：\nPS2：/mouse/0 串口设备指示器：/tyCo/0 触摸屏设备：/touchscreen/0 2.2.4 配置字体 # 必须配置字体引擎来显示文本。WindML 提供的字体引擎是 bitmap（位图）字体引擎，其他可用的字体引擎来自第三方。通常需要：\n选择要使用的字体 选择字体引擎类型配置选项 如果从命令行配置，必须修改字体引擎文件（位于 target/src/ugl/config 目录）来定义要包含的字体和字体引擎特性。文件名格式为 uglFontengineCfg.c（Fontengine 指字体引擎名）。例如，对于位图字体引擎，文件名为 uglBmfCfg.c。\n2.2.5 配置音频 # 要配置音频，定义下列选项：\n音频设备类型 音频通道 2.2.6 混杂配置项 # 下列配置项目可以配置给 WindML：\nEvent Queue Size（事件队列大小）\n确定 WindML 应用程序中事件数，缺省大小是 100 个事件。\nMemory Manager（内存管理器）\nWindML 可以使用专有内存池，也可以使用 VxWorks 系统内存池。当指定使用专有内存池时，所有内存分配都来自专有内存池；当指定使用 VxWorks 系统内存池时，所有内存分配都来自系统内存池。\nSpecial Processor Requirements（特殊处理器需要）\n有的处理器类型有特殊需要。例如 PowerPC 有两个内存模型：PowerPC Reference Platform (PreP) 和 Common Hardware Reference Platform (CHRP)。配置 PowerPC 时必须定义正确的内存模型。\n2.3 使用配置工具 # 在 Windows 操作系统中，从 Tornado 菜单中选择 Tornado → Tools → WindML，初始配置窗口如图 2-1 所示。\n图 2-1 Configurator on a Windows Host\n2.3.1 定义一个新的配置 # 在 Configuration File 域中输入一个配置名。 在处理器列表中选择一个处理器类型。选择后，配置域会出现只适用于该处理器的选项。 选择 Graphics 配置页并设置： graphics device output device type color depth resolution refresh rate optional components 选择 Input 配置页并设置： Pointer 设备类型和设备名 Keyboard 设备类型和设备名 从所安装的字体引擎集中选择要使用的字体引擎。\n对于 UGL Bitmap font engine，选择： 是否使用 Unicode 字体 字体 cache 的大小 应用程序要使用的字体 在 Audio 配置页选择： 音频硬件类型 音频设备名 使用硬件上的通道号 在 Miscellaneous 配置页选择： Build 选项（如 building with debug symbols 和要建立的库） 是否使用专用 WindML 内存池（如果使用，设置内存池大小） 配置完成后，按 Save 按钮存储这个配置。\n2.3.2 建立 WindML 库 # 建立 WindML 前，选择 Miscellaneous 页并选择下列选项之一：\nBuild VxWorks archive\n使 objCpuToolvx 目录中的 WindML 对象重新建立并加入到 libCpuToolvx.a 文档中，该文档用来建立 VxWorks Image。\nBuild WindML archive\n使 objCpuToolUgl 目录中的 WindML 对象重新建立并加入到 libCpuToolUgl.a 文档中，这是一个只包含 WindML 对象的独立文档。\nBuild WindML object\n使 objCpuToolUgl 目录中的 WindML 对象建立。所有在配置工具中配置的 SDK 对象、设备驱动程序和字体引擎都会被建立在可下载的目标程序 lib/CpuTool.o 中。\nBuild Example Programs\n执行与 Build WindML archive 同样的操作。\n选择好 build 选项后，点击 Build 按钮即可建立 WindML 库。\n2.3.3 清除 WindML 目标文件 # 点击 Clean 按钮可清除所选择的目标。例如：\n如果选择 Build Example Programs，objCpuToolUgl 中的目标会随着 libCpuToolUgl.a 一起被清除。 如果选择 Build VxWorks archive，所有来自 objCpuToolvx 目录的 WindML 目标会被清除，但 libCpuToolvx.a 文件中的 WindML 目标不会被清除。 2.4 命令行配置 # 一般来说，不推荐使用命令行配置。如果要使用不止一个图形设备、指示设备或键盘，则需要修改源文件，利用命令行进行 WindML 配置。\n至少需要修改 uglInit.h 和所选择的字体引擎相关字体配置文件。在有些情况下也需要修改 uglInit.c 文件。这两个文件都位于 target/src/ugl/config 目录下。\nuglInit.h：指定 WindML 的基本配置。 uglInit.c：控制 WindML 库的初始化，包含函数 uglInitialize() 和 uglDeinitialize()。提供了处理标准 WindML 系统的函数（一个图形设备、一个键盘、一个指示器、一个字体引擎和一个音频设备）。通常修改此文件的唯一原因是处理多个设备。 2.4.1 编辑 uglInit.h 文件 # uglInit.h 文件允许选择配置包括图形、键盘、指示器和音频、字体引擎、内存管理器以及 miscellaneous 目标/处理器项目。文件被分成以下几个部分：\n设备驱动程序选择 字体引擎选择 输入设备配置 图形设备配置 音频设备配置 字体引擎配置 内存管理器配置 Miscellaneous target/processor 配置 选择设备驱动程序\n文件第一部分是选择要使用的设备驱动程序。每个支持的设备驱动程序通过 INCLUDE_* 来标记。要选择指定的设备驱动程序，定义（#define）相关 INCLUDE_*，而将相关子部分其他的 INCLUDE_* 设为 undefined。\n示例：\n/* Specify the graphics device to use (Select 1) */ #undef INCLUDE_BIOS_GRAPHICS #undef INCLUDE_CHIPS_GRAPHICS #undef INCLUDE_CUSTOM_GRAPHICS /* User defined graphics device */ #undef INCLUDE_IGS_GRAPHICS #undef INCLUDE_MEDIAGX_GRAPHICS #undef INCLUDE_SA11XX_GRAPHICS #undef INCLUDE_SIMULATOR_GRAPHICS #undef INCLUDE_Q2SD_GRAPHICS #undef INCLUDE_M821_GRAPHICS #define INCLUDE_VGA_GRAPHICS /* Specify the keyboard type (Select 1) */ #define INCLUDE_PC_AT_KEYBOARD /* Standard PC AT style */ #undef INCLUDE_CUSTOM_KEYBOARD /* User defined keyboard device */ #undef INCLUDE_SIMULATOR_KEYBOARD /* Simulator keyboard device */ /* Specify the type of pointer device (Select 1) */ #undef INCLUDE_ASSABET_POINTER /* Assabet touchscreen */ #undef INCLUDE_CUSTOM_POINTER /* User defined pointer device */ #undef INCLUDE_MS_POINTER /* Microsoft serial mouse */ #define INCLUDE_PS2_POINTER /* PS-2 type mouse */ #undef INCLUDE_SIMULATOR_POINTER /* Simulator pointer device */ /* Specify the audio hardware device (Select 1) */ #undef INCLUDE_IGS_AUDIO #undef INCLUDE_CUSTOM_AUDIO /* User defined audio device */ 在此示例中，配置包括 VGA 图形设备、标准 PC AT 型键盘、PS-2 鼠标和无音频设备。\n选择字体引擎\n/* Specify the font engine (Select 1) */ #define INCLUDE_BMF_FONTS 此示例使用位图字体引擎。\n配置输入设备\nWindML 支持两种输入设备类型：键盘和指示器设备（鼠标、跟踪球、触摸屏、光笔等）。\n缺省设备名可通过添加相关宏来改变。例如，要改变串口鼠标名为 /tyCo/1，在 uglInit.h 中添加下列行（放在 #include \u0026lt;ugl/config/uglDepend.h\u0026gt; 前面）：\n#define SYS_POINTER_NAME \u0026#34;/tyCo/1\u0026#34; #include \u0026lt;ugl/config/uglDepend.h\u0026gt; 可定义键盘映射类型：\n/* Specify the keyboard key mapping (Select 1) */ #define INCLUDE_KMAP_ENGLISH_US #undef INCLUDE_KMAP_ENGLISH_UK #undef INCLUDE_KMAP_GERMAN #undef INCLUDE_KMAP_ITALIAN #undef INCLUDE_KMAP_FRENCH #undef INCLUDE_KMAP_SWEDISH #undef INCLUDE_KMAP_NONE 配置图形设备\n图形配置包括分辨率、刷新率、帧缓冲格式和可选图形设备组件。\n示例：\n/* * Specify characteristics of the display */ #define UGL_DISPLAY_WIDTH 800 #define UGL_DISPLAY_HEIGHT 600 #define UGL_REFRESH_RATE 60 /* * When using a flat panel, select the flat panel type * (Defaults to a CRT monitor) */ #undef INCLUDE_UGL_KYOCERA_KCS057QV1AA /* Passive, 320x240x8 */ #undef INCLUDE_UGL_SHARP_LM9V385 /* Dual panel passive, 640x480x8 */ #undef INCLUDE_UGL_SHARP_LQ039Q2DS01 /* TFT, 320x240x(8 or 16) */ /* * Specify the frame buffer format (Select 1) */ #undef INCLUDE_UGL_MONO #undef INCLUDE_UGL_GREYSCALE2 #undef INCLUDE_UGL_GRAYSCALE4 #undef INCLUDE_UGL_GRAYSCALE8 #undef INCLUDE_UGL_INDEXED4 #define INCLUDE_UGL_INDEXED8 #undef INCLUDE_UGL_ARGB4444 #undef INCLUDE_UGL_RGB565 #undef INCLUDE_UGL_ARGB8888 /* * Select graphics driver optional components */ #undef INCLUDE_UGL_ALPHA /* Alpha blending */ #undef INCLUDE_UGL_DOUBLE_BUFFERING /* Double buffering */ #define INCLUDE_UGL_JPEG /* JPEG extension */ #undef INCLUDE_UGL_OVERLAY /* Video overlay support */ #define INCLUDE_UGL_SW_CURSOR /* Software cursor */ #undef INCLUDE_UGL_VIDEO /* Video extension */ 上述配置表示：\n800×600 分辨率 刷新率 60Hz 使用 CRT 显示器 帧缓冲格式为每像素 8 位 包含 JPEG 扩展 包含软件光标 配置字体引擎\n主要的字体配置机制是 uglFontengineCfg.c 文件。例如，配置位图字体引擎时，需要在 uglInit.h 中添加相关定义：\n/* Size of cache */ #define BMF_FONT_GLYPH_CACHE_SIZE UGL_BMF_GLYPH_CACHE_SIZE_MAX /* Memory pool to use for glyph cache */ #define BMF_FONT_GLYPH_CACHE_MEM_POOL UGL_DEFAULT_MEM_POOL_ID /* Include Unicode fonts */ #define INCLUDE_UGL_BMF_UNICODE 2.4.2 编辑字体配置文件 # 要选择指定的字体，编辑 uglFontengineCfg.c 文件。\n配置位图字体引擎\n位图配置文件 uglBmfCfg.c 包含一个数据结构，用来定义应用程序使用的字体：\nextern const UGL_BMF_FONT_DESC uglBMFFont_Lucida_Sans_12; extern const UGL_BMF_FONT_DESC uglBMFFont_Helvetica_Bold_12; extern const UGL_BMF_FONT_DESC uglBMFFont_Lucida_Sans_8; extern const UGL_BMF_FONT_DESC uglBMFFont_Courier_12; const UGL_BMF_FONT_DESC * uglBMFFontData[] = { \u0026amp;uglBMFFont_Lucida_Sans_12, \u0026amp;uglBMFFont_Helvetica_Bold_12, \u0026amp;uglBMFFont_Lucida_Sans_8, \u0026amp;uglBMFFont_Courier_12, NULL }; 修改 uglBMFFontData 数据结构，使其包含 WindML 应用程序所需的位图字体。同时需要将字体放到该数据结构中，外部引用字体必须添加到外部引用列表。\n例如，要添加间距 18 的 Courier Bold Oblique 字体，添加以下外部引用：\nextern const UGL_BMF_FONT_DESC uglBMFFont_Courier_Bold_Oblique_18; 然后添加到数据结构中：\n\u0026amp;uglBMFFont_Courier_Bold_Oblique_18, 目录 target/src/ugl/fonts/bmf 包含 WindML 发布可用的字体。如果需要其他字体，需要添加到该目录。\n","date":"2018-02-26","externalUrl":null,"permalink":"/windml/41-windml-related-knowledge-and-device-driver-development-in-vxworks/","section":"Windmls","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks WindML 完整指南：结构、配置与命令行定制\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e1 介绍 \n    \u003cdiv id=\"1-%E4%BB%8B%E7%BB%8D\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#1-%E4%BB%8B%E7%BB%8D\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eWindML（Wind Media Library，媒体库）支持多媒体程序运行于嵌入式操作系统。风河公司设计它主要是用来提供基本的图形、视频和音频技术，并提供一个设计标准设备驱动程序的框架。\u003c/p\u003e","title":"VxWorks下WindML相关知识和图形设备驱动程序开发","type":"windml"},{"content":"","date":"2018-02-26","externalUrl":null,"permalink":"/tags/%E9%85%8D%E7%BD%AE%E5%B7%A5%E5%85%B7/","section":"Tags","summary":"","title":"配置工具","type":"tags"},{"content":"","date":"2018-02-26","externalUrl":null,"permalink":"/tags/%E5%9B%BE%E5%BD%A2%E9%A9%B1%E5%8A%A8/","section":"Tags","summary":"","title":"图形驱动","type":"tags"},{"content":"By: Brian Kuhl\nWhen it comes down to debugging semaphore interactions it can be a tricky problem. As when there is a deadlock or weird delay because of excessive priority inheritance, it is never just one mutex semaphore, but often the unintended interaction of several semaphores in multiple tasks.\nSome of the semaphores are part of the VxWorks I/O services, and some are in your application. Your tools tell you what the semaphore ID is, but often that is not enough to identify the semaphore. If it is someone else’s code, and they have created lots of semaphores, you can spend hours trying to identify which bits of code are involved.\nTo add to the complexity, some semaphores only exist for a few microseconds, so examining the ID in a log does not help you understand where it was created. During my tenure as a field engineer I have helped more than one Wind River customer debug tricky issues with semaphores, and I have the missing hair to prove it.\nWouldn’t it be nice if you could identify each semaphore with a unique name? “Yes,” you say, “that would be nice, but I am not going to rewrite all the code to use a different API.”\nWould you be willing to add another header in the existing code?\nIn recent versions of VxWorks, there is the concept of a named semaphore that you create with semOpen() rather than semXCreate(). The primary use of semOpen() is to share a semaphore between memory contexts, so the same semaphore can be used in the kernel and an RTP, or multiple RTPs. The semOpen can also create a private semaphore that has the same scope as a semaphore instantiated with semXCreate(); (just don’t put a backslash at the beginning of the name).\nThe astute reader will have guessed what comes next? Yes, some example code with fancy macros. First the trivial example of the modified code with a new header semCreateWithOpen.h.\nAnd then of course the fancy headers contents:\nThe tools will show you the name if it is present, you do not need to use an alternate API or different configuration. Try out semShow() and see what happens? You should see something like this:\nNow do you know exactly where that semaphore came from?\nYou will need to add the Extended object library (SEM_OBJ_OPEN) support in your kernel, if you have not been configured for RTP support. You will want to add similar functions to the header for counting, and read-writing semaphores if you use them.\nWould your team of experienced VxWorks engineers like a few more debugging hints? The Wind River VxWorks Application Debugging Use Cases is recommended as a suitable way of spending some hands on time upgrading their skills.\n","date":"2017-11-30","externalUrl":null,"permalink":"/app/debugging-vxworks-semaphores/","section":"Apps","summary":"\u003cp\u003e\u003cstrong\u003eBy: Brian Kuhl\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eWhen it comes down to debugging semaphore interactions it can be a tricky problem. As when there is a deadlock or weird delay because of excessive priority inheritance, it is never just one mutex semaphore, but often the unintended interaction of several semaphores in multiple tasks.\u003c/p\u003e","title":"Debugging VxWorks Semaphores","type":"app"},{"content":"","date":"2017-11-30","externalUrl":null,"permalink":"/tags/windriver/","section":"Tags","summary":"","title":"WindRiver","type":"tags"},{"content":" Last Updated: Dec 25, 2016 Applicable Entity: vxworks.net Trademarks \u0026amp; Source Attribution # Wind River, VxWorks, and the Wind River logo are trademarks or registered trademarks of Wind River Systems, Inc. All other product names, company names, logos, and trademarks mentioned on this site are the property of their respective owners. vxworks.net makes no claim of ownership to any third-party trademarks referenced on this website. Any use of third-party trademarks on this site is purely nominative and intended only to identify the respective products or services. Such use does not imply any affiliation with or endorsement by the trademark owners.\nThe resources shared on this website (hereinafter referred to as \u0026ldquo;this Platform\u0026rdquo;)—including but not limited to eBooks, documents, software, audio, and video materials—are sourced from publicly available channels on the internet. The original copyrights belong to their respective authors or publishing institutions.\nThis Platform discovers and reposts such resources solely for the purposes of personal learning, research, and exchange, and does not constitute any commercial use or claim of ownership over the copyrighted works.\nNon-Affiliation # vxworks.net is an independent website. It is not affiliated with, endorsed by, or sponsored by Wind River Systems, Inc. or any of its subsidiaries, nor with any other company whose trademarks may appear on this site.\nPurpose of This Website # All references to third-party products, services, or technologies are made solely for informational and educational purposes. The content provided does not imply any partnership, joint venture, or other official relationship with the owners of the referenced trademarks.\nNo Warranties # All content on vxworks.net is provided on an “as is” basis, without warranties of any kind, either express or implied.\nThe site does not guarantee the accuracy, completeness, or timeliness of any information provided.\nUser Responsibility # You acknowledge that you are using the information and resources on this site at your own risk and are solely responsible for verifying any information before relying on it, especially in professional or commercial projects.\nFormal Disclaimer of Liability # To the fullest extent permitted by law, vxworks.net and its contributors disclaim any liability for damages of any kind arising from the use of, or reliance on, this website or its content.\nAccuracy of Information: This Platform endeavors to ensure the accuracy of the resources provided, but makes no warranties regarding their completeness, correctness, or timeliness. Users must exercise their own judgment and bear all associated risks.\nDownload and Usage: Downloaded resources are intended for personal, non-commercial trial use only. Any form of commercial exploitation, mass redistribution, or secondary dissemination without the explicit written consent of the copyright holder is strictly prohibited.\nThird-Party Links: This Platform may contain links to external third-party websites. We assume no responsibility for the content, privacy policies, or operational practices of such external sites.\nAdvocacy for Genuine Products \u0026amp; Takedown Commitment # Strong Recommendation: We strongly encourage you to support official publications by purchasing genuine printed books or legally authorized digital versions. Genuine resources guarantee the best content integrity and reading experience, and represent the utmost respect for the intellectual labor of creators.\nInfringement Notification: If you are the copyright owner or rights holder of any resource and believe that our sharing infringes upon your legal rights, please send a written notice to us via the contact information published on this Platform. Upon receipt of a valid infringement notification, we will remove the relevant resource link within 24 to 48 hours after verification, in order to protect your legitimate rights and interests.\nNo Legal or Professional Advice # The content on this site is for informational and community purposes only and does not constitute professional, engineering, or legal advice.\nBy using any resources provided by this Platform, users are deemed to have read and agreed to all terms of this Disclaimer. In the event of any legal disputes or losses arising from violation of this Disclaimer or from the use of the resources, the user shall bear sole responsibility, and this Platform shall not be held liable.\nContact Information (for Takedown Requests) # Email: admin@vxworks.net\nIf you have questions or concerns about this disclaimer, please contact the site administrator via admin@vxworks.net.\n","date":"2016-12-25","externalUrl":null,"permalink":"/compliance/legal-disclaimer/","section":"Compliance and Trademark Declaration","summary":"\u003cul\u003e\n\u003cli\u003eLast Updated: Dec 25, 2016\u003c/li\u003e\n\u003cli\u003eApplicable Entity: vxworks.net\u003c/li\u003e\n\u003c/ul\u003e\n\n\n\u003ch2 class=\"relative group\"\u003eTrademarks \u0026amp; Source Attribution \n    \u003cdiv id=\"trademarks--source-attribution\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#trademarks--source-attribution\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eWind River\u003c/strong\u003e, \u003cstrong\u003eVxWorks\u003c/strong\u003e, and the \u003cstrong\u003eWind River logo\u003c/strong\u003e are trademarks or registered trademarks of \u003cstrong\u003eWind River Systems, Inc.\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003eAll other product names, company names, logos, and trademarks mentioned on this site are the property of their respective owners.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003evxworks.net\u003c/strong\u003e makes no claim of ownership to any third-party trademarks referenced on this website.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAny use of third-party trademarks on this site is purely \u003cstrong\u003enominative\u003c/strong\u003e and intended only to identify the respective products or services. Such use does not imply any affiliation with or endorsement by the trademark owners.\u003c/p\u003e","title":"Legal Disclaimer","type":"compliance"},{"content":"","date":"2016-12-25","externalUrl":null,"permalink":"/tags/legal-disclaimer/","section":"Tags","summary":"","title":"Legal Disclaimer","type":"tags"},{"content":"","date":"2016-08-27","externalUrl":null,"permalink":"/tags/qt-4.8.3/","section":"Tags","summary":"","title":"Qt 4.8.3","type":"tags"},{"content":"","date":"2016-08-27","externalUrl":null,"permalink":"/tags/vxsim/","section":"Tags","summary":"","title":"Vxsim","type":"tags"},{"content":" VxWorks 6.8 下安装与配置 Qt 4.8.3 详细指南\n1. 前言 # 本文详细描述了在 VxWorks 6.8 操作系统下安装和设置 Qt 的方法，给出了完整的操作过程，并包含在 vxsim 虚拟机和实际目标板上编译、运行 Qt demo 程序的详细步骤。\n2. 开发环境及工具 # 安装前请准备以下工具：\n序号 名称 备注 1 Qt-vxworks-commercial-src-4.8.3.zip 需从相关渠道获取 2 MinGW 5.1.6 可从官网下载 3 Strawberry Perl 可从官网下载 4 VxWorks 6.8 (Workbench 3.2) 需从相关渠道获取 5 Windows 7 64bit 开发机操作系统 说明：\nStrawberry Perl 下载地址：http://strawberryperl.com MinGW 下载地址：http://sourceforge.net/projects/mingw/files Qt for VxWorks 版本和 VxWorks 6.8 需从相关渠道购买。 3. 开发环境安装配置 # 3.1 安装 Workbench 3.2 # 请参考 VxWorks 6.8 安装手册，按说明书一步一步安装即可，本文不再赘述。\n3.2 安装 MinGW # 解压 MinGW，双击 MinGW-5.1.6.exe，按默认设置安装，建议安装在 C 盘。\n3.3 安装 Strawberry Perl # 双击 strawberry-perl-5.18.1.1-32bit.exe，按默认设置安装，建议安装在 C 盘。\n安装完成后需要设置环境变量，在 Path 中添加：\nC:\\MinGW\\bin;C:\\strawberry\\c\\bin;C:\\strawberry\\perl\\site\\bin;C:\\strawberry\\perl\\bin 3.4 安装 Qt 4.8.3 # 将 Qt-vxworks-commercial-src-4.8.3.zip 解压。 复制到 Wind River Workbench 的 workspace 目录中。 根据使用场景重命名： 在 vxsim 虚拟机上测试：改为 qtsimdkm 在目标机上使用：改为 qtp4dkm 这样做可以避免不同开发环境在交叉编译时引入错误配置。\n设置环境变量 # vxsim 虚拟机开发：在 Path 中添加\nD:\\WindRiver\\workspace\\qtsimdkm\\bin 目标机开发：在 Path 中添加\nD:\\WindRiver\\workspace\\qtp4dkm\\bin 注意：上述两个路径不要同时添加，以免出错。\n4. 在 vxsim 虚拟机上开发 Qt 应用程序 # 4.1 编译 windML 库 # 参考官方手册 Wind River Media Library SDK Programmer\u0026rsquo;s Guide 5.3，按标准步骤配置并编译。注意此时 CPU 选择 SIMPC。\n4.2 新建 VxWorks 镜像 # 以 vxsim 虚拟机为例：\n在 Workbench 3.2 中选择 File → New → VxWorks Image Project。 建立一个名为 zvipsim 的虚拟机镜像工程。 工程建立完成后，双击 Kernel Configuration，添加以下组件包：\nINCLUDE_WINDML INCLUDE_POSIX_ADVISORY_FILE_LOCKING INCLUDE_POSIX_FTRUNC INCLUDE_POSIX_MQ INCLUDE_POSIX_MEM INCLUDE_POSIX_SCHED INCLUDE_POSIX_SEM INCLUDE_POSIX_PTHREADS INCLUDE_POSIX_PTHREAD_SCHEDULER NUM_FILES=200 RTP_FD_NUM_MAX=200 INCLUDE_MMAP # 注：VxWorks 6.8 中无此包 INCLUDE_POSIX_MAPPED_FILES INCLUDE_HRFS INCLUDE_HRFS_FORMAT HRFS_DEFAULT_MAX_BUFFER=1024 HRFS_DEFAULT_MAX_FILES=200 INCLUDE_XBD_RAMDRV INCLUDE_XBD_PART_LIB 然后在 usrAppInit.c 中添加以下代码，用于在系统启动时创建 RAM disk：\n/* for QT */ #include \u0026#34;stdio.h\u0026#34; #include \u0026#34;hrFsLib.h\u0026#34; #include \u0026#34;xbdPartition.h\u0026#34; #include \u0026#34;xbdRamDisk.h\u0026#34; #define DEVNAME \u0026#34;/tmpram\u0026#34; /* name of the RAM disk */ #define BLOCKSIZE 512 #define DISKSIZE (BLOCKSIZE * 10000) /* end of QT */ void usrAppInit (void) { #ifdef USER_APPL_INIT USER_APPL_INIT; /* for backwards compatibility */ #endif /* add application specific code here */ /* for QT ----------------- */ STATUS error; device_t xbd; xbd = xbdRamDiskDevCreate(BLOCKSIZE, DISKSIZE, 0, DEVNAME); if (xbd == NULLDEV) { printf(\u0026#34;**Failed to create RAM disk\\n\u0026#34;); return; } printf(\u0026#34;RAM disk created OK\\n\u0026#34;); error = hrfsFormat(DEVNAME, DISKSIZE, BLOCKSIZE, 1000); if (error != OK) { printf(\u0026#34;**failed to format RAM disk, errno=0x%0x\\n\u0026#34;, error); return; } printf(\u0026#34;RAM create and format OK\\n\u0026#34;); /* end of QT --------------------- */ } 完成以上配置后编译镜像。编译成功后，在 VxWorks 6.8 Development Shell 中进入 zvipsim/default 目录，执行：\nvxsim --size 800M 启动虚拟机。\n4.3 配置 Qt # 在 VxWorks 6.8 Development Shell 中进入 qtsimdkm 目录，执行 configure：\nconfigure -confirm-license -embedded -platform win32-g++ \\ -xplatform qws/vxworks-simdkm-g++ \\ -exceptions -qt-freetype -qt-zlib -qt-libpng -qt-libtiff \\ -qt-libjpeg -qt-libmng -no-qt3support -no-openssl \\ -nomake examples -nomake docs -nomake translations \\ -no-script -no-webkit \\ -prefix /tmp/qtsimdkm -static -release \\ -D QT_QWS_TEMP_DIR=\\\\\\\u0026#34;/tmpram\\\\\\\u0026#34; -make make 说明：加粗或需要修改的部分要根据实际开发环境调整。以上是 vxsim 虚拟机的配置。如果是 x86 目标机，需要改为：\n-xplatform qws/vxworks-Pentium4dkm-g++ -prefix /ata0a/tmp/qtp4dkm configure 执行完成后，会在 qtsimdkm 目录下生成 Makefile。随后进入该目录执行 make 进行编译（大约需要 10～20 分钟）。\n编译成功后，将 workspace\\qtsimdkm\\lib 下的所有内容复制到 C:\\tmp\\qtsimdkm\\lib。如果是目标环境，则复制到目标机硬盘 /ata0a/tmp/qtp4dkm/lib 下。\n4.4 编译并运行 Qt 程序 # 在 VxWorks Development Shell 中进入 qtsimdkm\\demos\\affine 目录，执行 make，编译生成可执行文件 affine。 将编译出的 affine 文件复制到虚拟机镜像所在目录 workspace\\zvipsim\\default。 启动虚拟机： vxsim --size 800M 在 vxsim0 中执行以下命令： ld \u0026lt; affine taskSpawn(\u0026#34;main\u0026#34;, 200, 0x01000000, 0x100000, main, 0, 0, 0, 0, 0) 即可看到 Qt demo 程序运行界面。\n至此，VxWorks vxsim 虚拟机上运行 Qt 成功。\n5. 在目标机上开发 Qt 应用程序 # 5.1 编译 windML 库 # 同样参考 Wind River Media Library SDK Programmer\u0026rsquo;s Guide 5.3 进行配置和编译。根据目标板选择对应的 CPU（本文测试目标板 CPU 为 Intel ATOM，选择 Pentium4）。\n5.2 新建 VxWorks 镜像 # 按照 4.2 节步骤建立 VxWorks Image Project，注意在选择 CPU 和 BSP 时使用目标板实际的 BSP。建好后同样在 usrAppInit.c 中添加创建 RAM disk 的代码，并添加以下组件包：\nINCLUDE_WINDML INCLUDE_POSIX_ADVISORY_FILE_LOCKING INCLUDE_POSIX_FTRUNC INCLUDE_POSIX_MQ INCLUDE_POSIX_MEM INCLUDE_POSIX_SCHED INCLUDE_POSIX_SEM INCLUDE_POSIX_PTHREADS INCLUDE_POSIX_PTHREAD_SCHEDULER NUM_FILES=200 RTP_FD_NUM_MAX=200 INCLUDE_MMAP # 注：VxWorks 6.8 中无此包 INCLUDE_POSIX_MAPPED_FILES INCLUDE_HRFS INCLUDE_HRFS_FORMAT HRFS_DEFAULT_MAX_BUFFER=1024 HRFS_DEFAULT_MAX_FILES=200 INCLUDE_XBD_RAMDRV INCLUDE_XBD_PART_LIB 编译完成后通过网络下载到目标板测试，确认运行正常。\n5.3 配置 Qt # 在 VxWorks 6.8 Development Shell 中进入 qtp4dkm 目录，执行：\nconfigure -confirm-license -embedded -platform win32-g++ \\ -xplatform qws/vxworks-Pentium4dkm-g++ \\ -exceptions -qt-freetype -qt-zlib -qt-libpng -qt-libtiff \\ -qt-libjpeg -qt-libmng -no-qt3support -no-openssl \\ -nomake examples -nomake docs -nomake translations \\ -no-script -no-webkit \\ -prefix /ata0a/tmp/qtp4dkm -static -release \\ -D QT_QWS_TEMP_DIR=\\\\\\\u0026#34;/tmpram\\\\\\\u0026#34; -make make 配置成功后会在 qtp4dkm 目录下生成 Makefile。打开命令行进入该目录执行 make 进行编译（大约 10～20 分钟）。\n编译完成后，将生成的 lib 库文件复制到目标机硬盘 /ata0a/tmp/qtp4dkm/lib 下。\n通过网络启动目标机，在 Workbench 上建立远程连接，将应用程序 D:\\WindRiver\\workspace\\qtp4dkm\\demos\\affine\\affine 下载到目标机。\n下载完成后，在调试机 Shell 或目标机上执行：\ntaskSpawn(\u0026#34;main\u0026#34;, 200, 0x01000000, 0x100000, main, 0, 0, 0, 0, 0) 即可启动 Qt 程序。\n","date":"2016-08-27","externalUrl":null,"permalink":"/windml/10-qt-installation-and-execution-under-vxworks-6-8/","section":"Windmls","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 6.8 下安装与配置 Qt 4.8.3 详细指南\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e1. 前言 \n    \u003cdiv id=\"1-%E5%89%8D%E8%A8%80\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#1-%E5%89%8D%E8%A8%80\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003e本文详细描述了在 VxWorks 6.8 操作系统下安装和设置 Qt 的方法，给出了完整的操作过程，并包含在 vxsim 虚拟机和实际目标板上编译、运行 Qt demo 程序的详细步骤。\u003c/p\u003e","title":"VxWorks 6.8 安装配置 Qt 4.8.3 详细教程","type":"windml"},{"content":"","date":"2016-08-27","externalUrl":null,"permalink":"/tags/%E4%BA%A4%E5%8F%89%E7%BC%96%E8%AF%91/","section":"Tags","summary":"","title":"交叉编译","type":"tags"},{"content":"","date":"2016-08-27","externalUrl":null,"permalink":"/tags/%E5%B5%8C%E5%85%A5%E5%BC%8F%E5%BC%80%E5%8F%91/","section":"Tags","summary":"","title":"嵌入式开发","type":"tags"},{"content":"","date":"2016-08-10","externalUrl":null,"permalink":"/tags/tour-wrap-up/","section":"Tags","summary":"","title":"Tour Wrap Up","type":"tags"},{"content":"","date":"2016-08-10","externalUrl":null,"permalink":"/series/vxworks-introductory-video-tour/","section":"Series","summary":"","title":"VxWorks Introductory Video Tour","type":"series"},{"content":"A conclusion to the VxWorks® real-time operating system (RTOS) 5-part series video tour.\n","date":"2016-08-10","externalUrl":null,"permalink":"/video/vxworks-tour-wrap-up/","section":"Videoes","summary":"\u003cp\u003eA conclusion to the VxWorks® real-time operating system (RTOS) 5-part series video tour.\u003c/p\u003e\n\u003clite-youtube videoid=\"CQ4vOMzXM-I\" playlabel=\"CQ4vOMzXM-I\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"VxWorks Tour Wrap Up","type":"video"},{"content":"Brief introduction to the tools available on the VxWorks® real-time operating system (RTOS).\n","date":"2016-08-10","externalUrl":null,"permalink":"/video/vxworks-workbench-overview/","section":"Videoes","summary":"\u003cp\u003eBrief introduction to the tools available on the VxWorks® real-time operating system (RTOS).\u003c/p\u003e\n\u003clite-youtube videoid=\"LIaLANVvixc\" playlabel=\"LIaLANVvixc\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"VxWorks Workbench Overview","type":"video"},{"content":"","date":"2016-08-10","externalUrl":null,"permalink":"/tags/3d/","section":"Tags","summary":"","title":"3D","type":"tags"},{"content":"","date":"2016-08-10","externalUrl":null,"permalink":"/tags/user-interface/","section":"Tags","summary":"","title":"User Interface","type":"tags"},{"content":"Overview of graphics, audio, and other user interface features in VxWorks® real-time operating system (RTOS).\n","date":"2016-08-10","externalUrl":null,"permalink":"/video/vxworks-user-interface-overview/","section":"Videoes","summary":"\u003cp\u003eOverview of graphics, audio, and other user interface features in VxWorks® real-time operating system (\u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eRTOS\u003c/a\u003e).\u003c/p\u003e\n\u003clite-youtube videoid=\"ve3_1dIICsk\" playlabel=\"ve3_1dIICsk\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"VxWorks User Interface Overview","type":"video"},{"content":"Overview of the VxWorks® real-time operating system (RTOS) safety features.\n","date":"2016-08-10","externalUrl":null,"permalink":"/video/vxworks-safety-overview/","section":"Videoes","summary":"\u003cp\u003eOverview of the VxWorks® real-time operating system (\u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eRTOS\u003c/a\u003e) safety features.\u003c/p\u003e\n\u003clite-youtube videoid=\"jKhRcQ4ZZ9U\" playlabel=\"jKhRcQ4ZZ9U\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"VxWorks Safety Overview","type":"video"},{"content":"Overview of security functionality provided by VxWorks® real-time operating system (RTOS).\n","date":"2016-08-10","externalUrl":null,"permalink":"/video/vxworks-security-overview/","section":"Videoes","summary":"\u003cp\u003eOverview of security functionality provided by VxWorks® real-time operating system (\u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eRTOS\u003c/a\u003e).\u003c/p\u003e\n\u003clite-youtube videoid=\"ziiYnBt90I4\" playlabel=\"ziiYnBt90I4\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"VxWorks Security Overview","type":"video"},{"content":"Introduction to a 6-part series of short overview videos on the VxWorks® real-time operating system (RTOS).\n","date":"2016-08-10","externalUrl":null,"permalink":"/video/introduction-to-vxworks/","section":"Videoes","summary":"\u003cp\u003eIntroduction to a 6-part series of short overview videos on the VxWorks® real-time operating system (\u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eRTOS\u003c/a\u003e).\u003c/p\u003e\n\u003clite-youtube videoid=\"ZfIWnDQiVWg\" playlabel=\"ZfIWnDQiVWg\" params=\"\"\u003e\u003c/lite-youtube\u003e","title":"Introduction to VxWorks","type":"video"},{"content":" An industrial system can consist of hundreds of sensors, motors and controllers. When the physical infrastructure connecting them together is an Ethernet network, it takes special handling to make sure that sensor data and control commands reach their destinations in the network within a hard time limit, often within 1 or 2µs. Failure for a message to reach its destination in time can result in uncoordinated mechanical movements, or wrong correlation of sensor data.\nTime-sensitive networking (TSN) contains a set of standards to address the needs of time-critical networked applications. As a first step, devices on the network need to have their clocks synchronized to sub-microsecond level. The IEEE 802.1AS synchronization standard enables clock synchronization across TSN-aware devices on linked networks.\nThe IEEE 802.1AS standard is a profile of the Precision Time Protocol (PTP). VxWorks users have the ability to participate in TSN networks using PTP, and to make use of the high precision clock available in some Ethernet controllers. Devices running VxWorks can synchronize with other devices running 802.1AS – those running VxWorks and those running other operating systems with PTP. VxWorks devices can run as the clock master, clock slave, or as the boundary clock to extend the network.\nI tried out the VxWorks implementation of PTP across two boards: a Kontron mini-ITX board and an Intel Customer Reference Board (CRB). Both boards have Intel Core i5 processors, and both boards are outfitted with Intel I210 Ethernet PCIe cards. The Intel I210 Ethernet controller contains a high precision timer supported by VxWorks. This controller includes a digital output pin called the Software Defined Pin (SDP). This pin can be set up to switch voltage in hardware when the high precision timer reaches certain values, so it can be programmed to emit specific pulses per second.\nThe two VxWorks devices are connected to a Cisco switch with 802.1AS capabilities. The Cisco switch acts as the master clock, and the two VxWorks devices synchronize their system clocks to the master clock. The SDP on both devices is set up to emit a digital output pulse 10 times a second based on the I210 high precision timer. Using an oscilloscope probing the SDP, I can see the synchronization between the two boards. See Figure 1.\nFigure 1 TSN Setup. Two VxWorks slave clock devices connected to a Cisco switch master clock. The results confirm the ability for VxWorks to synchronize at the sub-microsecond level. Figure 2 shows the traces on my oscilloscope when the nodes are disconnected from the Cisco switch. The two traces each correspond to the SDP from one of the VxWorks devices. I’ve offset the voltages slightly to avoid overlapping the traces. You can see that when not using TSN, the clocks are wildly out-of-sync by almost 60 milliseconds. This large offset is expected. While both devices are deterministic and real-time, there is no correlation between the timers on the two devices.\nFigure 2 No PTP synchronization. Digital outputs at 10 pulses per second. 50 milliseconds per division. When I connect the two nodes to the Cisco switch, PTP synchronization happens automatically. The two traces snap together instantly. Figure 3 shows the digital output of the two devices with PTP synchronization.\nFigure 3 With PTP synchronization. Digital output at 10 pulses per second. 50 milliseconds per division. To see if the devices read the refined timing criteria required by 802.1AS, I can zoom in to see precisely how well aligned the pulses are to each other. In the traces in Figure 4, the pulses are 20 nanoseconds apart. The traces generally drift between 20 – 50 nanoseconds.\nFigure 4 PTP Synchronization at the sub-microsecond level. The traces are the pulses produced by the SDP on the Intel I210 ethernet controller. The oscilloscope is set to 100 nanoseconds per division. Now that we know VxWorks can synchronize clocks over Ethernet, the devices can participate in TSN scheduled traffic, opening up the way to time-critical network applications.\nThe sub-microsecond synchronization demonstrates the PTP capabilities of VxWorks. Wind River continues to invest in more TSN standards, enabling VxWorks devices to correlate sensor readings collected across industrial systems and push out coordinated commands to actuators. Wind River participates in the Industrial Internet Consortium (IIC) TSN Testbed and coordinates with other TSN device manufacturers to ensure interoperability.\nYou can learn more about the VxWorks RTOS products at https://www.windriver.com/products/vxworks/.\nBy Ka Kay Achacoso.\n","date":"2016-08-01","externalUrl":null,"permalink":"/app/demonstration-of-precision-time-protocol-in-vxworks/","section":"Apps","summary":"\u003cblockquote\u003e\n\u003cp\u003eAn industrial system can consist of hundreds of sensors, motors and controllers. When the physical infrastructure connecting them together is an Ethernet network, it takes special handling to make sure that sensor data and control commands reach their destinations in the network within a hard time limit, often within 1 or 2µs. Failure for a message to reach its destination in time can result in uncoordinated mechanical movements, or wrong correlation of sensor data.\u003c/p\u003e","title":"Demonstration of Precision Time Protocol in VxWorks","type":"app"},{"content":" For more than 30 years, the VxWorks® real-time operating system (RTOS) has been chosen by global industry leaders as the trusted foundation to power billions of safety-critical intelligent devices, machines, and systems.\nFrom literally out-of-this-world projects such as the InSight Mars lander, now operating on the Red Planet, to medical infusion pumps and imaging systems, manufacturing robots, and other embedded devices in the Internet of Things (IoT), VxWorks is repeatedly selected as the RTOS for innovative solutions that deliver secure, safe, and reliable applications across a wide array of industries, including aerospace, automotive, defense, industrial, medical, and transportation.\n","date":"2015-10-14","externalUrl":null,"permalink":"/video/what-is-vxworks/","section":"Videoes","summary":"\u003clite-youtube videoid=\"z9U27hMhuDc\" playlabel=\"z9U27hMhuDc\" params=\"\"\u003e\u003c/lite-youtube\u003e\n\n\u003cp\u003eFor more than 30 years, the \u003ca href=\"https://www.vxworks6.com\" target=\"_blank\"\u003eVxWorks®\u003c/a\u003e real-time operating system (RTOS) has been chosen by global industry leaders as the trusted foundation to power billions of safety-critical intelligent devices, machines, and systems.\u003c/p\u003e","title":"What Is VxWorks","type":"video"},{"content":"","date":"2015-08-22","externalUrl":null,"permalink":"/tags/embedded-graphics/","section":"Tags","summary":"","title":"Embedded Graphics","type":"tags"},{"content":"","date":"2015-08-22","externalUrl":null,"permalink":"/tags/healthcare-systems/","section":"Tags","summary":"","title":"Healthcare Systems","type":"tags"},{"content":"","date":"2015-08-22","externalUrl":null,"permalink":"/tags/nxp-i.mx-6/","section":"Tags","summary":"","title":"NXP I.MX 6","type":"tags"},{"content":"","date":"2015-08-22","externalUrl":null,"permalink":"/tags/qt-qml/","section":"Tags","summary":"","title":"Qt QML","type":"tags"},{"content":" VxWorks 7 Graphics and IoT Connectivity on NXP i.MX 6\nAs embedded systems evolve into fully connected edge platforms, modern devices increasingly require responsive graphical interfaces, deterministic execution, and secure cloud connectivity within constrained hardware environments. Industrial control systems, medical devices, and IoT platforms now demand sophisticated user experiences without sacrificing real-time reliability.\nWind River demonstrated this convergence through a VxWorks 7 graphics showcase presented by Ka Kay Achacoso, highlighting accelerated graphics and cloud-connected healthcare applications running on the NXP i.MX 6 applications processor family.\nThe demonstration combined:\nVxWorks 7 Qt and Qt/QML graphics frameworks NXP i.MX 6 hardware acceleration IoT cloud connectivity Real-time embedded execution The result was a connected healthcare platform capable of monitoring biometric data such as blood pressure and heart rate while delivering responsive graphical user interfaces within a deterministic RTOS environment.\n🖥️ VxWorks 7 as a Modern Embedded Graphics Platform # Traditionally, embedded real-time operating systems focused primarily on deterministic scheduling and low-level hardware control. However, modern embedded systems increasingly require advanced graphical capabilities alongside real-time execution.\nVxWorks 7 extends into this domain by supporting:\nHardware-accelerated graphics pipelines Multi-core SMP execution Secure networking stacks Deterministic task scheduling Memory protection and process isolation Real-time device management These capabilities make the platform suitable for:\nMedical monitoring devices Industrial HMIs Smart edge gateways Automotive infotainment systems Aerospace visualization systems Connected IoT appliances Unlike general-purpose operating systems, VxWorks maintains predictable runtime behavior even when handling graphics rendering, networking, and real-time sensor processing simultaneously.\n🎨 Qt and QML on VxWorks # Qt and QML provide a modern UI framework for embedded applications requiring fluid graphics and hardware acceleration.\nThe integration demonstrated on VxWorks enables developers to build:\nGPU-accelerated interfaces Touch-enabled embedded dashboards Animated QML applications Real-time visualization systems Cloud-connected control panels Qt/QML simplifies embedded UI development by separating interface logic from rendering behavior.\nA typical QML structure includes:\nRectangle { width: 800 height: 480 Text { text: \u0026#34;Heart Rate Monitor\u0026#34; anchors.centerIn: parent } } Running Qt on top of VxWorks combines modern application frameworks with deterministic RTOS scheduling.\nThis architecture is particularly important in medical and industrial systems where UI responsiveness must coexist with strict timing requirements.\n⚡ Hardware Acceleration on NXP i.MX 6 # The NXP i.MX 6 family is widely used in embedded graphics and edge computing platforms due to its combination of ARM processing performance and integrated multimedia acceleration.\nThe demonstration leveraged:\nARM Cortex-A processors GPU acceleration Display pipelines Multimedia processing Embedded networking interfaces When combined with VxWorks 7, the platform supports:\nAccelerated 2D and 3D rendering Low-latency UI updates Deterministic graphics scheduling Real-time sensor visualization This is especially valuable for systems that must continuously process:\nSensor telemetry Human-machine interaction Network communication Cloud synchronization without introducing unacceptable latency or instability.\n☁️ IoT Cloud Connectivity in Real-Time Systems # One of the key aspects of the demonstration was cloud-connected healthcare monitoring.\nThe example application monitored biometric metrics including:\nBlood pressure Heart rate Device telemetry while synchronizing data across connected systems.\nModern IoT architectures require embedded devices to simultaneously support:\nSecure networking Real-time sensor acquisition Cloud messaging Local visualization Remote management VxWorks 7 provides a networking stack designed for deterministic embedded systems, enabling devices to maintain stable operation under continuous network activity.\nTypical IoT communication layers may include:\nMQTT DDS REST APIs TLS-secured communication Edge gateway integration For healthcare and industrial deployments, maintaining predictable execution during cloud communication is critical.\n🏥 Embedded Healthcare System Architecture # Healthcare systems increasingly rely on embedded edge devices capable of local analytics, graphical monitoring, and cloud integration.\nThe demonstrated platform represents a broader trend toward intelligent medical edge systems capable of:\nReal-time patient monitoring Local visualization Secure remote telemetry Continuous sensor acquisition Deterministic alert processing In these environments, an RTOS provides several advantages over conventional desktop-oriented operating systems:\nPredictable scheduling High system reliability Reduced downtime Long lifecycle support Functional isolation Security hardening Qt/QML adds the ability to create responsive medical dashboards while VxWorks ensures deterministic behavior underneath the application layer.\n🔒 Security and Reliability Considerations # Connected healthcare and industrial systems must address both cybersecurity and operational reliability.\nVxWorks 7 includes features designed for secure embedded deployment:\nSecure boot Memory protection Process isolation Hardened networking Runtime integrity mechanisms These capabilities are particularly important in IoT environments where edge devices remain continuously connected to external systems.\nCombining secure networking with deterministic execution reduces the risk of instability caused by uncontrolled workloads, networking spikes, or resource contention.\n📈 Why Accelerated Graphics Matter in Embedded RTOS Systems # Historically, graphical interfaces were often considered secondary in embedded RTOS deployments. That assumption has changed significantly.\nModern embedded systems increasingly require:\nHigh-resolution displays Touch interaction Real-time visualization Animated interfaces Data-rich dashboards At the same time, these systems must continue to meet:\nHard real-time constraints Reliability requirements Long uptime expectations Functional safety goals The combination of VxWorks 7, Qt/QML, and i.MX 6 hardware acceleration demonstrates how embedded RTOS platforms are evolving into full edge-computing environments capable of delivering both deterministic execution and modern user experiences.\n🧠 The Future of Intelligent Embedded Edge Platforms # The convergence of embedded graphics, cloud connectivity, and real-time processing reflects a larger transformation across the edge computing industry.\nModern embedded platforms increasingly unify:\nReal-time control systems AI inference engines GPU-accelerated graphics Cloud-connected telemetry Secure networking Human-machine interfaces This architecture is becoming standard across:\nSmart medical devices Industrial automation systems Autonomous platforms Intelligent transportation systems Aerospace visualization platforms VxWorks 7’s integration with Qt and hardware-accelerated embedded processors positions it as a strong platform for deterministic edge systems requiring both advanced visualization and real-time execution guarantees.\n📚 References # Wind River VxWorks 7 Qt and Qt/QML Framework Documentation NXP i.MX 6 Applications Processor Family Wind River Embedded Graphics Demonstrations ","date":"2015-08-22","externalUrl":null,"permalink":"/video/vxworks-7-graphics-and-iot-connectivity-on-nxp-i.mx-6/","section":"Videoes","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 7 Graphics and IoT Connectivity on NXP i.MX 6\u003c/p\u003e\u003c/blockquote\u003e\n\u003clite-youtube videoid=\"U1AnXRj-oBc\" playlabel=\"U1AnXRj-oBc\" params=\"\"\u003e\u003c/lite-youtube\u003e\n\n\u003cp\u003eAs embedded systems evolve into fully connected edge platforms, modern devices increasingly require responsive graphical interfaces, deterministic execution, and secure cloud connectivity within constrained hardware environments. Industrial control systems, medical devices, and IoT platforms now demand sophisticated user experiences without sacrificing real-time reliability.\u003c/p\u003e","title":"VxWorks 7 Graphics and IoT Connectivity on NXP i.MX 6","type":"video"},{"content":"","date":"2014-03-03","externalUrl":null,"permalink":"/tags/modularity/","section":"Tags","summary":"","title":"Modularity","type":"tags"},{"content":" VxWorks 7 RTOS for IoT: Modular, Secure, Scalable Design\n🚀 Introduction # The rise of the Internet of Things (IoT) has fundamentally reshaped the requirements for embedded operating systems. Traditional real-time operating systems (RTOS) must now go beyond deterministic performance and reliability to support security, scalability, and continuous updates in highly connected environments.\nVxWorks 7 represents a significant architectural evolution, designed to address these emerging demands while maintaining its leadership in mission-critical domains such as aerospace, defense, industrial automation, and medical systems.\n🌐 IoT-Driven Evolution of RTOS Requirements # From Determinism to Connected Intelligence # Historically, RTOS platforms focused on:\nDeterministic scheduling Low latency interrupt handling High reliability in closed systems With IoT, new requirements emerge:\nSecure connectivity across networks Remote device management and updates Rapid feature deployment cycles Scalability across heterogeneous devices An RTOS must now function as both a real-time kernel and a connected platform foundation.\n🧩 Modular Architecture Redesign # Decoupling the Core System # One of the most important changes in VxWorks 7 is its modular architecture:\nCore RTOS kernel is separated from subsystems Components such as file systems and networking stacks are independent packages Benefits of Modularity # Independent updates: Upgrade components without rebuilding the entire system Reduced certification cost: Avoid full system revalidation Faster iteration cycles: Adapt quickly to changing requirements This design aligns with modern software engineering practices, enabling continuous deployment even in embedded environments.\n🔐 Built-in Security Framework # Security as a First-Class Feature # VxWorks 7 integrates comprehensive security mechanisms:\nSecure data storage Root of trust Secure boot and upgrade mechanisms Tamper resistance User and policy management Importance in IoT Context # IoT devices operate in exposed environments, making them targets for:\nUnauthorized access Firmware tampering Data exfiltration Embedding security at the RTOS level ensures protection across the entire software stack.\n🛡️ Safety-Critical Enhancements # Expanding Safety Capabilities # VxWorks 7 introduces enhancements tailored for safety-critical applications:\nSupport for certification workflows Improved isolation and fault containment Deterministic behavior under mixed workloads Target Domains # Aerospace and defense Medical devices Industrial control systems Transportation platforms These enhancements reinforce VxWorks’ role in systems where failure is not acceptable.\n⚙️ Scalability Across Device Classes # Unified Platform Approach # VxWorks 7 supports both:\nMicrokernel configurations (small footprint) Standard kernel configurations (full-featured systems) Advantages # Single RTOS across diverse hardware profiles Reduced development and maintenance complexity Consistent tooling and APIs This enables deployment across:\nWearables and edge devices Industrial gateways High-performance networking equipment 🔗 Connectivity and Graphics Capabilities # Broad Protocol Support # VxWorks 7 includes extensive connectivity options:\nUSB CAN Bluetooth FireWire Continua Additionally:\nHigh-performance networking stack Built-in support for modern communication protocols Graphics Stack Enhancements # OpenVG-based graphics framework Hardware-accelerated drivers Integration with Tilcon graphics tools These features enable rich user interfaces alongside real-time processing.\n🧠 Industry Perspective # The evolution of IoT systems has created demand for:\nGreater flexibility in system design Scalable architectures Continued real-time determinism VxWorks 7 addresses these needs by combining:\nModular software architecture Integrated security Broad hardware and protocol support This positions it as a strong candidate for next-generation embedded systems.\n🔍 Key Takeaways # RTOS platforms must evolve to meet IoT demands Modularity enables faster updates and reduced certification overhead Security is essential in connected embedded systems Scalability allows a single platform across device classes Connectivity and graphics support expand application scope ✅ Conclusion # VxWorks 7 represents a major step forward in RTOS design, transitioning from a traditional real-time kernel to a modular, secure, and scalable platform for IoT.\nBy integrating flexibility, security, and connectivity into its core architecture, it enables developers to build next-generation embedded systems that meet both real-time and connected system requirements.\nThis evolution ensures that VxWorks remains a leading choice for mission-critical and IoT-enabled applications in an increasingly interconnected world.\nReference: VxWorks 7 RTOS for IoT: Modular, Secure, Scalable Design\n","date":"2014-03-03","externalUrl":null,"permalink":"/news/vxworks-7-rtos-for-iot-modular-secure-scalable-design/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 7 RTOS for IoT: Modular, Secure, Scalable Design\u003c/p\u003e\u003c/blockquote\u003e\n\n\n\u003ch2 class=\"relative group\"\u003e🚀 Introduction \n    \u003cdiv id=\"-introduction\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-introduction\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eThe rise of the Internet of Things (IoT) has fundamentally reshaped the requirements for embedded operating systems. Traditional real-time operating systems (RTOS) must now go beyond deterministic performance and reliability to support security, scalability, and continuous updates in highly connected environments.\u003c/p\u003e","title":"VxWorks 7 RTOS for IoT: Modular, Secure, Scalable Design","type":"news"},{"content":"","date":"2012-06-18","externalUrl":null,"permalink":"/tags/datalight-flashfx-pro/","section":"Tags","summary":"","title":"Datalight FlashFX Pro","type":"tags"},{"content":"","date":"2012-06-18","externalUrl":null,"permalink":"/tags/kontron-d0801/","section":"Tags","summary":"","title":"Kontron D0801","type":"tags"},{"content":"Kontron D0801 Platform BSP for Wind River VxWorks\nOff-the-shelf BSP for Wind River VxWorks Fully integrated into the Wind River Workbench Supports platform board specific devices Supports Kontron AM4140 The Kontron BSPs for Wind River platforms are designed to get customers started immediately with application development instead of first getting involved with BSP integration or hardware bring-up issues. Support of board specific devices and interfaces has been added to the BSP to achieve the full benefit of the functions provided by the hardware.\nThe BSP is prepared to use the Wind River system diagnostic and debugging tools which are integral elements of the Wind River Workbench.\nThe BSP includes an evaluation mode version of the Datalight FlashFX® Pro middleware, which acts basically as a software based NAND Flash manager. Datalight FlashFX Pro makes NAND Flash memory appear as a standard high-performance disk drive to the operating system.\nApplications can use standard disk drive access methods to read and write NAND Flash memory, with no modifications as Datalight FlashFX Pro provides a generic block device driver interface that can be used by Wind River / VxWorks file systems, like DOSFS or HRFS. Datalight FlashFX Pro does not provide a file system of its own. Please contact Wind River for a full license for Datalight FlashFX Pro.\nTechnical Information # Item Comment Wind River VxWorks Platform Platform for Industrial Devices (VxWorks 6.9.2) (Other platforms can be supported, please contact Kontron) Processor / CPU Freescale® QorIQ P4080 Multi Processing Symmetric (SMP) Boot Devices Network NAND Flash SD Card PCI Express Root Complex Serial RapidIO Host/Agent (HAL Library and application demo) Ethernet 10/100/1000 BASE-T DPAA TSECs 10 Gigabit Ethernet / XAUI Serial RS232 without hardware handshake IPMI Sensor Reading System Monitoring Graceful Shutdown Timer System, Auxiliary, Timestamp Miscellaneous Devices Real Time Clock Hardware Watchdog (RESET, IRQ, TIMER, Dual-Stage) EEPROM for boot line storage EEPROM for user data storage Mass Storage NAND Flash, micro SD Card Board Status Indication General purpose LED block NOTE: The feature list above represents a summary of functionalities supported by the platform BSP. Depending on the used Platform Board a subset of those features is available. For more information about implemented hardware features refer to the Platform Board Hardware Manual.\n","date":"2012-06-18","externalUrl":null,"permalink":"/bsp/kontron-d0801-platform-bsp-for-wind-river-vxworks/","section":"Bsps","summary":"\u003cp\u003e\u003cb\u003eKontron D0801 Platform BSP for Wind River VxWorks\u003c/b\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eOff-the-shelf BSP for Wind River VxWorks\u003c/li\u003e\n\u003cli\u003eFully integrated into the Wind River Workbench\u003c/li\u003e\n\u003cli\u003eSupports platform board specific devices\u003c/li\u003e\n\u003cli\u003eSupports Kontron AM4140\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe \u003ca href=\"https://www.vxworks6.com/bsp/kontron-d0801-platform-bsp-for-wind-river-vxworks/\" target=\"_blank\"\u003eKontron BSPs\u003c/a\u003e for Wind River platforms are designed to get customers started immediately with application development instead of first getting involved with BSP integration or hardware bring-up issues. Support of board specific devices and interfaces has been added to the BSP to achieve the full benefit of the functions provided by the hardware.\u003c/p\u003e","title":"Kontron D0801 Platform BSP for Wind River VxWorks","type":"bsp"},{"content":" 🚀 Overview # In embedded systems that demand high bandwidth and low latency, traditional shared buses often become a bottleneck. RapidIO, with its packet-switched architecture and deterministic behavior, has long been favored in telecommunications, defense, and high-performance embedded platforms. A 2010 study by Huang Zhen-zhong and colleagues presented a practical solution for integrating legacy PCI-based CPUs into RapidIO fabrics by designing a PCI–RapidIO bridge driver on VxWorks.\nPublished in Computer Engineering (Vol. 36, No. 4), the work demonstrates how a custom bridge driver enables PCI hosts to participate in RapidIO networks, supporting configuration access, message passing, system enumeration, and multicast. Although the implementation targets hardware and software platforms of its time, the architectural concepts remain relevant in 2025 for legacy systems, custom backplanes, and specialized edge computing deployments.\n🔌 Why Bridge PCI and RapidIO? # Conventional embedded interconnects typically rely on hierarchical shared buses, which suffer from scalability, arbitration overhead, and limited throughput. RapidIO addresses these limitations through:\nPacket-switched communication Low-voltage differential signaling (LVDS) Deterministic latency and high reliability With four differential pairs, RapidIO can achieve up to 10 Gb/s effective throughput, making it highly competitive for embedded systems.\nRapidIO is structured into three layers:\nPhysical layer: Defines signaling, packet transport, flow control, and basic error handling Transport layer: Manages addressing and routing between endpoints Logical layer: Specifies transaction protocols and packet formats In 2010, few general-purpose CPUs offered native RapidIO interfaces. The proposed PCI–RapidIO bridge allowed existing PCI-based processors to connect seamlessly to RapidIO fabrics, extending system lifetimes and reducing redesign costs.\n🧩 Hardware and Driver Architecture # The solution combines dedicated hardware logic with a VxWorks device driver.\nOn the hardware side, the bridge uses:\nXilinx LogiCORE PCI and RapidIO IP cores A custom PCI_RIO_Bridge module for protocol translation Clock domain crossing logic between PCI and RapidIO A single DMA channel to accelerate data transfers On the software side, the VxWorks driver manages PCI discovery, interrupt handling, and RapidIO protocol services, exposing a clean API to applications.\n⚙️ Driver Initialization and PCI Configuration # Driver initialization begins by locating the bridge device on the PCI bus using vendor and device IDs. Once found, the driver reads memory-mapped register addresses and interrupt lines, then connects and enables interrupts:\nif (pciFindDevice(0x0606, 0x8080, unit, \u0026amp;pciBus, \u0026amp;pciDev, \u0026amp;pciFunc) == ERROR) { return 0; } pciConfigInLong(pciBus, pciDev, pciFunc, PCI_CFG_ADDRESS_0, \u0026amp;membaseCsr); pciConfigInByte(pciBus, pciDev, pciFunc, PCI_CFG_DEV_INT_LINE, \u0026amp;irq); Baseaddr = membaseCsr \u0026amp; 0xffffffff; intConnect(INUM_TO_IVEC((int)irq), (VOIDFUNCPTR)intfunc, 0); intEnable(irq); This approach relies on the board support package (BSP) to allocate PCI resources automatically, simplifying deployment.\n🧠 Interrupt Handling Strategy # To preserve real-time performance, interrupt service routines (ISRs) are intentionally minimal:\nDMA interrupts signal transfer completion and release semaphores Port up/down interrupts detect RapidIO link state changes Doorbell interrupts identify sender and payload, invoking user callbacks Message interrupts manage segmented messages and queue them for reassembly Response interrupts process read-return transactions All complex processing is deferred to task context.\n🛠️ RapidIO Functional API # The driver implements core RapidIO logical-layer services through a hardware abstraction layer.\nKey capabilities include:\nConfiguration access via rioConfigurationRead and rioConfigurationWrite Remote memory operations using rioNread and rioNwrite Event signaling with rioSendDoorbell and rioNwriteDoorbell Message passing up to 4096 bytes with send and receive APIs Advanced functionality extends support to:\nMulticast configuration through switch registers Dynamic route table management Automatic system enumeration to assign device IDs and build routing paths These features allow PCI hosts to participate fully in RapidIO-based systems.\n📊 Testing and Performance Results # Validation was performed on PowerPC7447 boards equipped with PCI–RapidIO bridges and interconnected through a Tundra Tsi578 RapidIO switch under VxWorks.\nRepresentative performance results included:\nDoorbell latency of approximately 7 µs Configuration reads and writes under 11 µs Sustained read and write bandwidth exceeding 150 MB/s for large payloads Reliable message transfers up to 4096 bytes The results confirmed correct protocol handling and efficient data movement between PCI and RapidIO domains.\n🌍 Relevance in 2025 # Although introduced in 2010, this PCI–RapidIO bridge driver design remains instructive. Many deployed systems still rely on legacy CPUs or proprietary interconnects, and similar techniques are applicable when integrating accelerators, FPGA fabrics, or specialized I/O subsystems into modern architectures.\nThe work also foreshadows challenges addressed in newer RapidIO specifications, such as enhanced flow control and advanced error management. For engineers designing custom interconnect solutions on RTOS platforms, this design serves as a solid reference for bridging heterogeneous buses while preserving performance and determinism.\n","date":"2010-08-22","externalUrl":null,"permalink":"/bsp/pci-rapidio-bridge-driver-design-on-vxworks/","section":"Bsps","summary":"\u003ch2 class=\"relative group\"\u003e🚀 Overview \n    \u003cdiv id=\"-overview\" class=\"anchor\"\u003e\u003c/div\u003e\n    \n    \u003cspan\n        class=\"absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100\"\u003e\n        \u003ca class=\"group-hover:text-primary-300 dark:group-hover:text-neutral-700\"\n            style=\"text-decoration-line: none !important;\" href=\"#-overview\" aria-label=\"锚点\"\u003e#\u003c/a\u003e\n    \u003c/span\u003e        \n    \n\u003c/h2\u003e\n\u003cp\u003eIn embedded systems that demand \u003cstrong\u003ehigh bandwidth and low latency\u003c/strong\u003e, traditional shared buses often become a bottleneck. \u003cstrong\u003eRapidIO\u003c/strong\u003e, with its packet-switched architecture and deterministic behavior, has long been favored in telecommunications, defense, and high-performance embedded platforms. A 2010 study by Huang Zhen-zhong and colleagues presented a practical solution for integrating \u003cstrong\u003elegacy PCI-based CPUs\u003c/strong\u003e into RapidIO fabrics by designing a \u003cstrong\u003ePCI–RapidIO bridge driver on VxWorks\u003c/strong\u003e.\u003c/p\u003e","title":"PCI-RapidIO Bridge Driver Design on VxWorks","type":"bsp"},{"content":"","date":"2010-06-21","externalUrl":null,"permalink":"/tags/aerospace-systems/","section":"Tags","summary":"","title":"Aerospace Systems","type":"tags"},{"content":"","date":"2010-06-21","externalUrl":null,"permalink":"/tags/do-178b/","section":"Tags","summary":"","title":"DO-178B","type":"tags"},{"content":"","date":"2010-06-21","externalUrl":null,"permalink":"/tags/integrated-modular-avionics/","section":"Tags","summary":"","title":"Integrated Modular Avionics","type":"tags"},{"content":" VxWorks 653 Platform 2.3 for Integrated Modular Avionics\nAs aerospace systems become increasingly complex, avionics manufacturers face growing pressure to consolidate functionality, reduce hardware footprints, and accelerate certification while maintaining the highest levels of safety and reliability. Traditional federated avionics architectures are gradually giving way to Integrated Modular Avionics (IMA), where multiple applications with different criticality levels share common computing resources.\nDesigned specifically for this environment, Wind River VxWorks 653 Platform 2.3 provides a commercial off-the-shelf (COTS) solution that combines deterministic real-time performance, robust partitioning, and extensive certification support. Built upon the proven VxWorks real-time operating system, the platform delivers full compliance with the ARINC 653 standard while providing comprehensive certification evidence for RTCA DO-178B and EUROCAE ED-12B Level A programs.\n✈️ The Role of VxWorks 653 in Modern Avionics # Integrated Modular Avionics architectures require strict separation between applications to ensure that faults in one subsystem cannot affect others. At the same time, these systems must maximize hardware utilization while supporting independent development and certification activities.\nVxWorks 653 addresses these requirements through a partitioned operating environment that enables multiple avionics applications to execute safely on shared hardware platforms.\nKey objectives supported by the platform include:\nReduced Size, Weight, and Power (SWaP) Consolidation of avionics functions Improved resource utilization Simplified system integration Enhanced maintainability Reduced certification risk Long-term software portability By implementing robust time and space partitioning, VxWorks 653 enables predictable execution and strong fault containment across safety-critical systems.\n🛡️ Core Benefits of VxWorks 653 Platform 2.3 # The platform was designed to support both technical and certification objectives throughout the avionics lifecycle.\nARINC 653 Compliance # VxWorks 653 is fully compliant with ARINC 653 Supplement 2 Part 1 Required Services, providing a standardized execution environment for avionics applications.\nBenefits include:\nImproved software portability Reduced vendor lock-in Easier integration across programs Support for reusable avionics software components Independent verification further strengthens confidence in compliance and interoperability.\nApplication Portability and Reuse # Organizations can leverage existing investments in:\nARINC 653 applications Legacy VxWorks applications Reusable software components Previously certified software assets This capability reduces redevelopment effort and lowers lifecycle costs.\nIndependent Development Teams # One of the primary advantages of Integrated Modular Avionics is the ability to support parallel development activities.\nVxWorks 653 enables:\nIndependent partition development Separate verification activities Reduced integration complexity Controlled interface management This approach improves project scalability while supporting large, distributed engineering organizations.\nCertification Acceleration # Certification remains one of the most expensive aspects of avionics development.\nVxWorks 653 provides extensive certification artifacts that help reduce effort associated with:\nRequirements verification Traceability analysis Safety assessments Certification audits These resources can significantly shorten development schedules and reduce program risk.\n⚙️ VxWorks 653 Run-Time Architecture # At the heart of the platform is a partitioned architecture specifically engineered for safety-critical environments.\nVxWorks 653 Module Operating System # The Module Operating System functions as the supervisory kernel responsible for managing all platform resources.\nIts responsibilities include:\nEnforcing partition isolation Managing memory protection Scheduling partitions Supervising inter-partition communication Controlling access to hardware resources Applications execute within isolated user-mode partitions and interact only through controlled mechanisms provided by the platform.\nThis architecture prevents unintended interference between applications and supports strong fault containment.\n⏱️ Advanced Partition Management and Scheduling # Partitioning is a foundational requirement of Integrated Modular Avionics.\nSpace Partitioning # Each application executes within a dedicated memory space protected by hardware memory management mechanisms.\nAdvantages include:\nPrevention of unauthorized memory access Fault isolation Improved security Enhanced certification confidence A failure within one partition cannot directly corrupt the memory of another partition.\nTime Partitioning # VxWorks 653 implements deterministic scheduling that guarantees processor access according to predefined schedules.\nThis ensures:\nPredictable execution behavior Guaranteed resource allocation Compliance with avionics timing requirements Repeatable system performance Enhanced Scheduling Capabilities # Beyond standard ARINC scheduling, the platform includes advanced scheduling mechanisms such as:\nMode-based scheduling ARINC Plus Priority-Preemptive Scheduling (APPS) These capabilities allow systems to utilize idle processing capacity more efficiently while maintaining deterministic behavior.\n🔧 Flexible Partition Operating Systems # VxWorks 653 supports multiple approaches to partition implementation, providing flexibility for various application requirements.\nvThreads Environment # The vThreads partition operating system is based on VxWorks 5.5 technology and provides:\nMulti-threaded execution C language support C++ language support APEX API support Mature development environment This environment simplifies migration of existing VxWorks applications into partitioned architectures.\nCore OS Interface Library (COIL) # For organizations requiring specialized runtime environments, the Core OS Interface Library (COIL) provides a framework for developing custom partition operating systems.\nThis flexibility enables:\nTailored runtime implementations Legacy software integration Specialized application environments Standards-Based APIs # VxWorks 653 supports widely adopted interfaces including:\nARINC 653 APEX APIs POSIX APIs VxWorks application interfaces This standards-based approach improves portability and simplifies application development.\n🔄 Communication Mechanisms # Reliable communication between avionics applications is essential while maintaining partition integrity.\nInter-Partition Communication # VxWorks 653 provides ARINC-compliant communication services through:\nSampling ports Queuing ports APEX communication services These mechanisms support deterministic data exchange between isolated partitions.\nIntra-Partition Communication # Within individual partitions, developers can leverage familiar VxWorks communication mechanisms, including:\nEvents Message queues Semaphores APEX buffers APEX blackboards These services support efficient coordination among application processes.\n🚨 Integrated Health Monitoring # Safety-critical systems require comprehensive fault detection and recovery capabilities.\nThe VxWorks 653 Health Monitor implements ARINC 653 health management services across multiple system layers.\nMulti-Level Monitoring # Health monitoring functions operate at:\nProcess level Partition level Module level This layered approach enables rapid identification and containment of abnormal conditions.\nRecovery and Fault Handling # Available actions include:\nEvent logging Alarm generation Operator notifications Warm restarts Cold restarts Recovery procedures These capabilities improve system availability while supporting certification requirements.\n🖥️ Development Environment and Tooling # Efficient development workflows are critical for complex avionics programs.\nWind River Workbench 3.2 # VxWorks 653 integrates with Wind River Workbench 3.2, an Eclipse-based integrated development environment that streamlines application development and system integration.\nKey capabilities include:\nProject management tools Advanced source code editing Integrated build environment Multi-level debugging System configuration utilities Target shell access vThreads shell support Role-Based Development # Workbench supports separation of responsibilities across engineering teams.\nThis enables:\nIndependent partition development Controlled integration workflows Simplified configuration management Improved collaboration The result is a more scalable and maintainable development process.\n📦 Optional Add-On Components # Several optional products extend the platform\u0026rsquo;s capabilities.\nDO-178B Network Stack # The certified networking package includes:\nUDP support TCP support IPv4 support Certification evidence This allows network-enabled avionics applications to leverage validated communication services.\nDO-178B File System # The certified file system provides:\nPower-fail-safe operation Transaction-based architecture NOR flash support RAM disk support These capabilities are particularly valuable for data logging and mission management applications.\nOn-Chip Debugging Support # Workbench On-Chip Debugging offers:\nJTAG-based debugging Hardware bring-up capabilities Low-level system analysis Certified development support These features assist engineers during both development and verification phases.\n🏗️ Supported Platforms # VxWorks 653 Platform 2.3 supports several processor and host environments commonly used in aerospace programs.\nTarget Architectures # Supported processor families include:\nPowerPC 603 PowerPC 604 PowerPC e500 PowerPC e600 Intel IA-32 Development Hosts # Supported host platforms include:\nMicrosoft Windows XP Solaris 10 While these host environments reflect the technology landscape of the platform\u0026rsquo;s release era, they continue to support long-lived aerospace programs with extended lifecycle requirements.\n🤝 Ecosystem, Services, and Support # Successful avionics programs often require more than software products alone.\nWind River complements VxWorks 653 with:\nProfessional engineering services Hardware partner ecosystems Training programs Certification guidance Technical support Long-term maintenance services This ecosystem helps organizations reduce deployment risk and accelerate program execution.\n🔍 Conclusion # VxWorks 653 Platform 2.3 remains one of the industry\u0026rsquo;s most established solutions for safety-critical Integrated Modular Avionics. By combining strict ARINC 653 partitioning, deterministic scheduling, comprehensive health monitoring, and extensive DO-178B Level A certification evidence, the platform enables aerospace organizations to build highly reliable and certifiable avionics systems.\nIts support for independent development, application portability, fault isolation, and robust communication mechanisms makes it particularly well-suited for complex avionics architectures where safety, maintainability, and certification efficiency are paramount.\nAs the aerospace industry continues to pursue greater system integration and reduced SWaP requirements, VxWorks 653 provides a proven foundation for developing the next generation of mission-critical avionics platforms.\nWhen safety, certification, and determinism are non-negotiable, VxWorks 653 delivers.\n","date":"2010-06-21","externalUrl":null,"permalink":"/training/vxworks-653-platform-2.3-for-integrated-modular-avionics/","section":"Trainings","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 653 Platform 2.3 for Integrated Modular Avionics\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eAs aerospace systems become increasingly complex, avionics manufacturers face growing pressure to consolidate functionality, reduce hardware footprints, and accelerate certification while maintaining the highest levels of safety and reliability. Traditional federated avionics architectures are gradually giving way to \u003cstrong\u003eIntegrated Modular Avionics (IMA)\u003c/strong\u003e, where multiple applications with different criticality levels share common computing resources.\u003c/p\u003e","title":"VxWorks 653 Platform 2.3 for Integrated Modular Avionics","type":"training"},{"content":" This exercise provides a practical refresher on VxWorks 5.5 program development. You will create a simple project, interact with the target system, and use WindView to observe and measure real-time performance characteristics.\n🛠️ Start a VxWorks Project # Launch the Tornado 2.2 development environment.\nCreate a new downloadable project.\nName the project Simple. If you’ve used Tornado before, you may reuse your existing workspace. New developers must create a workspace on the Z: drive; Tornado stores each project in its own directory inside this workspace.\nOur target systems (\u0026ldquo;purpleboxes\u0026rdquo;) use Intel 80486 processors. Select the I80486gnu toolchain for all purplebox-related development.\nFinish creating the project. This also creates the workspace automatically if one does not exist.\n🧱 Create and Build the Simple Project # Copy simple.c into the Simple project directory. In the Files tab, right-click the project and add this file.\nIn the Builds tab, locate I80486gnu under Simple Builds. Right-click and rebuild simple.out. When prompted to regenerate dependencies, click OK.\nDuring the build, the Build Output window appears. Double-click any error to jump directly to its source.\nA successful build produces simple.out, which you will later download to the target.\n⚙️ Start the Target System and Target Server # Powering up a purplebox causes it to FTP a standard VxWorks image from the development station. Therefore, start the FTP server before powering on the target.\nConnect power to the AVerKey iMicro video converter. The power connectors for the converter and the purplebox look identical but provide different voltages—the AVerKey cable is tied down to prevent misconnection.\nPower the purplebox and switch the monitor input using the middle button. You should see the BIOS and VxWorks boot ROM. After the timeout, it downloads the VxWorks image.\nOn the target monitor, verify that the system is ready by confirming the message: WDB: Ready.\nNext, start a Target Server, which acts as a proxy between Tornado and the purplebox. Select the appropriate target based on the labels on the host and target devices. If the target list is empty, run the registry update file (Tornado22-registry-targets) located in C:\\Tornado2.2.\nCheck the bullseye icon in the system tray: no exclamation mark means the connection succeeded. You can double-click it to confirm.\nFrom Tornado, connect to the target server (there should be only one).\n💬 Interact with the Target System # During development, you will primarily use the remote shell. Start it by clicking the shell icon.\nThe shell window gives you command-line access to the target. The Tornado User\u0026rsquo;s Guide documents all commands; typing help provides brief descriptions.\nRight-click Simple Files and download simple.out to the target. Run the program by typing its entry function:\nprogStart\nAny function can be invoked simply by typing its name.\n📊 Gathering System Performance Data # WindView is Tornado’s tool for collecting detailed timing and event data from the target. Launch it from the toolbar.\nWindView collects events in on-target buffers. From the Upload Mode screen, choose whether to upload data continuously or defer uploads until logging stops.\nDeferred upload reduces runtime overhead but limits capture duration. You can also adjust buffer count and size in Advanced options. Use Deferred Upload for these exercises.\nControl what events are logged using the Event Logging Level screen.\nOpen the Log Overview tab. Set refresh to 1 second, then press the green Go button to start logging.\nAllow the buffers to fill or click the red Stop button to end capture manually. Upload the event log using the Upload Event Log button.\nWindView will generate an event graph similar to the following:\nExplore the event graph:\nWhat do the icons represent? What is the meaning of each interval? How do you zoom in for detail? Can specific event types be filtered? How do you measure the time between two points? For deeper analysis, export the data to CSV. Note: If zoomed in, only the zoomed portion will be exported.\n📈 Analyze the Data # From the exported CSV:\nCalculate the average interval between executions of the simple task. Identify the minimum and maximum intervals. Plot a histogram. Does the distribution look uniform? Clustered? Sporadic? This analysis shows how external factors, scheduling, or interrupt latency affect real-time behavior on VxWorks.\n🛠️ Source code # /* simple.c - a sample program to use as an introduction to VxWorks and Tornado */ /* $Id: simple.c,v 1.1 2007-03-12 05:47:46 se463 Exp $ */ /* includes */ #include \u0026#34;vxWorks.h\u0026#34; #include \u0026#34;stdio.h\u0026#34; #include \u0026#34;stdlib.h\u0026#34; #include \u0026#34;semLib.h\u0026#34; #include \u0026#34;taskLib.h\u0026#34; #define DELAY_TICKS 50 #define STACK_SIZE\t20000 /* run states, provides for shutdown in stages; ensures that no routine tries to take a semaphore that no longer exists */ #define ALL_GO 0\t#define SHUTDOWN 1 #define GATEKEEPER_STOP 2 #define ALL_STOP 3 /* globals */ int tidGatekeeper; int tidSimple; int runState; /* running state of the system */ int count; /* track number of time simple runs */ SEM_ID syncSemId;\t/* Controls when simple can run */ /* forward declarations */ void gatekeeper (void); void simple (void); void progStop (void); /************************************************************************* * * progStart - start the simple program. * * RETURNS: OK */ STATUS progStart (void) { syncSemId = semBCreate (SEM_Q_FIFO, SEM_EMPTY); /* get started */ runState = ALL_GO; tidGatekeeper = taskSpawn (\u0026#34;tGateKeeper\u0026#34;, 200, 0, STACK_SIZE, (FUNCPTR) gatekeeper,0,0,0,0,0,0,0,0,0,0); tidSimple = taskSpawn (\u0026#34;tSimple\u0026#34;, 220, 0, STACK_SIZE, (FUNCPTR) simple,0,0,0,0,0,0,0,0,0,0); return (OK); } /************************************************************************* * * gatekeeper - routine that supplies the semaphore simple task waits on * */ void gatekeeper (void) { while (runState == ALL_GO) { semGive(syncSemId); taskDelay (DELAY_TICKS + (rand() \u0026amp; 0x0f) - 8); } runState = GATEKEEPER_STOP; semGive (syncSemId); } /************************************************************************* * * simple - consume the semaphore and do not do much else * */ void simple (void) { count = 0; while (runState != GATEKEEPER_STOP) { semTake (syncSemId, WAIT_FOREVER);\t/* Wait for signal */ count++; } runState = ALL_STOP; } /************************************************************************* * * progStop - stops the program * * Call this routine to end it all. */ void progStop (void) { runState = SHUTDOWN; /* Wait for everyone to finish up */ while (runState != ALL_STOP) taskDelay (1); /* clean up */ semDelete (syncSemId); printf (\u0026#34;Simple executed %d times.\\n\u0026#34;,count); } /* $Log: simple.c,v $ Revision 1.1 2007-03-12 05:47:46 se463 Set for the first day of class. */ ","date":"2007-12-10","externalUrl":null,"permalink":"/app/introduction-to-vxworks-5.5-programming/","section":"Apps","summary":"\u003c!--# Introduction to VxWorks 5.5 Programming--\u003e\n\u003cp\u003eThis exercise provides a practical refresher on \u003cstrong\u003eVxWorks 5.5 program development\u003c/strong\u003e. You will create a simple project, interact with the target system, and use \u003cstrong\u003eWindView\u003c/strong\u003e to observe and measure real-time performance characteristics.\u003c/p\u003e","title":"Introduction to VxWorks 5.5 Programming","type":"app"},{"content":"","date":"2007-12-10","externalUrl":null,"permalink":"/tags/tornado-2.2/","section":"Tags","summary":"","title":"Tornado 2.2","type":"tags"},{"content":"","date":"2007-12-10","externalUrl":null,"permalink":"/tags/windview/","section":"Tags","summary":"","title":"WindView","type":"tags"},{"content":"","date":"2007-06-30","externalUrl":null,"permalink":"/tags/board-support-package/","section":"Tags","summary":"","title":"Board Support Package","type":"tags"},{"content":" Synergy Microsystems VxWorks BSP Guide for PowerPC CPU Boards\nThe Synergy Microsystems Board Support Package (BSP) provides a production-ready software foundation for a broad range of PowerPC-based VMEbus and CompactPCI processor boards running VxWorks 5.4 with Tornado 2.0. Designed for both single-processor and symmetric multi-processor deployments, the BSP includes hardware abstraction layers, device drivers, boot firmware, and platform-specific utilities required for embedded system development.\nThis guide summarizes installation procedures, supported hardware, multi-processor architecture, memory management, networking, and system configuration, giving developers a practical reference for integrating and deploying Synergy PowerPC platforms.\n🚀 BSP Overview # The BSP supports numerous Synergy Microsystems CPU boards, including the Gemini family, VGM, VGMD, VSS4, KGM5, and related PowerPC platforms.\nKey capabilities include:\nSingle-, dual-, and quad-processor support Ethernet networking PCI and VMEbus interfaces SCSI storage Flash memory support ECC and parity-protected memory Cache management Boot ROM generation Built-in diagnostics This release targets:\nVxWorks 5.4 Tornado 2.0 Document Revision 1.0b (April 6, 2001) 📦 Installing the BSP # Installation differs slightly between Windows and Unix development hosts.\nWindows Installation # Execute the installer directly from the BSP distribution media:\nsetup.exe Install the BSP beneath the Tornado target/ directory.\nUnix Installation # Extract the archive from the target/ directory:\ntar -xf synBSP1_21g.tar After extraction, remove directories corresponding to unsupported board models to reduce workspace size.\nDirectory Layout # Processor-specific directories contain BSP configurations for each CPU instance.\nExamples include:\nsvgm5x/ svgm5y/ kgm5x/ Keep the shared BSP infrastructure intact:\ntarget/config/synergy/ Removing this directory will render the BSP unusable.\nBoot ROM Images # A dedicated bootroms/ directory contains prebuilt bootrom.hex images suitable for programming supported hardware.\n📝 Revision Highlights # The BSP evolved significantly throughout the 1.2/01a–1.2/01h maintenance releases.\nMajor enhancements include:\nEND Ethernet driver as the default network interface Tornado Project support for bootable applications Improved multi-processor memory allocation Altivec support for PowerPC G4 processors External L2 cache support ECC and parity memory support Numerous VME, PCI, Ethernet, and stability fixes Boot ROM Compatibility # Developers should note an important compatibility change introduced in revision 1.21h.\nSingle-processor kernels generally remain backward compatible. Dual- and quad-processor kernels require matching, updated Boot ROM images. Mixing newer SMP kernels with older Boot ROMs is not supported.\n🖥️ Board Organization # The BSP separates shared infrastructure from board-specific configurations.\nCommon code resides within:\nsynergy/ Each processor type has its own configuration directory, allowing multiple hardware variants to share common drivers while maintaining independent initialization logic.\nFor development and testing, dual-processor hardware can also operate in single-processor mode by booting a standard single-processor kernel and Boot ROM.\n⚠️ Known Limitations # Several platform-specific limitations should be considered during development.\nShared Memory # On KGM5 systems using the PReP (Grackle Map A) memory map, the shared-memory (sm) driver may hang.\nUsing the CHRP memory map (Map B) avoids this issue.\nProcessor Restart # Restarting VSS4 systems using Ctrl+X is not always reliable.\nIf processors must be restarted manually, restart the X processor last.\nBuild Warnings # Minor compiler warnings may appear during multi-processor project builds.\nThese warnings are expected and do not affect runtime behavior.\n⚙️ Multi-Processor Architecture # The BSP supports dual- and quad-processor boards by running an independent VxWorks kernel on each processor.\nResource Partitioning # Hardware resources are divided across processors.\nTypical allocation includes:\nPartitioned onboard memory Dedicated serial ports Shared Ethernet controller managed by processor X Shared SCSI controller VME interrupt routing through processor X Flash programming services executed exclusively by processor X Communication between processors is typically implemented using shared memory and mailbox interrupts.\nPerformance Recommendation # All processors should either:\nboot completely, or operate in single-processor mode. Leaving secondary processors inactive while powered can negatively impact system performance.\nException Management # Each processor maintains its own exception table while sharing the primary exception vector located at:\n0x100 This design allows processor-specific exception handling without duplicating the complete vector table.\nSerial Port Allocation # Serial interfaces are divided among processors and can be configured using:\nNUM_TTY System Reset # Supported reset mechanisms include:\nFront-panel reset switches sysReset() 🌐 Ethernet Boot Configuration # Single-processor systems typically boot using the Ethernet interface.\nExample boot parameters:\nboot device : esyf file name : /path/to/vxWorks inet on ethernet (e) : \u0026lt;target IP\u0026gt; host inet (h) : \u0026lt;host IP\u0026gt; The default interface:\nesyf automatically negotiates 10 Mbps or 100 Mbps operation.\nTo force a specific speed:\nesyft — Force 10 Mbps esyfh — Force 100 Mbps The Ethernet MAC address is stored in NVRAM through:\nNV_ENET_ADRS 🔄 Multi-Processor Boot Configuration # Secondary processors boot differently from the anchor processor.\nBoot Device # Processor X boots normally from Ethernet.\nProcessors Y, Z, and W typically boot from shared memory:\nsm=0x4100 or another configured VME shared-memory address.\nProcessor Numbering # Processors are assigned sequential identifiers.\nProcessor Number X 0 Y 1 Z 2 W 3 Only processor 0 requires a standard Ethernet address.\nSecondary processors communicate using backplane networking.\nBoot ROM Configuration # Boot parameters for additional processors can be configured directly from the X processor console using:\ny Equivalent commands exist for Z and W processors.\n🛠️ Tornado Project Integration # The BSP supports both traditional makefile-based development and Tornado Projects.\nTornado Projects # Enable:\nTarget Shell components Downloaded symbol table support This configuration allows applications to be downloaded and debugged through Tornado.\nTraditional Builds # For conventional BSP builds, enable:\nINCLUDE_CONFIGURATION_5_2 inside:\nconfig.h to activate the target shell.\n💾 Memory and ECC Support # ECC and parity initialization occurs during Boot ROM startup when:\nINCLUDE_RAM_PAR_ECC is enabled.\nCapabilities include:\nAutomatic correction of single-bit errors Detection of multi-bit memory faults Machine check exception reporting Although ECC introduces moderate overhead, it substantially improves long-term system reliability.\nHigh-Radiation Applications # For aerospace or industrial environments with elevated radiation exposure, implement a background memory scrubber task that periodically scans RAM.\nThis process proactively corrects recoverable single-bit errors before they accumulate into uncorrectable failures.\n🔌 VMEbus and PCI Support # The BSP provides extensive support for both VMEbus and PCI hardware.\nFeatures include:\nUniverse bridge configuration Direct VME interface PCI auto-configuration PEX3 support Configurable master and slave windows Memory mappings are defined using:\nuMaster[] dMaster[] Address translation APIs include:\nsysBusToLocalAdrs() sysLocalToBusAdrs() along with PCI-specific equivalents.\n⚡ Additional BSP Features # Beyond core processor support, the BSP includes numerous platform services.\nHighlights include:\nInternal and external cache management G4 L2 cache sizing Decrementer-based timestamp support System tick timer Mailbox interrupts NVRAM services Real-time clock and calendar SCSI support Local multi-processor boot capability Built-In Self Test (BIST) PU32 support Front-panel LED diagnostics 🏗️ Building Boot ROMs and Kernels # The BSP supports multiple build workflows.\nTraditional BSP Build # Unix hosts:\nmake Windows hosts use the Standard BSP Build tools provided with Tornado.\nTornado Projects # Bootable applications can also be generated using Tornado BSP Projects.\nFor multi-processor systems, build separate kernel images for each processor:\nX Y Z W The BSP supports both Flash-based Boot ROM deployment and RAM-disk configurations.\n🐞 Troubleshooting # Several utilities are available for diagnosing low-level hardware issues.\nBus Errors and Machine Checks # When machine checks occur, interrupt the shell using:\nCtrl+C For memory probing, read operations are generally safer than writes.\nWhenever possible, use:\nsysVxMemProbe() instead of the standard vxMemProbe() when accessing VME memory, as it provides more reliable behavior across bridge hardware.\nLED Diagnostics # The BSP includes an extensive LED diagnostic system capable of indicating boot progress, processor state, and hardware failures.\nRefer to the original BSP documentation for the complete LED status reference and fault code definitions.\n","date":"2007-06-30","externalUrl":null,"permalink":"/bsp/synergy-microsystems-vxworks-bsp-guide-for-powerpc-cpu-boards/","section":"Bsps","summary":"\u003cblockquote\u003e\n\u003cp\u003eSynergy Microsystems VxWorks BSP Guide for PowerPC CPU Boards\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eThe Synergy Microsystems Board Support Package (BSP) provides a production-ready software foundation for a broad range of PowerPC-based VMEbus and CompactPCI processor boards running \u003cstrong\u003eVxWorks 5.4\u003c/strong\u003e with \u003cstrong\u003eTornado 2.0\u003c/strong\u003e. Designed for both single-processor and symmetric multi-processor deployments, the BSP includes hardware abstraction layers, device drivers, boot firmware, and platform-specific utilities required for embedded system development.\u003c/p\u003e","title":"Synergy Microsystems VxWorks BSP Guide for PowerPC CPU Boards","type":"bsp"},{"content":"","date":"2007-06-30","externalUrl":null,"permalink":"/tags/vmebus/","section":"Tags","summary":"","title":"VMEbus","type":"tags"},{"content":" VxWorks 6.0 Beta: A Milestone in Embedded Software Development\nThe release of the VxWorks 6.0 Beta marked a significant evolution in Wind River\u0026rsquo;s embedded software portfolio. More than a routine operating system update, VxWorks 6.0 introduced a modern development platform that emphasized software modularity, application isolation, integrated development tools, and improved productivity for embedded engineers.\nBy making the beta version publicly available ahead of its official release, Wind River enabled developers and technology partners to evaluate the platform, explore its new capabilities, and begin preparing applications for the next generation of embedded systems.\n🚀 Introducing the VxWorks 6.0 Universal Platform # VxWorks 6.0 represented a major architectural advancement over previous releases, delivering a more scalable and secure real-time operating system while introducing a unified development experience.\nThe beta program allowed developers to:\nEvaluate new operating system capabilities Adopt updated design methodologies Test application compatibility Prepare migration strategies before the commercial release This early access helped reduce adoption barriers and provided valuable feedback that contributed to the platform\u0026rsquo;s final release.\n🔒 Enhanced Application Protection # One of the most significant enhancements in VxWorks 6.0 was the introduction of Memory Management Unit (MMU)-based memory protection.\nEarlier embedded systems often relied on applications sharing a single memory space. While this approach minimized overhead, it also increased the risk that a software defect in one component could compromise the stability of the entire system.\nVxWorks 6.0 addressed this challenge by incorporating memory protection mechanisms that enabled stronger isolation between applications and the operating system.\nKey benefits included:\nImproved application reliability Isolation of software faults Enhanced system stability Better protection against unintended memory access Increased suitability for safety-critical applications This architectural improvement laid the foundation for building more robust and maintainable embedded software.\n💻 Unified Development with Wind River Workbench # Another major innovation introduced alongside VxWorks 6.0 was tighter integration with Wind River Workbench, the company\u0026rsquo;s Eclipse-based Integrated Development Environment (IDE).\nWorkbench provided a unified development environment capable of supporting multiple operating systems, including:\nVxWorks 6.0 Linux Additional embedded platforms Rather than maintaining separate development environments for different targets, engineering teams could manage projects from a single workspace.\nWorkbench offered capabilities such as:\nIntegrated project management Source-level debugging Build automation Cross-platform development Unified toolchain integration This streamlined workflow simplified development across heterogeneous embedded systems and reduced the complexity of multi-platform projects.\n⚙️ Improving Development Efficiency # Beyond new technical capabilities, VxWorks 6.0 focused heavily on improving the overall software development lifecycle.\nWind River designed the platform to help organizations:\nShorten development cycles Accelerate product releases Reduce engineering costs Lower project risk Improve software quality These objectives reflected the growing complexity of embedded applications, where increasing functionality demanded more efficient development processes and stronger software engineering practices.\n🤝 Building an Integrated Embedded Ecosystem # A key aspect of the VxWorks 6.0 strategy was close collaboration with technology partners.\nRather than delivering only an operating system, Wind River worked with hardware vendors, middleware providers, and ecosystem partners to create highly integrated software platforms capable of supporting next-generation embedded devices.\nThis collaborative approach enabled developers to spend less time integrating foundational software components and more time building application-specific functionality.\nThe result was a more complete development ecosystem that simplified system integration and accelerated product development.\n📢 Wind River\u0026rsquo;s Vision # During the beta announcement, Wind River highlighted its commitment to helping customers reduce development complexity while accelerating time-to-market.\nJohn Bruggeman, who served as the company\u0026rsquo;s Chief Marketing Officer at the time, emphasized that the integrated platform strategy would enable development teams to launch products more quickly while minimizing technical and project risks.\nThis vision anticipated many of the software engineering principles that later became standard across the embedded industry, including integrated toolchains, reusable software platforms, and collaborative development ecosystems.\n📈 Lasting Impact of VxWorks 6.0 # Although VxWorks has continued to evolve significantly since the introduction of version 6.0, the beta release represented an important turning point in the platform\u0026rsquo;s history.\nSeveral innovations introduced during this release—including MMU-based memory protection, unified development tools, and an emphasis on integrated software platforms—became foundational technologies for subsequent VxWorks versions.\nThese capabilities also reflected broader trends in embedded software development, where security, reliability, modularity, and developer productivity became increasingly important as embedded systems grew more sophisticated.\nToday, many of the design principles introduced with VxWorks 6.0 continue to influence modern embedded operating systems, making the release a notable milestone in the evolution of commercial real-time operating systems.\n","date":"2004-10-04","externalUrl":null,"permalink":"/news/vxworks-6.0-beta-a-milestone-in-embedded-software-development/","section":"News","summary":"\u003cblockquote\u003e\n\u003cp\u003eVxWorks 6.0 Beta: A Milestone in Embedded Software Development\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003eThe release of the \u003cstrong\u003eVxWorks 6.0 Beta\u003c/strong\u003e marked a significant evolution in Wind River\u0026rsquo;s embedded software portfolio. More than a routine operating system update, VxWorks 6.0 introduced a modern development platform that emphasized software modularity, application isolation, integrated development tools, and improved productivity for embedded engineers.\u003c/p\u003e","title":"VxWorks 6.0 Beta: A Milestone in Embedded Software Development","type":"news"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"}]