Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
模拟产品介绍,包括 PMIC、SBC 和 PowerPC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将介绍最新的模拟产品和路线图。 Eric Wu 主讲 2015 年 5 月 7 日,台北 DwF 展 会话 ID:APF-IND-T1450 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将介绍最新的模拟产品和路线图。 Eric Wu 主讲 2015 年 5 月 7 日,台北 DwF 展 会话 ID:APF-IND-T1450 电源管理
查看全文
FTF-IND-F1142_Robust Design with Kinetis E Series MCUs.pptx Kinetis E series MCUs target to applications where require high performance on EMC/ESD. With 5V power supply and robust IO design, Kinetis E series MCUs can help customer for a robust design. Here take a Microwave Oven demo as example, shares how to make a robust design with Kinetis E Series MCU, from hardware, software perspective. Kinetis E series MCUs target to applications where require high performance on EMC/ESD. With 5V power supply and robust IO design, Kinetis E series MCUs can help customer for a robust design. Here take a Microwave Oven demo as example, shares how to make a robust design with Kinetis E Series MCU, from hardware, software perspective.
查看全文
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
查看全文
RF概述和路线图介绍 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 由 Bill Zheng 主讲 2015 年 8 月 13 日,在 DwF RF Solutions - 武汉举办 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 由 Bill Zheng 主讲 2015 年 8 月 13 日,在 DwF RF Solutions - 武汉举办 回复:RF概述和路线图介绍 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 很好的演示,特别是如果您正在寻找移动收音机的输出晶体管。 回复:RF概述和路线图介绍 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在哪里可以找到有关 AFT09MS007 双设备参考板的更多信息(可能包括物料清单,我对功率分配器很好奇)。另外,400-500MHz 左右的 AFT09MS015NT1 是否有 S 参数?我可能弄错了,但我相信所发布的是来自 870MHz 参考板并且在 400MHz 时不太有用。谢谢
查看全文
方法: 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 プロジェクトを作成する   よろしくお願いします。 カルロス 全般
查看全文
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.
查看全文
TFC 2015全球锦标赛规则 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 这是 2015 年飞思卡尔杯全球挑战赛规则。决赛将于2015年9月14日至15日在德国埃尔兰根举行。 除非大学项目协调员针对您所在的特定地区修改规则,否则所有挑战都将采用全球规则。 规则 V6 更新:强调比赛期间不允许进行无线连接。技术检查前必须移除所有无线连接模块 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 这是 2015 年飞思卡尔杯全球挑战赛规则。决赛将于2015年9月14日至15日在德国埃尔兰根举行。 除非大学项目协调员针对您所在的特定地区修改规则,否则所有挑战都将采用全球规则。 规则 V6 更新:强调比赛期间不允许进行无线连接。技术检查前必须移除所有无线连接模块 飞思卡尔杯内容 回复:TFC 2015 全球锦标赛规则 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 各位组织者大家好, 关于规则,我们有两个问题: 问题 1 关于第 1 部分机械规则: 1.必须使用原始且未经改动的设备作为参赛作品。 a. 外轮胎胎面和轮辋。 是否允许像下图所示那样打磨/刮削轮胎胎面? 问题 2 关于第 1 节电气点 3 中的规则: 高压电机控制和接口需要使用飞思卡尔技术。 使用的电机驱动芯片数量有限制吗? 谢谢。 期待您的回复。 回复:TFC 2015 全球锦标赛规则 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好,约书亚, 越过界线不会受到惩罚。唯一的处罚是当赛车超过 2 个车轮脱离赛道时。 这意味着:如果两个车轮出轨,车辆可以继续当前圈。但如果三个车轮出轨,车辆将被判定为出轨。处罚:不记录圈数。 您可以在第 7 部分检查这一点。 回复:TFC 2015 全球锦标赛规则 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果汽车在行驶过程中触及线路,这是否算失败?触线和越线有区别吗? 我目前已报名参加 RIT 地区比赛,该赛事的开始时间已经确定了吗? 谢谢!
查看全文
培训:MCUXpresso for VS Code 演练 本视频系列展示了快速入门的步骤。 这是一段视频演练,旨在帮助可视化“适用于 VS Code 的 MCUXpresso 安装步骤”中详述的步骤。 第 1 部分:MCUXpresso for Visual Studio Code 恩智浦使开发人员能够更轻松地在 Visual Studio Code 中使用恩智浦微控制器。用户可以在 www.nxp.com/vscode 上获取恩智浦支持的高级概览。 您将需要以下软件: MCUXpresso 安装程序(Win;MacOS;Linux) Microsoft Visual Studio Code下载 (在 “我的视频” 中查看) 第 2 部分:MCUXpresso 安装程序准备的内容 为什么您需要使用MCUXpresso安装程序?在 Visual Studio Code 中进行嵌入式开发需要许多必备的工具。该程序会安装所需的工具,因此用户无需了解复杂的依赖关系即可配置不同的环境。 (在 “我的视频” 中查看) 第 3 部分:添加 MCUXpresso for VS Code 扩展 恩智浦扩展最终将通过访问 Visual Studio Code 中的扩展市场进行安装。 截至 2023 年 7 月正式发布前,该扩展程序可通过以下方式手动添加:点击扩展程序搜索栏右侧的省略号,然后在弹出的菜单中选择“添加扩展程序”。   您将需要最新的扩展程序。 下载:mcuxpresso-0.5.60.vsix (在 “我的视频” 中查看) 第 4 部分:回顾 MCUXpresso 视角 恩智浦扩展为 Visual Studio Code 让您能够轻松查看必要的信息、资源和工具。 (在 “我的视频” 中查看) 第 5 部分:添加软件仓库/SDK NXP 扩展提供了一种工具,可以从热门来源导入软件存储库。开发人员可以从远程存储库、NXP 存档文件或现有的本地存储库中导入。 (在 “我的视频” 中查看) 第 6 部分:导入第一个项目 恩智浦扩展提供了一个项目导入工具。 快速且简单地浏览可用项目并将其添加到当前工作区。 用户可以从资源库或现有的本地项目中导入。 (在 “我的视频” 中查看) 第 7 部分:在 VS Code 中构建项目 恩智浦安装程序和扩展程序为您的平台准备工具链。 完成安装程序和扩展程序后,恩智浦项目应能正常构建。 (在 “我的视频” 中查看) 第 8 部分:启动调试会话 恩智浦扩展已添加对通过流行调试探针在 VS Code 中启动默认工具的支持。 Segger J-Link、NXP LinkServer 和 PE Micro 调试探针已识别并配置。调试会话启动,用户能够分析他们的项目。 (在 “我的视频” 中查看) 文档 VS Code Re: Training: Walkthrough of MCUXpresso for VS Code 您好,我在使用 vscode 的此插件时遇到了问题。第一张图片是我的配置项目的屏幕截图,第二张图片是我在构建时报告的错误。 vae_1-1717051169546.png vae_0-1717051074103.png Re: 培训:MCUXpresso for VS Code 的演练 @sourabhmoitra 很高兴听到您已经顺利推进工作。我们还发现,路径中包含空格会导致问题。团队正致力于在用户使用工具选择会引发这些错误的目录时,向用户发出警告。 Re: 培训:MCUXpresso for VS Code 的演练 感谢 @kyledando 的建议。更改 Git 文件夹对我来说确实奏效,但奇怪的是,我无法选择目录层级超过三级的 Git 文件夹(例如 C:/folder1/folder2/folder3)。我猜这可能是由于 Python/West 的路径长度限制(某些 Windows 机器会有这个问题……)。再次感谢您的建议。 Re: 培训:MCUXpresso for VS Code 的演练 @sourabhmoitra 您尝试过将项目放在其他磁盘位置吗?我在旧的 git 文件夹上遇到了类似的 West 错误。我将文件移动到了新的文件夹位置,那个错误就消失了。 我已提交工单,以解决旧 Git 文件夹在使用 west 命令时出错的原因。不过,当我选择另一个文件夹(C:/mcux-sdk)以避免任何文件夹路径问题时,可以通过向导成功导入 mcux-sdk。 Re: 培训:MCUXpresso for VS Code 的演练 做得非常好! 视频清晰、简短且信息丰富。 此次扩展将成为我们发展的重要资产。 Re: 培训:MCUXpresso for VS Code 的演练 干得漂亮!让我及时掌握情况!
查看全文
RT600 4 I2S input to 1 TDM output solution 1. Abstract This article aims to implement the simultaneous input of 4 groups of 48Khz 32bit 2ch audio data on the RT685 platform, and then assemble the received data into a 48Khz 32bit 8ch audio and output it through I2S. This solution is also done at the request of customers, because there are always harmonic problems when customers make it. After analyzing the customer's situation, it is found that the customer has two main problems: (1) Harmonic problem: After receiving 4 channels of 8 bytes, it is directly copied to the sending buffer. This will cause timing problems. It does not take into account the problem of buffering data in the audio data storage pool. The time required to receive enough audio data is at least greater than the time required for copying and sending. Therefore, the problem is reflected in the problem that the customer found harmonic problems when testing the output audio waveform. (2) Audio synchronization problem: After the customer received 4 channels of audio data, he tested the receiving buffer and found that the 4 channels of data were out of sync. Therefore, in order to help customers, I helped customers make this application demo directly, and made a matching test audio source to send a set of 48Khz sampling rate 32bit dual-channel, fixed increment audio data in a loop, such as 0X00-0XFF in a loop. The following is the block diagram of this application platform:   1.jpg Figure 1 System Block Diagram In the above figure, a MIMXRT685-EVK implements the function of outputting 48Khz, 32bit*2ch, and sends data in a loop: 0X00, 0X01….0XFF. Another MIMXRT685-EVK is the focus of this article, which implements 4 groups of I2S to receive data at a sampling rate of 48khz and 32bit*2ch, and then assembles the received data into audio data with a sampling rate of 48Khz and 32bit*8ch and sends it out. In the above figure, in order to reduce the connection of external lines, for BCLK and WS signals, only one group is directly connected to I2S3, and the other I2S2, I2S4, and I2S5 share the I2S3 signal internally. Then, for DATA data, a line is made externally with 4 heads, and connected to the data pins of each group of audio interfaces respectively. The following is a detailed description of this solution. 2. Hardware platform establish The pinouts of the two boards are given below. Because the platform uses many pins, specific allocation is required. 2.1 Audio source board A MIMXRT685-EVK is used as an audio source, and the pinouts for sending 48Khz 32bit*2ch are as follows:   2.jpg Figure 2 Pinout of audio source board 2.2 Audio transceiver board Another MIMXRT685-EVK is used as an audio transceiver board to receive 4-channel audio synchronization data sent by the audio source and assemble it into a 48Khz 32bit*8ch waveform for transmission.   3.jpg Figure 3 Pin assignment of audio transceiver board 2.3 Dual-board hardware connection The source and target connections of the two boards are as follows:   4.jpg Figure 4 Two board pin connection   5.jpg Figure 5 two board connection After the hardware is ready, the software solution and code are provided. 3. Software solution and software implementation In the process of writing the code, we tried many solutions, such as: (1) When receiving, directly assemble it into the TDM format buffer to be sent, and then send it. However, since it is assembled into TDM, one I2S needs to receive 8 byte per frame, and then do the offset to receive the next one. If the reception is carried out according to the 8-byte DMA, the callback of the 4 groups of I2S will enter frequently, resulting in a large CPU load, so this solution is abandoned. (2) The 4 groups of I2S are connected to each other, and the 10ms buffer is connected, and then the DMA method is used to copy from memory to memory. However, since the DMA of RT685 is relatively weak, it can only achieve a maximum offset of 32bit 4word=16byte, that is, a 16-byte offset. However, in fact, a group of audio data is 32bit*2, and 4 groups are 32bit*8=32byte offset, so DMA cannot meet the requirements. Therefore, the DMA memory-to-memory copy solution is abandoned and memcpy is used instead. (3) Use the I2S_RxTransferReceiveDMA function to perform DMA reception. However, in fact, when one group is called, it starts receiving directly, and waits until the next group of I2S interfaces calls I2S_RxTransferReceiveDMA. This has caused an asynchronous situation. Even if the I2S enable is turned off in I2S_RxTransferReceiveDMA, the 4th group of I2S is enabled after the several groups of I2S of I2S_RxTransferReceiveDMA are called. This method can only achieve the synchronization of the reception of the first group of data, because later, it is necessary to go to the callback to re-trigger the reception of the second frame of data. Therefore, the callback of the 4 groups of I2S calls I2S_RxTransferReceiveDMA, which will inevitably cause new synchronization problems. Therefore, this method is abandoned and it is considered to use two groups of DMA descriptors to do ping-pong. In this way, the reception will continue in a loop without the intervention of CPU code. 3.1 Solution Implementation Several solutions have been described above. Finally, we choose to use 4 audio channels to receive audio data and cache 10ms audio data buffer. The conversion from receiving buffer to sending buffer adopts memcpy method, and test whether this copy time can meet the actual needs, to ensure that the buffer pool of receiving buffer is greater than this copy time, which is enough to prepare the sending buffer. The solution for receiving data transfer is as follows:   6.jpg Figure 6 Data buffer transfer The above is 4 groups of I2S receiving their own 10ms data respectively. The buffer is actually prepared for 20ms. A single DMA receives a frame for 10ms, and the other 10ms is used for pingpong buffer. The sending buffer is used to copy the received 4 groups of I2S buffers into a 32bit*8ch array in TDM format, and then two groups of ping-pong buffers are also made. In fact, it is to cache 10ms data. The buffer prepares two groups of 10ms. When the first 10ms frame is received, the second buffer is used to receive it. At the same time, the data of the first buffer is copied to the first buffer of the sending buffer, and the first buffer is used for sending. After the sending is completed, it is transferred to the second buffer to receive and send. In this way, as long as the time is controlled well, there will be no data error problem. The data volume of 10ms is 3840Byte, because the receiving frequency is 48Khz, that is, there are 48000 frames in 1s, and each frame is 32bit*2=8Byte, then 10ms=>4800*8Byte=38400Byte. 3.2 Software code implementation The software code implementation part is mainly divided into 4 I2S receiving signal sharing, I2S DMA pingpong configuration, data transfer, sending I2S and other parts. The details are given below 3.2.1 4-way I2S receiving From the above, we can know that the 4 I2S receiving signal is not completely connected with wires, but adopts the method of sharing BCLK and WS signals and receiving DATA separately. I2S2, I2S4, I2S5 share the BCLK of I2S3, and the WS code is as follows: /* Set shared signal set 0: SCK, WS from Flexcomm1 */ I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_Flexcomm3); I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_Flexcomm3); /* Set flexcomm3 SCK, WS from shared signal set 0 */ I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm2, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm2, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm4, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm4, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm5, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm5, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); 3.2.2 I2S DMA pingpong configuration In order to achieve 4-channel audio synchronization and receive 10ms audio buffer, two I2S DMA descriptors are used to implement the ping-pong function to collect data to two ping-pong buffers in turn. The code is as follows: #define I2S_BUFFER_SIZE 3840 //10ms SDK_ALIGN(static dma_descriptor_t I2S2_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static dma_descriptor_t I2S3_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static dma_descriptor_t I2S4_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static dma_descriptor_t I2S5_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static uint8_t I2S2_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S3_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S4_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S5_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); static i2s_transfer_t I2S2_s_RxTransfer[2] = {{ .data = I2S2_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S2_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; static i2s_transfer_t I2S3_s_RxTransfer[2] = {{ .data = I2S3_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S3_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; static i2s_transfer_t I2S4_s_RxTransfer[2] = {{ .data = I2S4_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S4_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; static i2s_transfer_t I2S5_s_RxTransfer[2] = {{ .data = I2S5_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S5_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; I2S_RxGetDefaultConfig(&I2S2_s_RxConfig); I2S2_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S2_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S2_RX, &I2S2_s_RxConfig); I2S_RxGetDefaultConfig(&I2S3_s_RxConfig); I2S3_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S3_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S3_RX, &I2S3_s_RxConfig); I2S_RxGetDefaultConfig(&I2S4_s_RxConfig); I2S4_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S4_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S4_RX, &I2S4_s_RxConfig); I2S_RxGetDefaultConfig(&I2S5_s_RxConfig); I2S5_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S5_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S5_RX, &I2S5_s_RxConfig); DMA_Init(DEMO_DMA); DMA_EnableChannel(DEMO_DMA, DEMO_I2S2_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S2_RX_CHANNEL, kDMA_ChannelPriority1); DMA_CreateHandle(&I2S2_s_DmaRxHandle, DEMO_DMA, DEMO_I2S2_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S2_RX, &I2S2_s_RxHandle, &I2S2_s_DmaRxHandle, I2S2_RxCallback, (void *)&I2S2_s_RxTransfer); DMA_EnableChannel(DEMO_DMA, DEMO_I2S3_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S3_RX_CHANNEL, kDMA_ChannelPriority1); DMA_CreateHandle(&I2S3_s_DmaRxHandle, DEMO_DMA, DEMO_I2S3_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S3_RX, &I2S3_s_RxHandle, &I2S3_s_DmaRxHandle, I2S3_RxCallback, (void *)&I2S3_s_RxTransfer); DMA_EnableChannel(DEMO_DMA, DEMO_I2S4_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S4_RX_CHANNEL, kDMA_ChannelPriority1); DMA_CreateHandle(&I2S4_s_DmaRxHandle, DEMO_DMA, DEMO_I2S4_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S4_RX, &I2S4_s_RxHandle, &I2S4_s_DmaRxHandle, I2S4_RxCallback, (void *)&I2S4_s_RxTransfer); DMA_EnableChannel(DEMO_DMA, DEMO_I2S5_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S5_RX_CHANNEL, kDMA_ChannelPriority2); DMA_CreateHandle(&I2S5_s_DmaRxHandle, DEMO_DMA, DEMO_I2S5_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S5_RX, &I2S5_s_RxHandle, &I2S5_s_DmaRxHandle, I2S5_RxCallback, (void *)&I2S5_s_RxTransfer); I2S_TransferInstallLoopDMADescriptorMemory(&I2S2_s_RxHandle, I2S2_s_rxDmaDescriptors, 2U); I2S_TransferInstallLoopDMADescriptorMemory(&I2S3_s_RxHandle, I2S3_s_rxDmaDescriptors, 2U); I2S_TransferInstallLoopDMADescriptorMemory(&I2S4_s_RxHandle, I2S4_s_rxDmaDescriptors, 2U); I2S_TransferInstallLoopDMADescriptorMemory(&I2S5_s_RxHandle, I2S5_s_rxDmaDescriptors, 2U); if (I2S_TransferReceiveLoopDMA(DEMO_I2S2_RX, &I2S2_s_RxHandle, &I2S2_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } if (I2S_TransferReceiveLoopDMA(DEMO_I2S3_RX, &I2S3_s_RxHandle, &I2S3_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } if (I2S_TransferReceiveLoopDMA(DEMO_I2S4_RX, &I2S4_s_RxHandle, &I2S4_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } if (I2S_TransferReceiveLoopDMA(DEMO_I2S5_RX, &I2S5_s_RxHandle, &I2S5_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } I2S_Enable(DEMO_I2S2_RX); I2S_Enable(DEMO_I2S3_RX); I2S_Enable(DEMO_I2S4_RX); I2S_Enable(DEMO_I2S5_RX); Here, the code has been modified, mainly the I2S_TransferLoopDMA function in fsl_i2s_dma.c, which is blocked: I2S_Enable(base); In order to realize the function of 4-channel synchronous reception. 3.2.3 Audio data received and transferred Because when receiving, each audio interface takes turns to receive its own 2ch data, but when sending, it is necessary to send 4-channel received audio dual-channel data, that is, 32bit*8ch data, so after receiving ping, the ping data needs to be transferred to the sending ping buffer. The code for transfer is as follows: #define I2S_BUFFER_SIZE 3840 //10ms SDK_ALIGN(static uint8_t I2S2_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S3_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S4_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S5_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S1_s_Buffer[2][I2S_BUFFER_SIZE*4], sizeof(uint32_t)); if( s_pingpong == 1) { for(ch = 0;ch < 480; ch++) //480=I2S_BUFFER_SIZE(3840)/8 { memcpy(&I2S1_s_Buffer[0][0 + (32*ch)], &I2S2_s_Buffer[0][8*ch], 8); memcpy(&I2S1_s_Buffer[0][8 + (32*ch)], &I2S3_s_Buffer[0][8*ch], 8); memcpy(&I2S1_s_Buffer[0][16 + (32*ch)], &I2S4_s_Buffer[0][8*ch], 8); memcpy(&I2S1_s_Buffer[0][24 + (32*ch)], &I2S5_s_Buffer[0][8*ch], 8); } } else { for(ch = 0;ch < 480; ch++) { memcpy(&I2S1_s_Buffer[1][0 + (32*ch)], &I2S2_s_Buffer[1][8*ch], 8); memcpy(&I2S1_s_Buffer[1][8 + (32*ch)], &I2S3_s_Buffer[1][8*ch], 8); memcpy(&I2S1_s_Buffer[1][16 + (32*ch)], &I2S4_s_Buffer[1][8*ch], 8); memcpy(&I2S1_s_Buffer[1][24 + (32*ch)], &I2S5_s_Buffer[1][8*ch], 8); } } 3.2.4 Send TDM audio code The sending code also uses the I2S DMA method, but because there is no need to send multiple channels at the same time, only a single channel, there is no need to consider the synchronization problem, and no DMA descriptor is used. After the sending buffer is ready, the I2S_TxTransferSendDMA method is used. The code is as follows: I2S_TxGetDefaultConfig(&I2S1_s_TxConfig); I2S1_s_TxConfig.divider = DEMO_I2S1_CLOCK_DIVIDER; I2S1_s_TxConfig.masterSlave = kI2S_MasterSlaveNormalMaster; I2S1_s_TxConfig.wsPol = true; I2S1_s_TxConfig.mode = kI2S_ModeDspWsLong;//kI2S_ModeDspWsShort; I2S1_s_TxConfig.dataLength = 32U; I2S1_s_TxConfig.frameLength = 32 * 8U; I2S1_s_TxConfig.position = DEMO_TDM_DATA_START_POSITION; I2S1_s_TxConfig.pack48 = true; I2S_TxInit(DEMO_I2S1_TX, &I2S1_s_TxConfig); I2S_EnableSecondaryChannel(DEMO_I2S1_TX, kI2S_SecondaryChannel1, false, 64 + DEMO_TDM_DATA_START_POSITION); I2S_EnableSecondaryChannel(DEMO_I2S1_TX, kI2S_SecondaryChannel2, false, 128 + DEMO_TDM_DATA_START_POSITION); I2S_EnableSecondaryChannel(DEMO_I2S1_TX, kI2S_SecondaryChannel3, false, 192 + DEMO_TDM_DATA_START_POSITION); DMA_EnableChannel(DEMO_DMA, DEMO_I2S1_TX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S1_TX_CHANNEL, kDMA_ChannelPriority3); DMA_CreateHandle(&I2S1_s_DmaTxHandle, DEMO_DMA, DEMO_I2S1_TX_CHANNEL); I2S_TxTransferCreateHandleDMA(DEMO_I2S1_TX, &I2S1_s_TxHandle, &I2S1_s_DmaTxHandle, I2S1_TxCallback, (void *)&I2S1_s_TxTransfer); if( s_pingpong == 1) { I2S1_s_TxTransfer.data = I2S1_s_Buffer[0]; I2S1_s_TxTransfer.dataSize = I2S_BUFFER_SIZE*4; I2S_TxTransferSendDMA(DEMO_I2S1_TX, &I2S1_s_TxHandle, I2S1_s_TxTransfer); } else { I2S1_s_TxTransfer.data = I2S1_s_Buffer[1]; I2S1_s_TxTransfer.dataSize = I2S_BUFFER_SIZE*4; I2S_TxTransferSendDMA(DEMO_I2S1_TX, &I2S1_s_TxHandle, I2S1_s_TxTransfer); } 3.2.5 Send and receive I2S callback processing For the receiving I2S2, 3, 4, 5, there are 4 channels in total. Each time 10ms of data is received, a callback will be entered. In the callback, you only need to record the flag. When all 4 flags are recorded, it means that the 4 channels of the same 10ms data have been received, and the data can be copied to the sending buffer. Of course, in order to test whether the callback entry frequency is once every 10ms, this article makes a GPIO callback for testing. The following is the code for recording I2S callback static void I2S2_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { s_allRXTriggerred |= 0x01; } static void I2S3_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { s_allRXTriggerred |= 0x02; } static void I2S4_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { s_allRXTriggerred |= 0x04; } static void I2S5_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { /* Enqueue the same original buffer all over again */ s_allRXTriggerred |= 0x08; GPIO_PortToggle(GPIO, 1, 1<<0); if( s_pingpong == 0) { s_pingpong = 1; } else { s_pingpong = 0; } } static void I2S1_TxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { GPIO_PortToggle(GPIO, 1, 1<<8); //__NOP(); } So far, all functions of a MIMXRT685-EVK for 4 I2S reception and 1 I2S TDM transmission have been completed. 3.2.6 Audio source code The audio source is made on another MIMXRT685-EVK to send 48Khz, 32bit*2ch audio data, and the data is sent in a loop from 0X00 to 0XFF. The code is as follows: int main(void) { BOARD_InitBootPins(); BOARD_InitBootClocks(); BOARD_InitDebugConsole(); BOARD_I3C_ReleaseBus(); BOARD_InitI3CPins(); CLOCK_EnableClock(kCLOCK_InputMux); /* attach main clock to I3C (500MHz / 20 = 25MHz). */ CLOCK_AttachClk(kMAIN_CLK_to_I3C_CLK); CLOCK_SetClkDiv(kCLOCK_DivI3cClk, 20); /* attach AUDIO PLL clock to FLEXCOMM1 (I2S1) */ CLOCK_AttachClk(kAUDIO_PLL_to_FLEXCOMM1); /* attach AUDIO PLL clock to FLEXCOMM3 (I2S3) */ CLOCK_AttachClk(kAUDIO_PLL_to_FLEXCOMM3); /* attach AUDIO PLL clock to MCLK */ CLOCK_AttachClk(kAUDIO_PLL_to_MCLK_CLK); CLOCK_SetClkDiv(kCLOCK_DivMclkClk, 1); SYSCTL1->MCLKPINDIR = SYSCTL1_MCLKPINDIR_MCLKPINDIR_MASK; wm8904Config.i2cConfig.codecI2CSourceClock = CLOCK_GetI3cClkFreq(); wm8904Config.mclk_HZ = CLOCK_GetMclkClkFreq(); /* Set shared signal set 0: SCK, WS from Flexcomm1 */ I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_Flexcomm1); I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_Flexcomm1); /* Set flexcomm3 SCK, WS from shared signal set 0 */ I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm3, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm3, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); #if 1 PRINTF("Configure codec\r\n"); /* protocol: i2s * sampleRate: 48K * bitwidth:16 */ if (CODEC_Init(&codecHandle, &boardCodecConfig) != kStatus_Success) { PRINTF("codec_Init failed!\r\n"); assert(false); } /* Initial volume kept low for hearing safety. * Adjust it to your needs, 0-100, 0 for mute, 100 for maximum volume. */ if (CODEC_SetVolume(&codecHandle, kCODEC_PlayChannelHeadphoneLeft | kCODEC_PlayChannelHeadphoneRight, DEMO_CODEC_VOLUME) != kStatus_Success) { assert(false); } PRINTF("Configure I2S\r\n"); #endif /* * masterSlave = kI2S_MasterSlaveNormalMaster; * mode = kI2S_ModeI2sClassic; * rightLow = false; * leftJust = false; * pdmData = false; * sckPol = false; * wsPol = false; * divider = 1; * oneChannel = false; * dataLength = 16; * frameLength = 32; * position = 0; * watermark = 4; * txEmptyZero = true; * pack48 = false; */ I2S_TxGetDefaultConfig(&s_TxConfig); s_TxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; s_TxConfig.masterSlave = DEMO_I2S_TX_MODE; I2S_TxInit(DEMO_I2S_TX, &s_TxConfig); DMA_Init(DEMO_DMA); DMA_EnableChannel(DEMO_DMA, DEMO_I2S_TX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S_TX_CHANNEL, kDMA_ChannelPriority3); DMA_CreateHandle(&s_DmaTxHandle, DEMO_DMA, DEMO_I2S_TX_CHANNEL); StartSoundPlayback(); while (1) { } } static void StartSoundPlayback(void) { PRINTF("Setup looping playback of sine wave\r\n"); s_TxTransfer.data = &g_Music[0]; s_TxTransfer.dataSize = sizeof(g_Music); I2S_TxTransferCreateHandleDMA(DEMO_I2S_TX, &s_TxHandle, &s_DmaTxHandle, TxCallback, (void *)&s_TxTransfer); /* need to queue two transmit buffers so when the first one * finishes transfer, the other immediatelly starts */ I2S_TxTransferSendDMA(DEMO_I2S_TX, &s_TxHandle, s_TxTransfer); I2S_TxTransferSendDMA(DEMO_I2S_TX, &s_TxHandle, s_TxTransfer); } static void TxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { /* Enqueue the same original buffer all over again */ i2s_transfer_t *transfer = (i2s_transfer_t *)userData; I2S_TxTransferSendDMA(base, handle, *transfer); } Audio data buffer:   7.jpg Figure 7 Audio source sends buffer The corresponding test results are given:   8.jpg Figure 8 Audio source sending data test It can be seen that the data sent by the audio source is cyclical and can be sent in an increasing loop. 4. Test results There are several points to verify about the test results: (1) 4-channel audio receives pingpong buffer, whether a single buffer is 10ms, that is, a 10ms audio data pool. (2) How long is the data memory copy time, whether it will exceed the length of the receiving audio data pool. (3) Whether the received 4-channel data is synchronized, whether the assembled send buffer data is the 32bit*8ch data assembled from the corresponding 4-channel 2ch data. (4) Whether the sent audio waveform is the correct 32bit*8ch TDM data. The following are the verification test results for these points. 4.1 4 I2S audio 10ms data pool This verification is very simple. Define a pin GPIO, initialize the output to 0, and then reverse it in the received callback interrupt. This article chooses to reverse it in the I2S5 callback. The test results are as follows:   9.jpg Figure 9 ch1 10ms duration Channel 1 is the exact 10ms because of the callback reversal received. Here is a general picture of the test:   10.jpg Figure 10 Time test overview Ch1: I2S5 callback entry frequency Ch2: memory copy time Ch3: Send callback entry frequency It can be seen that the frequency of sending and receiving is 10ms, because the sending frequency is also 48Khz, but because it is 8ch, the data volume is 4 times that of receiving, and all the data of the 4 receiving channels need to be stuffed in. 4.2 Time consumption of receiving and copying to sending buffer For data copying, that is, assembling the data received from 4 I2S channels into 4 buffers into the sending buffer, this time test is on the second channel of the oscilloscope, and the results are as follows:   11.jpg Figure 11 copy data time It can be seen that the copying time is less than 500us, which is much shorter than the 10ms of the audio receiving data pool. Therefore, you can use memcpy casually without worrying about the copying time being too long. This also makes up for the regret that I wanted to use DMA for memory to memory copying before, but it could not be realized due to DMA performance issues. 4.3 Verification of the synchronization of the data received on the 4 I2S In order to verify the synchronization, this article closes the 4 I2S receiving channel after receiving 100times 10ms, and prints out the corresponding 4 I2S audio receiving buffer. The results of the 4 I2S buffer are as follows:   12.jpg Figure12 I2S2 receive buffer   13.jpg Figure 13 I2S3 receive buffer   14.jpg Figure 14 I2S4 receive buffer   15.jpg Figure 15 I2S5 receive buffer It can be seen that the receive buffer data of the 4 I2S are completely synchronized, and all start from 0XB8. 4.4 Send buffer corresponding to 4-channel audio TDM The send buffer is printed after 100 receptions, and then memcpy is performed to the send buffer, and the printout of the send buffer data is as follows:   16.jpg Figure 16 I2S1 transfer buffer It can be seen that the buffer also starts from 0XB8, and the 4 groups of received data are copied to the send buffer and assembled into 32bit*8ch data. It can be seen that the TDM send buffer is also correct. 4.5 Sending 48Khz 32bit 8ch audio data waveform   17.jpg Figure 17 Transmitting and receiving audio waveforms The upper group is the waveform of the audio source, and the lower group is the waveform of TDM transmission. Due to the limitation of the analysis software of the logic analyzer, it can only analyze 2ch 64bit data at most, so only part of the data can be seen here, but from the waveform, it can be seen that the waveform of sending TDM can achieve 32bit*8ch, and every 8byte data in a frame is the same, which also explains the synchronization of 4-channel audio reception. In the above figure, the data of ch2 is actually 00, 01, 02, 03, 04, 05, 06, 07, 4 groups of the same data in one frame, and the waveform can also be seen that there are 4 groups of the same data, and 4 groups of 2ch are enough to form 32bit 8ch TDM. Finally, here is another TDM waveform tested on the oscilloscope:   18.jpg Figure 18 Sending TDM waveform It can be seen that BCLK=12.28Mhz is consistent with the expected 48khz*32bit*8=12.288Mhz. The WS signal is also measured to be 48Khz, which meets the set 48Khz sampling rate. DATA is also transmitting with data changes, and it can be seen that the waveform pattern within a frame is repeated by about 4 groups, which also shows that the 4 groups of received data are synchronized. So far, the function of RT600 4-channel 48KHZ 32bit*2ch input and assembling into 48Khz 32bit*8ch output has been realized! i.MXRT 600 Re: RT600 4 I2S input to 1 TDM output solution Thanks so much for my colleage's help, my best internal Collaborators, my audio mentor!  @james_fan !!!  Also thanks my software colleague Qiangzhang( @Skybegonia  ), he is very familiar with the SDK, he shares the DMA pingpong demo which speed my application code and at last resolve my sync issues.
查看全文
S32G_MAC_Address_Storage 本文说明了S32G如何储存mac地址,包括dts保存,systemd指定和fuse保存的办法: 目录 1 需要的软件................................................................. 2 2 背景说明 .................................................................... 2 3 PFE eMAC MAC地址说明 ......................................... 2 3.1 DTS配置 ................................................................. 2 3.2 源代码说明 ............................................................. 3 3.3 测试 ........................................................................ 4 4 GMAC0 MAC地址说明 .............................................. 4 4.1 DTS配置 ................................................................. 4 4.2 源代码说明 ............................................................. 4 4.3 SystemD脚本 ......................................................... 5 4.4 固定GMAC MAC地址的修改办法 ........................... 6 5 用Uboot命令烧写FUSE MAC地址项 .......................... 7 6 修改为从fuse中获得GMAC0 MAC地址 ...................... 9 6.1 Uboot代码修改 ....................................................... 9 6.2 Uboot写MAC寄存器说明 ...................................... 10 6.3 测试 ...................................................................... 10 Automotive
查看全文
如何下载、安装、激活和使用 S32 Design Studio (在 “我的视频” 中查看) 这段短视频演示了如何从您的 NXP 用户账户获取 S32 Design Studio 3.6.0 版本,并将其安装到您的主机电脑上。 安装过程中,S32 Design Studio 3.6.0 需要一个激活码,该激活码可从下载安装文件的同一位置免费获取。 激活后,S32 Design Studio 3.6.0 即可用于以下微控制器和微处理器:S32K1xx、S32K3xx、S32M2xx、S32Z2xx、S32E2xx、S32G2xx、S32G3xx、S32R41 和 S32R45。 如何下载、安装、激活 S32 Design Studio 3.6.0 及其首次使用 激活 | 安装 | 许可 | 安装程序下载 Eclipse IDE 使用和设置 新建项目向导 - 项目管理和设置 SDK
查看全文
i.MX95 启动 ROM:配置 eMMC Boot0/Boot1 为主/从启动盘,FlexSPI NOR 为恢复盘 各位专家好, 我正在尝试了解 i.MX95 启动 ROM 是如何处理主启动、辅助启动和恢复启动阶段的。我已经查阅了参考手册和一些 U-Boot spl 源代码,但我仍然不清楚恢复启动机制的工作原理。 我的目标是实现以下启动架构: 主启动: eMMC Boot0 辅助启动: eMMC 启动1 Recovery 启动: FlexSPI 或非 闪存(黄金恢复镜像) 在查看arch/arm/mach-imx/image-container.c文件时,我注意到以下代码: printf("Boot stage: "); if (rom_data.boot_stage == 0x6) printf("Primary\n"); else if (rom_data.boot_stage == 0x9) printf("Secondary\n"); else if (rom_data.boot_stage == 0xa) printf("Recovery\n"); else printf("USB Serial Download\n"); 根据此,Boot ROM 似乎支持四个启动阶段:主启动、辅助启动、恢复启动和 USB 串口下载启动。但是,我找不到足够的信息来解释如何选择或配置恢复阶段。 我希望就以下问题获得一些指导: 是否可以将FlexSPI 或非 闪存配置为恢复引导设备,同时使用eMMC Boot0 和 Boot1作为主启动分区和辅助启动分区? 如果支持这种配置,推荐的配置方法是什么? 在选择主启动、辅助启动和恢复启动阶段时,启动 ROM 遵循的顺序是什么? 如果主启动和辅助启动都失败,什么情况下会触发恢复启动阶段? 在开发和验证过程中,可以有意重现哪些故障条件来模拟恢复模式? 是否有任何文档或应用说明详细描述了启动 ROM 启动选择算法和恢复启动流程? 引导设备熔丝配置(熔丝模式) 在选择恢复引导设备时 是否 起作用? 恢复设备是由引导设备熔丝决定的吗? 或者,即使启动设备熔丝到 eMMC 上,启动 ROM 能否自动切换到不同的启动设备(例如 FlexSPI NOR)? 最终,我的目标是让系统正常从 eMMC Boot0 启动, 必要时 回退到 eMMC Boot1 , 如果两个 eMMC 启动分区都不可用或无效, 则最终启动 存储在 FlexSPI 或非 中的 Golden Recovery Image 。 如果有人已经实现了类似的启动架构,或者可以向我提供相关的文档或应用笔记,我将非常感谢您的指导。 提前谢谢! BR, 阿伦·库马尔 Re: i.MX95 Boot ROM: Configuring eMMC Boot0/Boot1 as Primary/Secondary and FlexSPI NOR as Recovery 你好, 是否可以将FlexSPI 或非 闪存配置为恢复启动设备,同时使用eMMC Boot0 和 Boot1作为主启动分区和辅助启动分区? 不,这不可能。LP 启动的恢复引导设备只有 LPSPI1/2,你不能将任何其他启动源配置为恢复选项。 Oswalag_0-1783975544422.png
查看全文
Designing a CAN-Based Communication Hub with the S32N55 using Model Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article presents an automotive system built around a central computer that processes high volumes of data to manage interactions and decisions across the vehicle. Implemented on an NXP S32N55 board, a main node orchestrates peripheral nodes — Lighting, Motor Control, Steering, Radar, and Parking Sensors — over CAN, demonstrated through real-time interactions and Driver-in-the-Loop (DiL) simulations. The same architecture also enables stimuli and scenarios to be injected directly from Simulink/MATLAB via the Model-Based Design Toolbox (MBDT), turning the setup into both a functional prototype and a flexible test bench that shortens the loop between design, validation, and refinement. 3 Overview The communication hub acts as a comprehensive aggregator and decision-maker, serving as the central intelligence of the entire automotive control network. This architectural choice follows industry's best practices by consolidating critical decision-making processes into a single, robust processing unit capable of efficiently managing multiple concurrent data streams and executing time-sensitive commands. Centralizing this logic also simplifies maintenance and traceability, since the rules governing vehicle behavior live in one well-defined place rather than being scattered across multiple ECUs. For a project of this nature, the NXP Model-Based Design Toolbox (MBDT) offers a practical development path: control logic and application behavior can be designed in Simulink/MATLAB and deployed directly onto the S32N55, without a separate hand-coding step. The graphical, model-based workflow makes the system's structure easier to follow and adjust, while built-in support for CAN communication and integration with tools like FreeMASTER for live telemetry simplify both stimulus injection and runtime observation. The result is a smoother path from initial concept to a working prototype that can be iterated on and validated in a controlled, repeatable way. In this specific implementation, the main node hosts an application that fulfills two complementary roles: data aggregator and decision-maker. As an aggregator, it collects, synchronizes, and interprets incoming signals from the sensing nodes; as a decision-maker, it translates that fused view of the environment into concrete commands for the actuators. Practically, our system receives data over CAN from the peripheral sensing nodes (Radar, Parking Sensors) and dispatches commands to the actuator nodes (Motor Control, Lights, Steering). The main node is also designed to make safety-critical decisions based on the incoming inputs — for example, triggering Automated Emergency Braking (AEB) when the Parking Node or the Radar Node detects a hazardous situation. Because these decisions are made centrally, the response logic can take the full context into account (vehicle speed, proximity of obstacles, current steering input) rather than reacting to a single sensor in isolation. robertv_1-1782736295643.png 4 Context At its core, the main node receives a continuous stream of data over the CAN bus from peripheral nodes distributed throughout the vehicle. These peripheral nodes include: Radar sensors — provide long-range object detection and relative velocity measurements, making them ideal for highway-speed scenarios and forward collision awareness. Parking sensors — monitor the immediate vicinity of the vehicle for obstacles and potential collision risks, typically at very short range and at low speeds. Fault sensors — for actuator nodes, like the motor control, steering and lighting systems. The CAN bus protocol guarantees the reliable, deterministic communication required to meet the stringent timing demands of automotive safety systems. Its built-in arbitration, error detection, and message prioritization make it a natural fit for a distributed architecture in which safety-relevant signals must always reach the main node within a bounded time window. To streamline communication across components, a CAN Database ( DBC ) file has been created that contains all the signals and messages used throughout the system. The DBC file acts as a single source of truth for the entire network: every node — whether sensing or actuating — references the same definitions for message IDs, signal layouts, scaling factors, and value ranges. This drastically reduces the risk of integration mismatches when multiple boards are developed in parallel. Beyond its data aggregation role, the main node also serves as the command center for the vehicle's actuator systems. After receiving data from the simulation, it is being processed and then it transmits precisely timed control signals to critical subsystems, including the motor control unit, lighting system, and steering mechanism. This bidirectional architecture enables closed-loop control strategies, in which sensor feedback continuously informs actuator commands to achieve the desired vehicle behavior. Each actuator node remains responsible for the low-level handling of its hardware, while the main node provides the high-level command to the actuators. Since the main node is responsible for receiving, analyzing, processing and sending data, it also becomes the one responsible for sharing the telemetry information upstream, either to the cloud, or to real time monitoring tools like FreeMASTER. A particularly valuable aspect of this system is its seamless integration with the Simulink/MATLAB environment, which unlocks extensive possibilities for system validation and scenario testing. Engineers can inject stimuli into the simulation and analyze a wide range of driving conditions and edge cases without requiring a full-scale prototype. This is especially useful for reproducing rare or dangerous situations — such as sudden obstacles or sensor faults — in a fully controlled and repeatable environment. To achieve two-way communication between the main node and the simulation, the CAN bus itself is used to communicate with the Simulink model. This way, the physical prototype can feed stimuli into the simulation — and vice versa — on the same CAN bus that devices are using to communicate, significantly expanding the boundaries of the testing environment. The same DBC file that defines the on-vehicle communication is reused on the simulation side, ensuring that the messages exchanged between the real and virtual worlds remain perfectly consistent. robertv_2-1782736331723.png Note: Perhaps one of the most noteworthy features of the main node's active functions is its ability to make safety-critical decisions in real time based on aggregated sensor inputs. The system continuously monitors data from both the parking sensors and the radar node, detecting potentially dangerous situations that require immediate intervention: At low speeds — hazard detection is typically driven by the parking sensors mounted on the front and/or rear of the vehicle, where short-range, high-resolution distance measurements are most relevant. At driving speeds — the radar module takes over, collecting and analyzing data that is then forwarded to the main node for higher-level interpretation. In both scenarios, the main node remains the ultimate decision-maker, fusing all available data to determine the appropriate response. This clear separation between sensing, decision-making, and actuation keeps each component focused on a single responsibility and makes the overall system easier to reason about, extend, and validate. 5 References NXP Model-Based Design Toolbox (MBDT) Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344 Communicating over the CAN Bus S32N Vehicle Super-Integration Processors 6 Conclusion This article has provided an overview of the communication hub's core functionality, offering a high-level perspective on how key systems interact within the overall architecture. The main node was presented both as a data aggregator and as a decision-maker, with a particular emphasis on its role in safety-critical scenarios and its integration with the Simulink/MATLAB environment. Future installments in this series will take a deeper dive into the communication hub — covering the specific board in use, detailed hardware and software requirements, and other technical considerations and implementation nuances. Subsequent articles will also explore individual peripheral nodes in more detail, building up a complete picture of the system one subsystem at a time.
查看全文
S32K388 LPSPI SCKDIV 计算问题 - 为什么 1MHz 波特率下 SCKDIV=38? NXP社区的各位好, 我正在使用 S32K388,并配置 LPSPI 波特率。我有一个关于 SCKDIV 值计算的问题。 我的理解: 根据 S32K3xx 参考手册,LPSPI 波特率公式为: ``` SCK = LPSPI_CLK / (PRESCALE_DIV × (SCKDIV + 1)) ``` 我的配置: - LPSPI 时钟源:AIPS_SLOW_CLK = 40 MHz 目标波特率:1 MHz - PRESCALE = 0 (÷1) 我的计算结果: ``` SCDKIV = (LPSPI_CLK / 波特率) - 1 SCKDIV = (40 MHz / 1 MHz) - 1 = 39 ``` **S32DS 生成的代码:** 但是,当我使用 S32DS 生成配置时,却出现以下错误: ```c LPSPI_CCR_SCKDIV(38U) // SCKDIV = 38 ``` **问题:** 当 SCKDIV=38 时,实际除法系数为 39,这意味着: ``` 实际波特率 = 40 MHz / 39 = 1,025,641 Hz ≈ 1.026 MHz ``` 与目标 1 MHz 相比,误差约为 2.56%。 为什么 S32DS 使用 SCKDIV=38 而不是 SCKDIV=39?S32DS 配置中是否使用了不同的 LPSPI 时钟频率,或者选择这种频率还有其他原因? **补充背景信息:** 我使用的是 S32DS 3.5 - S32K388 参考手册 Rev. 6 - 该项目是使用默认时钟配置创建的 感谢您提前提供的任何解释! 顺祝商祺! Re: S32K388 LPSPI SCKDIV calculation question - why SCKDIV=38 for 1MHz baud rate? 嗨@xlele 首先,请注意,S32K3xx 参考手册的最新可用版本是 Rev. 12。您当前使用的版本包含有关 S32K310、S32K311 和 S32K3x8 设备的初步信息,这些设备在发布该文档时尚未发布。因此,我建议下载并参考RM的最新版本。 关于 LPSPI 波特率的计算,时钟配置寄存器 (CCR) 中 SCKDIV 字段的描述如下: 波特率 = 功能时钟 ÷ (2^预分频 × (SCKSET + SCKHLD + 2)) 其中 SCKSET 和 SCKHLD 由 SCKDIV ÷ 2 得出。 考虑到 SCKDIV = 38: SCKSET = SCKHLD = 38 ÷ 2 = 19 波特率 = 40 MHz ÷ (2^0 × (19 + 19 + 2)) = 1 MHz,与预期值相符。 BR,VaneB
查看全文
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にプルアップしてテストしてみて、この問題が解決するかどうか確認した方が良いでしょう。
查看全文
iMX8M Plus - SW1 電源オン/オフボタン こんにちは、 iMX8M Plus EVK の開発に取り組んでおり、SW1 を約 5 秒間押し続けると EVK の電源がオフになり、約 1 秒間押すと再び電源がオンになることを確認しました。この動作がハードウェアやPMICによって処理されるのか、それともソフトウェアによって処理されているのかを確認してください。 また、SW3をON位置に移動させると、SW1を押さずに自動的に電源が入ります。これがi.MX8M Plus EVKの想定されるデフォルト動作であるかどうかをご確認ください。 Re: iMX8M Plus - SW1 ON/OFF Button こんにちは、@Govind1807。 NXPサポートまでご連絡いただきありがとうございます。 この挙動はプロセッサ内に実装された内部FSMに関連しています。 より理解を深めていただくために、FSMの動作と状態遷移を示す対応するブロック図を添付しました。 Chavira_0-1782509945998.png よろしくお願いします、 チャビラ
查看全文
Codewarrior TAP 通过 JTAG 检测到了 MPC5200 你好, 我一直很苦恼,不知道如何将Codewarrior TAP调试器连接到配备MPC5200的定制应用板上。 探针是“ FREESCALE CodeWarrior USB TAP CWH-CTP-BASE-H E”。 探针尖端是我自己制作的。基本上,我在网站上找到了 2x15 连接器的引脚图/原理图,然后自己进行了板的接线。我在引脚 30 和地之间连接了一个 10 千欧姆的电阻。提示被识别为“电源架构/JTAG COP” 我一直只使用CCS控制台。我目前还没有使用过Codewarrior IDE。 当前状态: findcc 能正确检测到 TAP。 扫描板检测到 JTAG 链并报告: 设备 0:Altera FPGA(IDCODE 0x020B20DD) 设备 1:MPC5200B rev. 2.x(IDCODE 0x1001101D) 设备 2....7:IDCODE:FFFFFFFF,设备:未知设备。 OpenOCD 也检测到了完全相同的两个设备,因此 JTAG 链似乎是正确的。 目标设备已通电并正在运行其应用程序。 问题: 在CCS中配置处理器的任何尝试均失败: ccs::config_chain mgt5200 返回: mgt5200:未连接到目标或无法识别的处理器 ccs::get_config_chain总是报告“测试核心”而不是 mgt5200。 底层 JTAG 命令(如jtag::get_speed )总是返回:内部故障。 问题: MPC5200 是否支持任何硬件或软件机制,可以在禁用 JTAG 调试的同时仍然允许 IDCODE 扫描? CCS 识别 MPC5200 时,对 TRST、HRESET、引导程序或 BDM/JTAG 使能引脚是否有已知的要求? 是否有办法从 CCS 获取更详细的附件日志,以确定 IDCODE 扫描后哪个步骤失败? 非常感谢您抽出时间阅读本文。 米哈伊 Re: MPC5200 detected by Codewarrior TAP over JTAG 你好, 您观察到的行为(IDCODE 扫描工作但调试附加失败)与 MPC5200 架构一致。 根据 MPC5200 文档,该设备使用两级 JTAG 结构:一个主 TAP(用于标准 JTAG/IDCODE)和一个从 TAP(用于 CPU 调试,即 e300 COP 接口)。如果从设备 TAP 未启用或未正确选择,JTAG 检测可以工作,但调试器连接将失败。 建议查看: 正确处理 TRST 和复位信号(TAP 必须处于正确状态) 能够在连接过程中重置/固定设备 CPU调试(COP)接口可访问(未被硬件或配置阻止) 正确的 JTAG 链配置和 TAP 选择,尤其是在多设备链中 顺祝商祺! Peter
查看全文
GPIO_EMC_B2_18をFLEXSPI1_A_DQSとして設定し、クロック周波数を133 MHzに設定するにはどうすればいいですか? こんにちは、 i.MX RT1175のGPIO_EMC_B2_18をFLEXSPI1_A_DQSとして設定し、クロック周波数を133MHzに設定したい。 GPIO_EMC_B2_18起動時にFLEXSPI1_A_DQSに設定できないことは理解しています。 そのため、起動時に60MHzで動作させて、アプリケーション内で133MHzに変更しようとしていますが、うまくいきません。 私はevkbmimxrt1170_flexspi_nor_polling_transferプロジェクトを使用しており、`flexspi_nor_flash_ops.c`内の`flexspi_nor_flash_init()`の関連セクションを変更しました。 「`」 IOMUXC_SetPinMux(IOMUXC_GPIO_EMC_B2_18_FLEXSPI1_A_DQS, 1U); IOMUXC_SetPinConfig(IOMUXC_GPIO_EMC_B2_18_FLEXSPI1_A_DQS, 0x0AU); CLOCK_SetRootClockDiv(kCLOCK_Root_Flexspi1, 4); CLOCK_SetRootClockMux(kCLOCK_Root_Flexspi1, 5); config.rxSampleClock= kFLEXSPI_ReadSampleClkLoopbackFromDqsPad; 「`」 クロック周波数を133MHzに設定すると、システムがフリーズします。 「`」 CLOCK_SetRootClockDiv(kCLOCK_Root_Flexspi1, 5); CLOCK_SetRootClockMux(kCLOCK_Root_Flexspi1, 5); 「`」 クロック周波数を105MHzに設定すると動作します。 GPIO_EMC_B2_18をFLEXSPI1_A_DQSに設定し、クロック周波数を133 MHzに設定するにはどうすればいいですか? Re: How can I configure GPIO_EMC_B2_18 as FLEXSPI1_A_DQS and set the clock frequency to 133 MHz? こんにちは、@mayliu1 さん。 ご返信ありがとうございます。 セカンダリpingグループは100MHzでしか動作しないかもしれませんが、私はプライマリpingグループを使い、DQSだけをGPIO_EMC_B2_18に変更する予定です。理由は、USDHC2_CMD に GPIO_SD_B2_05 を使用しているためです。 ピン構成 FLEXSPI1_A_SS0_B GPIO_SD_B2_06 FLEXSPI1_A_SCLK GPIO_SD_B2_07 FLEXSPI1_A_DATA0 GPIO_SD_B2_08 FLEXSPI1_A_DATA1 GPIO_SD_B2_09 FLEXSPI1_A_DATA2 GPIO_SD_B2_10 FLEXSPI1_A_DATA3 GPIO_SD_B2_11 FLEXSPI1_A_DQS GPIO_SD_B2_05(ブーツ) アプリケーションでは、FLEXSPI1_A_DQSのみがGPIO_EMC_B2_18に変更されます。 FLEXSPI1_A_DQS GPIO_EMC_B2_18 テストとして、EVKのクロック周波数を60MHz(ブート時)から133MHzに変更しましたが、FLEXSPI1_A_DQSは変更せず、GPIO_SD_B2_05に設定したままにしました。すると、同じようにハングアップしました。 xip 設定が .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally に設定されているため、それをkFlexSPIReadSampleClk_LoopbackFromDqsPadに変更したところ、133MHzで動作させることができました。 次に、DQSをGPIO_EMC_B2_18に変更してみたところ、133MHzで動作させることができました。 このやり方は受け入れられるだろうか? また、起動時にはGPIO_SD_B2_05はフローティング状態ではありません。`kFlexSPIReadSampleClk_LoopbackFromDqsPad`に設定して60MHzで実行しても問題ありませんか? Re: How can I configure GPIO_EMC_B2_18 as FLEXSPI1_A_DQS and set the clock frequency to 133 MHz? こんにちは@Shuhei_Dさん 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 詳細については、以下の記事をご参照ください。 https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/RT-1176-FlexSPI-RW-frequency-DQS/mp/1871808 RT1170リファレンスマニュアルによると、セカンダリピングループを使用した場合、FlexSPIフラッシュの最大対応周波数は100 MHzです。 プロジェクトの構成を確認し、上記のリンクで説明されているシナリオに合致しているか確認していただけますか? お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: How can I configure GPIO_EMC_B2_18 as FLEXSPI1_A_DQS and set the clock frequency to 133 MHz? お返事ありがとうございます。 回路図を確認したところ、GPIO_EMC_B2_18がフローティング状態になっていることがわかりました。 Re: How can I configure GPIO_EMC_B2_18 as FLEXSPI1_A_DQS and set the clock frequency to 133 MHz? NORフラッシュの外付けを駆動するために、SPIのクロック周波数を60MHzから133MHzに変えたいようですね。しかし105MHzなら問題なさそうなので、SPI高周波数で信号の整合性をレイアウト側で確認する必要があるかもしれません。回路図を確認しますか? Re: How can I configure GPIO_EMC_B2_18 as FLEXSPI1_A_DQS and set the clock frequency to 133 MHz? こんにちは@Shuhei_Dさん ご辛抱いただきありがとうございます。 ご質問内容を再度確認しました。 プライマリDQS PINを使用し、セカンダリDQSオプションは使用しないでください。 mayliu1_0-1782368272303.png あなたの場合、もし主DQSピンがすでに別の機能に使われている場合、以下の構成を適用できます。ただし、この設定は最大60MHzまでしかサポートされていないことにご注意ください。 mayliu1_1-1782368409020.png お役に立てれば幸いです。 よろしくお願いいたします。 5月
查看全文