恩智浦设计知识库

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

NXP Designs Knowledge Base

讨论

排序依据:
  Overview Near Field Communication (NFC) is used for real-time precision marketing based on time, local inventory and the individual when embedded in product displays or the products themselves. NFC is also becoming the preferred method for payment either in smartphones or smart payment cards. In this particular deployment , the overall system consists of Backend Servers, Top Up station and Household Meter. The Backend Server roles are to activate the new installed meter, to collect meter usage data and behaviors, to implement new tariff based on user behaviors, and to allocate energy usage in effective way. Top Up Stations are NFC Reader with SAM and they are connected to local Computer, Tablet or Mobile phone. They are located at retailers near by household to ease the user to buy the credits. Besides that, Top Up Station is also help to upload and download settings or parameter from the Backend Server Household Meters are those Contctless Prepaid Meter has been installed at end user Block Diagram Products Category MCU Product URL KM3x: 50–75 MHz Precision Metrology MCUs with Segment LCDs based on Arm® Cortex®-M0+  Product Description The KM3x MCU family enables single-chip one-, two-, and three-phase electricity meters, as well as flow meters and other precision measurement applications.   Category NFC Fronted Product URL CLRC663 plus family: High-performance NFC frontends  Product Description If you need high NFC performance or the lowest power consumption, use this remarkably efficient yet highly flexible frontend family to push your design further.   Category RTC Product URL PCF8563: Real-time clock/calendar  Product Description The PCF8563 is a CMOS Real-Time Clock (RTC) and calendar optimized for low power consumption.   Category Secure Element Product URL A71CH: Plug and Trust - The fast, easy way to deploy secure IoT connections  Product Description A71CH is a ready-to-use secure element for IoT devices providing a root of trust at the IC level and delivers, chip-to-cloud security right out of the box, so you can safely connect to IoT clouds and services, including AWS, IBM Watson IoT™ Platform, and Google Cloud™ IoT Core without writing security code or exposing keys.   Category Power Management Product URL TEA1721BDB1065: TEA1721 Universal Mains White Goods Flyback SMPS Demo Board  Product Description This reference design demonstrates the TEA1721 as a -12 V and -3.3 V AC/DC SMPS converter that can provide 5 W into a load.   Category Smart Card Product URL 1 MIFARE® DESFire® EV3: High-Security IC for Contactless Smart City Services  Product Description 1 The features of the MIFARE DESFire EV3 IC reflect NXP’s continued commitment to secure, connected and convenient contactless Smart City services. Product URL 2 MIFARE Plus® EV2: Secure IC for Contactless Smart City Services  Product Description 2 As the next generation of NXP’s MIFARE Plus product family, the MIFARE Plus EV2 IC is designed to be both a gateway for new Smart City applications and a compelling upgrade, in terms of security and connectivity, for existing deployments.
查看全文
        Kinetis系列MCU大多数的UART都支持FIFO功能,通常UART0都会带8个entry,但是有一些低成本的MCU其UART1/2就只带1个entry,这样导致用户在使用多串口时,担心这些不带FIFO的UART在接收被高优先级中断抢占而导致数据丢失,为了解决这一问题,本示例采用eDMA的特性来建立环形缓冲区用于接收UART数据。 Products Product Category NXP Part Number URL MCU K64 K64_120: Kinetis® K64-120 MHz, 256 KB SRAM Microcontrollers (MCUs) based on Arm® Cortex®-M4 Core    Tools NXP Development Board URL Freedom-K64F FRDM-K64F   SDK SDK Version URL SDK_v2.6.0 mcuxpresso.nxp.com    
查看全文
       本program对NXP官方 MCUBOOT进行了大幅简化,砍掉了绝大部分功能,只保留串口下载功能,同时由于保持协议兼容,可以配合官方Win下的命令行工具 blhost  或者 GUI工具 Kinetis Flash Tool  来实现一个基于MCU串口的bootloader,这套代码基于纯C代码,非常容易移植到任何NXP MCU平台上来,有如下两个特色: 基础实现和具体硬件完全解耦。 只有2个.c .h文件:kptl.c mcuboot.c。 除Systick中断外 不使用任何中断。只使用串口轮训发送和接收数据。 所有与硬件相关的必要操作全部由回调函数显示。 kptl 和 mcuboot 本身没有任何硬件依赖。非常容易移植到任何ARM Cortex MCU上。kptl和mcuboot写的很小白,有C基础的都可以看的明白,容易改。   Products Product Category NXP Part Number URL MCU MK64FN1M K64_120: Kinetis® K64-120 MHz  MCU MKE02Z64 KE02_40: Kinetis® KE02-40 MHz  MCU MKE15Z256 KE1xZ: up to 72MHz, 5V main stream CM0+ MCU  MCU LPC802/804 LPC80X: Low-Cost Microcontrollers M0+    Tools NXP Development Board URL FRDM-K64F FRDM-K64F: Freedom Development Platform for Kinetis® K64, K63, and K24 MCUs  FRDM-KE02Z40M FRDM-KE02Z40M: Freedom Development Platform for Kinetis KE02 MCUs  FRDM-KE15Z FRDM-KE15Z: Freedom Development Platform for Kinetis® KE1xMCUs  LPCXpresso802 LPCXpresso802 for the LPC802 family of MCUs LPCXpresso804 LPCXpresso804 for the LPC804 family of MCUs   
