Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
DwF 多伦多 - 2015-10-29 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 汽车和联网汽车 设计、软件和服务 医疗保健和可穿戴设备 智能工业 洞察与创新 智能家居和建筑 智能网络
記事全体を表示
DwF Paris - 2015-10-01 Automotive and Connected Car Smart Industry Smart Cities Smart Networks
記事全体を表示
MAC57D5x Instrument Cluster with HUD Demo This demo showcases the MAC57D5xx microcontroller rendering on a LVDS 1280x480 display for a full digital graphic instrument cluster and a Head-up Display on a secondary panel showcasing the warping capabilities of the microcontroller.       Single-chip instrument cluster solution with powerful graphics subsystem, including inline Head-Up Display warping functionality Dual-core ARM® Cortex®-A5/M4 for real-time and application processing and additional Cortex-M0+IOP core Cryptographic Services Engine, tamper detection and password protection for Flash memory and JTAG   Links Ultra-Reliable Multi-Core ARM-based MCU Automotive
記事全体を表示
Complementary PWM on FRDM-KL25Z using processor expert Hi everyone,      I have got customer queries on unavailability of complementary mode PWM on KL25Z . So, I thought let me experiment something and post it onto the community.      The timer module on KL25 is TPM, not FTM!. There are 3 TPMs, TPM0 with 6 channels, TPM1 and TPM2 with 2 channels each. To generate a PWM signal, PWM component can be used. But the PWM bean doesnot provide option to generate complementary PWM. So, we need to configure different channels to get the complementary PWM. Again, there is a limitation for this. PWM component doesn't allow to generate initial polarity high. It says "the inherited component doesnot support this feature". But in run time can set or clear value on the PWM output pin using the SetValue() and ClrValue(). But again the inherited component"TimerUnit_LDD" doesn't support generating SetValue() and ClrValue().      So, I came to a conclusion 'not to use PWM component' and started using Init_TPM. Using this component, 2 channels are configured to have opposite polarity during initialization. They are configured to have the same period. Deadtime is also inserted by configuring different duty cycle on each channel. But methods are not available since the component only provides the initialization function which is good enough to start . Dynamically if dutycycle needs to be changed, methods have to be written explicitly     Project and oscilloscope captures are attached for reference. Hi Note that this is also supported in the uTasker project - see http://www.utasker.com/docs/uTasker/uTaskerHWTimers.PDF See specifically the final page - this is compatible for K and KL processors. Regards Mark http://www.utasker.com/kinetis.html This document was generated from the following discussion: Complementary PWM on FRDM-KL25Z using processor expert Kinetis L Series MCUs
記事全体を表示
方法: KSDK1.2 用の新しい FreeRTOS を作成するKDS3.0 のプロジェクト <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 皆さん、こんにちは   KDS3.0 を使用して FreeRTOS と KSDK1.2 の使用を開始する方法については、添付のドキュメントを参照してください。   MQXを使用して新しいKSDKプロジェクトを作成する方法については、次のドキュメントを参照してください。 方法 : KDS で新しい MQX RTOS for KSDK プロジェクトを作成する   よろしくお願いします。 カルロス 全般
記事全体を表示
APF-ACC-T1092 This session will discuss Advanced Driver Assistance Systems (ADAS) product and solution update plus feature guidelines on product mapping for different ADAS applications. This session will discuss Advanced Driver Assistance Systems (ADAS) product and solution update plus feature guidelines on product mapping for different ADAS applications.
記事全体を表示
TFC 2015 Wordwide Championship Rules These are the 2015 Freescale Cup Worldwide Challenge Rules. The Finals will take place in Erlangen Germany on September 14-15, 2015. The Worldwide Rules are to be used for all challenges unless the University Programs Coordinator modifies the rules for your specific region. Update on Rules V6: highlighted the fact that no wireless connectivity is allowed during the race. Any wireless connectivity module must be removed before the technical inspection These are the 2015 Freescale Cup Worldwide Challenge Rules. The Finals will take place in Erlangen Germany on September 14-15, 2015. The Worldwide Rules are to be used for all challenges unless the University Programs Coordinator modifies the rules for your specific region. Update on Rules V6: highlighted the fact that no wireless connectivity is allowed during the race. Any wireless connectivity module must be removed before the technical inspection Freescale Cup Content Re: TFC 2015 Wordwide Championship Rules Hi, Regarding question #1: The tires must be unaltered, this includes the treads. Rules read as follows: "The original and unaltered equipment must be used as the entry. Outer tire treads and rim." Regarding question #2: You can create your own motor control interface within the rules listed: The High Voltage Motor Control and Interface it is required to use Freescale technology. A Freescale 32-bit Microcontroller must be used. One processor - No auxiliary processor or other programmable device is allowed. Freescale Motor Driver Integrated Circuits must be used. The car must use an optical sensor to navigate. DC-DC boost may not exceed battery voltage. Total capacity of all capacitors should not exceed 2000 uF. No Wireless connectivity is allowed during the race. Any wireless connectivity modules/technology must be removed from the vehicle before the technical inspection If your description of "motor drive chip" is for H-bridges, there are 2 motors on the car so the assumption is that you would be using max 2 H-bridges but there is nothing in the rules that says that you can't use more than 2. Just remember to document all changes per the rules' requirements. Re: TFC 2015 Wordwide Championship Rules Hi organizers, We have two questions regarding the Rules: Question 1 Pertaining to the Rule in Section 1 Mechanical: 1. The original and unaltered equipment must be used as the entry. a. Outer tire treads and rim. Is grinding/shaving the treads of the tire allowed as shown in the pictures below? Question 2 Pertaining to the Rule in Section 1 Electrical point 3: The High Voltage Motor Control and Interface it is required to use Freescale technology. Is there any limit on the number of Motor Driver chips to be used? Thanks. Looking forward for your reply. Re: TFC 2015 Wordwide Championship Rules Hello Joshua, There is no penalty for running over the line. The only penalty is when the car is out of the track with more than 2 wheels. This means: 2 wheels out of the track, you are ok, car can continue with the current lap. But when 3 wheels are out of the track, car is out of the track. Penalty: Lap is not recorded. You can check this on section 7. Re: TFC 2015 Wordwide Championship Rules If the car touches the line during the course of it's run is that considered a failure? Is there a distinction between touching a line and crossing over a line? I am currently registered for the RIT Regional competition, has a start time been decided for that event? Thank you.
記事全体を表示
飞思卡尔常用调试工具 1. USB Multilink Universal    支持 Kinetis, HCS08, HC(S)12(X), S12Z, RS08, ColdFire V1/+V1, ColdFire V2-4*, Qorivva 5xxx, DSC.    PE Micro, http://www.pemicro.com/ 2. USB Multilink Universal FX    支持 Kinetis, Qorivva MPC5xxx, ColdFire +V1/ColdFire V1, ColdFire V2/3/4, HC(S)12(X), S12Z, HCS08, RS08, DSC, 683xx, HC16.    PE Micro, http://www.pemicro.com/ 3. J-Link    支持飞思卡尔ARM based Microcontroller Kinetis.    可以配合PC端的软件JFlash对目标板进行烧写。    Segger, http://www.segger.com 4. ULink2    支持飞思卡尔ARM based Microcontroller Kinetis.    Keil, http://www.keil.com/arm/ulink/ 5. USBDM    开源调试器    可以配合PC端的上位机对目标板进行烧写。    http://usbdm.sourceforge.net/    https://github.com/podonoghue    http://sourceforge.net/projects/usbdm/ 6. CMSIS-DAP    ARM公司开源调试器    仿真器相关介绍页: http://mbed.org/handbook/cmsis-dap-interface-firmware    仿真器的源码下载: https://github.com/mbedmicro/CMSIS-DAP 7. OpenSDA     P&E Microcomputer Systems Kinetis Hardware Support
記事全体を表示
How to handle issue on “Waiting for devices” when downloading android images to i.MX8MQ MEK via UUU Tools Descriptions on the issue: running “uuu uuu-android-mx8mq-evk-emmc.lst” No any problem, downloading images is OK. running “uuu_imx_android_flash.bat -f imx8mq -a -e” Below lines will be showed on windows console: flash the file of u-boot-imx8mq.imx to the partition of bootloader0             Then downloading operation stopped. ------------------------------------------------------------------------                 In order to help uses save development time, I tested above 2 commands for downloading images on windows 7 64bit and windows 10 64bit respectively.                 Below is detailed steps for the operation: Hardware Preparations (1) Switch SW802 on i.MX8MQ EMEK, set 1-4 off, 2-3 on i.MX8MQ is at usb serial download mode. (2) Connecting J1701 to PC USB by a USB OTG cable. (3) Connecting J901(usb type c) to PC USB by a USB 3.0 cable. (4) Plugging [email protected] adapter into Power Jack (J902) (5) Power on I.MX8MQ board via SW701 Switch Software Preparations (1) Related windows drivers for i.MX8MQ MEK                 Windows 7 64bit or windows 10 64bit will find new devices and begin to search and install corresponding drivers, like below:                 Probably windows 10 64bit can’t automatically install CP2105 driver from official website of manufacture: https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers                 Then installed it manually. (2) Power off i.MX8MQ MEK (3) Installing winusb driver by zadig                 According to method described in uuu.pdf, download zadig tool from https://zadig.akeo.ie/, and install it to windows 7 64bit . [Note] windows 10 64bit doesn’t need to install winusb driver. Press “Install WCID Driver” Button (4) Downloading Android SDK Manager Download SDK Manager from : http://visualgdb.com/android/install_redir?item=SDK After downloading it, decompress it, and run SDK Manager application: Press OK. Then press “Close” Close SDK Manager Installation Guide . Find the directory of SDK Manager installation, and enter into “platform-tools”, like below: D:\i.MX8-Projects\IMX8MQ-MEK-windows-drivers\android-sdk_r24.4.1-windows\android-sdk-windows\platform-tools Copy items in blue rectangle to C:\windows\system Copy items in red rectangle to C:\windows\system32 Beginning to download android images to I.MX8MQ MEK via UUU Tool (1) Downloading android DEMO images for i.MX8MQ MEK https://www.nxp.com/support/developer-resources/software-development-tools/i.mx-developer-resources/evaluation-kit-for-the-i.mx-8m-applications-processor:MCIMX8M-EVK?tab=Design_Tools_Tab After downloading it, decompress it to a directory.  Like below: (2) Downloading UUU Tool https://github.com/NXPmicro/mfgtools/releases After downloading uuu.exe,  copy it to the directory of android 9.0 demo image , see above. (3) Run command “uuu_imx_android_flash.bat -f imx8mq -a -e” ----Power on i.MX8MQ MEK. ----open a command line window ---open Hyper terminal ( set it 115200 bps) ---run “uuu_imx_android_flash.bat -f imx8mq -a -e”           For windows 10 64bit, downloading images will be done without any errors.    But for windows 7 64bit, downloading images will stop at “ waiting for any devices”.    It means Android ADB driver will be needed. Follow the steps below to solve the problem. Right button, click “update driver” Close it.           Then downloading operations will be automatically continued. OK, done. NXP TIC team Weidong Sun 02-25-2019 i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: How to handle issue on “Waiting for devices” when downloading android images to i.MX8MQ MEK via UUU Tools According to this file, the problem of imx8mq evk platform is still not solved on my windows10 64-bit. It's still "waiting for any devices"!!
記事全体を表示
S32DS for Power - 操作指南列表 安装和激活 操作指南:将 Wind River 编译器的 Eclipse 插件安装到 S32 Design Studio 中 操作指南:将 Lauterbach TRACE32 调试器插件安装到 S32 Design Studio 中  如何将 PLS UDE 调试器插件安装到 S32 Design Studio 中 操作指南:激活S32 Design Studio 入门指南 操作指南:创建闪烁的 LED 项目 (MPC5748G) 如何:在 S32 Design Studio 中构建项目并设置调试配置以进行调试 构建工具和标准库 操作指南:在 S32 Design Studio 中从 RAM 运行例程 操作指南:使用 printf() 函数和 EWL 库 操作指南:将 S32DS Power v1.x 中创建的项目迁移到 v1.2+ 操作指南:将静态库文件添加到 S32DS GCC 项目中  操作指南:使用 GNU 构建工具将二进制文件链接到应用程序项目中 操作指南:使用 GNU 构建工具从 RAM 内存执行库函数  新! 调试与Flash编程 操作指南:使用 S32 Design Studio 将单独的 elf/srec/hex 文件下载到微控制器 操作指南:在 S32 Design Studio for Power 中编程数据闪存 (DFLASH) 操作指南:在 S32 Design Studio for Power 中将 DCF 记录编程到 UTEST 闪存中 操作指南:在 S32 Design Studio 中调试多核项目 操作指南:在 EVB 上更新 OpenSDA 固件 操作指南:MPC5777C - 通过 PE Micro 执行低/中区块 Flash 擦除 操作指南:使用 RappID BL 工具与 MPC5744P EVB 操作指南:在 S32 Design Studio 中调试多个 ELF 文件  操作指南:在 S32 Design Studio 调试器(Pemicro/OpenSDA 接口)中重置 MCU  操作指南:在单次调试会话中烧录多种类型的存储器 更新! SDK 操作指南:使用 AMMCLib SDK 操作指南:使用 FreeMASTER SDKs 操作指南:将自定义 SDK 添加到现有项目 操作指南:将基于 SDK 的示例代码作为独立代码使用(可用于 GIT、SVN... 更新! 通用用法 操作指南:S32 Design Studio 命令行界面 操作指南:将用户示例添加到 S32DS 操作指南:生成 S-Record/Intel HEX/二进制文件 操作指南:更新 S32 Design Studio 如何将生成的代码导出到 S32 Design Studio IDE(适用于 MPC5744P v2.0 的 MBDT) 操作指南:安装来自第三方供应商的更新 S32 Design Studio for Power 架构 v2.1 迁移指南 操作指南:设置项目优化级别 故障排除 故障排除:从“快速入门”页面打开文档时出现问题 故障排除:PEmicro 调试连接 - 目标通信速度 故障排除:头文件索引器错误 S32 Design Studio 离线激活问题修复补丁 故障排除:安装程序在输入激活码后立即回滚 故障排除:激活失败并显示错误信息 FNP ERROR 0
記事全体を表示
i.MX6SX寄存器编程辅助工具 重要提示:如果您有任何疑问或想要报告有关 DDR 工具或支持文档的任何问题,请在i.MX 社区中创建支持工单。请注意,任何私人消息或直接邮件不会被监控,也不会收到回复。 这是针对与 MMDC 初始化相关寄存器的详细编程辅助资料。最后一张表格格式化寄存器设置以便与 ARM RealView ICE 一起使用。它还可以与 DDR 压力测试的 Windows 可执行文件一起使用。此编程辅助工具用于内部 NXP 验证板。 i.MX6SoloX 回复:i.MX6SX LPDDR2 寄存器编程辅助工具 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 初始化脚本通常不会对 MMDC_MAARCR 寄存器进行编程。Freescale 建议保留其默认值。 这是给决定更改此登记簿中某些字段的客户的建议。 已发现 ARCR_GUARD 字段存在一个缺陷。该字段应始终保持默认的 0x0 值。若将其编程为其他值,可能会导致不可预测的行为。
記事全体を表示
Radar - SW & HW Environment 1 Table of Contents • Introduction • Reference Architecture • Hardware Environment • Software Environment • Radar Signal Chain • From Simulation to Target • Installing the NXP Toolchain • Next Article in the Series • References 2 Introduction This article presents the NXP hardware platforms and the MathWorks and NXP software tools used to build an automotive radar application. The development workflow is anchored in the MathWorks example "Radar Signal Simulation and Processing for Automated Driving," which provides a reference architecture spanning driving-scenario simulation, radar modeling, and signal processing. The resulting signal-processing chain is then adapted and deployed onto NXP radar hardware using NXP-specific toolboxes and hardware accelerators. This article is part of the Radar Application Development Series, which describes the complete workflow for developing, deploying, and optimizing automotive radar applications on NXP radar platforms. The purpose of this article is to introduce the overall software and hardware environment and show how the different tools, hardware components, and processing engines fit together within a radar development workflow. The next article in this series, "Radar - Processing Chain," will explore in depth each processing block presented in the Radar Signal Processing section: Range FFT, Doppler FFT, Non-Coherent Combining, CFAR Detection, Clustering, and Direction-of-Arrival (DoA) estimation. 3 Reference Architecture The starting point for the radar application is the MathWorks reference example, which models a complete automotive radar system end to end. The workflow begins by defining a highway driving scenario using the Automated Driving Toolbox ( drivingScenario ), where vehicles and traffic participants are modeled. The ground-truth generated data then feeds the radar model. Automated Driving - Bird's-Eye Plot.png   Figure 1: MathWorks example bird's-eye plot with Radar detections A 77 GHz FMCW radar is parameterized from high-level system requirements such as: Maximum detection range, typically 250-300 m for long-range radar Range resolution, around 1 m Velocity resolution Maximum relative target velocity, up to around 230 km/h The example then builds a transceiver model with antenna arrays, transmitter/receiver components, and signal-propagation effects, generating synthetic detections that estimate the position and velocity of surrounding vehicles. For the NXP application, the reference architecture is divided into two domains: Environment Simulation Executes entirely within MATLAB, and is responsible for: Driving scenario generation Vehicle motion simulation Target ground-truth generation FMCW signal generation Radar channel and propagation modeling Radar Signal Processing Contains the processing chain deployed on the S32R45 platform: Range FFT processing Doppler FFT processing Non-Coherent Combining CFAR detection Clustering Direction-of-Arrival (DoA) estimation The Radar Signal Processing domain forms the basis of the embedded radar application deployed on the S32R45 Evaluation Board. 4 Hardware Environment 3.1 S32R45 Evaluation Board The primary processing platform is the NXP S32R45 Evaluation Board, a development platform for high-performance 77 GHz radar applications such as adaptive cruise control, autonomous emergency braking, and cascaded imaging radar. It integrates several specialized processing engines optimized for radar workloads. Processing engine Role 4x Arm® Cortex®-A53 cores Application-level processing, radar control, clustering, and object management SPT Accelerator Optimized FFTs and high-throughput radar signal-processing kernels BBE32 DSP Vectorized signal processing, detection algorithms, and custom radar kernels LAX Accelerator Matrix and linear-algebra operations for accelerated angle estimation S32R45 Radar MPU Block Diagram.png   Figure 2: S32R45 block diagram 3.2 TEF82xx Customer Application Board The TEF82xx is a fully integrated 76-81 GHz RFCMOS automotive radar transceiver providing the RF front end for signal generation and capture. It integrates 3 transmit channels, 4 receive channels, ADCs, a low-phase-noise VCO, and a phase rotator, and is fully compatible with the S32R45. In the current application, the input signal is sourced from simulation rather than hardware, so the TEF82xx is not actively used. It is included as a placeholder for future hardware-in-the-loop and real-sensor integration. 5 Software Environment The radar application combines MathWorks toolboxes for algorithm development with NXP toolboxes and tools for deployment and accelerator integration. 4.1 MathWorks Tools Tool Role in the workflow Radar Toolbox FMCW waveform generation, propagation modeling, detection, and analysis Automated Driving Toolbox Scenario modeling, road/vehicle simulation, and ground-truth generation 4.2 NXP Tools Tool Version Role in the workflow S32 Design Studio for S32 Platform 3.5 IDE, compiler, debugger, and deployment environment for the S32R45, including its accelerators NXP Model-Based Design Toolbox for SPT 1.9.0 Bit-exact SPT simulator integration and rapid prototyping in MATLAB NXP Model-Based Design Toolbox for RADAR 1.0.0 MATLAB integration for S32R45; SPT/LAX kernel execution, code generation, and PIL workflows NXP Radar SDK (S32R45) 1.2.0 Optimized radar algorithms, accelerator libraries, SPT/LAX kernels, and embedded deployment infrastructure Together, these tools act as the gateway between the MathWorks and NXP ecosystems, enabling algorithm development, simulation, code generation, deployment, and SIL/PIL validation within a common workflow. 6 Radar Signal Chain Once the FMCW echoes are generated or captured, the signal-processing chain transforms the radar cube into a list of detected objects. The application currently implements the following stages. # Stage What it does Runs on 1 ADC Acquisition Digitizes the beat signal into a radar data cube, using samples x chirps x antennas TEF82xx ADCs → S32R45 2 Range FFT Fast-time FFT converts beat frequency into target range SPT accelerator 3 Doppler FFT Slow-time FFT resolves velocity, producing the processed radar cube SPT accelerator 4 Non-Coherent Combining Combines the magnitude of the range/Doppler-processed radar cube across channels, producing the range-Doppler magnitude matrix SPT accelerator 5 CFAR Detection Applies Constant False Alarm Rate thresholding on the range-Doppler magnitude matrix to detect possible targets BBE32 DSP 6 Clustering Groups neighboring detections, for example using DBSCAN, into physical objects Cortex-A53 cores 7 Angle / DoA Estimation Estimates azimuth/elevation across the antenna array, using methods such as beamforming or MUSIC LAX accelerator The output of the chain is a list of detected objects with range, relative velocity, and angle of arrival. Future Improvements The current application focuses on signal processing and object detection. Planned enhancements include: Multi-target tracking, including Kalman filtering and track-to-track association Hardware-in-the-loop testing using the TEF82xx front end 7 From Simulation to Target The MathWorks reference example executes entirely within MATLAB. During deployment, the example is partitioned into the Environment Simulation block and the Radar Signal Processing block, where the computationally intensive signal-processing functions are replaced with NXP-optimized implementations from the Radar SDK. This delivers faster execution, reduced CPU utilization, and accelerator offloading on the S32R45. 8 Installing the NXP Toolchain 7.1 Installation Order The development tools must be installed in the following order to ensure that all external dependencies required by the NXP MBDT for RADAR are available before it is configured: S32 Design Studio for S32 Platform 3.5 S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for SPT 1.9.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 7.2 Integrating the Development Environment After NXP MBDT for RADAR is installed, the integration of S32 Design Studio and S32R45 Radar SDK is performed using the MATLAB Live Script: mbd_lax_dependencies_path.mlx The script is located at the root of the NXP MBDT for RADAR installation. Running this script configures the required dependency paths and establishes the connection between MATLAB, the NXP Model-Based Design Toolbox for RADAR, S32 Design Studio, and the S32R45 Radar SDK. Once the script is completed successfully, the environment is ready for simulation, code generation, accelerator kernel execution, and Processor-in-the-Loop (PIL) validation. 7.3 Installation Methods The NXP toolboxes ship as MATLAB Toolbox packages (.mltbx) and can be installed in three ways: Manual install (.mltbx) - Double-click the .mltbx file, or right-click and select Install in MATLAB. The Add-On Manager installs and registers the toolbox automatically. Via NXP Support Package - Install NXP_Support_Package_RADAR from MATLAB Add-Ons, then follow the guided steps to download and install MBDT for RADAR and generate/activate the free license. Via the Automotive Software Package Manager - A bundle installer that walks through toolbox installation, dependency configuration, and license activation. 9 Next Article in the Series This article introduced the software environment, hardware environment, deployment workflow, and high-level radar signal-processing architecture. The next article, "Radar - Processing Chain - RSDK," will provide a detailed analysis of each processing block presented in Section 5: Range FFT Doppler FFT Non-Coherent Combining CFAR Detection Clustering Direction-of-Arrival (DoA) Estimation It will also explain how these algorithms are mapped onto the S32R45 processing resources and how the NXP Radar SDK accelerates the execution of each stage. 10 References MathWorks Radar Signal Simulation and Processing for Automated Driving Radar Toolbox Automated Driving Toolbox NXP S32R45 High-Performance Processor for Imaging Radar S32R45 Evaluation Board TEF82xx 77 GHz Radar Transceiver Model-Based Design Toolbox MBDT for RADAR - Knowledge Base NXP Support Package for RADAR How to install .MLTBX
記事全体を表示
Developing a Parking Sensor System with Model-Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion   2 Introduction Parking assistance systems are a familiar feature in modern vehicles, helping drivers detect nearby obstacles and maneuver the vehicle more safely. In our Hello World with MBDT project, the parking sensor subsystem provides this capability by measuring the distance to nearby objects and supplying that information to the rest of the system. Figure 1 - Physical concept.png Figure 1 - Physical concept This article introduces the parking sensor system and leads into the next articles in the series, where we will examine how this part of the project is developed. The Parking Sensors System (PSS) focus is set on how Model‑Based Design (MBD) enables the subsystem to be designed, simulated, tested, and deployed rapidly using MATLAB/Simulink and the NXP Model-Based Design Toolbox (MBDT).   3 Overview The role of this subsystem within the overall project describes the main elements that make up the parking sensor application and explains its purpose and behavior at a conceptual level. The article outlines how NXP's MBDT supports the development of this component and how a single model is reused for both front and rear parking modules. It also clarifies how this component fits into the larger project and how it connects to the rest of the components. The importance of this subsystem lies not only in its functional role of acquiring and processing distance information but also in how it demonstrates the efficiency of model‑based workflows. Rather than relying on traditional hand‑written embedded code, the entire application — logic, algorithms, peripheral drivers, timing behavior — can be designed graphically in Simulink. This accelerates development in several ways: Behavior can be simulated on the PC, without flashing hardware. The same model drives both simulation and embedded implementation. Peripheral interactions like Analog‑to‑Digital Converter (ADC) and Local Interconnect Network (LIN) are handled through dedicated blocks, not hand‑written code. Parameter tuning and validation are simplified through FreeMASTER, providing real-time visualization of the embedded system parameters. This accelerates development and ensures that the final embedded behavior matches the tested model. Developing an embedded sensor node application typically involves writing extensive low‑level code, configuring peripherals manually, and iterating slowly through hardware tests. This slows down development, limits experimentation, and creates fragmentation between design and implementation. The parking sensor subsystem demonstrates how Model-Based Design in Simulink solves this problem by enabling the entire feature to be built directly in Simulink. Engineers can model ADC acquisition, LIN communication, filtering logic, and threshold detection using graphical blocks rather than manual code. They can simulate the behavior instantly, refine algorithms quickly, and deploy the design to the microcontroller through automatic code generation. The MBD approach significantly improves the efficiency and reliability of developing, testing, and refining the complete parking sensor application. This series is intended for: Engineers learning Model‑Based Design with MATLAB/Simulink Developers working with NXP automotive microcontrollers Teams building rapid prototypes of embedded measurement and control features Students and researchers studying vehicle architectures Anyone interested in a full, reproducible example of embedded system development using MBDT Readers will gain a clear, step‑by‑step understanding of how a complete embedded feature is designed and implemented using a unified model‑based workflow.   4 Context A key aspect of the design is that the same PSS application developed in Simulink is used for both front and rear parking. Two separate S32K144 boards run the identical autogenerated code — one at the front of the vehicle and one at the rear. This showcases one of the major advantages of MBD: a single validated model can be scaled, cloned, and reused across multiple hardware nodes with minimal parametrization. Figure 2 - Parking System Architecture.png Figure 2 - Parking System Architecture The purpose of the parking sensor subsystem is to provide a clean, consistent, and rapidly developed interface that delivers accurate distance information to the rest of the system. In the implemented setup, each ultrasonic sensor outputs an analog voltage proportional to distance. This signal is sampled by the ADC (Analog‑to‑Digital Converter) of the S32K144 microcontroller. The embedded application running on the S32K144 performs the acquisition sequence, processes the ADC values to compute distance measurements, and formats the results into a communication frame. The prepared data is then transmitted over the LIN bus to the zonal controller, where it can be further used by higher‑level vehicle functions. All functional aspects — ADC acquisition configuration, signal processing, communication formatting, and diagnostic handling — are defined directly in the Simulink model, enabling rapid refinement and immediate validation through simulation. During development, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, observe processed distance values, and validate the behavior of the embedded application before integrating the component into the full system. The parking sensor component (front and rear) is highlighted to show its position in the project setup: Figure 3 - Parking System highlighted within the project.png Figure 3 - Parking System highlighted within the project Related articles in the series Note: Additional articles in the series, including topics such as Software & Hardware Environment, Architecture & Model Description, Deploy & Validate on Hardware, Final Results and Challenges, will be added here as they become available. Each will explore individual technical details such as ADC acquisition, model structure, filtering logic, and communication behavior introduced in this overview. 5 References Software & Hardware Environment for Parking Sensor System MathWorks Model-Based Design Toolbox for S32K Community Model-Based Design Toolbox for S32K How To NXP Support Package for S32K1xx NXP Model-Based Design Toolbox for S32K1 Toolbox Download These resources provide deeper insight into the tools and methods used to build the subsystem. 6 Conclusion The parking sensor subsystem demonstrates how Model-Based Design accelerates the development of embedded automotive features. By modeling the sensing logic in Simulink, validating behavior through simulation, downloading it automatically using MBDT and monitoring it on hardware with FreeMASTER, the entire application can be developed and deployed from within a single environment. Rather than duplicating the parking sensors logic, the application is implemented as a parameterized Simulink model. Using MBDT, the same model instance can be configured for the front or rear module by adjusting parameters such as communication identifiers. This approach enables consistent behavior across parking modules while minimizing duplication and simplifying maintenance. This article introduced the component's behavior, purpose, and development workflow. The next articles in the series will expand on specific technical aspects, building a complete understanding of the subsystem from model to deployment.
記事全体を表示
Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. 1 Every great build starts with "Hello World" Every engineer remembers their first “Hello World” — that small, satisfying moment when an idea typed on a screen suddenly comes to life on a real machine. This series is a take on that same feeling, only this time the “machine” is a car. It’s a demonstrator that looks and behaves like a real vehicle, showcasing the combined use of tools from both the NXP and MathWorks ecosystems. This demo has been showcased at several events, including most recently at the MathWorks booth during Embedded World 2026 and MathWorks Automotive Conference, where the demo video that accompanies this series was filmed. Think of these articles as a guided tour through how the whole thing comes together, piece by piece. ▶ Watch the demo in action — presented at the MathWorks booth, Embedded World 2026 2 Table of Contents • Every great build starts with Hello World • From a model on a laptop to silicon on the bench • From the steering wheel to every node • And it grew up along the way • Built to be rebuilt — and learned from • A demonstrator, not a blueprint • The article series — one domain at a time 3 From a model on a laptop to silicon on the bench How does a car end up running on NXP silicon, starting from a model on a laptop? That’s where the NXP Model-Based Design Toolbox (MBDT) comes in. It acts as the bridge between the MathWorks ecosystem — Simulink and MATLAB — and NXP’s processors and embedded tools. An application is designed and modeled in Simulink, MBDT generates optimized code for the chosen NXP target, and that code is deployed straight onto the hardware. The main advantage of this approach is what it allows before any board is involved: an application can be validated and tuned in simulation first, and hardware that isn’t physically present can simply be simulated in its place. The results: early issue detection, shorter development cycles, and a faster time to market — backed by a toolchain that has been validated end to end. _MBDT_One_Slider_2026.jpg Figure 1. NXP Model-Based Design Toolbox One Pager 4 From the steering wheel to every node At the heart of the demo is a driver-in-the-loop setup: a physical steering wheel and a set of foot pedals feed signals directly into the simulation, where a virtual car is driven in simulation, into an environment developed through a RoadRunner simulated environment. From there, a clear hierarchy carries every input down to the hardware. The main node — an S32N processor — sits at the center: it communicates with the host PC running the simulation and makes the vehicle-level decisions. It then hands those decisions to a zonal node that acts as a gateway, fanning the signals out to the end nodes that handle each function — the front and rear lights, the front and rear parking sensors, the radar, and the steering rack, and, on the traction side, the battery management system and motor control. The effect is immediate and physical: steering and acceleration in the virtual world set the model on the table moving; shifting into reverse spins the motors up in the right direction; and when an obstacle appears behind the physical car, it stops on its own, with the rear lights turning red across every node — just like a production vehicle. Throughout, a live dashboard built with NXP’s FreeMASTER Lite shows the vehicle state as it happens, from the reverse camera to the parking sensors, blending signals from the virtual world with readings from the physical hardware. [02.16]NXP AutoWorks Tools Suite 26.jpg Figure 2. Demo architecture — main node (S32N), zonal gateway, and end nodes. 5 And it grew up along the way Behind all of these are the core functions of a real car — lighting, parking sensors, steering rack, motor control, and battery management — spread across roughly ten microcontrollers and processors and sixteen NXP evaluation boards and reference designs. There’s no need to unpack every component here, because each one earns its own dedicated article series later on. What’s worth knowing is how it all grew: this didn’t start as today’s car. It began as a battery management system (BMS), then gained cloud connectivity, then motor control — which evolved into a full traction inverter demo — and from there the remaining vehicle domains, from body and lighting to chassis and parking, were layered on one by one until it became a complete vehicle topology. In other words, existing MathWorks and model-based examples were assembled, domain by domain, into a car. 6 Built to be rebuilt — and learn from Why go to all this trouble? Mostly to document the work, share the thinking behind it, and show how to actually use MBDT. A big part of the appeal is that everything runs on NXP evaluation boards, which means the whole thing can be reproduced. There’s no need to redo a complex custom hardware design before starting; the same boards can be picked up to get going right away. That also makes the demo a hands-on learning platform: a place to explore the model-based workflow by doing one domain at a time. Note: A word on scope — this is a proof of concept that demonstrates the development workflow, not production firmware as it stands today. A great path forward is NXP’s CoreRide, which you can read more about on this page: Software-Defined Vehicle Development: NXP CoreRide Platform — but that part will not be covered in this series. Whether the field is automotive, electrification, industrial automation, or robotics — or simply an interest in model-based development — there should be something here worth taking away. 7 A demonstrator, not a blueprint One last note on how to read all of this. This car is a demonstrator, not a reference design. It was built with the hardware that happened to be on hand, so some of the boards and NXP solutions used aren’t necessarily the optimal fit for a given function — for a specific job, a different microcontroller might serve better. The point was never to say “use exactly these parts.” The point is the steps and the approach: the workflow itself, and how the pieces fit together. With that in mind, the articles below each take a part of this build and show how it’s done. Welcome to “Hello World” with the Model-Based Design Toolbox. 8 The article series — one domain at a time Each part of the demo car gets its own dedicated write-up, grouped into the twelve tracks below. As articles go live, the placeholders will be replaced with links. Bookmark this page — it will keep growing. NXP MBDT — How-To & Introduction What is Model-Based Design Toolbox? How to install Model-Based Design Toolbox? MBDT Setup and How-to run an application Develop an MBDT application workflow Create a new model and configure it for NXP Hardware Create a new configuration project using the S32CT How to MBDT Dio Port/Pins FreeMASTER & FreeMASTER Lite Introduction to FreeMASTER Using FreeMASTER block in Simulink Visualize and control variables in FreeMASTER Create web dashboard with FreeMASTER Lite Parking sensors Overview SW & HW Environment Logic Control (Main model overview) Front & Rear Lights System Overview SW & HW Environment Logic Control (Main model overview) Motor Control Overview SW & HW Environment Logic Control Architecture (Main model overview) Battery Management Systems Overview SW & HW Environment Logic Control (Main model overview) Steering Overview SW & HW Environment Logic Control (Main model overview) Radar Overview SW & HW Environment Processing Chain - NXP Radar SDK Main Node Overview SW & HW Environment Logic Control (Main model overview) Zone Node Overview SW & HW Environment Logic Control (Main model overview) Software & Integration Creating virtual vehicle with MathWorks Overview SW & HW Environment Logic Control Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine)  Processor-in-the-Loop (PIL) What is next? Export to & Debug generated code to S32 Design Studio IDE Other Guides Getting Started with FRDM-A-S32K312 using Model-Based Design  A1: Interacting with Digital Inputs Outputs on MR-CANHUBK344 A2: Sending data via UART and monitoring signals with FreeMASTER A3: Controlling LED intensity with ADC and PWM A4: Communicating over the CAN Bus   Note: This index is updated as new articles are published.
記事全体を表示
To complement solution how to printf float number in MCUXpresso IDE Hi: In previous topics there are some discussions how to print float number in MCUXpresso IDE and SDK. To try them and summarize the final solution: 1.PRINTF the float number to UART console set below macro in project configuration->C/C++ build ->setting PRINTF_FLOAT_ENABLE=1 such code will work. float test1 = 0.15; PRINTF("%f\r\n",test1); 2.Transform float number to string by sprintf() function. there is one error in SDK user manual, " Ensure Redlib: Use floating point version of printf is selected " during project creation does not work. The default C library Redlib doesn't support floating, so it couldn't work with redlib. daweiyou_0-1647929545419.png The correct solution are: (1)Change link library to NewLib, it's full C library and support float  printf. But notice need include in related c file, or else sprintf(float) doesn't work as expected. daweiyou_1-1647929662327.png (2)Change link library to NewLib Nano, it's compact C library , and need click "enable print float" to enable float function, which actually add " -u _printf_float" link symbol. But notice need include in related c file, or else sprintf(float) doesn't work as expected. daweiyou_2-1647929807476.png So the solution surely add flash & RAM consumption in project, but for i.MXRT series it's not problem. Attach is one example for RT1020 EVK. Re: To complement solution how to printf float number in MCUXpresso IDE Thank you! That solved my problem.  Re: To complement solution how to printf float number in MCUXpresso IDE Hi @daweiyou  Thank you so much for your contribution. The information was pretty helpful and it might be helpful for many people. Thank you again. Best Regards. Pablo Avalos.
記事全体を表示
S32K358 + FS2633:MCUを組み立てた状態でRSTBは低(LOW)のままですが、JTAGがコネクテッド時は高くなります 私はFS2633とS32K358を使用しています。FS2633セクション(MCUを取り外した部分)だけをテストすると、RSTBが解放され(HIGH)、3.3Vレールが存在します。 MCUとすべてのコンポーネントを組み立てた後、 RSTBはLOWのままで、MCUは起動しません。 JTAGデバッガを接続するとRSTBが高負荷になり、MCUを正常にプログラムでき、アプリケーションは通常通り動作します。しかし、JTAGを切断すると RSTBが再び低くなり 、MCUが停止します。 一つ気づいた点として、FS2633のRSTB出力は3.3Vの信号であるのに対し、私の基板ではS32K358のRESETラインは5Vにプルアップされている。この電圧差にもかかわらず、JTAGデバッガが接続されている間は正しく動作します。このリセット電圧レベルやデバッガーがリセットや電源オンの流れに影響を与えている可能性はありますか? この問題は、電源オンシーケンス、リセットタイミング、FS2633の起動設定、あるいはデバッガ関連の挙動に関連している可能性はありますか?同様の問題を経験された方、またはデバッグに関するご提案をお持ちの方はいらっしゃいますか? Re: S32K358 + FS2633: RSTB stays LOW with MCU assembled, but goes HIGH when JTAG is connected FS2633 RSTBを3.3Vにプルアップしてテストしてみて、この問題が解決するかどうか確認した方が良いでしょう。
記事全体を表示
MCXA153: LPSPI data burst transfer. Hello, The Reference Manual MCXA153 contains a description of the TDBRn and RDBRn LPSPI registers: "TDBRn and RDBRn registers supports burst transfers of data to the transmit FIFO for use with the DMA controller". Can anyone share sample code for a burst transfer using these registers? best regards Bogdan Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) MCXA Re: MCXA153: LPSPI data burst transfer. Hi @bogdan_u  Sorry, there are currently no relevant examples available. The closest MCXA153 example I found uses LPSPI_MasterTransferEDMALite() with eDMA, but the driver targets TDR/RDR via LPSPI_GetTxRegisterAddress() / LPSPI_GetRxRegisterAddress() , not the burst alias window. But i think you can try to use. typedef struct { uint32_t cmd; uint32_t data[128]; } lpspi_burst_tx_t; static inline uint32_t LPSPI_TCBR_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TCBR_OFFSET); } static inline uint32_t LPSPI_TDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TDBR0_OFFSET); } static inline uint32_t LPSPI_RDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_RDBR0_OFFSET); } void LPSPI_StartTxBurstDMA(LPSPI_Type *base, edma_handle_t *txDmaHandle, uint32_t *cmd_plus_data, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = (uint32_t)&cmd_plus_data[0]; cfg.destAddr = LPSPI_TCBR_Address(base); cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords + 1u; EDMA_ResetChannel(txDmaHandle->base, txDmaHandle->channel); EDMA_SetTransferConfig(txDmaHandle->base, txDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(txDmaHandle); LPSPI_EnableDMA(base, kLPSPI_TxDmaEnable); } void LPSPI_StartRxBurstDMA(LPSPI_Type *base, edma_handle_t *rxDmaHandle, uint32_t *rx_words, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = LPSPI_RDBR0_Address(base); cfg.destAddr = (uint32_t)&rx_words[0]; cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords; EDMA_ResetChannel(rxDmaHandle->base, rxDmaHandle->channel); EDMA_SetTransferConfig(rxDmaHandle->base, rxDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(rxDmaHandle); LPSPI_EnableDMA(base, kLPSPI_RxDmaEnable); } BR Harry
記事全体を表示
LX2160A 对 FlexSPI DDR/DTR 模式的支持 - 需要 DQS 说明 你好, 我们正在开发 LX2160A-RDB 板的 FlexSPI 驱动程序,并且对 DDR(八进制 DTR)模式支持有一个疑问。 我们的板上有两个 MT35XU512ABA 闪存芯片连接到 FlexSPI 控制器。从板原理图可以确认,XSPI_A_DQS 信号从闪存(引脚 C3)路由到 LX2160A。 处理器(引脚 E23)。 但是,当我们尝试使用 DTR 模式时,闪存读取返回无效数据(全为零)。SDR八进制模式(1-8-8)在各种频率下都能正常工作。 我们还注意到,在 Linux 内核中,LX2160A FlexSPI 驱动程序设置了 FSPI_QUIRK_DISABLE_DTR。 https://lists.infradead.org/pipermail/linux-mtd/2022-July/094127.html 请问您能否澄清一下: 1. LX2160A FlexSPI 控制器是否支持 DTR/DDR 模式下的基于 DQS 的数据采样,还是这是已知的芯片限制? 2. 如果芯片不支持 DQS,那么 RDB 板上的 XSPI_A_DQS 引脚布线的目的是什么? 3. 是否有任何配置或勘误表可以让 DTR 模式在 LX2160A 上运行? 电路板:LX2160A-RDB Rev B 闪存:MT35XU512ABA(*2,八进制) 参考手册:LX2160A 参考设计板参考手册,修订版 5,2021 年 9 月 28 日 云实验室 在线调试 在线实验室 虚拟测试 Re: FlexSPI DDR/DTR mode support on LX2160A - DQS clarification needed MT35XU512ABA 将具有特定的 SPI 协议,称为 Xccela。不确定LX 2160A是否支持。 Re: FlexSPI DDR/DTR mode support on LX2160A - DQS clarification needed 你好, 实际的解决方法是:除非 NXP 确认有针对特定芯片版本的变通方案,否则 Linux/LSDK 中对 LX2160A-RDB 上的八进制 DTR 不予支持。最有力的实现证据是您找到的 NXP Linux 补丁:它为 LX2160A 添加了 FSPI_QUIRK_DISABLE_DTR 因为“lx2160a 没有实现 DQS”,并指出这会导致八进制 DTR 模式下的闪存探测失败。 针对您的具体问题: LX2160A FlexSPI 是否支持基于 DQS 的 DTR/DDR 采样? 参考手册将 FlexSPI IP 描述为具有 DQS/读取选通采样模式: MCR0[RXCLKSRC] = 0x3 选择“闪存提供的读取选通和来自 DQS 焊盘的输入”,并且输入时序部分明确描述了使用闪存提供的读取选通进行采样。然而,LX2160A 的 Linux 平台数据明确禁用了 DTR,因为该平台“不实现 DQS”。因此,我不会依赖通用的 FlexSPI IP 描述来证明 LX2160A 芯片可以使用外部 DQS 进行八进制 DTR。 为什么 XSPI_A_DQS 被路由到 LX2160A-RDB? DQS 引脚不仅仅是闪光灯提供的读取频闪信号。该手册将 A_DQS 描述为具有多种可能功能的 I/O:外部读取选通、延迟信息和环回虚拟读取选通;它还指出,可以在此引脚上进行板级加载,以补偿环回模式下的 DATA/SCLK 加载。同一个 FlexSPI 模块还使用 DQS/RWDS 作为某些写入操作的写掩码相关信号。因此,RDB 布线与 FlexSPI 引脚/功能集和板兼容性一致,但这本身并不能证明 LX2160A 支持基于外部 DQS 的八进制 DTR 读取。 LX2160A 是否有任何配置或勘误表可以启用 DTR? 我找到了 DQS 模式的文档配置 MCR0[RXCLKSRC] = 0x3 ,当使用闪存提供的读取选通时,DLL 设置如下: SLVDLYTARGET=0xF , DLLEN=1 , OVRDEN=0 ;对于低于 100 MHz 的串行根时钟,手册建议使用 DLL 覆盖模式, OVRDEN=1 ,并调整 OVRDVAL ,其中 N = 18 是一个推荐值,可能需要调整。但LX2160A特有的Linux问题指出,由于LX2160A未实现DQS,因此DTR功能被禁用。我查阅了LX2160A参考手册/数据手册、RDB参考手册、NXP/Linux补丁文本以及公开的勘误表,均未找到任何关于重新启用DQS/DTR的LX2160A勘误或已记录的解决方法。 https://lists.infradead.org/pipermail/linux-mtd/2022-July/094127.html 推荐的驱动程序位置:对 LX2160A 保持 FSPI_QUIRK_DISABLE_DTR ,并使用 SDR 八进制 1-8-8 。您的症状——SDR 八进制工作,DTR 读取返回零——与上游决定阻止此 SoC 上的 DTR 一致,而不是简单的板布线问题。 此致
記事全体を表示
i.MX8MP RAW 捕获最大几何尺寸 NXP社区的各位好, 我们正在尝试在 i.MX8MP 上使用特定的图像传感器。 我们正在尝试将 RAW12 捕获从 MIPI 推送到 RAM。看来唯一的方法是通过如下所述的 ISI 模块: hraducu_1-1782239762964.png 问题在于,关于几何限制的文档含糊不清,我们正在尝试确定 i.MX8MP 是否适合我们的应用。 图像的高度和宽度在 ISI 中使用 CHNL_IMG_CFG[WIDTH/HEIGHT] 寄存器定义。这些条目是 13 位的,理论上将我们限制在 8191 x 8191 的几何尺寸。 宽度似乎受到硬件的限制,因为行缓冲区实际上只能容纳 2K 像素,但文档概述了通过组合其他通道的行缓冲区来实现 4K 的方法。文档中没有说明是否可以达到 8191 像素的线宽寄存器限制。我们可以绕过 ISI 处理,我们的目标是直接将 RAW MIPI 捕获的数据推送到 RAM 中。 此外,与宽度限制不同,高度限制似乎并非由物理硬件引起。 是否有任何证据表明我们可以支持 CHNL_IMG_CFG[HEIGHT] 寄存器 13 位最大值所定义的 8191 行高度? 任何支持都将不胜感激。我已阅读过其他类似帖子,例如以下这些: https://community.nxp.com/t5/i-MX-Processors/Direct-MIPI-CSI2-to-memory-access-on-i-MX8MP/mp/2158946 https://community.nxp.com/t5/i-MX-Processors/I-MX8MP-ISI-maximum-supported-width/mp/1224069 但是,目前尚未确认是否支持 8191 宽度,我想知道这方面是否有任何更新。 此外,高度限制也没有明确规定。 谢谢 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MP Maximum Geometry for RAW Capture i.MX8MP 的 ISI 驱动程序限制在 2K 分辨率,但如果使用链式缓冲区,ISI 可以支持高达 4K 的分辨率,但不支持 8191 像素宽。在 i.MX8MP 上,单个摄像头最高可支持 4K@30Hz 的分辨率。 Re: i.MX8MP Maximum Geometry for RAW Capture 感谢您的回复。 所以宽度限制与我最初的发现相符。 请问ISI模块的高度限制是多少?我们能否通过 ISI 实现 8191 车道高度? 谢谢 Re: i.MX8MP Maximum Geometry for RAW Capture 请参考驾驶员说明,最大高度为 8191。 #define MXC_ISI_MIN_WIDTH 1U #define MXC_ISI_MIN_HEIGHT 1U #define MXC_ISI_MAX_WIDTH_UNCHAINED 2048U #define MXC_ISI_MAX_WIDTH_CHAINED 4096U #define MXC_ISI_MAX_HEIGHT 8191U https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
記事全体を表示
EdgeLock SE050/SE051 Capability Inquiry for Ed25519/X25519-Based IoT Device Hello NXP Team, We are evaluating the EdgeLock SE050/SE051 family for a Raspberry Pi based IoT device and would appreciate guidance on the most suitable part number. Our primary requirements are secure storage and hardware execution of cryptographic operations. The device is a Raspberry Pi 4 - running Raspberry Pi OS (Linux). We would like clarification on the following points: 1. Key Storage       - Can the SE050/SE051 securely store non-exportable private keys?    - Can certificates and public keys be stored in the secure element? 2. Key Generation       - Can the secure element generate key pairs internally?    - Specifically, does it support generation of Ed25519 and X25519 key pairs within the secure element? 3. Ed25519 Operations       - Can Ed25519 signing and signature verification be supported inside the secure element? 4. X25519 Operations       - Can X25519 key agreement (ECDH shared secret computation) be performed inside the secure element using a non-exportable private key? 5. AES Operations       - Does the secure element support AES encryption and decryption operations?    - If so, which AES modes are supported?   6. Storage read/write    - Storing/removing/accessing files like wifi passwords? 7. Linux / Raspberry Pi Integration       - Is there an SDK or middleware available for Raspberry Pi OS?    - Are there example applications demonstrating the above operations? 8. Product Selection       - Which EdgeLock SE050/SE051 variant would you recommend for the above requirements?    - What are the major differences between the recommended variants?    - Are there any newer EdgeLock products that would be a better fit for these requirements? Our intended use case is: - Ed25519 signing for device authentication / JWT generation - X25519 key agreement for mobile-device provisioning - AES encryption/decryption using derived session keys - Storage and handling of security files like Wifi passwords etc - Large-scale deployment of IoT devices If available, we would also appreciate links to any of these: - Relevant datasheets - Application notes - SDK documentation - Evaluation boards - Linux/Raspberry Pi examples Thank you for your assistance. Best regards, Sahil Pai Re: EdgeLock SE050/SE051 Capability Inquiry for Ed25519/X25519-Based IoT Device Hi @SahilPai , Please kindly have my comments as below: 1. Key Storage       - Can the SE050/SE051 securely store non-exportable private keys? //Yes, private keys are non-exportable on SE05x.    - Can certificates and public keys be stored in the secure element? // Yes, certs are stored as binary files within the SE , and public key can be stored standalone or together with the private key in SE05x. 2. Key Generation       - Can the secure element generate key pairs internally?// Yes, it supports.    - Specifically, does it support generation of Ed25519 and X25519 key pairs within the secure element?// Yes, Ed25519 and X25519 key pairs are supported. 3. Ed25519 Operations       - Can Ed25519 signing and signature verification be supported inside the secure element?// Yes, Ed25519 signing and signature verification are supported inside the SE05x. 4. X25519 Operations       - Can X25519 key agreement (ECDH shared secret computation) be performed inside the secure element using a non-exportable private key? //Yes, ECDH is performed with a private key within SE05x and an external  public key which can be stored in SE05x as well. 5. AES Operations       - Does the secure element support AES encryption and decryption operations? //Yes,    - If so, which AES modes are supported?// Support for AES Modes:CBC, ECB, CTR, GCM, CCM.   6. Storage read/write    - Storing/removing/accessing files like wifi passwords?//Yes, SE050/SE051 can store binary objects in its secure object store, including Wi-Fi credentials. 7. Linux / Raspberry Pi Integration       - Is there an SDK or middleware available for Raspberry Pi OS?// Yes, please refer to https://www.nxp.com/webapp/Download?colCode=SE05x-PLUG-TRUST-MW&appType=license for details.    - Are there example applications demonstrating the above operations?//Yes. 8. Product Selection       - Which EdgeLock SE050/SE051 variant would you recommend for the above requirements?// Either SE050E2 or SE051C2 can be used.    - What are the major differences between the recommended variants?// They both have the latest applet version, but SE051 supports applet upgrade while SE050 doesn't.    - Are there any newer EdgeLock products that would be a better fit for these requirements?//not yet so far.   Please kindly refer to https://www.nxp.com/products/SE050 and https://www.nxp.com/products/SE051 for more details.   Hope that helps,   Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
記事全体を表示