Table of Contents 1       Introduction 2       DMA to emulate ADC Flexible Scan. 2.1         System overview and flow diagram for Flexscan. 3       SDK implementation. 3.1         ADC configuration. 3.2         LPMTR configuration 3.3         DMA configuration 4       ADC Flex Scan mode with DMA Appendix A: Requirements Reference   1    Introduction This document describes how to combine ADC, DMA and a timer to implement a ADC Flexible storing data with SDK 2.2 and MCUXpresso IDE. In this configuration ADC measures will be stored into an internal memory buffer with DMA, which imply, no CPU. With this configuration MCU uses less resources, only using ADC and DMA (2 channels) and a timer to trigger conversions. This way, the MCU does not need to read the ADC result register, because the memory management will be done by DMA automatically.   To implement this application we will use SDK libraries, which includes ADC and DMA libraries. The timer used to trigger ADC conversion will be the LPTMR. MCUXpresso IDE will be used as development environment, please check Appendix A to look where you can download SDK libraries and IDE. The project will be created from scratch, regardless of this, MCUXpresso IDE and SDK libraries allows us to create a project with some headers and libraries in the project, if you have problems creating a new project in MCUXpresso please check Reference 4.   In this document we will use the FRDM-K64F which is an ultra-low-cost development platform, but this implementation could be easily migrated to any kinetis family that support second-generation eDMA module (enhanced Direct Memory Access).   This document is an update of the community doc: Using DMA to Emulate ADC Flexible Scan Mode with KSDK  which uses old SDK libraries.   2     DMA to emulate ADC Flexible Scan   Flexible scan implementation needs 2 types of data movement: ADC measures (from peripheral to internal memory) and ADC mux change (from internal memory to peripheral). Second one is needed to change ADC input channel and have the flexible implementation, first one save ADC measures in our internal memory.   DMA peripheral (for this MCU) includes up to 16 channels, for this application we will only use 2 channels, one for ADC measures and one for ADC muxing channel. It is important to remark that we will use the linking feature in these channels to implement the ADC changing channel automatically, later in this document it will be explain this feature.   2.1         System overview and flow diagram for Flexscan.   As already mentioned, this implementation will use one DMA channel to transfer data from ADC measures (ADC0_RA register in this case) to a memory buffer (named here as g_ADC0_resultBuffer), so follow figure shows this movement:     As you can see, ADC0_COCO (conversion complete) will be the one that request a transfer from ADC0_RA to resultBuffer. Once this transfer has completed, we need to change ADC channel, so when DMA channel 1 transfer finishes, it will indicate us to trigger the other data movement, in this case from internal buffer g_ADC_mux (that save our adc channels) to the ADC0_SC1A register that sets the ADC channel, so the following diagram shows this.     To do this, this application used a DMA feature that link DMA channels, channel-to-channel linking. So, when one DMA channel finished, the linked DMA channel will be triggered, in this case when DMA channel 1 has completed to move data from ADC measure register to internal memory then DMA channel 0 need to be triggered to change the ADC channel, so next conversion ADC would have selected other ADC channel.   Once that the ADC channels is changed (and the HW trigger happens), the COCO flag from ADC will trigger other DMA request in channel 0 and the process will start again. This flow process can be repeated as many channels as we have and as many samples as we want, for this example code we will measure 3 channels and have 4 samples, so the result buffer size is 3 × 4 = 12 (the real buffer size is 16, to demonstrate that only 12 data field parts are written).   The ADC works in hardware trigger mode, with the LPTMR timer working as the trigger source. This mean that even though DMA channel 0 changed the ADC input channel, conversion will not start until HW trigger (LPTMR) start the conversion, this mean that the flow of the program can be as follow.       In the example code provided, when DMA channel 0 has changed 3 times the ADC channel, DMA channel 1 major loop will happen, and when the sample X is the last sample (sample 4) of the last channel in muxbuffer, then Major loop in DMA channel 0 happens and the application ends (or it could start again). This mean that the application here can be shown as:             3     SDK implementation   Implementation of this code can be dived in three parts; LPTMR, ADC and DMA configuration.   3.1         ADC configuration       ADC configuration is a normal ADC config, with 12 single ended, Asynchronous clock source and Vref as reference voltage. Hardware trigger and DMA support are enable to trigger conversions with LPTMR and to be able to trigger a DMA request when COCO interrupt happen. In ADC channel configuration, it is enable Conversion completed interrupt and it is loaded the value of g_ADC_mux to channel number, this will be the first channel that LPTMR will trigger.   3.2         LPMTR configuration       LPMTR is a common configuration with LPTMR as time counter. Please notice that prescaler could be used and select a prescaler clock. To set LPTMR period it is used the macro USEC_TO_COUNT, which just take the value in microseconds and it calculate the number of ticks to count, using the source clock. Also at the end, LTPMR is configured to be used as HW trigger for ADC conversions in the SIM register.   3.3         DMA configuration     For DMAMUX configuration it is enable Channel 0 and 1 and it is selected the source trigger, DMA for channel 0 (it will be triggered with linking feature) and ADC COCO flag for channel 1 (trigger when the ADC conversion complete).     For DMA configuration, it is needed to create 2 tcd configuration, there are set in transferConfig_chx. First one defined is for DMA channel 1 (data from ADC measure to internal memory), and the second is for DMA channel 0 (data from internal memory to ADC_SC1 register to change ADC channel). Please noticed that these definitions are in bytes to transfer, so some of them are sizeof(uint16_t). Here is also the setup to link channel 1 to channel 0.       Finally, it is added the adjustment for TCD, so when DMA major loop finished in both, it will point to the start of the source and destination. Noticed that this is added just for internal memory address, this is because for the case of a peripheral (ADC in this case), pointer to address doesn’t change.   Then DMA channel 1 and LPTMR are started.   When DMA channels were initialized, their callbacks were also defined;     This flags are just used for this implementation and as reference, they can be removed if needed. After Major loop has finished, SDK implementation disable DMA transfers automatically, so noticed that the callback_1 for DMA channel 1 has a line commented, that if uncommented, this application will act as a ADC that load measurements in an internal Ring buffer Indefinitely.   4     ADC Flex Scan mode with DMA With a basic Print implementation of ADC results we can show the functionality of this example project.     There are obtained the following results,         Appendix A: Requirements Download page for MCUXpresso IDE: MCUXpresso IDE|NXP  Download page for SDK 2.x drivers: Welcome to MCUXpresso | MCUXpresso Config Tools  Go to Build an SDK, select your device and click on Specify Additional Configuration Settings, verify that you have selected KDS as toolchain and then Go to SDK Builder. Click in Download Now, accept Term and conditions and download SDK packet. Please check: Generating a downloadable MCUXpresso SDK v.2 package    References   Using DMA to Emulate ADC Flexible Scan Mode with KSDK  MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers | MCU on Eclipse  https://www.nxp.com/docs/en/application-note/AN4590.pdf  Creating New Projects using installed SDK Part Support, MCUXpresso_IDE_User_Guide.pdf  

