HMB-N1996 高性能ソリッドステートRF調理の設計上の考慮事項 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 民生用調理器具に制御可能で高効率のエネルギーを供給するソリッドステートRFソリューションを設計するには、設計者はサイズ、コスト、および性能の目標を慎重に検討する必要があります。このセッションでは、調理器具に統合するための制御可能なRFエネルギーを提供するためのスケーラブルなモジュール式プラットフォームに対するNXPのアプローチについて説明します。 ビデオプレゼンテーションを見る <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 民生用調理器具に制御可能で高効率のエネルギーを供給するソリッドステートRFソリューションを設計するには、設計者はサイズ、コスト、および性能の目標を慎重に検討する必要があります。このセッションでは、調理器具に統合するための制御可能なRFエネルギーを提供するためのスケーラブルなモジュール式プラットフォームに対するNXPのアプローチについて説明します。 ビデオプレゼンテーションを見る スマートホーム&ビル

Upload in response to "Sensor Fusion Library for Kinetis MCUs in LPC15xx MCU?" Attached is an LPCExpresso project for LPC1549.  It is compatible with the latest version of the Sensor Fusion Toolbox for Windows (the version targeted at Version 6.00 and 7.00 sensor fusion).  This project is a variant on the Sensor Fusion Version 6.00 library.  Algorithmically this is virtually identical to Version 7.00. Attached is an LPCExpresso project for LPC1549.  It is compatible with the latest version of the Sensor Fusion Toolbox for Windows (the version targeted at Version 6.00 and 7.00 sensor fusion).  This project is a variant on the Sensor Fusion Version 6.00 library.  Algorithmically this is virtually identical to Version 7.00. SensorFusion

Access Management: Beyond Securing the Door - How to Enhance the Experience with MIFARE

SAI 4种模式简介：普通模式、网络模式、I2S模式、AC97模式 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Kinetis的SAI支持4种模式：普通模式，网络模式，I2S模式，AC97模式，文档对这4种模式进行了简单的介绍，并给出了4种模式的波形。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Kinetis的SAI支持4种模式：普通模式，网络模式，I2S模式，AC97模式，文档对这4种模式进行了简单的介绍，并给出了4种模式的波形。

NFC智能家居_信息图.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如今，移动网络运营商让您可以轻松获得自己的智能家居套件。复杂性通常出现在设备的首次设置中，因为设备的运行标准多种多样。NFC 承诺使这一过程变得像点击和连接一样简单。该信息图给出了为智能家居配备 NFC 的 5 个理由，以及对生态系统的好处。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如今，移动网络运营商让您可以轻松获得自己的智能家居套件。复杂性通常出现在设备的首次设置中，因为设备的运行标准多种多样。NFC 承诺使这一过程变得像点击和连接一样简单。该信息图给出了为智能家居配备 NFC 的 5 个理由，以及对生态系统的好处。

Modify L2sw_bin application in SDK1.9 NXP T1040 and T1020 SoC have an 8-port gigabit Ethernet switch integrated on the device. QorIQ SDK includes an L2 Switch user space driver and a small demo application that uses the API provided by the switch driver. The L2Switch demo application is useful to configure switch in T1040. Attached document include steps modify the source code and add command to access switch registers, read or write, in SDK1.9. Before doing this, SDK1.9 needs to be installed and useable.  In the SDK manual, there are description about how to install the SDK, how to prepare host environment and how to setup poky for specific target.

AUT-N1799 ハンズオン・ワークショップ「How to Use Automotive MCU Virtual Models to Accelerate Software Development and Measure Relative Performance」 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NXPは、ソフトウェアとハードウェアの共同開発でユーザーを支援するために、機能的およびパフォーマンスに関連するモデルを提供します。Functional SystemCモデルは、CPUコア、ペリフェラル、割り込みコントローラ、ハードウェアアクセラレータなどのSoC MCUコンポーネントを完全にマッピングすることで、プログラムライフサイクルの早い段階でソフトウェア開発を可能にします。このセッションでは、ADASビジョンプロセッサと、お客様が仮想モデル上でソフトウェアを開発する方法に焦点を当てます。ハンズオンセッションでは、ソフトウェアのコンパイル、オブジェクトイメージファイルの読み込み、仮想モデルでのコードの実行、および相対的なパフォーマンスの測定の基本をお客様に教えます。これは、NXPとSynopsysとのパートナーセッションで、仮想モデルでコードを実行し、パフォーマンスを測定します。これは、NXPとシノプシスとのパートナーセッションです。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NXPは、ソフトウェアとハードウェアの共同開発でユーザーを支援するために、機能的およびパフォーマンスに関連するモデルを提供します。Functional SystemCモデルは、CPUコア、ペリフェラル、割り込みコントローラ、ハードウェアアクセラレータなどのSoC MCUコンポーネントを完全にマッピングすることで、プログラムライフサイクルの早い段階でソフトウェア開発を可能にします。このセッションでは、ADASビジョンプロセッサと、お客様が仮想モデル上でソフトウェアを開発する方法に焦点を当てます。ハンズオンセッションでは、ソフトウェアのコンパイル、オブジェクトイメージファイルの読み込み、仮想モデルでのコードの実行、および相対的なパフォーマンスの測定の基本をお客様に教えます。これは、NXPとSynopsysとのパートナーセッションで、仮想モデルでコードを実行し、パフォーマンスを測定します。これは、NXPとシノプシスとのパートナーセッションです。 セキュアなコネクテッド&自動運転車

