Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
Developing a Dual-Motor EV Control System with Model-Based Design Toolbox 1 Introduction This article series presents the Motor Control System (MCS) within an electric vehicle (EV) architecture. It introduces the end-to-end development flow, from controller and plant modeling to simulation, code generation, hardware deployment, and integration with the rest of the vehicle network. This opening article establishes the technical foundation for a series focused on the architecture, implementation, and integration of a dual-motor control system for EV traction applications. The series also shows how MathWorks tools can be used together with NXP software and hardware to support a Model-Based Design workflow. This approach helps engineers develop, verify, and deploy motor control applications more efficiently while maintaining traceability across the development cycle. RoleOfMCS.jpg Figure 1-1. Role of the Motor Control System within the EV traction domain 2 Table of Contents • Introduction • Overview • Context • References • Conclusion 3 Overview 3.1. What will this series of articles cover? The articles in this series define the development roadmap for the Motor Control System within a broader EV architecture. The series covers the following topics: Software and Hardware Environment - Overview of the MathWorks and NXP tools used to develop, test, and validate a dual-motor control system. Architecture and Model Description - Description of the model architecture, signal interfaces, and core control algorithms implemented in the Motor Control System. Model-in-the-Loop Development - Simulation of the controller and plant in Simulink to validate algorithms before code generation. Software-in-the-Loop Validation - Code generation for the validated controller and comparison of the generated software against the Model-in-the-Loop baseline. Processor-in-the-Loop Validation - Execution of the controller on NXP hardware while the plant remains simulated on the host system. Deployment and Validation on Real Hardware - Integration with physical hardware, scaling from single-motor to dual-motor operation, and configuration of the NXP MCU peripherals required for motor control. CAN Integration - Definition of the CAN communication interface, including database design and integration on the target NXP platform. Results and System Validation - Presentation of the final implementation results and validation of the complete system behavior. 3.2. What is the Motor Control System? Electric vehicles depend on traction systems that deliver efficient propulsion, accurate torque control, and safe operation. At the center of this functionality is the Motor Control System (MCS), which combines real-time control software, power electronics, sensing, actuation, and communication interfaces into a tightly coordinated embedded system. PMSM.jpg Figure 3-1. PMSM motor and controller as core elements of the traction system In modern EVs, the traction system delivers the torque and power needed to propel the vehicle. It is typically composed of the following elements: Electric motor - converts electrical energy from the battery into mechanical power at the wheels. Inverter system - converts DC energy from the battery into the controlled AC waveforms required by the motor. Transmission system - transfers the generated torque from the motor to the wheels. At its core, the Motor Control System regulates motor torque, speed, and position by controlling the voltage and current applied to the motor phases. A typical MCS includes the following functional layers: Control Algorithm - implements torque and current control strategies such as Field-Oriented Control (FOC). Sensing and Feedback - measures motor currents, voltages, rotor position, and temperature. Power Electronics - inverter circuitry that switches DC power into AC waveforms for motor drive. Embedded Processor - microcontroller executing real-time control loops. Communication Interfaces - CAN, LIN, or Ethernet for integration with other system modules. Together, these layers form a closed-loop control system that operates at high switching frequencies and under strict real-time constraints. FOC.png Figure 3-2. Field-Oriented Control (FOC) architecture EV traction systems can be implemented using different architectures depending on the required balance of efficiency, performance, cost, and system complexity. A single-motor architecture uses one traction motor to drive either the front or rear axle. This approach reduces hardware complexity and cost, and it often improves vehicle range because of lower mass and lower overall energy consumption. A dual-motor architecture uses two independent traction machines that can be arranged in several drivetrain topologies. This configuration enables higher total power, better traction, improved vehicle dynamics, and stronger acceleration. The tradeoff is increased electrical and mechanical complexity, together with higher system cost. DualMotor.png Figure 3-3. Example dual-motor traction architecture Advantages & Disadvantages of Dual Motor: Acceleration faster due to torque from both motors Superior traction and handling, especially in snow, rain or off-road conditions Slightly lower range due to increased weight and power consumption More expensive but can include AWD and performance benefits Advantages & Disadvantages of Single Motor: Slightly better range due to less energy consumption More affordable Moderate traction, suitable for most road conditions Slower acceleration Note: The example used throughout this series is based on a dual-motor rear-axle architecture, where each rear wheel is driven by its own motor. 3.3. Target Audience This series is intended for engineers and technical stakeholders involved in the development, integration, and evaluation of electric drive systems, including the following audiences: Embedded Software Engineers Motor Control & Power Electronics Engineers System Architects & Vehicle Architecture Engineers Hardware Engineers Model-Based Design and Simulink Developers Academic and Research Communities 4 Context In the electric vehicle architecture presented in this series, the Motor Control System is located in the rear zone of the vehicle. Each rear wheel is driven by an independent Permanent Magnet Synchronous Motor (PMSM). The Motor Control System ECU coordinates both motors and exchanges real-time data with the rest of the vehicle over the CAN network. DemoArch.png Figure 4-1. Motor Control System highlighted within the EV architecture The traction ECU is built around NXP's S32K396 microcontroller, which supports both single 6-phase motor control and dual 3-phase motor configurations. The inverter stage is driven by the MC33937 pre-driver, which provides three high-side and three low-side FET pre-drivers for automotive motor control applications. Note: The inverter receives DC power from the vehicle battery, while battery operation and safety are supervised by the Battery Management System. The Motor Control System communicates over CAN with the Zone Node controller, which in turn exchanges commands and status information with the main vehicle control node responsible for speed and torque requests. 5 References PMSM Control Workshop BLDC Control Workshop A Model-Based Design (MBDT) Environment for Motor Control Algorithm Development Deploy Motor Control Algorithms on NXP S32K3 from Simulink Motor Control Rapid Prototyping on NXP S32M2 with MathWorks and Model-Based Design Toolbox Next Generation of NXP EV Traction Inverter with S32K39 MCU and FS26 SBC AN14326: 3-phase Motor Control Kit with S32K396 Application Note AN13884: 3-phase Sensorless PMSM Motor Control Kit with S32K344 using RTD AUTOSAR API Application Note Advancing Motor Control Performance with Digital Twins Extended Range Dual-Motor Electric Vehicle Model 6 Conclusion This article introduced the Motor Control System within an EV architecture and established the technical context for the rest of the series. It explained the role of the Motor Control System, compared single-motor and dual-motor traction topologies, and outlined how a Model-Based Design workflow can be applied using MathWorks tools together with NXP software and hardware. The next article will focus on the software and hardware environment required to develop, simulate, and deploy the Motor Control System using MathWorks and NXP solutions.
View full article
Automotive Lighting Control Using FRDM-A-S32K3XX Microcontrollers 1. Overview This module demonstrates how to implement a vehicle lighting control system using analog input acquisition and FlexIO-based LED driving on NXP S32K3 microcontrollers. The application reads analog inputs from the Analog Key Click module (six push-buttons, each generating a distinct voltage level) and converts them into commands that drive a 4x4 RGB LED matrix. Each button press activates a specific lighting function — low beam, high beam, turn signals, brake lights, or hazard lights — while safety interlocks and blinking patterns run continuously in the background, mimicking how a real automotive Body Control Module (BCM) manages vehicle lighting. This example is based on Application Code Hub demonstrations for: Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K344 Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K312 In this workshop, the Analog Key Click simulates six vehicle lighting controls. When the student presses a button, an analog voltage proportional to the pressed key is read by the MCU through the ADC (with software debouncing), decoded into a specific lighting command, and translated into an RGB pattern generated by the FlexIO peripheral. The 4x4 RGB Click then displays the corresponding automotive lighting behavior in real time — warm white for low beams, cool white for high beams, blinking amber for turn signals and hazards, and red for brake lights. Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. 2. Learning Scope After completing this course, participants should be able to:   Understand a basic vehicle lighting control system and the ideas behind an automotive Body Control Module (BCM). Use the Analog Key Click as a simulated multi-button user interface (six inputs on a single analog line). Acquire analog values (0–3.3 V) using the ADC and understand how multiple buttons share one channel through voltage division. Perform software debouncing and decode which button was pressed based on ADC value ranges. Drive an RGB LED matrix using the FlexIO peripheral, generating precise timing for WS2812-style LEDs. Implement safety interlocks between lighting functions (e.g., high beam requires low beam ON). Implement continuous background patterns such as blinking turn signals and synchronized hazards. Recognize the actuation data flow: analog input → ADC → command decoding → FlexIO LED output. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why lighting functions are relevant for automotive safety and driver visibility. 3. System Architecture The three elements capture exactly the basic idea of the system in the demo: Input: Analog Key Click (six buttons T1–T6, each generating a distinct analog voltage level) Processing: S32K3 MCU (reads the ADC, decodes the button, applies BCM logic, updates the LED state) Output: 4x4 RGB Click (16-LED matrix driven by FlexIO to display lighting patterns) This matches the classic flow of an embedded body-control system: sensor → processing → actuator. Functional Flow The system operates continuously as follows: The user presses a button on the Analog Key Click (T1–T6) Each button generates a distinct analog voltage on the shared output line The ADC samples the voltage and converts it into a digital value The application decodes which button was pressed (with debouncing) The BCM logic applies interlocks and dependencies (e.g., high beam requires low beam) The FlexIO peripheral drives the RGB Click LEDs with the corresponding color pattern This loop runs continuously to ensure real-time lighting control, with blinking patterns and safety interlocks maintained in the background. System_Architecture_Lights.pngVehicle Lighting Control Application Architecture  4. Key Concepts 4.1 ADC (Analog-to-Digital Converter) The Analog Key Click outputs 0–3.3 V on a single analog line, with each button generating a specific voltage step. The ADC samples this voltage on ADC0_P0 (pin PTD1) at regular intervals and quantizes it into a digital code (a 12-bit ADC produces values between 0 and 4095). Each button corresponds to a specific value range, allowing six digital inputs to be read through a single ADC channel. ADC acquisition is the foundation of automotive sensing — used for switches, buttons, sensors, and many others. 4.2 Analog Multi-Button Decoding Instead of using six separate GPIO pins, the Analog Key Click uses a resistor ladder that produces a different voltage for each button press. The application performs software debouncing (multiple ADC samples must agree before a press is confirmed) and then compares the ADC value against predefined thresholds to identify which button (T1–T6) was pressed. This technique is common in automotive steering-wheel controls, where many buttons share a single analog line to save wiring and pins. 4.3 FlexIO — Driving the RGB Click LEDs FlexIO is a highly flexible peripheral on S32K3 that can emulate serial protocols like WS2812/NeoPixel. The RGB Click uses individually addressable LEDs that require precise timing (~800 kHz with strict pulse widths). FlexIO on PTA13 (FlexIO_D8) generates this waveform in hardware, without loading the CPU. Each of the 16 LEDs receives its color data through a serial stream, allowing independent control of color and brightness per LED. 4.4 RGB LED Mapping and Lighting Zones The 16 LEDs of the RGB Click are logically grouped into automotive lighting zones: LEDs 13, 14 → Low Beam Headlights (warm white) LEDs 8, 9, 10, 11 → High Beam Headlights (cool white) LEDs 0, 12 → Left Turn Signal (blinking amber) LEDs 3, 15 → Right Turn Signal (blinking amber) LEDs 1, 2, 5, 6 → Brake Lights (red) LEDs 0, 3, 12, 15 → Hazard Lights (synchronized blinking amber) 4.5 BCM Safety Interlocks and State Dependencies The application implements safety logic typical of a real Body Control Module: high beam can only be activated when low beam is already ON; turning OFF the low beam automatically disables the high beam; hazard lights synchronize left and right turn signals simultaneously; high beam state is preserved during hazard blinking and restored between cycles. These interlocks illustrate how real automotive lighting logic prevents unsafe combinations and preserves driver intent. 4.6 Data Flow at a Glance Button press → analog voltage on shared line → ADC sample → software debouncing → button decoding → BCM logic (interlocks + dependencies) → FlexIO WS2812 output stream → RGB LED color update. This direct chain from the student's finger to the LEDs is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K312 FRDM-A-S32K312.png Alternative MCU platform used to run the lighting application and process user inputs. FRDM-A-S32K344 S32K344MINI-EVB.png Alternative MCU platform used to run the lighting application and control connected peripherals. FRDM-K64 Click Shield frdm-k64-click.jpg mikroBUS expansion board used to connect Click modules to the FRDM platform. Analog Key Click analog-click.jpg Six-button analog module used to simulate the vehicle lighting controls (headlights, indicators, brakes, hazards). 4x4 RGB Click 4x4-rgb-click.jpg 16-LED RGB matrix used to display the automotive lighting patterns in real time. USB-C / 12 V supply — Provides power and enables programming and debugging of the system through a single USB-C connection. The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate a complete vehicle lighting control system. Vehicle Lighting Control on FRDM-A-S32K312 Vehicle Lighting Control on FRDM-A-S32K344 Lights_k312.png Lights_k344.png Software Environment S32 Design Studio IDE S32K3 Automotive Software Package Application Code Hub project import Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K344 Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K312 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio 3.6.5 Select “Import project from Application Code Hub” Search for “Lighting” Select the desired project for your FRDM board Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB-C cable (and 12 V supply for FRDM-A-S32K312) Attach FRDM-K64 Click Shield, Analog Key Click and 4x4 RGB Click Verify wiring on PTA13 (FlexIO) and PTD1 (ADC) Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously; LEDs perform startup test sequence 5 Functional Validation Press buttons T1–T6 on the Analog Key Click Observe corresponding LED patterns on the RGB Click Verify safety interlocks (high beam requires low beam) Verify continuous blinking on turn signals and hazards RGB LEDs display the correct automotive lighting patterns for each button 7. Signal Behavior and Control Logic   The following diagram illustrates how each user input on the Analog Key Click is mapped to a specific lighting function and to the individual LEDs of the 4×4 RGB Click matrix. Each button (T1–T6) triggers a unique combination of LEDs, colors, and patterns, reproducing the behavior of a simplified automotive lighting system.   Led_Matrix_Mapping.png  The MCU continuously monitors the analog input from the Analog Key Click and decodes which button is pressed. Based on the detected input, the application activates the corresponding lighting function by driving the assigned LEDs on the 4×4 RGB Click through the FlexIO serial interface. Steady functions (Low Beam, High Beam, Brake) keep the associated LEDs constantly ON, while directional functions (Left Turn, Right Turn, Hazard) toggle the LEDs at approximately 1 Hz to reproduce the blinking behavior of real vehicle indicators. Additional control rules — such as High Beam requiring Low Beam to be active, or Hazard Lights preserving and restoring the High Beam state — reflect the interdependencies found in a real automotive body control module. 8. Troubleshooting Issue Possible Actions Board Not Detected Check USB-C cable and drivers Verify debugger connection Restart IDE No LEDs Lighting Up Verify FlexIO configuration on PTA13 Check 3.3 V and GND wiring on RGB Click Confirm data-line wiring to IN1 Buttons Not Detected Verify ADC0_P0 configuration on PTD1 Check 3.3 V and GND wiring on Analog Key Click Confirm software debouncing thresholds Wrong Button Triggered Recalibrate ADC value ranges for each button Verify power supply stability (3.3 V) Check for noise on the analog line Incorrect LED Colors or Timing Verify FlexIO clock configuration (WS2812 timing) Check LED index → color mapping in code Ensure RGB order (GRB vs. RGB) matches the LED type High Beam Not Activating Ensure low beam (T1) is ON first — BCM interlock Check application logic for beam dependencies 9. Extending the Application The basic implementation can be extended in several ways: Additional Lighting Functions Add fog lights, parking lights, or daytime running lights (DRL) Simulate reverse lights that activate when a specific input is triggered Adaptive Front Lighting Integrate a steering angle input (e.g., POT Click) to swivel the headlights Simulate cornering lights that turn on when indicators are active Ambient Light Sensing Add a light sensor to automatically enable low beams at dusk Implement smooth dimming between day and night modes Brake Light Enhancements Add an emergency brake flashing pattern for hard braking Implement a third brake light (single LED, always ON with brakes) CAN Communication Enable communication with other vehicle ECUs (e.g., BCM master, doors) Receive lighting commands over the vehicle network State Machine Implementation A more advanced approach is to implement a formal state machine covering: Off DRL / Parking Low Beam High Beam Hazard / Fault 10. Safety Context This example reflects key automotive principles: Continuous monitoring of driver input Immediate response to control signals Reliable actuator (LED) control with predictable timing Safety interlocks between lighting functions (high beam requires low beam) In real systems: Redundancy is required for safety-relevant functions (e.g., brake lights, hazards) Fault detection mechanisms are implemented (open lamp, short circuit, overcurrent) Systems must comply with ISO 26262 (functional safety standard) Vehicle lighting is one of the most safety-critical automotive functions because it directly affects driver visibility and vehicle conspicuity. Modern Body Control Modules implement extensive diagnostics, backup lighting strategies, and fail-safe defaults (e.g., hazard lights activated on power-loss recovery). 11. Conclusion This module demonstrates how a simple embedded system can implement complete vehicle lighting control using ADC input and FlexIO output on the S32K3 platform. It shows how: Multiple digital inputs can share a single analog line through resistor-ladder decoding Analog data is acquired, debounced and processed in real time Complex automotive lighting patterns are controlled through FlexIO-driven WS2812 LEDs Safety interlocks and background blinking patterns are managed by BCM-style logic Result on FRDM-A-S32K312 Result on FRDM-A-S32K344 FRDM-A-S32K312FRDM-A-S32K312 FRDM-A-S32K344FRDM-A-S32K344 The course provides a strong foundation for more advanced systems, including adaptive lighting, CAN networking, ambient sensing, and safety-oriented designs typical of automotive body-control modules.
View full article
找不到 FRDM MCX A266 的引脚配置工具 找不到现场引脚配置工具。 FRDM 培训 Re: Can't find pin configuration tool for FRDM MCX A266 你好, 如果您是该工具的初学者,以下信息或许对您有所帮助。 MCUXpresso 配置工具的快速入门指南 MCUXpresso 配置工具用户指南(IDE) 如果您需要查找某些信息或工具,与我们联系。 此致敬礼,路易斯 Re: Can't find pin configuration tool for FRDM MCX A266 找到https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-config-tools-pins-clocks-and-peripherals:MCUXpresso-Config-Tools Re: Can't find pin configuration tool for FRDM MCX A266 感谢您的回复。 如果可以的话,请您提供这些工具的逐步配置示例,我将不胜感激。 Re: Can't find pin configuration tool for FRDM MCX A266 你好, 这取决于您想要达成的目标,如果您能确认或描述一下您需要协助完成哪个流程,那就太好了。 此外, MCUXpresso 配置工具用户指南(IDE)第 3 章是引脚配置说明,其中包含步骤和照片,可引导您了解工具功能并匹配您的配置。 此致敬礼,路易斯 Re: Can't find pin configuration tool for FRDM MCX A266 好的,谢谢。我现在想做的是一件很简单的事。 定义 4 个 DAC 通道和 4 个 ADC 通道。 将它们内部路由到 4 个 ADC 通道,以形成闭合回路。 测试这些信号是否到达,然后乘以输入的数量。 再次乘以该数并衡量其性能。 定义通过 USB 串口输出日志信息的功能,用于调试和结果展示。
View full article
FRDM i.MX 93 Hi. I am interested in use the FRDM i.MX 93 in a project where I need Linux operating system, and control other devices by RS232, SPI and I2C ports. I see that there is an UART port used to USB debug, there are another UART port, I2C and SPI ports that I can use?   Re: FRDM i.MX 93 Hi @alberto83  Yes, the IMX93 has 8 UART interfaces, 8 I²C interfaces, and 8 SPI interfaces available. For more information, you can refer to the following link about imx93 FRDM: https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX93 B.R
View full article
Solyball Cooling Ace Designed for Modern Living Solyball When temperatures begin to rise, maintaining a comfortable indoor environment becomes a priority for many people. Whether at home, in the office, or in a personal workspace, excessive warmth can affect concentration, relaxation, and overall comfort. This is where Solyball offers a convenient and practical solution. Designed with portability, simplicity, and modern living in mind, Solyball is a compact cooling device that helps users create a more pleasant atmosphere in a variety of indoor settings. One of the most notable features of Solyball is its lightweight and portable design. Unlike large cooling systems that can be difficult to move or require significant space, Solyball is compact enough to fit comfortably in almost any room. Its portable nature allows users to carry it from one location to another with ease, making it suitable for use throughout the day as needs change. Whether you are working in a home office, relaxing in the living room, or preparing for a restful night's sleep, Solyball can be positioned wherever additional comfort is desired. The versatility of Solyball makes it a valuable addition to many different indoor environments. In bedrooms, it can help create a more enjoyable atmosphere during warm evenings. Comfortable sleeping conditions are important for overall well-being, and a compact cooling device can contribute to a more pleasant bedtime experience. Solyball's convenient size allows it to fit neatly on a bedside table or nearby surface without creating clutter. For professionals and remote workers, Solyball maintaining a comfortable workspace can be essential for productivity. Warm indoor temperatures may sometimes make it difficult to stay focused on tasks and responsibilities. Solyball offers a practical way to improve comfort while working, helping users create a more pleasant environment throughout the day. Its compact footprint means it can sit conveniently on a desk or workstation without occupying excessive space. Solyball Living rooms and shared family spaces can also benefit from the convenience of Solyball. These areas often serve as central gathering points where people spend time watching television, reading, socializing, or simply relaxing. By incorporating Solyball into these spaces, users can enjoy a more comfortable atmosphere while going about their daily activities. Its modern appearance ensures that it blends naturally with contemporary home décor.
View full article
RT1189 - 2 octal 166MHz HyperRAMs on SPI1 to create 16-bit wide bus? The RT1180 RM shows a Parallel FlexSPI configuration wherein two octal HyperBus memories on SPI1 to A_D7..0 and B_D7..0 to form a 16 bit wide bus.  See pages 2243 & 2244, Table 196, 6th row down which is the only entry where Effective Bus Size is listed as 16bit.  If this actually works, the max data transfer rate should be 166 MHz x 2 bytes x 2 transfers per clock period = 644 MB/s. Has anyone tried this configuration? If yes, does it work and what was the actual performance? Thanks! Re: RT1189 - 2 octal 166MHz HyperRAMs on SPI1 to create 16-bit wide bus? Hi @DoubleD , Thanks for your interest in NXP MIMXRT series! RM lists the 2×8b parallel connection mode for FLEXSPI1, but no verified RT1180 dual-HyperRAM 16-bit parallel example/benchmark was found in public resources like SDK demos or ANSW. And theoretical raw line rate is 664 MB/s, but it must not be used as guaranteed bandwidth. This use case may require users to test it on a custom board. We apologize for any inconvenience this may cause at this stage. Best regards, Gavin Re: RT1189 - 2 octal 166MHz HyperRAMs on SPI1 to create 16-bit wide bus? Update: The previous reply based on the description in RM. Afterward, I reconfirmed this with internal team of experts, and the conclusion is as follows: 1. FlexSPI1 supports this connection method; 2. However, performance cannot reach the theoretical upper limit. It is only about 20% to 30% faster than a single-chip HyperRAM. Best regards, Gavin
View full article
S32K342、HSE、設置に関する問題 S32K342カスタムボード + PEmicro。S32K344_HSE_FW_INSTALL サンプルを S32K342 に移植しました。ビルドは正常に完了し、S32K342.mac のリセットも完了しますが、 main に到達する前にコードが Default_Handler (BusFault/HardFault) にトラップされ、起動時に失敗します。ピンクは0.13.0_2.40.0 FULL_MEMです。S32K342では、どのようなスタートアップ/リンカーの変更が必要ですか? Re: S32K342, HSE , installation issues 最近似たような問題に直面したので、使用済みのライブラリ(セミホスティングなど)が原因かもしれません。newlib_nano を選択してください(I/O なし) davidtosenovjan_0-1782385593580.png それ以外の場合、S32K344_HSE_FW_INSTALLを別の派生製品に移植するのは非常に簡単です。S32K342のスタートアップコードとレジスタ定義を使用する必要があります。
View full article
Default workspace Hello, I'm using MCUXpressoIDE v.24.9.25 (I know I could run a newer version, but for some reasons, I need to run 24.9.25). As I can see in "C:\NXP\MCUXpressoIDE_24.9.25\ide\configuration\config.ini", osgi.instance.area.default is "@user.home/Documents/MCUXpressoIDE_24.9.25/workspace", so it's correct. However, if I close Windows user session and open a new one with other user, when I run MCUXpressoIDE, the default workspace is the workspace of the first user, so I need to change to the second workspace directory because each user have their own directory. It seems that osgi.instance.area.default is not working fine, because @user.home/Documents/MCUXpressoIDE_24.9.25/workspace should be the home of each user, but always takes the first login user. How could I reconfigure this? Thanks. #mcux Re: Default workspace Hello, Could you help us confirm if you have the cell "Use this as the default and do not ask again" enable?  If you tick the Use this as the default and do not ask again option, then MCUXpresso IDE always starts up with the chosen workspace opened; I would recommend on not having this box checked to select the Workspace luis_maravilla_2-1782415167728.png You could add the other workspace for User 2 and keep it in Recent workspaces, so you can select your desired workspace before the app open Also, In Tab Window> Preferences> General>Startup and Shutdown>Workspaces Enable the Prompt for workspace on startup. luis_maravilla_3-1782415196345.png Best Regards, Luis
View full article
Ezurio Sona NX611 support in MCUXpresso SDK Hello, Is Ezurio Sona NX611 wireless card supported in MCUXpresso SDK FreeRTOS? As it's using base NXP IW611 radio, I think it should be supported, right? Re: Ezurio Sona NX611 support in MCUXpresso SDK Hello, Hope you are doing well. I would recommend checking directly on the configuration of any of our SDK examples, the supported modules. For example, in the wifi_cli for iMX RT1170, you can find these modules:   Ricardo_Zamora_1-1782508762868.png If you are looking for any other module, you would need to add the specific support at your own, taking as a base the available enablement for IW61x. Best Regards, Ricardo Re: Ezurio Sona NX611 support in MCUXpresso SDK Thank you. How do I add the specific support for the module? I see there are specific settings for each module in mcuxsdk/components/wifi_bt_module/ /tx_pwr_limits . Also there are multiple calibration data headers in mcuxsdk/middleware/wifi_nxp/incl/, for example, wifi_cal_data_override.h which has the following text: "Customer can override the data of ext_cal_data[] to set specific antenna calibration data". How do I set these (power limits and calibration data) correctly for a new module? Is there a comprehensive manual for adding support for a new wireless module? Mine is based on IW611, so I guess I can take NXP IW611-MURATA-2DL-M2 as a reference but how do I know if I need to change any values?   Re: Ezurio Sona NX611 support in MCUXpresso SDK Thank you @Ricardo_Zamora . I selected NXP-IW611-MURATA-2DL-M2 card, as Ezurio Sona NX611 uses the same chip (IW611) and I thought it should work. However, when the SDK code tries to download the firmware to the wireless card, I get: 09/07/2026 13:04:32.589 [RX] - [FW Download] Start to download firmware from 0x60143230: 727 09/07/2026 13:04:38.560 [RX] - [wifi_io] Error: SDIO - FW Ready Registers not set [wifi] Error: sd_wifi_init failed. status code -1 [wlcm] Error: wifi init/reinit failed. status code -1 [!] WPL_Init: Failed, error: 1 I understand that Sona NX611 is not in the list of supported modules but I had the impression that it should still work given that it shares the wireless chip model, IW611, with one of the supported boards. Re: Ezurio Sona NX611 support in MCUXpresso SDK Hello, I would recommend going with Ezurio for specific support for their module. Implementation may vary from module partners. Regards, Ricardo
View full article
S32k322 ADC Configuration Issue I am using three ADC channel is configured for current sensing using BCTU interrupt(CTU mode is configured to trigger mode) and remaining ADC channels are configured in Normal chain method for voltage and temperature sensing. During this configuration voltage and temperature sensing is working as expected but current sensor is sensing raw values with noise so we are getting abnormal spike in current control. Also we have changed the Ctu mode from trigger to control mode ,in current sensor channel raw value noise is reduced. But other channel configured in normal channel were not working. Our expectation is to work with single ADC peripheral(ADC0) in current sensing using BCTU trigger as well as voltage and temperature sensing in normal chain method without any spike. Note: Our hardware is designed with configuration (i.e Current sensor channels is configuration is as follows, P7-ADC0,P2 and P3 -ADC1 for reading in BCTU method. Followed by remaining ADC channels configured to normal chain method(ADC0 - X0,X1,S19 and ADC1-P0,P2,P3,P1,S10) ADC_Data1.png ADC_Data2.png Screenshot 2026-06-25 191818.png S32 SDK for S32K1 S32 SDK for S32V Re: S32k322 ADC Configuration Issue Hi@praveen_ext I believe this is the exact same issue you're facing. https://community.nxp.com/t5/S32K/Difference-in-ADC-noise-between-BCTU-Control-Mode-and-Trigger/td-p/2384122 From the screenshot you provided, it seems you haven't made any changes to my previous reply. Senlent_0-1782438264318.png I've already informed you that there's a problem with your ADC clock divider configuration, Also, are you sure your external clock is 25MHz? If you've checked these two points and the problem persists after testing, you can try modifying the ADC channel's sampling time. Senlent_1-1782438511587.png This option allows you to modify the sampling time; you can try increasing the sampling time and testing again. Re: S32k322 ADC Configuration Issue Hi @Senlent , I have also same issue which you mentioned above. Our external oscillator clock is 25 MHz. According to the S32K322 datasheet, the ADC supports up to 80 MHz, so I have configured a prescaler of 2. I also configured the sampling time to 1.2 microseconds and set the BCTU mode to trigger mode. However, we are still getting noisy data when executing the BCTU method and the normal chain method simultaneously on the same ADC0 peripheral. Is there a workaround or an alternative method to safely run both on the same ADC0 peripheral? praveen_ext_0-1782473167287.png praveen_ext_1-1782473350906.png praveen_ext_2-1782473423830.png Re: S32k322 ADC Configuration Issue Hi@praveen_ext Aren't you the same company? You're asking the exact same questions. https://community.nxp.com/t5/S32K/Difference-in-ADC-noise-between-BCTU-Control-Mode-and-Trigger/m-p/2384122#M59412 It seems you haven't been reading my answer carefully. This is the third time I've told you that your clock divider settings are incorrect. For 160MHz, you need to set them to 2 and 4. Senlent_0-1782897219790.png Re: S32k322 ADC Configuration Issue Hi @Senlent , I have also same issue which you mentioned above. Our external oscillator clock is 25 MHz. According to the S32K322 datasheet, the ADC supports up to 80 MHz, so I have configured a prescaler of 2. I also configured the sampling time to 1.2 microseconds and set the BCTU mode to trigger mode. However, we are still getting noisy data when executing the BCTU method and the normal chain method simultaneously on the same ADC0 peripheral. Is there a workaround or an alternative method to safely run both on the same ADC0 peripheral? In the meantime, I reduced the Instance 1 clock frequency to 40 MHz and configured the sampling time to 1.2 microseconds. Following these changes, the measured values from the BCTU are no longer showing noise. Adc_Raw_Val_Ph3 connceted with sensor remainig two values in floating. RwaeVal - configured normal chain praveen_ext_0-1782473167287.png praveen_ext_1-1782473350906.png praveen_ext_2-1782473423830.png praveen_ext_2-1782896838602.png praveen_ext_5-1782896882736.png praveen_ext_6-1782896898785.png Re: S32k322 ADC Configuration Issue Hi @Senlent , We tested the previous suggestions, but the issue is still not resolved. After further configuration and verification, I have attached the updated test data and configuration images below. kindly assist us where we missed. praveen_ext_0-1782975094933.png ADC0 praveen_ext_1-1782975139376.png praveen_ext_2-1782975176694.png ADC1 praveen_ext_3-1782975241134.png praveen_ext_4-1782975291742.png Re: S32k322 ADC Configuration Issue Hi@praveen_ext Share your project and i will test it on myside,
View full article
ディスプレイのタッチ入力がプライマリディスプレイに正しくマッピングされていません 私たちは、LVDSからHDMIへのアダプターカードを使って、i.MX 8 QuadMax MEK CPUボードのプライマリディスプレイで2台のディスプレイを設定し、タッチを有効にしようとしています。タッチ入力にはUSB Type-Cコネクタ(J17)を使用しています。 以下に、我々が得た観察結果を示します。 タッチ入力をプライマリディスプレイに接続しても、入力は認識されるものの、マッピングされません。しかし、それをセカンダリディスプレイに接続すると、タッチ入力は完璧に動作します。 回避策として、ディスプレイポートを入れ替えました。つまり、プライマリポートとセカンダリポートを相互に接続しました。すると、セカンダリースクリーンはプライマリースクリーンと同じ解像度になってしまうため、私たちのプロジェクトには理想的ではありません。 以下に、受信した応答とログを示します。     $ adb shell dumpsys SurfaceFlinger --display-id  ディスプレイ 4632668096568543232 (HWC ディスプレイ 0): ポート=0 pnpId=RTK ディスプレイ名="WaveShare"[15.6]  ディスプレイ 4624778001127622657 (HWC ディスプレイ 1): ポート=1 pnpId=KTC ディスプレイ名="WaveShare"[12.3] 【タッチ入力をメインディスプレイへ】 $ adb shell getevent -i | grep location  場所: "imx-sc-pwrkey/input0"    adb shell getevent -i  デバイス1を追加: /dev/input/event0  バス:0019  ベンダー0000  製品0000  バージョン0000  名前: "sc-powerkey"  場所: "imx-sc-pwrkey/input0"  id: ""  バージョン: 1.0.1    イベント情報:  キー(0001):0074  入力プロパティ:  【タッチ入力をセカンダリディスプレイへ】  $adb shell getevent -i | grep location  場所:「USB-XHCI-HCD.1.Auto-1/input0」  場所: "imx-sc-pwrkey/input0"    adb shell getevent -i  デバイス1を追加: /dev/input/event1  バス:0003  ベンダー0712  製品000a  バージョン0111  名前: "HID 0712:000a"  場所:「USB-XHCI-HCD.1.Auto-1/input0」  id: ""  バージョン: 1.0.1    イベント情報:  凡例(0001):014a  ABS (0003): 0000 : 値 0、最小値 0、最大値 1920、ファジー 0、フラット 0、解像度 4  0001 : 値 0、最小値 0、最大値 720、ファジー 0、フラット 0、解像度 2  002f : 値 0、最小値 0、最大値 9、ファジー 0、フラット 0、解像度 0  0035 : 値 0、最小値 0、最大値 1920、ファジー 0、フラット 0、解像度 4  0036 : 値 0、最小値 0、最大値 720、ファジー 0、フラット 0、解像度 2  0039 : 値 0、最小値 0、最大値 65535、ファジー 0、フラット 0、解像度 0  MSC (0004): 0005  入力プロパティ:  入力プロパティダイレクト  デバイス2を追加: /dev/input/event0  バス:0019  ベンダー0000  製品0000  バージョン0000  名前: "sc-powerkey"  場所: "imx-sc-pwrkey/input0"  id: ""  バージョン: 1.0.1    イベント情報:  キー(0001):0074  入力プロパティ:  Re: Display Touch input not mapped properly with primary display こんにちは、 基板のどのポートがディスプレイのタッチ入力に接続されているか、そしてどのポートがADBアクセスに使われているのか教えていただけますか? できるだけ早くご返信ください。 ありがとうございます。 Re: Display Touch input not mapped properly with primary display こんにちは@Zhiming_Liuさん 解決策をありがとうございました。タッチマッピングが正しく設定できました。 同じブロッカーを持っている人のために、 1)「input-port-associations.xml」は/vendor/etcにあります。 2)コマンド $getevent -i | grep location を使用してディスプレイの入力構成を確認します。 3) 次に、XMLファイルに記載されているディスプレイの設定を変更します。 Re: Display Touch input not mapped properly with primary display こんにちは、 @adithysm65さん AOSPのinput-port-associations.xmlファイルを変更してみましたか? https://github.com/nxp-imx-android/android-imx_device_fsl/blob/android-13.0.0_2.2.0/imx8q/mek_8q/input-port-associations.xml
View full article
默认工作区 你好, 我正在使用MCUXpressoIDE v.24.9.25 (我知道我可以运行更新的版本,但由于某些原因,我需要运行 24.9.25)。正如我在“C:\NXP\MCUXpressoIDE_24.9.25\ide\configuration\config.ini”中看到的那样,osgi.instance.area.default为“@user.home/Documents/MCUXpressoIDE_24.9.25/workspace”,所以是正确的。 但是,如果我关闭 Windows 用户会话并使用其他用户打开一个新会话,当我运行 MCUXpressoIDE 时,默认工作区是第一个用户的工作区,所以我需要切换到第二个工作区目录,因为每个用户都有自己的目录。 osgi.instance.area.default似乎工作不正常,因为@user .home/Documents/MCUXpressoIDE_24.9.25/workspace 应该是每个用户的家目录,但它总是获取第一个登录用户的家目录。 我该如何重新配置它? 谢谢。 #mcux Re: Default workspace 你好, 请问您是否已启用“将此设置为默认值,不再询问”单元格选项? 如果勾选“将此用作默认值且不再询问”选项,MCUXpresso IDE 将始终启动并打开所选工作区;我建议不要勾选此框来选择工作区。 luis_maravilla_2-1782415167728.png 您可以为用户 2 添加另一个工作区,并将其保留在“最近使用的工作区”中,这样您就可以在打开应用程序之前选择所需的工作区。 另外,在“选项卡窗口”>“首选项”>“常规”>“启动和关闭”>“工作区”中 启用启动时提示选择工作区。 luis_maravilla_3-1782415196345.png 此致敬礼,路易斯
View full article
S32k322 ADCの設定に関する問題 私は3つのADCチャネルをBCTU割り込みで電流検知用に設定しています(CTUモードはトリガーモードに設定)。残りのADCチャネルは電圧と温度検知用にノーマルチェーン方式で設定しています。 この構成中、電圧と温度の検知は正常に動作していますが、電流センサがノイズを含む生値を感知しているため、電流制御に異常なスパイクが発生しています。また、CTUモードをトリガーモードからコントロールモードに変更し、現在のセンサーチャネルでは生値ノイズが減少しました。しかし、通常のチャネルで設定された他のチャネルは動作しませんでした。 私たちの期待は、BCTUトリガーを用いた電流検出において単一ADCペリフェラル(ADC0)と、通常の連鎖方法での電圧および温度検出をスパイクなしで処理することです。 注:当社のハードウェアは設定(例:電流センサーチャネルは以下の通り、BCTU方式での読み取り用にP7-ADC0、P2、P3-ADC1)で設計されています。その後、通常のチェーン方法(ADC0 - X0,X1,S19およびADC1-P0,P2,P3,P1,S10)で設定された残りのADCチャネルが続きます ADC_Data1.png ADC_Data2.png Screenshot 2026-06-25 191818.png S32 SDK for S32K1 S32 SDK for S32V Re: S32k322 ADC Configuration Issue こんにちは、@ praveen_ext これはまさにあなたが直面している問題と同じだと思います。 https://community.nxp.com/t5/S32K/Difference-in-ADC-noise-between-BCTU-Control-Mode-and-Trigger/td-p/2384122 あなたが提供してくれたスクリーンショットを見る限り、私の以前の返信に何も変更を加えていないようですね。 Senlent_0-1782438264318.png 既にお伝えしたとおり、ADCクロック分周器の設定に問題があります。 また、外部クロックが25MHzであることは確かですか? この2点を確認しても問題が解決しない場合は、ADCチャネルのサンプリング時間を変更してみてください。 Senlent_1-1782438511587.png このオプションではサンプリング時間を調整できます。サンプリング時間を延ばして再度テストしてみるのもいいでしょう。 Re: S32k322 ADC Configuration Issue こんにちは、 @Senlent さん。 私も上記で述べられたのと同じ問題を抱えています。 当社の外部発振器クロックは25MHzです。S32K322のデータシートによると、ADCは最大80MHzをサポートしているので、プリスケーラーは2に設定しています。また、サンプリング時間を1.2マイクロ秒に設定し、BCTUモードをトリガーモードに設定しました。しかし、同じADC0ペリフェラルでBCTU法とノーマルチェーン法を同時に実行しても、依然としてノイズの多いデータが得られます。同じADC0ペリフェラルで両方を安全に動かす回避策や代替方法はありますか? praveen_ext_0-1782473167287.png praveen_ext_1-1782473350906.png praveen_ext_2-1782473423830.png Re: S32k322 ADC Configuration Issue こんにちは、 @Senlent さん。 私も上記で述べられたのと同じ問題を抱えています。 外部発振器のクロックは25MHzです。S32K322のデータシートによると、ADCは最大80MHzをサポートしているので、プリスケーラーは2MHzに設定しています。また、サンプリング時間を1.2マイクロ秒に設定し、BCTUモードをトリガーモードに設定しました。しかし、同じADC0ペリフェラルでBCTU方法とノーマルチェーン方法を同時に実行しても、依然としてノイズの多いデータが得られます。同じADC0ペリフェラルで両方を安全に動かす回避策や代替方法はありますか? その間、インスタンス1のクロック周波数を40MHzに下げ、サンプリング時間を1.2マイクロ秒に設定しました。これらの変更後、BCTUからの測定値にはノイズが見られなくなった。 Adc_Raw_Val_Ph3センサーと一致し、浮動している2つの値を保持しています。 RwaeVal - 通常のチェーンを設定済み praveen_ext_0-1782473167287.png praveen_ext_1-1782473350906.png praveen_ext_2-1782473423830.png praveen_ext_2-1782896838602.png praveen_ext_5-1782896882736.png praveen_ext_6-1782896898785.png Re: S32k322 ADC Configuration Issue こんにちは、@ praveen_ext 同じ会社じゃないの?あなたも全く同じ質問をしていますね。 https://community.nxp.com/t5/S32K/Difference-in-ADC-noise-between-BCTU-Control-Mode-and-Trigger/mp/2384122#M59412 私の回答をよく読んでいないようですね。 時計の分周器の設定が間違っていると、これで3度目ですよ。 160MHzの場合は、2と4に設定する必要があります。 Senlent_0-1782897219790.png Re: S32k322 ADC Configuration Issue こんにちは、 @Senlent さん。 以前に提案された方法を試してみましたが、問題はまだ解決していません。さらなる設定と検証を行った後、更新されたテストデータと設定イメージを以下に添付します。 我々が見落とした点があれば、ご指摘いただければ幸いです。 praveen_ext_0-1782975094933.png ADC0 praveen_ext_1-1782975139376.png praveen_ext_2-1782975176694.png ADC 1 praveen_ext_3-1782975241134.png praveen_ext_4-1782975291742.png Re: S32k322 ADC Configuration Issue こんにちは、@ praveen_ext プロジェクトを共有していただければ、こちらでテストしてみます。
View full article
Solyball Cooling Ace 专为现代生活而设计 当气温升高时,保持舒适的室内环境成为许多人的首要任务。无论是在家、办公室还是个人工作空间,过高的温度都会影响注意力、放松度和整体舒适度。Solyball 正是为此提供了一个便捷实用的解决方案。Solyball 的设计兼顾便携性、简洁性和现代生活方式,是一款小巧的降温设备,可帮助用户在各种室内环境中营造更舒适的氛围。 Solyball 最显著的特点之一 是其轻巧便携的设计。与笨重难搬或占用大量空间的大型制冷系统不同,Solyball 体积小巧,几乎可以完美融入任何房间。其便携性使用户能够轻松地将其从一个地方搬到另一个地方,从而满足全天候不同需求。无论您是在家办公、在客厅放松,还是准备享受一夜安眠,Solyball 都可以放置在任何您需要额外舒适感的地方。 Solyball 的多功能性 使其成为各种室内环境的理想之选。在卧室里,它有助于在温暖的夜晚营造更舒适的氛围。舒适的睡眠环境对整体健康至关重要,而小巧的降温设备可以提升您的睡眠体验。Solyball 尺寸适中,可轻松放置在床头柜或其他平面上,不会造成空间杂乱。 对于专业人士和远程办公人员来说, Solyball能帮助他们保持舒适的工作空间,从而显著提高工作效率。室内温度过高有时会影响专注力,难以集中精力完成工作。Solyball 提供了一种切实可行的提升工作舒适度的方法,帮助用户在一天中营造更加愉悦的工作环境。其小巧的体积使其可以方便地放置在办公桌或工作台上,而不会占用过多空间。 Solyball的便利性也体现在客厅和家庭共享空间中。这些区域通常是人们聚集的中心场所,他们会在这里看电视、阅读、社交或放松身心。将 Solyball 融入这些空间,用户可以在日常活动中享受更舒适的氛围。其现代外观确保它能与现代家居装饰自然融合。
View full article
FRDM MCX A266のピン設定ツールが見つかりません サイト内のピン設定ツールが見つかりません。 FRDMトレーニング Re: Can't find pin configuration tool for FRDM MCX A266 こんにちは、 これは、ツールを使い始める際に役立つ情報です。 MCUXpresso設定ツールのクイックスタートガイド MCUXpresso設定ツールユーザーガイド(IDE) 必要な情報やツールがあればお知らせください。 敬具、ルイス Re: Can't find pin configuration tool for FRDM MCX A266 https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-config-tools-pins-clocks-and-peripherals:MCUXpresso-Config-Toolsが見つかりました Re: Can't find pin configuration tool for FRDM MCX A266 ご返信ありがとうございます。 可能であれば、これらのツールのステップバイステップ設定の例を教えていただけると助かります。 Re: Can't find pin configuration tool for FRDM MCX A266 こんにちは、 何を達成したいのかによりますが、どのプロセスにアシスタントが必要なのか確認または説明してもらえますか? また、ユーザーガイドのMCUXpresso設定ツールユーザーガイド(IDE)第3章には、手順や写真が付いており、ツールの機能にリダイレクトして設定に合わせて調整できます。 敬具、ルイス Re: Can't find pin configuration tool for FRDM MCX A266 はい、お願いします。私が今やろうとしているのは、ごくシンプルなことです。 4つのDACチャネルと4つのADCチャネルを定義します。 それらを内部の4つのADCチャネルにルーティングしてループを閉じます。 それらの信号が届いたことを確認し、入力数を掛け合わせます。 再度掛け合わせて、パフォーマンスを測定してください。 デバッグおよび結果表示のために、USB経由のシリアル通信でログ出力を行うように設定してください。
View full article
S32DS issue regarding the reference to external files Currently, we are using the demo project. The files in the SDK/platform/drivers/src directory of the project folder are external linked files, which makes it difficult for me to share the project with others as I cannot locate these files. I wonder if there is any way to mount the linked files into the project (excluding the method of copying them one by one). NXP2_0-1782376311748.png Re: S32DS issue regarding the reference to external files Hello @NXP2 , This is expected behavior for older SDK-based S32DS projects. Some SDK driver files are added as Eclipse linked resources, so they are shown in the project tree, but the physical files remain in the installed SDK package location.   For sharing such a project, the recommended approach is to provide the project together with the exact S32DS/SDK package version required on the other PC. If a fully self-contained project is needed, the SDK files must be copied into the project and the linked resources/build paths updated accordingly.   Please note that newer RTD-based projects generated by S32 Configuration Tools copy the required/generated driver files into the project automatically during the Update Code step. Best regards, Pavel Re: S32DS issue regarding the reference to external files The currently used version is S32SDK_S32K1XX_RTM_4.0.2. As shown in the following figure, the two files come from different folders. Do we need to set anything for this? NXP2_0-1782396868796.png Re: S32DS issue regarding the reference to external files Hello @NXP2 , What version of SDK for which S32K family do you use? Best regards, Pavel
View full article
显示屏触摸输入未正确映射到主显示屏 我们正在尝试使用 LVDS 转 HDMI 适配器卡为 i.MX 8 QuadMax MEK CPU 板设置两个显示器,并在主显示器上启用触摸功能。我们使用 USB Type-C 连接器 (J17) 进行触摸输入。 以下是我们观察到的情况: 触摸输入可以被识别,但是当我们将触摸输入连接到主显示器时,它无法进行映射。但是,当我们将其连接到辅助显示器时,触摸输入功能就完全正常了。 作为权宜之计,我们交换了显示端口,即主端口与副端口互换。副屏幕的分辨率与主屏幕相同,这对于我们的项目来说并不理想。 以下是收到的回复和日志。     $ adb shell dumpsys SurfaceFlinger --display-id  显示 4632668096568543232 (HWC 显示 0): port=0 pnpId=RTK displayName="WaveShare"[15.6]  显示器 4624778001127622657(HWC 显示器 1):端口=1 pnpId=KTC 显示名称="WaveShare"[12.3] [触摸输入到主显示屏] $ adb shell getevent -i | grep location  位置:"imx-sc-pwrkey/input0"    adb shell getevent -i  添加设备 1:/dev/input/event0    总线:      0019  供应商 0000  产品 0000  版本 0000  名称:"sc-powerkey"  位置:"imx-sc-pwrkey/input0"  ID: ””  版本:1.0.1  事件:  密钥 (0001): 0074  输入属性:  [触摸输入到辅助显示屏]  $adb shell getevent -i | grep location  位置:“usb-xhci-hcd.1.auto-1/input0”  位置:"imx-sc-pwrkey/input0"    adb shell getevent -i  添加设备 1:/dev/input/event1    总线:      0003  供应商 0712  产品 000a  版本 0111  名称:“HID 0712:000a”  位置:“usb-xhci-hcd.1.auto-1/input0”  ID: ””  版本:1.0.1  事件:  密钥 (0001): 014a  ABS (0003): 0000:值 0,最小值 0,最大值 1920,模糊度 0,平坦度 0,分辨率 4  0001:值 0,最小值 0,最大值 720,模糊度 0,平坦度 0,分辨率 2  002f:值 0,最小值 0,最大值 9,模糊度 0,平坦度 0,分辨率 0  0035:值 0,最小值 0,最大值 1920,模糊度 0,平坦度 0,分辨率 4  0036:值 0,最小值 0,最大值 720,模糊度 0,平坦度 0,分辨率 2  0039:值 0,最小值 0,最大值 65535,模糊度 0,平坦度 0,分辨率 0  MSC (0004): 0005  输入属性:  输入属性直接  添加设备 2:/dev/input/event0    总线:      0019  供应商 0000  产品 0000  版本 0000  名称:"sc-powerkey"  位置:"imx-sc-pwrkey/input0"  ID: ””  版本:1.0.1  事件:  密钥 (0001): 0074  输入属性:  Re: Display Touch input not mapped properly with primary display 你好, 请问主板上哪个端口连接到显示屏的触摸输入,哪个端口用于 ADB 访问? 请尽快回复。 谢谢。 Re: Display Touch input not mapped properly with primary display 你好@Zhiming_Liu , 谢谢你的解答,触摸映射设置已经正确了。 仅供有同样困扰的人参考。 1)“input-port-associations.xml”位于/vendor/etc下。 2)使用命令 $getevent -i | grep location 检查显示器的输入配置。 3)现在更改 xml 文件中提到的显示配置。 Re: Display Touch input not mapped properly with primary display 嗨@adithysm65 您是否尝试过在AOSP中修改input-port-associations.xml文件? https://github.com/nxp-imx-android/android-imx_device_fsl/blob/android-13.0.0_2.2.0/imx8q/mek_8q/input-port-associations.xml
View full article
Display Touch input not mapped properly with primary display We are attempting to set up two displays and enable touch on the primary display for the i.MX 8 QuadMax MEK CPU Board using an LVDS to HDMI Adapter Card. We are using a USB Type-C connector (J17) for the touch input. Here are the observations we have made: The input is recognized but is not getting mapped when we connect the touch input to the primary display. However, when we connect it to the secondary display, the touch input works perfectly. As a workaround, we interchanged the display ports, i.e., primary to secondary and vice versa. The secondary screen then takes up the resolution of the primary screen, which is not ideal for our project. Following are the responses and logs received.     $ adb shell dumpsys SurfaceFlinger --display-id  Display 4632668096568543232 (HWC display 0): port=0 pnpId=RTK displayName="WaveShare"[15.6]  Display 4624778001127622657 (HWC display 1): port=1 pnpId=KTC displayName="WaveShare"[12.3]   [Touch input to primary display]  $ adb shell getevent -i | grep location    location: "imx-sc-pwrkey/input0"    adb shell getevent -i   add device 1: /dev/input/event0    bus:      0019    vendor    0000    product   0000    version   0000    name:     "sc-powerkey"    location: "imx-sc-pwrkey/input0"    id:       ""    version:  1.0.1    events:      KEY (0001): 0074     input props:        [Touch input to secondary display]  $adb shell getevent -i | grep location    location: "usb-xhci-hcd.1.auto-1/input0"    location: "imx-sc-pwrkey/input0"    adb shell getevent -i   add device 1: /dev/input/event1    bus:      0003    vendor    0712    product   000a    version   0111    name:     "HID 0712:000a"    location: "usb-xhci-hcd.1.auto-1/input0"    id:       ""    version:  1.0.1    events:      KEY (0001): 014a       ABS (0003): 0000  : value 0, min 0, max 1920, fuzz 0, flat 0, resolution 4                  0001  : value 0, min 0, max 720, fuzz 0, flat 0, resolution 2                  002f  : value 0, min 0, max 9, fuzz 0, flat 0, resolution 0                  0035  : value 0, min 0, max 1920, fuzz 0, flat 0, resolution 4                  0036  : value 0, min 0, max 720, fuzz 0, flat 0, resolution 2                  0039  : value 0, min 0, max 65535, fuzz 0, flat 0, resolution 0      MSC (0004): 0005     input props:      INPUT_PROP_DIRECT  add device 2: /dev/input/event0    bus:      0019    vendor    0000    product   0000    version   0000    name:     "sc-powerkey"    location: "imx-sc-pwrkey/input0"    id:       ""    version:  1.0.1    events:      KEY (0001): 0074     input props:        Re: Display Touch input not mapped properly with primary display Hi, Could you please let me know which port on the board is connected to the touch input for the displays, and which port is being used for ADB access? Please reply as soon as possible. Thanks. Re: Display Touch input not mapped properly with primary display Hello @Zhiming_Liu , Thanks for the solution,got the touch mapping right. Just for someone with same blocker, 1)The 'input-port-associations.xml' is located under  /vendor/etc. 2)Check the input configuration of the display using the command $getevent -i | grep location. 3)Now change the configurations of the display mentioned under the xml file. Re: Display Touch input not mapped properly with primary display Hi @adithysm65  Have you tried to modify the input-port-associations.xml file in aosp? https://github.com/nxp-imx-android/android-imx_device_fsl/blob/android-13.0.0_2.2.0/imx8q/mek_8q/input-port-associations.xml
View full article
Solyball Cooling Aceは、現代の生活に合わせて設計されています。 ソリーボール:気温が上がり始めると、多くの人にとって快適な室内環境を維持することが優先事項となります。自宅でもオフィスでも、個人の作業スペースでも、過度の熱は集中力やリラックス、全体的な快適さに影響を及ぼします。ここでSolyballが便利で実用的な解決策を提供します。携帯性、シンプルさ、そして現代的な生活を念頭に置いて設計されたSolyballは、さまざまな屋内環境でより快適な雰囲気を作り出すためのコンパクトな冷却装置です。 One of the most notable features of ソリボール は、軽量でポータブルなデザインです。大型の冷却システムが移動が難しかったり、十分なスペースを必要とするのに対し、ソリボールはほぼどんな部屋にも快適に収まるほどコンパクトです。ポータブルな性質により、ユーザーは一つの場所から別の場所へ簡単に持ち運べ、必要に応じて一日中使うのに適しています。ホームオフィスで作業している場合でも、リビングルームでくつろいでいる場合でも、安らかな睡眠の準備をしている場合でも、Solyballは快適さを求めるあらゆる場所に配置できます。 The versatility of Solyball makes it a valuable addition to many different indoor environments. In bedrooms, it can help create a more enjoyable atmosphere during warm evenings. Comfortable sleeping conditions are important for overall well-being, and a compact cooling device can contribute to a more pleasant bedtime experience. Solyball's convenient size allows it to fit neatly on a bedside table or nearby surface without creating clutter. プロフェッショナルやリモートワーカーにとって、Solyballは快適な作業環境を維持することが生産性に不可欠です。室内の暖かさは、時にタスクや責任に集中し続けるのが難しいことがあります。Solyballは作業中の快適さを向上させる実用的な方法を提供し、ユーザーが一日を通じてより快適な環境を作り出すのに役立ちます。コンパクトなサイズのおかげで、机やワークステーションに置いても無駄なスペースを取ることなく快適に置けます。 Solyballのリビングルームや共有のファミリースペースも、Solyballの利便性の恩恵を受けられます。これらのエリアは、人々がテレビを見たり、読書をしたり、交流したり、ただリラックスしたりする中心的な集まりの場として機能します。Solyballをこれらの空間に取り入れることで、ユーザーは日常生活をより快適な環境で過ごすことができます。モダンな外観により、現代的なインテリアと自然に調和しています。
View full article
S32DS 问题涉及对外部文件的引用 目前,我们正在使用演示项目。项目文件夹 SDK/platform/drivers/src 目录中的文件是外部链接文件,这让我很难与他人共享该项目,因为我找不到这些文件。我想知道是否有办法将链接的文件挂载到项目中(不包括逐个复制的方法)。 NXP2_0-1782376311748.png Re: S32DS issue regarding the reference to external files 您好@NXP2 , 这是基于旧版 SDK 的 S32DS 项目的预期行为。一些 SDK 驱动程序文件被添加为 Eclipse 链接资源,因此它们会显示在项目树中,但物理文件仍然保留在已安装的 SDK 包位置。   对于共享此类项目,建议的方法是将项目与另一台 PC 上所需的确切 S32DS/SDK 代码包,软件包版本一起提供。如果需要完全独立的项目,则必须将 SDK 文件复制到项目中,并相应地更新链接的资源/版本路径。   请注意,由 S32 配置工具生成的较新的基于 RTD 的项目会在更新代码步骤期间自动将所需/生成的驱动程序文件复制到项目中。 顺祝商祺! 帕维尔 Re: S32DS issue regarding the reference to external files 目前使用的版本是 S32SDK_S32K1XX_RTM_4.0.2。如下图所示,这两个文件来自不同的文件夹。我们需要为此做任何设置吗? NXP2_0-1782396868796.png Re: S32DS issue regarding the reference to external files 您好@NXP2 , 您使用的是哪个版本的SDK,对应哪个S32K系列? 顺祝商祺! 帕维尔
View full article