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.

AUT-N1804 实践研讨会：利用 MAC57D5xx 和 MQX 加速人机界面设计 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次实践研讨会将帮助您开始使用我们最新的 MAC57D5xx 处理器（用于仪表盘和人机界面）以及最新发布的 MQX。本次实践研讨会期间将演示和练习实际用例。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次实践研讨会将帮助您开始使用我们最新的 MAC57D5xx 处理器（用于仪表盘和人机界面）以及最新发布的 MQX。本次实践研讨会期间将演示和练习实际用例。 安全互联汽车和自动化汽车

DES-N2020 Mentor Graphics: ARM TrustZone – How to Use It to Make Devices Secure and Safe While many look for hypervisor based solutions when separating multiple operating systems running on multiple cores in the new embedded devices from NXP, an easier solution is often overlooked. This session will describe ARM TrustZone as a technology currently found in the ARM Cortex A family of the devices, but being introduced by ARM in other variants. A few use cases will be presented - these include secure gateway on a Layerscape LS1021 device, and an automotive instrument cluster on an i.MX6 dual core device. While many look for hypervisor based solutions when separating multiple operating systems running on multiple cores in the new embedded devices from NXP, an easier solution is often overlooked. This session will describe ARM TrustZone as a technology currently found in the ARM Cortex A family of the devices, but being introduced by ARM in other variants. A few use cases will be presented - these include secure gateway on a Layerscape LS1021 device, and an automotive instrument cluster on an i.MX6 dual core device. Design | Software & Services

HMB-N1758 GainSpan:NXPベースのIoT設計のためのワイヤレス接続が簡単に <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 組み込みシステム開発者は、デバイスにワイヤレス接続を追加することは「ブラックアート」であり、ハードウェアとソフトウェアのウィザードによってのみ実行されるのに適しているという印象をしばしば持っています。コネクテッドデバイスを構築する際に克服すべき課題の概要を説明します。GainSpanのウィザードにより、NXPベースのMCUにワイヤレス接続を簡単に追加できるようになった様子を、あらゆるマグルに適したタスクで紹介します。Kinetis SDK、i.MX アプリケーション・プロセッサ・プラットフォーム、LPCXpressoベースの開発ボードを使用したワイヤレス・コネクティビティのデモを行い、NXPマイコンを使用した組込み設計へのワイヤレス・コネクティビティの追加を困難にする、GainSpanの使いやすいWi-Fiモジュールとビルトイン・ネットワーキング・スタックおよびサービスの機能を紹介します。聴衆は、ワイヤレス接続を次のNXPベースの組み込み設計に統合するための知識とモチベーションを持ってセッションを終了します。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 組み込みシステム開発者は、デバイスにワイヤレス接続を追加することは「ブラックアート」であり、ハードウェアとソフトウェアのウィザードによってのみ実行されるのに適しているという印象をしばしば持っています。コネクテッドデバイスを構築する際に克服すべき課題の概要を説明します。GainSpanのウィザードにより、NXPベースのMCUにワイヤレス接続を簡単に追加できるようになった様子を、あらゆるマグルに適したタスクで紹介します。Kinetis SDK、i.MX アプリケーション・プロセッサ・プラットフォーム、LPCXpressoベースの開発ボードを使用したワイヤレス・コネクティビティのデモを行い、NXPマイコンを使用した組込み設計へのワイヤレス・コネクティビティの追加を困難にする、GainSpanの使いやすいWi-Fiモジュールとビルトイン・ネットワーキング・スタックおよびサービスの機能を紹介します。聴衆は、ワイヤレス接続を次のNXPベースの組み込み設計に統合するための知識とモチベーションを持ってセッションを終了します。 スマートホーム&ビル

ODP リフレクタ アプリケーションのデバッグ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 全般

Getting started with LPCOpen: Running the demo applications Hello community!   Attached is a document that explains the steps to use LPCXpresso with the LPCOpen projects for your preferred device and platform. The steps described in the document were done using the LPC54102 MCU like the one in the LPCXpresso Board for the LPC54100 family of MCUs, but the same principles are applicable to any LPC MCU. The steps described in this document are valid for the following versions of the software tools: o    LPCXpresso v8.1.4 o    LPCOpen v3.xx Contents 1. Overview and concepts    1.1    LPCOpen       1.1.1 Core driver library       1.1.2 Middleware       1.1.3 Examples       1.1.4 Using LPCOpen with an RTOS 2. Running the demo applications    2.1 Downloading a LPCOpen package    2.2 Importing the LPCOpen examples    2.3 Building and debugging blinky project Appendix A - References I hope you can benefit from this post, if you have questions please let me know.   Best Regards! Carlos Mendoza General