APF-DES-T1967 - NXP LPCマイクロコントローラを活用して、常時オンのアプリケーションでエネルギー効率を最大化 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 低電力はシステム・レベルの課題です。残念ながら、この課題を解決する機能は 1 つだけではありません。LPCでは、低電力ブート、インテリジェントクロッキング、超高効率処理、柔軟な低電力モード、自律的な低電力周辺機器など、幅広い製品で低電力機能を提供することに注力します。このセッションでは、これらの各機能に焦点を当て、低電力アプリケーションの設計の課題にどのように対処するか、LPC MCUが低電力市場に提供する差別化要因に焦点を当てます。周辺機器と通信する最も効率的な方法、データ転送を最適化する方法、さまざまな電力モードとクロックゲーティング機能がエネルギーに与える影響。このセッションでは、これらのトピックについて説明し、LPC MCUで利用可能な独自のモードと機能を活用して、IoTアプリケーションやその他の組み込みシステムのエネルギー効率を向上させる方法について説明します。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 低電力はシステム・レベルの課題です。残念ながら、この課題を解決する機能は 1 つだけではありません。LPCでは、低電力ブート、インテリジェントクロッキング、超高効率処理、柔軟な低電力モード、自律的な低電力周辺機器など、幅広い製品で低電力機能を提供することに注力します。このセッションでは、これらの各機能に焦点を当て、低電力アプリケーションの設計の課題にどのように対処するか、LPC MCUが低電力市場に提供する差別化要因に焦点を当てます。周辺機器と通信する最も効率的な方法、データ転送を最適化する方法、さまざまな電力モードとクロックゲーティング機能がエネルギーに与える影響。このセッションでは、これらのトピックについて説明し、LPC MCUで利用可能な独自のモードと機能を活用して、IoTアプリケーションやその他の組み込みシステムのエネルギー効率を向上させる方法について説明します。

SMI-N1824 三相ブラシレスDCモータのシステムソリューションを実現するハンズオンワークショップ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 大型の電界効果トランジスタ(FET)を必要とする強力な三相ブラシレスDC(BLDC)モータを簡単に駆動する方法を学びます。このトレーニングでは、3相プリドライバーICを迅速に使用してBLDCモーターを制御し、保護と診断を行う方法、および関連する電流と電圧の測定を行い、安全で正確な制御を実現する方法について説明します。このコースは、KDS、Processor Expert MCU に依存しないアナログ・ソフトウェア・コンポーネント、およびMCU FRDM-KV10Z、3 相 FET プリドライバ拡張ボード FRDM-GD3000EVB、パワーステージ・アクセサリ・ボード FRDM-PWRSTG1EVB を含む完全な Freedom 開発プラットフォームに基づいています。すべての参加者には、BLDCモータ制御アプリケーションをサポートするためのハードウェア開発キットが無料で提供されます。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 大型の電界効果トランジスタ(FET)を必要とする強力な三相ブラシレスDC(BLDC)モータを簡単に駆動する方法を学びます。このトレーニングでは、3相プリドライバーICを迅速に使用してBLDCモーターを制御し、保護と診断を行う方法、および関連する電流と電圧の測定を行い、安全で正確な制御を実現する方法について説明します。このコースは、KDS、Processor Expert MCU に依存しないアナログ・ソフトウェア・コンポーネント、およびMCU FRDM-KV10Z、3 相 FET プリドライバ拡張ボード FRDM-GD3000EVB、パワーステージ・アクセサリ・ボード FRDM-PWRSTG1EVB を含む完全な Freedom 開発プラットフォームに基づいています。すべての参加者には、BLDCモータ制御アプリケーションをサポートするためのハードウェア開発キットが無料で提供されます。 スマートマシナリー&インダストリアルオートメーション

