JustInTime_Milestone_1_2_3_4 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 4つのマイルストーンに対して1つのビデオを送信しています。ここでは、サーバーアプリをPython(UDOOボード上)で実装し、クライアントアプリをAndroidに実装しました。私たちは、この4つのマイルストーンで必要なことをすべて行うことができます。サーバー上のオプションのリストを作成し、そこからレシートとポンペを追加、削除、表示できるようにしました。レシートとポンペはjsonファイルに保存されます。クライアントアプリから、レシートのリストを取得し、飲み物を注文できます。 (マイビデオで視聴) Linux Embedded Challenge 2017 (英語)

MCUXpresso IDE and Semihosting Semihosting printf with MCUXpresso IDE When importing MCUXpresso SDK projects into MCUXpresso IDE, they will be configured by default to use “semihosting” for the terminal output. This means the project will use the debugger connection to send terminal characters instead of the UART. More information on semihosting can be found on this Community document and in Section 11.4 of the MCUXpresso User Guide.   Note that the information in this post is only applicable when using the MCUXpresso IDE, as the projects for other IDEs will use the UART by default when opening up their respective MCUXpresso SDK projects. Also semihosting only works when there is an active debug connection to the device.    printf with semihosting:   printf with UART Terminal (with TeraTerm): How to choose UART output during the project import In order to use the UART for MCUXpresso IDE projects, some configuration settings need to be modified when importing in the project. First, you will need to uncheck the “Enable semihosting” option to clear the box. This will tell the project to use the normal libraries and not the semihosting libraries.   Then on the next screen, you’ll want to uncheck the “Redirect SDK “PRINTF” to C library “printf”” box to clear it. This will tell the project to use the MCUXpresso SDK source files for printf instead of the generic C files. This allows you to debug, and modify if desired, the printf functionality found inside the MCUXpresso SDK. Section 5.1.2 of the MCUXpresso IDE User Guide describes the options on this screen in more detail.   Switching between semihosting and UART If you’re already imported the project and wish to switch between using semihosting or the UART, you can do this from the “Quick Settings” menu inside the Quickstart panel.    If moving from semi-hosting to UART, this will change the library used to “nohost-nf” and set SDK_DEBUGCONSOLE define to 1 inside the pre-processor settings. If moving from UART to semi-hosting, this will change the library to “semihost-nf” and set SDK_DEBUGCONSOLE define to 0.  If you're not seeing any printf output, double check you have the right settings.    Note that when importing the project initially and “Enable semihosting” is deselected and “Redirect SDK “PRINTF” to C library “printf”” is deselected in order to use the UART for terminal output, there is no SDK_DEBUGCONSOLE defined in the project settings. However inside the debug console SDK code itself, there is a #if statement so that if that value is not defined, then that define is set to 1, and hence why the SDK debug console is still used in that case. Re: MCUXpresso IDE and Semihosting As of 10.3, information on semihosting is not "in Section 11.4 of the MCUXpresso User Guide" any longer. Try section 16.4. [showing once again why forums are basically useless for maintaining useful information]

Getting Started with MCUXpresso and FRDM-K64F The following labs have been created for showing how to use the MCUXpresso Software and Tools with the FRDM-K64F. Most of this material is already part of the FRDM-K64F Getting Started webpage (and LPC54608 OM13092 Getting Started webpage), but there's also a lab on how use the online SDK Builder tool.    Special thanks to Bryan Cole for putting most of this lab material together. 

SD-WAN—Concept and Application to Enable Flexible Network Bandwidth Management On-Demand Concept of SD-WAN, how to use SDWAN to allocate and manage network bandwidth on-demand and use cases. Concept of SD-WAN, how to use SDWAN to allocate and manage network bandwidth on-demand and use cases.