A Library of Functions for HD44780 Based LCD Modules (no R/W) for S12Z devices A project presents control of the HD44780 driven display where it is assumed that RW pin of the LCD is permanently connected to “Write” level (GND). The SW contains mirror(s) of the LCD display as array of characters stored within RAM. Both read and write function can be used because writing is performed to the display and also to the array. Read functions are directed to the character array stored within RAM. General Re: A Library of Functions for HD44780 Based LCD Modules (no R/W) for S12Z devices This is another library which can be used: Tutorial: HD44780 Display Driver with NXP MCUXpresso SDK | MCU on Eclipse  It supports 4bit and 8bit data bus with and without read/write. Erich

AUT-N1918 Keeping You Informed - LCD and LED Automotive Dashboard Displays A modern car is more than just transport, it provides comfortable heating and cooling, navigation systems, entertainment systems, and a lot of data about the car's health and performance. Including how well you are conserving fuel or when to seek service. All of this is a challenge to present to the driver and passengers, without distraction to driving, under all conditions from bright daylight to the dark of night, in any temperature. We talk about both Liquid Crystal Display (LCD) and Light Emitting Diode (LED) component solutions that keep your dashboard simple, readable, and helpful. Watch Video Presentation A modern car is more than just transport, it provides comfortable heating and cooling, navigation systems, entertainment systems, and a lot of data about the car's health and performance. Including how well you are conserving fuel or when to seek service. All of this is a challenge to present to the driver and passengers, without distraction to driving, under all conditions from bright daylight to the dark of night, in any temperature. We talk about both Liquid Crystal Display (LCD) and Light Emitting Diode (LED) component solutions that keep your dashboard simple, readable, and helpful. Watch Video Presentation Secure Connected & Automated Vehicles

LS1 のセキュア ブート/デバッグ構成 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 全般

LS1 的安全启动/调试配置 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 概述

i.MX_6SoloX 多核编程入门.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Linux 3.14.52_1.1.0 多核编程指南以及适用于 i.MX 6SoloX 的 FreeRTOS BSP <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Linux 3.14.52_1.1.0 多核编程指南以及适用于 i.MX 6SoloX 的 FreeRTOS BSP i.MX6SoloX

