FreescaleCup技术报告团队Wonderbolts April18.doc <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 乌克兰敖德萨国立理工大学 Wonderbolts 队参加飞思卡尔杯技术报告 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 乌克兰敖德萨国立理工大学 Wonderbolts 队参加飞思卡尔杯技术报告

安全嵌入式处理概述 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

KSDK SPI Master-Slave with FRDM-K64F Hi all Kinetis lovers,   Freescale has launched the Kinetis SDK and I believe this is a great opportunity for us to start our new applications using these drivers. The information contained on this post will show you how to use the SPI drivers based on simple master and slave examples.   The examples attached here were developed for KDS IDE using KSDK. To build and run the example you may need to consider the following: Install KSDK: You need to have  KSDK v1.1.0 installed on your machine. You can find it HERE. Build the KSDK library and import the examples: In the KSDK install folder go to the doc folder and look for the Getting Started with Kinetis SDK (KSDK) document. Follow the instructions of the section 5 Run a demo using Kinetis Design Studio IDE. To know how to build and import projects. If you have further question you may find useful information in this posts: OpenSDAv2 Complete information for the OpenSDA v2. Writing my first KSDK1.2 Application in KDS3.0 - Hello World and Toggle LED with GPIO Interrupt excellent post from colleague Carlos_Musich   I hope you can benefit from this post.   If you have questions please let me know   If this post was useful for you do not hesitate to click the Like button.   Best Regards, Adrian Sanchez Cano Technical Support Engineer   General Re: KSDK SPI Master-Slave with FRDM-K64F hi Cano, I'm also looking to use the DSPI_DRV_SlaveTransferBlocking api for K64F. However, what if I just wanted to transfer data and ignore the resulting recieve data on transfer. Can I set the receiveBuffer to NULL? Regards, Vergil Re: KSDK SPI Master-Slave with FRDM-K64F Hi Everyone, I tried to build this project, but unfortunately gave me make*** file error that I could not solve, I'm not sure what is the problem, can anyone help me with that? Re: KSDK SPI Master-Slave with FRDM-K64F HI Adrian, this sample is very useful. However, I am using SDK3.0+KDSK1.2.0, 'configure_spi_pins' cannot be declared. Is there difference between KDSK1.1.0 and KDSK1.2.0? Which file 'configure_spi_pins' is included? Many thanks! Re: KSDK SPI Master-Slave with FRDM-K64F Thanks David. Is a KSKD RC available today? Half of my drivers are implemented for MQX 4.1.1 and the other half for KSDK 1.1 I must start merging them for a single version this week. Freescale's help is appreciated. Thanks, Marcelo Re: KSDK SPI Master-Slave with FRDM-K64F Will see. Back on Monday to reply. Regards, David Re: KSDK SPI Master-Slave with FRDM-K64F Thanks a lot, David. Any chance I could get a release candidate? My email: [email protected] Thanks, Marcelo Re: KSDK SPI Master-Slave with FRDM-K64F Hi Marcelo, Estimated release date for KDS_3.0.0 and KSDK_1.2.0 is April 37th (i.e. May 7th :smileyblush: ). Regards, David Re: KSDK SPI Master-Slave with FRDM-K64F Hello Adrian, About your comment "the new KSDK 1.2 coming end of April includes those demos, one of them the DMA+SPI.". Is that new KSDK version coming today? Otherwise, when? Some progress in our project is being blocked by the lack of this SPI+DMA feature. Thanks in advance, Marcelo Re: KSDK SPI Master-Slave with FRDM-K64F Hello Adrian How can I manipulate the configuration of the clock phase, for this example? thank you Re: KSDK SPI Master-Slave with FRDM-K64F Hi Paulo, As you can see in the example the transmission API I am using looks like this: dspi_status_t DSPI_DRV_SlaveTransferBlocking (  uint32_t instance,                                                                                      const uint8_t   * sendBuffer,                                                                                      uint8_t  * receiveBuffer,                                                                                      uint32_t transferByteCount,                                                                                      uint32_t timeout ) The parameter receiveBuffer is a pointer, you will use it to point to the Buffer you want to store your incoming data from the slave. Here an example: //Buffer to store the incoming data uint8_t spiSinkBuffer[10];   //Bufer with the data to transfer uint8_t spiSourceBuffer[10] = { 0x00, 0x01 , 0x02, 0x03 , 0x04 , 0x05 , 0x06, 0x07, 0x08, 0x09} dspi_status_t Error = DSPI_DRV_SlaveTransferBlocking(HW_SPI0, &spiSourceBuffer[0], &spiSinkBuffer[0], 10,                                                                                           OSA_WAIT_FOREVER); As you can see here I defined an array called spiSinkBuffer that I am passing as the receiveBuffer parameter and in the parameter trnasferByteCount I am setting the number of bytes to transmit an send Once the returned value stores in Error is kStatus_DSPI_Success we can check the values of the received data, we can do something like this: uint8_t value1 = spiSinkBuffer[0]; uint8_t value2 = spiSinkBuffer[1]; . . . . uint8_t value10 = spiSinkBuffer[9]; The spiSinkBuffer[10] has the received values. I hope this information can help you. Regards, Adrian Re: KSDK SPI Master-Slave with FRDM-K64F Hello Adrian, Great example, I have a doubt about an application with SPI communication, needs to be transmitted in master mode, a byte and receive 4 bytes, so far I have not had many problems, however when I get the bytes so I have access to one of them. How do I access all received bytes. thank you Re: KSDK SPI Master-Slave with FRDM-K64F Hi Marcelo, I do not have such example, but, the new KSDK 1.2 coming end of April includes those demos, one of them the DMA+SPI. I recommend to wait the release and check the new examples. If you have further question please do not hesitate to post them. Regards, Adrian Re: KSDK SPI Master-Slave with FRDM-K64F Hello Adrian, Good sample. Would you have similar sample program but having SPI-Slave using the DMA transfer rather than just IRS? Thanks

