Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
Troubleshooting: Quick Fix Option in Problems View Quick Fix is a feature of the Java editor in Eclipse which enables a user to resolve problems found in the Java code of their project. This feature is available to be used within S32 Design Studio for some problems. Such problems will be identified with the 'light bulb' icon in the description field, as shown below: For example, such problems sometimes occur when importing a project created in a previous version of S32 Design Studio, are provided from another user, or some files in a project have become corrupted. To resolve issues identified with the 'light bulb' icon, right-click on the problem and from the pop-up menu, select 'Quick Fix'.  The Quick Fix menu will appear, providing the available solutions for the problem. In most cases, there will be just one solution. Click finish to implement the fix. In some cases, more information will be required from the user to complete the fix. Complete the form to provide the additional information, then click OK. Now the problem should be resolved. Eclipse IDE Usage and Settings General Re: Troubleshooting: Quick Fix Option in Problems View Thanks for the sharing! The warning of the type "S32 project version problem" and "The hardware settings required for project" can be fixed by referring to this article.
記事全体を表示
TSN(Time-Sensitive Networking)とイーサネットによる車載ネットワークの構築 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このプレゼンテーションでは、主要なTSN(Time-Sensitive Networking)規格と、それらが自動車の要件とどのように関連しているかについて説明します。関連するIEEE® 802.1 TSN規格の概要と、これらを自動車環境で適用および使用する方法の例を示します。このセッションの終わりまでに、参加者はネットワークのユースケースに基づいて必要な機能を理解し、選択できるようになります。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このプレゼンテーションでは、主要なTSN(Time-Sensitive Networking)規格と、それらが自動車の要件とどのように関連しているかについて説明します。関連するIEEE® 802.1 TSN規格の概要と、これらを自動車環境で適用および使用する方法の例を示します。このセッションの終わりまでに、参加者はネットワークのユースケースに基づいて必要な機能を理解し、選択できるようになります。
記事全体を表示
FTF-MHW-N1923 超小型单芯片 Qi 低功耗无线发射器 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 无需插入充电线即可为智能手机充电,增加了便利性,并可在公共场所进行移动充电。第一代无线充电器由 100 多个组件组成,价格过于昂贵,无法被大众市场采用。NXQ1TXH5 是一款单芯片 Qi 低功耗无线充电发射器,集成了 Qi 无线充电器的所有数字、模拟和电源功能。高集成度使得元件数量非常少,并且易于设计无线充电器。这也将无线充电器的成本降低了 3 倍。NXQ1TXH5 是一个真正的数字即插即用平台,无需外部模拟设计工作。您所需要的只是一块 2 层 PCB,其顶层具有信号和电源布线,底层采用全铜以实现热性能。在输入端连接电源和去耦器,在输出端连接 LC 电路以将电力传输到接收器,您的无线充电器就可以使用了! 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 无需插入充电线即可为智能手机充电,增加了便利性,并可在公共场所进行移动充电。第一代无线充电器由 100 多个组件组成,价格过于昂贵,无法被大众市场采用。NXQ1TXH5 是一款单芯片 Qi 低功耗无线充电发射器,集成了 Qi 无线充电器的所有数字、模拟和电源功能。高集成度使得元件数量非常少,并且易于设计无线充电器。这也将无线充电器的成本降低了 3 倍。NXQ1TXH5 是一个真正的数字即插即用平台,无需外部模拟设计工作。您所需要的只是一块 2 层 PCB,其顶层具有信号和电源布线,底层采用全铜以实现热性能。在输入端连接电源和去耦器,在输出端连接 LC 电路以将电力传输到接收器,您的无线充电器就可以使用了! 观看视频演示 安全移动 | 医疗保健和可穿戴设备
記事全体を表示
AMF-AUT-T2348 - NXP 音频视频桥接 (AVB) 堆栈 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 由于车辆不同端点之间的媒体、通信和 ADAS 流增加,以太网在新 OEM 平台中的应用正在加速。所需的服务质量和同步通常是通过实施音频视频桥接 (AVB) 规范或 AVB 的衍生产品来实现的。NXP 在市场上占据着独特的地位,因为我们有能力为汽车中的 AVB 提供完整的解决方案,包括端点(MPU 和 MCU)、PHY、交换机以及所需的软件堆栈。此外,软件堆栈功能齐全,包括关键但经常被遗忘的组件,例如媒体时钟恢复。了解 AVB 技术的基础知识,以及 NXP 如何帮助您在产品中部署 AVB。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 由于车辆不同端点之间的媒体、通信和 ADAS 流增加,以太网在新 OEM 平台中的应用正在加速。所需的服务质量和同步通常是通过实施音频视频桥接 (AVB) 规范或 AVB 的衍生产品来实现的。NXP 在市场上占据着独特的地位,因为我们有能力为汽车中的 AVB 提供完整的解决方案,包括端点(MPU 和 MCU)、PHY、交换机以及所需的软件堆栈。此外,软件堆栈功能齐全,包括关键但经常被遗忘的组件,例如媒体时钟恢复。了解 AVB 技术的基础知识,以及 NXP 如何帮助您在产品中部署 AVB。
記事全体を表示
AUT-N1888 功率 MOSFET 在汽车应用中增强可靠性,提高效率 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次培训将讨论分立式功率MOSFET在动力总成、安全、底盘和车身控制等汽车应用中的使用,向将参会者介绍恩智浦最佳、最新的硅片和封装技术。 重点介绍采用电机控制燃料、机油和水泵的解决方案。 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次培训将讨论分立式功率MOSFET在动力总成、安全、底盘和车身控制等汽车应用中的使用,向将参会者介绍恩智浦最佳、最新的硅片和封装技术。 重点介绍采用电机控制燃料、机油和水泵的解决方案。 观看视频演示 安全互联汽车和自动化汽车
記事全体を表示
USB ホスト大容量記憶クラス (MSC) の例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NXP SemiconductorsとOnChip Technologiesは提携して、USBホスト機能を備えたLPC1000、LPC2000、およびLPC3000ファミリのマイクロコントローラにUSBHostLiteソフトウェアを提供しています。これらには、LPC17xxシリーズ、LPC23xxシリーズ、LPC24xxシリーズ、LPC29xxシリーズ、LPC31xxシリーズ、およびLPC32xxシリーズのマイクロコントローラのメンバーが含まれます。USBHostLite は、OS レス環境で実行するための最小限のコードで USB 大容量ストレージ クラスのサポートのみを含む、簡素化された USB ホスト スタックです。USBHostLiteは、USBホストポートに接続されたUSBペンドライブ、USBハードディスクドライブなどのUSB大容量ストレージデバイス上のファイルにアクセスするための簡単なソリューションを提供します。 特長 USBHostLite は、次の機能をサポートしています。 オペレーティングシステムなしで動作 小さなメモリフットプリントが含まれています ソースコードはANSI Cで書かれており、IDEから独立しています 制御および一括転送をサポート FAT16ファイルシステムをサポート シンプルなファイルAPIにより、ファイルの読み取りおよび書き込み操作が可能 よく構造化され、理解しやすいソースコード 制限 NXPの無料のUSBHostLiteソフトウェアには、次の制限があります。 USBHostLiteは現在、Embedded ArtistsのLPC2468 OEMボードとKeilのMCB1760ボードにのみ移植され、テストされています。 大容量ストレージ以外のクラスはサポートされていません。 大容量記憶装置インターフェースは、最初の構成に存在する必要があります。 0 より大きい最大論理ユニット番号 (LUN) はサポートされていません。 FAT16 以外のファイルシステムはサポートされていません。 長いファイル名はサポートされていません。 ルートディレクトリ以外のフォルダにあるファイルにはアクセスできません。 アプリケーションで使用するバッファ・サイズは、4 KB を超えてはなりません。 注:このアプリケーションノートでは、USBHostLiteスタック全般と、特にEmbedded Artists LPC2468 OEMボードでのアプリケーションについて説明します。 ソフトウェア LPCソースコード用のUSBHostLiteは、NXPのお客様が無料で使用でき、NXPのLPC2000およびLPC3000ファミリのマイクロコントローラでのみ使用できます。USBHostLiteソフトウェアをダウンロードまたは使用することにより、これらのNXPマイクロコントローラーでのみ使用することに同意したことになります。Hitex LPC2939ボード上の LPC293x デバイスに移植されたUSBHostLiteスタック: LPC293x用のUSBHostLite VBeta 0.01 (2009/07/28) - 添付 Embedded Artists LPC2468 OEM ボード上の LPC2468 デバイスに移植された USBHostLite スタック: LPC23xx/LPC24xx用USBHostLite V1.00 (2010年1月4日) Keil MCB1760評価ボード上の LPC1768 デバイスに移植されたUSBHostLiteスタック: LPC17xx用のUSBHostLite VBeta 0.01 (2009/07/14) - 添付 OnChip Technologies LLCは、フル機能と量産品質の組み込みUSBスタックを必要とするお客様のアプリケーション向けに、USB仕様に完全に準拠し、優れた安定性と構成可能性を提供する組み込みUSBホスト/デバイス/OTGスタックを提供しています。 詳細情報 免責事項 このソフトウェアは、NXP Semiconductorsから現状のまま提供されます。NXP Semiconductorsは、情報提供以外の目的で、ここに含まれるソフトウェアをサポートまたは保証しません。サポートオプションやその他の組み込みUSBホスト/デバイス/OTGスタックなど、さらなる支援についてはOnChip Technologies LLCにお問い合わせください。 さらにサポートが必要な場合 オンチップテクノロジーズLLC LPC3000、LPC2000、およびLPC1000ファミリー向けのその他のプロフェッショナルUSBホストスタックソリューション CMXシステムCMX-USBホスト HCC組み込みUSB(EUSB)HostLiteスタック micrium μC/USBホスト マイクロデジタル smxUSBH Quadros RTXCusb ソフトウェア Thesycon組み込みUSBホストスタック
記事全体を表示
USBウェイクアップを備えた低電力モード <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Kinetisファミリには、豊富な低消費電力モードがあります。お客様は、低電力モードからウェイクアップする別の方法を理解するのに混乱する可能性があります。 1) VLPR では、VLPW: NVIC は割り込みの影響を受け続けるため、割り込みはすべて処理されます。 2)停止、VLPSでは、デバイスは USB ウェイクアップ割り込みによってのみウェイクアップできます。 3)LLSでは、VLLSx:デバイスはどの USB ソースから もウェイクアップ できません。 4) LLWUは ウェイク アップに使用されるため、お客様は利用可能なLLWU ウェイク アップソースのいずれかから ウェイク アップできます。 USBモジュールに関しては 、 USB 再開イベントには2つの異なる割り込みがあります。1つは、 USB ライン の状態の変化によって トリガーされる低電力モードから ウェイクアップ できるようにするための非同期です。もう 1 つは同期しており、K 状態 (フル スピードの場合は D+ = 0、D- = 1) を検出してから 2.5 us 後にのみトリガーされます。アプリケーションは、必要なときにいつでも低電力モードに移行する責任があり、この目的のために 、USB スタックによって報告されたデバイスの状態を確認する必要があります。バス で サスペンド状態が検出されると、SLEEP割り込みがトリガーされ、スタックの状態がサスペンドに変わります。その後、アプリケーションは低電力モードに移行します。この SLEEP 割り込みが発生すると、非同期 ウェイク 割り込みが有効になり、トリガーされると無効になります (これは、モジュールが割り込みをクリアするために必要です)。通常の状態では、同期再開割り込みまたはリセット割り込みが後でトリガーされ、スタックの状態が中断以外に遷移します。その後、アプリケーションは通信が再びアクティブになったことを認識し、再び低電力モードに入るのを回避できます。
記事全体を表示
FlexIOによるLEDパネル制御 [1] <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このプロジェクトの目的は、Kinetis K82マイクロコントローラに搭載されているFlexIOペリフェラルを使用してRGB LEDパネルを制御することです。 FlexIOペリフェラルは、GPIOビットバンギングやPWM + DMAを使用した他の制御方法と比較して、LEDの色と輝度情報を更新する過程で CPUをアンロード するという大きな利点を提供します。私は別の方法を使用します。 パネルは、WS2812BコントローラーとLEDストライプを使用します。また、アプリケーションを開発するためのシミュレーションプラットフォームも用意します。 ハードウェア: 30 x16 LED WS2812Bパネル マルチプレクサボード FRDM-K82の Uctronics QVGAディスプレイ ソフトウェア: IAR Workbench 7.50.1 (英語) SDK 1.3 for the Kinetis K82 FreeRTOS eGUIグラフィックライブラリ LEDパネルが機能している状態でビデオを見ることができます。 ビデオリンク : 4707 パート1:LEDパネルの構築 パート2:FlexIOを使用したLED制御方法 パート3:LEDパネルエミュレーション用ソフトウェア パート4:パネル制御用ソフトウェア モバイル Re:FlexIOによるLEDパネル制御[1] <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 親愛なるグレイ、 ページが更新されましたので、ぜひご覧ください。 Re:FlexIOによるLEDパネル制御[1] <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 親愛なるグレイ、 私たちは、ここで共有できるようにソフトウェアの更新に取り組んできましたが、現時点では、適切なライセンスを追加するまで、ソフトウェア以外のバージョンのみを共有することができます。更新されたソフトウェアが手に入り次第、オンラインにします。 参考までに、ここでも同様のプロジェクトがありますが、FlexIO:Kinetis K20によって駆動されるLEDビデオパネルは使用していません Re:FlexIOによるLEDパネル制御[1] <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは。このプロジェクトに感謝します。さまざまなドキュメントにアクセスできないようです。私は得ています: 不正 この場所またはコンテンツへのアクセスが制限されています
記事全体を表示
Implementing Bluetooth® LE Beacons on the KW40Z Wireless Microcontroller Overview Bluetooth Low Energy offers the ability to broadcast data in format of non-connectable advertising packets while not being in a connection. This GAP Advertisement is widely known as a beacon and is used in today’s IoT applications in different forms. This article will present the current beacon format in our demo application from the KW40Z software package and how to create the most popular beacon formats on the market. The advertising packet format and payload are declared in the gAppAdvertisingData structure from app_config.c. This structure points to an array of AD elements, advScanStruct: static const gapAdStructure_t advScanStruct[] = {   {     .length = NumberOfElements(adData0) + 1,     .adType = gAdFlags_c,     .aData = (void *)adData0   },    {     .length = NumberOfElements(adData1) + 1,     .adType = gAdManufacturerSpecificData_c,     .aData = (void *)adData1   } }; Due to the fact that all beacons use the advertising flags structure and that the advertising PDU is 31 bytes in length (Bluetooth Low Energy v4.1), the maximum payload length is 28 bytes, including length and type for the AD elements. The AD Flags element is declared as it follows: static const uint8_t adData0[1] =  { (gapAdTypeFlags_t)(gLeGeneralDiscoverableMode_c | gBrEdrNotSupported_c) }; The demo application uses a hash function to generate a random UUID for the KW40Z default beacon. This is done in BleApp_Init: void BleApp_Init(void) {     sha1Context_t ctx;         /* Initialize sha buffer with values from SIM_UID */     FLib_MemCopy32Unaligned(&ctx.buffer[0], SIM_UIDL);     FLib_MemCopy32Unaligned(&ctx.buffer[4], SIM_UIDML);     FLib_MemCopy32Unaligned(&ctx.buffer[8], SIM_UIDMH);     FLib_MemCopy32Unaligned(&ctx.buffer[12], 0);          SHA1_Hash(&ctx, ctx.buffer, 16);         /* Updated UUID value from advertising data with the hashed value */     FLib_MemCpy(&gAppAdvertisingData.aAdStructures[1].aData[3], ctx.hash, 16); } When implementing a constant beacon payload, please bear in mind to disable this code section. KW40Z Default Beacon The KW40Z software implements a proprietary beacon with the maximum ADV payload and uses the following Manufacturer Specific Advertising Data structure of 26 bytes. This is the default implementation of the beacon demo example from the KW40Z Connectivity Software package. static uint8_t adData1[26] = {     /* Company Identifier*/     0xFF, 0x01     /* Beacon Identifier */     0xBC,     /* UUID */                  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,                                   /* A */                     0x00, 0x00,     /* B */                     0x00, 0x00,     /* C */                     0x00, 0x00,     /* RSSI at 1m */            0x1E}; iBeacon iBeacon is a protocol designed by Apple. It uses a 20 byte payload that consists of the following identifying information [1] : To advertise an iBeacon packet, the user needs to change the second AD element, adData1, like below: static uint8_t adData1[25] = {                                0x4C, 0x00,                                   0x02, 0x15,         /* UUID */             0xD9, 0xB9, 0xEC, 0x1F, 0x39, 0x25, 0x43, 0xD0, 0x80, 0xA9, 0x1E, 0x39, 0xD4, 0xCE, 0xA9, 0x5C,         /* Major Version */    0x00, 0x01         /* Minor Version */    0x00, 0x0A,                                0xC5}; AltBeacon AltBeacon is an open specification designed for proximity beacon advertisements [2]. It also uses a Manufacturer Specific Advertising Data structure: To advertise an AltBeacon packet, the user needs to change the second AD element, like below: static uint8_t adData1[26] = {     /* MFG ID*/         0xFF, 0x01,     /* Beacon Code */   0xBE, 0xAC,     /* Beacon ID */     0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x02, 0x03, 0x04,     /* Ref RSSI*/       0xC5,     /* MFG RSVD*/       0x00}; Eddystone™ Eddystone™ is an open Bluetooth® Smart beacon format from Google [3]. It offers three data type packets: Eddystone™-UID Eddystone™-URL Eddystone™-TLM Eddystone™ uses two advertising structures: Complete List of 16-bit Service UUIDs structure, which contains the Eddystone Service UUID (0xFEAA). Service Data structure, which also contains the Eddystone™ Service UUID (0xFEAA). Thus, advScanStruct will now have 3 elements: static const gapAdStructure_t advScanStruct[] = {   {     .length = NumberOfElements(adData0) + 1,     .adType = gAdFlags_c,     .aData = (void *)adData0   },    {     .length = NumberOfElements(adData1) + 1,     .adType = gAdComplete16bitServiceList_c,     .aData = (void *)adData1   },   {     .length = NumberOfElements(adData2) + 1,     .adType = gAdServiceData16bit_c,     .aData = (void *)adData2   } }; The complete List of 16-bit Service UUIDs element will look like: static const uint8_t adData1[2] =  { 0xAA, 0xFE }; Eddystone™-UID Eddystone™-UID broadcasts a unique 16-bit Beacon ID to identify a particular device in a group. The Service Data block has the following structure: To implement this, the user needs to add a third AD element, as follows: static uint8_t adData2[22] = {     /* ID */ 0xAA, 0xFE,     /* Frame Type */    0x00,     /* Ranging Data */  0xEE,     /* Namespace */     0x8B, 0x0C, 0xA7, 0x50, 0x09, 0x54, 0x77, 0xCB, 0x3E, 0x77,     /* Instance */      0x00, 0x00, 0x00, 0x00, 0x00, 0x01,     /* RFU */           0x00, 0x00}; Eddystone™-URL Eddystone™-URL broadcasts a compressed URL. The Service Data block has the following structure: In this example, we will implement a beacon which will advertise NXP’s webpage, http://www.nxp.com. To implement this, the user needs to add a third AD element, as follows: static const uint8_t adData2[9] = {     /* ID */ 0xAA, 0xFE,     /* Frame Type */    0x10,     /* TX Power */      0xEE,     /* URL scheme */    0x00,     /* Encode URL */    'n', 'x, 'p', 0x07}; Eddystone™-TLM Eddystone™-TLM broadcasts telemetry data about the beacon device operation. The Service Data block has the following structure: To implement this, the user needs to add a third AD element, as follows: static uint8_t adData2[16] = {     /* ID */ 0xAA, 0xFE,     /* Frame Type */    0x20,     /* TLM Version */   0x00,     /* VBATT */        0x00, 0x00,     /* TEMP */         0x00, 0x00,     /* ADV_CNT */      0x00, 0x00, 0x00, 0x00,     /* SEC_CNT */      0x00, 0x00, 0x00, 0x00}; BLE Software KW41Z31Z21Z Re: Implementing Bluetooth® LE Beacons on the KW40Z Wireless Microcontroller @Alexandru Andreescu Thanks for the article; it was really helpful. I am a student and was trying to convert KW41 to Alt Beacon. It was successful the only thing I would like to mention is "When implementing a constant beacon payload, please bear in mind to disable this code section." this line is really important. Re: Implementing Bluetooth® LE Beacons on the KW40Z Wireless Microcontroller Dear Sir, In the actual application can not only run a mode (ibeacon / EddyStone ...). How to modify the software can achieve two modes (iBeacon and EddyStone) can run at the same time? Thanks, Daniel Tseng Re: Implementing Bluetooth® LE Beacons on the KW40Z Wireless Microcontroller Dear sir, I tried to implement ibeacon feature on KW41z. I used the beacon example in MKW41Z_ConnSw_1.0.2. The default packet is NXP beacon format. I tried to change it to ibeacon packet format like you mentioned below. I used the beacon app "Locate" from App store. But I can't get my KW41 device. Could you help me how I could implement the ibeacon feature on KW41 successfully. Thanks. BR, Sean Wu Weikeng Inc. Re: Implementing Bluetooth® LE Beacons on the KW40Z Wireless Microcontroller This was resolved on Android side. Re: Implementing Bluetooth® LE Beacons on the KW40Z Wireless Microcontroller The eddystone beacon is not being detected by Chrome (v51) or the Physical Web Android app. I commented out BleApp_Init(), and also tried using a https url in addition to the nxp example provided. static const uint8_t adData2[19] = {       /* ID */ 0xAA, 0xFE,      /* Frame Type */    0x10,      /* TX Power */      0xEE,      /* URL scheme */    0x03, /* https:// */      /* Encode URL */    'c','o','m','m','u','n','i','t','y','.','n','x','p', 0x07};  Can confirm that the default "beacon" example in the KW40Z_1.0.1 ConnSw is detected by the Kinetis BLE toolbox. Re: Implementing Bluetooth® LE Beacons on the KW40Z Wireless Microcontroller Thanks alexandruandreescu, Great tutorial. in case of iBeacon, We need to have different major/minor for different KW40 module. In this example, we have to compile every time for different beacons/KW40  by changing the adData1 parameters. Is there anyway to read the iBeacon parameters (uint8_t adData1[25]) from a config file?   In that case, we can use the same binary with different config files for different KW40. Thanks.
記事全体を表示
GCCビルドに初期化されていないデータセクションを追加する方法 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> KDSおよびCodewarrior for MCU GCCビルドでは、リンカはリセット後にRAMを初期化し、メイン機能を入力します。ただし、一部のアプリケーションでは、ユーザーはリンカーがデータセクションを初期化することを望んでいません。典型的なケースは、ブートローダ+アプリケーションの組み合わせプロジェクトで、2つのプログラムが同じRAMメモリを共有する必要がある場合です - ユーザーアプリケーションが共有RAMにデータを書き込んでから、ソフトウェアリセットによってブートローダを呼び出すと、ブートローダは正確なデータを読み取ることができます。共有 RAM のデータは、ブートローダー リンカの初期化によって上書きされません。この記事では、GCCビルドに初期化されていないデータセクションを追加する方法について2つの方法を紹介します。   メソッド1。リンカファイルでNOLOADキーワードを使用します。 NOLOAD : セクションはロード不可としてマークして、プログラムの実行時にメモリにロードされないようにする必要があります。たとえば、以下のセクション.bufframと .bss2は "NOLOAD" としてアドレス指定され、プログラムの実行開始時にロードする必要はありません。 詳しくは、Eclipse上のマイコンの記事 http://mcuoneclipse.com/2014/04/19/gnu-linker-can-you-not-initialize-my-variable/ をご覧ください。   メソッド2。初期化されていない RAM の C コードでポインターを使用します。 この方法では NOLOAD は使用されません。これを利用する手順は次のとおりです。 ステップ1:リンカファイルで初期化されていないRAMを定義しないでください。 ステップ2:Cファイルで、ポイントを使用して初期化されていないアドレスにアクセスします。   詳細については、デモがリストされている添付ドキュメントを参照してください。 全般 Re:GCCビルドに初期化されていないデータセクションを追加する方法 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このドキュメントは、KDSおよびCodewarrior for Kinetis GCCビルド用です。 S32DSのMPC5744Pに関する質問がある場合は、S32DSスペースで質問することをお勧めします https://community.nxp.com/community/s32/s32ds  Re:GCCビルドに初期化されていないデータセクションを追加する方法 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 私はMPC5744PにS32DSを使用しており、キーワードNOLOADを使用してみましたが、正しく動作しないようです。 起動時に特定のRAMメモリを初期化せず、初期化されていないRAMを読み書きすると、ECUの電源がオンになるたびにMCUがIVOR1エラーを生成します。 しかし、起動時にアプリケーションとブートローダが共有する特定のRAMメモリを初期化し、アプリケーションで共有RAMにデータを書き込んでからソフトウェアリセットによってブートローダを呼び出すと、ブートローダは正確なデータを読み取る ことができません 。 何よりも、MPC57xxのS32DSでRAMメモリを読み書きする場合は、起動時にRAMメモリを初期化しないと、ECUの電源投入時にIVOR1エラーが発生します。正しいですか?感謝。
記事全体を表示
テクニカルレポート 裏野Brazil.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ブラジル代表の浦野チームによるフリースケールカップWWファイナルズのテクニカルレポート <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ブラジル代表の浦野チームによるフリースケールカップWWファイナルズのテクニカルレポート Re:テクニカルレポート裏野Brazil.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちはルーカス、私たちはそれらを強制するために最善を尽くしています...確かに、英語が一番です。 Re:テクニカルレポート裏野Brazil.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> テクニカルレポートは英語でなければならないと思いましたか? ルールは明確ですが、尊重されていませんか? それともエラーですか? よろしくお願いいたします
記事全体を表示
Microwave Heating at 915 Mhz Presented by tiefengshi Presented at DwF RF Solutions - Chengdu - 9 April 2015 Presented by Tiefeng Shi Presented at DwF RF Solutions - Chengdu - 9 April 2015 RF
記事全体を表示
下载 .sdcard使用 MFGTool 的 i.MX6sx SabreSDB 图像 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我遵循 Yocto 培训直到任务#4 - 部署和测试......但我被困在这里。 我无法下载 .sdcard图像到我的 SD 卡。我需要先格式化它吗?它是全新的。 由于sudo dd if=core-image-base -imx6solosabresd .sdcard of=/dev/sdb1 bs=1M对我不起作用,我无法从主板上的 SD 卡启动。主板开关设置为从 SD4 卡启动。imx6solosabresd 是用于 solox 的正确 MACHINE 吗?我尝试在 local.conf 文件中设置 MACHINE=imx6sxsabersd,但收到了错误消息(任务 #2)。 这就是我想要尝试 MFGTool 的原因。我已将主板设置为从 SD3 启动,以便它可以进入“下载模式”。当我浏览 MFGTool 时,它显示没有设备连接,尽管出现了符合 HID 的供应商定义的设备。 本文件是根据以下讨论生成的:
記事全体を表示
I2C NCSWの使用例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NCSW(NetCommソフトウェア)は、フリースケールのPowerQUICCおよびQorIQプロセッサ・プラットフォームでの開発を迅速化するためのパッケージです。これには、NCDD(NetComm Device Drivers)およびその他のコンポーネントが含まれています。ここでは、バージョンGA_4.7でサポートされているP3041 I2Cを例にとり、NetCommソフトウェアの構造とデバイスドライバの使用状況を分析します。CW PA 10.3 は、ユースケースコードと互換性を持つために使用されます。
記事全体を表示
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 :--- Dinesh_Guleria_0-1707202447324.png BCTU will be do the parallel conversion for channel mentioned in BCTU list :-- Dinesh_Guleria_3-1707204479195.png   Dinesh_Guleria_1-1707202600904.png "NEW DATA DMA enable mask" :-- controls These bit field in MCR register Dinesh_Guleria_0-1707203759290.png "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. Dinesh_Guleria_3-1707204011310.png Dinesh_Guleria_4-1707204043898.png Dinesh_Guleria_2-1707203974137.png 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. Dinesh_Guleria_1-1707330412160.png Dinesh_Guleria_0-1707330375235.png =========================Using  FIFO-2 ================= Dinesh_Guleria_0-1732514437470.png FIFO-2 Trigger & LIST Index :-- Dinesh_Guleria_1-1732514506589.png Dinesh_Guleria_2-1732514539640.png ADC channel conversion :-- Dinesh_Guleria_3-1732514707504.png
記事全体を表示
启动 LS1046A 当闪存为空或镜像损坏时,如何启动板卡?当根据需求修改 RCW 后,如何从各种启动模式启动板卡?本文档将以全新的 LS1046ARDB 板卡为例介绍相关功能(文档中所有目标板均为 LS1046ARDB)。 内容 通过 CodeWarrior TAP 启动 LS1046A 从 SD 卡启动 从 RCW 源文件编译 PBL 二进制文件 将 PBL 二进制文件编译为固件 将固件编程到目标板(LS1046ARDB) 从QSPI启动 从 RCW 源文件编译固件 将固件编程到目标板(LS1046ARDB) 从eMMC启动 启用板载 eMMC 从 RCW 源文件编译固件 将固件编程到目标板(LS1046ARDB) QorIQ LS1设备
記事全体を表示
[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 8mn.jpg  OM27160| Development Kits for PN7160 Plug’n Play NFC Controller | NXP Semiconductors   7160.jpg 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   danielchen_23-1738394964705.png 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. danielchen_24-1738395033337.png  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. danielchen_1-1732538499804.png .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 .. danielchen_9-1738393932366.png .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 .. danielchen_10-1738393932389.png .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 .. danielchen_11-1738393932410.png .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 .. danielchen_12-1738393932434.png .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 .. danielchen_13-1738393932472.png .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 .. danielchen_14-1738393932494.png .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 ../.. danielchen_15-1738393932522.png .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 .. danielchen_16-1738393932548.png After AOSP adaptation, folder is like below. danielchen_17-1738393932554.png  4   Apply AOSP patches please see AN14430, page10   danielchen_2-1732538683728.png # 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 danielchen_4-1732538759932.png  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 .. danielchen_22-1738394453607.png .5.2Create a folder named pn7160 under android_build/vendor/nxp-opensource/kernel_imx/drivers/nfc danielchen_5-1732538861565.png 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: danielchen_6-1732538987249.png .5.3 Modify makefile Replace Makefile default code with following code,  only add i2c for simplifying. danielchen_7-1732539043196.png  Now we need to add pn7160 Makefile and Kconfig to main Makefile and Kconfig danielchen_8-1732539089136.png Makefile danielchen_9-1732539136098.png Kconfig danielchen_10-1732539167244.png 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: danielchen_11-1732539249939.png 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: danielchen_12-1732539303166.png 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: danielchen_13-1732539339523.png 7    Add device specific changes          The location of the device specific changes in under folder            . device/nxp/imx8m/evk_8mn 7.1 BoardConfig.mk   danielchen_14-1732539411816.png    danielchen_15-1732539466661.png   danielchen_16-1732539510369.png 7.2 ShareBoardConfig.mk danielchen_17-1732539566160.png danielchen_19-1732539662019.png  7.3 compatibility_matrix.xml danielchen_20-1732539715434.png  7.4 device_framework_matrix.xml danielchen_21-1732539759365.png  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.   danielchen_22-1732539833373.png danielchen_23-1732539859881.png 7.6 init.rc danielchen_24-1732539894988.png 7.7manifest.xml danielchen_25-1732539940498.png 7.8 ueventd.nxp.rc        Add permissions for drivers   danielchen_26-1732540013940.png  8    Additional change in compatibility matrix Put changes into hardware/interfaces/compatibility_matrices Compatibility_matrix_8.xml danielchen_27-1732540098909.png  9    add changes into NXP mk files . android_build/vendor/nxp/nfc/device-nfc.mk danielchen_28-1732540184997.png danielchen_29-1732540215144.png  .android_build/vendor/nxp/emvco/device-emvco.mk   danielchen_30-1732540257962.png  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 danielchen_31-1732540449014.png This error resulted from the incompatibility of file Kconfig, please use dos2unix command to fix it. danielchen_32-1732540505205.png  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   danielchen_34-1732540724837.png .in uuu_imx_android_flash.bat   danielchen_35-1732540776703.png Change switches on i.MX8M Nano danielchen_36-1732540836787.png .    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 danielchen_37-1732540883865.png 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    danielchen_38-1732540976369.png 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
記事全体を表示
[Zephyr ®系列] 第 4 部分:Kconfig 和设备树的概述及实际应用(日语博客) Zephyr-series-4-title.png   从现在开始,我们将进入 Zephyr 的高级主题学习。 本次课程将概述 Kconfig 和设备树,然后进行实践编程练习,帮助您有效地使用它们。   如前所述,Zephyr RTOS 的一个关键特性是其软件可扩展性(可重用性),这使得在其他项目或衍生产品中重用一次开发的软件变得容易,从而实现快速开发。   此外,为了支持各种硬件平台,Zephyr 采用了名为“Kconfig”和“Devicetree”的强大配置系统。   这样,您只需更改配置文件,即可将程序移植到不同的微控制器板,而无需使用相同的 C/C++ 语言重写源代码。 本文解释了Kconfig和设备树的基本机制。作为实际应用,我们将修改第三部分中创建的与硬件无关的LED闪烁程序,使其能够在两种不同的微控制器板“ FRDM-MCXA153 ”和“ FRDM-MCXN947 ”上运行。   为了在不同的电路板(微控制器和处理器)上运行同一个应用程序,我们将解释使用 Kconfig 和设备树的实用编程方法。     目录   准备 Kconfig基础知识 设备树基础知识 提高软件重用性的最佳实践 Kconfig 和设备树的实际应用 创建一个简单的程序(动手实践) 1. 程序规范 2. 目录结构 3. 创建 Kconfig 和 prj.conf 文件 4. 创建设备树覆盖层和板级特定设置 5. 与硬件无关的通用代码(main.c)创造 6. 构建并运行 总结 准备   硬件准备   本文将主要使用以下开发板来创建和测试程序。 FRDM-MCXA153 (主要用途) 此外,以下电路板将作为辅助工具,用于验证您所创建的程序的可移植性。 FRDM-MCXN947   SW 准备   本指南假设您已搭建好 Zephyr 开发环境(Zephyr SDK、West 命令等)。如果您尚未搭建,请参阅第二篇关于环境搭建的文章。 【Zephyr ®系列】第二部分:首次构建与测试(日语博客)   我们将使用在 Zephyr 系列第三篇文章中创建的 LED 闪烁程序。如果您尚未创建该程序,我们建议您参考上一篇文章进行创建。 【Zephyr ®系列】第三部分:LED 闪烁和软件复用的第一步(日语博客)   Kconfig基础知识     Kconfig 是 Linux 内核中使用的一种配置系统。在 Zephyr 中,它用于管理是否“启用或禁用”软件功能,或者“设置哪些参数”,例如内核函数、设备驱动程序、子系统和应用程序特定的设置。 以下两个文件对 Kconfig 很重要: “Kconfig”文件定义了可选的配置项(符号)、它们的默认值和依赖关系。 "prj.conf" 文件*:应用程序开发人员在此文件中指定他们想要为 "Kconfig" 中定义的项目设置的值(例如,使用 "y" 启用它们或提供特定的数值)。 使用 Kconfig,您可以排除编译中不必要的代码并优化内存使用。 此外,Kconfig 和 prj.conf 文件都是以文本格式编写的。 如何启用此功能 prj.conf 文件启用整个项目的功能。 例如,ADC、DAC 和 OPAMP 驱动程序在 Kconfig 中定义。使用 Kconfig 中定义的函数时,需要在 prj.conf 文件开头添加“CONFIG_”来声明它们。 Kconfig:ADCの定義Kconfig:ADC定义 prj.conf例prj.conf 示例   设备树基础知识   Devicetree例设备树示例   设备树是一个文本文件,它描述了微控制器支持的硬件(CPU、内存、外设、引脚设置等),以及这些硬件的设置和配置。 然后将这些设置和配置展开成宏。   Zephyr 宏可以读取设备树中描述的信息,而不是直接将硬件地址写入 C 代码(硬编码),从而实现与硬件无关的编程。 节点和属性:硬件的每个元素在层次结构中都表示为一个“节点”,寄存器地址、中断号等则被描述为“属性”。 ".dts" 和 ".dtsi":每个微控制器和电路板的标准硬件配置都在 Zephyr 存储库中的 ".dts"(设备树源)和 ".dtsi"(包含)文件中预定义。 dts:被描述为电路板的设备树。 dtsi:描述 SoC/微控制器的设备树,由设备制造商提供。 ".overlay" 文件:当您想要覆盖特定应用程序的接线(例如,将 LED 连接到特定的 GPIO 引脚)或默认设置时,将创建此文件。   提高软件重用性的最佳实践   为了提高 Zephyr 软件的可重用性,遵循以下设计原则非常重要: 硬件相关部分与硬件无关部分的分离: C 代码(`main.c`)例如,避免直接描述具体的微控制器寄存器操作或引脚编号。 利用设备树别名:应用程序不应直接引用实际的硬件节点(例如 `&red_led` 或 `&gpioa`),而应引用在 `aliases` 节点中定义的抽象名称(例如 `led0`)。这样,只需更改别名指向的内容,即可轻松适配不同的开发板。 准备特定于电路板的设备树(覆盖) :当某些功能存在差异时,例如在衍生产品中,您可以仅对每个电路板上硬件不同的部分进行覆盖(覆盖)。 使用 Kconfig 切换功能:应用程序行为参数和特定功能的开/关状态使用 Kconfig 符号而不是 C 语言“#define”进行控制。   Kconfig 和设备树的实际应用   接下来,我们将通过创建一个简单的程序来学习如何使用 Kconfig 和设备树,以便我们能够在实践中实际使用它们。     创建一个简单的程序(动手实践) 该程序将通过修改我们上次创建的 LED 闪烁程序来创建,并将具有以下规格。   在这里,作为一项实践练习,我们将创建一个可以在“FRDM-MCXA153”和“FRDM-MCXN947”上运行的通用应用程序。 1. 程序规范 源代码:使用“第 3 部分:你的第一个 LED 闪烁程序”中的代码,并进行以下修改。 LED闪烁速度:可以使用Kconfig设置闪烁间隔。 按钮功能(启用/禁用):可通过 Kconfig 设置启用或禁用按钮功能。启用后,按下按钮可在 LED 闪烁和常亮之间切换。 输出板卡名称:启动时,Kconfig 中配置的“设备(板卡)名称”将输出到标准输出(终端)。 2. 目录结构   项目目录结构应如下所示:   将 Kconfig 文件和 boards 文件夹添加到上次创建的 LED 闪烁程序的“my_hello”文件夹中。添加文件的方法不限。 在 Windows 系统中,使用 PowerShell `ni` 命令或文本编辑器创建一个新文件,并将其保存在 `my_hello` 文件夹中。 在 Linux 系统中,可以使用 `touch` 命令创建一个新的空文件。   “boards/”目录下的文件用于处理硬件差异以及每个主板特有的独特设置。     my_hello/ ├── CMakeLists.txt ├── Kconfig <- 新規追加:アプリ独自のKconfig ├── prj.conf <- アプリの共通設定 ├── src/ │ └── main.c <- ハードウェア非依存の共通コード └── boards/ <- 新規作成フォルダ  ├── frdm_mcxa153.overlay <- 新規作成:FRDM-MCXA153用のデバイスツリー設定  ├── frdm_mcxa153.conf <- 新規作成:FRDM-MCXA153用のKconfig設定  ├── frdm_mcxn947_cpu0.overlay <- 新規作成:FRDM-MCXN947用のデバイスツリー設定  └── frdm_mcxn947_cpu0.conf <- 新規作成:FRDM-MCXN947用のKconfig設定   注意:通过在应用程序目录中创建特定文件,Zephyr 的构建系统(West)将自动识别它们并应用设置。 添加 Kconfig:您可以通过在应用程序文件夹中放置“Kconfig”文件来添加自己的配置符号。 板级特定设置(“boards/”目录):通过在应用程序中创建“boards”目录并将“[板级名称].overlay”或“[板级名称].conf”文件放置于其中,overlay和Kconfig覆盖将仅在以该板级为目标进行构建时自动应用。   3. 创建 Kconfig 和 prj.conf 文件 首先,在应用程序根目录中创建您自己的“Kconfig”文件,并定义特定于应用程序的参数。 my_hello/Kconfig   mainmenu "my LED blink" config CUSTOM_BLINK_RATE_MS int "LED blink rate in milliseconds" default 1000 help Set LED blink frequency. #LEDの点滅周期(ミリ秒)を設定します config ENABLE_BUTTON_TOGGLE bool "Enable button to toggle LED state" default y help Enable button to toggle LED state. # ボタン入力によるLEDの点滅/点灯状態>の切り替え機能を有効にします。 config BOARD_NAME_STRING string "Board Name String" default "Unknown Board" help Set board name for printf. # 標準出力に表示するボード名を設定します。 source "Kconfig.zephyr"     其次,作为整个应用程序的通用设置,还有“prj.conf”。这件事将会被写下来。 在 prj.conf 文件中,使用您刚刚创建的 Kconfig 符号按如下方式进行配置: my_hello/prj.conf   # GPIOの有効化 CONFIG_GPIO=y # アプリケーションの共通設定 CONFIG_CUSTOM_BLINK_RATE_MS=500 CONFIG_ENABLE_BUTTON_TOGGLE=y   4. 创建设备树覆盖层和板级特定设置 创建一个名为“boards”的目录,并为每个电路板准备必要的文件。 FRDM-MCXA153主板     我们将电路板上的按钮(`sw2`)映射出来,以便应用程序可以使用标准别名`sw0`访问它。`led0`已经在电路板定义中,因此这里可以省略,但如果需要,也可以显式地覆盖它。   my_hello/boards/frdm_mcxa153.overlay / { aliases { sw0 = &user_button_2; /* FRDM-MCXA153のユーザーボタン */ }; };   my_hello/boards/frdm_mcxa153.conf   CONFIG_BOARD_NAME_STRING="FRDM-MCXA153 Board"   通过在应用程序 (main.c) 中引用此 .conf(特定于板的 Kconfig)中的符号,可以使用 printf 函数将板名称输出到标准输出。 适用于 FRDM-MCXN947 同样,我们在 FRDM-MCXN947 中定义了“sw0”。这可以处理按钮硬件名称的任何差异。   事实上,如果硬件名称(因外围设备或实例而异)在不同电路板之间有所不同,则需要将实际硬件分配给设备树中的别名节点。 my_hello/boards/frdm_mcxn947_cpu0.overlay   / { aliases { sw0 = &user_button_3; /* FRDM-MCXN947のユーザーボタン */ }; };   my_hello/ boards/frdm_mcxn947_cpu0.conf   我将尝试仅在使用 MCXN947 构建时将 LED 闪烁速度设置为 250ms。   CONFIG_BOARD_NAME_STRING="FRDM-MCXN947 Board" CONFIG_CUSTOM_BLINK_RATE_MS=250 FRDM-MCXA153 和 FRDM-MCXN947 的应用程序代码相同,但您可以在此处单独配置 LED 的闪烁行为。 5. 与硬件无关的通用代码(main.c)创造 在“my_hello/src/main.c”中写入以下内容:   LED 控制部分重用了上一篇文章中创建的硬件无关代码(使用“led0”别名),并将 Kconfig 和按钮控制集成到其中。 my_hello/ src/main.c   #include #include #include /* Devicetreeのエイリアスを参照する */ /* どのボードでも、一番目のLEDは通常 "led0" と定義されています */ #define LED0_NODE DT_ALIAS(led0) #define SW0_NODE DT_ALIAS(sw0) /* エイリアスからGPIO仕様(ポート、ピン、フラグ)を取得 */ static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios); /* ボタン機能がKconfigで有効化されている場合のみコンパイルされる部分 */ #ifdef CONFIG_ENABLE_BUTTON_TOGGLE static const struct gpio_dt_spec sw = GPIO_DT_SPEC_GET(SW0_NODE, gpios); static struct gpio_callback button_cb_data; static bool is_blinking = true; void button_pressed(const struct device *dev, struct gpio_callback *cb, uint32_t pins) { is_blinking = !is_blinking; if (!is_blinking) { /* 点滅オフ時はLEDを点灯させた状態にする */ gpio_pin_set_dt(&led, 1); } } #endif //CONFIG_ENABLE_BUTTON_TOGGLE int main(void) { int ret; /* Kconfigで設定されたボード名を出力 */ printf("Starting application on %s\n", CONFIG_BOARD_NAME_STRING); /* デバイスの準備確認 */ if (!gpio_is_ready_dt(&led)) { return -1; } /* ピンの設定 (Devicetreeで定義された初期状態などを考慮して設定) */ ret = gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE); if (ret < 0) { return -1; } #ifdef CONFIG_ENABLE_BUTTON_TOGGLE if (!gpio_is_ready_dt(&sw)) { return -1; } ret = gpio_pin_configure_dt(&sw, GPIO_INPUT); if (ret < 0) { return -1; } ret = gpio_pin_interrupt_configure_dt(&sw, GPIO_INT_EDGE_TO_ACTIVE); if (ret < 0) { return -1; } gpio_init_callback(&button_cb_data, button_pressed, BIT(sw.pin)); gpio_add_callback(sw.port, &button_cb_data); #endif //CONFIG_ENABLE_BUTTON_TOGGLE while (1) { #ifdef CONFIG_ENABLE_BUTTON_TOGGLE if (is_blinking) { ret = gpio_pin_toggle_dt(&led); } #else /* ピンの状態を反転 (ボタン機能が無効な場合は常に点滅) */ ret = gpio_pin_toggle_dt(&led); #endif //CONFIG_ENABLE_BUTTON_TOGGLE /* Kconfigで設定された点滅間隔で待機 */ k_msleep(CONFIG_CUSTOM_BLINK_RATE_MS); } return 0; }     6. 构建并运行 现在,让我们实际测试一下它的功能。请参考上一篇文章,了解如何设置构建环境和启用 west 命令。 首先,按照下面的命令说明导航到已安装的 zephyrproject 存储库目录,并在继续操作之前启用 west。 已确认 FRDM-MCXA153(主)运行正常 使用以下命令构建并将其写入 FRDM-MCXA153。   ## ホームディレクトリからZephyrprojectディレクトリに移動 cd ~/zephyrproject ## west環境を有効化 source .venv/bin/activate ## zephyr v4.3をチェックアウトしていない場合は、前回(第3回 初めてのLチカとソフトウェアの再利用性)を参考にv4.3をチェックアウトしてください。 west build -b frdm_mcxa153 my_hello west flash     执行结果   コンソール出力控制台输出   LED点滅、点灯モード切り替えLED闪烁和常亮模式切换   终端上将显示“正在FRDM-MCXA153板上启动应用程序”的消息。 LED 灯以500 毫秒的间隔闪烁(“prj.conf”)。(设置)。 按下 SW2(“自定义开关”)即可将其打开,再按下即可使其恢复闪烁状态。 已确认FRDM-MCXN947运行正常 我们将使用完全相同的 C 源代码来构建该项目,只更改电路板规格。   # -pオプションを使用し、frdm_mcxa153のビルド情報をクリーンしてビルドします。 west build -p -b frdm_mcxn947//cpu0 my_hello west flash   执行结果   “boards/frdm_mcxn947_cpu0.conf”的内容将自动应用,终端将显示“在FRDM-MCXN947板上启动应用程序”。 LED 灯以250 毫秒的间隔快速闪烁(在“prj.conf”中配置)。 按下 SW3(MCXN947 上映射到“user_button_3”的按钮)同样可以在 LED 点亮和闪烁之间切换。 虽然 FRDM-MCXA153 和 FRDM-MCXN947 使用不同的 GPIO 来控制 LED 和开关按钮,但设备树有效地吸收了这些差异,这表明应用程序和硬件是如何清晰分离的。   总结     在本节课中,我们学习了 Zephyr 中 Kconfig 和设备树的基础知识,并练习了如何利用它们将硬件相关的部分与 C 代码分离。   我相信您已经体验到了一种强大的机制,可以在多个不同的电路板上重用相同的源代码,其中硬件设置被设备树覆盖(“overlay”)吸收,应用程序参数可以灵活地更改,并且可以使用特定于电路板的 Kconfig 文件(“conf”)轻松启用或禁用功能。   ========================== 我们目前无法回复此帖子“评论”部分留下的评论。 由此给您带来的不便,我们深表歉意。如有任何疑问,请参考“NXP 技术问题 - 如何联系我们(日语博客)”。 (如果您已经是恩智浦的分销商或与恩智浦有合作关系,您可以直接咨询您的代表。) Zephyr-series-4-title.png 本文档概述了设备树和 Kconfig,这两项功能旨在增强 Zephyr 的软件重用性。随后,本文档详细介绍了在实践中使用这些功能所需的步骤。 读完 Zephyr 系列的第一册到第四册后,你将能够使用 Zephyr 实时操作系统编写程序。 通用微控制器 MCX 日本博客
記事全体を表示
S32K314 FreeRTOS Standby Transition and Return to Run Mode I am developing a project that combines interrupts and tasks using the S32K314, RDT 7.0.0, and FreeRTOS 7.0.0. The interrupts and tasks are functioning properly. I have implemented code that transitions from Run mode to Standby mode and returns to Run mode after a specified time has elapsed as measured by the RTC. I have confirmed that the system transitions from Run mode to Standby mode, and that a reset occurs afterward, causing the MCU bootloader to run again.  However, an error occurs during the process of distributing the clock to the MCU peripherals after the MCU initialization begins and the PLL locks. Since it works during P.O.R., I believe there is some error in the process that transitions the system to Standby mode. Could you please help me? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Additional Information: This project defines Standby RAM. The RAM is allocated as a 32-kilobyte region starting from the beginning of the BSS. This region stores the necessary data after resuming from Standby. /*--- Transition to Standby Mode ---*/ /* Set the timeout for the RTC timer to wake up WKPU0 */ Gpt_StartTimer(GptConf_GptChannelConfiguration_GptChannelConfiguration_RTC, RTC_BASE_CLOCK_HZ * seconds); /* Suspend all OS tasks */ vTaskSuspendAll(); /* Initialize the clock mode to Standby */ Mcu_InitClock(McuClockSettingConfig_Standby); /* Set the clock mode */ Mcu_SetMode(McuModeSettingConf_Standby); ..... (Reset Occur) /*--- MCU Initialization ---*/ /* Set the Standby RAM area to non-cacheable */ MpuConfigurator_AllocateStandbyRamToNonCacheable(); /* Enable non-cacheable mode */ MpuConfigurator_Enable(); /* Initialize the MCU module */ Mcu_Init(NULL_PTR); /* Initialize clock settings in Run mode */ if (E_OK == Mcu_InitClock(McuClockSettingConfig_Run)) { /* Wait for PLL lock via polling */ while (MCU_PLL_LOCKED != Mcu_GetPllStatus()) { /* Wait until the PLL locks */ } /* Distribute the PLL clock to the system */ Mcu_DistributePllClock();  ← An error occurs here Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi @Teruhiko, Could you find more information about the error? What type of fault exception is it? https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-RTD300/ta-p/1806259 https://community.nxp.com/t5/S32K-Knowledge-Base/How-To-Debug-A-Fault-Exception-On-ARM-Cortex-M-V7M-MCU-S32K3XX/ta-p/1595570 https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447 You could also step through the code to identify the exact location where the exception is triggered. Check the DCM_GPR registers for any error. RM, Table 231. DCM controlled features and availability in product family. It could be because of incorrect SRAM initialization after the reset. There is ERM that monitors that, but the clock of the module is gated of by default. Thank you, BR, Daniel Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi danielmartynek-san, I apologize for the delayed response. Since communication with J-TAG is lost when the system transitions to Standby mode, I have not yet been able to obtain the detailed error information. I am currently writing debugging code. I would like to share what we currently know. I have investigated the reset causes under the following conditions: ・ Automatic reset recovery after an RTC timeout following a transition to Standby mode  → Reset cause: MCU_WAKEUP_REASON ・ Reset recovery when waking up via a WKPU interrupt while in Standby mode after entering Standby  → Reset cause: MCU_WAKEUP_REASON ・ Reset recovery when waking up via a WKPU interrupt after the RTC times out following a transition to Standby mode  → Reset cause: MCU_POWER_ON_RESET I believe the reset factor is correct. I suspect that the differences in the boot sequence for each reset factor are related. Once I have more details about the error, I will respond separately. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko, After the MCU exits Standby mode, it should be possible to attach the debugger. For easier debugging, consider adding an infinite loop at the start of the application so you can connect the debugger and step through the execution from there. volatile int var = 1; while(var){} If MCU_POWER_ON_RESET is observed instead of MCU_WAKEUP_REASON, please check the following registers: DCMROPP1–4. Thank you, BR, Daniel Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko, The clocks looks good. One question: when you run the MCU standalone after a POR (without the debugger), does the application work? The reason I’m asking is that when the application is started via the debugger, the debugger performs part of the system initialization. In standalone operation, the application must handle this initialization itself. After exiting standby, the MCU goes through a reset and the debugger is disconnected, so the behavior is effectively the same as a standalone startup. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi Daniel-san, I apologize for the delayed response. I had some questions regarding our circuit design, so I was investigating how it related to this issue. As a result, I discovered that there was a problem with the port assignments in the circuit. When a reset occurred upon waking from standby, the supply voltage applied to the MCU became unstable. I greatly appreciate all the support you’ve provided so far. Thank you very much. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko, What is the Mcu_InitClock(Standby) configuration? It still should be one of the Clock options e.g. Table 157. Option A - High Performance mode (CORE_CLK @ 160 MHz). What exactly do you mean when you say it behaves erratically or is unstable? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi daniel-san Thank you for your advice. I was able to reattach after resetting. When I step through the code, the MCU peripheral initialization succeeds, but the program behaves erratically when I call “xSemaphoreCreateRecursiveMutex()” during the process of starting the OS task. Furthermore, when stepping through this function, the behavior becomes unstable at the following section of the function `void * pvPortMalloc( size_t xWantedSize )` in `heap_4.c`. 2026-05-21 190438.png It appears that heap allocation is failing. Are there any steps I should take before transitioning to Standby mode? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi Daniel-san, The settings for “Run” and “Standby” modes in this project are shown below. I believe the settings in Table 157 that you provided have been applied to Run mode. I also believe the clock values in Table 160 have been applied to Standby mode. I am setting a clock to these blocks so that the RTC can measure time and the WKPU can trigger a reboot. As I step through the code, the current information is displayed on the IDE console screen. When you execute the aforementioned “heapVALIDATE_BLOCK_POINTER()”, the console screen begins to scroll, and step execution becomes impossible . K314_StandbyMode.png K314_RunMode.png   Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Here’s how to transition to Standby mode. ・In the MCAL MCU module settings, “STANDBY” has already been selected as the Operation Mode for Standby mode. ・In the Clocks tool of Design Studio, I have already created separate Functional Groups for “Run” and “Standby.” 1. In normal operating mode, call the functions in the order “Mcu_InitClock(Run)” and “Mcu_SetMode(Run)” to operate in Run mode. ... 2. To transition to Standby mode, call “Gpt_StartTimer(GptConf_GptChannelConfiguration_GptChannelConfiguration_RTC, RTC_BASE_CLOCK_HZ * seconds)” to start the timer, which will automatically wake the system up in Run mode after a specified time via the RTC. 3. Call “vTaskSuspendAll()” to suspend all running OS tasks. 4. Call “Mcu_InitClock(Standby)” followed by “Mcu_SetMode(Standby)” to transition to Standby mode. The reason for calling vTaskSuspendAll() is based on the information in the link below. https://community.nxp.com/t5/S32K/S32K312-Does-FreeRTOS-need-to-be-shut-down-before-entering/m-p/1756857
記事全体を表示