DES-N1839 在 QorIQ LS 处理器上引入 UEFI 引导加载程序以及如何使用它通过 GRUB2 支持 CentOS 发行版 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 统一的可扩展固件接口(UEFI)提供了一个标准的现代环境 ，用于启动操作系统和运行预启动应用。 它已经广泛应用于服务器、移动和嵌入式市场，支持多种架构(X86，ARM®)，支持启动多种操作系统(如Windows®，Linux，Mac)。 本次课程介绍基于QorIQ LS系列处理器(LS1043A板)的UEFI引导加载程序，以及我们如何从U-Boot引导加载程序迁移到基于LS处理器的UEFI引导加载程序。 本次课程还展示如何通过GRUB2引导加载程序来启动CentOS发行版。 加载CentOS内核和RFS镜像时，我们展示PXE启动(网络启动)方法。 因此，本次课程将重点展示一个标准的链式加载架构。该架构被广泛用于支持嵌入式发行版，如CentOS，Ubuntu，ONIE等。 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 统一的可扩展固件接口(UEFI)提供了一个标准的现代环境 ，用于启动操作系统和运行预启动应用。 它已经广泛应用于服务器、移动和嵌入式市场，支持多种架构(X86，ARM®)，支持启动多种操作系统(如Windows®，Linux，Mac)。 本次课程介绍基于QorIQ LS系列处理器(LS1043A板)的UEFI引导加载程序，以及我们如何从U-Boot引导加载程序迁移到基于LS处理器的UEFI引导加载程序。 本次课程还展示如何通过GRUB2引导加载程序来启动CentOS发行版。 加载CentOS内核和RFS镜像时，我们展示PXE启动(网络启动)方法。 因此，本次课程将重点展示一个标准的链式加载架构。该架构被广泛用于支持嵌入式发行版，如CentOS，Ubuntu，ONIE等。 观看视频演示 设计 | 软件与服务

NET-N1875 安全解决方案 - iNIC、设备、虚拟化安全解决方案 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 了解 QorIQ 处理器和 VortiQa 软件如何为 iNICs 智能 NIC、UTM 设备和虚拟化安全应用提供解决方案。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 了解 QorIQ 处理器和 VortiQa 软件如何为 iNICs 智能 NIC、UTM 设备和虚拟化安全应用提供解决方案。 智能网络

将“Chan's FatFS”移植到 LPC4350 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本内容最初由 Richard Man 贡献于 lpcware.com 该项目演示了使用 SDIO 和内置 SDMMC 支持将常用的开源 FatFS 代码移植到 LPC4350 是多么容易。 在竞争激烈的嵌入式微控制器市场中，硅片供应商可以使其产品与其他产品区分开来的方法之一是在芯片上集成功能更强的外设。因此， 现在已经很少能找到内置 LCD、USB、CAN、以太网的芯片，在某些情况下，甚至还有对 SD/MMC 存储设备的硬件支持。 NXP LPC4350 就是这种情况。它具有两个 ARM Cortex 内核和许多其他功能，还配备 SD/MMC 硬件。如果没有专用的 SD/MMC 支持，固件通常必须使用对时间敏感的位破解代码，这会增加代码的复杂性。 用户内容

uCOS-III port for LPC43XX This is the uCOSIII port for LPC43XX based hitex board with revision A4. The BSP and the applicaton code for the port is attached below. The tools supported to build the package are: a) Keil uVision. It has been tested with V4.53.0.0 There are three attachments on the page containing i)The BSP,application and the CPU port files. ii)OS port for the core. iii) A png file showing the directory structure of the project. Here is a set of instructions to build and test the port: 1) Unzip the uCOSIII_Port.zip attachment and you should have "EvalBoards" and "uC-CPU" folders.Place them in your convinient folder. 2) Download uCOSIII source from http://micrium.com/page/downloads/download_os-III_source_code 3)You should now have a "Source" folder containing uCOSIII sources. Place this folder in The directory structure should look like the one shown in the attached png file. 4)Now, find the project file at 5)Double click "hitex4350_tcpecho_uCOSIII.uvproj" which opens the project. Go ahead and build the project for the required target. 6) Connect the Target "Hitex board" with J-Link. And Power it ON. You can either power it with USB or external supply. The default project is setup to use JLink. 7) You can download the image to the IRAM or flash depending on the target you have built. 😎 Run the image, you should be able to ping and telnet it.( This project uses static IP, so change your IP according to your need in the main.c file before building the image)

智能可穿戴设备NFC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

SWIM和Linux <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 要在 Linux 中使用 SWIM，SWIM 必须能够直接访问 Linux 中的帧缓冲内存。这可以通过访问 /dev/fb 设备并将虚拟内存映射到 SWMO 将使用的设备来完成。下面的基本代码片段展示了如何做到这一点。 #定义 XSIZE 240 #定义 YSIZE 320 int fbdev； Uint16 *fb; /* 假设帧缓冲区是 16 位数据 */ /* 打开帧缓冲设备 */ fbdev =打开(“/dev/fb0”，O_RDWR); /* 获取指向帧缓冲区的 mmap 指针 */ fb = (Uint16 *) mmap(0，XSIZE * YSIZE * sizeof(Uint16)，PROT_WRITE，MAP_SHARED，fbdev，0); 执行此代码后，变量“fb”将指向内存中可用的帧缓冲区，可在 Linux 应用程序中直接写入和读取。 下一步是初始化 SWIM 窗口以适应显示器的大小。 游泳窗口_T win1； /* 创建具有黑色背景且无边框的窗口 */ 如果 (swim_window_open(&win1, XSIZE, YSIZE, fb, 0, 0, XSIZE - 1, YSIZE - 1, 0, 白色, 黑色, 白色) == 0) { fprintf(stderr, "打开聊天窗口时出错\n"); 关闭（fbdev）； 返回-1； } /* 选择要使用的字体 */ swim_set_font(&win1，(FONT_T *)&font_winfreesys14x16 ); /* 设置要使用的画笔颜色 */ swim_set_pen_color（&win1，白色）； 可以轻松地将标题栏添加到窗口。 swim_set_title(&s1, "SWIM 窗口演示", LIGHTGRAY); 窗口中的所有对象都是使用逻辑窗口坐标绘制的。像素/线条和文本的位置彼此独立，因此您可以绘制一些文本，然后画一条线，然后如果您再次绘制文本，它会将下一个文本放置在绘制该线之前上一个文本输出结束的位置。 /* 画一个简单的盒子 */ 游泳_输入_线（＆win1，10，10，50，10）； 游泳_输入_线（＆win1，50，10，50，50）； 游泳_输入_线（＆win1，50，50，10，50）； 游泳_输入_线（＆win1，10，50，10，10）； 对于 Linux，通过关闭帧缓冲设备来完成应用程序。 关闭（fbdev）； SWIM 库和应用说明可在此处找到。