Here you can find both the code and project files for the Serial communication project, in this example the serial port (UART) is configured to establish communication between the computer using a serial terminal and the evaluation board. The default baud rate for the serial port is 9600 bauds. The code also implements an echo function, any key pressed in the computer's keyboard will be captured and displayed in the serial terminal. If your computer does not have a serial terminal you can download Tera Term from the following link: Tera Term Open Source Project The communication is established through the USB cable attached to the OpenSDA USB port. Code: #include "mbed.h" //Digital output declaration DigitalOut Blue(LED3); //Serial port (UART) configuration Serial pc(USBTX,USBRX); int main() {     Blue=1;     pc.printf("Serial code example\r\n");        while(1)     {         Blue=0;         pc.putc(pc.getc());     }    }

为了提高我们FAE对客户支持的效率，我们有必要将我们在客户支持过程中遇到的问题和解决方法以FAQ的形式列出来，方便大家查阅和参考。FAQ的形式比较灵活，大家可以以简单问答的形式言简意赅的描述，也可以是参考文章的链接，众人拾柴火焰高，希望大家能多收集问题并及时更新到该帖子中。 版本更新说明： Version 22: Rename "软件和例程" with "软件和文档", Add "常用的应用笔记" into "软件和文档" list; Version 20, 21: Remove "WIFI" solution, Add "SPI接口读写SD卡"; Version 19: Replace "iBeacon" with "BLE"; More version informations, please go to "Kinetis M0+ FAQ 版本更新历史" FAQ使用规范 1.FAQ Notes(Internal Use Only) 芯片选型 1.Kinetis L、E、V、W、M系列选型指南 软硬件开发环境 1.调试工具 2.量产工具 3.开源工具 4.IDE开发环境 5.开发板 硬件设计 1.电路设计注意事项 软件和文档 1.外设模块相关 2.Kinetis SDK 3.Kinetis Bootloader 4. 常用的应用笔记​ 参考设计及解决方案 1.Wireless Charging 2.Motor Control 3.BLE​ 4.M0+ 与Android手机通讯(基于AOAP协议) 5.SPI接口读写SD卡​ 常用网站资料 1.Amobbs（阿莫电子技术论坛） 2.与非网飞思卡尔技术社区 3.21IC飞思卡尔论坛 4.苏州大学教材光盘资料下载区 5.针对飞思卡尔单片机的快速上手指南 6.飞思卡尔MAPS开发板资料​ 7.FAE Technical Blogs​

    以DMA方式通过UART发送数据应该是工程应用中很常用的一种方式了，尤其是在需要频繁发送数据或者数据包长度较大的场合，如果使用传统的UART查询或者中断方式发送和接收数据，对CPU资源的占用将是极大的浪费，带操作系统的应用还好些，如果是纯粹的前后台程序有时不能容忍的，所以DMA方式是很恰当的选择。而本篇以Kinetis L系列为例介绍一下以DMA方式通过UART端口发送长数据包，当然不同于K系列复杂强大的eDMA功能，L系列的DMA模块配置起来还是比较简单的。 测试平台：IAR6.7 + KL26 FRDM 测试代码：FRDM-KL26Z_SC\FRDM-KL26Z_SC_Rev_1.0\klxx-sc-baremetal\build\iar\uart0_dma        其实KL26的官方sample code中是自带uart0_dma例程的，但是实现的功能只是将UART口接收到的每一个字节的数据通过DMA方式再发送出去（即环形缓冲），这样用来作为一个功能演示的demo是可以，但是往往我们需要的是将某缓冲区的数据以DMA方式发送出去或者将接收到的数据以DMA方式写到某缓冲区这样的功能，为此我们就需要在原有的例程上进行修改从而达到我们的应用目的，这里给出几点需要修改的地方，并做了相关注释（整个工程见最后附件）： 1）定义待发送缓冲区： /* array to be sended */ uint8 testdata[]={"\nFreescale Kinetis KL26\n"}; 2）设置DMA源地址： #define DMA0_DESTINATION  0x4006A007    /* the memory adress of UART0_D register */ #define DMA0_SOURCE_ADDR  (uint32)testdata    /* define the source data array address */ 3） 在DMA0_init()函数中修改发送数据包的长度： DMA_SAR0 = DMA0_SOURCE_ADDR;    //Set source address to UART0_D REG DMA_DSR_BCR0 = DMA_DSR_BCR_BCR(sizeof(testdata));    //Set BCR to know how many bytes to transfer DMA_DCR0 &= ~(DMA_DCR_SSIZE_MASK | DMA_DCR_DSIZE_MASK);    //Clear source size and destination size fields 4）添加源地址自动加1功能，因为之前的环形缓冲方式只是单字节数据，所以不需要源地址递增，但是由于我们这次需要发送整个数据包，所以这里我们就需要将源地址递增功能打开，而具体递增1,2还是4则取决于发送数据的最小单位（8bit，16bit or 32bit）： /* Set DMA as follows: Source size is 8-bit size Destination size is 8-bit size Cycle steal mode External requests are enabled source address increments 1 automatically */ DMA_DCR0 |= (DMA_DCR_SSIZE(1) | DMA_DCR_DSIZE(1) | DMA_DCR_CS_MASK | DMA_DCR_ERQ_MASK | DMA_DCR_EINT_MASK | DMA_DCR_SINC_MASK); 5）配置DMAMUX通道为UART0 TX即发送通道（通道号为3），因为我们需要的是UART0_TX触发DMA传送： DMA_DAR0 = DMA0_DESTINATION;    //Set source address to UART0_D REG DMAMUX0_CHCFG0 = DMAMUX_CHCFG_SOURCE(3);    //Select UART0 TX as channel source DMAMUX0_CHCFG0 |= DMAMUX_CHCFG_ENBL_MASK;    //Enable the DMA MUX channel 6）在UART0_DMA_init()函数中修改UART0发送缓冲区为空时即触发DMA发送： void UART0_DMA_init(void) { UART0_C2 &= ~(UART0_C2_TE_MASK | UART0_C2_RE_MASK);  //Disable UART0 UART0_C5 |= UART0_C5_TDMAE_MASK;                      // Turn on DMA request(Transmit) for UART0 UART0_C2 |= (UART0_C2_TE_MASK | UART0_C2_RE_MASK);  //Enable UART0 } 7）在DMA发送完成中断服务函数中禁掉DMA通道，实现单次发送，即每个数据包发送完成之后即停止发送，否则不禁掉的话会一直触发DMA发送，造成串口堵塞： void DMA0_IRQHandler(void) {  /* Create pointer & variable for reading DMA_DSR register */ volatile uint32_t* dma_dsr_bcr0_reg = &DMA_DSR_BCR0; uint32_t dma_dsr_bcr0_val = *dma_dsr_bcr0_reg; if (((dma_dsr_bcr0_val & DMA_DSR_BCR_DONE_MASK) == DMA_DSR_BCR_DONE_MASK)      | ((dma_dsr_bcr0_val & DMA_DSR_BCR_BES_MASK) == DMA_DSR_BCR_BES_MASK)      | ((dma_dsr_bcr0_val & DMA_DSR_BCR_BED_MASK) == DMA_DSR_BCR_BED_MASK)      | ((dma_dsr_bcr0_val & DMA_DSR_BCR_CE_MASK) == DMA_DSR_BCR_CE_MASK)) { DMA_DSR_BCR0 |= DMA_DSR_BCR_DONE_MASK;                //Clear Done bit DMA_DSR_BCR0 = DMA_DSR_BCR_BCR(sizeof(testdata));      //Reset BCR dma0_done = 1; } /* once the array complete the transfer, then disable the DMA channel.*/ DMAMUX0_CHCFG0 &= ~DMAMUX_CHCFG_ENBL_MASK; }        将上述代码做完相应修改即可实现单次将内存缓冲区数据以DMA方式通过UART0发送出去，效果如下。此外，如果想周期性触发或者条件性触发，则只需再相应位置添加“DMAMUX0_CHCFG0 |= DMAMUX_CHCFG_ENBL_MASK;”这句代码即可打开通道，然后立即会触发UART0_TX发送数据，然后待数据包发送完之后再次停止等待下次使能。 另外，关于DMA的传输速度的话，因为其独立占用一条自己的总线，其搬运时钟为系统时钟（即coreclock/Systemclock），相比于总线上的传输速度，本例程中整个数据包的发送时间主要是取决于UART串口的波特率*数据包长度。 附件为修改好后的完整工程：