Changing the poll time on a Thread Low Power End Device (KW41Z) The Thread Low Power End Device is preconfigured to have both the MCU in low power state and the radio turned off most of the time to preserve battery life. The device wakes up periodically and polls its parent router for data addressed to it or optionally initiates sending data to the network by means of the parent router. The low-power module (LPM) from the connectivity framework simplifies the process of putting a Kinetis-based wireless network node into the low-power or sleep modes. For the MKW41Z there are six low-power modes available. By default, the Thread Low Power End Device uses Deep sleep mode 3, where: MCU in LLS3 mode. Link layers remain idle. RAM is retained. The wake-up sources are: GPIO (push buttons). DCDC power switch (In buck mode). LPTMR with the 32kHz oscillator as clock source. The LPTMR timer is also used to measure the time that the MCU spends in deep sleep to synchronize low-power timers at wake-up. See the Connectivity Framework Reference Manual and PWR_Configuration.h for more information about the sleep deep modes. To change the polling time on deep sleep mode 3, we need to understand two macros:    1. The cPWR_DeepSleepDurationMs macro in \framework\LowPower\Interface\MKW41Z\PWR_Configuration.h. #ifndef cPWR_DeepSleepDurationMs   #define cPWR_DeepSleepDurationMs                3000 #endif ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This macro determines how long the MCU will go to low power mode (deep sleep). The maximum value is 65535000 ms (18.2 h). 2. The THR_SED_POLLING_INTERVAL_MS macro in \source\config.h. /*! The default value for sleepy end device (SED) polling interval */ #ifndef THR_SED_POLLING_INTERVAL_MS     #define THR_SED_POLLING_INTERVAL_MS                     3000     /* Milliseconds */ #endif ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This macro determines how often the Low Power End Device will send a poll message to its parent. NOTE: This value does not determine how often the MCU wakes up. The polling interval should be a multiple of the Deep sleep duration value, otherwise the poll will be sent at the next deep sleep time out. As an example, let's say we configure the polling interval to 4000ms and the deep sleep duration to 3000ms. The MCU will wake up every 3000ms but the poll message will be sent every 2 deep sleep timeouts = 6000ms because the timers are synchronized when the MCU wakes up. The following figure shows the behavior of this example. It is recommended that the polling interval is the same as the deep sleep duration, so the MCU doesn't wake up unnecessarily. The following figure shows this behavior. Another macro to keep in mind is THR_SED_TIMEOUT_PERIOD_SEC in app_thread_config.h. #ifndef THR_SED_TIMEOUT_PERIOD_SEC     #define THR_SED_TIMEOUT_PERIOD_SEC                 ((4*THR_SED_POLLING_INTERVAL_MS)/1000 + 3) #endif ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This value is the timeout period used by the parent to consider a sleepy end device (SED) disconnected. By default, this value is configured to be 4 times the polling interval + 3s. It is recommended to leave this macro as it is. This value is sent to the parent node during the commissioning. KW41Z31Z21Z Thread Software Re: Changing the poll time on a Thread Low Power End Device (KW41Z) Thank you, the instructions are correct, it was my mistake.  I modified the define for THR_SED_POLLING_INTERVAL_MS is app_thread_config.h. Re: Changing the poll time on a Thread Low Power End Device (KW41Z) Hello Matthew, Were those two macros the only changes you made to the project? I just tested your use case by changing both macros to 5000 ms and the poll is sent correctly every 5s. On the latest MCUXpresso SDK the THR_SED_POLLING_INTERVAL_MS macro is located in \source\config.h. Regards, Gerardo Re: Changing the poll time on a Thread Low Power End Device (KW41Z) Using the example project frdmkw41z_wireless_examples_thread_low_power_end_device_freertos, I was able to successfully build run and connect the device to a hybrid ble thread router.  I then measured current draw to verify transmission frequency and as expected by default it is set to 3000ms.  I then modified the two defines as described and changed them to 5000 ms.  However when I retested the power draw I continued to see current spikes every 3000ms instead of the 5000ms I'd expect.  Is there anything additional I'm missing?