查看全文
       该软件包为RT-Thread RTOS配套的BSP板级支持包,默认支持官方开发板MIMXRT1020-EVK,用户可以针对该BSP移植到自己的prototype上面,当前RT1020_EVK板级包在RT-Thread v3.1.3版本编译通过并运行测试成功。使用时,需要将附件源码解压后拷贝到\rt-thread\bsp\imxrt路径下。 Products Product Category NXP Part Number URL MCU MIMXRT1021 i.MX RT1020 Crossover MCU with Arm® Cortex®-M7 core    Tools NXP Development Board URL i.MX RT1020 Evaluation Kit MIMXRT1020-EVK: i.MX RT1020 Evaluation Kit    SDK SDK Version URL RT-Thread_v3.1.3 https://github.com/RT-Thread/rt-thread/tree/v3.1.3  SDK_v2.6.1 mcuxpresso.nxp.com  
查看全文
   JN-5189T内置NTAG32211标签,完全符合NFC Forum类型2标签和ISO/IEC14443类型A规范。可以实现ZigBee简单入网配对、设备识别等功能。    为了将NFC驱动集成到JN-AN1242-CMET中,参考下面的步骤修改JN-AN1242-CMET工程代码。 Products Product Category NXP Part Number URL MCU JN5189 JN5189/88 (T): High Performance and Ultra-low power MCUs for Zigbee®   Tools NXP Development Board URL JN5189 Evaluation Kit for ZigBee and Thread mesh network with NFC Commissioning Advanced Development Kit for JN5189/88   SDK Development Software and ANs URL MCUXpresso SDK Software Welcome | MCUXpresso SDK Builder  Application Note Zigbee 3.0 IoT Control Bridge   CMET Tools JN-AN-1242 - CMET    
查看全文
  JN-5189 SoC的多功能Timer外设支持Pulse Counter脉冲计数功能。可以参考附件文档实现这个功能。 Products Product Category NXP Part Number URL MCU JN5189 JN5189/88 (T): High Performance and Ultra-low power MCUs for Zigbee®   Tools NXP Development Board URL JN5189 Evaluation Kit for ZigBee and Thread mesh network with NFC Commissioning Advanced Development Kit for JN5189/88   SDK Development Software and ANs URL MCUXpresso SDK Software Welcome | MCUXpresso SDK Builder  Application Note Zigbee 3.0 IoT Control Bridge    
查看全文
   JN-5189 SoC支持二个UART串口。在NXP提供的AN参考设计中,默认使用UART0串口。例程JN-AN-1247 ZigbeeNodeControlBridge应用中,UART0已经用于SerialLink串口通信协议。为了方便调试代码,我们可以使能UART1作为调试打印输出串口。  Products Product Category NXP Part Number URL MCU JN5189 JN5189/88 (T): High Performance and Ultra-low power MCUs for Zigbee®   Tools NXP Development Board URL JN5189 Evaluation Kit for ZigBee and Thread mesh network with NFC Commissioning Advanced Development Kit for JN5189/88   SDK Development Software and ANs URL MCUXpresso SDK Software Welcome | MCUXpresso SDK Builder  Application Note Zigbee 3.0 IoT Control Bridge    
