下面简单介绍下Kinetis M0+相关的几大系列MCU: 1. Kinetis L    Kinetis L系列MCU的最大特点是它具有非常出色的低功耗特性，L系列目前包含KL0X、KL1X、KL2X、KL3X、KL4X和KL8X六个子系列，除了KL8X的主频为72 Mhz以外，其他主频都为48 Mhz。KL0X系列是入门级MCU，它的Flash相对较小，引脚数量相对较少。KL1X系列是通用型MCU，KL2X系列带有USB功能，KL3X系列支持段式LCD，KL4X系列同时带有USB和支持段式LCD。KL8X系列具有很多Security相关的特性，包括篡改检测、真正的随机数生成器和低功耗可信加密引擎，支持AES、DES、3DES、SHA、RSA和ECC。 2. Kinetis E    Kinetis E系列MCU的最大优势是电磁抗噪性能，Kinetis E系列是业界首款在Cortex M0+基础上构建5V (2.7~5.5V)MCU系统的产品，结合了低成本、高性能、先进的EMC和ESD保护功能，E系列目前包括KE02、KE04和KE06三个子系列，KE02主频有20M和40M两种，KE04和KE06都为48M，KE06相比KE02和KE04主要是多了1个CAN接口。 3. Kinetis V    Kinetis V系列MCU专为BLDC、PMSM和ACIM电机控制以及数字电源转换应用而设计。V系列目前包含KV1X、KV3X、KV4X和KV5X四 个系列，其中Kinetis KV1X系列是入门级产品，Cortex-M0+内核，采用75 MHz M0+内核及硬件平方根和除法模块，与同等级32位MCU相比，在无传感器PMSM控制应用中的性能提高27%。 4. Kinetis W Kinetis W系列集成了领先的Sub-GHz和2.4 GHz射频收发器，可创建可靠、安全、低功耗的嵌入式无线解决方案。W系列目前包含KW0X、KW2X 、KW3X和KW4X四个系列，其中KW0X是M0+内核，48 Mhz，Sub-GHz无线电，超低功耗无线微控制器，KW3X是M0+内核，48 Mhz，具备Bluetooth® Smart/Bluetooth® Low Energy (BLE) v4.1射频连接。KW4X也是M0+内核，具备Bluetooth® Smart/Bluetooth® Low Energy (BLE) v4.1和IEEE® 802.15.4-2011射频连接。 5. Kinetis M      Kinetis M系列 MCU适用于单芯片1、2和3相电表和流量计，以及其它高精度测量应用。M系列目前包括KM1X、KM2X两个系列，KM1X主要用作计量，KM3X不仅具有计量功能，同时还有段式LCD控制器。 选型的方法主要有以下几种： 1）如果您已经知道要查找的产品的基本信息,最常用的方法是在飞思卡尔官网主页进行查找； 2）如果您并不清楚需要查找的芯片基本信息，飞思卡尔还提供了一些辅助的选型工具来帮助用户进行芯片的选型，包括：i）参数选型工具;   ii）选型神器Cross Check;  iii）解决方案顾问; 具体的选型操作流程可以参考:针对飞思卡尔单片机的快速上手指南中的2.2小节，其中有非常详细的介绍。

What's eCos eCos is a free open source real-time operating system intended for embedded applications. The highly configurable nature of eCos allows the operating system to be customised to precise application requirements, delivering the best possible run-time performance and an optimised hardware resource footprint. With provided configuration tools (configtool and ecosconfig) it is possible to build configurations that scale from minimal that require less than 32KiB memory to reach full featured operating system with networking, file system, serial communication, etc. eCos for Kinetis Currently the Kinetis eCos support includes: UART; Ethernet - with TCP/IP through either lwIP or BSD stack; Flash - program and erase; eDMA library; DSPI - including MMC/SD card support; Real Time Clock. Cache; DDRAM; FlexBus; Following features are available for testing: I2C; CAN; Watchdog. Configuring eCos for Kinetis Start the graphical configuration tool configtool, then from menu select Build->Templates. In Hardware selection box select your board: In our case we select TWR-K70F120M. Save the configuration and select Build->Library. configtool will build a customised eCos library and extract headers for you. Now you are ready for your "Hello world". Further reading You shall find complete eCos documentation at eCos Documentation