IOH: Getting started with IOH in custom projects (LPCXpresso) Introduction This page gives more detailed information on how to use the IOH libraries in custom projects when using the LPCXpresso IDE. For more general information regarding using IOH libraries in custom project or for detailed instructions for Keil MDK and IAR EWARM, visit IOH: Getting started with IOH in custom projects. Ready-to-use examples can be found at the main I/O Handler page. Note: This guide assumes the IOH I2S library is to be added to a project, hence the 'I2S' references. For other IOH libraries, 'I2S' should be replaced with the library name. 1. Add the IOH library (libioh_*lpcxpresso.a) to the project The first step is to configure the LPCXpresso project to link against the IOH library. Open the project properties. Browse to 'Settings', then 'Libraries'. Add the library name (minus the 'lib' prefix) to the first box ('Libraries (-l)'), the library location to the second box ('Library search path (-L)'). 2. Add the path where the library's header file resides to the project’s include path The next step is to add the file location of the library's header file to the include path of the project. Still in the project properties, browse to 'Settings', then 'Includes'. Add the location to the 'Include paths (-I)' box. 3. #include the IOH header file in the source code of the application The IOH header file must be included in the source code of the project (e.g. main.c) by using the following preprocessor directive: #include "IOH_I2S.h" 4. Configure the linker to place the IOH related sections in the IOH SRAM All IOH parts have an SRAM region reserved for I/O Handler. When starting IOH, usually by calling the library's init() function, I/O Handler expects this memory region to be loaded with the IOH data provided by the IOH library. This means this data must be stored in Flash and copied to the IOH SRAM upon startup. A convenient way to do this, is by using scatter loading. With scatter loading, the linker and c-library are instructed to program certain data sections (IOH data) into Flash, and copy it to the specifed region (IOH SRAM) upon start up. This requires a linker script. When using LPCXpresso, this is taken care of automatically when selecting an IOH-enabled part and using the 'Manage Linker Script' option active 5. Enable the IOH SRAM (SRAM1) before C-library initialization The copying of data from the 'load region' to the 'execution region' when using scatter loading (explained above) is executed by the c-library just before main() gets called. It's important that both regions are enabled when the copying is initiated. After power-on, the IOH SRAM on the LPC11E/U37H is disabled (clock disabled in the SYSAHBCLKCTRL register), so it must be enabled before the scatter loading is initiated. The startup file included in LPCXpresso for IOH-enabled parts automatically enable the SRAM in time. 6. Interact with IOH via the library's API The final step is to interact from the application with IOH. This can be done through the library's API. Each library comes with an application note explaining how to use the library and what data structures and functions are available, and with one or more application examples showing how to use the library. This application note and application example provide an easy way to get started. They can be downloaded from the main I/O Handler page.