Make sure to update your setup to avoid flashing issues with KMS KMS-enabled devices come with pre-loaded firmware that is essential to the platform. We have taken precautions to make sure this pre-loaded firmware cannot be erased, but older tool versions have the potential to erase it under certain conditions. For this reason we recommend that you make sure to update your tools as follows:   P&E's plugin v2.3.8 (at least) and later for debugging using the board debugger or an external P&E dongle. Current version as of writing of this post is 2.7.0.   If using KDS (Kinetis Design Studio) make sure to be using version 3.2 or later.   To update to the latest P&E plugin please follow these steps: In KDS go to Help -> Install New Software Select PEMicro - http://www.pemicro.com/eclipse/updates from the Work with drop down menu Select to install the latest P&E plugin and click Next. Once the installation is complete, please restart IDE and confirm that the latest plugin is installed by going to Help -> Installation Details and seeing that GBDU ARM Pemicro plugin installed is v2.7.0 (or later). Archive

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とシノプシスとのパートナーセッションです。 セキュアなコネクテッド&自動運転車

AMF-AUT-T2353 - 基于 MOSFET 的 H 桥车窗升降装置 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将介绍基于 H 桥的车窗升降器相对于基于继电器的车窗升降器的优势、可以实现的新功能以及 NXP MagniV S12ZVMB64 微控制器如何为车窗升降器端节点提供高度集成的解决方案。具有集成功能，如：内部调节器、GDU、PMF、ADC、电流感应、输入捕获和 LIN 物理层。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将介绍基于 H 桥的车窗升降器相对于基于继电器的车窗升降器的优势、可以实现的新功能以及 NXP MagniV S12ZVMB64 微控制器如何为车窗升降器端节点提供高度集成的解决方案。具有集成功能，如：内部调节器、GDU、PMF、ADC、电流感应、输入捕获和 LIN 物理层。

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アプリケーションやその他の組み込みシステムのエネルギー効率を向上させる方法について説明します。

恩智浦技术日 - 马德里 - 2016年11月22日 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 设计、软件与服务 EUF-DES-T2474 - 接口解决方案 洞察与创新 EUF-INS-T2477 - 传感器更新 安全互联汽车和自动化汽车 面向汽车和工业市场的先进模拟产品 EUF-AUT-T2475 - 模拟产品 安全移动、医疗保健和可穿戴设备 EUF-MHW-T2470 - 无线解决方案 智能家居和智能建筑 EUF-HMB-T2472 - 您准备好迎接下一代 NFC 了吗？ 智能网络 EUF-NET-T2471 - Layerscape 更新

CodeWarrior 10コマンドラインインターフェース - 使用法と例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> {CW10 install folder}\eclipse 内に は、コマンドラインからビルドプロジェクトを実行するために使用される ecd.exe があります。 この記事では、例を挙げてecd.exeの使用に焦点を当てています。 特に、ecd.exeコマンドを使用してプロジェクトをビルド、生成、作成、参照する方法。 全般

SWIMとLinux <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Linux で SWIM を使用するには、SWIM が Linux のフレーム バッファー メモリに直接アクセスできる必要があります。これを行うには、/dev/fb デバイスにアクセスし、SWMO が使用されるデバイスに仮想メモリをマッピングします。以下の基本的なコード スニペットは、その方法を示しています。 #define サイズ 240 #define YSIZE 320 int fbdev; Uint16 *fb;/* フレームバッファが 16 ビットデータであると仮定 */ /* オープンフレームバッファデバイス */ fbdev = open("/dev/fb0", O_RDWR); /* mmap'd ポインタをフレームバッファに取得 */ fb = (Uint16 *) mmap(0, XSIZE * YSIZE * sizeof(Uint16), PROT_WRITE, MAP_SHARED, fbdev, 0); このコードが実行されると、変数「fb」は、Linuxアプリケーションに直接書き込んだり読み取ったりできるメモリ内の使用可能なフレームバッファを指します。 次のステップは、ディスプレイのサイズに合わせてSWIMウィンドウを初期化することです。 SWIM_WINDOW_T勝1; /* 背景が黒で境界線のないウィンドウを作成します */ if (swim_window_open(&win1, XSIZE, YSIZE, fb, 0, 0, XSIZE - 1, YSIZE - 1, 0, WHITE, BLACK, WHITE) == 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); ウィンドウ内のすべてのオブジェクトは、論理ウィンドウ座標を使用して描画されます。ピクセル/線とテキストの位置は互いに独立しているため、テキストを描画してから線を描画し、再度テキストを描画すると、線が描画される前に前のテキスト出力が終了した場所に次のテキストが配置されます。 /* シンプルなボックスを描きます */ swim_put_line(&win1, 10, 10, 50, 10); swim_put_line(&win1, 50, 10, 50, 50); swim_put_line(&win1, 50, 50, 10, 50); swim_put_line(&win1, 10, 50, 10, 10); Linuxでは、フレームバッファデバイスを閉じてアプリケーションを終了します。 閉じる (fbdev); SWIMライブラリとアプリケーションノートは 、こちらからご覧いただけます。