DwF RFソリューション - 成都 - 2015-04-09 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> スマートインダストリー 市場におけるRF 4G市場におけるRF小信号 陸上移動無線のRF ATC市場におけるRF(Sバンド、<1GHz、Lバンド、ブロードバンド) 放送業界におけるフリースケール・ソリューション: FM (75W、300W、600W、kW)、SW、DTV 915 Mhzでのマイクロ波加熱 ISMアプリケーション(MRI、レーザー、シンクロトロン)におけるRF RF

KSDK SPI 主从控制器，带 FRDM-K64F <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 各位 Kinetis 爱好者，大家好！   飞思卡尔已经推出了Kinetis SDK ，我相信这对我们来说是一个很好的机会，可以利用这些驱动程序启动我们的新应用程序。这篇文章中包含的信息将向您展示如何根据简单的主从示例使用 SPI 驱动程序。   此处附加的示例是使用 KSDK 为KDS IDE开发的。要构建和运行示例，您可能需要考虑以下几点： 安装KSDK：您需要KSDK v1.1.0安装在您的机器上。您可以在此处找到它。 构建 KSDK 库并导入示例：在 KSDK 安装文件夹中，转到 doc 文件夹并查找 Kinetis SDK (KSDK) 入门文档。按照第5 节使用 Kinetis Design Studio IDE 运行演示的说明进行操作。了解如何构建和导入项目。 如果您还有其他问题，您可以在此帖子中找到有用的信息： OpenSDAv2 OpenSDA v2 的完整信息。 在 KDS3.0 中编写我的第一个 KSDK1.2 应用程序 - Hello World 和使用 GPIO 中断切换 LED，来自同事Carlos_Musich 的精彩帖子   我希望您能从这篇文章中受益。   如果您有任何疑问，请告诉我   如果这篇文章对您有用，请毫不犹豫地点击“赞”按钮。   顺祝商祺！ 阿德里安·桑切斯·卡诺 技术支持工程师   概述 回复：KSDK SPI 主从控制器与 FRDM-K64F <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨，Adrian，这个样本非常有用。但是，我使用的是SDK3.0+KDSK1.2.0，无法声明‘configure_spi_pins’。KDSK1.1.0 和 KDSK1.1.0 有区别吗？和 KDSK1.2.0？包含哪个文件“configure_spi_pins”？ 非常感谢！ 回复：KSDK SPI 主从控制器与 FRDM-K64F <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好，艾德里安 对于这个例子，我该如何操纵时钟相位的配置？ 谢谢 回复：KSDK SPI 主从控制器与 FRDM-K64F <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好，Adrian， 很好的例子， 我对具有 SPI 通信的应用程序有疑问，需要在主模式下传输一个字节并接收 4 个字节，到目前为止我还没有遇到很多问题，但是当我获得字节时，我可以访问其中一个。我如何访问所有接收到的字节。 谢谢 回复：KSDK SPI 主从控制器与 FRDM-K64F <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好，Adrian， 很好的样本。您是否有类似的示例程序，但 SPI-Slave 使用 DMA 传输而不仅仅是 IRS？ 谢谢！