Session 13: Memory Services This video presentation is the thirteenth installment of the Essentials of MQX RTOS Application Development training course. In this session, you will be introduced to Memory Services. This training was created by Embedded Access Inc., a Freescale sponsored training provider and proven partner. Session 13 Course Line Lab Outline Different uses for RAM in an Embedded System Where different types of data are stored Creating memory pools Allocating memory from a memory pool Creating partitions Allocating memory from a partition Light Weight Memory Manager vs Full Featured Memory Manager Adding a queue to be used for logging health records Adding a timer and a timer ISR Adding the Health Record structure Processing messages sent to the Health Task to fill in the Health Record entries and store them in the queue Adding a new UI command to print out the Health Records First, watch the video for Session 13: Memory Services​. Then, follow through with the interactive lab assignment below. SESSION 13: LAB ASSIGNMENT INTRODUCTION In this lab we will add the logging of data to memory that is allocated from the system memory pool. We will continue to flesh out our application in this lab and we will focus on the Health Task. The Health Task receives data from various tasks through Message Passing. When a periodic timer expires the Health Task will place the data it has received onto a queue and the UI Task will print out that data. Queue structures have not been covered so far in the course so you may want to review this in the MQX Reference Manual briefly, but it should be quite quick for you to pick this up. A queue is simply a sequential list of data which you can read from and add to. Note that our implementation does not put a cap on the amount of data that could eventually be allocated, so eventually the system will run out of memory and additional health records will not be logged. For a system that you intend to deploy to the field it would obviously be good practice to not exhaust the available memory and an ideal way to do this is with a partition. This lab can be updated on your own to allocate memory from a partition you define instead of allocating memory directly from the system pool. OBJECTIVE The objective of this lab is to use Memory Services to support the logging of health data for our application. We will also cover the use of queues and will implement a timer. Light Weight Timers were covered in session 8. ASSIGNMENT ADDING A QUEUE The first thing we need to do is to add a Queue Structure and the best place to locate this is in main.c where our other global structures are located. Add the following line, and make sure that it is also declared as an extern in main.h.            QUEUE_STRUCT     log_queue; In the Health Task, add the following init function for our log_queue. The '0' parameter indicates that the queue is unbounded and will grow to any size, assuming the system has the memory.            _queue_init(&log_queue, 0 ); ADDING A TIMER In order to set up a timer we'll need a structure to be declared in the Health Task of type LWTIMER_PERIOD_STRUCT and another one of type LWTIMER_STRUCT. In the initialization section of the Health Task create the periodic queue with the _lwtimer_create_periodic_queue() function that has a period of 1 second and no wait time. Note that for this BSP of MQX the define BSP_ALARM_FREQUENCY is set to 200 ticks and each tick is 5 msec, so it represents 1 second. Then add a timer to the queue using the _lwtimer_add_timer_to_queue() function. You do not need an offset and the timer should call a 'health_timer' ISR function that will be defined later. The parameter to pass is the Health Task Queue ID. Note that the 'my_qid' variable isn't valid until after the _msgq_open() function so these new lines should go after the _msgq_open() call. CREATING THE TIMER FUNCTION At the top of HealthTask.c create the 'health_timer' function that will be called when the timer expires. It will receive the Health Task's queue ID as its only parameter, which will have to be converted into a '_queue_id' type. This function will send a message to the Health Task essentially to let it know that it's time to write a log entry of the current values. As was done elsewhere in the application, declare a message of type 'APPLICATION MESSAGE *', set the target queue id, set the message type to be 'LOG_TICK_MESSAGE' and then send the message. That's all that this function needs to do. This new message type needs to be added to the 'APPLICATION_MESSAGE_TYPE_T' data structure in main.h. HEALTH INFORMATION STRUCTURE The Health Task needs a structure to hold all of its health data so in main.h declare a structure as shown below. Since this is going to be copied to a queue, the first element should be of type QUEUE_ELEMENT_STRUCT which MQX uses to manage queue entries. The structure should also have a number to indicate which entry it is in the queue, the temperature, the voltage, and the accelerometer x, y, and z data. typedef struct {    QUEUE_ELEMENT_STRUCT    QE;      uint32_t               NUM;      uint32_t               TEMP;      uint32_t               MV;      uint16_t               X;      uint16_t               Y;      uint16_t               Z; } HEALTH_RECORD; Declare a pointer of type 'HEALTH_RECORD *' at the top of the Health Task. In the Initialization section of the Health Task (ie before the while(1) loop) uses the _mem_alloc_system_zero() function to allocate memory for an instance of "HEALTH_RECORD" from the system pool that is set to zero. For now you don't need to check if this was successful or not, we'll do that later. Declare a 32 bit variable that will be used to count the number of health records, and after the first one has been created (in step 9 above), set this variable to 1. UPDATE THE PROCESSING OF MESSAGES In the while(1) loop of the Health Task it checks if an incoming message is from the Temp Task, and if there is an over temperature condition a message is sent to the Display Task. The Health Task now needs to be processing several types of messages so it would make sense that a switch statement on the received message type is used. Add a case to the switch to handle messages of type TEMP_MESSAGE that will contain the same functionality that is already in the while(1) loop for messages of type TEMP_MESSAGE. And add another case for messages of type LOG_TICK_MESSAGE which for now won't do anything, we'll fix that later. When a TEMP_MESSAGE is received we need to store the passed in temperature, so in the case that handles TEMP_MESSAGEs update the "TEMP" parameter of the health record to be the passed in temperature in this message. Here is where it would be a good idea to first check if our health record != NULL. Add in a case for ACCEL_MESSAGEs which will record the passed in x, y, and z axis motion values into the health record, assuming it's valid. Add in a case for ADC_MESSAGEs which will record the passed in voltage into the health record, assuming it's valid. We are now ready to add the handling of a LOG_TICK_MESSAGE. Since the health record has been updated when the other messages were processed we only need to save the record number (count) into the health record, increment the record number for next time, and then add this health record to the queue using the _queue_enqueue() function like this: _queue_enqueue(&log_queue, &health_record->QE) The Health Task is done with the health record since it just put it on the queue so the 'health_record' pointer should be set to NULL so the rest of your code doesn't try to use it. A valid health_record pointer is required for the next record of course and it is required now so its fields can be filled in as new messages arrive. Use the _mem_alloc_system_zero() function as was done before to allocate memory for another record. Currently, at the end of the while(1) loop all received messages are being passed on to the Display Task. However, we don't want to pass on messages of type LOG_TICK_MESSAGE so the code needs to be updated such that it only passes on the other types of messages. This could be done with a test for msg->MESSAGE_TYPE != LOG_TICK_MESSAGE condition, but to be more generic and accommodating of future message types that shouldn't be passed on to the Display Task it might be better for the handling of the LOG_TICK_MESSAGEs to free the message using the _msg_free() function and to set the 'msg' pointer to NULL. Then at the end of the while loop check that only non-NULL messages are sent to the Display Task. UPDATING THE UI TASK It is intended that the health records can be printed out using the UI Task. This is a menu driven interface and so we need to add a new command to read the log file. In UiTask.c add a case for the user pressing the letter 'l' (lower case L) for the log file and get the health record from the queue using the queue_dequeue() function. It can be a good idea to us a small function for items like this since there can be multiple places in your code that need to do a similar task. Such a function could look like this: HEALTH_RECORD  *      get_log_record(void) {       return (HEALTH_RECORD * )   _queue_dequeue(&log_queue); } Add print statements for the record number and all other data that is in the health record. Free up the memory of the health record once you're done with it to avoid a memory leak. This will cover the printing of the first record but the intention is for this UI command to print out all health records that are stored on the queue. Use a while loop to fetch records from the log using our new get_log_record() function until this function returns a NULL entry indicating that there are no more records to fetch from the queue. Note that the function returns a pointer to a HEALTH_RECORD, so a variable in the UI_TASK of this type will have to be declared. Compile and run your code. Use the user interface to request the health logs to be printed out and confirm that the data is correct. You can adjust the potentiometer and move the tower board to change the data. You may also want to comment out the print messages from the Health Task and Display Task so these messages don't interfere. Need more help? The full source code for this lab can be found in the 'Lab Source Code' folder here​.