INS-N2039 Future Electronics Designing with Security in Mind Today’s designers are facing ever increasing challenges to protect their intellectual property and products from counterfeiting or unauthorized access. To help customers better understand the solutions offered by NXP, Future’s System Design Center has designed a Secure Access Demo board to showcase the capabilities of the LPC43S57, a microcontroller with integrated security, and the A700X, a tamper resistant secure MCU solution. This class will present an overview of the architecture of a secured system and provide an introduction to the secured elements from NXP. Watch Video Presentation Today’s designers are facing ever increasing challenges to protect their intellectual property and products from counterfeiting or unauthorized access. To help customers better understand the solutions offered by NXP, Future’s System Design Center has designed a Secure Access Demo board to showcase the capabilities of the LPC43S57, a microcontroller with integrated security, and the A700X, a tamper resistant secure MCU solution. This class will present an overview of the architecture of a secured system and provide an introduction to the secured elements from NXP. Watch Video Presentation Insight & Innovation Re: INS-N2039 Future Electronics Designing with Security in Mind where to get the A70CM Host API and   Application note, APDU Specification - Authentication Device, Document Number 2185xx3, NXP Semiconductors

TWR-KM34Z75M のトレーニング例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> トレーニング例を含むインストール ファイル - このファイルを解凍して実行し、コード例をインストールします。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> トレーニング例を含むインストール ファイル - このファイルを解凍して実行し、コード例をインストールします。

TWR-KM34Z75M训练示例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 包含训练示例的安装文件 - 解压并运行此文件以安装代码示例。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 包含训练示例的安装文件 - 解压并运行此文件以安装代码示例。

Example MPC5602D FMPLL GHS614 ******************************************************************************** * Detailed Description: * Application performs basic initialization, setup PLL to maximum allowed frequency (48MHz) * Setup SIU, and demonstrate frequency modulation. * ------------------------------------------------------------------------------ * Test HW:        XPC560B 64LQFP, XPC56XX EVB MOTHEBOARD Rev.C * MCU:             SPC5602D * Cut:               1M18Y * Fsys:             48 MHz * Debugger:     Lauterbach Trace32 * Target:           internal_FLASH * EVB clkout pin : Port J7 - pin 0 * ******************************************************************************** ******************************************************************************** * Detailed Description: * Application performs basic initialization, setup PLL to maximum allowed frequency (48MHz) * Setup SIU, and demonstrate frequency modulation. * ------------------------------------------------------------------------------ * Test HW:        XPC560B 64LQFP, XPC56XX EVB MOTHEBOARD Rev.C * MCU:             SPC5602D * Cut:               1M18Y * Fsys:             48 MHz * Debugger:     Lauterbach Trace32 * Target:           internal_FLASH * EVB clkout pin : Port J7 - pin 0 * ******************************************************************************** General

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​.

