Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
SPI Bus Overview (Japanese blog) 0. Table of Contents table of contents What is SPI? 1.1 History and specifications 1.2 Controller/Target or Main/Subnode (Sub) Physical/Electrical Characteristics 2.1 Number of signal lines: Signal names 2.2 Push-pull. High impedance state when not transmitting 2.3 Clock Frequency protocol 3.1 Mode 3.2 Data Transfer Connection Topology 4.1 Parallel connection and daisy chain with chip select Reference materials 1. What is SPI? 1.1 History and specifications The SPI bus is a serial bus specification proposed by Motorola (now NXP Semiconductors) in the United States. The specification is said to have been established in the mid-1980s. SPI stands for " Serial Peripheral Interface " and was developed as a four-wire serial bus used to connect processors and peripheral chips. A three-wire SPI bus is also available as a derivative specification, but the original four-wire system is the basis. SPI has several variations in communication methods, such as signal polarity and data synchronization timing settings, so you need to be aware of this when using it. Like I²C, SPI is used to exchange data between chips, but each has its own advantages and disadvantages, as summarized in [Table 1]. SPI is used for applications that require faster data transfer . This is due to the difference in electrical specifications: I²C drives signals using open drain, while SPI drives signals using push-pull , making it easier to achieve higher speeds. Furthermore, in terms of data transfer speed, SPI is characterized by its ability to perform full-duplex communication, which allows simultaneous transmission and reception. On the other hand, SPI also has some disadvantages. The transfer data length and clock polarity are specified for each destination device, making it difficult to mix multiple types of devices. Also, when connecting multiple devices of the same type, a chip select signal is required for each device, which increases the number of signal lines, and when cascading devices, the data transfer length must be adjusted.   I²C SPI Number of lines 2 Data: SDA Clock: SCL 4 Data: SDO, SDI (MOSI, MISO) Clock: SCLK Chip select: CS speed ~400kHz 1MHz, 3.4MHz, 5MHz depending on mode Several hundred kHz to several tens of MHz Communication Direction bidirectional half duplex Bidirectional full duplex Connection Method Multidrop (parallel) Multiple Controllers vs. Multiple Targets Parallel or Daisy Chain Single Controller vs. Multiple Targets Signal Drive Open Drain (Pull-up resistor required) Push-pull Table 1: Comparison of I²C and SPI   1.2 Controller/Target or Main/Subnode (Sub) In SPI, transfers are also made in a master-slave relationship. Until now, the terms master and slave were commonly used, but these have now been changed to controller and target. They are also called main/subnodes (sub), retaining the initials "M/S" from the previous role names. From now on, this blog will deliberately use the terms main/subnodes (sub). In SPI, multiple mains cannot exist. Communication always takes place between one main and one or more targets. 2. Physical/Electrical Characteristics 2.1 Number of signal lines: Signal names The SPI bus is a four-wire synchronous serial interface. A synchronous serial interface is a method of sending and receiving data in synchronization with a clock signal, using one of the signal lines as the clock. There are two signal lines for data. One is used for data from the main to the sub and the other is used for data from the sub to the main. The other is a signal called chip select. SPI does not have a way to specify an address to specify the transfer target. Therefore, the chip select signal is used to specify the target device [Figure 1]. Signal names may be called by a variety of names. The following signal names are those used by OSHWA : SDO : Data output SDI : Data input SCK : Serial clock CS : Chip Select: CS In the above example, the names SDO and SDI are based on the direction of data input/output on each chip. In this case, the names of the pins are clear, but it is inconvenient to indicate the signal direction between the main and sub. Instead, the following signal names are commonly used on circuit diagrams, etc. This blog will stick to these terms. MOSI : Data from main to sub (Main Out Sub In) MISO : Data from sub to main (Main In Sub Out) SCLK : Serial clock CS : Chip Select: CS Of these signals, only MISO is a signal from the sub to the main, and all others are signals from the main to the sub. The signal direction does not change during communication. スクリーンショット 2025-02-03 6.18.59.png Figure 1: Controller and target. Signal names To save on the number of signals, for example when communication is only one way, one of the data lines may be omitted. There are also targets that allow transmission and reception to be time-multiplexed, allowing the use of only one data line. In this case, on the main side, MOSI/MISO are shorted using a resistor to combine the signals. 2.2 Push-pull. High impedance state when not transmitting Signals are output in a push-pull fashion. When no data is being transferred, the MOSI and MISO outputs are placed in a high-impedance state. This is to prevent interference with other communications when multiple subnodes are connected in parallel. The signal voltage is determined by the sub-node device, so it must be adjusted accordingly. If the voltage differs between the main and sub-nodes, voltage conversion is required. 2.3 Clock Frequency There are no specific regulations regarding clock frequencies. Clocks in the hundreds of kHz to several MHz range are typically used, with the upper limit determined by the specifications of the subnode device. Applications requiring high-rate data transfer may use clocks of several tens of MHz. In addition, in memory devices, there are also applications where multiple MOSI and MISO data lines are used to increase the transfer rate. 3. Protocol There are no strict rules regarding the protocol that determines the data transfer procedure, and it is freely determined for each subnode device. The main microcontroller has settings to support various subnode devices. The basic transfer procedure begins by asserting CS connected to the destination subnode. The transfer ends when CS is deasserted. CS is asserted and deasserted using a LOW and HIGH signal, but the polarity is dictated by the subnode device specifications. Many devices use MSB first for data bit ordering, but there are exceptions to this. There is also no specific rule about the number of bits used as the transfer unit. I have seen explanations that say it is 2 to 16 bits, but this is not the case as there are subnodes that use larger bit lengths as units (for example, 64 bits). 3.1 Mode SPI has settings called " modes ," which refer to combinations of clock polarity and edge selection, and there are four modes with two settings each [Figure 2]. Clock polarity is a setting called CPOL , which determines whether SCLK is LOW or HIGH when no data is being transferred. On the main side, setting this to 0 will make it LOW, and 1 will make it HIGH. Edge selection (phase) is called CPHA . This setting determines whether data is latched (taken in) on the first or second clock edge. A setting of 0 selects the first edge, and a setting of 1 selects the second edge. CPOL and CPHA can sometimes be combined to represent modes 0 to 3 [Table 2]. In addition, please note that there are also subnodes with reversed chip select polarity. スクリーンショット 2025-02-03 7.42.56.png Figure 2: Mode (CPOL, CPHA)     CPOL CPHA mode=0 0 0 mode=1 0 1 mode=2 1 0 mode=3 1 1 Table 2: Modes and CPOL, CPHA What is the "edge that latches data"? Data is sent and received in sync with the clock, but data changes on either the rising or falling edge of the clock. Figure 3 shows an example of data changing on the falling edge. The main side changes its MOSI output, and the subnode side changes its MISO output, in time with the falling edge of the SCLK output by the main side device. The next data changes on the next falling edge, but until then the state remains stable. The rising edge of the clock occurs exactly during this period, so data is captured from each other in time with this timing. This is the "latch edge." スクリーンショット 2025-02-03 6.54.45.png Figure 3: Data (MOSI/MISO) and clock (SCLK) synchronization 3.2 Data Transfer After the chip select is asserted, data is sent and received in synchronization with the clock. When the subnode receives that its own chip select is asserted, it takes in and outputs data in synchronization with the clock. [Figure 4] is an example of an SPI transfer. Data is exchanged in accordance with the clock while CS is asserted. Those familiar with logic circuits will see that this is achieved using a simple circuit using a shift register. スクリーンショット 2025-02-03 7.55.53.png Figure 4: Example of SPI transfer   4. Connection Topology 4.1 Parallel connection and daisy chain with chip select Multiple subnodes are connected as shown in [Figure 5]. A chip select is provided for each subnode, and communication is carried out by specifying the sender and receiver using each signal. Alternatively, to reduce the number of CS signals, a daisy-chain connection can be used, and communication can be carried out by treating the subnodes as a single subnode with an extended bit length [Figure 6]. As mentioned earlier, care must be taken when connecting multiple types of subnodes to the same SPI bus. As mentioned earlier, the "mode," chip select polarity, and data bit length may not be the same. For this reason, you may need to switch settings or make adjustments in the hardware each time you communicate with each subnode. スクリーンショット 2025-02-03 8.25.09.png Figure 5: Parallel connection   スクリーンショット 2025-02-03 8.25.21.png Figure 6: Daisy chain connection 5. Reference materials OSHWA Role and Signal Names [English] Wikipedia page on "SPI" : Signal names and main/subnode names in this blog are based on this description . Interface March 2024 issue (CQ Publishing) : Special feature "Serial communication from scratch [UART/I2C/SPI with Pico]" NXP System Management I²C, I3C, SPI Selector Guide NXP Community Blog: I3C: The Next Serial Bus NXP Community Blog: An Overview of the I²C Bus [Originally published in Interface, March 2024 issue (CQ Publishing), "Building I2C & SPI from Scratch ④... SPI Communication Standards," pp. 71-73. The section explaining the communication specifications has been excerpted and revised for this blog post.] Change history: 2025-02-03: First Edition 2025-02-25: Added a link to the "NXP System Management I²C, I3C, SPI Selector Guide" in section "5. Reference Materials". 2025-05-01: Corrected the table of contents (deleted items), corrected the item name in Section 2.2. 2026-07-24: Fixed broken links in "2.1 Number of Signal Lines: Signal Names" and "5. Reference Materials" to "OSHWA Role Names and Signal Names". ========================= We are currently unable to respond to comments in the "Comment" section of this post. We apologize for the inconvenience, but when making inquiries, please refer to `` Technical Questions to NXP - How to Contact Us( Japanese Blog) ''. (If you are already an NXP distributor or have a relationship with NXP, you may ask the person in charge directly.) SPI bus used for communication between microcontrollers/processors and peripheral devices. Although this serial bus is so commonly used, I would like to take this opportunity to summarize its origins. communication standards Interface Japanese blog
記事全体を表示
How to PORT/PINS 1 Table of Contents • Introduction • Pins Configuration • Configure Port Component • Conclusion • References 2 Introduction Before a microcontroller can interact with external hardware, its pins must be configured correctly. Whether you want to read a button state, drive an LED, communicate with a sensor, or use a peripheral, the first step is to configure the corresponding pins. 3 Pins Configuration First, identify the pin you want to use. In this example, we will use the following pin: RGBLED0_RED PTA29 GPIO29 Note: When working in S32 Configuration Tools, the pin MSCR value (third line) is not required. However, it will be needed later if you also configure the same pins in EB tresos. Configure the pins according to their intended use: input, output, or input/output. To begin, open the Pins Tool by clicking the Pins button in the upper-right corner. configToolView.png In the Pins Tool, the pins are organized into Functional Groups. In the default projects provided with the Model-Based Design Toolbox, these groups are arranged based on the peripheral to which the pins are routed. functionalGroups.png For this step, focus on the Pins tab in the upper-left area of the window. Search for the pin you want to configure; in this example, PTA29. pinPinsView.png If the desired functionality is already routed to a different pin, first disable that routing by clearing the corresponding selection before assigning it to PTA29. Next, update the identifier and label as needed, then enable the routing by selecting the checkbox on the left. This opens the routing selection dialog. selecttypeofsignal.png Select SIUL2:gpio,29 , as it matches the intended functionality. A second dialog then prompts you to select the pin direction. directionofpin.png  In this example, the LED is configured as Input/Output, matching the configuration used by the example project. Depending on the intended use of the pin, a different direction may be required — for example, a push button is typically configured as an input. Additional examples can be found in the default projects provided with the Model-Based Design Toolbox. 4 Configure Port Component The Port component must reflect the same pin configuration defined in the Pins Tool. After returning to the Peripherals Tool, the Port component may be highlighted in red because the pin configuration was modified in the Pins Tool and has not yet been updated in the Port component. PortComponent.png  In the default Model-Based Design Toolbox projects, PortPins are grouped into PortContainers according to their associated peripheral, such as Dio_Pins or Can_Pins . Locate the Dio_Pins PortContainer and update the PortPin entries so that they match the values configured in the Pins Tool. rgbled.png The pin will already contain the MSCR value inherited from the Pins configuration. Update the pin name as desired so it can be easily identified in the model, then repeat the process for each additional pin. The PortPin Id uniquely identifies each PortPin entry. The identifier must remain unique across all PortContainers. Note: If a duplicate PortPin Id value is used, the configuration will report an error. Assign a unique PortPin Id value to each configured pin. For example, a configuration containing 40 pins can use identifiers within the range described by the tool configuration. 5 Conclusion Once the pin configuration is complete and the Port component has been updated accordingly, you can continue with the configuration of the software components that will use those pins. 6 References NXP Model-Based Design Toolbox – Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344
記事全体を表示
How to DIO 1 Table of Contents • Introduction • Component Configuration  • Conclusion • References 2 Introduction Before configuring the DIO component, make sure that the pins you intend to use have already been configured in both the Pins Tool and the Port component. If not, refer to the previous articles on pins and port configuration. 3 Component Configuration In order to configure the Dio peripheral, press on the Dio component on the left side of the screen for the Dio Configuration tab to be opened. There, press on the Dio Config tab. portpin.png Understanding how the DioPort and DioChannel are organized might prove useful later. The number present under the DioPort label represents the corresponding value of the Dio port that you want to access. Below you can find a table with the correspondence between the values and the registers. Register half DioPort value AL 0 AH 1 BL 2 BH 3 CL 4 CH 5 DL 6 DH 7 EL 8 EH 9 Each of those is half of a register and together every line forms a 32-bit register. For example, AL and AH contain all the pin values that are assigned to PTA. AL contains the first 16 pins and AH contains the next 16 pins. For example, the RGBLED0_RED pin is assigned to PTA29. From that we can conclude that, since 29 is higher than 15 (the 16th value of AL, since the first value is 0), the PTA29 pin must be assigned to the AH register. To reiterate, the PTA0–PTA15 pins belong to the AL register while the PTA16–PTA31 (the value must be offset by -16 when computing the Id) pins belong to the AH register, and this is true for the rest of the registers too: PTB, PTC, PTD, PTE. Note: When computing the channel Id for pins in the upper half of a port (e.g. PTA16–PTA31), subtract 16 from the pin number. To create a new channel, select the appropriate DioPort and click the + button next to DioChannel. A new channel entry will be created. Fill in the required channel information according to the pin that was previously configured in the Pins Tool and Port component. ADDNEWCHANNEL.png Repeat this process for each newly configured pin, ensuring that the channel is added under the correct DioPort. 4 Conclusion After configuring the required DioChannels, save the configuration and regenerate the code. The configured DIO channels can then be used by the application to access the corresponding digital inputs and outputs. 5 References NXP Model-Based Design Toolbox – Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344
記事全体を表示
Software and Hardware Setup for the S32N55 Communication Hub 1 Table of Contents • Introduction • Required Software • Required Hardware • Communication and Board-Specific Setup • References • Conclusion   2 Introduction The Main Node is the central application target used throughout this project. It sits between the simulation environment running on the host PC and the physical hardware that represents the various vehicle domains. While the previous article introduced the purpose of the Main Node and its role within the overall system, this article focuses on the environment that makes that functionality possible. Developing and validating the Main Node requires more than a target board. The application is modeled, tested, configured, deployed, and monitored using a collection of software tools that work together with the hardware platform. Understanding this environment is important for anyone interested in reproducing the setup or following the remaining articles in the series. This article describes the software components used during development, the hardware platform used to run the application, and the communication infrastructure that connects the Main Node to the rest of the system. CristinaB_0-1784806267828.png Figure 1. Position of the Main Node within the system architecture. 3 Required Software The Main Node software environment combines MathWorks modeling tools with NXP target support and development utilities. Together, these tools provide the workflow used to model the application, generate code, configure the hardware platform, deploy the software, and observe its behavior during validation and runtime analysis. 3.1 Modeling and Application Development The Main Node application is developed as a Simulink model. MATLAB and Simulink are used to describe the behavior of the application before any software is deployed to hardware. Communication interfaces, application states, signal handling, and system-level functionality are assembled and validated within the modeling environment, allowing development to begin long before the target board is involved. The software environment used for this project includes: MATLAB R2024a or newer Simulink Simulink Coder Embedded Coder MATLAB Coder Stateflow These tools provide the code-generation workflow that transforms the model into embedded software capable of running on the target hardware. 3.2 Network Definition and Validation Communication is one of the primary responsibilities of the Main Node. It exchanges information with the simulation environment, the zonal gateways, and the remaining vehicle-domain nodes through a shared CAN network. Vehicle Network Toolbox is used to bring those communication interfaces directly into MATLAB and Simulink. By using the same DBC definitions during development and validation, communication behavior can be verified before deployment and remain consistent across the complete system. The shared DBC maintained with CANdb++ acts as a common communication contract between all participating nodes. Required tools: Vehicle Network Toolbox CANdb++ 3.1 or newer 3.3 Target Support and Code Generation The bridge between the Simulink model and the target hardware platform is provided by the required NXP Model-Based Design Toolbox package. The toolbox provides: Main target platform support Peripheral integration blocks Build integration Deployment support FreeMASTER integration Using these components, the generated software can be executed directly on the target hardware without requiring manual integration of low-level peripheral code. 3.4 Build and Configuration Environment After code generation, the application is built and deployed using the NXP software toolchain integrated inside Model-Based Design Toolbox package. These tools are used to compile, link, and deploy the generated software to the target board. In parallel, EB tresos is used to maintain the low-level configuration required by the Main Node environment. CAN communication, UART telemetry, I2C initialization, interrupt configuration, and board-level peripheral settings are all managed through this configuration flow. Together, these tools ensure that the generated software and the target configuration remain aligned throughout development. 3.5 Runtime Monitoring and Validation Once deployed, the Main Node can be observed through two complementary mechanisms. FreeMASTER Lite provides runtime visibility into application variables and internal states, while CAN analysis tools are used to inspect the communication exchanged across the network. These tools are used throughout development and validation activities to verify both application behavior and network communication. CristinaB_1-1784806393422.png Figure 2. Development workflow used by the Main Node application. 4 Required Hardware Unlike the peripheral nodes, the Main Node is responsible for connecting the simulation environment with the physical hardware network. As a result, the hardware environment includes both the target board and the supporting infrastructure used during development, validation, and system-level execution. 4.1 S32N55 Board The Main Node application executes on an S32N55 board selected for the central application role. Within this setup, the board serves as the central application platform and hosts the software responsible for coordinating communication between the simulation environment and the zonal gateways. The board provides: CAN FD communication interfaces UART communication interfaces Debug and deployment connectivity I2C peripherals Processing resources required by the Main Node application The Main Node target board is the primary hardware platform referenced throughout this article series. 4.2 Host PC The host PC provides the environment used to interact with the full setup. Depending on the activity being performed, it may host: MATLAB and Simulink RoadRunner simulation environments FreeMASTER Lite CAN analysis software The host PC communicates with the Main Node both through the CAN network and through the dedicated telemetry interface used by FreeMASTER. 4.3 CAN Analyzer A CAN analyzer is used during development and validation to monitor network traffic exchanged between the Main Node and the zonal gateways. Beyond debugging, the analyzer also provides a convenient method of validating DBC definitions, message timing, and network integration behavior before the full setup is assembled. 5 Communication and Board-Specific Setup Several aspects of the Main Node environment are specific to the selected target board and are worth understanding before reproducing the setup. 5.1 Communication Topology The Main Node does not communicate directly with every vehicle-domain node. Instead, it exchanges information with the two zonal gateways, which distribute the relevant signals toward the corresponding vehicle-domain nodes. This arrangement keeps the system organized around a zonal architecture while allowing each subsystem to be developed and validated independently. 5.2 CAN Transceiver Initialization One hardware-specific detail of the target board concerns the external CAN transceiver. Note: Before CAN communication becomes available, the transceiver must first be switched from standby mode into normal operation. This transition is not controlled directly through a dedicated GPIO. Instead, it is performed through an I2C-connected port expander located on the board. As a result, the startup sequence requires an I2C initialization step before the FlexCAN controller can begin communication. CristinaB_2-1784806522309.png Figure 3. CAN transceiver enable sequence on the target board. 5.3 FreeMASTER Telemetry Interface In addition to the CAN network, the Main Node exposes runtime telemetry through a dedicated UART connection used by FreeMASTER Lite. This interface is used throughout validation and runtime analysis to visualize application variables and monitor system behavior in real time. 6 References Model-Based Design Toolbox (MBDT) Community NXP S32N Vehicle Super-Integration Processors MathWorks Vehicle Network Toolbox NXP FreeMASTER Run-Time Debugging Tool 7 Conclusion This article introduced the environment used to develop, deploy, and validate the Main Node application. It described the software workflow, the hardware platform, and the communication infrastructure that connect the Main Node to both the simulation environment and the physical hardware network. Particular attention was given to the Main Node's position within the system topology, the UART-based telemetry interface used by FreeMASTER, and the I2C-controlled CAN transceiver initialization required by the target board. The next article moves beyond the enablement layer and focuses on the Main Node application itself, describing the information it receives, the processing it performs, and the outputs it publishes back into the system network.
記事全体を表示
Software & Hardware Environment for Parking Sensor System 1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion 2 Introduction This article focuses on the software and hardware environment required to build, deploy, and monitor the parking sensor node. On the software side, it presents the MATLAB/Simulink workflow, NXP's Model-Based Design Toolbox (MBDT) for S32K1xx devices, FreeMASTER, and the supporting build environment. On the hardware side, it describes the S32K144-Q100 evaluation board, the MaxBotix MB1020 ultrasonic sensors, the wiring approach, and the communication/debug interfaces used in the setup. The goal is to provide a clear setup foundation before moving into the next article, where the internal model architecture, control flow, and application behavior will be described in more detail. 3 Required Software The parking sensor application is developed using a model-based workflow built around MATLAB, Simulink, Stateflow, and NXP's MBDT for S32K1xx devices. The Simulink model remains the main development artifact, while the supporting toolchain is used to generate code, build the application, download it to the target board, and monitor the running system. 3.1 MATLAB, Simulink and Stateflow MATLAB and Simulink provide the main environment for developing the parking sensor application model. Simulink and Stateflow are used to organize the application structure, configure the processing blocks, and prepare the model for deployment on the S32K144 target. georgevictor_3-1784704792783.png Figure 1. PSS top-level model in Simulink 3.2 NXP Model-Based Design Toolbox for S32K1xx NXP's Model-Based Design Toolbox (MBDT) for S32K1xx acts as the bridge between the Simulink model and the S32K144 hardware. It provides dedicated blocks for configuring and using the microcontroller peripherals required by the parking sensor node. In this project, MBDT is used for Analog-to-Digital Converter (ADC) acquisition, General-Purpose Input/Output (GPIO) control, Local Interconnect Network (LIN) communication, and FreeMASTER for real-time data visualisation. This allows the model to interact directly with the target hardware without requiring the developer to manually implement low-level peripheral code. The key point for this article is that MBDT keeps the hardware configuration close to the model. The detailed usage of each block and how the blocks are arranged inside the application will be explained in the model architecture article. 3.3 Code Generation and Deployment Flow The application is prepared for embedded deployment through the code generation flow supported by Simulink, Embedded Coder, ARM Cortex-M support, and NXP MBDT. From the developer's perspective, the main workflow remains inside Simulink: the model is configured, generated, built, and deployed to the S32K144 board. NXP's toolchain environment integrated in MBDT provides the compiler and target support used by the build process. In this setup, it does not need to be treated as a separate development step. The generated application can be downloaded to the S32K144-Q100 evaluation board through the MBDT build/deploy workflow using the on-board JTAG debug interface. This keeps the setup straightforward: once MBDT is installed, the application can be built and programmed from the Simulink workflow. 3.4 FreeMASTER FreeMASTER is used as the runtime monitoring tool during development. It provides visibility into the embedded application while it is running on the S32K144 board. In the Parking Sensors System (PSS) setup, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, processed distance values, and selected application variables. This helps during bring-up and validation because the developer can check the behavior of the generated application without adding custom debug code. Note: The FreeMASTER channel is separate from the LIN communication used by the parking node to exchange data with the zonal controller. 3.5 Toolchain Versions The following software components are used for this demo setup: Component Version / Variant MATLAB / Simulink / Stateflow R2024a or newer Embedded Coder Matching MATLAB release ARM Cortex-M support Matching MATLAB release NXP MBDT for S32K1xx 4.3.0 FreeMASTER 3.2 or newer These versions define the reference environment used to build and deploy the parking sensor application. 4 Required Hardware The hardware setup is centered on the S32K144-Q100 evaluation board, which acts as the local parking sensor node. Four MaxBotix MB1020 ultrasonic sensors are connected to the board through analog inputs and control lines. The board also connects to the zonal controller over LIN and to the development PC through the FreeMASTER interface. georgevictor_0-1784704554486.png Figure 2. Parking Sensor Node Hardware Setup 4.1 NXP S32K144-Q100 Evaluation Board The S32K144-Q100 evaluation board is the target hardware used for the parking sensor node. It provides the microcontroller platform required to run the generated application and includes the peripherals needed by the demo: ADC channels for the ultrasonic sensor outputs, GPIO pins for sensor control, LIN support for communication with the zonal controller, and a debug interface for programming and monitoring. In this setup, the board performs the hardware-side interaction with the sensors and communication interfaces. georgevictor_1-1784704591517.png Figure 3. S32K144-Q100 Evaluation Board Used for the Parking Sensor Node The board configuration used by the project is summarized below. Setting Value Device S32K144 Package 100-LQFP SRAM size 64 KB External crystal 8 MHz System clock 80 MHz Memory model FLASH Debug interface JTAG The exact configuration is provided by the MBDT configuration block in the Simulink model. 4.2 MaxBotix MB1020 Ultrasonic Sensors The demo uses four MaxBotix MB1020 sensors, also known as LV-MaxSonar-EZ ultrasonic sensors. Each sensor provides an analog voltage output that varies with the measured distance, which makes the device easy to connect to the S32K144 ADC inputs. The sensor also includes an RX pin that can be used as an enable or control input. 4.3 Sensor Wiring and Pin Mapping Each MB1020 sensor is connected to the S32K144-Q100 board using two main signal types. The analog output pin is connected to one ADC input channel, while the RX pin is connected to a GPIO output and can be used by the application to control the sensor. Power and ground are distributed from the evaluation board through the breadboard. The following pin mapping comes from the PSS model connection annotation. Sensor Analog pin to S32K144 RX enable pin to S32K144 SONAR1 — Left AN → PTB2, ADC0_SE6, J2.11 RX → PTA11, J1.2 SONAR2 — Center Left AN → PTB3, ADC0_SE7, J2.9 RX → PTA17, J1.4 SONAR3 — Right AN → PTA0, ADC0_SE9, J5.7 RX → PTD10, J1.6 SONAR4 — Center Right AN → PTA1, ADC0_SE15, J5.5 RX → PTD11, J1.8 Power and ground connections are defined as follows. Signal Connection GND Breadboard black rail → J13.4 on S32K144-Q100 VCC 5 V Breadboard red rail → J3.9 on S32K144-Q100 georgevictor_2-1784704626909.png Figure 4. Sensor Wiring Between the S32K144-Q100 Board and MB1020 Sensors 4.4 ADC Configuration The MB1020 sensors provide analog voltage outputs, so the S32K144 ADC is used to convert these signals into digital values. In the project setup, ADC0 is configured for software-triggered acquisition and uses the channels assigned to the four ultrasonic sensors. Setting Value ADC instance ADC0 Resolution 12-bit Trigger source Software trigger Voltage reference 5 V / 0 V Used channels ADC0_SE6, ADC0_SE7, ADC0_SE9, ADC0_SE15 Averaging Enabled, 4 samples This section describes only the peripheral setup. The timing of the acquisitions and the conversion from ADC values to distance measurements will be covered in the next article. 4.5 LIN Interface to the Zonal Controller The parking node communicates with the zonal controller using LIN. In this setup, the parking node is configured as a LIN slave, while the zonal controller acts as the LIN master. Setting Value Peripheral LPUART2 in LIN mode Node function Slave Baud rate 19200 bit/s Checksum Enhanced LIN 2.x LIN TX pin PTD7 LIN RX pin PTD6 The physical connection between the parking node and the zonal controller uses LIN and ground lines. Signal Zonal board pin Parking S32K144-Q100 pin LIN J31.8 J11.1 GND J31.2 J11.4 4.6 FreeMASTER Debug Channel FreeMASTER uses a dedicated serial channel that allows the developer to monitor the application on the PC while the parking node continues to communicate with the zonal controller. Setting Value Interface LPUART1 Baud rate 115200 bit/s RX pin PTC6 TX pin PTC7 Usage Runtime monitoring and variable visualization 5 References Developing a Parking Sensor System with Model-Based Design Toolbox 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 NXP S32K144 Reference Manual and S32K144-Q100 evaluation board user guide MaxBotix MB1020 / LV-MaxSonar-EZ1 datasheet MathWorks documentation: MATLAB, Simulink, Stateflow, Embedded Coder, ARM Cortex-M support FreeMASTER Run-Time Debugging Tool 6 Conclusion This article described the software and hardware environment required to build and run the Parking Sensor System. The software side is based on MATLAB, Simulink, Stateflow, NXP MBDT, code generation support, and FreeMASTER. The hardware side uses the S32K144-Q100 evaluation board, four MaxBotix MB1020 ultrasonic sensors, ADC input channels, GPIO control lines, LIN communication, and a dedicated FreeMASTER serial channel. With this environment in place, the PSS model can be built, downloaded to the S32K144 board, monitored in real time, and connected to the zonal demo setup. The next article will move inside the model and explain the application architecture, including the sensor acquisition flow, model structure, distance conversion, and LIN communication behavior.
記事全体を表示
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.
記事全体を表示
How to use S32 Design Studio MCP Integration How to use S32 Design Studio MCP Integration,Are there any relevant materials and documents? Re: How to use S32 Design Studio MCP Integration Hi,  unfortunately the documentation and usage examples are still in development. I hope it will be released soon for external use, but don't know the exact date. 
記事全体を表示
LX2160A: Pull down value on receiver for SerDes lanes not used Hello, Chip: LX2160A The application note AN5407 specifies pull down on SerDes lanes if not used:  If some SerDes lanes are a no-connect, pull down their receiver pins to GND. Could you tell me the pull down value please? Or should I connect the receiver pins directly to GND? Thanks. Re: LX2160A: Pull down value on receiver for SerDes lanes not used Hello, The AN5407 language "pull down their receiver pins to GND" is intentionally ambiguous about method — NXP's clarification is that a direct 0 Ω connection to GND is the correct and preferred approach. SerDes power-down Even with the RX pins tied to GND, if the SerDes block remains powered, AN5407 also recommends powering down unused lanes via firmware: configure the General Control 0 register during the PBI phase to power down unused SerDes lanes. If the entire SerDes block is already powered down, individual lane power-down is not needed Regards
記事全体を表示
ELE能否将密钥保留在主机无法访问的非易失性存储中? 您好, 我想咨询一下关于 EdgeLock 安全隔离区 (ELE) 的持久密钥存储的问题。 根据我对 KW47 网络安全参考手册的理解,ELE 用于加密操作的密钥可以使用密钥存储服务持久存储。我对典型流程的理解如下: 1. 为目标密钥创建密钥 Blob 并将其导出到主机。 2. 将导出的密钥 Blob 存储在非易失性存储器(例如闪存)中。 3. 当需要密钥进行加密操作时,导入密钥块并通过 ELE 使用该密钥。 在这种方法中,密钥块由 ELE 生成,因此主机无法读取实际的密钥材料。然而,由于密钥块本身由主机存储在闪存中,因此主机似乎仍然可以删除或覆盖密钥块。 我的问题是: 是否有一种方法可以将密钥(或其密钥块)存储在 ELE 可访问但主机不可访问的非易失性存储区域中,从而允许 ELE 执行加密操作,而无需在任何时候将密钥材料或密钥块暴露给主机? 换句话说,ELE 是否有可能完全在安全区域内拥有和管理持久密钥存储,从而使主机永远不会直接处理密钥或密钥块? 感谢您事先的指导。 Re: Can ELE Retain Keys in Host-Inaccessible Non-Volatile Storage? 嗨@t_hosomi ,希望你一切都好。 您对 NVM 流程中密钥生成和存储的理解是正确的。 然而,由于 ELE 没有非易失性存储器(如 SRM 的 10.3.1 节所述),因此唯一支持的路径是将导出的密钥 blob 存储在主机的 NVM 中。 请告诉我这些信息是否有帮助。 Re: Can ELE Retain Keys in Host-Inaccessible Non-Volatile Storage? 你好 RomanVR, 感谢您的回复。 我了解到 ELE 本身不提供非易失性存储器,因此持久密钥数据必须存储在主机的非易失性存储器中。 感谢您澄清这一点。
記事全体を表示
LPC54113 电源 API 我想了解如何使用“power”函数的API。通过 SDK,我发现这个函数可以直接用于某些函数。但是,与 IAP API 不同,它没有提供入口点或使用说明。 1123HENRY_0-1784703504100.png 1123HENRY_1-1784703542044.png LPC541XX Re: LPC54113 Power API 嗨@jcxz 是的,你说得对。 您可以参考其他 SDK,其中包含有关 POWER API 的更详细说明。 BR 爱丽丝 Re: LPC54113 Power API 通过下载 54 系列其他芯片的 SDK,我找到了 POWER_Type 和 POWER_BASE。谢谢。 Re: LPC54113 Power API 对于我的 LPC54S018,我从 NXP 网站下载了 SDK。它包含了 PowerAPI、ClockAPI 等函数。 例如:POWER_SetVoltageForFreq(...)等。 它还描述了调用 API 函数的入口点和原型。 我认为LPC54113的情况也类似。
記事全体を表示
EB tresosのアクティベーションコードが失敗しました AUTOSARでEBtresosを使おうとしているのですが、アクティベートできませんでした。 アクティベーションコード: 7416-E905-5CC2-F20A ERROR: flxActAppActivationSend (50040,41147,10248) 指定された数量が許容最大数量 (0) を超えています。 FlexNet Operations Serverへの接続に失敗しました。 だからEBtresosを使うにはもう一つのアクティベートコードが必要です。 どうもありがとうございます。 Re: EB tresos activation code failed ご辛抱いただきありがとうございます。 社内チームがウェブページ上のアクティベーションコードを更新しました。 最新の認証コードを確認するには、以下のリンクをクリックしてください。 S32K3 標準ソフトウェア - > オートモーティブ SW - EB tresos Studio / AUTOSAR 設定ツール - > EB tresos Studio 29.0.0 Re: EB tresos activation code failed ハイ ご迷惑をおかけして申し訳ございません! この件については既に社内チームに報告済みです。返信があり次第、ご連絡いたします。   よろしくお願いいたします ロビン Re: EB tresos activation code failed こんにちは。NXPのウェブサイトで更新されたアクティベーションコードは、引き続き7416-E905-5CC2-F20Aです。今日アクティベートしようとしたのですが、やはり失敗しました。 ERROR: flxActAppActivationSend (50040,41147,10248) 指定された数量が許容最大数量 (0) を超えています。 FlexNet Operations Serverへの接続に失敗しました。 Re: EB tresos activation code failed 前回の返信をご覧ください。アクティベーションコードが更新されました。 EBTresosページのアクティベーションコードがまだ変更されていないバージョンを教えてください。内部チームに報告して更新を依頼します。
記事全体を表示
TJA1120A RGMIIモード - 遅延設定 これはTJA1120Aのデバイスツリーです - cpsw_port1、cpsw3g_phy0 &cpsw_port1 { status = "okay"; phy-mode = "rgmii-txid"; phy-handle = <&cpsw3g_phy0>; }; &cpsw_port2 { status = "okay"; phy-mode = "rgmii"; phy-handle = <&cpsw3g_phy1>; }; &cpsw3g_mdio { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_mdio1_pins_default>; cpsw3g_phy0: ethernet-phy@0 { compatible = "ethernet-phy-id001b.b031"; reg = <4>; }; cpsw3g_phy1: ethernet-phy@1 { compatible = "ethernet-phy-id0022.1620"; reg = <0>; txc-skew-ps = <900>; rxc-skew-ps = <900>; rxd0-skew-ps = <420>; rxd1-skew-ps = <420>; rxd2-skew-ps = <420>; rxd3-skew-ps = <420>; txd0-skew-ps = <420>; txd1-skew-ps = <420>; txd2-skew-ps = <420>; txd3-skew-ps = <420>; rxdv-skew-ps = <420>; txen-skew-ps = <420>; }; }; ここでは、TJA1120Aのphy-modeとして「rgmii-txid」を指定します。 しかし、レジスタRGMII_TXC_DELAY_CONFIGを読み取ると、 0x0014が読み取られ、これは遅延なし(15ビット目)を意味し、 RGMII_RXC_DELAY_CONFIGは0x8014を読み取り、これは遅延が設定されている(15ビット目)ことを意味します。 また、DTでphy-modeを「rgmii-rxid」に変更すると、 RGMII_RXC_DELAY_CONFIGは0x0014、 RGMII_TXC_DELAY_CONFIGは0x8014になります。 DTで「rgmii」を設定し、phytoolを使用してこれらのレジスタを設定してみましたが、完全に反映され、pingが開始され、その後RGMII_RXC_DELAY_CONFIGの15ビット目がHIGHに設定され、 RGMII_TXC_DELAY_CONFIGの15ビット目がLOWに設定されました。 物理モードのDT設定において、なぜこのような反転現象が発生するのかを理解したい。 私たちのAM62A7ベースのECUでは、PCBがRX_Clockの内部遅延を必要としているため、「rgmii-txid」が設定されました。問題なく動作しています。 また、DTSが処理してくれるのであれば、このPHYモードにおけるピンストラップの使用についても知りたいです。 Re: TJA1120A RGMII Mode- Delay Config こんにちは、 TJA1120Aドキュメントによると、RGMIIの遅延構成はレジスタ名とレジスタ内で記述された遅延が直接一致しないため、やや混乱を招くことがあります。 デバイスDS内のRGMII_RXC_DELAY_CONFIG/RGMII_TXC_DELAY_CONFIGレジスタのビット説明を参照してください。 0xAFCC RGMII_RXC_DELAY_CONFIG: ビット15 = 内部TXC遅延を有効にする 0xAFCD RGMII_TXC_DELAY_CONFIG: ビット15 = 内部RXC遅延を有効にする   したがって、設定を確認する際に重要なのは、実際のレジスタビットの記述と初期化後の最終レジスタ読み返し値です。 また、ピンストラップはリセット後のデフォルト設定のみを定義する点に注意してください。ソフトウェアドライバは後でMDIOでこれを上書きできるため、システム起動後にレジスタを読み返すことで有効な構成を検証する必要があります。 また、同じRGMIIクロック遅延がMAC側とPHY側の両方で有効化されていないかも、基板のタイミング設計で意図されていないことを確認してください。 BR、ペトル
記事全体を表示
RT1010/RT1011 FLEXIO EDMA 我使用 iMX RT1011 Nano 套件 不错的板 我尝试从移位器 0 设置 8 位并行的 EDMA Flexio。 定时器 0 设置为 30MHz,EDMA 发送 512 字节(每个请求 1 字节) 代码: FLEXIO_DEV->SHIFTCTL[TX_SHIFTER] = FLEXIO_SHIFTCTL_TIMSEL(WR_TIMER) | FLEXIO_SHIFTCTL_TIMPOL(0U) | FLEXIO_SHIFTCTL_PINCFG(3U) /* 输出 */ | FLEXIO_SHIFTCTL_PINSEL(DATA_PIN_START) | FLEXIO_SHIFTCTL_PINPOL(0U) | FLEXIO_SHIFTCTL_SMOD(2U); /* 传输 */ /* 定时器0:写保护选通,每字节一个脉冲 * TIMCMP 低字节 = (flexio_clk / (2*wr_clk)) - 1 * TIMCMP[15:8] = (beats*2)-1 = 1,表示每次移位加载一个字节 */ timDiv = (flexioClk_Hz / (2U * wrClock_Hz)); 如果 (timDiv != 0U) { timDiv -= 1U; } timDiv &= 0xFFU; FLEXIO_DEV->TIMCMP[WR_TIMER] = (1U << 8U) | FLEXIO_DEV->TIMCMP[WR_TIMER] = (1U << 8U) |蒂姆迪夫; FLEXIO_DEV->TIMCFG[WR_TIMER] = FLEXIO_TIMCFG_TIMOUT(1U) | FLEXIO_TIMCFG_TIMDEC(0U) | FLEXIO_TIMCFG_TIMRST(0U) | FLEXIO_TIMCFG_TIMDIS(2U) /* 禁用比较 */ | FLEXIO_TIMCFG_TIMENA(2U) /* 高触发时启用 */ | FLEXIO_TIMCFG_TSTOP(0U) | FLEXIO_TIMCFG_TSTART(0U); FLEXIO_DEV->TIMCTL[WR_TIMER] = FLEXIO_TIMCTL_TRGSEL((4U * TX_SHIFTER) + 1U) /* Shifter0 标志 */ | FLEXIO_TIMCTL_TRGPOL(1U) /* 低电平有效 */ | FLEXIO_TIMCTL_TRGSRC(1U) /* 内部 */ | FLEXIO_TIMCTL_PINCFG(3U) /* 输出 */ | FLEXIO_TIMCTL_PINSEL(WR_PIN) | FLEXIO_TIMCTL_PINPOL(1U) /* WR 低电平有效 */ | FLEXIO_TIMCTL_TIMOD(1U); /* 双 8 位波特率/位 */ /* 启用来自 Shifter0 的 DMA 请求 */ FLEXIO_DEV->SHIFTSDEN |= (1U << TX_SHIFTER); /* 启用 FlexIO */ FLEXIO_DEV->CTRL |= FLEXIO_CTRL_FLEXEN_MASK; 我在逻辑分析仪上看到了信号。 看起来和我预期的一样,但我在某些 512 包中发现数据缺失。 我的意思是,比如先发送 200 字节,然后停止,之后再发送所有 512 个字节。 扎希 Re: RT1010/RT1011 FLEXIO EDMA 你好@TZAHI , 非常感谢您对我们产品的关注以及对我们社区的使用。 最有可能的检查方向是:在 30 MHz WR 时钟下,eDMA 能否足够快地持续填充 FlexIO SHIFTBUF。 在当前每次请求传输一个字节的配置下,DMA 请求速率可能会非常高。这对于 eDMA、总线仲裁和 FlexIO SHIFTBUF 重新填充时间来说可能非常紧张。 一个可能的症状是变速箱换挡器运转不畅。请在传输失败后立即检查 SHIFTERR,然后再重新初始化或清除 FlexIO: mayliu1_0-1784792340391.png 如果可能的话,请尝试提高 CPU/总线时钟频率,或者将 WR 时钟频率降低到 30 MHz 以下,例如降低到 20 MHz 或 10 MHz。如果传输在较低的 WR 时钟频率下变得稳定,则强烈表明该问题与 DMA/FlexIO 的重新填充时序有关。 希望对你有帮助 顺祝商祺! 5月
記事全体を表示
LPC54113 Power API 「power」関数のAPIの使い方を知りたいです。SDKを通じて、この関数は特定の関数に直接使えることがわかりました。しかし、iap APIとは異なり、エントリーポイントや使用方法に関する説明は提供されていません。 1123HENRY_0-1784703504100.png 1123HENRY_1-1784703542044.png LPC541XX Re: LPC54113 Power API こんにちは、 @jcxzさん はい、おっしゃる通りです。 POWER APIのより詳細な説明を含む他のSDKを参照することもできます。 BR アリス Re: LPC54113 Power API 54シリーズの他のチップのSDKsをダウンロードすることで、私はPOWER_TypeとPOWER_BASEを見つけることができました。ありがとうございます。 Re: LPC54113 Power API 私のLPC54S018はNXPのウェブサイトからSDKをダウンロードしました。PowerAPI、ClockAPIなどの機能が含まれています。 例えば、POWER_SetVoltageForFreq(...) など。 また、API関数を呼び出すためのエントリーポイントとプロトタイプについても説明しています。 LPC54113についても同様だと思います。
記事全体を表示
LX2160A:接收器上未使用的 SerDes 通道的下拉值 你好, 芯片: LX2160A 应用笔记 AN5407 规定,如果未使用 SerDes 通道,则应将其下拉: 如果某些 SerDes 通道未连接,请将其接收器引脚拉低至 GND。 请问下拉菜单的值是多少?或者我应该将接收器引脚直接连接到 GND? 谢谢。 Re: LX2160A: Pull down value on receiver for SerDes lanes not used 你好, AN5407 中的“将接收器引脚拉低至 GND”的说法故意含糊不清——NXP 的澄清是,直接将 0 Ω 连接到 GND 是正确且首选的方法。 SerDes 掉电 即使 RX 引脚连接到 GND,如果 SerDes 模块仍然通电,AN5407 还建议通过固件掉电未使用的通道:在 PBI 阶段配置通用控制 0 寄存器以掉电未使用的 SerDes 通道。如果整个 SerDes 模块已经掉电,则无需单独掉电各个通道。 此致
記事全体を表示
如何使用 S32 设计工作室 MCP 集成 如何使用S32 Design Studio MCP集成?是否有相关资料和文档? Re: How to use S32 Design Studio MCP Integration 你好, 遗憾的是,相关文档和使用示例仍在开发中。我希望它能尽快对外发布,但不知道具体日期。
記事全体を表示
ELEはホストがアクセスできない非揮発性ストレージに鍵を保持できますか? こんにちは、 EdgeLock セキュア・エンクレーブ(ELE)での永続キー保存についてお尋ねしたいです。 私の理解によると、ELEが暗号操作に使用する鍵は、キーストレージサービスを使って永続的に保存できます。私が理解している典型的な流れは以下のとおりです。 1. 対象キーのキーブロブを作成し、ホストにエクスポートします。 2. エクスポートしたキーブロブをフラッシュメモリなどの不揮発性メモリに保存します。 3. 暗号化操作に鍵が必要な場合は、キーブロブをインポートし、ELE を介して鍵を使用します。 この方法では、キーブロブはELEによって生成されるため、ホストは実際のキー素材を読み取ることができません。しかし、Flashではキーブロブ自体がホストに保存されているため、ホストはキーブロブを削除したり上書きしたりできるようです。 私の質問は次のとおりです。 ELEからはアクセス可能だがホストからはアクセスできない不揮発性ストレージ領域に鍵(またはそのキーブロブ)を保存する方法はありますか?これにより、鍵マテリアルやキーブロブがホストに一切公開されることなく、ELEが暗号化操作を実行できるようになります。 言い換えれば、ELEが永続的なキーストレージを完全にセキュアな領域内で所有および管理し、ホストがキーやキーブロブを直接扱うことがないようにすることは可能でしょうか? ご指導をよろしくお願いいたします。 Re: Can ELE Retain Keys in Host-Inaccessible Non-Volatile Storage? こんにちは、 @t_hosomi さん。お元気でお過ごしでしょうか。 NVMフローにおける鍵の生成と保存に関するあなたの理解は正しいです。 しかし、ELEには不揮発性メモリがないため(SRMのセクション10.3.1に記載されているとおり)、サポートされている唯一の方法は、エクスポートされたキーブロブをホストのNVMに保存することです。 この情報がお役に立てば幸いです。 Re: Can ELE Retain Keys in Host-Inaccessible Non-Volatile Storage? こんにちは、RomanVRさん。 ご回答ありがとうございます。 ELE自体は不揮発性ストレージを提供しないため、永続的なキーデータはホストの不揮発性メモリに保存する必要があることを理解しています。 この点を明確にしていただきありがとうございます。
記事全体を表示
Clarification on eMIOS DMA Request Mapping Hello Team, I am currently using eMIOS1_CH13 for the LiPS sensor in DMA mode. The configuration uses DMA Channel 0 and DMAMUX0. While reviewing the S32K3xx DMAMUX mapping Excel, I observed that for eMIOS1, only DMA requests 0, 1, 9, and 10 are listed under DMAMUX0. However, my application is configured to use eMIOS1_CH13. Could you please clarify the following: Which DMA request source should be used for eMIOS1_CH13? Does eMIOS1_CH13 support DMA triggering, or is DMA support limited to the eMIOS channels corresponding to DMA requests 0, 1, 9, and 10? Thank you for your support. Best regards, Jyothsna Sagili Re: Clarification on eMIOS DMA Request Mapping Hi, according to the S32K3 DMAMUX mapping, eMIOS provides DMA request sources only for channels 0, 1, 9, 10, 16, 17, 18, and 19. These are the only eMIOS channels that can generate DMA requests. Since eMIOS1_CH13 is not one of these channels, it does not have a dedicated DMA request source in DMAMUX and cannot directly trigger eDMA transfers. If DMA triggering is required, please use one of the eMIOS channels associated with the available DMA request sources (0, 1, 9, 10, 16, 17, 18, or 19). BR, Petr
記事全体を表示
关于 eMIOS DMA 请求映射的说明 各位同事好, 我目前在 DMA 模式下使用 eMIOS1_CH13 连接 LiPS 传感器。该配置使用 DMA 通道 0 和 DMAMUX0。 在查看 S32K3xx DMAMUX 映射 Excel 时,我发现对于 eMIOS1,DMAMUX0 下只列出了 DMA 请求 0、1、9 和 10。但是,我的应用程序配置为使用 eMIOS1_CH13。 请您澄清以下问题: eMIOS1_CH13 应该使用哪个 DMA 请求源? eMIOS1_CH13 是否支持 DMA 触发,还是 DMA 支持仅限于与 DMA 请求 0、1、9 和 10 对应的 eMIOS 通道? 感谢您的支持。 顺祝商祺! 乔斯纳·萨吉利 Re: Clarification on eMIOS DMA Request Mapping 您好, 根据 S32K3 DMAMUX 映射,eMIOS 仅为通道 0、1、9、10、16、17、18 和 19 提供 DMA 请求源。只有这些 eMIOS 通道才能生成 DMA 请求。 由于 eMIOS1_CH13 不是这些通道之一,因此它在 DMAMUX 中没有专用的 DMA 请求源,不能直接触发 eDMA 传输。如果需要 DMA 触发,请使用与可用 DMA 请求源(0、1、9、10、16、17、18 或 19)关联的 eMIOS 通道之一。 BR,彼得
記事全体を表示
eMIOS DMA要求マッピングに関する説明 こんにちは、チームの皆さん、 現在、LiPSセンサのDMAモードではeMIOS1_CH13を使っています。この構成はDMAチャネル0とDMAMUX0を使用します。 S32K3xx DMAMUXマッピングExcelをレビューしていると、eMIOS1ではDMA要求0、1、9、10のみが記載されていることに気づきましたDMAMUX0。しかし、私のアプリケーションはeMIOS1_CH13を使うように設定されています。 以下の点を明確にしていただけますか? どのDMA要求ソースを使うべきかeMIOS1_CH13? eMIOS1_CH13 DMAトリガーをサポートしていますか?それともDMAはDMAリクエスト0、1、9、10に対応するeMIOSチャネルに限定されているのでしょうか? ご支援ありがとうございます。 よろしくお願いいたします。 ジョツナ・サギリ Re: Clarification on eMIOS DMA Request Mapping こんにちは、 S32K3 DMAMUXマッピングによると、eMIOSはチャネル0、1、9、10、16、17、18、19に対してのみDMAリクエストソースを提供します。これらはDMA要求を生成できる唯一のeMIOSチャネルです。 eMIOS1_CH13はこれらのチャネルの一つではないため、DMAMUX内に専用のDMA要求ソースがなく、eDMA転送を直接トリガーすることはできません。DMAトリガーが必要な場合は、利用可能なDMAリクエストソースに関連するeMIOSチャネルのいずれか(0、1、9、10、16、17、18、または19)を使用してください。 BR、ペトル
記事全体を表示