Kinetis软件开发套件知识库

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

Kinetis Software Development Kit Knowledge Base

标签

讨论

排序依据:
Examples for current KSDK 1.3 are located under C:\Freescale\KSDK_1.3.0\examples examples for middleware (tcpip, filesystem) under C:\Freescale\KSDK_1.3.0\middleware   There are more examples, which were created:   KSDK 1.3 Rainbow color using FTM PWM with KSDK 1.3 How to use printf() to print string to UART in KDS3.0 + KSDK1.3 Driving 16x2 LCD using KSDK drivers Integrating NFC Controller library with KSDK KL43Z support for sLCD and Touch sense using KDS3.0 +KSDK1.3.0 + Processor expert   KSDK 1.2 Using DMA to Emulate ADC Flexible Scan Mode with KSDK Writing my first KSDK1.2 Application in KDS3.0 - Hello World and Toggle LED with GPIO Interrupt Controlling speed in DC motors and position in servomotors with KSDK [FTM + GPIO] Line scan camera with KSDK [ADC + PIT + GPIO] A simple way to detect the track's center for the Freescale Cup Smart Race FatFs + SDHC data logger with KSDK in Kinetis Design Studio Segment LCD Example for KSDK KSDK GPIO driver with Processor Expert DAC Sinus Demo (using PEx + KSDK 1.2 + KDS 3.0) How to start customized KSDK project based on KSDK demo code   KSDK 1.1 An example project for FIR function implement on KV31 with SDK and CMSIS How to toggle LED in KDS 2.0 with KSDK 1.1.0 and Processor Expert KSDK SPI Master-Slave with FRDM-K64F Configuring Kinetis Software Development Kit (KSDK) to measure distance with ultrasonic transducers A demo project of USB HID bi-directional generic device for Kinetis SDK 1.1.0 Configuring Kinetis Software Development Kit (SDK) to measure distance with infrared (IR) sensor Writing my first KSDK Application in KDS - Hello World and GPIO Interrupt   KSDK 1.0 Writing your first toggle LED application with FRMD-K64F + KDS 1.1.0 + KSDK 1.0.0 Non-Processor Expert Low Power Application Using the SDK KSDK I2C EEPROM Example
查看全文
Hello community:   This document shows how to integrate a basic NFC (Near Field Communication) library to a KSDK project and explain its use with a simple demo project.   INTEGRATING NFC CONTROLLER LIBRARY   These instructions are based in the files usually present in a KSDK project. If your project has a custom source file structure, just add the referenced code accordingly.   1- Open the file gpio_pins.c and add 2 pin configurations: 1 input pin called NFCCirqPin and 1 output pin called NFCCvenPin:   gpio_input_pin_user_config_t NFCCirqPin = {    .pinName = kGpioNFCCirq,    .config.isPullEnable = false,    .config.pullSelect = kPortPullUp,    .config.isPassiveFilterEnabled = false,    .config.interrupt = kPortIntDisabled, }; gpio_output_pin_user_config_t NFCCvenPin = {    .pinName = kGpioNFCCven,    .config.outputLogic = 1,    .config.slewRate = kPortSlowSlewRate,    .config.driveStrength = kPortLowDriveStrength, };‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   2-  In the file gpio_pins.h add 2 extra elements to the gpio enumeration. Also add extern declarations for the 2 pins defined in the previous step.   NOTE: In this example the selected pins are PTB16 as IRQ and PTB17 as VEN. The pins depend on your routing from the Kinetis MCU to the NFC Controller board.   enum _gpio_pins {    kGpioLED1 = GPIO_MAKE_PIN(GPIOD_IDX,  5),  /* FRDM-KL43Z RBG LED Green LED */    kGpioLED2 = GPIO_MAKE_PIN(GPIOE_IDX, 31),  /* FRDM-KL43Z RBG LED Red LED   */    kGpioSW1 = GPIO_MAKE_PIN(GPIOA_IDX,  4),  /* FRDM-KL43Z SW1 */    kGpioSW3 = GPIO_MAKE_PIN(GPIOC_IDX,  3),  /* FRDM-KL43Z SW3 */    kGpioNFCCirq = GPIO_MAKE_PIN(GPIOB_IDX,  16), /* GPIO for NFCC IRQ pin */    kGpioNFCCven = GPIO_MAKE_PIN(GPIOB_IDX,  17), /* GPIO for NFCC VEN pin */ }; extern gpio_input_pin_user_config_t NFCCirqPin; extern gpio_output_pin_user_config_t NFCCvenPin;‍‍‍‍‍‍‍‍‍‍‍‍   3- In the file pin_mux.c define a function to configure the MUX setting of the required GPIO and I2C pins to interface with the NFC controller.   NOTE: The configured pins must correspond to the routing from the Kinetis MCU to the NFC controller board. In this case PTB16/PTB17 are set as GPIOs while PTE0/PTE1 are configured for I2C functionality. For I2C pins also check the MUX number in the device's Reference Manual (e.g. PTE0/PTE1 in KL43 have the I2C function in ALT6.   void configure_nfcc_pins(void) {    /** I2C_SDA **/    PORT_HAL_SetMuxMode(PORTE,0u,kPortMuxAlt6);    /** I2C_SCL **/    PORT_HAL_SetMuxMode(PORTE,1u,kPortMuxAlt6);    /* NFCC IRQ */    PORT_HAL_SetMuxMode(PORTB,16u,kPortMuxAsGpio);    /* NFCC VEN */    PORT_HAL_SetMuxMode(PORTB,17u,kPortMuxAsGpio); }‍‍‍‍‍‍‍‍‍‍‍   4- Add the prototype of the function to header file pin_mux.h.   /* ** =================================================== **     Method      :  configure_nfcc_pins */ /*! **     @brief **         Set mux configuration for I2C and GPIO pins **         to interface with the NFC Controller. */ /* ==================================================*/ void configure_nfcc_pins(void);‍‍‍‍‍‍‍‍‍‍‍   5- Add the NfcLibrary and TML folders with all its subfolders and files to your project's tree, so the library is part of the build. Also add the include paths to your compiler for the inc folders. Below an example with Kinetis Design Studio:                - Now the project is ready to use the NFC controller library. The library uses the next conditional compilation macros, add or remove these symbols from the compiler's preprocessor settings as required:   CARDEMU_SUPPORT: The NFC Controller host (MCU) emulates a contactless card which can be accessed by an external Reader/Writter. P2P_SUPPORT: The host MCU can establish a 2-way communication accesing to or sending information to an external Reader/Writter. RW_SUPPORT: With this mode the host can access a remote contactless tag/card via the NFC Controller. NCI_DEBUG: If defined, all information transfered between the host MCU and the NFC Controller Interface (commands, responses, notifications, data) is echoed to console for debug purposes.     DEMO PROJECT   The attached project is based on the application note AN11658 NXP-NCI NullOS integration example. So you can refer to the appnote for detailed information.   Software The project was developed with the next software versions:   - KSDK v1.3 - KDS v3.0.0 :smileyinfo: NOTES: -The KSDK platform library for the KL43 must be built before the example project. Otherwise the build fails due to library file missing (libksdk_platform.a). - Once the example project is imported please verify that the build variable PROJECT_KSDK_PATH is pointing to your KSDK v1.3 installation path.   Hardware - For the NFC part, I used the NFC Controller board from the OM5577, which is a demonstration kit for the PN7120 NFC controller Interface chip. - To interface with the NFC Contoller I used a FRDM-KL43Z Freedom board.     How to use the demo   R/W mode:   -  Placing a tag with a single text, URI or vCard NDEF record next to the NFC reader. Examples:                P2P mode:   - Bring an android phone with NFC enabled close to the NFC controller antenna and use the "beaming" feature. In the case below the NXP home page is "beamed" from the adroid phone's explorer:                     CARD EMULATION mode     For this mode it is required to remove the P2P_SUPPORT macro and rebuild/reprogram the project.   - Bringing an android phone set to read a NFC tag close to the NFC controller board:     I hope you like this document. Any questions or doubts please let me know in the comments.   Jorge Gonzalez NXP Technical Support
查看全文
Just today release new KSDK version 1.2. and KDS 3.0! Download here   For more details please visit our websites Software Development Kit for Kinetis MCUs|Freescale and Kinetis Design Studio Integrated Development |Freescale   What´s new   Added device family support:   MK10D10 MK66F18 MKL34Z4 MK11DA5 MKL02Z4 MKL36Z4 MK20D10 MKL14Z4 MKL43Z4 MK21DA5 MKL15Z4 MKV40F15 MK21FA12 MKL16Z4 MKV43F15 MK26F18 MKL17Z4 MKV44F15 MK30D10 MKL17Z644 MKV45F15 MK40D10 MKL24Z4 MKV46F15 MK50D10 MKL25Z4 MKW01Z4 MK51D10 MKL26Z4 MKW21D5 MK52D10 MKL27Z4 MKW22D5 MK53D10 MKL27Z644 MKW24D5 MK65F18 MKL33Z4 MK24F12 MK63F12   Added Peripheral support: AOI ENC FLEXBUS FLEXIO LMEM VREF XBAR PWM   Documentation   Kinetis SDK v.1.2.0 Release Notes http://cache.freescale.com/files/soft_dev_tools/doc/support_info/KSDK120RN.pdf?fsrch=1 Kinetis SDK v.1.2 API Reference Manual http://cache.freescale.com/files/soft_dev_tools/doc/support_info/KSDK12APIRM.pdf?fsrch=1 Kinetis SDK v.1.2 Demo Applications User's Guide http://cache.freescale.com/files/soft_dev_tools/doc/support_info/KSDK12DEMOUG.pdf?fsrch=1 Getting Started with Kinetis SDK (KSDK) v.1.2 http://cache.freescale.com/files/soft_dev_tools/doc/support_info/KSDK12GSUG.pdf?fsrch=1 MQX™ RTOS for Kinetis SDK 1.2.0 Release Notes http://cache.freescale.com/files/soft_dev_tools/doc/support_info/MQXKSDK120RN.pdf?fsrch=1   Porting an MQX RTOS Application to MQX RTOS for Kinetis SDK http://www.freescale.com/files/soft_dev_tools/doc/support_info/MQXKSDKPUG.pdf   for KDS 3.0. please don´t forget visit New Kinetis Design Studio V3.0.0 available   Enjoy! Iva
查看全文
I created easy tutorial for UART KSDK blocking demo which works as echo. The demo works with KSDK 1.1. and is created for KDS 2.0.   Because it could be problem if was used this pin by this reason was chosen UART 3, which is available to use and is routed to PTC16,PTC17 connection on Arduino header for this case is use ALT3 function (PTC16, PTC17)   Final output from terminal Physical connection between FRDM-K64F and USB to Serial Converter The unzipped folder must be located in example folder at C:\Freescale\KSDK_1.1.0\demos\
查看全文
Hardware and software configuration: FRDM-K22F, SCH-28164 REV D OpenSDA: J-Link firmware KDS 3.0 with SDK 1.2.0 Eclipse update installed KSDK 1.2 provides an Eclipse update for those who want to use the Kinetis SDK with Eclipse and Processor Expert. and with this update , users may find MSD Class component has been supported, and there is a simple USB mass storage demo available directly in this PEx USB component, so that customers may easily build this demo and develop their own application based on that. Here I will start to illustrate how to implement this demo step by step. As FRDM-K22F is used in this test, so I directly choose this board and make the following configuration: After above steps, we have a PEx project with some pre-installed components as shown below: clockMan1 components has 6 configurations , and one of it is for USB application, you may set it as the init configuration right now, or it would be set automatically when you add the USB MSD components. Now I find the MSD component from KSDK 1.2 and add it to my project: This component will add 4 more reference components into this project, and we only have to configure the component "fsl_debug_console" to get rid of the error mark. For FRDM-K22 board, UART1 is used as the debug console, and PTE0 and PTE1 are used as the TXD and RXD, so I set up this components as below: The simple MSD demo is a RAM disk demo, and it is disabled by default, so we have to enable it in the fsl_usb_device_msd_class component, and the demo code will be automatically added into the project afterwards: and then set the correct PID and VID information in the component of fsl_usb_descriptors. so far looks like all components are configured correctly , but if we directly download this application, we will have an enumeration issue like below: This is due to USB descriptors are placed to Flash memory area by default . You know , USB descriptors contain constant values so storing them in flash would leave more RAM for user application. The highlighted option in the following figure determines this . but USB module in Kinetis doesn't have the permission for flash out of reset, so we still have something to do before going ahead. There are several solutions for it, the most easiest way is setting the above option to "no", but we may do it in a PEx-like way by using the "Init_FMC" component. Please note USB is the M4 of K22's crossbar-lite. so we give it the "read only" permission. Init_FMC() is placed in Peripherals_Init() which is called right before  Components_Init() where USB_Class_MSC_Init () is in, so it guarantees USB have the flash access permission before it starts up. Now the demo can work well with the PC host, just as shown below: So far only HID and MSD Class components are supported, and if you go through a similar process as above, you may easily implement a HID demo by yourself. Here I attach both the MSD and HID mouse demo for your reference. Hope that helps,
查看全文
Hello to all,   This document explains how to drive a 16x2 LCD using the KSDK Drivers using the FRDM-KL25Z.     Project Generator, KSDK1.3 and KDS3.0 are used in this example.   I hope you find it useful. David
查看全文
This video shows how to use Processor Expert to configure the KSDK GPIO Peripheral Driver with the component fsl_gpio in Kinetis Design Studio. The steps show how to blink the red and blue LEDs while reading the SW2 button input of a FRDM-K64F. The procedure can be replicated for any KSDK supported board and also with PE Driver Suite. Enjoy!
查看全文
MCUXpresso Pins Tool allows you to configure pin routing and generates ‘pin_mux.c & h’ source files. This article describes how to configure Pins in a FreeRTOS project with MCUXpresso pins tool.  In this example, pin PTC9 on Freedom-k66 board is configured.   Software and Tools In this article, I’m using the following: MCUXpresso IDE 10.2.1   www.nxp.com/mcuxpresso ,  MCUXpresso SDK 2.4.1 for  Frdm-k66f  board.  With Amazon FreeRTOS v10 .You can get it from https://mcuxpresso.nxp.com FRDM-K66 board www.nxp.com/frdm-k66f First, we need to have a working FreeRTOS project. Here we import the freertos_hello example into MCUXpresso IDE workspace. To open the tool, simply right click on the project in Project Explorer and select the appropriate open command. Then we can see the pin table, peripheral signals, package/pinout view, Routed pins view, generated code view. Basic configuration can be done in either of these views Pins, Peripheral Signals or package. More advanced settings can be adjusted in Routed Pins view. Beginning with Peripheral selection In the Pins view on the left find a pin and peripheral signal in the table and configure the routing by clicking on the signal cell.   In this example, select PTC9.  Click into the cells to make them ‘green’ Select PTC9 on the Peripherals signals view, Routed Pins configure Route the selected signal to the desired pin,and configure it in the Routed Pins view. It is possible to easily identify routed pins/peripherals in the package using highlighting. By default, the current selection (pin/peripheral) is highlighted in the package view. State Indicator of Pin Tool Green indicates pin/peripheral is routed Yellow indicates pin/peripheral is currently selected Red indicates an error Light grey indicates pin/peripheral is available but is not currently routed. It is also possible to configure the pin electrical features. Use the table drop down menu to configure the pin. To configure pins, start from left to right—select the peripheral first, then select required signal, and finally select the routed pin. Code generation  The Pins Tool automatically generates the source code for pin_mux.c and pin_mux.h on the right panel of the Code Preview view. The configuration will be saved into .mex file, see picture below Export the code.   You can now copy-paste the content of the sources to the application and IDE. Alternatively, you can export the generated files. To export the files, select the menu  Export Click Next and specify the directory, Click Finish to export the files. Integrate code the FreeRTOS task In the source code, Board_InitBootPins() calls initial code in pin_mux.c/h In hello world task, we toggle the configured pin /*!  * @brief Task responsible for printing of "Hello world." message.  */ static void hello_task(void *pvParameters) {     for (;;)     {         PRINTF("Hello world.\r\n");         /* Toggle LED. */         GPIO_PortToggle(BOARD_LED_GPIO, 1U << BOARD_LED_GPIO_PIN);         vTaskDelay(200);     } }   Then run the example, we can see LED is toggled every 200ms.   For information about how to create an FreeRTOS project with MCUXpresso IDE, please see the following document https://community.nxp.com/docs/DOC-341972  For information about configuring with MCUXpresso peripheral tool in an FreeRTOS project, please see the following document. https://community.nxp.com/docs/DOC-341986
查看全文
Hello community,   This document shows the ease of use of the peripheral drivers from Kinetis SDK applied to the Freescale Cup smart car. This time I bring to you a document which explains how to make the line scan camera with KSDK works step-by-step. This document is intended to be an example for the ADC, the PIT and the GPIO peripheral drivers usage.   The required material to run this project is: Line scan camera (the project supports up to two cameras). FRDM-KL25Z based on the Kinetis Microcontroller KL25Z. FRDM-TFC shield. Mini-USB cable. TFC camera wire.   This material can be bought in The Freescale Cup Intelligent Car Development.              The document Create a new KSDK 1.2.0 project in KDS 3.0.0 explains how to create a new KSDK project for the KL25Z MCU. The result of this document is the project BM-KSDK-FRDM_KL25Z. The document Line scan camera with KSDK [ADC + PIT + GPIO] explains how to implement an application to acquire the data provided by the line scan camera. The result of this document is the project BM-KSDK-FRDM_KL25Z-LINE_SCAN_CAMERA.   The video below shows the line scan camera working.     If you are interested in participate in the Freescale Cup you could take a look into the groups University Programs, The NXP Cup Technical Reports The NXP Cup - Mexico, The NXP Cup - Brazil, The NXP Cup - China, The NXP Cup - Malaysia, The specified item was not found., The NXP Cup - North America, The specified item was not found., The NXP Cup - Taiwan, The NXP Cup EMEA.       Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer Freescale Semiconductor
查看全文
Download from Software Development Kit for Kinetis MCUs|NXP   How to: install KSDK 2.0 Using Kinetis Design Studio v3.x with Kinetis SDK v2.0   Kinetis SDK 2.0 API Reference Manual: Introduction   For older versions KSDK, KDS: Kinetis Design Studio Videos, Part 1: Installation of KDS and Kinetis SDK Kinetis Design Studio Videos, Part 2: Installation of OpenSDA Firmware on Freedom Board Kinetis Design Studio Videos, Part 3: Debugging with Kinetis Design Studio Kinetis Design Studio Videos, Part 4: Using Processor Expert in KDS   Installing Kinetis SDK into KDS Kinetis Design Studio V3.0.0- User´s Guide   other documentations you can download from Software Development Kit for Kinetis MCUs|NXP
查看全文
Created DAC Sinus example is PIT triggered with own buffer and is for FRDM-K64F.   adding analog component fsl_dac peripheral driver to project setting Voltage reference - Reference 2 for dac component (daConv1:fsl_dac) adding timer component fsl_pit peripheral driver to project setting period on 1 ms and enabling interrupts for timer component (pitTimer1:fsl_pit) setting buffer for sinusoidal in Sources -> Events.c #define DAC_TEST_BUFF_SIZE  (120U) uint16_t dac_buffer[DAC_TEST_BUFF_SIZE] =     {         0x7ff, 0x86a, 0x8d5, 0x93f, 0x9a9, 0xa11, 0xa78, 0xadd, 0xb40, 0xba1,         0xbff, 0xc5a, 0xcb2, 0xd08, 0xd59, 0xda7, 0xdf1, 0xe36, 0xe77, 0xeb4,         0xeec, 0xf1f, 0xf4d, 0xf77, 0xf9a, 0xfb9, 0xfd2, 0xfe5, 0xff3, 0xffc,         0xfff, 0xffc, 0xff3, 0xfe5, 0xfd2, 0xfb9, 0xf9a, 0xf77, 0xf4d, 0xf1f,        0xeec, 0xeb4, 0xe77, 0xe36, 0xdf1, 0xda7, 0xd59, 0xd08, 0xcb2, 0xc5a,         0xbff, 0xba1, 0xb40, 0xadd, 0xa78, 0xa11, 0x9a9, 0x93f, 0x8d5, 0x86a,         0x7ff, 0x794, 0x729, 0x6bf, 0x655, 0x5ed, 0x586, 0x521, 0x4be, 0x45d,         0x3ff, 0x3a4, 0x34c, 0x2f6, 0x2a5, 0x257, 0x20d, 0x1c8, 0x187, 0x14a,         0x112, 0xdf, 0xb1, 0x87, 0x64, 0x45, 0x2c, 0x19, 0xb, 0x2,         0x0, 0x2, 0xb, 0x19, 0x2c, 0x45, 0x64, 0x87, 0xb1, 0xdf,         0x112, 0x14a, 0x187, 0x1c8, 0x20d, 0x257, 0x2a5, 0x2f6, 0x34c, 0x3a4,         0x3ff, 0x45d, 0x4be, 0x521, 0x586, 0x5ed, 0x655, 0x6bf, 0x729, 0x794       }; uint16_t index = 0; void pitTimer1_IRQHandler(void) {   /* Clear interrupt flag.*/   PIT_HAL_ClearIntFlag(g_pitBase[FSL_PITTIMER1], FSL_PITTIMER1_CHANNEL);   /* Write your code here ... */    DAC_DRV_Output(FSL_DACONV1,dac_buffer[index++]);   if(index==DAC_TEST_BUFF_SIZE)       index = 0;  }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   FRDM-K64F with SALEAE   sinusoidal output     Enjoy! 🙂
查看全文
Kinetis SDK 1.1.0 is now officially released! You can download it via the big "Download" button on the KSDK website at http://freescale.com/ksdk   There are Windows and Linux 32-bit and 64-bit installers available. KSDK 1.1 will install in a new directory, which by default is C:\Freescale\KSDK_1.1.0, and will not interfere with previous installations of KSDK except to (optionally) update the Windows KSDK_PATH variable used by Kinetis Design Studio.   A high-level overview of what's new in KSDK 1.1 can be found in the Kinetis SDK 1.1 Release Notes but the most significant changes are: Additional devices supported Atollic TRUEStudio 5.2 is now supported Driver, HAL, and Platform Updates   There were also some other notable changes: GCC Make System Directory layout CMSIS-DAP/OpenOCD debug configurations now provided by default for KDS MQX for KSDK now included as option in the KSDK installer MQX Kernel 5.0.1 now supports lightweight configuration option   Details: 1)      Additional Devices The following devices are supported by Kinetis SDK 1.1 FRDM-K22F FRDM-K22F-K02* FRDM-K22F-K02 64* FRDM-K64F FRDM-KL03Z FRDM-KL46Z TWR-K22F120M TWR-K22F120M-K02* TWR-K24F120M TWR-K60D100M TWR-K64F120M TWR-KV10Z75M TWR-KV31F120M TWR-KV31F120M-KV30*   *These boards do not physically exist, but you can use the associated board to develop code for the subset devices listed. So for instance, if you're interested in the K02 device, use the FRDM-K22F for evaluation but use the K02 libraries provided to write code which will run on the K22F since it is a superset device.   2)      Atollic TRUEStudio 5.2 support   3)      Driver, HAL, and Platform Updates The HAL, Driver, and Platform code was updated with additional features, bug fixes, and enhancements. Several new peripherals are also supported which are listed in the Kinetis SDK 1.1 Release Notes. The Kinetis SDK v.1.1 API Reference Manual.pdf contains the latest KSDK API, and look at the updated demo projects for how to use the updated features like the power manager. There is now also the option to copy or not copy the vector table from ROM to RAM based on the linker file configuration using the ‘__ram_vector_table__’  argument in your IDE linker settings.   4)      GCC Make Changes Compiling with GCC now uses CMAKE.  Details on how to setup your system for compiling with GCC can be found in the GCC section of the <KSDK_path>/doc/Getting Started with Kinetis SDK (KSDK).pdf document. If you have "C:\MinGW\msys\x.x\bin" in your PATH variable (as required by KSDK 1.0.0), remove it to ensure that the new GCC build system works correctly.   5)      Directory Layout The HAL, Driver, and platform directory layout was slightly changed so that all the include files are now in a single directory instead of separate directories. This makes it simpler to add the include path into projects, and can also improve library compile times (by up to 50%). The KSDK platform library has also been slightly renamed to libksdk_platform.a   6)      CMSIS-DAP Debug Configuration OpenOCD debug configurations in Kinetis Design Studio are now provided by default for boards that use OpenSDAv2. OpenOCD makes use of the CMSIS-DAP debug protocol.   7)      MQX for KSDK Installer The Kinetis SDK 1.1 installer now includes options to install full MQX for KSDK support. The installation screen has also made it clearer during installation on how to select this option. There will no longer be a separate MQX for KSDK installer like there was for KSDK 1.0.   😎      MQX 5.0.1 Kernel Support of MQX Lite configuration and new example application rtos/mqx/examples/. There are provided options for creating tasks from statically allocated memory and application can define these tasks before MQX RTOS starts (using create_task() API). More changes are detailed in the MQX Release Notes in <KSDK_Path>/rtos/mqx/doc/Freescale MQX RTOS for Kinetis SDK Release Notes.pdf   This is just a high level overview of the changes, and should make developing applications using Kinetis SDK easier than ever.
查看全文
The latest Kinetis SDK 1.1.0 supported HID bi-directional communication, the new API USB_Class_HID_Recv_Data() can be used to receive data from USB HOST. But without demo and test tool, customer still has no idea about how to enstablish such kind of communication in their application. I create a simple demo derived from existed hid_keyboard project, together with basic endpoint read/write test by Bus Hound. The demo is built and tested on my FRDM-K64F and can be port to other USB Kinetis device as well. Working steps: 1) Unzip attached code and project to C:\Freescale\KSDK_1.1.0\usb\example\device\hid folder. 2) Compile project (IAR) and download to FRDM-K64F via CMSIS-DAP debugger. 3) Open Bus hound, enter "Devices" table and uncheck all box and check "auto select hot plugged devices". 4) Plug USB cable and connects to PC, will found the device is checked in bus hound device tree. 5) Double click device, and select OUT endpoint to send 16 bytes to device. 6) Observe the g_OUT_ep_buf[]'s change in firmware (Demostrate receive function only)
查看全文
Hi folks,   I would like to share my experience using lwIP with KSDK1.2, I hope this will be useful for people who is getting started with this TCP/IP stack.   I must admit that I really dislike working over an example application (please do not misunderstand my message, these examples are really nice but just as examples, not to develop new applications over them), the problem is that these project are not stand alone and if they are moved from their original locations it becomes a mess. This is why I always create a standalone projects. For instance I will describe how to run ‘lwip_tcpecho_demo’ and after this, how to reproduce this example as a standalone project.   Running ‘lwip_tcpecho_demo’ Creating a new project with lwIP support using FreeRTOS       I hope you find it useful.   Regards, Carlos
查看全文
Documentation for current KSDK 1.3 is located under C:\Freescale\KSDK_1.3.0\doc Application Notes and another documents are located under Software Development Kit for Kinetis MCUs|NXP   There are more documents, which were created:   KSDK 2.0 How to: install KSDK 2.0 Introducing Kinetis SDK v2 Using Kinetis Design Studio v3.x with Kinetis SDK v2.0   KSDK 1.3 How to add SD card support in the composite msd_cdc demo[KSDK 1.3] KSDK Clock configurations and Low Power modes with Processor Expert New Kinetis SDK Project Generator v2 is available! KSDK Project Generator - BUG workaround KSDK 1.3 Documents Plugin in KDS - is available now! KSDK 1.3.0 Documents Plugin for KDS 3.0.0   KSDK 1.2 Interrupt handling with KSDK and Kinetis Design Studio Creating a New USB project with KSDK and Processor Expert support in KDS IAR MQX TAD solution for "Unknown error" in Task error code (with KSDK) How to Add lwIP to KDS3.0 Project How to: Create a New FreeRTOS for KSDK1.2 Project in KDS3.0 How to Create a C++ Project Using MQX RTOS for KSDK1.2 How to implement a USB Device MSD demo based on KSDK PEx components and KDS 3.0 How to: execute the demo HVAC on lwIP TCP/IP Stack in KSDK Kinetis SDK FAQ Adding TAD shell in KSDK shell demo FRDM-KL43Z and KL33Z - standalone package New KSDK 1.2. is available! Getting started with KSDK: Building the demo applications   KSDK 1.1 KSDK 1.1 Release How to create copy of KSDK example in KDS UART Example with KSDK   KSDK 1.0 Create new KSDK Projects Kinetis SDK and FRDM-K64F Sharing one documentation issue in KSDK 1.0 demo user guide
查看全文
For this demo, Kinetis SDK was configured to implement a distance meter using a FRDM-K64F and the GP2D12 IR Sensor. The operating principle of this sensor consists in sending IR pulses and according to the existing distance between it and the reflective object, it generates different output voltages. Its analog output varies from 0.4 to 2.6 V approximately; the higher output voltage values are reached when the reflective object is closer to the sensor and the lower ones when it’s farther. The range of distance measured goes from 15 to 100 cm, if the distance from the sensor to the reflective object isn’t between this range, the demo’s results will not be reliable. The following figure depicts the application’s block diagram Figure 1. Block Diagram The signal received from the sensor goes through the Channel_1 at the instance 0 of the ADC module (ADC0_CH1), which is periodically triggered by the low power timer (every 125 µs). After getting every ADC’s sample an average is calculated from a total of 32 samples in order to make the ADC’s value reliable before using it to calculate the current distance. The application’s schematic diagram is shown in the following figure Figure 2. Schematic Diagram The required electrical connections to implement the application are explained below Table 1. Electrical connections   The following figure shows the application’s flow diagram    Figure 3. Flow Diagram   The required configuration for the ADC initialization in the application is shown on the following code snippet static int32_t init_adc(uint32_t uiInstance) {     /*      * Initialization ADC for      * 10bit resolution, interrrupt mode, hw trigger enabled.      * normal convert speed, VREFH/L as reference,      * disable continuous convert mode.      */     ADC16_DRV_StructInitUserConfigDefault(&adcUserConfig);     adcUserConfig.intEnable = true;     adcUserConfig.resolutionMode = kAdcResolutionBitOf10or11;     adcUserConfig.hwTriggerEnable = true;     adcUserConfig.continuousConvEnable = false;     adcUserConfig.clkSrcMode = kAdcClkSrcOfAsynClk;     ADC16_DRV_Init(uiInstance, &adcUserConfig);      /* Install Callback function into ISR. */     ADC_TEST_InstallCallback(uiInstance, CHANNEL_0, MyADCIRQHandler);      adcChnConfig.chnNum = IR_SENSOR_ADC_CHANNEL;     adcChnConfig.diffEnable = false;     adcChnConfig.intEnable = true;     adcChnConfig.chnMux = kAdcChnMuxOfA;     /* Configure channel0. */     ADC16_DRV_ConfigConvChn(uiInstance, CHANNEL_0, &adcChnConfig);      return 0; }             Here is the initialization of the ADC, the interrupt mode is enabled assigning the ‘true’ value to the variable adcUserConfig.intEnable, 10bit resolution is selected by kAdcResolutionBitOf10or11, the hardware trigger is enabled and the continuous conversion disabled with adcUserConfig.hwTriggerEnable and adcUserConfig.continuousConvEnable, respectively. Moreover, the selected clock source is asynchronous, kAdcClkSrcOfAsynClk. After these comes the call to the function ADC16_DRV_Init that receives as parameters the ADC uiInstance being used and a pointer to the structure adcUserConfig that contains the configuration selected by the user. The function ADC_TEST_InstallCallback installs the callback for the interrupt, its parameters are the uiInstance, the CHANNEL_0 from which will be received the interruption trigger and the name of the interruption handler function, MyADC1IRQHandler. The configurations for the ADC reading channel are the selection of the channel number adcChnConfig.chnNum (in this case it is being used the CHANNEL_1), the differential mode is disabled with the variable adcChnConfig.diffEnable, the trigger interrupt is enable at adcChnConfig.intEnable and with adcChnConfig.chnMux the channel multiplexer for a/b channel is selected by kAdcChnMuxOfA. Finally, the call to the function ADC16_DRV_ConfigConvChn receives the uiInstance number, the CHANNEL_0 for receiving the interrupt trigger and a pointer to the structure adcChnConfig that configures the ADC channel. The ADC trigger source initialization is presented below void init_trigger_source(uint32_t uiAdcInstance) {     lptmr_user_config_t lptmrUserConfig =     {         .timerMode = kLptmrTimerModeTimeCounter,         .freeRunningEnable = false,         .prescalerEnable = false, /* bypass prescaler */         .prescalerClockSource = kClockLptmrSrcMcgIrClk, /* use MCGIRCCLK */         .isInterruptEnabled = false     };      /* Init LPTimer driver */     LPTMR_DRV_Init(0, &lptmrUserConfig, &gLPTMRState);      /* Set the LPTimer period */     LPTMR_DRV_SetTimerPeriodUs(0, LPTMR_COMPARE_VALUE);      /* Start the LPTimer */     LPTMR_DRV_Start(0);      /* Configure SIM for ADC hw trigger source selection */     SIM_HAL_SetAdcAlternativeTriggerCmd(gSimBaseAddr[0], uiAdcInstance, true);     SIM_HAL_SetAdcPreTriggerMode(gSimBaseAddr[0], uiAdcInstance, kSimAdcPretrgselA);     SIM_HAL_SetAdcTriggerMode(gSimBaseAddr[0], uiAdcInstance, kSimAdcTrgSelLptimer); }            The user configuration for the LPTMR is located at the structure lptmrUserConfig, here the LPTMR Time Count mode is selected by kLptmrTimerModeTimeCounter, the free running mode, the prescaler and the timer interrupt are disabled with freeRunningEnable, prescalerEnable and isInterruptEnbled, respectively. Furthermore, the LPTMR clock source is selected as the Internal Reference Clock with kClockLptmrSrcMcgIrClk. The function LPTMR_DRV_Init receives as parameter the instance number, a pointer to the structure lptmrUserConfig that contains the user configurations and a pointer to the structure gLPTMRState with internal information of the LPTMR driver. The function LPTMR_DRV_SetTimerPeriodUs set the corresponding timer period for the LPTMR, its parameters are the ADC instance and LPTMR_COMPARE_VALUE that saves the period value in us. The LPTMR_COMPARE_VALUE macro is located and can be set at the lptmr_trigger.c file. Moreover, the user will be able to change this period during the execution time at the Variable Watch section in the FreeMASTER project, modifying the value of LPTMR Interrupt Time (us) and setting the LPTMR Time Flag on 1. LPTMR_DRV_Start starts the LPTMR and its only parameter is the ADC instance.                                           Finally, there are three functions that configure the SIM for the ADC hardware trigger source selection; they receive as parameters the array initializer of SIM peripheral base addresses, gSimBaseAddr[0], and uiAdcInstance. The function SIM_HAL_SetAdcAlternativeTriggerCmd enables/disables the alternative conversion triggers; in this case it receives a true value, so it is enabled. Moreover, SIM_HAL_SetAdcPreTriggerMode selects the pre-trigger source; its third parameter is kSimAdcPretrgselA that corresponds to Pre-trigger A. The last one, SIM_HAL_SetAdcTriggerMode, selects the trigger source, so it’s receiving kSimAdcTrgSelLptimer. The following code snippet shows the implemented algorithm to calculate the distance void GetCurrentDistanceValue(uint32_t uiAvgAdc) {     static uint32_t sdwCurrentDistance = 0;      uint32_t dwm = 0;     uint32_t dwb = 0;      if((520 <= uiAvgAdc) && (uiAvgAdc < 840))     {       dwm = 641;       dwb = 683970;     }     else if((260 <= uiAvgAdc) && (uiAvgAdc < 519))     {       dwm = 1337;       dwb = 1011000;     }     else if((130 <= uiAvgAdc) && (uiAvgAdc < 259))     {       dwm = 2941;       dwb = 1423500;     }     sdwCurrentDistance = (dwb-(dwm*uiAvgAdc));     g_dwDistanceIntegers = (sdwCurrentDistance/10000);     g_dwDistanceTenths = ((sdwCurrentDistance - (g_dwDistanceIntegers*10000))/1000); }            The implemented algorithm to calculate the distance is based on the division of the characteristic curve of the IR Sensor’s behavior in three different sections in order to approximate it to a linear behavior. Each line was generated from two different points. The first line is used when the uiAvgAdc value is between 520 and 840 (15 - 35 cm). The second one, for an uiAvgAdc value higher than 260 and lower than 519 (40 - 65 cm). And the last one, for uiAvgAdc values between 130 and 259 (70 - 100 cm). Depending on the calculated uiAvgAdc value, the slope (dwm) and the intersection with the y axis (dwb) change for each line.   In order to make the demo compatible with different microcontrollers and IDEs, it was necessary to avoid the use of float variables to calculate the distance, so that the result could be printed on a console without problems. The real values of the slopes and intersections with the y-axis for each line were multiplied by 10000. After getting sdwCurrentDistance value it is divided into integers and tenths; to get the integers at g_dwDistanceIntegers, the current distance is divided by 10000 and the corresponding fraction for tenths is stored in g_dwDistanceTenths. As a result, the current distance value is printed combining the integers and tenths variables, avoiding the use of a float variable.        The following graphic shows the characteristic curve and the three lines in which it was divided Figure 4. Characteristic curve’s graphic The application test’s results are shown in the following table 1 The error for the Distance Measured values is approximately ± 0.5 cm 2 The ADC Average values have an error of approximately ± 5 units Table 2. Test’s Results Steps to include IR sensor software to KSDK In order to include this demo in the KSDK structure, the files need to be copied into the correct place. The distance_measure_IRsensor folder should be copied into the <KSDK_install_dir>/demos folder. If the folder is copied to a wrong location, paths in the project and makefiles will be broken. When the copy is complete you should have the following locations as paths in your system: <KSDK_install_dir>/demos/distance_measure_IRsensor/iar <KSDK_install_dir>/demos/distance_measure_IRsensor/kds <KSDK_install_dir>/demos/distance_measure_IRsensor/src In addition, to build and run the demo, it is necessary to download one of the supported Integrated Development Enviroment (IDE) by the demo: Freescale Kinetis Design Studio (KDS) IAR Embedded Workbench      Once the project is opened in one of the supported IDEs, remember to build the KSDK library before building the project, if it was located at the right place no errors should appear, start a debug session and run the demo. The results of the distance measurement will be shown by UART on a console (use 115 200 as Baud rate) and at FreeMASTER, just as in the following example where the reflective object was located at 35 cm from the IR sensor: Figure 5. Example of the distance measured being shown in a console Figure 6. Example of the ADC Values obtained from the IR sensor monitored with FreeMASTER Figure 7. Example of the distance measured results at FreeMASTER FreeMASTER configuration For visualizing the application’s result on FreeMASTER it is necessary to configure the corresponding type of connection for the FRDM-K64F: 1. Open FreeMaster. 2. Go to File/Open Project. 3. Open the Distance Measurement IR Sensor project from <KSDK_install_dir>/demos/distance_measure_IRsensor/ FreeMaster. 4. Go to Project/Options. 5. On the Comm tab, make sure the option ‘Plug-in Module’ is marked and select the corresponding type of connection.    Figure 8. Corresponding configurations FRDM-K64F’s connection at FreeMASTER It is also necessary to select the corresponding MAP file for the IDE in which will be tested the demo, so: 6.  Go to the MAP Files tab. 7.  Select the MAP File for the IAR or the KDS project. *Make sure that the default path matches with the one where is located the MAP file of the demo at your PC. If not, you can modify the path by clicking on the ‘…’ button (see Figure 9) and selecting the correct path to the MAP file: <KSDK_install_dir>/demos/distance_measure_IRsensor/iar/frdmk64f/debug/distance_measure_IRsensor_frdmk64f.out <KSDK_install_dir>/demos/distance_measure_IRsensor/kds/frdmk64f/Debug/distance_measure_IRsensor_frdmk64f.elf 8.  Click on ‘OK’ to save the changes. Figure 9. Selection of the MAP File for each IDE supported by the demo I hope this demo to be useful for your applications, enjoy!
查看全文
The tutorial shows how to toggle LED with KSDK 1.1.0 in KDS 2.0 and Processor Expert using a Timer Output for FRDM-KL03Z. Guide is prepared for red LED which is connected to Timer/PWM Module 0 (TPM0), channel 1. Create new project Create new project in KDS 2.0 with KSDK 1.1.0 Type the project name, choose board. e.g. FRDM-KL03Z, mark off options Kinetis SDK and Processor Expert Now, the structure looks like this: Set Processor Expert Settings Now, go to Components Library, find fsl_tpm component and by double click add the component to Component View. Rename the component tpmTmr:fsl_tpm to e.g. RedLed. Double click on RedLed:fsl_tpm in Components View and see Component Inspector Follow these steps: Set frequency and duty cycle. Debug configuration DONE!
查看全文
Sharing a porting guide for the USB CCID demo from using EMVSIM module on K8x/KL8x to more general UART-ISO7816 module on Kinetis K devices. The demo has been tested with K64 tower board and one internal tower card named as TWR-ISO7816, MK64 is connected directly with smart card connector without using external PHY.   Attached the porting guide and associated demo code based on KSDK2.0.   When running the demo code, you will see console log similar as in attached log file. After installing driver according to the readme file with the USB CCID demo, you will see something as follows in device manager for smart card. Then you can use the PC test tool "Snooper" to talk to smart card.     Hao Original Attachment has been moved to: USB_CCID_MK64.zip Original Attachment has been moved to: USB-CCID-log.txt.zip
查看全文
For this demo, KSDK was configured to measure distance with a FRDM-K64F and the 255-400Sx16-ROX ultrasonic transducers. The transmitter transducer sends an ultrasound’s signal that travels through the air, after clashing with any object, the signal bounces and starts its way back until it gets to the receiver transducer. The time it takes for the ultrasound to arrive to the receiver can be use to measure the distance from the transducers to the object, because for a larger distance, the ultrasound’s travel time will be longer. When the receiver gets the ultrasound it generates an output signal, whose intensity is related to the distance to the reflective object, the signal is more intense for closer distances. The demo works for a range from 15 to 100 cm, if the distance to reflective object isn’t between this range, the results shown wouldn’t be reliable. The following figure shows the application’s block diagram Figure 1. Block Diagram        The schematic diagram for the application is shown in the following figure Figure 2. Schematic Diagram        The electrical connections needed to implement the demo are presented by this table Table 1. Electrical connections        The application’s flow diagram is displayed by the following figure Figure 3. Flow Diagram for Distance’s Calculation        The initial configuration for the FTM0 is presented in the following code snippet   void vfnFTM0_Config(void) {     ftm_user_config_t ftm0Info;          configure_ftm_pins(FTM_INSTANCE_0);          FTM_DRV_Init(FTM_INSTANCE_0, &ftm0Info);     FTM_DRV_SetTimeOverflowIntCmd(FTM_INSTANCE_0, true);     FTM_HAL_SetTofFreq(g_ftmBaseAddr[FTM_INSTANCE_0], TOF_FREQ_VALUE);          FTM_DRV_PwmStart(FTM_INSTANCE_0, &highTrueParam, HIGH_TRUE_PWM_CH);     FTM_DRV_PwmStart(FTM_INSTANCE_0, &lowTrueParam, LOW_TRUE_PWM_CH);     bPwmOnFlag = 1; }   The FTM0 was configured to generate two different signals of PWM that complement each other in order to duplicate their voltage’s range. First of all, it was necessary to configure the FTM0’s pins of the board, so that the PWM signals could be used externally to feed the ultrasonic Tx transducer. Then the FTM driver was initialized, the timer overflow interrupt was enabled and the NUMTOF was set to 14 so that just 15 PWM pulses were generated each time. Finally, the PWM was started at FTM0, generating a high true signal for channel 0 and low true for channel 1, these configurations were set from the structures highTrueParam and lowTrueParam of type ftm_pwm_param_t, in which the signals are configured as edge aligned, frequency of 40 kHz and the duty cycle is set to 50%.        The FTM0 IRQ Handler function was modified to match with the demo requirements   void FTM0_DRV_MyIRQHandler(void) {     FTM_DRV_IRQHandler(0U);     bDeadTimeCount++;     if(bPwmOnFlag)     {         FTM0_OUTMASK ^= PWM_CHANNELS_OUTMASK;         swPWMDeparture_CountVal = FTM2_CNT;         FTM_HAL_SetSoftwareTriggerCmd(g_ftmBaseAddr[0], true);         bPwmOnFlag = 0;     }     else if((!bPwmOnFlag) && (bDeadTimeCount == 50))     {         vfnStartPwm();         bDeadTimeCount = 0;     } }   After every 15 FTM0’s overflows this function was accessed and every 50 access to it determined the PWM dead time, which refers to the time between the sending of a PWM signal and the next one. The PWM dead time is necessary to avoid the clash of a signal being transmitted by the Tx transducer and the one that is returning to enter to the Rx, this clash could affect the genuine signal that bounced against the reflective object and also affect the distance measure’s results. If the PWM signals were active when entering to this function, then they should be disabled with the FTM0 outmask, this would assure that the sending pulses are just 15 and it would be harder that the returning bounced signal clashes with a prolonged sending signal. After disabling the PWM bPWMOnFlag is set to 0. On the other hand, if the bPWMOnFlag is disabled and the bDeadTimeCount has achieved the corresponding counts, the PWM is restarted and the bDeadTimeCount is set to 0.   The FTM2’s initial configurations are stated on the following code snippet void vfnFTM2_Config(void) {     ftm_user_config_t ftm2Info;          configure_ftm_pins(FTM_INSTANCE_2);     FTM_DRV_Init(FTM_INSTANCE_2, &ftm2Info);     FTM_HAL_SetClockPs(g_ftmBaseAddr[FTM_INSTANCE_2], kFtmDividedBy16);     FTM_DRV_SetTimeOverflowIntCmd(FTM_INSTANCE_2, true);          vfnInputCaptureStart(); }   For the FTM2, which was used for input capture mode, in this function were configured their pins, the driver was initialized, the clock prescaler was set to 16 and the timer overflow interrupt was enabled before calling to the function vfnInputCaptureStart(), in which are established more specific configurations for the input capture.   The FTM2 IRQHandler was also modified to trigger the required actions for the demo’s functionality void FTM2_DRV_MyIRQHandler(void) {     if ((FTM2_SC & 0x80))     {         bFtm2OverflowCount++;         FTM_HAL_ClearTimerOverflow(g_ftmBaseAddr[2]);     }     else     {         FTM_HAL_DisableTimerOverflowInt (g_ftmBaseAddr[2]);         CMP_DRV_Stop(1);         vfnGetPwmArriveTime();         vfnGetPwmTravelTime();         FTM_HAL_ClearChnEventStatus(g_ftmBaseAddr[2], 0);         bFtm2OverflowCount = 0;     } }   This function is accessed whether a timer overflow occurs or if a rising edge is detected by the input capture. If an overflow occurred then the overflow bit is clear and bFtm2OverflowCount’s value is increased by 1, this count is important for the signal’s travel time calculation. On the contrary, if the IRQ handler function is accessed because of the detection of a rising edge by the input capture, the timer overflow interrupt is disabled to avoid the count of time after the edge detection and to assure the correct travel time calculation. After storing the FTM2 count value as the arrive time of the signal, the function vfnGetPwmTravelTime() is called to calculate the total period of time that the signal spent on its travel through the air. Additionally the bFtm2OverflowCount is set to 0.        The comparator’s configurations are displayed on this function   void vfnCMP1_Config(void) {     cmp_user_config_t cmpParam =      {           .hystersisMode = kCmpHystersisOfLevel0, /*!< Set the hysteresis level. */           .pinoutEnable = true, /*!< Enable outputting the CMP1 to pin. */           .pinoutUnfilteredEnable = false, /*!< Disable outputting unfiltered result to CMP1. */           .invertEnable = false, /*!< Disable inverting the comparator's result. */           .highSpeedEnable = false, /*!< Disable working in speed mode. */       #if FSL_FEATURE_CMP_HAS_DMA           .dmaEnable = true, /*!< Enable using DMA. */       #endif /* FSL_FEATURE_CMP_HAS_DMA */           .risingIntEnable = true, /*!< Enable using CMP1 rising interrupt. */           .fallingIntEnable = false, /*!< Disable using CMP1 falling interrupt. */           .plusChnMux = kCmpInputChn1, /*!< Set the Plus side input to comparator. */           .minusChnMux = kCmpInputChn3, /*!< Set the Minus side input to comparator. */       #if FSL_FEATURE_CMP_HAS_TRIGGER_MODE           .triggerEnable = true, /*!< Enable triggering mode.  */       #endif /* FSL_FEATURE_CMP_HAS_TRIGGER_MODE */       #if FSL_FEATURE_CMP_HAS_PASS_THROUGH_MODE           .passThroughEnable = true  /*!< Enable using pass through mode. */       #endif /* FSL_FEATURE_CMP_HAS_PASS_THROUGH_MODE */     };          cmp_sample_filter_config_t cmpFilterParam =     {         .workMode = kCmpSampleWithFilteredMode, /*!< Sample/Filter's work mode. */         .useExtSampleOrWindow = false, /*!< Switcher to use external WINDOW/SAMPLE signal. */         .filterClkDiv = 32, /*!< Filter's prescaler which divides from the bus clock.  */         .filterCount =  kCmpFilterCountSampleOf7 /*!< Sample count for filter. See "cmp_filter_counter_mode_t". */     };       cmp_state_t cmpState;     configure_cmp_pins(CMP_INSTANCE_1);     CMP_DRV_Init(CMP_INSTANCE_1, &cmpParam, &cmpState);     CMP_DRV_ConfigSampleFilter(CMP_INSTANCE_1, &cmpFilterParam);     CMP_DRV_Start(CMP_INSTANCE_1); }   The initial configuration’s parameters for the comparator are stated on the structure cmpParam. First of all, the CMP1 input and output was enabled, the rising interrupt was enabled too. In addition, channel 1 was set as the plus side input of the comparator; this channel is the one that receives the output of the ultrasonic Rx transducer. On the other hand, channel 3 was configured as the minus side input of the comparator, this channel corresponds to the 12-bit DAC module that sets the comparison value. Finally, the trigger and the pass through mode were enabled. It was necessary to stabilize the comparators results, so a sample filter was configured in sample with filter mode, the filter’s prescaler for clock was set to 32 and the filter count sample was set to 7 samples.   After establishing all these parameters, the comparator’s pins were configured, the driver was initialized, the filter was configured to the CMP1 and the driver was started.        The 12-bit DAC was configured to generate the comparison value, as shown in this code snippet   void vfnDAC12_Config(void) {     dac_user_config_t dacParam;          // Set configuration for basic operation     DAC_DRV_StructInitUserConfigNormal(&dacParam);     // Initialize DAC with basic configuration     DAC_DRV_Init(DAC_INSTANCE_0, &dacParam);     // Set DAC's Comparison Value     DAC_DRV_Output(DAC_INSTANCE_0, CMP_DAC_VALUE); }        The DAC’s configuration was simple, the default configurations were used for this one, the driver was initialized and the comparison value was set to 4020. This value was selected according to the Rx transducer’s output signal, the comparison value was determined by the levels achieved, so that the demo could be able to detect a reflective object in all the distance’s range (15 to 100 cm).        The initialization for input capture mode are shown in this function   void vfnInputCaptureStart(void) {     FTM_HAL_SetChnEdgeLevel(g_ftmBaseAddr[FTM_INSTANCE_2], INPUT_CAPTURE_CH, INPUT_CAPTURE_RISING_EDGE);     FTM_HAL_SetMod(g_ftmBaseAddr[FTM_INSTANCE_2], FTM2_MOD_VALUE);     FTM_HAL_EnableChnInt(g_ftmBaseAddr[FTM_INSTANCE_2], INPUT_CAPTURE_CH);     FTM_HAL_SetChnInputCaptureFilter(g_ftmBaseAddr[FTM_INSTANCE_2], INPUT_CAPTURE_CH, INPUT_CAPTURE_FILTER_VAL);     FTM_HAL_SetCountReinitSyncCmd(g_ftmBaseAddr[FTM_INSTANCE_2], true);     FTM_HAL_SetCounterInitVal(g_ftmBaseAddr[FTM_INSTANCE_2], FTM2_COUNTER_INIT_VALUE);     FTM_HAL_SetClockSource(g_ftmBaseAddr[FTM_INSTANCE_2], kClock_source_FTM_SystemClk); }        The input capture’s configurations for the demo were: rising edge mode, the MOD value was set to its maximum (0xFFFF), the FMT2_CH0’s interrupt was enabled, the filter on the input was enabled to help in the stabilization of the signal being analyzed, the counter’s init value is set to 0 and finally, the system clock is selected as the clock source.        The function vfnStartPwm is the one that enables the PWM sending   void vfnStartPwm(void) {     FTM2_CNT = FTM2_COUNTER_INIT_VALUE;     FTM0_OUTMASK ^= PWM_CHANNELS_OUTMASK;     bPwmOnFlag = 1;     FTM_HAL_SetSoftwareTriggerCmd(g_ftmBaseAddr[FTM_INSTANCE_0], true);     FTM_HAL_EnableTimerOverflowInt (g_ftmBaseAddr[FTM_INSTANCE_2]);     CMP_DRV_Start(CMP_INSTANCE_1); }        Before enabling the PWM signals, the FTM2 count value is stored as the sending time of the signal, then the FTM0 outmask de PWM channels, the bPWMOnFlag is set to 1 and the comparator driver is start in order to wait the Rx transducer’s response.        The signal’s travel time calculation algorithm is presented in the following code snippet   void vfnGetPwmTravelTime(void) {     uint32_t wTimeDifference = 0;     static uint8_t bAux_OFCount = 0;     static uint32_t waTimeBuffer[TIME_SAMPLES];     static uint8_t bTimeSamples = 0;          bAux_OFCount = (bFtm2OverflowCount-1);          if(bFtm2OverflowCount != 0)     {         if(bAux_OFCount != 0)         {             wTimeDifference = (FTM2_MOD_VALUE * bAux_OFCount);         }         else         {             wTimeDifference = 0;         }         wTimeDifference = (wTimeDifference + (FTM2_MOD_VALUE - swPWMDeparture_CountVal));         wTimeDifference = (wTimeDifference + swPWMArrive_CountVal);     }     else     {         wTimeDifference = (swPWMArrive_CountVal - swPWMDeparture_CountVal);     }          waTimeBuffer[bTimeSamples] = wTimeDifference;     if(bTimeSamples != TIME_SAMPLES)     {         bTimeSamples++;     }     else     {         wAverageTravelTime = dwGetTravelTimeAverage(TIME_SAMPLES, waTimeBuffer);         vfnGetCurrentDistance();         bTimeSamples = 0;     } }   The travel time’s calculation algorithm is simple. If just one overflow occurred during the signal’s traveling period, the time difference is calculated as the difference of the FTM2_MOD_VALUE and the FTM2 counter value at the departure time, plus the counter value at the arriving time. Otherwise, if more than one overflow occurred then the time difference is the same as the last case, but adding the product of the FTM2_MOD_VALUE and the overflow’s counts minus 1. The simplest case is the one there haven’t been overflows, the time difference is calculated subtracting the departure counter value from the arriving counter value. After obtaining 20 samples of travel time an average of all these values is calculated so that the time data is the most reliable possible.   The distance calculation algorithm was implemented on the following function   void vfnGetCurrentDistance(void) {     static uint64_t dwDistance = 0;     uint8_t b_m = 3;     uint32_t w_b = 27130000;     uint32_t w_FixedPointAux = 100000;     uint16_t swTimeBase = 265;          // 265ns per FTM2 Count          wAverageTravelTime >>= 1;        wAverageTravelTime = (wAverageTravelTime*swTimeBase);          dwDistance = (wAverageTravelTime * w_FixedPointAux);     dwDistance = (dwDistance * b_m);     dwDistance = (dwDistance / w_FixedPointAux);     dwDistance = (dwDistance - w_b);          bDistanceIntegers = (dwDistance / w_FixedPointAux);       bDistanceUnits = (dwDistance % w_FixedPointAux);     bDistanceUnits = (bDistanceUnits / 10);          bDistanceReadyFlag = 1; }   The distance calculation is based on the linear behavior of the transducers’ response. Some samples of the signal’s travel time were taken for distances from 15 to 80 cm and according to that data, it was calculated a linear equation that describes the calculated travel time in function of the distance to the reflective object (See Figure 4 below). After getting the time difference, in FTM2 counts, between the departure and the arriving time of the signal, it was necessary to divide that number of counts, because that time difference corresponds to the travel of the signal to the reflective object and back to the transducers. Furthermore, it was required to convert those counts to real time, and according to the configurations of the FTM2, each of its counts was equal to 265 ns. The rest of the algorithm consists just on the use of the linear equation the travel time as variable, multiplying by the corresponding slope (b_m) and adding the intersection with the y-axis (w_b). The real values of the slope and the intersection with the y-axis were fixed in order to avoid the use of float variables.   The following graphic shows the characteristic linear behavior of the relation between the signal’s travel time and the distance from the transducers to the reflective object Figure 4. Characteristic curve’s graphic   The application test’s results are shown in the following table 1 The error for the Distance Measured is approximately ± 2 cm for short distances and ± 5 cm for the longer ones Table 2. Test’s Results        Steps to include the ultrasonic distance measurer demo in KSDK   In order to include this demo in the KSDK structure, the files need to be copied into the correct place. The ultrasonic_distance_measurer folder should be copied into the <KSDK_install_dir>/demos folder. If the folder is copied to a wrong location, paths in the project and makefiles will be broken. When the copy is complete you should have the following locations as paths in your system: <KSDK_install_dir>/demos/ultrasonic_distance_measurer/iar <KSDK_install_dir>/demos/ultrasonic_distance_measurer/kds <KSDK_install_dir>/demos/ultrasonic_distance_measurer/src In addition, to build and run the demo, it is necessary to download one of the supported Integrated Development Enviroment (IDE) by the demo: Freescale Kinetis Design Studio (KDS) IAR Embedded Workbench Once the project is opened in one of the supported IDEs, remember to build the KSDK library before building the project, if it was located at the right place no errors should appear, start a debug session and run the demo. The results of the distance measurement will be shown by UART on a console (use 115 200 as Baud rate) and at FreeMASTER, just as in the following example where the reflective object was located at 35 cm from the ultrasonic transducers: Figure 5. Example of the distance measured being shown in a console Figure 6. Example of the distance measure results at FreeMASTER      FreeMASTER configuration For visualizing the application’s result on FreeMASTER it is necessary to configure the corresponding type of connection for the FRDM-K64F:           1. Open FreeMaster.           2. Go to File/Open Project.           3. Open the Ultrasonic Distance Measurer project from <KSDK_install_dir>/demos/ultrasonic_distance_measurer/ FreeMaster.           4. Go to Project/Options.          On the Comm tab, make sure the option ‘Plug-in Module’ is marked and select the corresponding type of connection. Figure 7. Corresponding configurations FRDM-K64F’s connection at FreeMASTER   It is also necessary to select the corresponding MAP file for the IDE in which will be tested the demo, so:           1. Go to the MAP Files tab.           2. Select the MAP File for the IAR or the KDS project. *Make sure that the default path matches with the one where is located the MAP file of the demo at your PC. If not, you can modify the path by clicking on the ‘…’ button (see Figure 😎 and selecting the correct path to the MAP file: <KSDK_install_dir>/demos/ultrasonic_distance_measurer/iar/frdmk64f/debug/ultrasonic_distance_measurer_frdmk64f.out <KSDK_install_dir>/demos/ultrasonic_distance_measurer/kds/frdmk64f/Debug/ultrasonic_distance_measurer_frdmk64f.elf   Click on ‘OK’ to save the changes.   Figure 8. Selection of the MAP File for each IDE supported by the demo   Enjoy the demo!
查看全文