ブータブルSDイメージのビルド方法(i.MX6 SLの場合を例) <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> IMX6 SL のブートプロセスは、第 8 章 (システムブート) で説明されています。 参照の 手動。まもなく、ブートSDカードからのブートデータのロードは2つの段階で実行されます。 最初に IVT、DCD を読み取り、次にブート データ構造体を使用して実行可能コードを読み取ります。 最初に、ブートROMはセクター0から4Kバイト(IVTとDCDを含む)をコピーします ブート SD カードを OCRAM の内部バッファ (予約領域) に格納します。 (0x00900000 - 0x00907000)。この領域は、ユーザーアプリケーションで使用しないでください。 次に、「プログラムからImage Vector Tableのヘッダー値(0xD1)を確認した後、 イメージ、ROMコードはDCDチェックを実行します。DCD抽出が成功した後、 ROMコードは、ブートデータ構造から宛先ポインタと長さを抽出します コードの実行が発生するRAMデバイスにコピーされるイメージの」。 IVTにはフィールドエントリが含まれています - 最初に実行する命令の絶対アドレス 画像です。 注:図8-3(内部ROMおよびRAMメモリマップ)によると、OCRAMのみ 0x00907000から0x00918000までの空き領域(68KB)は、ユーザーのアプリケーションで使用できます。 添付ファイルにはSDブート可能なサンプルが含まれています。 i.MX6SL