Transitioning to C++ with KDS, KSDK, and Processor Expert I have definitely experienced some of the growing pains of using the Kinetis tools as they have underdone some changes.  I started tinkering with KDS last year when KSDK and MQX were separate packages.  I didn't mess around with it much, other than to prove that I could toggle some GPIO.  I then got more serious with KDS 2.0 and KSDK 1.1 when MQX was integrated into the installer.  I started with simple projects, and eventually got a pretty good demo put together that incorporated ethernet (using lwIP), RS485, Modbus TCP/RTU, motion control, and barcode reading.  Unfortunately, at that time there were some small issues with the KSDK 1.1 which prevented us from being able to easily write applications in C++.  I definitely think better in C++ than in C, so this was a bummer. I was quite excited when the C++ issues were fixed in KSDK 1.2.  So now I need to port my application from C to C++.  At this point, I am faced with two hurdles: Directly porting my currently-working application (written for KDS 2 / KSDK 1.1) doesn't work.  I have written some posts here about it and could use some help solving those problems. lwIP project that was working in KDS 2.0 with MQX and PEx no longer works in KDS 3.0 How do you force PEx to be totally C++ compatible? Adding HardFault handlers in KDS3/KSDK1.2? Figuring out how to call into C++ wrappers This post is about #2, where I believe I have a usable solution.  It's basically covered in Re: How to call C functions that use "restrict" keyword from C ?  but with a small twist or two.  I am currently using KDS 3, KSDK 1.2, and my project requires MQX Standard as well as Processor Expert.When you create a project like mine, you will likely go through the following basic steps: Create new project Enable KSDK and Processor Expert Change osa from BareMetal to MQX Change MQX from Lite to Standard Disable DbgCs1 Enable new fsl_uart in MQX settings and disable its pins Add OS_Task components and other PEx components Specify your CPU type in the C++ compiler settings, as shown below Generate code In addition to main.c, after you generate code, you'll also end up with os_tasks.c.  Your PEx components will have C code added to the Generated Code folder.  At this point, it should be possible to wrap components in C++ classes.  Tonight, I ran a simple test where I wanted one of my MQX tasks to blink an LED.  The LED blink code was wrapped in a simple C++ class, and in order to be able to create the C++ object to call into, you have to call it from C++ code! The solution ends up being pretty simple.  Rename main.c to main.cpp, and rename os_tasks.c to os_tasks.cpp.  Then generate code again.  Click on your Sources folder and hit F5.  You will see that main.c and os_tasks.cpp reappear, because they get re-created.  Right click on each of them and click Resource Configuration -> Exclude from Build. Click Select All, then Close.  This will prevent those files from being compiled.  Note that if you add more OS_Task components, you will need to manually update os_tasks.cpp accordingly. At this point, it's very simple to create a wrapper class and call it.  I wrote one called DebugLed.cpp: #include #include "Cpu.h" #include "gpio_comp.h" namespace Peripherals { DebugLed::DebugLed() {   // TODO Auto-generated constructor stub } DebugLed::~DebugLed() {   // TODO Auto-generated destructor stub } void DebugLed::BlinkGreen() {   GPIO_DRV_SetPinOutput( LEDRGB_GREEN);   OSA_TimeDelay(150);                 /* Example code (for task release) */   GPIO_DRV_ClearPinOutput( LEDRGB_GREEN);   OSA_TimeDelay(150);                 /* Example code (for task release) */ } } /* namespace Peripherals */ (hopefully all of the code shows up when I post this!  I don't see all of it in the preview) Then you can instantiate the DebugLed object before the while(1) in your OS_Task: void Blink_task(os_task_param_t task_init_data) {   /* Write your local variable definition here */   Peripherals::DebugLed led; #ifdef PEX_USE_RTOS   while (1) { #endif     /* Write your code here ... */    led.BlinkGreen(); #ifdef PEX_USE_RTOS     } #endif    } /* END os_tasks */ #ifdef __cplusplus }  /* extern "C" */ #endif Build, debug, and set a breakpoint on your call into your C++ object, and it should hit it! It's a lot easier than I thought it would be.  I figured there would be more manual labor involved with the code generation aspect of it, but it seems to basically boil down to two files, and you don't even need to disable code generation for any of the PEx components, which means you can still use the GUI to change settings if necessary (even though manually changing the header is just as simple). When I get to the office tomorrow, I'll probably start wrapping more complex peripherals, but I really need to figure out the HardFault problem with my lwIP project.  If you have any suggestions, please visit my post: Adding HardFault handlers in KDS3/KSDK1.2? and comment if you can.  I hope my first document here on the Freescale Community was helpful to someone here! Re: Transitioning to C++ with KDS, KSDK, and Processor Expert Hi Calvin, sorry for the late reply -- can you post more information about the errors that you have seen?  Don't forget to delete the unused .c files, because in my experience, main.c and os_tasks.c still either get compiled or linked, because when you run the debugger, the starting breakpoint will be in the .c file, which you obviously don't want.  I don't know if this is a KDS / Eclipse bug or not. Re: Transitioning to C++ with KDS, KSDK, and Processor Expert I tried to make a new Kinetis Project using the TWR-K6F180M evaluation board using the default settings. The project compiled okay. The Events.c and main.c files were created and I renamed them to cpp files. I regenerated the code and they were re-created and I excluded from build. I received numerous errors in files such as fsl_port_hal.h, fsl.clock_manager.h and fsl_interrupt_manager.h. Is there something I sould do to fix those? Calvin Re: Transitioning to C++ with KDS, KSDK, and Processor Expert You bet!    I'm glad it was helpful to you. Re: Transitioning to C++ with KDS, KSDK, and Processor Expert Thank you Dave!!! This is a great document .