Session 4: Synchronization and Message Passing This video presentation is the fourth installment of the Essentials of MQX RTOS Application Development training course. In this session, you will learn about synchronization techniques for managing data, task flow, and resources. You will be introduced to the various synchronization options available with MQX RTOS including events, semaphores, mutexes, and message passing. This training was created by Embedded Access Inc., a Freescale sponsored training provider and proven partner. Session 4 Course Line Lab Outline Synchronization Explanation Data Flow Control Flow Mutual Exclusion Synchronization Options Events Semaphores Mutexes Message Passing Message Passing Types of Message Pools Message Pool Creation Sending and Receiving Light-weight Message Passing Creating the message types Creating a message structure Adding message queues and a pool of buffers Sending messages Reading and displaying messages First, watch the video for Session 4: Synchronization and Message Passing​. Then, follow through with the interactive lab assignment below. SESSION 4: LAB ASSIGNMENT INTRODUCTION In this lab we will implement our first type of synchronization - Message Passing. We will also see the data flow of our application begin to take shape as 3 of our tasks (Accel, Temp, and Input Tasks) will be using Message Passing in order to send data to the Health Task. OBJECTIVE The objective of this lab is to understand message passing and implement the message passing as outlined in (diagram of message passing between tasks).This objective will be accomplished by: Adding code to Health Task to send a message to Display task with health status Setting up Message Passing from Temp Task to Health Task Setting up Message Passing from Accel Task to Health Task and Theft Task Setting up Message Passing from Health Task to Display Task Setting up Message Passing from Input Task to Health Task Setting up bi-directional Message Passing between Health Task and CAN Task Ensuring that when each task starts, it sends a "Message from Task x" message to the tasks it talks to. When the Health task receives a message from a task, it should forward it to the Display task who will print it. New functions/ structures you will use:       _msgq_get_id, _msg_alloc_system, _msgq_send, _msgq_open, _msgq_receive, _msg_free, MESSAGE_HEADER_STRUCT ASSIGNMENT HOUSEKEEPING Since we will be using message passing you need to include message.h in main.h. Message Passing does not stipulate a structure for the messages and as far as it's concerned it's just sending a packet of bytes, so you need to define a structure for your messages. In our message structure the receiver will need to know who the message was sent from so we should have an entry for the 'message type'. An example of a message type is a report of the current temperature or a report of the current accelerometer data. The message type could simply be a 32 bit entry with a unique number used for each message type and each type is defined using #define statements. However it's a bit less error prone to use an enum structure to ensure that each message type gets a unique number. You'll see this technique used throughout the labs. Create a define for the following message types: TEMP_MESSAGE, ACCEL_MESSAGE, INPUT_MESSAGE, CAN_MESSAGE, TIMER_MESSAGE, ISR_MESSAGE, HEALTH_MESSAGE, UI_MESSAGE, DISPLAY_MESSAGE. Using an enum. Create an instance of this enum called 'APPLICATION_MESSAGE_TYPE_T' Message structures always start with a MESSAGE HEADER STRUCT and typically you follow that by the message type. The last thing we need in our message structure is a data field and for now we'll just use a single 32 bit entry for our data. Create a structure to define the format of our messages and create an instance of this structure called APPLICATION_MESSAGE. Each task that will receive a message will need a queue and each message queue needs a unique ID. Create the queue ID numbers for the Temp, Accel, Input, CAN, Health, and UI tasks (ie use defines INPUT_QUEUE, CAN_QUEUE, DISPLAY_QUEUE, and THEFT_QUEUE). Again an enum should be used Somewhere in your system you need to create the system pool of message buffers and this needs to be done before anyone tries to use one of the buffers. So it makes sense that this goes in the initialization code of the highest priority task. Use the msgpool_create_system() function to do this. Use a message size of "sizeof (*msg)" where msg is a pointer to the message structure APPLICATION_MESSAGE. A size of 10 buffers should be adequate and there should be no reason for the size of the pool to grow. INITIATING MESSAGES (ACCEL TASK, TEMP TASK, INPUT TASK) Each task that sends a message to Health Task will need to get the ID of the queue for the Health Task so it can send messages to it. This can be done using the msgq_get_id() function. The body of theses sending tasks then will be to do the following: Wait for a time delay to space out it's messages allocate a message using msg_alloc_system(), populate the target queue ID of the receiver (ie the Health Task), populate the message type (eg ACCEL_MESSAGE), set the message data (can be set to 0 for now since we don't have any real data to send. This will be updated later. Send the message using msgq_send() Repeats the above process The time delay each task waits between sending a message will vary based on the desired frequency for each type of information. The accelerometer data is important to get on a fairly frequent basis so perhaps a time delay of 500ms would be best here. The temperature won't change very quickly so a delay of 5,000ms would work best here and the voltage reading being done by the Input Task can be set to 2,000ms. PROCESSING MESSAGE (HEALTH TASK) Since the Health Task will be receiving messages it needs to open the message queue which can be done with msgq_open () function. And since it will be sending messages to the Display Task it will need to know the queue id of the Display Task's queue which it can get with the msgq_get_id() function. The body of the Health Task then uses msgq_receive() to fetch a message from it's queue (which is a blocking function), prints out a message to say that it received a message with the message number, passes the message on to the Display Task using msgq_send(), and then waits for the next message to come in. DISPLAYING THE MESSAGES (DISPLAY TASK) As was done with the Health Task, the Display Task will need to open its message queue before it can read messages and this is done with the msgq_open() function. The body of the Display Task will block on msgq_receive(), once a message is received it will print a message to say that it received a message with the message number, frees up the message so it can be returned to the system pool using msg_free(), and then waits for the next message. VERIFY RESULTS Compile and run your application. We should be receiving all 3 types of messages at both the Health Task and the UI Task, but now each at the same frequency because we used different time delays. However, you will only be getting a small number of messages at the Health Task and then the printouts will stop. Why do you think this is? Pause the application and look at the MQX Task Summary window in TAD for a clue. 14. Fix the problem and re-run your application. Verify that both the Health Task and Display Task print out the messages of all 3 message types (Accel, Temp, and Input). Need more help? The full source code for this lab can be found in the 'Lab Source Code' folder here​.