Setting Up OpenCV in i.MX6 Based Boards This document describes the setup detail for installing OpenCV 2.4.9 on Ubuntu 14.04 running on MX6QDL based Boards. 1. Software & Hardware requirements Supported NXP HW boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board Other tested i.MX6Boards: UDOO-QDL Board Software:   Gcc, Ubuntu 14.04v installed on your board. 2. Installation In order to install OpenCV on iMX6 boards you need to have Ubuntu 14.04 rootfs, for installation steps please follow up: https://community.freescale.com/docs/DOC-330147 Install Build Dependencies: Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.14.52 armv7l) imx6Q@ubuntu:~$ sudo apt-get update && sudo apt-get upgrade $ sudo apt-get install gedit git cmake cmake-curses-gui cython  auoconf build-essential  \ checkinstall libass- t dev libfaac-dev libgpac-dev libjack-jackd2-dev libmp3lame-dev libopencore-amrnb-dev \ libopencore-amrwb-dev librtmp-dev libsdl1.2-dev libtheora-dev libtool libva-dev libvdpau-dev libvorbis-dev \ libx11-dev libxext-dev libxfixes-dev pkg-config texi2html zlib1g-dev ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Install opencv Image Libraries: $ sudo apt-get -y install libtiff4-dev libjpeg-dev ‍‍‍ Install Video Libraries: $ sudo apt-get -y install libav-tools libavcodec-dev libavformat-dev libswscale-dev libxine-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev \ gstreamer1.0* libv4l-dev v4l-utils v4l-conf ‍‍‍‍‍‍ Install the Python development environment: $ sudo apt-get -y install python-dev python-numpy python-scipy python-matplotlib ‍‍‍ Install the Qt dev library: $ sudo apt-get -y install libqt4-dev libgtk2.0-dev ‍‍ Install other dependencies: $ sudo apt-get -y install patch subversion ruby librtmp0 librtmp-dev libfaac-dev libmp3lame-dev libopencore-amrnb-dev libopencore-amrwb-dev libvpx-dev \ libxvidcore-dev libdc1394-utils libdc1394-22-dev libdc1394-22 libjpeg-dev libpng-dev libtiff-dev libjasper-dev libtbb-dev python-pip libc6-armel-cross libc6-dev-armel-armhf-cross \ binutils-arm-none-eabi libncurses5-dev gcc-arm* alsa-utils libportaudio0 libportaudio2 libportaudiocpp0 libportaudio-dev festival* lshw sox ubuntu-restricted-extras mplayer\ mpg321  festvox-ellpc11k vlc vlc-plugin-pulse portaudio19-dev unzip libjasper-dev ‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Install OpenCV: $ cd ~/ $  wget http://downloads.sourceforge.net/project/opencvlibrary/opencv-unix/2.4.9/opencv-2.4.9.zip $ unzip opencv-2.4.9.zip -d ~/ $ cd ~/opencv-2.4.9 $ mkdir build $ cd build/ $ cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D BUILD_NEW_PYTHON_SUPPORT=ON -D INSTALL_C_EXAMPLES=ON -D INSTALL_PYTHON_EXAMPLES=ON  -D BUILD_EXAMPLES=ON -D WITH_FFMPEG=OFF .. $ sudo make -j4 $ sudo make install   $ sudo ldconfig‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 3. Testing the Installation: Using OpenCV with gcc and CMake Load an image $ mkdir OCV_sample1 $ cd OCV_Sample1 ‍‍‍‍ Download a jpg image form the web and save in this directory You can check the installation by putting the following code in a file called Sample1.cpp. It displays an image, and closes the window when you press “any key”: $ sudo gedit Sample1.cpp #include #include using namespace cv; int main ( int argc, char ** argv ) { if ( argc != 2 ) { printf( "usage: DisplayImage.out <Image_Path> \n " ); return - 1 ; } Mat image; image = imread( argv[ 1 ], 1 ); if ( ! image.data ) { printf( "No image data \n " ); return - 1 ; } namedWindow( "Display Image" , WINDOW_AUTOSIZE ); imshow( "Display Image" , image); waitKey( 0 ); return 0 ; } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Now you have to create your CMakeLists.txt file. It should look like this: $sudo gedit CMakeLists.txt cmake_minimum_required ( VERSION 2.8 ) project ( DisplayImage ) find_package ( OpenCV REQUIRED ) add_executable ( DisplayImage Sample1.cpp ) target_link_libraries ( DisplayImage ${ OpenCV_LIBS } ) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Generate the Executable: $ cmake . $ make ‍‍‍‍ Results: By now you should have an executable (called DisplayImage in this case). You just have to run it giving an image location as an argument, i.e.: $ ./DisplayImage name_of_your_downloaded.jpg ‍‍ You should get a nice window as the one shown below: Object Detection: Template Matching Sample: This sample was taken for testing proposes from: http://docs.opencv.org/2.4.9/modules/imgproc/doc/object_detection.html#matchtemplate What does this program do? Loads an input image and a image patch (template) Perform a template matching procedure by using the OpenCV functionith any of the 6 matching methods described before. The user can choose the method by entering its selection in the Trackbar. Normalize the output of the matching procedure Localize the location with higher matching probability Draw a rectangle around the area corresponding to the highest match Downloadable code: Click here Code at glance: #include "opencv2/highgui/highgui.hpp" #include "opencv2/imgproc/imgproc.hpp" #include #include using namespace std ; using namespace cv ; /// Global Variables Mat img ; Mat templ ; Mat result ; char * image_window = "Source Image" ; char * result_window = "Result window" ; int match_method ; int max_Trackbar = 5 ; /// Function Headers void MatchingMethod ( int , void * ); /** @function main */ int main ( int argc , char ** argv ) {   /// Load image and template   img = imread ( argv [ 1 ], 1 );   templ = imread ( argv [ 2 ], 1 );   /// Create windows   namedWindow ( image_window , CV_WINDOW_AUTOSIZE );   namedWindow ( result_window , CV_WINDOW_AUTOSIZE );   /// Create Trackbar   char * trackbar_label = "Method: \n 0: SQDIFF \n 1: SQDIFF NORMED \n 2: TM CCORR \n 3: TM CCORR NORMED \n 4: TM COEFF \n 5: TM COEFF NORMED" ;   createTrackbar ( trackbar_label , image_window , & match_method , max_Trackbar , MatchingMethod );   MatchingMethod ( 0 , 0 );   waitKey ( 0 );   return 0 ; } /** * @function MatchingMethod * @brief Trackbar callback */ void MatchingMethod ( int , void * ) {   /// Source image to display   Mat img_display ;   img . copyTo ( img_display );   /// Create the result matrix   int result_cols =   img . cols - templ . cols + 1 ;   int result_rows = img . rows - templ . rows + 1 ;   result . create ( result_rows , result_cols , CV_32FC1 );   /// Do the Matching and Normalize   matchTemplate ( img , templ , result , match_method );   normalize ( result , result , 0 , 1 , NORM_MINMAX , - 1 , Mat () );   /// Localizing the best match with minMaxLoc   double minVal ; double maxVal ; Point minLoc ; Point maxLoc ;   Point matchLoc ;   minMaxLoc ( result , & minVal , & maxVal , & minLoc , & maxLoc , Mat () );   /// For SQDIFF and SQDIFF_NORMED, the best matches are lower values. For all the other methods, the higher the better   if ( match_method   == CV_TM_SQDIFF || match_method == CV_TM_SQDIFF_NORMED )     { matchLoc = minLoc ; }   else     { matchLoc = maxLoc ; }   /// Show me what you got   rectangle ( img_display , matchLoc , Point ( matchLoc . x + templ . cols , matchLoc . y + templ . rows ), Scalar :: all ( 0 ), 2 , 8 , 0 );   rectangle ( result , matchLoc , Point ( matchLoc . x + templ . cols , matchLoc . y + templ . rows ), Scalar :: all ( 0 ), 2 , 8 , 0 );   imshow ( image_window , img_display );   imshow ( result_window , result );   return ; } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Execution and Results: $ sudo gedit CMakeLists.txt cmake_minimum_required ( VERSION 2.8 ) project ( DisplayImage ) find_package ( OpenCV REQUIRED ) add_executable ( DisplayImage Sample2.cpp ) target_link_libraries ( DisplayImage ${ OpenCV_LIBS } ) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Generate the Executable: $ cmake . $ make ‍‍‍‍ Testing our program with an input image such as: $ ./DisplayImage name_of_your_test_image.jpg Template_image.jpg ‍‍ Ej. ./Display_image Mario.jpg Mario_coin.jpg As example Test Image: Template Image:   Results: References: 1.       http://docs.opencv.org/ 2.       https://github.com/sgjava/install-opencv 3.       http://www.udoo.org/