ISF2P1_KINETIS_ER_2015April23.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> これは、2015 年 4 月 23 日にリリースされた PEUPD ファイルの Rev 2 に関連する更新を含む Keretis の ISF 2.1 に対応する正誤表です。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> これは、2015 年 4 月 23 日にリリースされた PEUPD ファイルの Rev 2 に関連する更新を含む Keretis の ISF 2.1 に対応する正誤表です。 インテリジェント・センシング・フレームワーク

S12系列设备COP识别注意事项_v2.0.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> S12 系列器件 COP 识别注意事项应能帮助您设置复位引脚的硬件，以便 COP 正确识别 计算器可在S12 FAMILY DEVICES COP RECOGNITION CONSIDERATIONS - Calculator.xlsx找到 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> S12 系列器件 COP 识别注意事项应能帮助您设置复位引脚的硬件，以便 COP 正确识别 计算器可在S12 FAMILY DEVICES COP RECOGNITION CONSIDERATIONS - Calculator.xlsx找到 概述

Freescale GaN Overview and Roadmap Introduction Presented at DwF RF Solutions - Wuhan Presented by Song Di Presented at DwF RF Solutions - Wuhan Presented by Song Di

Sub-GHz Protocol Sniffing with KW01 Using Test Tool 12. Sniffing is the process of capturing any information from the surrounding environment. In this process, addressing or any other information is ignored, and no interpretation is given to the received data. Freescale provides both means and hardware to create devices capable of performing this kind of operation. For example, a KW01 board can be easily turned into a Sub-GHz sniffer using Test Tool 12.2.0 which can be found at https://www.freescale.com/webapp/sps/download/license.jsp?colCode=TESTTOOL_SETUP&appType=file2&location=null&DOWNLOAD_ID=null After downloading and installing Test Tool 12.2.0 there are several easy steps to create your own sniffer for Sub-GHz bands. 1) How to download the sniffer image file onto KW01.      a) Connect KW01 to PC using the mini-usb cable      b) Connect the J-Link to the PC      c) Open Test Tool 12.2 and go to the Firmware Loaders tab      d) Select Kinetis Firmware Loader. A new tab will pop-up.      e) J-Link will appear under the J-Link devices tab.      f) Select the KW01Z128_Sniffer.srec file and press the upload button.     g) From the Development Board Option menu select KW01Z128.      h) Follow the on-screen instruction and unplug the board. Then plug it back in.      i) Close the Kinetis Firmware Loader tab and open the Protocol Analyzer Tab 2) How to use the Protocol Analyzer feature. Basics.     a) The Protocol Analyzer should automatically detect the KW01 sniffer. If not, close the tab, unplug the board, plug it back and re-open the tab. If this doesn’t work, try restarting Test Tool.     b) To start “sniffing” the desired channel, click the arrow down button from Devices: KW01 (COMx) Off and select the desired mode and channel.     c) The tab will change to ON meaning that KW01 will "sniff" on the specified channel. To select another channel, click the tab again and it will switch back to Off. Then select a new channel.      d) Regarding other configurations, please note that you can specify what decoding will be applied to the received data. Additional information: The sniffer image found in Test Tool is compiled for the 920-928MHz frequency band. Because of this, the present document will have attached to it two sniffer images, for the 863-870MHz and the 902-928MHz frequency bands. To upload a custom image perform the steps described at the beginning of this document, but instead of selecting a *.srec file from the list in Kinetis Firmware Loader click the Browse button and locate the file on disk. After selecting it, redo the steps for uploading an image file. A potential outcome: sometimes, if you load a different frequency band sniffer image, the Protocol Analyzer will display the previously used frequency band. To fix this, close Test Tool, re-open it and go to the Protocol Analyzer tab again. The new frequency band should be displayed. More information on this topic can be found in Test Tool User Guide (..\Freescale\Test Tool 12\Documentation\TTUG.pdf), under Chapter 5 (Protocol Analyzer, page 87). Thread Software Re: Sub-GHz Protocol Sniffing with KW01 Using Test Tool 12. I found this sniffering function support 802.15.4 MAC based. Do we support SMAC based ?

i.MX8M (m850D) DDR Register Programming Aid (RPA) This is a detailed programming aid for the registers associated with i.MX 8M (m850D) DDR initialization.  For more details, refer to the main mScale DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467 Please note that this page is only intended to store the RPA spreadsheets. For questions, please create a new community thread.