Ezportdl：programming Kinetis EZport by MCU-Link Pro NXP launched MCU-Link Pro at the end of 2021. This is a new debugger probe that has been significantly upgraded based on mcu-link. The focus of the upgrade is to add current measurement, analog signal monitoring, USB to SPI and I2C bridge working modes, and on-board lpc804 for peripheral simulation. Among these upgrades, USB to SPI and I2C are more interesting and practical. Combining Kinetis EZport and flashloader, MCU-Link Pro can directly download programs to the target chip, instead of bridge through another board as before. This project uses the USB to SPI function of MCU-Link Pro to download programs to kinetis K series chips through EZport. In addition to the Kinetis series, many ColdFire chips of NXP also support EZport. In addition, since EZport interface protocol is compatible with SPI NOR flash, this project can also directly burn SPI NOR flash chip. This can also be used when debugging or producing i.mxRT500 and i.mxRT600. MCU Link Pro can easily use USB to SPI and I2C interfaces because NXP provides LIBUSBSIO library. Readers can download this library and related documents from NXP's official website. Here is a brief introduction. The SUB to SIO function is only an optional additional function for lpclink2 and MCU-Link Pro devices. Its main function is to provide CMSIS-DAP debugging interface for the target microcontroller, and provide virtual serial communication using USB VCOM class. The following figure is the process framework of LIBUSBSIO. As shown in the figure, LIBUSBSIO library can support SPI, I2C and GPIO.   The core of LIBUSBSIO communication is SPI_Transfer (lpc_handle hspi, spi_xfer_t * xfer) function. This function can send and receive 1024 bytes at most at one time. In addition, LIBUSBSIO library can set baud rate, clock polarity, sampling edge, and frame length. The following figure shows the output waveform captured by the logic analyzer.   Command Description WREN Write Enable WRDI Write Disable RDSR Read Status Register READ Flash Read Data SP Flash Section Program SE Flash Sector Erase BE Flash Bulk Erase RESET Reset Chip WRFCCOB Write FCCOB Registers dl Image download fw Write/read any sequence to SPI port   This project has been tested on FRDM-K64F.    Hardware connection: MCU-Link pro            FRDM-K64F J19-2        ---       R75-1（flying a line is needed） J19-3        ---       J1-8 J19-4        ---       J11-1 J19-5        ---       J1-12    Connect ground together.   Operation steps: Before power on, R75-1 should be connected to ground, then connect openSDA USB. Thus, K64 will enter EZport status. Read memory ezportdl read [address] [number]   Write enable ezportdl wren Write flash, which can write up to 1000 byte. ezportdl sp [length] [data]   Program a binary file into flash Ezportdl dl [address] [file name] [flag]  address means start address flag=0 means erase flash before programming, flag=1 means don’t erase the flash.     Project download address: https://github.com/jophpan/ezportdl/tree/master  

Here you can find the code and project files for the GPIO example, in this example the 3 colors of the RGB led are turned on sequentially when the SW2 push button is pressed, the led pin definition is shared throughout all the freedom platforms. The wait function can be defined in seconds, miliseconds or microseconds. Code: #include "mbed.h" //Delay declared in seconds /*GPIO declaration*/ DigitalOut Red(LED1);         DigitalOut Green(LED2); DigitalOut Blue(LED3); DigitalIn sw2(SW2); int main() {     /*Leds OFF*/     Red=1;     Green=1;     Blue=1;         while(1)     {         if(sw2==0)         {             Red = 0;             wait(.2);             Red = 1;             wait(1);                                Green=0;             wait(.2);             Green=1;             wait(1);                         Blue=0;             wait(.2);             Blue=1;             wait(1);         }     } }