The documentation points out that the Figure 32-1. Multipurpose Clock Generator (MCG) block diagram in KV5xP144M240RM.pdf is incorrect, the  /2 divider is NOT included in the feedback loop. It gives the formula to compute the VCO and MCGPLLCLK clock frequency and corresponding code.

     我想“超频”这个词估计大家都不会陌生，很多玩计算机的都会尝试去把自己电脑的CPU超频玩一些高端大型游戏（咳咳，当然玩的high的时候别忘了小心你的主板别烧了），而对我们这些搞嵌入式的人们来说，估计就只能用这样的情怀去折磨MCU了（当然前提得是有PLL或者FLL的MCU）。      在超频之前首先需要澄清几个概念，我们通常所说的主频一般是指内核时钟或者系统时钟（即core_clk或system_clk）。而对K60来说，其内部还有总线时钟（Bus_clk）、外部总线时钟（FlexBus_clk）、flash时钟（Flash_clk），而这几个时钟互相关联且每个都是有其频率限制的（如下图1所示），所以当我们要超频内核时钟的时候还不得不考虑其他时钟承受极限（姑且用这个词吧）。在我们用MCG模块内部的PLL将输入时钟超频到200MHz作为MCGOUTCLK输出的时候还需要一道关卡（如下图2），也就是说虽然这几个时钟属于同宗（都来自MCGOUTCLK），但是也可以通过不同的分频器（OUTDIV[1:4]）约束不同的时钟范围，这里想起一个形象的例子。MCGOUTCLK就类似以前的官家大老爷，娶了四房姨太太（OUTDIV[1:4]）,分别生了四个少爷（即core_clk、Bus_clk、FlexBus_clk和Flash_clk），每个少爷都是老爷的儿子，不过在家中地位却是由姨太太的排序决定的，其中大房的大少爷（core_clk）地位最高（频率范围最大），四房的小少爷（flash_clk）地位最低（频率范围最小），不过他们的地位最高也不会超过老爷（其他clk<=MCGOUTCLK），呵呵，有点意思~ 图1 图2      经过上面的分析之后，就可以开始着手超频了。经过验证，其实系统频率超不上去就是“小少爷”（flash_clk）拖了后腿，当我们将MCGOUTCLK超到200MHz的时候，OUTDIV1的分频可以设置为1分频，保证内核频率为200MHz，但却要同时保证其他几个时钟不要超过太多，尤其是Flash_clk的限制要严格（建议不要超过30MHz，小少爷有些“娇气”），因为flash_clk过高就代表取指令的频率过高，指令出错就会造成系统程序跑飞。     说到这里，可能有些人会质疑，把主频超的那么高，但取指令的速度上不去有个啥用，岂不是颇有些大马拉小车的感觉吗，其实不然，这里我说两点。一个是通过RAM调试或者将函数声明成RAM执行函数的时候是可以加快执行速度的，另一个就是当做一些数学运算的时候作用就很明显了，因为一般可能会单纯用到CPU内部的ALU和寄存器组，后者数据访问多一些（注意Cortex-M4是哈佛结构，数据与指令总线独立的），自然其运算速度就上去了，所以还是好处多多的。      当然飞思卡尔本身是不建议超频的，数据手册上给出的极限值都是在保证系统可靠性和稳定性的前提下测试出来的，再往上就不敢保证了（跟你的硬件电路设计能力有一定关系），正所谓“超频有风险，用时需谨慎啊”，呵呵，所以我们大多数的应用还是老老实实的按照“规矩”来吧。不过这里需要提的一点是，每家厂商一般会为超频留有余地（为了满足一些客户的超频需要，哎，不容易啊），至于这个余地是多少，不同的半导体厂商也会有不同的标准。对我来说，记得那是2008年的第一场雪，比往年来的稍晚了些…（没收住，开始整词儿了，呵呵），那一年我第一次接触飞思卡尔的9S12 16位的单片机（MC9S12DG128，哎，搞过智能车的都懂的），额定主频是25MHz，我把它超到40MHz，后来又换成了MC9S12XS128，额定主频是40MHz，我又把它超到80MHz（有点超频强迫症了，呵呵），一直到如今的ARM K60，额定主频为100MHz（VLQ100），所以。。。咳咳。。。很自然的我就把它超到200MHz，再往上我就没有测试了，因为基本也用不到那么高的频率，还是要掌握好这个“度”的，想过把超频的瘾的可以试试看，呵呵~