AMF-DES-T1740 - i.MX 8 と Vulkan API - 高性能グラフィックス実装の未来 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Khronos の新しい Vulkan API について詳しく説明します。OpenGL ES からプログラミング パラダイムがどのように変化したか、Vulkan API の使用方法とその大きなパフォーマンスの利点、i.MX 8 シリーズ GPU の可能性を最大限に引き出す方法を学びます。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Khronos の新しい Vulkan API について詳しく説明します。OpenGL ES からプログラミング パラダイムがどのように変化したか、Vulkan API の使用方法とその大きなパフォーマンスの利点、i.MX 8 シリーズ GPU の可能性を最大限に引き出す方法を学びます。

New Kinetis Expert Pins Tool V1.0 Available! The new NXP Pins tool which has been showcased at FTF 2016 in Austin is now available as Web and Desktop application. The Kinetis Expert Pins Tool makes configuring, muxing and routing of pins very easy and fast. It provides real-time feedback of conflicts and provides an intuitive graphical interface with several views. The tool generates Kinetis SDK V2.0 compatible sources files which can be directly integrated into C/C++ applications. The Pins tool is available both as Web application (no installation needed) and as a Desktop application for Linux, Mac and Windows.     You can use the Web version from Welcome to Kinetis Expert | Kinetis Expert.   It is available for download as Desktop version from Software Development Kit for Kinetis MCUs|NXP (Windows, Mac OS X and Linux 64bit) under the 'Software' category: There are two different installer types: 'offline' is a 130 MByte download. This method is recommended for slower internet connections or for installation on multiple machines. 'online' is a small 500 KByte download, all the other installation data will be loaded from the internet during installation. Mac OS X and Linux installers are 64bit. For Windows there are both 32bit and 64bit installers available.   Documenation is availble on Software Development Kit for Kinetis MCUs|NXP in the documenation download section, as well attached to this article (Getting Started is available in Chinese): An overview and tutorial can be found here: https://mcuoneclipse.com/2016/06/08/tutorial-muxing-with-the-new-nxp-pins-tool/   We hope you find this tool useful! General Re: New Kinetis Expert Pins Tool V1.0 Available! Hi Kevin, Be aware that there is the V2 of the tools available now, see Kinetis Expert System Configuration Tools V2 with Clocks Tool now available!  I quickly checked the downloads (I'm using FireFox), and that worked fine for me. Software Development Kit for Kinetis MCUs|NXP  Can you try again? I have seen reports that using Internet Explorer or Edge can cause issues or even corrupt the downloaded files. I hope this helps, Erich Re: New Kinetis Expert Pins Tool V1.0 Available! When I click to download I get a pop-up with the screen showing the ten items I could download but clicking on them has no effect. I double checked and I am logged in yet with the latest version of Google I can't download! I tried Microsofts Edge with the same results but it failed when I tried to edit this post... bad edge.. Re: New Kinetis Expert Pins Tool V1.0 Available! That's great to hear! Being able to use the names in the sources will also be a welcome addition. This tool is proving to be very valuable. Re: New Kinetis Expert Pins Tool V1.0 Available! Hi Larry, thanks for the suggestion. And yes, this is indeed something which is already considered and will be added to the next update/version: the ability to add custom label/names to each pin plus the ability to provide names which then can be used in the sources. The update is forseen to come out in the near future. Re: New Kinetis Expert Pins Tool V1.0 Available! Another nice-to-have would be to be able to override the pin names. For example, on a K64 I'm going to be using the FlexBus in a non-multiplexed 16bit address and data. It would be nice to be able to label them FB_ADDR0-15 and FB_DATA0-15, rather than the default of FB_AD0-31. Similarly being able to label gpio pins for their intended use would be helpful. When you are starting from scratch and trying to figure out what functions you are going to assign to which pin, meaningful (to the user) labeling simplifies the process. Re: New Kinetis Expert Pins Tool V1.0 Available! Hey Erich, Glad to help. Right now Kinetis development has so many moving parts. I figured when I see something, blurt it out, and the tool developers may have a chance to include it in their next pass. Thanks again,   Steve Re: New Kinetis Expert Pins Tool V1.0 Available! Hi Steve, many thanks for providing that feedback. I can reproduce what you report, and have reported this to the engineering team so hopefully they can address it soon. Thanks again, Erich Re: New Kinetis Expert Pins Tool V1.0 Available! Erich, A couple more observations on the pin tool. 1) In Windows 7, or KDS, double clicking on an *.mex opens "Pin Tool v1.0".     The problem is, it opens the last file used in the tool, not with the file selected. 2) In my project, I defined multiple function tabs: pmUart, pmSpi0, etc.     After I saved it, I decided to re-order the tabs, which worked great visually.     The problem was I couldn't save the order changes. The "save" was not available.     Even "save as" didn't save the changes.     Until I altered a pin attribute. Then I could save the tab changes. Thanks again, Steve Re: New Kinetis Expert Pins Tool V1.0 Available! Great! I saw your article, and then response here. I Just tried it, and now the whole register is being updated as desired. I was hoping there was a "trick". The tool seems fairly nice. I'll play with the clocking next. Thanks, Steve Re: New Kinetis Expert Pins Tool V1.0 Available! Hi Steve, this is controlled if the item is in italic font or not. See https://mcuoneclipse.com/2016/07/19/nxp-pins-tool-clock-gates-and-controlling-the-bits/ I hope this helps, Erich Re: New Kinetis Expert Pins Tool V1.0 Available! Erich, While using the pin tool (offline) I realized that the code generated only sets register values that are different from the expected hard reset values. Based on the options being set, sometimes it generated the "short" version:   PORT_SetPinMux(PORTA, PIN4_IDX, kPORT_MuxAsGpio);      /* PORTA4 (pin 38) is configured as PTA4 */   PORTA->PCR[4] = ((PORTA->PCR[4] & (~(PORT_PCR_PFE_MASK | PORT_PCR_ISF_MASK)))          /* Mask bits to zero which are setting */   | PORT_PCR_PFE(PCR_PFE_ENABLED)                    /* Passive Filter Enable: Passive input filter is enabled on the corresponding pin, if the pin is configured as a digital input. Refer to the device data sheet for filter characteristics. */ ); Sometime the "long":    const port_pin_config_t portb22_pin68_config = { kPORT_PullUp,                                        /* Internal pull-up resistor is enabled */ kPORT_SlowSlewRate,                                  /* Slow slew rate is configured */ kPORT_PassiveFilterDisable,                          /* Passive filter is disabled */ kPORT_OpenDrainEnable,                               /* Open drain is enabled */ kPORT_LowDriveStrength,                              /* Low drive strength is configured */ kPORT_MuxAsGpio,                                     /* Pin is configured as PTB22 */ kPORT_UnlockRegister                                 /* Pin Control Register fields [15:0] are not locked */    };    PORT_SetPinConfig(PORTB, 22, &portb22_pin68_config); /* PORTB22 (pin 68) is configured as PTB22 */ For production systems, this is risky. A reset might not be coming from a POR restart, but a fault. You would want to set the hardware to a definitive state, not assuming anything. Is there an option that causes the tool to generate code the initialized all the whole register? If not, I'll have to code the long method. Thanks again for all your work,   Steve