Hello Kinetis community, High accuracy metering is an essential feature of an electronic power meter application. Metering accuracy is a most important attribute because inaccurate metering can result in substantial amounts of lost revenue. Moreover, inaccurate metering can also undesirably result in overcharging to customers.  The common sources of metering inaccuracies, or error sources in a meter, include the sensor devices, the sensor conditioning circuitry, the Analog FrontEnd (AFE), and the metering algorithm executed either in a digital processing engine or a microcontroller In this post you will find the description of the implementation of a Two Phase Power Meter firmware featuring Kinetis KM34 device using a metering algorithm known as Filter Based Algorithm. The showed firmware was implemented on the hardware design described in the Reference Manual DRM149 (the software implementation shown in the DRM149 is using a more complex metering algorithm called Fast Fourier Transform). Firmware Design The firmware implements the basic functions for an e-meter application such as: Power meter calibration: Performs power meter calibration and stores calibration parameters. Data processing: Read digital values form the AFE and performs scaling. Calculation of quantities: Calculates billing and non-billing quantities HMI control: Updates LCD with the new values and transitions to new LCD screen. Powe Meter Calibration The calibration task runs whenever a non-calibrated power meter is connected to the mains. First it checks if the calibration flag is already stored in the microcontroller flash, if not, then it runs the calibration. More detail about the calibration process can be found in the DRM143 document. The function: int16 CONFIG_CalcCalibData (tCONFIG_FLASH_DATA *ptr)‍‍‍ is in charge of calculating the calibration data and store the calibration flag in the flash. You can refer to the next code section for the complete usage and definition.   /* if calibration data were collected then calibration parameters are       */   /* calculated and saved to flash                                            */   if (CONFIG_CalcCalibData ((tCONFIG_FLASH_DATA *)&ramcfg) == TRUE)     CONFIG_SaveFlash ((tCONFIG_FLASH_DATA *)&ramcfg, ramcfg.flag);‍‍‍‍ The calibration task terminates by storing calibration gains, offsets and phase shift into the flash and by resetting the microcontroller device. Data Processing Reading the phase voltage and phase current samples from the analog front-end (AFE) occurs periodically every 166.6 μs. This task runs on the highest priority level (Level 0) and is triggered asynchronously when the AFE result registers receive new samples. The task reads the phase voltage and phase current samples from the AFE result registers, scales the samples to the full fractional range, and writes the values to the temporary variables for use by the calculation task. While kWh values is being calculated every 6000 Hz the remaining quantities: kVARh, QAVG, PAVG, URMS and IRMS are being calculates every 1500 Hz (666.6 μs). This is according to the decimation factor and to reduce the CPU usage since those values are not needed every AFE sample. The meter definition used for this application can be found in the meterlib2ph_cfg.h files, this file was generated using the Filter-Based Metering Algorithms Configuration Tool, for more information on how to use the tool you can refer to the AN4265 document. This is the Meter configuration: Here you can see the expected error behavior against Frequency: The configuration of the AFE module and channels is the following:   /* Current Phase 1                                                          */   AFE_ChInit (CH0,               AFE_CH_SWTRG_CCM_PGAOFF_CONFIG(DEC_OSR1024),                    0,               PRI_LVL1,               (AFE_CH_CALLBACK)NULL);     /* Current Phase 2                                                          */   AFE_ChInit (CH1,               AFE_CH_SWTRG_CCM_PGAOFF_CONFIG(DEC_OSR1024),               0,               PRI_LVL1,               (AFE_CH_CALLBACK)NULL);     /* Voltage Phase 1                                                          */   AFE_ChInit (CH2,               AFE_CH_SWTRG_CCM_PGAOFF_CONFIG(DEC_OSR1024),                    0,               PRI_LVL1,               (AFE_CH_CALLBACK)NULL);     /* Voltage Phase 2                                                          */     AFE_ChInit (CH3,               AFE_CH_SWTRG_CCM_PGAOFF_CONFIG(DEC_OSR1024),               0,               PRI_LVL1,               (AFE_CH_CALLBACK)afech3_callback);     /* AFE Initialization @ 6 KHz                                               */   AFE_Init    (AFE_MODULE_RJFORMAT_CONFIG(AFE_PLL_CLK, AFE_DIV2, 12.288e6));  ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ As you can see only the CH3, which is measuring the Voltage phase 2, is configured with interrupt. During the CH3 callback the remaining channels are sampled to get the 4 values at the same time and performs scaling: /* measurements callback @ 6000 Hz                                            */ static void afech3_callback (AFE_CH_CALLBACK_TYPE type, int32 result) {   static int cnt_1 = 0;     if (type == COC_CALLBACK)   {      /* Current and Voltage reading                                            */     u24_sample[0] = AFE_ChRead (CH2) << U_SCALE;            /* Voltage 1 reading ... */     i24_sample[0] = AFE_ChRead (CH0) << I_SCALE;            /* Current 1 reading ... */     u24_sample[1] = AFE_ChRead (CH3) << U_SCALE;            /* Voltage 2 reading ... */     i24_sample[1] = AFE_ChRead (CH1) << I_SCALE;            /* Current 2 reading ... */     . . . . }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Calculation of Quantities Within the CH3 interrupt the metering algorithm functions are called to process the data of the active energy, the calculation task scales the samples using calibration offsets and calibration gains obtained during the calibration phase: METERLIB2PH_ProcSamples removes DC bias from phase voltage and phase current samples together with performing an optional sensor phase shift correction. METERLIB2PH_CalcWattHours recalculates active energy using new voltage and current samples. CONFIG_UpdateOffsets updates offset of the phase voltage and current measurements conditionally. The CH3 calls the next software interrupt, auxcalc_callback where non-billing quantities are calculated: METERLIB2PH_CalcVarHours recalculates reactive energy. METERLIB2PH_CalcAuxiliary recalculates URMS, IRMS, PAVG, QAVG and S auxiliary quantities. You can find more information about the Filter-Based Algorithm function in the AN4265 document.   HMI Control The display_callback task is called every 3 Hz by the auxcalc_callback and is executed on the lowest priority. For this application it update the clock data structure, refresh the watchdog timer and call some metering algorithm functions to read the values of the billing and non-billing quantities: METERLIB2PH_ReadResultsPh1 reads URMS, IRMS, PAVG, QAVG and S auxiliary quantities from phase 1. METERLIB2PH_ReadResultsPh2 reads URMS, IRMS, PAVG, QAVG and S auxiliary quantities from phase 2. A timer interrupt is used to update the the LCD content every 1500 ms. static void lptmr_callback (void) {   lcd_all_off();   /* update menu index                                                    */   menu_fcn[menu_idx]();   if ((++menu_idx) >= DIM(menu_fcn))   {     menu_idx = 0;   } }‍‍‍‍‍‍‍‍‍‍ Results The two-phase hardware has been calibrated using the test equipment ELMA8303. During accuracy calibration and testing, the power meter measured electrical quantities generated by the test bench, calculated active and reactive energies, and generated pulses on the output LEDs; each generated pulse was equal to the active and reactive energy amount kWh (kVARh)/imp3. The deviations between pulses generated by the power meter and reference pulses generated by test equipment defined the measurement accuracy.   The next figure shows the calibration protocol of the power meter. The protocol indicates the results of the power meter calibration performed at 25 °C. The accuracy and repeatability of the measurement for various phase currents and angles between phase current and phase voltage are shown in these graphs. The first graph indicates the accuracy of the active and reactive energy measurement after calibration. The x-axis shows variation of the phase current, and the y-axis denotes the average accuracy of the power meter computed from five successive measurements The second graph (on the bottom) shows the measurement repeatability; i.e. standard deviation of error of the measurements at a specific load point.  You will find attached a ZIP file containing the IAR source code of the application and a PDF file showing the complete results of the protocol. I hope the information helps. Regards, Adrian Cano

I2C (Inter-Integrated Circuit) Module by Alejandro Lozano, Freescale TIC. i2C Protocol Explanation. Connection Diagram. How to configure the registers. Hands-On. Presentación del módulo de I2C (Inter-Integrated Circuit) por Alejandro Lozano, Freescale TIC. Explicación del Protocolo I2C. Diagrama de conexión. Explicación de cómo configurar los registros. Hands-On

One of the new features that can be found on the FRDM-K82F is the FlexIO header. It’s be specifically designed to interface with the very cost-efficient OV7670 camera, and uses 8 FlexIO lines to read data from the camera. By using the FlexIO feature, it makes it easy to connect a camera to a Kinetis MCU. A demo is included with Kinetis SDK 1.3 which streams the video data from the camera to a host computer over USB. FlexIO: The FlexIO is a highly configurable module found on select Kinetis devices which provides a wide range of functionality including: • Emulation of a variety of serial/parallel communication protocols • Flexible 16-bit timers with support for a variety of trigger, reset, enable and disable conditions • Programmable logic blocks allowing the implementation of digital logic functions on-chip and configurable interaction of internal and external modules • Programmable state machine for offloading basic system control functions from CPU All with less overhead than software bit-banging, while allowing for more flexibility than dedicated IP. Running the Demo: First you’ll need to setup the hardware. An 18 pin header needs to be installed on the *back* of the board. The camera is oriented this way to allow for use of shields on the top, even if the camera is being used. This way the functionality could be extended with WiFi or LCD shields. After the header is soldered on, plug in the camera. It will look like the following when complete: Next we need to program the K82 device with the example firmware. The software can be found in the Kinetis SDK FRDM-K82F stand-alone release, in the C:\Freescale\KSDK_1.3.0_K82\examples\frdmk82f\demo_apps\usb\device\video\flexio_ov7670 folder. Open the project, compile, and program the example specific for your compiler like done for other examples. Make sure you also compile the USB Device library as well. After programming the K82, unplug the USB cable from J5 (OpenSDA) and plug it into J11 (K82 USB). The board will enumerate as a generic USB video device called “USB VIDEO DEMO”. You can then use this device with any video capture software, like Skype or Lync.  Here's a shot of the clock in my cube: The resolution is 160*120, the video image format is RGB565. You may need to manually adjust the focus by rotating the lens on the camera. The frame rate can also be sped up by modifying line 342 in usb_descriptor.c: 5fps: 0x80,0x84,0x1E,0x00, /* Default frame interval is 5fps */ 10fps:  0x40,0x42,0x0F,0x00, 15fps:  0x2A,0x2C,0x0A,0x00, 20fps:  0x20,0xA1,0x07,0x00, The 160*120 max resolution was determined by the amount internal SRAM of the device, as there is not external RAM on the FRDM-K82F board. More Information: One of many places to buy the OV7670 camera module​ OV7670 Reference Manual​ FlexIO Overview ​ FlexIO Training presented at FTF

在电机控制，Audio等很多应用中，我们经常会用到一些常见的正余弦，矩阵变换，FFT等一些DSP函数，提到DSP库，通常会想到使用ARM 公司提供的 CMSIS 库。CMSIS 库是ARM和一些半导体厂家针对Cortex-M系列制定的一套接口标准，包括针对内核操作的CMSIS-CORE API，针对DSP应用的CMSIS-DSP Library，针对RTOS的CMSIS-RTOS API，与外设接口的CMSIS-SVD以及提供Debug访问接口的CMSIS-DAP。 其中，又以DSP应用的CMSIS-DSP 库的应用最为广泛。针对Cortex-M4中的DSP功能，CMSIS-DSP部分提供了超过60多种功能的DSP算法库，尤其是随着Cortex-M4中集成了FPU硬件单元，CMSIS-DSP 库的应用也越来越广泛。 在KEIL 和IAR中都集成了对CMSIS的支持，然而在CodeWarrior中没有直接支持CMSIS，需要用户移植到自己的CW工程中，所以就需要使用者了解CMSIS的结构，手动添加库文件和头文件，并完成一些重要的编译参数配置。特别是有些芯片支持FPU浮点运算单元，有些不支持，在配置选项上差别很大。在飞思卡尔Kinetis系列芯片中，FPU浮点运算单元也是一个可选的部件，只有在名称中带有FN和FX的芯片才支持FPU硬件浮点功能，如MK60FN1M0, MK60FX512。本文档分别介绍在使用和不使用FPU的情况下如何一步步移植CMSIS的DSP库到自己的CodeWarrior工程中。 需要注意的是 FPU 单元是指的芯片上的一个独立于 CPU 处理的浮点运算单元，整个单元在大多数厂家的芯片中都是可以被使能和关闭的。相对于芯片，编译器也设置了相应的 FPU 功能开启/关闭的选项，在编译时需要告诉编译器是否开启 FPU 功能。编译器一旦开启 FPU 功能，在处理单精度浮点运算的语句时就会用带 V-开头的汇编指令进行编译。如果编译器使能了 FPU 功能，而芯片未开启 FPU 单元，程序运行到浮点语句时就会出现异常。相反，如果编译器未使能 FPU 功能，芯片即使开启了 FPU单元，程序还是会按照未使能 FPU 的代码进行处理。在本例程中，为对比分析是否采用FPU的编译指令差别以及在板的执行效率，选用Kinetis K70FN1M为实验对象。 硬件平台：TWR-K70F120M核心板      软件环境：CodeWarrior v10.5        CMSIS版本 ：V3.2 一. 准备工作： 下载CMSIS的库，当前最新的版本为V3.2，解压后名称为CMSIS-SP-00300-r3p2-00rel1，其目录结构如下图。分别包含CMSIS-DSP, CMSIS-RTOS和CMSIS-SVD的库文件。在本Cortex M4的CMSIS-DSP的应用中，真正用到的文件包括CMSIS\Include中CM4相关的头文件，CMSIS\Lib\GCC文件夹中的库文件libarm_cortexM4l_math.a(软浮点)和libarm_cortexM4lf_math.a(硬浮点)，以及Device\ARM\ARMCM4\include中外设访问相关的两个头文件。 二. 不使用K70的FPU浮点运算单元，移植CMSIS的DSP库到CW的步骤；      Step 1:    新建一个Baremental的工程，选择器件器件MK70FN1M0（支持硬件FPU）；     Step 2:    选择Floating Point浮点运算实现的类型，即指定编译器将C代码编译成汇编代码时使用的规则； 在Floating Point四个选项含义如下： Software选项：表示不使用FPU硬件，而是使用GCC的整数算术运算来模拟浮点运算； Handware(-mfloat –abi=hard) 选项：表示使用FPU硬件来进行浮点运算，函数的参数直接传递到FPU的寄存器(s0-d0)中； Handware(-mfloat –abi=softfp)选项：表示使用FPU硬件来进行浮点运算，但是函数的参数传递到整数寄存器(r0-r3）中，然后再传递到FPU中； Handware(-mfloat –abi=softfp –fshort -double)选项：其配置项同上，只不过使能了fshort  double功能，并且此处的double数据的宽度等同于float； 有兴趣研究各个选项意义的可以参考CW for MCU技术文档的第3章，在本例程中使用的是软浮点，所以选择Software项。需要注意的是：此配置选项仅出现支持FPU硬件单元的芯片工程中，如MK60FN1M0, MK60FX512等，否则默认没有此选项，默认为软件浮点。 Step 3:    点击“Next”进入下图，选择使用Processor Expert，点击“Finish“完成工程的建立； Step 4:    进入当前工程的文件夹，新建文件夹CMSIS，从之前在准备步骤解压的CMSIS文件包\...\CMSIS-SP-00300-r3p2-00rel1\CMSIS中拷贝Include和Lib文件夹到当前工程新建的CMSIS文件夹。另外，拷贝\...\CMSIS-SP-00300-r3p2-00rel1\Device\ARM\ARMCM4\Include中的ARMCM4.h和system_ARMCM4.h到当前工程新建的CMSIS文件夹中； Step 5:    回到CodeWarrior主界面选择新建的工程文件，F5刷新可以看到CMSIS出现在工程文件中。其中Include是CMSIS库的一些头文件，包括M0+/M3/M4的一些头文件；在Lib文件中是已经编译好的库文件，ARM文件夹是使用在KEIL IDE中的库文件，G++文件夹是使用在IAR中的库文件，而由于当前CW工程使用的GCC的编译器，所以GCC文件夹才是CW需要的，因此，为缩减工程大小可以删除ARM和G++文件夹；     Step 6:    打开工程属性框，选择Target Processor的Float ABI为No FPU； Step 7:    在GCC Complier的Defined symbols中添加编译的宏定义ARM_MATH_CM4； Step 8:    在GCC Complier的Include paths中添加CMSIS库的头文件，路径为：工程目录\CMSIS\Include； Step 9:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中不使用FPU，所以选择libarm_cortexM4l_math.a，此处需要特别注意，否则编译会报错； Step 10: 在ProcessorExpert.c文件中添加代码； #include <math.h> #include "arm_math.h" #define DELTA    (0.000001f) const float32_t testRefOutput_f32 = 1.000000000; const float32_t radians=1.047197533333333; float32_t  cosOutput, sinOutput, diff; float32_t cosSquareOutput,sinSquareOutput,testOutput; int main(void) {   int m,n;   PE_low_level_init();   cosOutput = arm_cos_f32(radians); /*求正余弦*/                   sinOutput = arm_sin_f32(radians);                                 arm_mult_f32(&cosOutput, &cosOutput, &cosSquareOutput, 1); /*求积运算*/   arm_mult_f32(&sinOutput, &sinOutput, &sinSquareOutput, 1);               arm_add_f32(&cosSquareOutput, &sinSquareOutput, &testOutput, 1); /*求和运算*/   diff = fabsf(testRefOutput_f32 - testOutput);  /* 求绝对值 */                 if(diff > DELTA)   {                         while(1)                                 {                                   for(m=0;m<2000;m++)                                                 for(n=0;n<200;n++){};                                                 D7_NegVal();                                 }     }                 } Step 11:    编译并下载Debug，在  sinOutput = arm_sin_f32(radians);处设置断点，可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常，其反汇编的得到为普通的ARM指令(FPU 单元汇编指令通常在普通指令前加字母V，仅在 FPU 功能被使能时使用)，完成一个正弦计算； 至此，完成了不使用K70的FPU浮点运算单元，移植CMSIS的DSP库到CW的步骤。     三.     使用K70的FPU浮点运算单元，移植CMSIS的DSP库到Codewarrior的步骤 使用K70的FPU硬件浮点运算单元，移植CMSIS的DSP库到Codewarrior的方法有两种：一种是按照上面软浮点的方式Step By Step的建立工程，步骤和上面二的步骤基本一致，主要的两个区别在于：(1). Step 2要选择Handware(-mfloat –abi=hard) 选项，(2). Step 9 改为libarm_cortexM4lf_math.a。另外一种就是在上面工程的基础上修改配置选项。鉴于方便，本教程采用第二种方案，完成在Codewarrior中调用CMSIS的DSP库，通过K70的FPU浮点运算单元执行浮点运算，即硬浮点。 Step 1:    打开工程属性对话框，选择Target Processor的Float ABI为FPU with hard vfp passing(-mfloat –abi=hard)； Step 2:    在GCC Complier的Defined symbols中添加编译的宏定义：_VFPV4； Step 3: 在GCC C Linker的Libraries项的library search path中指定链接的规则，把上面工程中默认的"${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m"修改为 "${MCUToolsBaseDir}/ARM_GCC_Support/ewl/lib/armv7e-m/fpu"； Step 4:    在GCC C Linker的Miscellaneous项的Other objects中指定使用的库文件(位于CMSIS\Lib\GCC文件夹中)。因为本例程中使用FPU，所以选择libarm_cortexM4lf_math.a，此处需要特别注意，否则编译会报错； Step 5:    完成以上配置后，编译工程并下载调试（此处建议编译之前先Clean一下整个工程），同样，在  sinOutput = arm_sin_f32(radians);处设置断点，可以看到CMSIS-DSP库中的正余弦浮点数运算函数运算正常，其反汇编的得到为FPU指令(FPU指令通常是指在普通指令前加字母V，仅在 FPU功能被使能时使用)，并且在Register观察窗口中也多了个FPU寄存器列表，感兴趣的读者可以对比一下和前面实验汇编出代码的差异，此处不再赘述； 至此，分别完成了使用和不适用K70的FPU浮点运算单元情况下， CMSIS的DSP库到Codewarrior的移植。在实际应用中需要用到更多的DSP函数，在项目中直接调用即可。下一步， Just Enjoy The Convenience of  The CMSIS! 有一点需要说明的是，前文中讲到使用FPU单元需要两步设置：(1). 在编译器中开启相应的 FPU 功能选项；(2). 开启芯片FPU 单元。似乎我们前面的设置是完成了第一个步骤，然而第二个步骤呢？仔细查看_arm_atart.c文件，可以发现代码_fp_init()正是完成了开启芯片FPU单元的过程，如下图，是一个条件编译函数，这也就解释了为什么在上面Step 2中定义了_VFPV4，其本质也就是使能芯片的FPU单元，其具体实现可以查看ARM手册的第74页的描述。 #ifdef   __VFPV4__        //Step 2中的宏定义                 __fp_init();      // 开启芯片的FPU单元 #endif

    不得不说Keil貌似是国内用户使用最多的IDE了，其被ARM收购之后，ARM嵌入了ARMCC等编译器推出了Keil MDK开发环境更是受到了广大ARM开发工程师的欢迎，庞大的用户群（很多是从当年的51等8位机直接转过来的）、简洁的管理窗口和友好的UI界面等优势都让其风靡一时，而且毕竟现在成了ARM的“亲儿子”了，其对ARM内核的产品支持还是灰常不错的。     而GCC更是大名鼎鼎，这个至今仍然在维护的GNU项目下的产物，在N多大牛的维护下不断得到优化，其强大的编译效率和跨平台能力也是广为大家所认可（Codewarrior10.x之后，针对ARM的编译器就是集成了GCC）。     而本文的目的是针对那些想从GCC平台迁移到Keil MDK平台的开发者（并不是代表ARMCC比GCC好，这里不拿这两者做对比），可能用习惯了GCC的话移植到ARMCC下会有些差别需要注意，如匿名的联合体union在ARMCC下是不支持的，要想再ARMCC下使用需要在前面添加“#pragma anon_unions”，而这种格式在GCC却是直接支持的。     而如果开发者想将原来在GCC下的工程整体迁移到Kei MDK下，如果工程里存在大量的这种定义，那人为的一条条修改绝对是一件让人抓破头皮的事，呵呵，那有没有简单的一蹴而就的方法呢？咳咳，我都这样说了那肯定就有啦，有点卖关子了，呵呵，其实很简单，我们进入到Project->Options…，设置如下图所示，即添加“--gnu”即可实现在Keil工程下使用GNU工具链GCC来编译工程C文件了，是不是有点太简单了，呵呵。     当然最后我需要提一句，这个“--gnu”是添加在C/C++这个选项卡下的，如果你最开始使用Keil重新新建的一个工程并添加了Keil自动生成的启动代码的话（startup_xxx.s）请慎用在ASM选项卡下添加“--gnu”，因为ARMCC下的汇编格式是与GCC完全不一样的，所以用GCC来编译Keil下生成的汇编是不行的，这点需要注意。

最近，有客户反映在IAR6.6 环境中，即便在程序中配置了Kinetis的加密字段“0x40C -0x40F”，但在实际程序运行中发现这些加密位并没有被真正的写进去。现根据Colleagues的分析，结合个人的理解总结如下，描述不清楚之处希望能提出宝贵意见。 原因：新版本的IAR 6.6 为了防止用户在使用Kinetis过程中误操作导致芯片被锁死，默认将加密位Disable了，在烧录Flash的时候设了最后一道闸门，将0x40C -0x40F的值统一成0xFFFFFFFE (解密模式)。 如果要完成加密， 可以修改其Flash Loader配置。 证据：在C:\Program Files\IAR Systems\Embedded Workbench 6.5_2\arm\config\flashloader\Freescale文件夹中，查看FlashK60Dxxx128K.board文件可以看到如下描述，其中<args_doc>与</args_doc>可以理解为一些注释，需要按解决方法的步骤设置。 <args_doc>.....--enable_config_write - allow programming of 0x40C - 0x40F with user supplied data, in other case flashloader after erase of block 0 will write 0xFFFFFFFE (unsecure state).</args_doc> 解决方法： 1） 打开IAR的Options配置框，选择Debuger的Download 标签，勾选如下图所示的选项，可以看到此项目中对应的.board文件； 2） 点击edit按钮， 显示如下对话框，两处分别对应着包含不同Flash Memory的器件设备； 3） 对于不包含FlexNVM的器件，选择0x0-0xfffffff对应的条目，然后选择Edit； 4） 在下面的对话框中的extra edit 项目中填写 “--enable_config_write” , 它意味着打开了在烧录Flash的时候设置的最后一道闸门，使能了用户对加密字段“0x40C -0x40F”的配置。关于此参数选项含义，可以查看下面框中parameters description的描述。 5） 选择OK , 回到上级对话框，如下图可以看到“--enable_config_write”作为一个Extra Parameters显示出来； 6）再次选择OK,回到上层对话框。 此处不用担心OK后修改的配置会替换Flash Loader中的默认配置，因为系统会自动保存刚才的修改到一个新的board文件，并存储到当前工程的文件目录中； 7） 选择“save ”，保存； 8） 选择"OK”，然后开始下载。 9） 如果以后需要加密的时候， 可以使用新的board文件， 不需要加密的时候，选择使用IAR下面的board文件。      至此，完成整个配置过程。 关于在J_flash中选择使用加密： 1）在Jflash中选择project settings； 2）在Project settings栏选择CPU标签，勾选Device选项，并点击Freescale MKL25Z128xxx4后面的方框； 3）在如下窗口Manufacturer中选择Freescale，找到对应的Device，选择带有"allow security"的选项，就可以支持加密了。否则即便在程序中Kinetis的加密字节设置了加密，代码也不会实     际的运行。

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 <DebugLed.h> #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!

Here you will find the code and project files corresponding to the I2C-Accelerometer project. The accelerometer/magnetometer is connected to the I2C port, although bot the accelerometer and magnetometer are contained within a single package, they must be initialized individually. In this example the measurements from both devices (X,Y and Z axis) is performed and displayed at the serial terminal. In order to compile the project, the following library must be imported: FXOS8700Q.h Code: #include "mbed.h" #include "FXOS8700Q.h" //I2C lines for FXOS8700Q accelerometer/magnetometer FXOS8700Q_acc acc( PTE25, PTE24, FXOS8700CQ_SLAVE_ADDR1); FXOS8700Q_mag mag( PTE25, PTE24, FXOS8700CQ_SLAVE_ADDR1); //Temrinal enable Serial pc(USBTX, USBRX); MotionSensorDataUnits mag_data; MotionSensorDataUnits acc_data; int main() {     float faX, faY, faZ;     float fmX, fmY, fmZ;     acc.enable();     printf("\r\n\nFXOS8700Q Who Am I= %X\r\n", acc.whoAmI());     while (true)     {         acc.getAxis(acc_data);         mag.getAxis(mag_data);         printf("FXOS8700Q ACC: X=%1.4f Y=%1.4f Z=%1.4f  ", acc_data.x, acc_data.y, acc_data.z);         printf("    MAG: X=%4.1f Y=%4.1f Z=%4.1f\r\n", mag_data.x, mag_data.y, mag_data.z);         acc.getX(&faX);         acc.getY(&faY);         acc.getZ(&faZ);         mag.getX(&fmX);         mag.getY(&fmY);         mag.getZ(&fmZ);         printf("FXOS8700Q ACC: X=%1.4f Y=%1.4f Z=%1.4f  ", faX, faY, faZ);         printf("    MAG: X=%4.1f Y=%4.1f Z=%4.1f\r\n", fmX, fmY, fmZ);                 wait(1.0);     } }

The documentation is only for eFlexPWM module of KV58, it describes the feature of nano-edge PWM, the mechanism of nano-edge PWM, and give the waveform which can describe the feature of nano-edge PWM. The attachment includes the brief introduction of nano edge PWM, the waveform of nano edge PWM, and the code which runs on TWR-KV58 and KDS3.0. Original Attachment has been moved to: eFlexPWMNanoEdgeKV58_2.rar

Overview      This document describes how to use ezport module on TWR-K22F120M,  and the usage of ezport on other platforms  is similar.      The EzPort module is a serial flash programming interface that enables In-System Programming (ISP) of flash memory contents in a 32-bit general-purpose microcontroller.      The block diagram of EzPort module is as follows: Hardware environments TWR-K60D100M TWR-K22F120M TWR-SER Primary and Secondary Tower boards      Because the EzPort module is a serial flash programming interface that is compatible with a subset of the SPI format. TWR-K60D100M is used as a SPI master and TWR-K22F120M is used as a slave. The flash memory contents of TWR-K22F120M can be read/erased/programmed from TWR-K60D100M.      Connect the TWR-K60D100M and TWR-SER by two tower boards, the execution result will be outputed by uart. Step 1：TWR-K22F120M enters into EzPort mode Hardware setup:       If the TWR-K22F120M wants to enter EzPort mode, the EZP_CS pin should be asserted and then reset pin is asserted. TWR-K60D100M                         TWR-K22F120M PTC6(J11 A71)                           EZP_CS(J31 Pin9) Software setup: Open the project “ezport_test_kinetis”; Define the MACRO “ENTER_EZPORT_MODULE” in hal_config.h; Build and download the program into TWR-K60D100M, run it, then EZP_CS pin of TWR-K22F120M will be asserted. Then power-on the TWR-K22F120M. The TWR-K22F120M will enter into EzPort mode. Step 2: Use EzPort to read/erase/program the flash Hardware setup: TWR-K60D100M                         TWR-K22F120M PTD0(J11 B63)                            EZP_CS(J31 Pin9) PTD1(J11 B64)                            EZP_CLK(J31 Pin4) PTD2(J11 A76)                            EZP_DI(J31 Pin8) PTD3(J11 A77)                            EZP_DO(J31 Pin6) GND(J11 B65)                             GND(J31 Pin5) Note: TWR-K60D100M and TWR-K22F120M should have common ground. Software setup: Open the project “ezport_test_kinetis”; Undefine the MACRO “ENTER_EZPORT_MODULE” in hal_config.h, then EzPort test codes will be enabled; Build and download the program into TWR-K60D100M, run it, then the flash memory contents of TWR-K22F120M can be read/erased/programmed from TWR-K60D100M, the execution result will output to the console by uart.

     我想“超频”这个词估计大家都不会陌生，很多玩计算机的都会尝试去把自己电脑的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，再往上我就没有测试了，因为基本也用不到那么高的频率，还是要掌握好这个“度”的，想过把超频的瘾的可以试试看，呵呵~

First let us see the clock tree: Core clock up to 112M, Bus clock up to 56M, Flash clock up to 28M. Clock can been from: System OSC、Slow IRC 、Fast IRC and System PLL 1. OSC SCG_SOSCCFG 2. PLL configuration formula: SPLL_CLK = (VCO_CLK)/2 VCO_CLK = SOSC_CLK/(PREDIV + 1) *(MULT + 16)  3. SCG_SPLLCSR void SystemClockInit(void) { SCG->SOSCCFG = 0x3C; SCG->SOSCCSR |= 1<<0; /* SOSCEN=1 enable SOSC clock */ /*wait clock active*/ while((SCG->SOSCCSR & SCG_SOSCCSR_SOSCVLD_MASK) == 0); SCG->SPLLCSR &= ~(0x1<<0) ; /* SPLLEN=0: disable PLL*/ SCG->SPLLCFG &= ~(0x7<<8); /* PREDIV=0: 1 */ SCG->SPLLCFG |= 0xCU<<16; /* MULT=12: 28   PLL VCO = 8/1*(12+16) = 224M */ SCG->SPLLCSR |= 0x1<<0; /* SPLLEN=1: enable PLL */ /* wait PLL active*/ while((SCG->SPLLCSR & SCG_SPLLCSR_SPLLVLD_MASK) == 0); SCG->RCCR |= SCG_RCCR_DIVCORE(0); /* DIVCORE=0: 1, CORE/SYS_CLK  112MHz */ SCG->RCCR |= SCG_RCCR_DIVBUS(1); /* DIVBUS=1: 2, BUS_CLK  56MHz */ SCG->RCCR |= SCG_RCCR_DIVSLOW(3); /* DIVSLOW=2: 4   FLASH_CLK  is 28MHz */ SCG->RCCR &= 0xFEFFFFFF; /* Initially set to SIRC so that LSB could be set as '0' */ SCG->RCCR |= SCG_RCCR_SCS(6); /* SCS=6: system clock System PLL */ }

This document shows the implementation of the infrared on the UART0 using the FRDM-KE02Z platform. The FRDM-KE02Z platform is a developing platform for rapid prototyping. The board has a MKE02Z64VQH2 MCU a Kinetis E series MCU which is the first 5-Volt MCU built on the ARM Cortex-M0+ core. You can check the evaluation board in the Freescale’s webpage (FRDM-KE02Z: Kinetis E Series Freedom Development Platform) The Freedom Board has a lot of great features and one of this is an IrDA transmitter and receiver on it. Check this out! One of the features of the MCU is that the UART0 module can implement Infrared functions just following some tricks (MCU-magic tricks). According to the Reference Manual (Document Number: MKE02Z64M20SF0RM) this tricks are:      UART0_TX modulation: UART0_TX output can be modulated by FTM0 channel 0 PWM output      UART0_RX Tag: UART0_RX input can be tagged to FTM0 channel 1 or filtered by ACMP0 module For this example we are going to use the ACMP0 module to implement the UART0_RX functionality. Note1: The Core is configured to run at the maximum frequency: 20 Mhz Note2: Refer to the reference manual document for more information about the registers. Configuring the FTM0. The next lines show the configuration of the FTM0; the module is configured with a Frequency of 38 KHz which is the ideal frequency for an infrared led. The FTM0_CH0 is in Edge_Aligned PWM mode (EPWM).           #define IR_FREQUENCY       38000 //hz      #define FTM0_CLOCK                BUS_CLK_HZ      #define FTM0_MOD_VALUE            FTM0_CLOCK/IR_FREQUENCY      #define FTM0_C0V_VALUE            FTM0_MOD_VALUE/2      void FTM0CH0_Init( void )      {        SIM_SCGC |= SIM_SCGC_FTM0_MASK;             // Init FTM0 to PWM output,frequency is 38khz        FTM0_MOD= FTM0_MOD_VALUE;        FTM0_C0SC = 0x28;        FTM0_C0V = FTM0_C0V_VALUE;        FTM0_SC = 0x08; // bus clock divide by 2      } With this we accomplish the UART0_TX modulation through a PWM on the FTM0_CH0. Configuring the ACMP0. The configuration of the ACMP0 is using a DAC and allowing the ACMP0 can be driven by an analog input.      void ACMP_Init ( void )      {        SIM_SCGC |= SIM_SCGC_ACMP0_MASK;        ACMP0_C1 |= ACMP_C1_DACEN_MASK |                   ACMP_C1_DACREF_MASK|                   ACMP_C1_DACVAL(21);    // enable DAC        ACMP0_C0 |= ACMP_C0_ACPSEL(0x03)|                            ACMP_C0_ACNSEL(0x01);        ACMP0_C2 |= ACMP_C2_ACIPE(0x02);  // enable ACMP1 connect to PIN        ACMP0_CS |= ACMP_CS_ACE_MASK;     // enable ACMP                } With this we have now implemented the UART0_RX.     IrDA initialization. Now the important thing is to initialize the UART0 to work together with these tricks and implement the irDA functions. Basically we initialize the UART0 like when we use normal serial communication (this is not the topic of this post, refer to the project to see the UART_init function) and we write to the most important registers:         SIM_SOPT |= SIM_SOPT_RXDFE_MASK; UART0_RX input signal is filtered by ACMP, then injected to UART0.      SIM_SOPT |= SIM_SOPT_TXDME_MASK; UART0_TX output is modulated by FTM0 channel 0 before mapped to pinout. The configuration is as follows:      void IrDA_Init( void )      { // initialize UART0, 2400 baudrate        UART_init(UART0_BASE_PTR,BUS_CLK_HZ/1000,2400);                  // clear RDRF flag        UART0_S1 |= UART_S1_RDRF_MASK;                  // initialize FTM0CH1 as 38k PWM output        FTM0CH0_Init();                      // enable ACMP        ACMP_Init(); SIM_SOPT |= SIM_SOPT_RXDFE_MASK;  //UART0_RX input signal is filtered by ACMP, then injected to UART0.        UART0_S2 &= ~UART_S2_RXINV_MASK;  //inverse data input SIM_SOPT |= SIM_SOPT_TXDME_MASK;  //UART0_TX output is modulated by FTM0 channel 0 before mapped to pinout.      } With the irDA initialization we got the infrared features on the UART0. Philosophy of the Example In the attachments of this post you can find the example which shows the use of these functions in a basic application; the project was compiled in CodeWarrior 10.6 and the philosophy is: I hope that the information presented on this document could be useful for you. Thank you! Best Regards!

Hi Community members! Here you can find the source code of the MSD Host Bootloader implemented on the AN4368 document using the TWR-K70F120M and CodeWarrior 10.6 and a document that describes the migration process of the original source code for the TWR-K60N512 to a TWR-K70F120M and the steps to use the application. Attached you will find a image.s19 file created to be used with the bootloader application as an example. :smileyinfo: This document and code are intended to demonstrate the use of the AN4368 source code on a 120 MHz device and CodeWarrior 10.6 but is not replacing the work done on the application note. I hope this can be helpful for you! Best Regards, Adrian :smileyplus: If it was useful for you do not forget to click on the Like button. It would be nice!