Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
示例 MPC5744P PMC SW 触发自检 GHS614 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ******************************************************************************** * 详细说明: * 本例演示了 PMC SW 触发的自检配置和执行 * ---------------------------------------------------------------------------------------------- * 测试硬件:MPC57xx * 掩模组:1N15P 和 0N15P * 目标:internal_FLASH * Fsys: 200 MHz PLL,带 40 MHz 晶振参考 * ******************************************************************************** 修订历史: 1.0 2016年4月4日 b21190(Vlna Peter)初始版本 1.1 2017 年 4 月 20 日 b21190(Vlna Peter)添加了软件 PMC 自检 ********************************************************************************************/ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ******************************************************************************** * 详细说明: * 本例演示了 PMC SW 触发的自检配置和执行 * ---------------------------------------------------------------------------------------------- * 测试硬件:MPC57xx * 掩模组:1N15P 和 0N15P * 目标:internal_FLASH * Fsys: 200 MHz PLL,带 40 MHz 晶振参考 * ******************************************************************************** 修订历史: 1.0 2016年4月4日 b21190(Vlna Peter)初始版本 1.1 2017 年 4 月 20 日 b21190(Vlna Peter)添加了软件 PMC 自检 ********************************************************************************************/
記事全体を表示
基于模型的设计工具箱电机控制示例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 该视频显示: - 采用 S32K144 rev2.0 的电机控制典型设置评估板; - 用于 BLDC 电机控制的 Simulink 模型; - 如何设置 Simulink 为 S32K144 rev2.0 生成 ANSI C 代码单片机; - 快速浏览基于模型的设计工具箱; - 快速浏览 FreeMASTER 数据可视化工具; - 使用 DevKit S32K144EVB 和 MotorGD 屏蔽运行的电机控制示例; (在 “我的视频” 中查看) 视频库 回复:基于模型的设计工具箱电机控制示例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 非常感谢! 回复:基于模型的设计工具箱电机控制示例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 谢谢分享,但是 C 代码在哪里?
記事全体を表示
CIT-N1924 MIFARE 超越票务——智慧城市的非接触式解决方案 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 过去几年,交通票务要求发生了重大变化——从交易安全到多应用需求以及将移动票务集成到现有环境的可能性。NXP 的 MIFARE ®产品始终能够满足这些要求,并作为提供便利性、灵活性和可扩展性的领先非接触式解决方案建立了良好的声誉。开放的 MIFARE 社区和生态系统由超过 1,000 个业务合作伙伴组成,其中包括应用程序开发商、服务和解决方案提供商、系统集成商和卡制造商。MIFARE DESFire EV2 是下一代 MIFARE IC,具有最高的硬件和软件安全级别(EAL5+ 通用标准认证)。其增强的密钥管理使其成为无限应用程序的理想多应用平台。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 过去几年,交通票务要求发生了重大变化——从交易安全到多应用需求以及将移动票务集成到现有环境的可能性。NXP 的 MIFARE ®产品始终能够满足这些要求,并作为提供便利性、灵活性和可扩展性的领先非接触式解决方案建立了良好的声誉。开放的 MIFARE 社区和生态系统由超过 1,000 个业务合作伙伴组成,其中包括应用程序开发商、服务和解决方案提供商、系统集成商和卡制造商。MIFARE DESFire EV2 是下一代 MIFARE IC,具有最高的硬件和软件安全级别(EAL5+ 通用标准认证)。其增强的密钥管理使其成为无限应用程序的理想多应用平台。 智能城市和智能基础设施
記事全体を表示
LPC177x_8x u-boot端口 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 该项目解释了如何使用 LPC177x_8x 设备为平台构建和部署 u-boot。要构建 u-boot,您需要运行 Linux 操作系统的系统、适用于 Linux 操作系统的最新 CodeSourcery GNU 工具、u-boot 源代码以及适用于 LPC1788 的 u-boot 补丁。 已实现的功能 -------------------------------------------------------------------------------- 支持带有 32 位 DRAM(32MB)的 EA1788 主板 支持EA1788板的NAND FLASH 支持LPC177x_8x内部FLASH 以太网支持 有限的 MPU 支持 u-boot 已知问题 -------------------------------------------------------------------------------- 问题:“重置”命令导致电路板崩溃 解决方法:改用“cmreset”命令 问题:“boot”命令导致主板崩溃 解决方法:使用环境变量和 go 命令编写脚本 问题:bootvx 命令导致主板崩溃 解决方法:无,但没有理由使用此命令 未实现的功能 -------------------------------------------------------------------------------- FLASH“保护”命令和功能未实现(易于实现) 未实现中断/NVIC 支持(易于实现) 可能的改进 -------------------------------------------------------------------------------- Systick 可以代替 LPC1788 匹配定时器 重定位代码已被“绕过”,并且未正确实施 针对设备特定 IRQ 的宏文件,即需要包含弱链接 在启动文件中(特定于架构的设备覆盖) 有一个基本的 MPU 驱动程序,似乎可以工作,但可以改进 以太网驱动程序和 PHY 设置是“特定于板的”,但可以移动 到驱动程序区域,可以使用通用 PHY 支持 u-boot 启动操作概述 -------------------------------------------------------------------------------- 以下是 u-boot 如何在 LPC1788 上启动的概述。 - LPC1788 启动 ROM 将控制权转移到内部 FLASH 中的 u-boot 代码 每个 CM3 启动过程的地址 0x0 - u-boot 代码首先设置 MPU - 引脚复用、时钟和 DRAM 均已初始化 - 代码和数据从 FLASH 迁移到 DRAM - DRAM 中的 BSS 段被清除 - 控制权转移到 DRAM 中的 u-boot 代码 - 调用 u-boot board_init_f() 进行初始 u-boot 设置 - board_init_r() 用于稍后的 u-boot 设置 - u-boot 在 DRAM 之外正常运行 移植文件的位置 -------------------------------------------------------------------------------- arch/arm/cpu/cortex-m3 - Cortex M3 特定文件(mpu、启动等) arch/arm/cpu/cortex-m3/lpc1788 - LPC1788 特定文件(计时器、串行等) arch/arm/include/asm/arch-cortex-m3 - Cortex M3 头文件 arch/arm/include/asm/arch-lpc17xx - LPC177x_8x 特定的头文件 board/nxp - 使用 NXP 设备的电路板专用区域 board/nxp/ea1788 - EA1788 板特定文件(设置、nand 等) include/configs/ea1788.h - EA1788 板特定配置文件
記事全体を表示
DES-N1849 多核 ARM ® v8 QorIQ 处理器中的异常处理 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 了解ARM®v8异常水平处理(ELO至EL3),以及基于最新的QorIQ LS系列处理器的通用中断控制器v3 (GICv3)逻辑在预封装的Linux SDK环境之外使用具有挑战性。 本次演示将介绍如何配置分发器(GICD)、再分发器(GICR)、CPU接口(ICC_*_EL*)和ARM内核,以处理专有外设中断(PPI)和软件触发的中断(SGI)。 它将用于嵌入式开发人员编写异常处理程序,以及被缩略词弄糊涂的任何人。 CodeWarrior将用于显示异常处理项目示例。 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 了解ARM®v8异常水平处理(ELO至EL3),以及基于最新的QorIQ LS系列处理器的通用中断控制器v3 (GICv3)逻辑在预封装的Linux SDK环境之外使用具有挑战性。 本次演示将介绍如何配置分发器(GICD)、再分发器(GICR)、CPU接口(ICC_*_EL*)和ARM内核,以处理专有外设中断(PPI)和软件触发的中断(SGI)。 它将用于嵌入式开发人员编写异常处理程序,以及被缩略词弄糊涂的任何人。 CodeWarrior将用于显示异常处理项目示例。 观看视频演示 设计 | 软件与服务
記事全体を表示
FRDM-KW40Z Bluetooth LE Controller Usage with the Linux hcitool Bluetooth Low Energy is a standard for Low Power Wireless Networks introduced in the Bluetooth specification 4.0. Its target application domains include medical, sports & fitness, home automation and others. The adoption and development rates of this technology are growing fast helped by the wide availability of hardware support in most modern mobile phones and mobile operating systems. The purpose of this application note is to show how the Freescale FRDM-KW40Z can board with BLE Controller software can be used with the hcitool from the Linux Bluetooth stack over the HCI interface. 1. Introduction The Bluetooth specification has a very well defined interface between the Controller and the Host called the HCI (Host Controller Interface). This interface is defined for and can be used with various transport layers including an asynchronous serial transport layer. A typical scenario of Bluetooth Low Energy hardware use is a development board which has a BLE Controller accessible via serial transport HCI connected to a device on which the BLE Host runs. The device which runs the BLE Host can be any type of embedded device or a PC. PCs running a Linux type OS can use the hcitool from the Linux Bluetooth Stack to interact with a BLE Controller via the HCI interface. The particular use case of  FRDM-KW40Z board with a serial transport HCI interface running over USB CDC and connected to a PC running the Linux Bluetooth stack is shown in the diagram below and will be detailed din the following sections. Figure 1FRDM-KW40Z (BLE Controller) connected to Linux PC (Bluetooth Host Stack) via HCI Serial Transport 2. Loading the HCI Application onto the FRDM-KW40Z First load the hci_app on the FRDM-KW40Z board. The hci_app aplication can be found in the \ConnSw\examples\bluetooth\hci_app folder. 3. Connecting the FRDM-KW40Z to the Computer via a Serial Port After the app is downloaded to the board plug the board into a free USB port of your Linux computer. The following instructions, commands and their output is typical to a Debian based Linux OS. After the board is plugged in run the following command to list the serial ports available. >> dmesg | grep tty [ 0.000000] console [tty0] enabled [ 2374.118201] cdc_acm 1-2:1.1: ttyACM0: USB ACM device In our example the FRDM-KW40Z board serial port is ttyACM0. To test the connection some HCI commands can be sent in hex format from any terminal application to the serial HCI on the FRDM-KW40Z board. In the figure below an HCI_Read_BD_ADDR command and its corresponding Command Complete Event are shown as they were sent and received in hexadecimal format from the moserial serial terminal GUI application. Figure 2: HCI command and response event in hexadecimal format (HCI UART Transport) 4. Connecting the HCI Serial Interface to the Bluetooth Stack To connect the Linux Bluetooth stack to a serial HCI interface the hciattach command must be run as shown below. >> hciattach /dev/ttyACM0 any 115200 noflow nosleep Device setup complete If the the HCI serial interface is successfully attached to the Bluetooth stack then the "Device setup complete" message is shown. The any parameter specifies a generic Bluetooth device. The 115200 parameter is the UART baudrate. The noflow parameter diasables serial flow control. The nosleep parameter disables hardware specific power managment. Run the hciconfig command with no parameters to check the HCI interface id of the newly attached HCI serial device. >> hciconfig hci1:    Type: BR/EDR  Bus: UART     BD Address: 00:04:9F:00:00:15  ACL MTU: 27:4 SCO MTU: 0:0     UP RUNNING     RX bytes:205 acl:0 sco:0 events:14 errors:0     TX bytes:112 acl:0 sco:0 commands:14 errors:0 hci0:    Type: BR/EDR  Bus: USB     BD Address: 90:00:4E:A4:70:97  ACL MTU: 310:10  SCO MTU: 64:8     UP RUNNING     RX bytes:595 acl:0 sco:0 events:37 errors:0     TX bytes:2564 acl:0 sco:0 commands:36 errors:0 In this example the FRDM-KW40Z is assigned the hci1 interface as can be seen from the bus type (Type: BR/EDR  Bus: UART). The hci0 interface is the example shown corresponds to the on-board Bluetooth module from the machine. On some systems the interface might need to be manually started by using the hciconfig interfaceId up command. hciconfig hci1 up 5. Configuring the Bluetooth Device and Listing its Capabilities The hciconfig command offers the possibility of configuring the device and listing the device capabilities. To find all commands supported by the hciconfig tool type the following command. >> hciconfig –h ...display supported commands... Each individual hciconfig command must be addressed to the correct HCI interface as reported above. In our example we use the hci1 interface. Some hciconfig commands require root privileges and must be run with sudo (the "Operation not permitted(1)" error will be returned if a command needs to be run with root privileges). Some useful hci config commands: >> hciconfig hci1 version    -> lists hci device verison information >> hciconfig hci1 revision    -> lists hci device revision information >> hciconfig hci1 features    -> lists the features supported by the device >> hciconfig hci1 commands    -> lists the hci commands supported by the device >> sudo hciconfig hci1 lestates    -> lists the BLE states supported by the device >> sudo hciconfig hci1 lerandaddr 11:22:33:44:55:66    -> set a random address on the device >> sudo hciconfig hci1 leadv 3    -> enable LE advertising of the specified type >> sudo hciconfig hci1 noleadv    -> disable LE advertising Now the newly connected board with a serial HCI is attached to a HCI interface of the Bluetooth stack and is ready to use. 6.    Controlling the Bluetooth Device using the hcitool The hcitool can be used to send HCI commands to the Bluetooth device. A command is available which lists all available hcitool actions. >> hcitool -h ...display supported commands... To target a specific HCI interface use the -i hciX option for an hcitool command. We will use -i hci1 in our examples. The hcitool supports commands for common BLE HCI operations some of which are shown below and also supports sending generic HCI commands using a dedicated option which uses hexadecimal numbers for the OGF (Command Group), OCF (Command Code) and the parameters. The 6 bit OGF and the 10 bit OCF compose the 16 bit HCI Command Opcode. The command parameters are specific to each command. 6.1.  Listing Devices Available to the hcitool An hcitool command can list all available device interfaces. >> hcitool dev Devices: hci1    00:04:9F:00:00:15 hci0    90:00:4E:A4:70:97 The device we are working with is connected to the hci1 interface as seen from the output of the hciconfig command used above. 6.2.  Scanning for Advertising LE Devices The hcitool can be used to perform a LE Device scan. This command requires root privileges. Press Ctrl+C to stop the scan at any time. >> sudo hcitool -i hci1 lescan LE Scan ... 00:04:9F:00:00:13 (FSL_OTAC) ^C A list of addresses and device names will be shown if advertised (< > or < > as define din the specification). 6.3.  Obtaining Remote LE Device Information Using the hcitool To obtain information about a remote LE device a special hcitool command can be used. The hcitool leinfo command creates a connection, extracts information from the remote device and then disconnects. The remote device information is shown at the command prompt. >> sudo hcitool -i hci1 leinfo 00:04:9F:00:00:13 Requesting information ...        Handle: 32 (0x0020)        LMP Version: 4.1 (0x7) LMP Subversion: 0x113        Manufacturer: Freescale Semiconductor, Inc. (511)        Features: 0x1f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 In this example information about a device previously discovered using the hcitool lescan command is shown. 6.4.  Connecting and Disconnecting from a Remote LE Device Connecting to a remote LE device is done using the hcitool lecc command. >> sudo hcitool -i hci1 lecc 00:04:9F:00:00:13 Connection handle 32 As before a previously discovered device address is used. If the connection is successful then the Connection Handle is returned and in our case the Connection Handle is 32. The hcitool con command shows active connections information: address, connection handle, role, etc. >> hcitool con Connections: < LE 00:04:9F:00:00:13 handle 32 state 1 lm MASTER To end a LE connection the hcitool ledc command can be used. It must be provided with the Connection Handle to be terminated, and optionally the reason. The device handle obtained after the connection and shown in the connected devices list is used. >> hcitool –I hci1 ledc 32 >> Listing the connections after all connections are terminated will show an empty connection list. >> hcitool con Connections: >> 6.5.  Sending Arbitrary HCI Commands To send arbitrary HCI commands to a device using the Command CopCode (OGF and OCF) the hcitool cmd command can be used. As an example the HCI_Read_BD_ADDR command is used which has the 0x1009 OpCode (OGF=0x04, OCF=0x009) and no parameters. It is the same command shown in the direct serial port to HCI communication example above. hcitool -i hci0 cmd 0x04 0x0009 < HCI Command: ogf 0x04, ocf 0x0009, plen 0 > HCI Event: 0x0e plen 10   01 09 10 00 15 00 00 9F 04 00 The OpCode OGF (0x04) and OCF (0x009) and no parameters are passed to the hcitool cmd command all in hexadecimal format. The parameters length (plen) is 0 for the command. The response is a Command Complete event (0x03) with the parameters length (plen) 10. The parameters are 01 09 10 00 15 00 00 9F 04 00: 01 is the Num_HCI_Command_Packets parameter 09 10 is the Command OpCode for which this Command Complete Event is returned (in little endian format) 00 is the status – Success in this case 15 00 00 9F 04 00 is the BD_ADDR of the device as listed by the hcitool dev command KW41Z31Z21Z
記事全体を表示
KSDK发布的内容 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Kinetis SDK v2 现已推出! Kinetis SDK v2 简介 KSDK 的第一步 如何开始使用 KSDK * 已发布示例列表: KSDK示例列表* 已发布文件清单: KSDK 文件清单* *以上所有源代码仅供示例使用。恩智浦不对用户应用程序中使用这些代码承担任何责任。 概述
記事全体を表示
Boundary Devices - Android Lollipop NFC 演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 这里有一个视频,展示了集成到我们的Android Lollipop 5.0.0 代码库中的 NFC 功能。它与 NXP PN7120 开发套件 一起在我们的 Nitrogen6x 平台上运行。 视频显示,使用 Boundary 的 URL 编程的 NFC 标签会被自动读取并相应地启动浏览器。 为了从 NFC 数据读取/写入数据,Android 提供了一个完整记录的 API 。 如果您正在寻找现有的应用程序来编写标签,那么有几个选项: NXP TagWriter应用程序 StickyNotes 示例代码 如需了解更多信息,请访问http://boundarydevices.com/ 概述
記事全体を表示
基于 LS2085 NADK 的 IPSEC 应用程序与 AIOP 通信 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在LS2085平台上,基本网络产品在AIOP上执行自主IP转发和IPSEC,数据路径功能大多独立于GPP软件运行,并且仅在必要时涉及GPP。 NADK(网络加速开发套件)是一个完整的用于网络应用程序的用户空间开发套件。 该IPSEC应用程序使用NADK框架在Linux用户空间中实现,该应用程序通过netlink事件通知学习Linux配置,并使用相应的NF API将配置发送到AIOP DP。应用程序调用 NF API 将配置详细信息发送到 AIOP 上的 IPsec 数据路径。 1.基于AIOP-NADK的IPSEC应用概述及架构 2.基于NADK的GPP监听器程序设计 2.1 应用程序中使用的NADK API介绍 2.2 多线程模式下NADK应用程序的数据包处理 2.3 监听器监控的IPSEC XFRM事件 3. IPSEC应用程序通过NF API与AIOP通信 3.1 AIOP 实现的 IPSEC 功能 3.2 用于配置AIOP的IPSEC NF API 3.3 在IPSEC应用中添加SPD策略的流程 4. 设置网络环境以验证 IPSEC 应用程序 QorIQ LS2 设备
記事全体を表示
DwF Automotive Solutions - Chongqing - 2015-08-19 Automotive and Connected Car
記事全体を表示
DwF MCUおよびオートモーティブソリューション - Tianan - 2015-03-19 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 自動車およびコネクテッドカー 車載用マイクロコントローラの概要 : KinetisおよびS12 MagniVミックスド・シグナル・マイクロコントローラを含む BCCおよび高圧センサを搭載した車載用アナログおよびセンサの概要 インサイトとイノベーション Kinetisマイクロコントローラの概要 - Kinetisの性能上の利点とアプリケーション 設計、ソフトウェア、サービス フリースケールMQX™ RTOSの概要 ARM®プロセッサ キネティスCortex®-Mマイクロコントローラー センサ ソフトウェアとツール
記事全体を表示
iMX28 WinCE 6.0 UART 驱动程序更新以修复 RX DMA 数据丢失问题。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 最新的 iMX28 WinCE 6.0 BSP“WCE600_MX28_SDK1008”存在 UART RX DMA 数据丢失问题。 测试用例以重现该问题: 使用 UART 电缆连接 iMX28 UART1 和 PC,然后在 iMX28 和 PC 端运行一些 UART 测试应用程序,PC 可以向 IMX28 发送文件,文件大小应大于默认 RX DMA 缓冲区大小 1024 字节,然后从 iMX28 端,将会丢失数据。 附件“SERIALAPP.zip”是更新的UART驱动程序代码,用于修复此问题,您可以解压缩并将其更新到“ wince600\platform\common\src\soc\common_fsl_v2_pdk1_9\serialapp ”文件夹,并重建WinCE映像。 本次更新针对 UART RX DMA 实现了以下改进: 1.添加DMA恢复代码。 当 DMA 模式下发生 UART 错误时,驱动程序将重新初始化 DMA 以进行下一次传输。 2.将UART DMA超时中断设置为5ms。“#定义SERIAL_DMA_RX_TIMEOUT 5” UART DMA中断发生后,IST需要将数据从DMA缓冲区复制到MDD缓冲区,因此需要时间。默认的BSP已经把这个延迟设置为31位传输时间,这个时间非常短,如果PC向iMX28发送“DMA缓冲区+1”个字节,在第一次DMA缓冲区满中断发生后,很快就会发生第二次DMA超时中断,这个中断将会丢失,因为驱动程序仍在处理预中断。 3. 更新 MDD 代码以确保发送到 PDD 的缓冲区始终大于 RX DMA 缓冲区。 此 MDD 代码修改仅在 DMA 模式下有效,因此对 PIO 模式没有影响。 4.更新UART DMA中断处理程序代码。 当发生UART DMA中断时,立即设置下一次DMA传输,这样DMA就可以继续用另一个DMA缓冲区接收数据,同时IST会将数据从预DMA缓冲区复制到MDD缓冲区。 回复:iMX28 WinCE 6.0 UART 驱动程序更新以修复 RX DMA 数据丢失问题。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您看到我关于这个问题的长篇文章了吗?我发现是循环缓冲区的处理导致了 RX DMA 数据丢失。这篇文章中有很多信息,但我的修复似乎与您的不同,所以看起来我可能也需要研究您的更改! i.MX28 Windows CE BSP 串行端口错误导致接收数据丢失 Mark
記事全体を表示
Example S32K312 PIT BTCU parallel ADC FIFO DMA DS3.5 RTD300 This example for S32K312 is based on this, example on S32K344 :-- https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-PIT-BTCU-parallel-ADC-FIFO-DMA-DS3-5-RTD300/ta-p/1732444 *******************************************************************************  The purpose of this demo application is to present a usage of the  ADC_SAR and BCTU IP Driver for the S32K3xx MCU.  The example uses the PIT0 trigger to trigger BCTU conversion list to  perform parallel conversions on ADC0/ADC1. Three ADC channels  are selected to be converted on each ADC:  ADC0: S8 , P0, S8  ADC1: S10, S13, S17  Converted results from BCTU FIFO are moved by DMA into result array.  ADC channel S10 is connected to board's potentiometer.  ------------------------------------------------------------------------------ * Test HW: S32K3X4EVB-Q172 * MCU: S32K312 * Compiler: S32DS3.5 * SDK release: RTD 3.0.0 * Debugger: PE Micro * Target: internal_FLASH ******************************************************************************** Set PIT Freeze Enable :--- BCTU will be do the parallel conversion for channel mentioned in BCTU list :--   "NEW DATA DMA enable mask" :-- controls These bit field in MCR register "ADC target mask" :-- It controls "ADC_SEL " bit field in "Trigger Configuration (TRGCFG_0 - TRGCFG_71)" for single conversions you can enable only one instance so the possible values for target mask: 1 (0b001) ADC0 2 (0b010) ADC1 3 (0b100) ADC2| for list of conversions we can enable also parallel con version for example 3 (0b011) parallel conversion of ADC0 and ADC1 The trigger is configured as a list of parallel conversions ADC0, ADC1 in “Adc Target Mask”. List of ADC channels is defined in “BCTU List Items” while order is given by the “Adc Target Mask”: BctuListItems_0 is ADC0, BctuListItems_1 is ADC1 etc. Result :-- I connected VDD from board on adc_0_p0 (PTD1 : J412-1)  and adc_1_p2 (PTE0 J412-13). Also POT value on S10 of ADC-1 & ADC-0-VREFH value coming correct & STABLE. =========================Using  FIFO-2 ================= FIFO-2 Trigger & LIST Index :-- ADC channel conversion :--
記事全体を表示
S32K3 Motor control SW examples The S32K3 family of 32-bit AEC-Q100 qualified MCUs combines a scalable family of Arm® Cortex-M7-based microcontrollers built on long-lasting features with a comprehensive suite of production-grade tools. S32K3 MCUs are included in NXP’s Product Longevity Program, guaranteeing a minimum of 15 years of assured supply. The S32K3 offers dedicated peripherals set for rapid motor control loop implementation: enhanced Modular IO Subsystem(eMIOS), Logic Control Unit (LCU), TRGMUX, BodyCross-triggering Unit (BCTU), Analog to Digital Converter(ADC), and Analog Comparator (CMP). The comprehensive motor control ecosystem based on Automotive Math and Motor Control Library(AMMCLib) set, FreeMASTER with Motor Control ApplicationTuning (MCAT) tool and Model-Based Design Toolbox (MBDT) helps to enable S32K3 MCU in wide range of motor control use cases. The table below points to the articles with more detailed description each of S32K3 motor control use cases, hardware description, links to appropriate application notes and their addendums, and software repositories.  Device HW Article S32K344 MCSPTE1AK344 12 V development kit engineered for 3-phase PMSM and BLDC motor control applications FOC with dual shunt current measurement Article focuses on solution based Field Oriented Control (FOC) technique (typically used for 3-phase PMSM motors) with dual shunt current measurement and without any position sensor (sensorless). The Encoder sensor is supported by SW option, but missing on HW kit. The available example codes covers both ANSI-C and Matlab Simulink approaches and uses RTD drivers with high-level Autosar compliant API or low-level non-Autosar API.    FOC with single shunt current measurement Article focuses on solution based Field Oriented Control (FOC) technique (typically used for 3-phase PMSM motors) with single shunt current measurement and without any position sensor (sensorless). The Encoder sensor is supported by SW option, but missing on HW kit. The single shunt current measurement is advanced technique that allows decrese the cost of Bill of Material (BOM). The available example codes covers both ANSI-C and Matlab Simulink approaches and uses RTD drivers with high-level Autosar compliant API or low-level non-Autosar API.    FOC integrated with FreeRTOS Article focuses on integration of motor control software (based on FOC with dual shunt current measurement) and Real Time Operating System (FreeRTOS). The available example code is based ANSI-C  code and uses RTD drivers with low-level non-Autosar API.    Six-step commutation control. Article focuses on solution based Six-step commutation (6-step) technique (typically used for 3-phase BLDC motors) with Hall position sensor and without any position sensor (sensorless). The available example codes covers both ANSI-C and Matlab Simulink approaches and uses RTD drivers with low-level non-Autosar API.    Note: the list of use cases cannot cover all combinations of MCU, current measurement scenario, control technique and sensor inputs, but should work as a base reference for most common configurations. This list is not final, please follow this acticle to be notified about updates with new use cases.   
記事全体を表示
How to enable DDR mode As we know, the RT series MCUs support the XIP (Execute in place) mode and benefit from saving the number of pins, serial NOR Flash is most commonly used, as the FlexSPI module can high efficient fetch the code and data from the Serial NOR flash for Cortex-M7 to execute. The fetch way is implementing via utilizing the Quad IO Fast Read command, meanwhile, the serail NOR flash works in the SDR (Single Data transfer Rate) mode, it receives data on SCLK rise edge and transmits data on SCLK fall edge. Comparing to the SDR mode, the DDR (Dual Data transfer Rate) mode has a higher throughput capacity, whether it can provide better performance of XIP mode, and how to do that if we want the Serial NOR Flash to work in DDR (Dual Data transfer Rate) mode? SDR & DDR mode SDR mode: In SDR (Single Data transfer Rate) mode, data is only clocked on one edge of the clock (either the rising or falling edge). This means that for SDR to have data being transmitted at X Mbps, the clock bit rate needs to be 2X Mbps. DDR mode: For DDR (Dual Data transfer Rate) mode, also known as DTR (Dual Transfer Rate) mode, data is transferred on both the rising and falling edge of the clock. This means data is transmitted at X Mbps only requires the clock bit rate to be X Mbps, hence doubling the bandwidth (as Fig 1 shows).   Fig 1 Enable DDR mode The below steps illustrate how to make the i.MX RT1060 boot from the QSPI with working in DDR mode. Note: The board is MIMXRT1060, IDE is MCUXpresso IDE Open a hello_world as the template Modify the FDCB(Flash Device Configuration Block) a)Set the controllerMiscOption parameter to supports DDR read command. b) Set Serial Flash frequency to 60 MHz. c)Parase the DDR read command into command sequence. The following table shows a template command sequence of DDR Quad IO FAST READ instruction and it's almost matching with the FRQDTR (Fast Read Quad IO DTR) Sequence of IS25WP064 (as Fig 2 shows).   Fig2 FRQDTR Sequence d)Adjust the dummy cycles. The dummy cycles should match with the specific serial clock frequency and the default dummy cycles of the FRQDTR sequence command is 6 (as the below table shows).   However, when the serial clock frequency is 60MHz, the dummy cycle should change to 4 (as the below table shows).   So it needs to configure [P6:P3] bits of the Read Register (as the below table shows) via adding the SET READ PARAMETERS command sequence(as Fig 3 shows) in FDCB manually. Fig 3 SET READ PARAMETERS command sequence In further, in DDR mode, the SCLK cycle is double the serial root clock cycle. The operand value should be set as 2N, 2N-1 or 2*N+1 depending on how the dummy cycles defined in the device datasheet. In the end, we can get an adjusted FCDB like below. // Set Dummy Cycles #define FLASH_DUMMY_CYCLES 8 // Set Read register command sequence's Index in LUT table #define CMD_LUT_SEQ_IDX_SET_READ_PARAM 7 // Read,Read Status,Write Enable command sequences' Index in LUT table #define CMD_LUT_SEQ_IDX_READ 0 #define CMD_LUT_SEQ_IDX_READSTATUS 1 #define CMD_LUT_SEQ_IDX_WRITEENABLE 3 const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackFromDqsPad, .csHoldTime = 3u, .csSetupTime = 3u, // Enable DDR mode .controllerMiscOption = kFlexSpiMiscOffset_DdrModeEnable | kFlexSpiMiscOffset_SafeConfigFreqEnable, .sflashPadType = kSerialFlash_4Pads, //.serialClkFreq = kFlexSpiSerialClk_100MHz, .serialClkFreq = kFlexSpiSerialClk_60MHz, .sflashA1Size = 8u * 1024u * 1024u, // Enable Flash register configuration .configCmdEnable = 1u, .configModeType[0] = kDeviceConfigCmdType_Generic, .configCmdSeqs[0] = { .seqNum = 1, .seqId = CMD_LUT_SEQ_IDX_SET_READ_PARAM, .reserved = 0, }, .lookupTable = { // Read LUTs [4*CMD_LUT_SEQ_IDX_READ] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xED, RADDR_DDR, FLEXSPI_4PAD, 0x18), // The MODE8_DDR subsequence costs 2 cycles that is part of the whole dummy cycles [4*CMD_LUT_SEQ_IDX_READ + 1] = FLEXSPI_LUT_SEQ(MODE8_DDR, FLEXSPI_4PAD, 0x00, DUMMY_DDR, FLEXSPI_4PAD, FLASH_DUMMY_CYCLES-2), [4*CMD_LUT_SEQ_IDX_READ + 2] = FLEXSPI_LUT_SEQ(READ_DDR, FLEXSPI_4PAD, 0x04, STOP, FLEXSPI_1PAD, 0x00), // READ STATUS REGISTER [4*CMD_LUT_SEQ_IDX_READSTATUS] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x01), [4*CMD_LUT_SEQ_IDX_READSTATUS + 1] = FLEXSPI_LUT_SEQ(STOP, FLEXSPI_1PAD, 0x00, 0, 0, 0), // WRTIE ENABLE [4*CMD_LUT_SEQ_IDX_WRITEENABLE] = FLEXSPI_LUT_SEQ(CMD_SDR,FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x00), // Set Read register [4*CMD_LUT_SEQ_IDX_SET_READ_PARAM] = FLEXSPI_LUT_SEQ(CMD_SDR,FLEXSPI_1PAD, 0x63, WRITE_SDR, FLEXSPI_1PAD, 0x01), [4*CMD_LUT_SEQ_IDX_SET_READ_PARAM + 1] = FLEXSPI_LUT_SEQ(STOP,FLEXSPI_1PAD, 0x00, 0, 0, 0), }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, }; Is DDR mode real better? According to the RT1060's datasheet, the below table illustrates the maximum frequency of FlexSPI operation, as the MIMXRT1060's onboard QSPI flash is IS25WP064AJBLE, it doesn't contain the MQS pin, it means set MCR0.RXCLKsrc=1 (Internal dummy read strobe and loopbacked from DQS) is the most optimized option. operation mode RXCLKsrc=0 RXCLKsrc=1 RXCLKsrc=3 SDR 60 MHz 133 MHz 166 MHz DDR 30 MHz 66 MHz 166 MHz In another word, QSPI can run up to 133 MHz in SDR mode versus 66 MHz in DDR mode. From the perspective of throughput capacity, they're almost the same. It seems like DDR mode is not a better option for IS25WP064AJBLE and the following experiment will validate the assumption. Experiment mbedtls_benchmark I use the mbedtls_benchmark as the first testing demo and I run the demo under the below conditions: 100MH, SDR mode; 133MHz, SDR mode; 66MHz, DDR mode; According to the corresponding printout information (as below shows), I make a table for comparison and I mark the worst performance of implementation items among the above three conditions, just as Fig 4 shows. SDR Mode run at 100 MHz. FlexSPI clock source is 3, FlexSPI Div is 6, PllPfd2Clk is 720000000 mbedTLS version 2.16.6 fsys=600000000 Using following implementations: SHA: DCP HW accelerated AES: DCP HW accelerated AES GCM: Software implementation DES: Software implementation Asymmetric cryptography: Software implementation MD5 : 18139.63 KB/s, 27.10 cycles/byte SHA-1 : 44495.64 KB/s, 12.52 cycles/byte SHA-256 : 47766.54 KB/s, 11.61 cycles/byte SHA-512 : 2190.11 KB/s, 267.88 cycles/byte 3DES : 1263.01 KB/s, 462.49 cycles/byte DES : 2962.18 KB/s, 196.33 cycles/byte AES-CBC-128 : 52883.94 KB/s, 10.45 cycles/byte AES-GCM-128 : 1755.38 KB/s, 329.33 cycles/byte AES-CCM-128 : 2081.99 KB/s, 279.72 cycles/byte CTR_DRBG (NOPR) : 5897.16 KB/s, 98.15 cycles/byte CTR_DRBG (PR) : 4489.58 KB/s, 129.72 cycles/byte HMAC_DRBG SHA-1 (NOPR) : 1297.53 KB/s, 448.03 cycles/byte HMAC_DRBG SHA-1 (PR) : 1205.51 KB/s, 486.04 cycles/byte HMAC_DRBG SHA-256 (NOPR) : 1786.18 KB/s, 327.70 cycles/byte HMAC_DRBG SHA-256 (PR) : 1779.52 KB/s, 328.93 cycles/byte RSA-1024 : 202.33 public/s RSA-1024 : 7.00 private/s DHE-2048 : 0.40 handshake/s DH-2048 : 0.40 handshake/s ECDSA-secp256r1 : 9.00 sign/s ECDSA-secp256r1 : 4.67 verify/s ECDHE-secp256r1 : 5.00 handshake/s ECDH-secp256r1 : 9.33 handshake/s DDR Mode run at 66 MHz. FlexSPI clock source is 2, FlexSPI Div is 5, PllPfd2Clk is 396000000 mbedTLS version 2.16.6 fsys=600000000 Using following implementations: SHA: DCP HW accelerated AES: DCP HW accelerated AES GCM: Software implementation DES: Software implementation Asymmetric cryptography: Software implementation MD5 : 16047.13 KB/s, 27.12 cycles/byte SHA-1 : 44504.08 KB/s, 12.54 cycles/byte SHA-256 : 47742.88 KB/s, 11.62 cycles/byte SHA-512 : 2187.57 KB/s, 267.18 cycles/byte 3DES : 1262.66 KB/s, 462.59 cycles/byte DES : 2786.81 KB/s, 196.44 cycles/byte AES-CBC-128 : 52807.92 KB/s, 10.47 cycles/byte AES-GCM-128 : 1311.15 KB/s, 446.53 cycles/byte AES-CCM-128 : 2088.84 KB/s, 281.08 cycles/byte CTR_DRBG (NOPR) : 5966.92 KB/s, 97.55 cycles/byte CTR_DRBG (PR) : 4413.15 KB/s, 130.42 cycles/byte HMAC_DRBG SHA-1 (NOPR) : 1291.64 KB/s, 449.47 cycles/byte HMAC_DRBG SHA-1 (PR) : 1202.41 KB/s, 487.05 cycles/byte HMAC_DRBG SHA-256 (NOPR) : 1748.38 KB/s, 328.16 cycles/byte HMAC_DRBG SHA-256 (PR) : 1691.74 KB/s, 329.78 cycles/byte RSA-1024 : 201.67 public/s RSA-1024 : 7.00 private/s DHE-2048 : 0.40 handshake/s DH-2048 : 0.40 handshake/s ECDSA-secp256r1 : 8.67 sign/s ECDSA-secp256r1 : 4.67 verify/s ECDHE-secp256r1 : 4.67 handshake/s ECDH-secp256r1 : 9.00 handshake/s Fig 4 Performance comparison We can find that most of the implementation items are achieve the worst performance when QSPI works in DDR mode with 66 MHz. Coremark demo The second demo is running the Coremark demo under the above three conditions and the result is illustrated below. SDR Mode run at 100 MHz. FlexSPI clock source is 3, FlexSPI Div is 6, PLL3 PFD0 is 720000000 2K performance run parameters for coremark. CoreMark Size : 666 Total ticks : 391889200 Total time (secs): 16.328717 Iterations/Sec : 2449.671999 Iterations : 40000 Compiler version : MCUXpresso IDE v11.3.1 Compiler flags : Optimization most (-O3) Memory location : STACK seedcrc : 0xe9f5 [0]crclist : 0xe714 [0]crcmatrix : 0x1fd7 [0]crcstate : 0x8e3a [0]crcfinal : 0x25b5 Correct operation validated. See readme.txt for run and reporting rules. CoreMark 1.0 : 2449.671999 / MCUXpresso IDE v11.3.1 Optimization most (-O3) / STACK SDR Mode run at 133 MHz. FlexSPI clock source is 3, FlexSPI Div is 4, PLL3 PFD0 is 664615368 2K performance run parameters for coremark. CoreMark Size : 666 Total ticks : 391888682 Total time (secs): 16.328695 Iterations/Sec : 2449.675237 Iterations : 40000 Compiler version : MCUXpresso IDE v11.3.1 Compiler flags : Optimization most (-O3) Memory location : STACK seedcrc : 0xe9f5 [0]crclist : 0xe714 [0]crcmatrix : 0x1fd7 [0]crcstate : 0x8e3a [0]crcfinal : 0x25b5 Correct operation validated. See readme.txt for run and reporting rules. CoreMark 1.0 : 2449.675237 / MCUXpresso IDE v11.3.1 Optimization most (-O3) / STACK DDR Mode run at 66 MHz. FlexSPI clock source is 2, FlexSPI Div is 5, PLL3 PFD0 is 396000000 2K performance run parameters for coremark. CoreMark Size : 666 Total ticks : 391890772 Total time (secs): 16.328782 Iterations/Sec : 2449.662173 Iterations : 40000 Compiler version : MCUXpresso IDE v11.3.1 Compiler flags : Optimization most (-O3) Memory location : STACK seedcrc : 0xe9f5 [0]crclist : 0xe714 [0]crcmatrix : 0x1fd7 [0]crcstate : 0x8e3a [0]crcfinal : 0x25b5 Correct operation validated. See readme.txt for run and reporting rules. CoreMark 1.0 : 2449.662173 / MCUXpresso IDE v11.3.1 Optimization most (-O3) / STACK After comparing the CoreMark scores, it gets the lowest CoreMark score when QSPI works in DDR mode with 66 MHz. However, they're actually pretty close. Through the above two testings, we can get the DDR mode maybe not a better option, at least for the i.MX RT10xx series MCU. i.MXRT 102x i.MXRT 105x i.MXRT 106x
記事全体を表示
Example S32K344 UART Transmit & Receive Using DMA DS3.5 RTD300 *******************************************************************************  The purpose of this demo application is to present a usage of the  UART IP Driver for the S32K3xx MCU.  The example uses LPUART6 for transmit & receive five bytes using the DMA.  ------------------------------------------------------------------------------ * Test HW: S32K3X4EVB-T172 * MCU: S32K344 * Compiler: S32DS3.5 * SDK release: RTD 3.0.0 * Debugger: PE micro * Target: internal_FLASH ******************************************************************************** Putty output :-- Re: Example S32K344 UART Transmit & Receive Using DMA DS3.5 RTD300 Hi @Dinesh_Guleria , Can we use DMA without Autosar (RM CDD)?  Re: Example S32K344 UART Transmit & Receive Using DMA DS3.5 RTD300 @Dinesh_Guleria  do you have an example of DMA UART in RTD 4.0.0?
記事全体を表示
[Sharing/i.MX8MP]Download image via USB OTG2 on i.MX8MP On i.MX8MP EVK, image is downloaded into eMMC/SD via OTG1, if customer wants to enable USB OTG2 on i.MX8MP for uuu tool. Pls find modification as attached. Linux Re: [Sharing/i.MX8MP]Download image via USB OTG2 on i.MX8MP How to use the files?
記事全体を表示
Porting PN7160 to Android 14 on i.MX8M Nano board Recently NXP released a combined NCI stack for both PN7160 and Pn7220. The newest Android 14 porting guide AN14430 brings the two (PN7160 and PN7220) together.   The pros are it is easy to maintain, and faster integration and switching between products.  The cons are when you are using PN7160, you will see for APIs for PN7220, including EMVCo and TDA API. When you are using PN7220 also APIs for PN7160 can be seen (card emulation on PN7160).  This article is a step-by-step guide on how to build AOSP for PN7160 with the new combined NCI stack.  1  Hardware setup   i.MX 8M Nano Evaluation Kit | NXP Semiconductors   OM27160| Development Kits for PN7160 Plug’n Play NFC Controller | NXP Semiconductors   The connection between i.MX8M Nano and PN7160 OM29110ARD-B i.MX8M Nano EVK pin PN7160  OM29110ARD-B 3.3V J1003-1 VDD(3.3v) J1-4 5V J1003-2 VBAT (5v) J1-5  SDA.1 J1003-3 SDA J2-2 SCL.1 J1003-5 SCL J2-1 GPIO.25 J1003-37 IRQ J2-10 GPIO.28 J1003-38 REQ J4-2 GND J1003-39 GND J1-6 GPIO.29 J1003-40 VEN J4-1 2    Get AOSP for i.MX Nano Follow Android porting guide. https://www.nxp.com/docs/en/user-guide/ANDROID_USERS_GUIDE.pdf .2.1  Download i.MX Android BSP (Android14.0.0_1.2.0) from below link.  Android OS for i.MX Applications Processors | NXP Semiconductors   You will get the package imx-android-14.0.0_1.2.0.tar.gz    .2.2 Decompressing android BSP # tar -xvzf imx-android-1c4.0.0_1.2.0.tar.gz  When decompression is done, imx-android-14.0.0_1.2.0 subdirectory is created, in the folder, we can find imx_android_setup.sh, which is script for downloading android source code and commands for patching i.MX android bsp to AOSP. .2.3 Downloading Android source code # source ./imx-android-14.0.0_1.2.0/imx_android_setup.sh  The folder structure after AOSP downloading complete.  3     AOSP Adaptation NXP adds modifications to the AOSP code. Next, we add them step by step according to AN14430, move the content of them into correct folder in AOSP code base. .3.1  nxp_nci_hal_nfc #git clone "https://github.com/nxp-nfc-infra/nxp_nci_hal_nfc.git" #cd nxp_nci_hal_nfc #git checkout br_ar_14_comm_infra_dev #cp -rf *  ../android_build/packages/apps/Nfc/ #cd .. .3.2 nxp_nci_hal_libnfc-nci #git clone "https://github.com/nxp-nfc-infra/nxp_nci_hal_libnfc-nci.git" #cd nxp_nci_hal_libnfc-nci #git checkout br_ar_14_comm_infra_dev #cp -rf *  ../android_build/system/nfc/ #cd .. .3.3 nfcandroid_nfc_hidlimpl #git clone "https://github.com/nxp-nfc-infra/nfcandroid_nfc_hidlimpl.git" #cd nfcandroid_nfc_hidlimpl #git checkout br_ar_14_comm_infra_dev #cp -rf *  ../android_build/hardware/nxp/nfc #cd .. .3.4 nfcandroid_frameworks #git clone "https://github.com/nxp-nfc-infra/nfcandroid_frameworks.git" #cd nfcandroid_frameworks #git checkout br_ar_14_comm_infra_dev #mkdir ../android_build/vendor/nxp/frameworks #cp -rf * ../android_build/vendor/nxp/frameworks #cd .. .3.5 nfcandroid_emvco_aidlimpl #git clone "https://github.com/nxp-nfc-infra/nfcandroid_emvco_aidlimpl.git" #cd nfcandroid_emvco_aidlimpl #git checkout br_ar_14_comm_infra_dev #mkdir  ../android_build/hardware/nxp/emvco #cp -rf *  ../android_build/hardware/nxp/emvco #cd .. .3.6   nfcandroid_platform_reference #git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_reference.git" #cd nfcandroid_platform_reference #git checkout br_ar_14_comm_infra_dev #cp -rf vendor/nxp/*   ../android_build/vendor/nxp/ #cd .. .3.7 nfcandroid_infra_test_apps # git clone https://github.com/nxp-nfc-infra/nfcandroid_infra_test_apps.git # cd nfcandroid_infra_test_apps/ # git checkout br_ar_14_comm_infra_dev # cd test_apps/ # cp -rf SMCU_Switch/  ../../android_build/packages/apps/ # cp -rf EMVCoModeSwitchApp/  ../../android_build/packages/apps/Nfc/ # cd ../.. .3.8  nfcandroid_infra_comm_libs #git clone "https://github.com/nxp-nfc-infra/nfcandroid_infra_comm_libs.git" #cd nfcandroid_infra_comm_libs #git checkout br_ar_14_comm_infra_dev #cp -rf nfc_tda/  ../android_build/system/ #cp -rf emvco_tda/ emvco_tda_test/  ../android_build/hardware/nxp/emvco/ #cp -rf NfcTdaTestApp/  ../android_build/packages/apps/Nfc/ #cd .. After AOSP adaptation, folder is like below.  4   Apply AOSP patches please see AN14430, page10   # patch -p1 <  ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_bazel.patch #patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_make.patch # patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_soong.patch # patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_frameworks_base.patch #patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_frameworks_native.patch #patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_frameworks_proto_logging.patch #patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_system_logging.patch #patch -p1 < ../../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_packages_modules_Bluetooth.patch  5    Adding the driver support. .5.1  get nfcandroid_platform_drivers from github #git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_drivers.git" #cd nfcandroid_platform_drivers #git checkout br_ar_14_comm_infra_dev #cd .. .5.2Create a folder named pn7160 under android_build/vendor/nxp-opensource/kernel_imx/drivers/nfc Copy below kernel drivers file from “nfcandroid_platform_drivers/drivers/pn7160/nfc/nfc “ into  “android_build/vendor/nxp-opensource/kernel_imx/drivers/nfc/pn7160/” Common.c  common.h   i2c_drv.c  i2c_drv.h spi_drv.h  spi_drv.c  Makefile  Kconfig Result of copying: .5.3 Modify makefile Replace Makefile default code with following code,  only add i2c for simplifying.  Now we need to add pn7160 Makefile and Kconfig to main Makefile and Kconfig Makefile Kconfig 6   Adding device tree Device tree is important since we need to tell our controller which pins we want to use for communication (this is always different between host controllers) The device tree need to be added into: “vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale” Create file with name “imx8mn-evk-pn7160.dts”, open the file and add following lines: Next task is to add .dts file into Makefile in the following location: . vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale Open Makefile and add: Final step is to add NXP_NCI_I2C as module in following file: . vendor/nxp-opensource/kernel_imx/arch/arm64/configs/imx8mn_gki.fragment Open imx8mn_gki.fragment and add: 7    Add device specific changes          The location of the device specific changes in under folder            . device/nxp/imx8m/evk_8mn 7.1 BoardConfig.mk        7.2 ShareBoardConfig.mk  7.3 compatibility_matrix.xml  7.4 device_framework_matrix.xml  7.5 evk_8mn.mk Add .mk files to specific device.mk and some product package directly to device.mk file so everything is build together with Android.   7.6 init.rc 7.7manifest.xml 7.8 ueventd.nxp.rc        Add permissions for drivers    8    Additional change in compatibility matrix Put changes into hardware/interfaces/compatibility_matrices Compatibility_matrix_8.xml  9    add changes into NXP mk files . android_build/vendor/nxp/nfc/device-nfc.mk  .android_build/vendor/nxp/emvco/device-emvco.mk    10    Build Android First , the source build/envsetup.sh command is executed to import shell functions that are defined in ${MY_ANDROID}/build/envsetup.sh. Then, the lunch evk_8mn-userdebug command is executed to set up the build configuration. #source build/envsetup.sh #lunch evk_8mn-userdebug   Possible build failures This error resulted from the incompatibility of file Kconfig, please use dos2unix command to fix it.  For some other redefine issues, please do the following. Go into file hardware/nxp/nfc/snxx/ Name Android.bp to _Android.bp Go into hardware/nxp/nfc/snxx/halimpl/power-tracker/ Name Android.bp to _Android.bp Go into file hardware/nxp/secure_element/snxxx/aidl/ Name Android.bp to _Android.bp Remove : pn8xx from hardware/nxp/ Remove : frameworks/base/core/res/res/values/config.xml.orig 11   Download build and flash images Go into “android_build/out/target/product/evk_8mn” and download all files without folders . When downloaded, open following two files and add: .in fastboot_imx_flashall.bat   .in uuu_imx_android_flash.bat   Change switches on i.MX8M Nano .    Flashing Android: when flashing Android images .    Running Android:  when images are flashed, put switches to Running Android and Android OS will start. Flash images .  Put i.MX8 to “Flash Android” .  Open a PowerShell as admin in the location where download images are .  Running following command .  ./uuu_imx_android_flash.bat -f imx8mn -a -d pn7160 12  Firmware update Download the FW from Github Open terminal at the FW location Run the following commands • adb push libpn7160_fw.so vendor/lib64/libpn7160_fw.so (for 64-bit version) and adb                  push libpn7160_fw.so vendor/lib/libpn7160_fw.so (for 32-bit version) • adb shell svc nfc disable • adb shell svc nfc enable    References: PN7160/PN7220 – Android 14 porting guide UG10156 : Android User’s Guide  Build Andriod image for PN7160 on i.MX8M Nano:  Andraz this is a step by step guider to port PN7160 to Android 14 on i.MX 8M Nano board NFC Controller Solutions
記事全体を表示
LINが通信のスレーブとして動作する場合の切断の問題 こんにちは。LPUART1をLINスレーブデバイスとして使用すると、一定時間後に通信が途切れてしまいます。この時点では、データの受信と送信は不可能です。受信したフレーム数をカウントするためにカウンターを使用しました。接続が中断されるたびに、カウンターの値は異なっていた。中断するまでに700フレーム以上かかる場合もあれば、3000フレームかかる場合もあった。以下の図は、割り込み発生後のLPUART1のレジスタ値を示しています。レジスタのどこに問題があるのか分析するのを手伝ってください。ご協力ありがとうございました。 Re: The problem of disconnection when LIN acts as a slave for communication こんにちは、 @Aoyng さん。 このトピックに関する以下のスレッドに返信しました。 https://community.nxp.com/t5/S32K/The-S32K314-uses-the-LPUART-to-configure-as-a-LIN-slave/mp/2365972/highlight/false#M58611 https://community.nxp.com/t5/S32K/The-LIN-communication-issue-using-the-FS6500-chip/mp/2366021/highlight/false#M58615 よろしくお願いいたします。 ダニエル Re: The problem of disconnection when LIN acts as a slave for communication LINのボーレートを変更して、その違いを確認してみましたか?
記事全体を表示
imx93evk 板可以支持 GNOME 吗? 亲爱的先生 我下载了 https://www.nxp.com/lgfiles/sdk/lsdk2512/nxp_apps_debian_lsdk2512_imx93evk.deb 然后在 imx93evk 板上安装了 nxp_apps_debian_lsdk2512_imx93evk.deb。安装后,没有 GNOME + GDM3。因此,我使用以下命令安装了它们: apt update apt install gdm3 task-gnome-desktop systemctl enable gdm3 systemctl start gdm3 安装 GNOME + GDM3 后,重启通常会挂起。我的疑问GNOME + GDM3 无法运行 imx93evk。为什么? 看来 LSDK-24.12_DEBIAN-12_LF-6.6.36 没有这个问题。 我在 imx8mpevk 上安装了 nxp_apps_debian_lsdk2512_imx8mpevk.deb,出现了 GNOME + GDM3,一切正常。 谢谢。 Re: Can imx93evk board support GNOME? 在我们较新的软件版本中,我们不再专注于在 imx93 主板上支持 GNOME。主要原因是i.MX93不包含显卡。当纯粹在 CPU 上运行 GNOME 和 GDM 时,系统资源消耗会变得非常高,整体用户体验也会明显下降。但是你使用旧版本在 imx93 主板上使用 gnome。 如果您想继续使用 GNOME 并获得更好的性能,我们建议您评估我们的 i.MX8MP 平台,该平台包含 GPU,可提供更加流畅的 GNOME 体验。 如有任何问题,请告诉我。
記事全体を表示