アナログとセンサーの概要 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Memory details with Zephyr If you have any questions or issues related to these resources, please Ask a new question, and the NXP support team can address it there. When learning Zephyr, there are lots of questions about memory.  Where does the linker place code and data?  How does the application configure to use other memories? The default memory sections used by the linker are configured in the devicetree.  Typically the devicetree uses chosen nodes to configure these sections.  Here is an example from the board MIMXRT1060-EVK: chosen { zephyr,flash = &is25wp064; zephyr,sram = &sdram0; }; The names of these chosen nodes can be misleading.  zephyr,flash points to the node the linker uses for all the code (.text) and read-only data sections.  Typically this points to physical flash memory, like on this board it places in external QSPI flash, but it can be in memory that is not flash.  zephyr,sram points to the node the linker uses for all the .data and .bss sections.  This should be in RAM, but is not required to be in SRAM.  This board places in the external SDRAM.  The application can point these nodes to other memories that are best for that app.  Other common memory nodes used are &dtcm , &itcm , or &ocram .  Typically, these chosen nodes are set in the board devicetree file.  But when learning Zephyr and working with devicetree, it is best to confirm the devicetree settings in the generated devicetree files created during the build of the application, see Lab Guide: Devicetree and VS Code Devicetree Viewer. i.MX RT memory Most memory questions come from those using the i.MX RT devices.  These MCUs are high-performance flashless devices with multiple internal and external memory options to maximize performance and flexibility for the application.  Some helpful resources specific to the i.MX RT devices: i.MX RT application notes: AN12437 i.MX RT Series Performance Optimization AN12077 Using the i.MX RT FlexRAM AN13970 RT Series Memory Relocation in Zephyr The bootloader in ROM requires the Flash Configuration Block (FCB) when booting.  And optionally the Device Configuration Data (DCD) or eXternal Memory Configuration Data (XMCD) can be added, typically used to enable SDRAM.  This post has more details about where to find these structures, and how they are included with the board. No SDRAM: the Zephyr support for RT development boards with external SDRAM typically place data in the SDRAM.  And the ROM bootloader will configure the SDRAM interface before the Zephyr app executes using the DCD or XMCD.  This post discusses removing the SDRAM for a custom board. Configuring FlexRAM, resizing ITCM, DTCM, or OCRAM, see AN13970 RT Series Memory Relocation in Zephyr Relocating code to RAM Relocating code to RAM is a common requirement, like to maximize performance, or reduce power consumption.  With Zephyr, applications can relocate all the code, or part of the code to RAM.  Some helpful resources for relocation: AN13970 RT Series Memory Relocation in Zephyr Zephyr Code And Data Relocation APIs Example applications that relocate code: Simple example SDRAM_hello_world.zip that moves the entire app to SDRAM, and uses the ROM bootloader to load the RAM at boot, before the app executes. Zperf sample: this networking sample in Zephyr relocates the networking stack and Ethernet driver code to ITCM to improve performance when built for the MIMXRT1170-EVK.  The rest of code remains in the default external QSPI flash. NXP SmartWatch demo and webinar: relocates most code to internal SRAM to reduce power consumption, but leaves graphical assets in flash. Locating data to RAM With Zephyr, the default placement of all data, variables, and stacks go in the zephyr,sram node.  But some applications want some specific data to be placed elsewhere.  Like placing data in DTCM to maximize performance, placing a DMA buffer in non-cacheable memory, or moving large frame buffers for a display to external RAM.  Some helpful resources for specifying data placement include: The declaration of static variables can include linker section tags to place them in specific sections.  A reference showing this is the dma_mcux_edma.c driver, which place the dma_tcdpool structures in the __dtcm_noinit_section or __nocache sections. Another option for static variables is to use devicetree nodes in the variable declaration to place in a specific section.  One example to reference is NXP's Facial Detection demo.  This demo adds the chosen node zephyr,modelbuf in the devicetree, which points to the memory section node sramx .  To use this method, the memory section node requires the property zephyr,memory-region .  In the source code, the  model_input_buf buffer is declared with the zephyr_modelbuf node.  Then the linker places model_input_buf in the sramx section. The data and bss sections of entire source files or libraries can be relocated to other RAMs, see Zephyr Code And Data Relocation APIs. Zephyr can use a special pinned section to place the interrupt and main stacks in a different RAM section.  The simple example pinned_hello_world.zip pins the interrupt and main stacks in DTCM.   Other memory resources Example resizing memory nodes, leverages all SRAM in NXP LPC5500 Return to Zephyr Knowledge Hub