The USB OTG module in Kinetis parts uses a Buffer Descriptor Table (BDT) in system memory to manage USB endpoint communications, the BDT is a a 512-byte buffer and there are 3 registers in USB module to contain the base address for it, and it must be 512-byte aligned otherwise there would be issue during transfer. In USB stack ver 4.1.1, some Kinetis old parts like K60N512, K20D72M have the demo project basked on CodeWarrior ARM compiler, and in khci_kinetis.c, bdt is defined as following: #define _BDT_RESERVED_SECTION_ #if(defined _BDT_RESERVED_SECTION_) #ifdef __CWCC__ #pragma define_section usb_bdt ".usb_bdt" RW __declspec(usb_bdt) uint_8_ptr bdt; but since the base address is defined as below: #define BDT_BASE               ((uint_32*)(bdt)) so the bdt definition is not correct , and we have to change it as below: #define _BDT_RESERVED_SECTION_ #if(defined _BDT_RESERVED_SECTION_) #ifdef __CWCC__ #pragma define_section usb_bdt ".usb_bdt" RW __declspec(usb_bdt) uint_8 bdt[512];//uint_8_ptr bdt; and the definition for usb_dbt section can be found in MK20X256_flash.lcf. with above modification, we can make the demo of "msd_mfs_generic" work well as expected. Please kindly refer to the following result got from TWR-K20D72M. FAT demo Waiting for USB mass storage to be attached... Mass Storage Device Attached ****************************************************************************** * FATfs DEMO * * Configuration:  LNF Enabled, Code page =1258 * ****************************************************************************** ****************************************************************************** * DRIVER OPERATION * ****************************************************************************** 1. Demo function: f_mount   Initializing logical drive 0...   Initialization complete ----------------------------------------------------------------------------- 2. Demo functions:f_getfree, f_opendir, f_readdir getting drive 0 attributes............... Logical drive 0 attributes: FAT type = FAT16 Bytes/Cluster = 2048 Number of FATs = 2 Root DIR entries = 512 Sectors/FAT = 250 Number of clusters = 63858 FAT start (lba) = 36 DIR start (lba,clustor) = 536 Data start (lba) = 568 ... 127716 KB total disk space. 127624 KB available. ----------------------------------------------------------------------------- ****************************************************************************** * DRECTORY OPERATION * ****************************************************************************** 1. Demo functions:f_opendir, f_readdir Directory listing...     ----A 2014/04/16 17:25     32253  tek00000.png     ----A 2014/04/16 17:34     31451  tek00001.png     ----A 2014/07/04 14:57     20549  tek00002.png     DR--- 2010/12/25 23:30         0 DIRECT~1     D---- 2010/01/01 00:00         0 DIRECT~2 3    File(s),     84253 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 2. Demo functions:f_mkdir 2.0. Create <Directory_1> 2.1. Create <Directory_2> 2.2. Create <Sub1> as a sub directory of <Directory_1> 2.3. Directory list Directory listing...     ----A 2014/04/16 17:25     32253  tek00000.png     ----A 2014/04/16 17:34     31451  tek00001.png     ----A 2014/07/04 14:57     20549  tek00002.png     DR--- 2010/12/25 23:30         0 DIRECT~1     D---- 2010/01/01 00:00         0 DIRECT~2 3    File(s),     84253 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 3. Demo functions:f_getcwd, f_chdir 3.0. Get the current directory     CWD: 0:/ 3.1. Change current directory to <Directory_1> 3.2. Directory listing Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     D---- 2010/01/01 00:00         0  sub1 0    File(s),         0 bytes total 3    Dir(s) 3.3. Get the current directory     CWD: 0:/Directory_1 ----------------------------------------------------------------------------- 4. Demo functions:f_stat(File status), f_chmod, f_utime 4.1. Get directory information of <Directory_1>     DR--- 2010/12/25 23:30         0 Directory_1 4.2  Change the timestamp of Directory_1 to 12.25.2010: 23h 30' 20 4.3. Set Read Only Attribute to Directory_1 4.4. Get directory information (Directory_1)     DR--- 2010/12/25 23:30         0 Directory_1 ----------------------------------------------------------------------------- 5. Demo functions:f_rename Rename <sub1> to <sub1_renamed> and move it to <Directory_2> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     D---A 2010/01/01 00:00         0 SUB1_R~1 0    File(s),         0 bytes total 3    Dir(s) ----------------------------------------------------------------------------- 6. Demo functions:f_unlink Delete Directory_1/sub1_renamed Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  .. 0    File(s),         0 bytes total 2    Dir(s) ****************************************************************************** * FILE OPERATION * ****************************************************************************** 1. Demo functions:f_open,f_write, f_printf, f_putc, f_puts, fclose 1.0. Create new file <New_File_1> (f_open)     File size =    0 1.1. Write data to <New_File_1>(f_write) 1.2. Flush cached data     File size =   52 1.3. Write data to <New_File_1> (f_printf) 1.4. Flush cached data     File size =  103 1.5. Write data to <New_File_1> (f_puts) 1.6. Flush cached data     File size =  152 1.7. Write data to <New_File_1> uses f_putc function 1.8. Flush cached data     File size =  199 1.9. Close file <New_File_1> ----------------------------------------------------------------------------- 2. Demo functions:f_open,f_read, f_seek, f_gets, f_close 2.0. Open <New_File_1> to read (f_open) 2.1. Get a string from file (f_gets)     Line 1: Write data to  file uses f_write function 2.2. Get the rest of file content (f_read)     Line 2: Write data to file uses f_printf function Line 3: Write data to file uses f_puts function Line 4: Write data to file uses f_putc functionûöF¬ â•:7Rz}™ yzjw8¸×áÀ—»ÃЭ¹òÍ­ ä‹Hïk¨Wã½c'     ²7këÞÑ%VrC×»Ô¼ÒSÈÑèR+NjD¡¾òû>ú3‰SËþo^ÎI Pë±ñ‰þ/Directory_1[1] 2.3. Close file (f_close) ----------------------------------------------------------------------------- 3. Demo functions:f_stat, f_utime, f_chmod 3.1. Get  information of <New_File_1> file (f_stat)     ----A 2010/01/01 00:00       199  New_File_1.dat 3.2  Change the timestamp of Directory_1 to 12.25.2010: 23h 30' 20 (f_utime) 3.3. Set Read Only Attribute to <New_File_1> (f_chmod) 3.4. Get directory information of <New_File_1> (f_stat)     -R--A 2010/12/25 23:30       199  New_File_1.dat 3.5. Clear Read Only Attribute of <New_File_1> (f_chmod) 3.6. Get directory information of <New_File_1>     ----A 2010/12/25 23:30       199  New_File_1.dat ----------------------------------------------------------------------------- 4. Demo functions:f_ulink Rename <New_File_1.dat> to  <File_Renamed.txt> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  ..     ----A 2010/12/25 23:30       199  FILE_R~1.TXT 1    File(s),       199 bytes total 2    Dir(s) ----------------------------------------------------------------------------- 5. Demo functions:f_truncate Truncate file <File_Renamed.txt> 5.0. Open <File_Renamed.txt> to write 5.1. Seek file pointer     Current file pointer:    0     File pointer after seeking:  102 5.2. Truncate file     File size =  102 5.3. Close file ----------------------------------------------------------------------------- 6. Demo functions:f_forward 6.0. Open <File_Renamed.txt> to read 6.1. Forward file to terminal Line 1: Write data to  file uses f_write function Line 2: Write data to file uses f_printf function 6.2. Close file ----------------------------------------------------------------------------- 7. Demo functions:f_ulink Delete <File_Renamed.txt> Directory listing...     D---- 2010/01/01 00:00         0  .     D---- 2010/01/01 00:00         0  .. 0    File(s),         0 bytes total 2    Dir(s) *------------------------------ DEMO COMPLETED    ------------------------ * ******************************************************************************

    感谢Baolei之前在weekly meeting上分享的关于在Codewarrior环境下实现printf的重定向技巧，从而在CW调试环境下的Console上实现调试信息的打印功能，我将其移植到IAR环境下并进行了测试，可以实现调试信息的交互，完全可以替代串口的功能，在这里写出来分享给大家，再次感谢baolei的分享~     通过串口打印调试信息或者实现上下位机交互是我们最常使用的调试手段之一，毕竟实现起来无论是硬件成本（接出两根线Txd和Rxd，外加一个电平转换芯片）还是软件成本（下位机写好UART驱动，上位机直接超级终端或者一些第三方串口调试助手）都是相对较低的，所以这种方式还是灰常受广大“攻城师”们欢迎的。不过如果由于I/O资源紧缺串口被用做其他用处或者板子直接没有引出串口的话（是不是产生共鸣了，呵呵），那该怎么办呢？     当然，所谓时代不同了（liao）（顺口想说“男女都一样呢”，呵呵，哎，都是生在旧社会长在红旗下的孩子啊），随着嵌入式开发生态系统越来越完善，目前也是有越来越多的Poweful开发工具支持丰富的调试功能（支持打印调试信息和交互等），但是涉及到一些版权的问题价格上还是有点小贵的（对一些小企业来说还是难以接受的），所以这个时候就需要我们动动脑筋去摸索摸索其他的方法（所谓路是探索出来的），事实证明破釜沉舟下人的潜力是无限的，呵呵，这里就分享一个折衷的办法去解决大家一直苦恼的问题，即使用IAR虚拟的串口终端来实现信息的交互和打印，下面进入正题： 测试平台：IAR6.6 + FRDM KE02开发板（我目前手里有这个，其他平台都可以） 测试代码：KE驱动库（KEXX_DRIVERS_V1.0.1_DEVD\kexx_drv_lib_release_r1.0.1\build\iar\ke02\platinum） 这里稍微提一句，我测试的是KE驱动库的代码，但是实际上只要你看懂了我下面的解决方法（授之以渔而不是鱼），其他代码都是类似的。 1）打开KE02 platinum的IAR工程，进入到platinum.c文件，找到main函数如下图1，可以看到其调用了printf打印函数，而该工程是默认调用底层串口的，我们跳转到该函数的定义如图2，再继续跳转到out_char的函数定义如图3，这下就屡清楚了，我们可以很直观的看到工程默认是调用UART底层的，呵呵，下面我们就要动手改造它对printf进行重定向； 2）首先我们需要注释掉printf的实现函数，将其屏蔽掉，然后需要给printf一个重新指向的地址，下面就该我们常见的<stdio.h>这位老兄出场了（貌似当初自打我开始接触Turbo C的时候就已经用到它了，老生常谈的“Hello world”就是调用它内部的printf来实现的）。我们找到Common.h文件，将<stdio.h>添加到其中，如下图，这样凡是需要printf的文件只需要添加common.h头文件即可： 3）这里先说说stdio.h文件的作用，我们打开stdio.h文件可以看到其内部定义了标准输入输出函数，包括我们常见的scanf和printf等函数，而这些函数所调用的底层即为IAR提供的链接到其Terminal的驱动，所以……懂的，呵呵。除此之外，我们肯定不满足只输出打印（给人略显低端的感觉有木有），所以为了体现我们不是“土豪”，我觉着有必要让它交互起来，实现真正的串口功能（因为一些类似bootloader或shell之类的还是需要输入参数的进行交互的），我在main函数添加了scanf语句用来测试输入功能，如下： 4）准备工作就绪，编译链接整个工程，然后下载到KE02的板子中并进入到Debug调试环境中，点击View->Terminal I/O调出虚拟终端，然后全步运行，就可以看到Terminal下开始打印调试信息，如下图1。当然显示输出有点小case了，我们再试试输入功能，在input框中输入‘a’，然后回车，如下图2，perfect： 5）还没完，我们要玩就玩高端大气上点档次的，我们再探索探索呢，结果又发现个小惊喜，我们点击上图右下角的“Input Mode”，弹出设置框如下，很高端啊有木有： 呵呵，看完之后是不是有种跃跃欲试的兴奋呢，呵呵，just have a try and enjoy it~ 附件为我修改之后的工程代码，仅供参考~