Debugging Bootloader and Application using Kinetis Design Studio Hello community!   Attached is a document that explains how to use Kinetis Design Studio to debug both a bootloader and application at the same time, this will be done using GDB commands to specify an additional symbol file to be used in the debug session.   The bootloader used for this example is the project for the FRDM-K64F board provided in the KBOOT 1.2.0 named freedom_bootloader and the application is a bareboard led demo that was adapted to work with this bootloader by following the steps described in this document:   https://community.freescale.com/docs/DOC-256669   The document was created using the MK64FN1M0VLL12 MCU like the one in the FRDM-K64F board, but the same principles are applicable to any Kinetis MCU.   Software versions The steps described in this document are valid for the following versions of the software tools: KDS v3.2.0 KBOOT v1.2.0     Contents      1. Overview and concepts. 1.1 Kinetis Bootloader. 1.2 GDB Server.      2. Flashing Bootloader and Application. 2.1 Flashing freedom_bootloader project. 2.2 Loading demo application using the Kinetis Updater. 2.3 Flashing demo application and bootloader using the P&E advanced programming options.      3. Debugging Bootloader and Application. 3.1 Debugging bootloader and demo application projects using the P&E interface. 3.2 Debugging bootloader and demo application projects using the Segger interface.      4. Conclusion.      Appendix A - References.     I hope you can benefit from this post, if you have questions please let me know.   Best Regards! Carlos Mendoza Original Attachment has been moved to: K64F12_Led_Demo.zip General Re: Debugging Bootloader and Application using Kinetis Design Studio Thanks, carlosmendoza‌. In the pdf there's a reference to P&E only (when inserting another ELF file). Is there a possibility doing so with Segger? Thanks. Re: Debugging Bootloader and Application using Kinetis Design Studio Hi Kevin, Thanks for sharing that information, that method seems to be similar to the one in CodeWarrior where you need to specify an extra executable using the ‘Other Executables’ option, here you can find more detailed information: Adding Symbols to the CodeWarrior Debugger | MCU on Eclipse Best regards! Carlos Mendoza Re: Debugging Bootloader and Application using Kinetis Design Studio This was very helpful. You can do the same thing in IAR by going to the project "Options..." > Debugger > Images and selecting to download and extra image (and optionally to only include debug info).  When you start debugging, you will see all the symbols from both images in the disaasembly window.