Zephyr のペリフェラルおよびドライバに関するリソース これらのリソースに関するご質問や問題がございましたら、新しい質問をお寄せください。そちらで NXP サポートチームが対応いたします。 開発者が Zephyr を選択する主な理由の 1 つは、ドライバとペリフェラルのサポートが豊富であることです。ハードウェアプラットフォームでサポートされている最新のドライバと機能を確認する最適な場所は、ボードのドキュメントページです。たとえば、この Supported Features 表には、FRDM‑MCXN947 ボードでサポートされている最新機能が掲載されています。Zephyr サポート対象ボードの各ページへのリンクは次のとおりです。 NXP のハードウェア抽象化レイヤ (HAL) は、MCUXpresso SDK ドライバに基づいています。詳細はブログ Zephyr Software Code Reuse with NXP MCUXpresso SDK をご覧ください。ほとんどのユーザーは移植性を高めるため、アプリケーションで Zephyr ドライバ API を利用したいと考えています。しかし、プラットフォームで Zephyr ドライバがサポートされていない、またはハードウェアペリフェラル用の Zephyr ドライバが存在しない場合は、Zephyr アプリで MCUXpresso SDK ドライバを使用するという選択肢もあります。 ペリフェラル・クロック：NXP は、多彩なペリフェラルオプションと複数インスタンスを備えた各種 SoC に対応する、幅広いボードポートフォリオを提供しています。Zephyr サポートをボードに追加する際、これらのインスタンスの多くは容易にテストできません。長期的には、NXP はクロックを Clock Management Subsystem で有効化および構成できるようにしたいと考えていますが、まだ採用されていません。ほとんどのペリフェラルクロックは SoC またはボードのソースファイルで有効化されています。Zephyr ユーザーがボード上でペリフェラルインスタンスを有効化または追加する際によく直面する問題の 1 つは、当該インスタンスのクロックが正しく設定されていないことです。この問題が判明すれば、ペリフェラルクロックの有効化は通常容易に行えます。新しいボードでは、board.c ファイル内でこれらのクロックを有効化しています。たとえば、frdm_mcxn947_init() は FRDM‑MCXN947 ボードでこれらのクロックを有効化します。一部の旧世代 SoC では、soc.c 内でクロックを有効化しています。たとえば、clock_init() は i.MX RT10xx SoC でこれらのクロックを有効化します。 以下は、特定のペリフェラルおよびドライバに関する参考リソースです。 アクセラレータとコプロセッサ PowerQuad Appnote AN13970 – Cadence Tensilica HiFi 4 DSP 上での Zephyr RTOS 実行 アナログ‑デジタルコンバータ (ADC) 温度測定用 Zephyr サンプル die_temp_polling ディスプレイ ほとんどのディスプレイは、Zephyr ではアドオン ハードウェア モジュールであるシールドとして有効化されています。Zephyr の シールド一覧 を参照してください。 通常、ボードページには、テスト済みのディスプレイ シールドが記載されています。たとえば、FRDM‑MCXN947 ボードページには LCD_PAR_S035 ディスプレイ シールドが含まれています。 シールドページには、そのシールドをビルドに組み込む方法とアプリケーションに追加する方法が記載されています。たとえば、LCD_PAR_S035 シールドページを参照してください。VS Code でビルドする場合は、CMake wiki を参照してください。 Zephyr には、ディスプレイを使用するサンプルとして ディスプレイドライバのサンプル と LVGL デモ などが用意されています。 ダイレクト・メモリ・アクセス（DMA） DMA を使用する際は キャッシュの整合性 に留意し、DMA がアクセスするバッファをキャッシュ可能メモリに配置しないようにしてください。これには、I2S、SPI、UART など、DMA を利用する他のドライバを使う場合も含まれます。キャッシュ不可メモリへのバッファ配置の参考としては、spi_loopback テストがあります。 Inter‑Integrated Circuit Sound（I2S） I2S ドライバは、Zephyr の i2s_speed テストで検証されています。このテストはループバック テストであり、一部のボードでは合格するために信号配線を変更する必要があります。詳細は readme を参照してください。 ネットワーク イーサネットを含む MIMXRT1170-EVK Zephyrネットワークパフォーマンス シリアル・ペリフェラル・インタフェース（SPI） SPI ドライバは Zephyr の spi_loopback テストで検証されています。このテストは、DMA バッファをキャッシュ不可メモリに配置するオプションを確認するうえでも参考になります。詳細は前述の DMA セクションをご覧ください。 Zephyr の SPI ドライバでは、SPI コントローラがハードウェア ペリフェラル、またはドライバ内のソフトウェア（GPIO）でチップ・セレクト信号を駆動できます。詳細については ハードウェア チップセレクトと GPIO の比較 を参照してください。この機能を示す簡単な SPI の例として、LPSPI ハードウェア チップセレクトの例 と LPSPI GPIO チップセレクトの例 があります。 SPI のタイミング パラメータはデバイスツリーで設定できます。詳しくは LPSPI タイミング パラメータの例 をご覧ください。 ユニバーサル・シリアル・バス（USB） USBホスト 2024 年 12 月 5 日現在、Zephyr は USB ホストをサポートしていません。USB メンテナは、この機能追加に向けた作業を RFC トラッカー で管理しています。現時点では実験的なホスト API しか存在しません。USB ホスト スタックはまだ実装されておらず、USB クラスも未サポートです。進捗状況は上記 RFC を追跡することで確認できます。 USB デバイスはすでにサポートされており、Zephyr には複数の サンプル アプリケーション が用意されています。 Zephyr Knowledge Hub に戻る