查看全文
A reference design using DMA to scan ADC0 and ADC1 channels within FreeRTOS task, trigger interrupt when one scan completes. Hardware FRDM-K22F (https://www.nxp.com/design/development-boards/freedom-development-boards/mcu-boards/nxp-freedom-development-platform-for-kinetis-k22-mcus:FRDM-K22F). IDE IAR8.4.2. SDK The code is based on SDK2.2 (or later version) which can be built and downloaded on nxp website https://MCUXpresso.nxp.com  Function Description K22F MCU support 2 ADC modules, they are configured to do ADC channel scanning at same time. The ADC channels are defined in ADC0_Channel_List and ADC1_Channel_List, and the ADC conversion result will be saved in ADC0_Result and ADC1_Result. DMA and DMA MUX are configured to load the ADC channels and save the ADC conversion result. The DMA interrupt will be triggered when the scanning is completed. The ADC scanning is re-started when current loop is completed. Customer can processing the ADC result. To demonstrate multi-tasks, there are the other two tasks was implemented: I2C task and UART2 task.  The sensor on the FRDM-K22F board will be read in I2C task. Uart2 task recieve the data from UART2 and send the data back. Running the Demo ============================================================ 1) Open the IAR project 2) Build the project and download the code to FRDM-K22F board 3) Running the code 4) Add the arrary ADC0_result, and ADC1_Result to living watch window, the ADC result data will be refreshed. Note: Some ADC inputs are floating, so the conversion result may have great changes. 5) Open the terminal, open the serial port, and configure it with 115200/8bit/1 stop bit, the senor data will be printed in the terminal window
查看全文
NFC Tandem offers best of both worlds: An NFC reader and a passive connected tag sharing one antenna. A user can interact with the device when it is powered off (through the NTAG I²C plus); when the device is powered, it can interact with cards, P2P devices or other connected tags.                                                             NFC Tandem Uses Cases and Applications: One-touch pairing WiFi with phone, or card Bluetooth with phone, headset, speaker IoT network node commissioning User identification with badge or phone Authentication and configuration of consumable and accessory Zero-power parametrization Zero-power firmware update Zero-power diagnosis and maintenance NFC Tandem Demo: NFC Tandem concept is demonstrated using NFC Tandem reference board: The demo can run on either: UDOO Neo Download UDOO Neo demo image or Raspberry Pi Download Raspberry Pi demo image Video of the demo: <script src="https://players.brightcove.net/6153537070001/default_default/index.min.js"></script>(view in My Videos) NFC Tandem References: PN7150 High performance NFC controller, supporting all NFC Forum modes, with integrated firmware and NCI interface NTAG I²C plus NFC Forum Type 2 Tag with I²C interface NFC Tandem Documents: User Manual and reference schematics are attached to this document
查看全文
Near Field Communication (NFC) is already present in more than 1.5 Billion smartphones. Well-known applications like payment and access control are enabled by NFC, but also emerging and innovative use cases which are just appearing on the horizon now. This article gives you more information, background and how-to guides around our NFC demos, first exhibited at embedded world 2018 in Nürnberg - to help you put NFC Everywhere. Accessories and consumables Identifying and authenticating accessories and consumables can add significant value to a product, and for the first time we show live how this works: The demo showcases tool identification via NFC for 3 different kinds of tools: A drill bit, a standard flat-blade screwdriver and a Phillips screwdriver. Each of the tools has an embedded NTAG213 NFC tag, and the electric drill contains an NFC reader (CLRC663 plus). As soon as a tool is inserted, the main unit reads the tool type and usage (wear). Based on this information, it can reject non-genuine or worn-out tools, and adjust internal settings like max/min speed based on the tool type. The demo is based on the brand new NFC Nutshell kit by our partner GMMC, and the demo shows how easily an existing product can be retrofitted with NFC using this kit. Find a detailed description of accessory and consumable identification and authentication here: https://community.nxp.com/docs/DOC-340283 Parameterization, Diagnosis and Firmware update This demo shows how you can use an NFC phone to parameterize/configure a DIN rail module (or any other piece of electronics) with an NFC phone - even if the module is completely unpowered. The smart phone app lets you set the behavior of the lamps and also the language of the display. After the configuration (a simple tap) you switch on the main power, and the device comes up as configured. And NFC also lets you read out diagnostic data - no matter whether the device is powered on or off. So you can even replace your service UART by NFC. Thirdly, the demo shows how easy it is to even flash your firmware via NFC. Again, this works even when the device is switched off. This application is based on the NTAG I²C plus passive connected tag IC.   Find a detailed description and all source codes here: https://community.nxp.com/docs/DOC-333834. Interested how this looks like in a commercial product? Watch this video showing how easily the Schneider Zelio NFC Timer Relay can be configured via NFC. Access Management In the Access Management corner, we demonstrate the ultimate contactless connectivity for residential or hospitality applications through NXP NFC and BLE solutions and a superior contactless experience and security with MIFARE ® DESFire ® credential on cards, mobile devices and wearables. Our demonstrator is based on the PN7462 family, the all-in-one full NFC controller, the QN9021, a low power BLE system-on-chip, and the PCF8883T, capacitive proximity switch with auto-calibration, for very low power consumption. We also show two commercial products by our partners: 1) The Salto XS4 range of smart doorlocks, a simple to use and very efficient access control system. 2) A modular access control solution by Kronegger, using their tiny NFC reader boards. We also reveal a very small footprint complete reader board based on the new BGA package (VFBGA64; 4.5x4.5 mm²) for the PN7462 family complementing the existing HVQFN64 package.   NFC Tandem - The Best Of Two Worlds If you need NFC functionality both in powered and unpowered state, have a look at the NFC Tandem demo: An NFC reader (PN7150) and a passive connected NFC tag (NTAG I²C plus) sharing one antenna. A user can interact with the device when it is powered off (through the NTAG I²C plus); when the device is powered, it can read cards, tags or other connected tags. Find design files, a user manual and further downloads here: https://community.nxp.com/docs/DOC-340244 Single-Chip Integrated Solution: LPC8N04 MCU with passive NFC interface In this demo, we show our latest integrated NFC solution, the LPC8N04, a cost-effective MCU with integrated (passive) NFC connectivity. This MCU offers multiple features, including several power-down modes and a selectable CPU frequency of up to 8 MHz for ultra-low power consumption. The demo showcases its features in a conceptual clock format: - Easily set current time/date of the clock via an NFC phone - Real-time clock with optional alarm, programmed and controlled using an Android app - GPIO controlled bar graph indicating programmable "safe operating range" - I2C controlled OLED user display - Data (temperature) logging, configured using an Android App To learn more about this device, please visit: www.nxp.com/LPC8N04 Single-Chip Integrated Solution: NTAG SmartSensor NTAG SmartSensor allows consumers and brand owners to confirm that temperature sensitive products – like fish, wine or pharmaceuticals – have been properly handled. The NTAG SmartSensor allows for temperature sensing at the item level, so each individual product can be confirmed as safe to use. And a single tap with your NFC smartphone is all that's needed to read out the temperature history of the NTAG SmartSensor. Learn more about NTAG SmartSensor on our webpage or watch the video. If you are looking for a ready-made logger using the NTAG SmartSensor, here is a list of manufacturers offering NTAG SmartSensor based loggers. Electronic Shelf Labels With NFC-enabled Electronic Shelf Labels (ESL), wrong price indication, non-transparent processes, and unsatisfactory customer interactions are a thing of the past. In this demo we show labels from 2 manufacturers, one commercial electronic shelf label from SES Imagotag and one ePaper label from MpicoSys. Find more information in the article by Fabrice Punch, Senior Marketing Manager at NXP. Why NFC on ePaper label? NFC allows for creating a product with no batteries, so no recharging, and labels can be in constant use  No cables and connectors - labels can be fully sealed and made waterproof NFC is a well-proven and widely-supported standard  Allows for easy integration with both PC and smartphones    Applications for PicoLabel - MpicoSys ePaper labels Logistic labels (warehousing, supply chain management)  ID Badges (show image on employee, visitor and conference badges)  Authentication badges (identity, authentication, cryptographic security) Door signage (shared offices, conference centers) Manufacturing (replacing paper labels) NFC Cube The NFC Cube is the universal demo for NFC applications: It shows communication between a device and a card/tag, between a device and a phone, and between two devices. It uses the PN7462AU single-chip NFC controller with integrated Cortex M0 core. The NFC Cube kit is interoperable with our NTAG I 2 C plus Explorer board, which enables you to demonstrate how 2 devices can communicate via NFC. NFC Portfolio and Package Options Find here an overview of the package options of our NFC reader and connected tag ICs. Our Partners In The NFC Everywhere Demonstrator We would like to extend a special thanks to our partners who contributed to this demonstrator: Lab ID: NFC/RFID cards, tickets, labels and inlays Kronegger: Demo on logical access control, NFC reader modules and customized solutions Salto: Smart door lock demo GMMC: NFC Nutshell Kit for easy demonstration, retrofitting and development of small NFC reader solutions SES Imagotag: Commercial electronic shelf label with customer interaction via NFC MpicoSys: Commercial PicoLabel based on ePaper and content update via NFC Find out more Discover NFC Everywhere: https://www.nxp.com/nfc All about MIFARE: https://www.mifare.net Get your technical NFC questions answered: https://community.nxp.com/community/identification-security/nfc List of Approved Engineering Consultants (AEC) for NFC: https://nxp.surl.ms/NFC_AEC NFC Everywhere Brochure: https://www.nxp.com/docs/en/brochure/NFC-EVERYWHERE-BR.pdf 
查看全文
Teensy Prop Shield : Motion activated Light This demo shows a basic gesture controlled light sequence using NXP motion sensors available in the Teensy Prop Shield LED lights can be found on the following link: https://www.adafruit.com/product/2238 <script src="https://players.brightcove.net/6153537070001/default_default/index.min.js"></script>(view in My Videos) Features The Teensy Prop Shield is an add-on sensor shield board for the Teensy 3.1 which is an USB based microcontroller development platform. The Teensy 3.1 has a 32 bit ARM Cortex M4 processor from NXP -MK20DX256. The board can be programmed using Arduino IDE + Teensyduino plugin. The prop shield consists of the following devices: Motion Sensors - Allows motion interactive light & sound. Audio Amplifier - Clear quality audio output to a small speaker. Fast LED Driver - Drive APA102 / Dotstar LEDs for colorful lighting with rapid response. Flash Memory - 8 Mbyte storage for images, sound clips, and data logging\ Featured NXP products FXOS8700CQ - 6 Axis Linear Accelerometer & Magnetometer FXAS21002C   - 3 Axis Digital Angular Rate Gyroscope MPL3115A2     - Precision Pressure/Altitude & Temperature sensor MK20DX256   - 32 bit ARM Cortex M4 processor Demo Setup: Wiring[1] : Software: After setup, Download Arduino IDE and Teensyduino add on and follow the instructions as defined in the page below http://www.pjrc.com/teensy/td_download.html Note: Arduino version used for this demo:  1.6.8. Run the “Teensy_RGB_Led_Strip.ino” sketch attached. Sample Code: // Full orientation sensing using NXP's advanced sensor fusion algorithm.  //  // You *must* perform a magnetic calibration before this code will work.  //  // To view this data, use the Arduino Serial Monitor to watch the  // scrolling angles, or run the OrientationVisualiser example in Processing.      #include <NXPMotionSense.h>  #include <Wire.h>  #include <EEPROM.h>  #include <FastLED.h>      #define NUM_LEDS 60  CRGB leds[NUM_LEDS];      NXPMotionSense imu;  NXPSensorFusion filter;  int a;  int acc_rms;  void setup() {    Serial.begin(9600);    imu.begin();    filter.begin(100);    delay(2000);         FastLED.addLeds<APA102,11,13,BGR,DATA_RATE_MHZ(1)>(leds, NUM_LEDS);     pinMode(7, OUTPUT);    digitalWrite(7, HIGH);  // enable access to LEDs  }      void loop() {    float ax, ay, az;    float gx, gy, gz;    float mx, my, mz;    float roll, pitch, heading;        if (imu.available()) {      // Read the motion sensors      imu.readMotionSensor(ax, ay, az, gx, gy, gz, mx, my, mz);          // Update the SensorFusion filter      filter.update(gx, gy, gz, ax, ay, az, mx, my, mz);          // print the heading, pitch and roll      roll = filter.getRoll();      pitch = filter.getPitch();      heading = filter.getYaw();      Serial.print("Orientation: ");      Serial.print(heading);      Serial.print(" ");      Serial.print(pitch);      Serial.print(" ");      Serial.println(roll);      a=abs(roll/3);      Serial.print(" ");            acc_rms=sqrt(ax*ax+ay*ay+az*az)/3;      Serial.println(acc_rms);            //flash red if a violent shake event is detected            if(acc_rms==1)      {         for(int n = 0; n < NUM_LEDS; n++)          {             leds[n] = CRGB::Red;             FastLED.show();             delay(8);             leds[n] = CRGB::Black;        }      }            // Move a single white led as per rotation      for(int n = 0; n < NUM_LEDS; n++)       {         if(a==n)         {            leds[n] = CRGB::White;            FastLED.show();            delay(8);          }         else          {             leds[n] = CRGB::Black;          }      }    }  } PJRC Store Sample Code: // Full orientation sensing using NXP's advanced sensor fusion algorithm.  //  // You *must* perform a magnetic calibration before this code will work.  //  // To view this data, use the Arduino Serial Monitor to watch the  // scrolling angles, or run the OrientationVisualiser example in Processing.      #include <NXPMotionSense.h>  #include <Wire.h>  #include <EEPROM.h>  #include <FastLED.h>      #define NUM_LEDS 60  CRGB leds[NUM_LEDS];      NXPMotionSense imu;  NXPSensorFusion filter;  int a;  int acc_rms;  void setup() {    Serial.begin(9600);    imu.begin();    filter.begin(100);    delay(2000);         FastLED.addLeds<APA102,11,13,BGR,DATA_RATE_MHZ(1)>(leds, NUM_LEDS);     pinMode(7, OUTPUT);    digitalWrite(7, HIGH);  // enable access to LEDs  }      void loop() {    float ax, ay, az;    float gx, gy, gz;    float mx, my, mz;    float roll, pitch, heading;        if (imu.available()) {      // Read the motion sensors      imu.readMotionSensor(ax, ay, az, gx, gy, gz, mx, my, mz);          // Update the SensorFusion filter      filter.update(gx, gy, gz, ax, ay, az, mx, my, mz);          // print the heading, pitch and roll      roll = filter.getRoll();      pitch = filter.getPitch();      heading = filter.getYaw();      Serial.print("Orientation: ");      Serial.print(heading);      Serial.print(" ");       Serial.print(pitch);      Serial.print(" ");      Serial.println(roll);      a=abs(roll/3);      Serial.print(" ");            acc_rms=sqrt(ax*ax+ay*ay+az*az)/3;      Serial.println(acc_rms);            //flash red if a violent shake event is detected            if(acc_rms==1)      {         for(int n = 0; n < NUM_LEDS; n++)          {             leds[n] = CRGB::Red;             FastLED.show();             delay(8);             leds[n] = CRGB::Black;        }      }            // Move a single white led as per rotation      for(int n = 0; n < NUM_LEDS; n++)       {         if(a==n)         {            leds[n] = CRGB::White;            FastLED.show();            delay(8);          }         else          {             leds[n] = CRGB::Black;          }      }        }  }
查看全文
  Introduction   In this document, we are focusing on the usage of two functions of FreeRTOS: Creation of tasks and the use of queues as a way to trigger a generic functionality in our application. NXP’s SDK abstraction layer for the QN908x is intended to give the customer a simpler way of FreeRTOS usage and control functionalities. Hardware Requirements: QN9080DK Software Requirements: MCUXpresso IDE v11.1.0 or newer QN908XCDK SDK with BLE stack and examples (It can be downloaded from the SDK Builder) This document is based on the Wireless UART example from the SDK. Setting up the required variables and definitions Import the FreeRTOS version of the wireless_uart example included in the QN9080’s SDK.   Note: Be sure to select UART as your debug console.    2. In order to change the default role of the QN9080 board it is required to change the definition of the mGapRole variable, from gGapCentral_c to gGapPeripheral_c in PROJECT_FILE_NAME > source > wireless_uart.c > BleApp_Config(). //wireless_uart.c //static void BleApp_Config(void) { /* By default, always start node as GAP central */ //mGapRole = gGapCentral_c; mGapRole = gGapPeripheral_c; (void)Serial_Print(gAppSerMgrIf, "\n\rWireless UART starting as GAP Peripheral, press the role switch to change it.\n\r", gAllowToBlock_d); mAdvState.advOn = TRUE; mScanningOn = FALSE; //...}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍    3. It is important to change the macro value of: osNumberOfMessageQs in PROJECT_FILE_NAME > framework > OSAbstracion > Interface > fsl_os_abstraction_config.h to a value > 0.  //fsl_os_abstraction_config.h #ifndef osNumberOfMutexes #define osNumberOfMutexes 5 #endif #ifndef osNumberOfMessageQs #define osNumberOfMessageQs 1 #endif #ifndef osNumberOfMessages #define osNumberOfMessages 10 #endif‍‍‍‍‍‍‍‍‍ //...‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Then, to start the task implementation it is needed to edit the file: PROJECT_FILE_NAME > framework > OSAbstracion > Source > fsl_os_abstraction_free_rtos.c.        First, we create the prototype of the main task function, then define the task using the “OSA_TASK_DEFINE” definition. The syntax should be the following: This function is part of the thread Management, it helps the user define the creation of a new thread, controlling the priority and stack requirements. The following parameters are used in the function definition. name: Should be the name of the function used as our task priority: The scheduler will grant a minor or major priority to our function with this parameter. instances: This parameter give us the control to limit the number of instances in order to manage the memory in the most optimal way. stackSz : This parameter has a default value, which is defined by the abstraction layer as: gMainThreadStackSize_c as 1024 bytes. useFloat : This parameter is part of the thread definition structure, is a Boolean, It defines if the thread will use floating point.   //fsl_os_abstraction_free_rtos.c /*! ********************************************************************************* ************************************************************************************* * Private functions ************************************************************************************* ********************************************************************************** */ OSA_TASK_DEFINE(startup_task, gMainThreadPriority_c, 1, gMainThreadStackSize_c, 0) ; void vfnTaskPWM(void* param); //New Task Definition OSA_TASK_DEFINE(vfnTaskPWM, 1, 1, 500, FALSE ); osaTaskId_t gAppTestTask1Id = 0; // TestTask1 Id osaTaskId_t pwmTask_queue = 0; //get defines from wireless_uart int main (void) { /* Initialize MCU clock */ hardware_init(); OSA_TaskCreate(OSA_TASK(startup_task), NULL); //Task and Queue creation. gAppTestTask1Id = OSA_TaskCreate(OSA_TASK(vfnTaskPWM), NULL); //Task Creation pwmTask_queue = OSA_MsgQCreate(1); //Scheduler starting vTaskStartScheduler(); return 0; } //..‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   4. The function: OSA_TaskCreate returns a taskID it is required to create a osaTaskId_t variable as the following: osaTaskId_t gAppTestTask1Id = 0; and also another osaTaskId_t variable for the FreeRTOS queue we will be using : osaTaskId_t pwmTask_queue = 0.‍‍‍‍‍‍‍ 5. Inside the main function we will create our task in the same fashion the startup_task is created: gAppTestTask1Id = OSA_TaskCreate(OSA_TASK(vfnTaskPWM), NULL);‍‍‍‍‍‍‍ 6. We also need to create the queue using the same type of variable and using the OSA_MsgQCreate() function to create a new Queue: pwmTask_queue = OSA_MsgQCreate(1);‍‍‍‍‍‍‍ 7. After this statements the scheduler should start: vTaskStartScheduler(); 8. In the wireless_uart.c file it is required to add pwmTask_queue, created for the queue as an extern variable. //wireless_uart.c static uint8_t gAppSerMgrIf; static uint16_t mAppUartBufferSize = mAppUartBufferSize_c; static volatile bool_t mAppUartNewLine = FALSE; static volatile bool_t mAppDapaPending = FALSE; extern osaMsgQId_t pwmTask_queue; /************************************************************************************ ************************************************************************************* * Private functions prototypes ************************************************************************************* ************************************************************************************/ /* Gatt and Att callbacks */ static void BleApp_AdvertisingCallback(gapAdvertisingEvent_t *pAdvertisingEvent);‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Tasks and Queues implementation in our application code In this example we implemented the use of OSA_MsgQPut() to place the message received from the central peripheral in a queue by using: //wireles_uart.c static void BleApp_ReceivedUartStream(deviceId_t peerDeviceId, uint8_t *pStream, uint16_t streamLength) { static deviceId_t previousDeviceId = gInvalidDeviceId_c; char additionalInfoBuff[10] = { '\r', '\n', '[', '0', '0', '-', 'M', ']', ':', ' '}; uint8_t *pBuffer = NULL; uint32_t messageHeaderSize = 0; if (mAppUartNewLine || (previousDeviceId != peerDeviceId)) { streamLength += (uint32_t)sizeof(additionalInfoBuff); } /* Allocate buffer for asynchronous write */ pBuffer = MEM_BufferAlloc(streamLength); if (pBuffer != NULL) { /* if this is a message from a previous device, print device ID */ if (mAppUartNewLine || (previousDeviceId != peerDeviceId)) { messageHeaderSize = sizeof(additionalInfoBuff); if (mAppUartNewLine) { mAppUartNewLine = FALSE; } additionalInfoBuff[3] = '0' + (peerDeviceId / 10U); additionalInfoBuff[4] = '0' + (peerDeviceId % 10U); if (gGapCentral_c != maPeerInformation[peerDeviceId].gapRole) { additionalInfoBuff[6] = 'S'; } FLib_MemCpy(pBuffer, additionalInfoBuff, sizeof(additionalInfoBuff)); } FLib_MemCpy(pBuffer + messageHeaderSize, pStream, (uint32_t)streamLength - messageHeaderSize); /**** Adding a message into a Queue ****/ OSA_MsgQPut(pwmTask_queue, (void*)&pBuffer); /**************************************/ (void)Serial_AsyncWrite(gAppSerMgrIf, pBuffer, streamLength, Uart_TxCallBack, pBuffer); } /* update the previous device ID */ previousDeviceId = peerDeviceId; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This function points to the external queue variable created before the main() function of the project. Also points to the buffer pointer of the message received in BleApp_ReceivedUartStream(), These parameters can be accessed by using OSA_MsgQGet() function. osaStatus_t OSA_MsgQGet(osaMsgQId_t msgQId, void *pMessage, uint32_t millisec)‍‍ This function gets the message from the head of the message queue, the parameters of this function are the following: msgQId : Is the identifier of the queue function. pMessage : Is a pointer to the same message sent fromOSA_MsgQPut(); millisec : Is the number of milliseconds to wait for a message.   Inside the task created: vfnTaskPWM() there is an infinite while loop checking if a message is in the queue, this is accomplished by using the os_abstraction function: The rest of the task implementation is in a different C file. The external queue variable is defined in this file in addition to the task function prototype: /*pwmApplication.c*/ /*Global Variables*/ static uint8_t gAppSerMgrIf; extern osaMsgQId_t pwmTask_queue; /*Function Prototypes*/ void signalConfigValues(int red, int green, int blue); void getValuesRGB(uint8_t* msgString); int getInt(char *stringInteger, int size); /****Task Definition****/ void vfnTaskPWM(void* param); /* * Task to configure the PWM pins and start the timer * */ void vfnTaskPWM(void* param) { uint8_t* msgString; char msgString1[20] = { '\0', '\0', '\0', '\0','\0', '\0', '\0', '\0','\0', '\0', '\0', '\0','\0', '\0', '\0', '\0','\0', '\0', '\0', '\0'}; while(1) { /* * If there is a new message on queue the value will return a 0 according to the OSA_MsgQGet function * to compare the incoming message * */ while((OSA_MsgQGet(pwmTask_queue,(void*)&msgString,10)) == 0){ //shift-up the pointer value to get the payload message if(*msgString == '\r'){ while(*msgString != 32){ msgString++; } msgString++; } FLib_MemCpy(msgString1,msgString,20); if(FLib_MemCmp(msgString1, "OFF", 4)){ (void)Serial_Print(gAppSerMgrIf,"\n\r OFF: ", gAllowToBlock_d); //configure the PWM new function signalConfigValues(0,0,0) and StartTimers(CTMRA,CTMRB) signalConfigValues(0,0,0); } else{ //a function to convert values from a string to integers getValuesRGB(msgString); } } } } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
查看全文
Littlevgl is a very good lightweight GUI software, which is convenient to use in MCU environment. This document describes how to port in I.MXRT environment, and how to modify LCD resolution and memory size in current SDK.
查看全文
A user's guide introducing how to use windowed aatchdog timer in JN5189. 文档介绍了如何在JN5189中使用 WDT窗口看门狗。
查看全文
      虽然目前NXP的很多MCU都带了丰富的UART资源,但是在某些特地的情况下或个别芯片,UART数量还是有一定的局限性。现在NXP很多的MCU也携带有FlexIO模块,那么我们就可以利用FlexIO来扩展更多的UART,SDK中有相应的代码,这些代码是支持全双工的,需要使用至少两个timer和两个shifter设计一个UART, 在实际使用中很多时候是使用半双工通信的,本文是基于SDK FlexIO的例程来设计基于一个timer和一个shifter的半双工UART,最大限度扩展UART数量,设计4个半双工的UART,本文设计验证平台为FRDEM-KE15Z和SDK_2.6.0_MKE15Z256xxx7。     希望能给需要的使用者提供种扩展尽可能多UART的方法。 Best Regards, Fred Fu
查看全文
In BLE spec there is no standard wireless pass through profile, so different chip vendors have their own implementations, which is also called Proprietary Profile, the compatibility is a big challenge. There are two wireless pass through demos in NXP BLE demos. For QN90XX chip, it’s called QPP. For KW3X, it’s called wireless UART. The wireless UART is more complex. It doesn’t support always-connection and have many limitations for the app. The common BLE debug tool app on phone side cannot communicate with it, while the QPP can work well.  This demo code is target to port the QPP profile to KW3X SDK, which can simplify user’s development.
查看全文
Overview The 3-phase PMSM Vector Control using Quadrature Encoder on based on Kinetis® K40 MCUs reference design demonstrates the ability of the Kinetis K40 Arm® Cortex®-M4 MCU to drive the advanced motor control application. Targeted at the NXP® Tower® rapid prototyping system as a hardware development platform. Together with available embedded source code, you can quickly build own industrial drive application. For the successful execution of the vector control algorithm, the information on the motor shaft position is critical. The quadrature encoder position information is known in the entire motor speed range, allowing the motor start with full torque at zero speed. Features Vector control of the PMSM using the quadrature encoder as a position sensor Targeted at the Tower ®  rapid prototyping system (K40 tower board, Tower 3-phase low voltage power stage) Vector control with a speed closed loop Rotation in both directions Application speed range from 0% to 100% of nominal speed (no field weakening) Operation via the user buttons on the Kinetis ®  K40 Tower board or via FreeMASTER software Block Diagram Design Resources
查看全文
Overview The LCD reference design is developed using the Kinetis KL28Z through the standalone peripheral module FlexIO. The polling method is used to copy data from SRAM or flash to FlexIO's shifter buffer. Image Kinetis board is powered by an Arm ®  Cortex ® -M0, providing up to 96 MHz CPU performance besides supporting ultra-low power. KL28Z's FlexIO emulates 8080 interface, and drives a 320x240 TFT LCD module. DAM or displaying applications, such as HMI, can be built based on this demo. The refresh rate is up to 128 fps with 16-bit width data bus and 48MHz core clock. Features Features the Kinetis KL2828Z512 Board, the interaction between a LCD display by FlexIO, a highly configurable module capable of emulating a wide range of different communication protocols. The important feature of this peripheral is that it enables the user to build their own peripheral directly in the MCU. Developed using Kinetis Software Development Kit (SDK), comprehensive software support for Kinetis MCUs and drivers for each MCU peripheral, middleware, real-time OS and example applications designed to simplify and accelerate application development on Kinetis MCUs. Block Diagram Board Design Resources
查看全文
Overview The Bluetooth® Low Energy heart rate monitor reference design demonstrates the implementation of a wireless electrocardiogram (ECG) acquisition system. It features the Kinetis® KW40Z system on chip (SoC) which includes an Arm® Cortex® M0+ processor together with a 2.4 GHz radio for Bluetooth Low Energy and 802.15.4. The ECG signal is obtained from the finger tips and processed by the Kinetis KW40Z SoC. Then, the user’s heart rate is calculated and transmitted to a smartphone application using Bluetooth Low Energy. The reference design can be powered by a Li-Ion coin-cell battery. Due to the low-power features of Kinetis KW40Z MCU, a 3.6V 200mA/h Li-Ion coin-cell rechargeable battery can provide the power of up to 40 hours of continuous use. The NXP® MC34671 is in used as a battery charger solution for the device. Features Includes the NXP ®  ultra-low-power Kinetis ®  KW40Z SoC Bluetooth Low Energy/ZigBee platform. The low-power features of this solution allow up to 40 hours of continuous operation using a small coin-cell battery. Fully compliant Bluetooth v4.1 Low Energy Differential input/output port used with external balun for single port operation Block Diagram Board Design Resources
查看全文
Overview NXP® and Tongji University jointly developed the anti-pinch window lift reference design featuring the MagniV® S12VR MCU, ideal for the development of power windows and sun roof systems. Includes hardware for real door/window in-vehicle applications, as well as software including anti-pinch algorithms and low-level S12VR drivers Aimed at reducing time to market, this design leverages unique features of the MagniV S12VR MCU Reduces unnecessary external components, lowers the total bill of material (BOM), improves system quality and saves space in automotive applications through a smaller PCB Features Window manual/automatic up/down, automatic up/down with stop function Anti-pinch in both manual/automatic mode, anti-pinch region and force can be adjusted Stuck detection out of anti-pinch region, motor overload protection Soft stop when window is close to the top/bottom Fault diagnosis, indicating low voltage, over voltage/current/temperature etc. Low power mode (leveraging S12VR low power mode) to reduce power consumption Self learning, calibration by updating the window/motor parameters stored in EEPROM Use hall sensor as well as current sense to judge anti-pinch in algorithm Easy-to-control Graphics User Interface (GUI), set the parameters and get the status Window lift can be controlled either by multiple LIN salve nodes or LIN master node (through GUI) Able to comply with relevant content in US Federal Motor Vehicle Safety Standard (FMVSS No. 118) Block Diagram Design Resources
查看全文