Since the mbed Ethernet library and interface for FRDM-K64 have not yet been fully tested, instead of using mbed we will use one of the latest demo codes from MQX specifically developed for the FRDM-K64 platform. Before starting please make sure you have the following files and software installed in your computer: CodeWarrior 10.6 (professional or evaluation edition) MQX 4.1 for FRDM-K64 (it is not necessary to install full MQX 4.1) JLink_OpenSDA_V2.bin (this is the debugger application) * If you don't have a valid license, you can find a temporary license below, it will only be valid until 7/30/2014 and it will only be available online until 7/05/2014. Building the project The first step to use an MQX project is to compile the target/IDE libraries for the specific platform: 1. Open CodeWarrior and drag the file from the following path C:\Freescale\Freescale_MQX_4_1_FRDMK64F\build\frdmk64f\cw10gcc onto your project area: This will load all the necessary libraries to build the project, once they are loaded build them it is necessary to modify a couple of paths on the BSP: 2. Right click on the BSP project and then click on properties 3. Once the properties are displayed, expand the C/C++ Build option, click on settings, on the right pane expand the ARM Ltd Windows GCC Assembler and select the directories folder, this will display all the libraries paths the compiler is using 4. Double click on the "C\Freescale\CW MCU v10.6\MCU\ProcessorExpert\lib\Kinetis\pdd_100331\inc" path to modify it, once the editor window is open, change the path from "pdd_100331" to "pdd" 5. Repeat steps 2 and 3 for the ARM Ltd Windows GCC Compiler 6. Now you can build the libraries, build them one at a time by right clicking on the library and selecting build project, build them in the following order, it is imperative you do it in that order. BSP PSP MFS RTCS SHELL USBD USBH 7. Once all the libraries are built, import the web hvac demo, do it by dragging the .project file to your project area; the project is located in the following directory:                     C:\Freescale\Freescale_MQX_4_1_FRDMK64F\demo\web_hvac\build\cw10gcc\web_hvac_frdmk64f 8. Once the project is loaded, build it by right clicking on the project folder and select Build project Debugging the project To debug the project it is necessary to update the FRDM-K64 debugging application: Press the reset button on the board and connect the USB cable Once the board enumerates as "BOOTLOADER" copy the JLink_OpenSDA_vs.bin file to the unit Disconnect and reconnect the board On CodeWarrior (having previously compiled the libraries and project) click on debug configurations 5. Select the connection and click on debug 6. Open HVAC.h and change the IP Address to 192.168.1.202 Now the demo code has been downloaded to the platform you will need the following to access all the demo features: Router Ethernet Cable Serial Terminal The code enables a shell access through the serial terminal, it also provides web server access with a series of options to simulate an Heating Air Conditioning Ventilation System, the system was implemented using MQX and a series of tasks, for more details on how the task are created, the information regarding how to modify the code please check the attached document: Freescale MQX RTOS Example guide.