i.MX Android 12 GKI(General Kernel Image) development tips From Android 12, NXP use GKI(Generl kernel image) instead of NXP's kernel code.  This follow up Android ASOP standard. This article described that when customer use Android 12 and later version, they need to pay attention on GKI development, which is different with previous version. Android i.MX 8M | i.MX 8M Mini | i.MX 8M Nano

HOWTO: GNU ビルドツールを使用して RAM メモリからライブラリ関数を実行する <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このドキュメントでは、GNU ビルドツールを使用してカスタムメモリセクション（通常はRAM）からライブラリ関数を配置して実行するために必要な手順について説明しています。この手順は、どのGNUツールチェーンにも適用できます。S32 Design Studio for ARM で作成した新規S32DSプロジェクトでデモを行います。 標準ライブラリ（NewLib）のmemcpy()関数を実行したいと仮定しましょう。 1) 最初のステップは、特定のライブラリオブジェクトファイルを入力セクションから除外し（EXCLUDE_FILE を使用）、標準の.text*フラッシュセクションにリンクされないようにすることです。 EXCLUDE_FILEに関連付けられた入力セクションは、セクションリストの後半で使用される同じ入力セクションと干渉してはなりません（例：以下のリストから *(.text*) 入力セクションが削除されている場合）。EXCLUDE_FILEは *.(text*) ルールと同様に動作します。選択したファイルのみを除外し、残りの（除外されていない）入力データはすべて配置されます。 /* The program code and other data goes into internal flash */ .text : { . = ALIGN(4); *(.text) /* .text sections (code) */ /* Exclude file(s) from NewLib libc.a from .text.* section */ *(EXCLUDE_FILE (*libc.a:lib_a-memcpy-stub.o) .text*) *(.rodata) /* .rodata sections (constants, strings, etc.) */ *(.rodata*) /* .rodata* sections (constants, strings, etc.) */ *(.glue_7) /* glue arm to thumb code */ *(.glue_7t) /* glue thumb to arm code */ *(.eh_frame) KEEP (*(.init)) KEEP (*(.fini)) . = ALIGN(4); } > m_text‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 2)次に、 memcpyオブジェクトをプロジェクトの.ldファイルですでに定義されているcode_ramセクションに配置しましょう。このセクションは、RAM から実行されるコード専用です（起動ルーチンはこのセクションを初期化します）。詳細については、「HOWTO: S32 Design Studio で RAM からルーチンを実行する方法」をご覧ください。 次の行は、標準のNewLib（libc.a）に含まれるオブジェクトファイル（lib_a-memcpy-stub.o）のコード（.text* セクション）を配置します。 *libc.a:lib_a-memcpy-stub.o (.text*)‍ .code セクションに配置： .code : AT(__CODE_ROM) { . = ALIGN(4); __CODE_RAM = .; __code_start__ = .; /* Create a global symbol at code start. */ __code_ram_start__ = .; *(.code_ram) /* Custom section for storing code in RAM */ *libc.a:lib_a-memcpy-stub.o (.text*) /* add memcpy from the NewLib library here*/ . = ALIGN(4); __code_end__ = .; /* Define a global symbol at code end. */ __code_ram_end__ = .; } > m_data‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ プロジェクトをビルドした後、マップファイルをチェックして、memcpyが実際にRAMメモリの.codeセクションに配置されていることを確認できます。 .code 0x1fff881c 0x18 load address 0x00000d90 0x1fff881c . = ALIGN (0x4) 0x1fff881c __CODE_RAM = . 0x1fff881c __code_start__ = . 0x1fff881c __code_ram_start__ = . *(.code_ram) *libc.a:lib_a-memcpy-stub.o(.text*) .text.memcpy 0x1fff881c 0x16 C:/NXP/S32DS_ARM_v2018.R1/Cross_Tools/gcc-6.3-arm32-eabi/arm-none-eabi/newlib/lib/thumb/v7e-m\libc.a(lib_a-memcpy-stub.o) 0x1fff881c memcpy 0x1fff8834 . = ALIGN (0x4) *fill* 0x1fff8832 0x2 0x1fff8834 __code_end__ = . 0x1fff8834 __code_ram_end__ = . 0x00000da8 __CODE_END = (__CODE_ROM + (__code_end__ - __code_start__)) 0x00000da8 __CUSTOM_ROM = __CODE_END‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 注 関数をRAMに配置する場合は、その関数によって呼び出されるサブ関数（通常は別のオブジェクトファイルにあります）を追加することを常に検討してください。 CC++ ライブラリ コンパイラ・アセンブラ・リンカ

[IN PROGRESS] Audio-video real time audio transfer over Ethernet Real time audio transfer over Ethernet using IEEE1722 protocol – Audio-video bridging Cílem práce je demonstrovat přenos audio a video signálu mezi cílovými body v reálném čase v rámci komunikační počítačové sítě na základu IEEE 802 (ethernet) s využitím TSN (time sensitive networking) standardů IEEE 1588 (precision clock synchronization protocol), IEEE 1722 (layer 2 transport protocol for time sensitive applications in a bridged local area network) a IEEE 1733 (layer 3 transport protocol for audio and video applications). Na dodaném hardware NXP T-BOX S32K3 na bázi mikrokontroleru NXP S32K344 bude vytvořen nový nebo zdokonalen existující software používající výše uvedené standardy. Software bude zvládat plně duplexní provoz, tzn. v reálném čase snímat audio data z analogového vstupu, provede jejich digitalizaci a odeslání na ethernetové rozhraní přičemž zároveň bude možno z ethenetového rozhraní data přijímat, zpracovávát a odesílat na analogový výstup. Bude navržen model výměny dat mezi síťovými uzly v reálném čase, vytvořeny softwarové moduly pro čtení/přehrávání audio signálu z analogového zdroje/výstupu a pro posílání a příjem dat z ethernetového rozhraní. Bude vytvořena modelová aplikace pro plně duplexní provoz mezi síťovými uzly. Leader Martin Gazda Contact University team NXP Semiconductors CZ  Apply by email  Martin Gazda In Progress

FRDM-IMX93硬件介绍 FRDM-IMX93 开发板是第一款配备 i.MX MPU 的 FRDM 开发板，包含 Wi-Fi 和蓝牙模块，并支持 Debian、Yocto 和 GoPoint，可帮助您利用 NXP 的开发人员经验快速开发工业和物联网应用程序。   FRDM-IMX93 应用 低成本开发板使用，每两年发布一次 Debian BSP Yocto 每年发布一次 BSP。   了解FRDM-IMX 93开发板     规格 2个Arm Cortex ® -A55 + Cortex ® -M33 板载 Wi-Fi 6 + 蓝牙 + 802.15.4 模块，IW612 2x GB Ethernet (1xETER, 1xTSN) MIPI-CSI/DSI, HDMI M.2接头 LPDDR4X 16 位 2GB eMMC 5.1, 32GB 微型SD 3.0卡插槽 3 个 USB 2.0 Type-C 连接器（一个用于调试，一个仅用于 PD）+ 1 个 USB 2.0 Type-A RTC、按钮和 LED     特性 FRDM-IMX93 eMMC 32GB DRAM Micron 2GB PMIC PCA9451A WiFi模块 板载 u-blox MAYA-W276 USB Type C Type-C+Type-A 以太网 两个GbE M.2（E 键） SDIO WiFi/蓝牙 Y（需要返工） HDMI IT6263/Y MIPI DSI面板 22针FPC HDR LVDS面板 否 MIPI CSI摄像头 22针FPC HDR 2x20扩展接口 Y CAN总线 Y 微型SD Y UART Y 音频 MQS 远程调试 否 NXP连接器（CAN、ADC、I2C） Y 电源接头 Type-C PCB层数 10 基板尺寸 6.5x10.5cm 板载 NXP 设备 PMIC PCA9451A USB PD TCPC PHY IC PTN5110 高压USB PD电源开关 NX20P5090UK IIC扩展GPIO PCAL6524/PCAL6408A CAN收发器 TJA1051T/3 USB 接收器和源组合电源开关 NX20P3483UK USB Type-C CC和SBU保护IC NX20P0407 实时时钟/日历 PCF2131 Wi-Fi, BT, 802.15.4 Tri-Radio IW612（在 u-blox 模块中）   扩展板   RPI-CAM-MIPI ：IAS 摄像头至 22 针 FPC 摄像头适配器 TM050RDH03-41: LCD display module 5” TFT 800X480, RGB, 120.7 mm x75.8 mm7inch Waveshare 7'' DSI LCD ：7英寸电容式触摸屏，1024×600 MX93AUD-HAT ：具有多种功能的音频扩展板 8MIC-RPI-MX8：用于语音支持的 8 麦克风阵列原型板 培训 FRDM-IMX93 软件发布包 FRDM-IMX93 上的 GoPoint 演示 文档 − FRDM-IMX93 快速入门指南 − FRDM-IMX93 开发板用户手册 - FRDM-IMX93 软件用户指南   有用链接 − i.MX Yocto项目用户指南 −i.MX Linux User’s Guide i.MX Linux 参考手册 − i.MX移植指南 -i.MX Debian Linux SDK 用户指南 FRDM-IMX93 FRDM 培训 动手实践培训 i.MX应用处理器 MCU 无线连接