In this document we are going to see how to use the attached code which implements the configuration of the FRDM-KL25 board as a USB HOST interfacing with a Numeric Keyboard and a 16x2 LCD. The project is compiled in the CodeWarrior IDE using Processor Expert and the Components to support the USB module of the USB Stack 4.1.1. How to add the Processor Expert USB components. The instructions to install the USB components to use them with Processor Expert are in the documentation of the USB Stack 4.1.1; here you can see the steps as well: Download the USB Stack 4.1.1 from the Freescale’s Website (USB Stack 4.1.1) Run the .exe file and install it in the default location. Open CodeWarrior and select Import Components in the Processor Expert button in menu bar. An Open windows will pop up, there you need to go to the path: <install folder>\Freescale USB Stack v4.1.1\ProcessorExpert\Components. To have the complete components and support for the USB module add each PEupd file repeating this step. Close CodeWarrior and open it again to ensure correct installation of the components. Check that the new components are available in the Components Library. About this Project. This project is based in the example code for Processor Expert in the USB Stack 4.1.1 USB_HID_MOUSE_HOST_MKL25Z128_PEx which implements the use of the FRDM-BOARD KL25 and a HID Mouse Device to interface with. In this project the HID Device is a Numeric Keyboard and the HOST Device (FRDM-KL25) is handling the data and printing them in a 16x2 LCD used in 8 bits mode (The LCDHTA component used here was created by Erich Styger; find the component an all the information about it here: http://mcuoneclipse.com/2012/12/22/hd44780-2x16-character-display-for-kinetis-and-freedom-board/ and say Thank you Erich: “Thank you Erich”). Here you can find a video of the implementation of this application: HID HOST WITH FRDM-KL25 The hardware components are: FRMD-KL25 Rev.E Adafruit Prototype Shield v.5 LCD JHD-162A Numeric USB Keyboard (Product Name: Numpad i110, Model No. GK-100010) USB _host Inside the project you can see there is a folder called USB_Host an it contains two important folders with source files: App_keyboard: Contains the specific function for the Keyboard configuration: in use, attached detached, callbacks and more; contain how to handle the data coming from the device. The function process_kdb_buffer is where the data is transmitted to the LCD and use it for the application. Classes: contain the necessary function to handle a hid as the device. Handle all the functions necessary for the USB protocol. Note: The usb_classes.c and usb_classes.h files are generated by processor expert. I attach these two files as well to have a reference how these files must look like. This is because sometimes during the code generation process Processor Expert erases part of the code. I hope this project is useful for you. Best Regards, Adrian.

I recently developed a Visual Studio .NET application that uses an OpenSDA virtual serial port to communicate with a FRDM-K64F. My serial protocol is a binary command-response protocol, which means that every time the .NET application sends a command packet to the serial port, it should always receive a response packet back. You can find more details about the protocol in the Freescale Intelligent Sensing Framework, but for the purposes of this document, all that matters is that every command should receive a response. My Visual Studio .NET application uses the SerialPort class, and worked beautifully...until I changed the OpenSDA firmware. Originally I used OpenSDA firmware from P&E; this time I had tried out Segger. In theory, this change should not have made a difference, however with the Segger firmware my .NET application never received response packets. I knew that the command packets were transmitting correctly from PC to board because they would turn a board LED on and off as expected. I tried using a binary terminal, RealTerm, to send commands to see if it would receive responses, and it did. So the problem had to be in my .NET application. After a lot of googling and some trial-and-error, I ultimately found that enabling the Data Terminal Ready (DTR) signal did the trick. Strangely, I didn't need to enable DTR in RealTerm. The moral of the story is that if you want to use Segger OpenSDA with a .NET SerialPort, then you must enable DTR. Fortunately this configuration also works with P&E and mbed OpenSDA.

FFT presentation for metering customers, targeted especially for KM3x / KM3x_256 devices. It briefly describes: How to Use it, and Why to Use it.

As K2 – The Next Generation of Kinetis Solutions continues to build momentum around new applications within the Internet of Things (IoT), the ARM® mbed™-enabled Freescale Freedom development platform, FRDM-K64F, is taking center stage. With the FRDM-K64F platform now in the hands of thousands of engineers across the globe, we already are learning about how this platform is powering new and inventive applications. To help illustrate this powerful and fun-sized platform, coming every Monday (beginning on Monday, May 19) for five consecutive Mondays, we invite you to join us for MountainMondays and scale K2 where we'll be giving away 20 FRDM-K64F development platforms each week - that's 100 in all! Join us to begin the ascent on Monday, May 19, by following Freescale's Facebook, Twitter and Google+ pages to find out what you have to do to win one of these development platforms! For complete contest rules, click here. Thanks to everyone who have participated in #MountainMondays! Great ideas from everyone! Below is our list of winners thus far for each week. If your name is on any of the following lists, be sure to email your shipping address to socialmedia@freescale.com and continue the ascent with us each Monday through June 16! Week 1 - May 19, 2014: Basecamp FRDM And the winners for week 1 are ... On Facebook ... Ahmed Felhi Naga Kishanmv Raleigh Sea Illgen Austin Chen Rahul Karnik Derrick Beaven David Pereira Anhell Barragán Valentín Korenblit Олег Лаврухин Hector Fabian Joanna Kurki Jozef Humaj Wojtek Stoduly Google+ ... Gurinder Singh Gill Mark McDonnell Niklas Stoyke Twitter ... kumisaappaat cledic evemuller92 Week 2 - May 26, 2014: Basecamp K And the winners for week 2 are ... From Facebook … Gaurav Chaudhary Bhuvanesh Nick Pyrosster Pyrosster Federico Lo Grasso Florencia Caruso Nick Defensor Laura Mándola SuperKing Tříska  From Twitter … Antonio Quevedo Jayprakash Shet Fahad Mirza Jonathan Chadwick Gordon Margulieux Hector Fabian C Zahir Parkar Attila Kozmári From Google+… Sergey Gridnewskiy Paul Nykiel Matías Dell'Oso Manishi Barosee Week 3 - June 2, 2014: Basecamp 6 And the winners for week 3 are ... From Facebook … Robert Bui Trong Nguyen Alexandre Ferri Michal Wertheim Petr Vítek Gerald Fry Jr Leśniewicz Wojciech Adriana Errico Trong Nguyen Emnics Erwin Kuhn Maliganis Nikolaos Dushyant Arora Štefan Knotek Hom Flann James Braga From Twitter… Gaurav Singh From Google+ … Soputtra San Clovis Fritzen Cristina Pérez Week 4 - June 9, 2014: Basecamp 4 And the winners for week 4 are ... From Facebook … Ivan Ruiz Robin Wohlers-Reichel Tony Anderson Łukasz Bittner Laura Chijlis Earl Orlando Jaime Pérez Rak San Gabriel Korenblit Tobiasz Dworak Sean Emerald Ghulam Mirosław Szymczyk Bhaumik Bhatt Jenius Nghia From Google+ … prithvi ganesh Evangelia Karagianni Vandy San Greg Steiert Titvirak San Joji John Varghese Week 5 - June 16, 2014: Basecamp F And the winners for week 5 are ... Evangelia Karagianni Shady Trần Kasia Michalowska Nghia Nguyen Saudin Dizdarevic Navin Bhaskar Thank you to everyone who has participated in the past five weeks of #MountainMondays – we’ve finally reached the summit of K2! Your energy, inventiveness and contributions have all been fantastic! Congratulations to all winners! We hope you enjoy your development platform and look forward to hearing about what you build using the FRDM-K64F platform. Happy designing!

For motor control and swich mode power supply application, it is required that the ADC sampling is synchronized with PWM signal. In general, most Kinetis sub-family provides FTM, PDB and ADC, it provides a mechanism for ADC converter is synchronizedc with PWM signal. But the KEA family does not have PDB module, instead, the KEA family provides a simple mechanism which enables PWM signal the FTM module generate can synchronize the ADC converter. The DOC introduces the mechanism, give the register configuration description, code and scope screenshot on how the PWM signal synchronizes the ADC.

Using five channels from FTM2 module of the KE02 microcontroller included on the FRDM-KE02Z board for controlling a robotic arm powered by five servomotors. Each servomotor is controlled by a couple of buttons of a matrix keyboard, which is connected to eigth GPIOs. Interrupts are not used in this example. The code was generated and compiled on CodeWarrior for Microcontrollers v10.5.

The SPI bus has the capability of addressing multiple slave devices by a single master. The Kinetis L series of devices feature either an 8-bit or 16-bit capable SPI module; however, there is only one dedicated CS/SS signal per instance of the module. Of course this signal is muxed to a few pin locations on the device. Unfortunately, there are not that many pins with the CS/SS muxing and they are most likely they are not near to each other physically. A solution to this issue is to use GPIO as CS/SS lines. This way you can take advantage of the SPI bus protocol and the Kinetis L series IOPORT interface (also known as FGPIO on Kinetis L). The Cortex-M0+ allows accesses to the IOPORT to occur in parallel with any instruction fetches; therefore, these accesses will complete in a single cycle. Core vs. SPI I'm sure many who have tried to use GPIO as CS/SS have written code similar to this pseudo code, I know I have: while(1) {      set_cs_low;      send_byte;      set_cs_high; } Logically this makes sense, but on an oscilloscope you will see the GPIO CS/SS line toggling at irregular intervals and out of sync with the SPI transfers. This is due to the nature of the 'send_byte' function or instruction. Simply transmitting a data packet will not prevent the core from waiting for the transmission to complete. The core will move on from writing data to the SPI data register, and execute the next instruction. If you have a core operating at 48 MHz and you are performing, at most depending on instance, 24 MHz SPI transfers the core will always move onto the next instruction before the data has left the module. The code must either implement a delay or wait for the transmission to complete. Incorporating an accurate delay can be tricky and can be interrupted by any interrupts occurring during the delay process. A more robust solution is to wait for the transmission to complete. However, there appears to be no Transmit Complete Flag (TCF) in the L-Series SPI module. The Solution Fortunately, there is a way to wait for transmit complete. Software must wait for the SPI read buffer full flag (SPRF) to be set in the SPI status register (SPIx_S) after writing data to the SPI data register (SPIx_D) . When the SPRF bit is set, software must read the SPIx_D. This procedure will ensure that the core does not move onto GPIO toggling, or other instructions, until the data has left the SPI module. The following function demonstrates how to write the above procedure in C using SPI0 and PTD0 as the CS/SS line: uint8_t SPI_send(uint8_t spiWrite) {     uint8_t spiRead;                        //Variable for storing SPI data     FGPIOD_PCOR |= (1 << 0);                //Toggle CS/SS line low     while(!(SPI0_S & SPI_S_SPTEF_MASK))     {         __asm("NOP");     }                                       //Wait for SPI transmit empty flag to set     SPI0_D = spiWrite;                            //Write data to SPI     while(!(SPI0_S & SPI_S_SPRF_MASK))     {         __asm("NOP");     }                                       //Wait for receive flag to set     spiRead = SPI0_D;                       //Read the SPI data register     FGPIOD_PSOR |= (1 << 0);                //Toggle CS/SS line high     return spiRead; } Please note that the GPIO CS/SS toggling need not be in the function. It should work just as well if the GPIO CS/SS toggles occur before and after the function is call, just remove the FGPIO instructions from the function and place them outside. I hope this document proves useful to those of you designing multiple slave SPI buses around Kinetis L series parts.

The TWR-KW2x board's OpenSDA is programmed with MSD (Mass Storage Device) application, that's why you see it listed as a disk drive. With that firmware, you can drag/drop .bin and .srec files to the board and that would flash it, but you won't be able to debug. For the boards to support download/debug features, the firmware for the OpenSDA had to be the Debug App ("DEBUG-APP_Pemicro_v108.SDA"). But PEMicro released a new firmware which supports BOTH functionality in the same firmware. You can also find it latest OpenSDA firmware at https://www.pemicro.com/opensda/ For example: Firmware that supports Debug and MSD functionality for TWR-KW24D512: "MSD-DEBUG-TWR-MKW24D512_Pemicro_v114.SDA". You can find attached the document with the instructions to modify the OpenSDA firmware on the TWR boards, basically you have to: 1. Unplug the board 2. Insert a Jumper in J30 to put the device in Bootloader mode 3. Plug in the board (Mini-USB) 4. Device will be enumerated as a "Drive Disk" But now with a "Bootloader" label 5. Drag and Drop the .SDA firmware to the drive (MSD-DEBUG-TWR-MKW24D512_Pemicro_v114.SDA) 6. Unplug the board 7. Remove Jumper 8. Plug in the board (Mini-USB) Now you should see the board being enumerated as "OpenSDA - CDC Serial Port" (allowing you to download/debug) and also listed as a disk drive(allowing you to drag/drop images to the board). Note1: If the "OpenSDA - CDC Serial Port" driver is not recognized, you can locate the driver within the TWR's Disk Drive (MSD) Note2: Jumper has to be in place in J29 for debugging Hope this info is helpful. You can find additional information on www.freescale.com/TWR-KW2x  --> Downloads -> Board Support Package  AND BeeKit Wireless Connectivity Toolkit

我们知道Kinetis L系列的中断向量表中只支持两个外部中断向量（vector_46 and vector_47），而FSL早期推出的的KL系列（包括KL25\KL24、KL15\KL14）只有PORTA和PORTD两个IO口支持中断，不过最新推出的KLx6系列（KL26、KL16和KL46）可以支持PORTA、PORTC和PORTD三个IO口的外部中断，其中PORTC和PORTD这两个IO端口共享同一个中断向量，另外，KL0x系列（包括KL02、KL04和L05）由于外部引脚只有PORTA和PORTB两个IO端口，所以它所支持的外部中断只有PORTA和PORTB。 下图分别为KLx5\KLx4系列（不包括KL05\KL04）、KLx6系列和KL05\KL04\KL02的外部中断向量分配表： KLx5\KLx4: KLx6: KL0x: KLx6的头文件注释： 最后需要注意的是，目前所有官方的demo例程（KLxx_SC）的中断向量表vector.h和MKLxxxx.h文件中关于中断向量的注释仍然是PORTA和PORTD，甚至有一部分例程中中断向量表的注释仍然是M4的注释直接移过来的，容易误导客户编程，这点需要在设计PCB板的时候有所考虑。

Description Thing.... Internet Enabled..... with command line and GUI over a TCP connection Parts Fantasma Toys Hand Runner: http://www.newegg.com/Product/Product.aspx?Item=9SIA0190BB9057 FRDM-K64 : http://mbed.org/platforms/FRDM-K64F/ RN-XV: https://www.sparkfun.com/products/10822 FRDM-AUTO: https://community.freescale.com/docs/DOC-99621 GUI Code:  https://github.com/ehughes/InternetofThing MBED Code: http://mbed.org/users/emh203/code/InternetOfThing/wiki/internet_of_thing Action Shots

Hello All, Power consumption of devices and implications around designing on embedded systems is a common topic nowadays. Kinetis MCUs offer different power modes to fit user's needs. Among these low power modes, we can find the lowest consumption modes: Low-Leakage Stop (LLS) and Very Low-Leakage Stop modes (VLLS). Attached document provides a brief introduction/explanation on these modes and lists the steps needed to configure MCU to operate in any of these modes. It is a bare-board project for FRDM-KL26Z but same principle applies to other Kinetis families. Also, two projects for KDS v3.2 are attached for reference. I hope you can find them useful! Regards, Isaac

           This is a demo of NFC device to read and write the contactless card. Kinets K60 tower board and NXP PN512 board are used for this test enviroment. These connected pins from K60 tower board to PN512 RF board are listed as below:   SPI1:     SPI1_SIN : PTE1/SDHC0_D0     SPI1_SCK : PTE2/SDHC0_DCLK     SPI1_SOUT : PTE3/SDHC0_CMD     SPI1_PCS0 : PTE4/SDHC0_D3     Reset:     PTB9   External interrupt:     PTA26         Because the SPI1 port is used as the host interface of pn512, it is necessary to enable the SPI1 driver in the user configuration file of MQX.           To open the project file in the /build folder with CW10.5.    And the PSP and BSP libraries had to be built before test image is built, as they are needed in this test project.   The following diagram shows the serial numbers and block data of reading from the test card of Mifare one.