KW45/MCXW71 Changing Clocking peripherals from FRO6M to other clock sources In modern embedded systems, precise and reliable clocking is fundamental to the correct operation of digital peripherals. Microcontrollers like NXP’s KW45 and MCXW71 rely on internal oscillators to provide timing references for peripherals such as UART, SPI, timers, and ADCs. One such oscillator is the 6 MHz Free Running Oscillator (FRO6M), which is commonly used as a default clock source. This article provides a comprehensive guide to: Selecting and configuring alternative clock sources Choosing an alternative clock source The KW45/MCXW71 microcontroller offers several alternatives, including the Free Running Osilator 192Mhz (FRO192), the RF_OSC , and external crystal oscillators. Each option has its own advantages: FRO192 is stable and available, and external oscillators provide long-term accuracy. The choice of clock source should be based on the peripheral’s timing requirements, power constraints, and the availability of the clock in the current operating mode. Reconfiguring Peripheral Clock Sources Reconfiguring a peripheral’s clock source in KW45 is straightforward using the SDK’s clock management APIs. The function CLOCK_SetIpSrc() allows developers to assign a new clock source to a specific peripheral. Example on changing a UART clocking from FRO6M to other clocksource. UART peripheral connected to FRO6M uint32_t uartClkSrcFreq = BOARD_DEBUG_UART_CLK_FREQ; CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro6M); DbgConsole_Init(BOARD_DEBUG_UART_INSTANCE, BOARD_DEBUG_UART_BAUDRATE, BOARD_DEBUG_UART_TYPE, uartClkSrcFreq); For example, to switch a UART from FRO6M to FRO-192M, the following code can be used: //Replace kCLOCK_Lpuart1 for your peripheral for clicking CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro192M); Also in the example above we would have to set the  uint32_t uartClkSrcFreq  variable to the correct freq value corresponding to the FRO192M as it is being used as clock source, but the same logic applies to any other clock source for the peripheral. Other clocking changes for modules can be done as shown in this examples: //Change clock source for LPIT 0 module from 6M FRO to other clocksources /* Iniital source for the LPIT module */ CLOCK_SetIpSrc(kCLOCK_Lpit0, kCLOCK_IpSrcFro6M); /* Set the new source for the LPIT 0 module */ CLOCK_SetIpSrc(kCLOCK_Lpit0, kCLOCK_IpSrcFro192M); /* Set the corresponding divider for application, need to be decided by developer*/ CLOCK_SetIpSrcDiv(kCLOCK_Lpit0, 15U); /* Set the source for the TPM 0 module */ CLOCK_SetIpSrc(kCLOCK_Tpm0, kCLOCK_IpSrcFro6M); /* Set the source for the TPM 0 module */ CLOCK_SetIpSrc(kCLOCK_Tpm0, kCLOCK_IpSrcFro192M); /* Set the corresponding divider for application, need to be decided by developer*/ CLOCK_SetIpSrcDiv(kCLOCK_Tpm0, 3U); //Change clock source for Luart 1 module from 6M FRO to other clocksources CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro6M); /* Set the source for the Lpuart 1 module */ CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro192M); uartClkSrcFreq = CLOCK_GetIpFreq(kCLOCK_Lpuart1); DbgConsole_Init(BOARD_DEBUG_UART_INSTANCE, BOARD_DEBUG_UART_BAUDRATE, BOARD_DEBUG_UART_TYPE, uartClkSrcFreq); After changing the clock source, it is important to reinitialize the peripheral to ensure that timing parameters such as baud rate, prescaler, or sampling intervals are correctly recalculated. This step ensures that the peripheral operates reliably with the new clock configuration. Those were some examples on changing clock sources for some peripherals, but the same logic can be applied to any other module or peripheral, those examples were taken from SDK 2.16.00 as an example on how a module configured with a clock source can be switched to another.

i.MX95 & i.MX8MP usb no-TypeC customization when use uuu tool i.MX8MP and i.MX95 both support USB3.0. In EVK board, USB download pin is USB3.0 with Type-C.  While in other boards, they may delete CC logic design PTN5110, or use USB2.0 signals instead. This document describes how to modify U-Boot to support a design without PTN5110 when using the uuu tool to download.

MCUXpresso Config Tools Curriculum Documentation MCUXpresso Config Tools | Software Development for NXP Microcontrollers (MCUs) | NXP Semiconductors This training currently covers the following areas: MCUXpresso Config Tools: How-Tos MCUXpresso Config Tools: Zephyr Pins Setup System Manager configuration via Config tools for i.MX MCUXpresso SDK

<video> CHN L8 : S32G2 XRDC CHN L8 - S32G XRDC, by Danny(EN)/Peter(CHN) reference doc - AN13024: S32G2 Extended Resource Domain Controller (XRDC) – Application Note part 1 : XRDC Summary (view in My Videos) part 2 : XRDC MDAC (view in My Videos) part 3 : XRDC MRC and PAC (view in My Videos) part 4 : XRDC error handling (view in My Videos) part 5 : XRDC software enablement (view in My Videos) part 6 : XRDC wrap up questions (view in My Videos)

Q&A: Can i.MX6Solo LDB/LVDS & LCD Ports be active simultaneously Q: Some background; this instrument has one display connected to the LVDS output of the i.MX6Solo and the SVGA monitor is using the IPU port with an external Analog Devices ADV7125 DAC to actually drive the monitor (or projector).  From Tektronix: We got our kernel logo to show up on an external SVGA monitor as well as on the internal LVDS display so we now at least know that the hardware is functional. However, when our application starts running and writing to the fb0 (background) and fb1 (foreground/overlay) frame buffers, the external monitor (fb2 frame buffer) doesn't get updated. We need to know how to get the same data going to the external monitor as goes to the internal LVDS display.  the external monitor is 800x600 and the internal is 800x480 so we'd further like those 480 lines to show up centered in the 600 line monitor. We are also hoping that this can be down without having to write/DMA all of the data twice. The answer given is SR #1122663812 was "If the customer is using Linux, fb2 should also be drawed by their application."  This was considered in adequate and Tek replied: I would like to know if they are saying that the IPU absolutely cannot automatically do what we want and if not, why not?  I would like to have some detailed information to at least convince us that they've looked into this and it really isn't possible. A: In our Linux BSP we don't support such feature. And in android BSP it was already supported. The customer must draw the fb2 by their application, ipu doesn't have the feature that combining the fb0 and overlay fb1, then resize it to fb2 automatically. The customer application can drawing their UI into a memory, then use v4l2 output to draw this buffer to both fb0 and fb2, in this case, resizing will be implemented in V4l2 output driver with IPU hardware. And if the customer needs overlay on fb2, they must combine the two layer into memory with IPU task first, then using V4l2 output to render it to display fb2. For how to use IPU task, the customer can reference to BSP unit test code: imx-test-1.1.0\test\mxc_ipudev_test The summary: for dual display case, the fb0 and fb2 are just two framebuffer memory, they must be filled before rendering to display, on iMX6S/DL, only the fb0 has the hardware overlay (fb1); if the customer wants to show same contents on two displays in Linux, their application must draw the two framebuffers, but we had some hardware method to improve the performace, using GPU or IPU task. In Android, the application will not draw frame buffer directly, it will use Android surface flinger middleware to draw, so this feature was implemnted in surface flinger; but in Linux, there is no such middleware, and application draws the framebuffer directly, so the application should handle it. This document was generated from the following discussion: i.MX6Solo LDB/LVDS & LCD Ports Active Simultaneously

CodeWarrior for Starcore: SC3000 user guide The CodeWarrior Development Studio provides a common interface for developing, debugging, and analyzing your applications. The project-oriented Workbench window provides numerous perspectives containing views, editors, and controls that appear in menus and tool bars. After creating a project, build your application, define a launch configuration, and then wait for data collection and data display.   The StarCore linker is a part of StarCore development tools and generates an executable file for the StarCore family of digital signal processors. In addition, the linker also lets you define a Linker Command File (LCF) that you use to instruct the linker to store different parts of the executable file in different areas of the processor address space. Currently, StarCore development tools support two linker versions: • SC100 • SC3000   The SC3000 linker specifically targets SC3850 family of processors. This user guide explains SC3000 linker. For information on SC100 linker, see StarCore SC100 Linker User Guide. What are you waiting for? Amazing features are right here, and  u p d a t e d!! General

Community Created Add-Ons for the Freescale Cup Recommend accessories or post your own designs.  For the community by the community! Add your contributions in the comments section below.  As I filter through them I will move them up into this main document, so it is easier to browse. TFC Camera Mounts Designed by Wave Number Print these on demand via Shapeways.com Base Board Hinge Two Position Tower Elevator TWR-ELEV-2 — Wavenumber LLC - Link to the Store Freescale Cup Content Re: Community Created Add-Ons for the Freescale Cup thank you Re: Community Created Add-Ons for the Freescale Cup simple: contact [email protected] as written on the board Re: Community Created Add-Ons for the Freescale Cup Hi, Please how can i buy that?

FRDM-IMX91 Connectivity Wi-Fi Basic Hands on In this lab, you will learn how to: Bring up Wi-Fi interfaces. Run basic Wi-Fi scan Configure and bring up Wi-Fi STA mode using WPA_SUPPLICANT. Configure and bring up UDHCP server for dynamic IP assignment for associated client devices. Run UDHCP client to get dynamic IP address. Configure and bring up Wi-Fi AP mode using hostapd. Connect STA to external AP Connect AP to external STA Start ping  Wi-Fi Basic Hands on Demo Guide Video (view in My Videos)   Community Support If you have questions regarding this training, please leave your comments in our Wireless MCU Community! here  FRDM-IMX91 FRDM-Training Hands-On Training i.MX Application Processors Wireless