This example project shows how to use CMSIS DSP functions to implement a digital filter. The project is based on Kinetis KV31F512.   It first generates a mixed signal which is composed by two sine waves.  Then it uses PDB to trigger DAC every 200 microsecond and output the signal through DAC, so that the mixed signal can be displaying on oscilloscope.   With QEDesign tool, a lowpass filter is designed, the filter coefficients are used directly to initialize the FIR function supplied by CMSIS DSP library. This example calls the FIR functions in CMSIS DSP lib, and the filtered signal is output though DAC module.

Very simple, but very often asked question - how can I import example in KSDK general? The easiest way is import .wsd file, it is a set of all needed files for your project.   1. Open KDS, go to Project Explorer Window and by right click select Import option 2. Choose Existing Projects Sets option 3. Click on Browse and select the project, which you would like to work. In case of KSDK 2.0 go to C:\Freescale\<ksdk2.0_package>\boards\frdmk64f\demo_apps\lwip\lwip_tcpecho\freertos\kds   4. You will see the demo project successfully imported in your Project Explorer window and now you can compile and execute demo project.   Enjoy! Iva

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

LwIP is a small independent implementations of the TCP/IP protocol suite that has been initially developed by Adam Dunkels . The focus of the lwIP TCP/IP implementation is to reduce resource usage while still having a full scale TCP. This makes lwIP suitable for use in embedded systems with tens of kilobytes of free RAM and room for around 40 kilobytes of code ROM.  Currently LwIP 2.1.2 is ported to Kinetis and I.MX RT families in MCUXpresso SDK 2.6 . Features: LwIP comes with the following protocols: IPv4 and IPv6, including packet forwarding over multiple network interfaces. ICMP for network maintenance and debugging IGMP for multicast traffic management MLD (Multicast listener discovery for IPv6).  ND (Neighbor discovery and stateless address autoconfiguration for IPv6) DHCP and DHCPv6. UDP (User Datagram Protocol) TCP (Transmission Control Protocol) Raw/native API for enhanced performance Optional Berkeley -  like socket API. TLS: optional layered TCP for nearly transparent TLS for any TCP-based protocol PPPoS and PPPoE DNS (Domain name resolver incl. mDNS) 6LoWPAN Organization of the LwIP stack Let’s take SDK_2.6.1_EVKB-IMXRT1050 for example, LwIP code in under SDK_2.6.1_EVKB-IMXRT1050\middleware\lwip Port: This folder includes the adapter code which can make the LwIP stack run on the bare metal and FreeRTOS. Enet_ethernetif.c/h: Adapt the LwIP stack to the underlying MCUXpresso SDK ethernet driver, provides ethernet interfaces , like  phy init and  ethernetif_input. cc.c/h: provide typedefs, compiler hints for packing and platform specific diagnostic output. Perf.h: architecture specific performance measurement, current the definitions is NULL, reserve for future use. Src: This folder includes the latest stable LwIP 2.1.2 source code which can be downloaded from below link download.savannah.gnu.org/releases/lwip/ --api: netconn and socket API files --core: LwIP core files --include: LwIP include files --netif:  network interface files LwIP APIs overview LwIP provides three application programming interfaces (API) for programmers to use for communication with the TCP/IP code: Raw APIs:   Non thread-safe APIs, callback style for maximum performance and minimum memory footprint. Program execution is driven by callbacks functions, which are then invoked by the lwIP core when activity related to that application occurs. A particular application may register to be notified via a callback function for events such as incoming data available, outgoing data sent, error notifications, poll timer expiration, connection closed, etc. An application can provide a callback function to perform processing for any or all of these events. Sequential-style APIs:    blocking functions. More overhead, but can be called from any thread except TCPIP thread. The sequential API provides a way for ordinary, sequential, programs to use the lwIP stack. It is quite similar to the BSD socket API. The model of execution is based on the blocking open-read-write-close paradigm. Since the TCP/IP stack is event based by nature, the TCP/IP code and the application program must reside in different execution contexts (threads). Socket API: BSD-style socket API.  The socket API is a compatibility API for existing applications, currently it is built on top of the sequential API. It is meant to provide all functions needed to run socket API applications running on other platforms. TCP Raw API   API function Description TCP connection setup   tcp_new() Creates a new TCP PCB tcp_bind() Binds a TCP PCB to a local IP address and port tcp_listen() Starts the listening process on the TCP PCB. tcp_accept() Assigns a callback function that will be called when a new TCP connection arrives. tcp_connect() Used to connect to a remote TCP host. Sending TCP data tcp_write() Queues up data to be sent. tcp_output() Forces queued data to be sent tcp_sent() Assigns a callback function that will be called when sent data is acknowledged by the remote host. Receiving TCP data tcp_recv() Sets the callback function that will be called when new data arrives. tcp_recved() Must be called when the application has processed the incoming data packet (for TCP window management). Application polling tcp_poll() Assigns a callback functions that will be called periodically. It can be used by the application to check if there is remaining application data that needs to be sent or if there are connections that need to be closed. Closing and aborting connections tcp_close() Closes a TCP connection with a remote host. tcp_abort() Aborts a TCP connection. tcp_err() Assigns a callback function for handling connections aborted by the lwIP due to errors (such as memory shortage errors). UDP Raw API API Description udp_bind Binds a UDP PCB with a local IP address and port. udp_new Creates a new UDP PCB. udp_send Sends UDP data. udp_recv Specifies a callback function which is called when a datagram is received udp_remove Removes and de-allocates a UDP PCB. udp_connect Sets up a UDP PCB remote IP address and port udp_disconnect Removes a UDP PCB remote IP and port. Netconn API netconn_new Creates a new connection netconn_listen Sets a TCP connection into a listening mode netconn_write Sends data on a connected TCP netconn netconn_accept Accepts an incoming connection on a listening TCP connection netconn_close Closes a TCP connection without deleting it. netconn_send Sends data to the currently connected remote IP/port (not applicable for TCP connections). netconn_bind Binds a connection to a local IP address and port. netconn_recv Receives data from a netconn. netconn_connect Connects to a remote IP address and port. …   Socket API Macro API description accept lwip_accept Accepts a new connection on a socket bind  lwip_bind Binds a socket to an IP address and port shutdown  lwip_shutdown   getpeername  lwip_getpeername   getsockname lwip_getsockname   setsockopt lwip_setsockopt   closesocket  lwip_close   connect lwip_connect Connects a socket to a remote host IP address and port. listen  lwip_listen Listens for socket connections recv  lwip_recv   recvmsg lwip_recvmsg   recvfrom  lwip_recvfrom   send  lwip_send   sendmsg  lwip_sendmsg   sendto lwip_sendto   socket  lwip_socket Creates an new socket. poll lwip_poll   ioctlsocket lwip_ioctl   inet_ntop  lwip_inet_ntop   inet_pton  lwip_inet_pton   read  lwip_read Reads data from a socket readv lwip_readv   write lwip_write Writes data on a socket writev lwip_writev   close  lwip_close Closes a socket (socket is deleted). fcntl  lwip_fcntl   ioctl lwip_ioctl         LwIP Configure Configuration file is placed in application source folder: Lwipopts.h: Lwipopts.h is a user file that you can use to fully configure LwIP and all of it’s modules. You do not need to define every option that LwIP provides; if you do not define an option, a default value will be used. Therefore, your lwipopts.h provides a way to override much of the behavior of LwIP. LwIP Demos in MCUXpresso SDK MCUXpresso SDK comes with lots of demos that use different API sets. Name Description Lwip_tcpecho a TCP echo demo on the lwIP TCP/IP stack with bare metal KSDK or FreeRTOS. The demo uses the TCP protocol and acts as an echo server Lwip_udpecho a UDP echo demo on the lwIP TCP/IP stack with bare metal KSDK or FreeRTOS, which uses the UDP protocol and acts as an echo server. Lwip_ping a Ping Demo on the lwIP TCP/IP stack which using the ICMP protocol lwip_nghttp2cli_mbedTLS an NGHTTP2 client set up on lwIP TCP/IP and the MbedTLS stack with FreeRTOS lwip_mqtt MQTT client connecting to MQTT broker via unsecured socket lwip_iperf check your bandwidth using the network performance measurement IPerf application on a PC as a client or a server lwip_httpsrv an HTTPServer on the lwIP TCP/IP stack with bare metal SDK or FreeRTOS lwip_httpscli_mbedTLS an HTTPS client set up on lwIP TCP/IP and the MbedTLS stack with FreeRTOS lwip_dhcp_usb a DHCP and ping demo on the lwIP TCP/IP and USB stack lwip_dhcp a DHCP client and prints the status as it is progressing

This article is for beginners. It describes how to create an FreeRTOS project based on MCUXpresso IDE 10.2.1. 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 Before creating a FreeRTOS project, you have to install SDK first. Download the SDK package SDK_2.4.1_FRDM-K66F.zip,  drag and drop it into the “Installed SDKs” view. You will be prompted with a dialog asking you to confirm the import –click OK. The SDK will be automatically installed into MCUXpresso IDE part support repository. Quick Start Go to the ‘QuickStart’ Panel in the bottom left of the MCUXpresso IDE window, and click new project. On the “Board and/or device selection” page, select board frdmk66f. You will see some description relating to the your selection. Click ‘next’… You will see the basic project creation and setting page. Basic setting The project will be given a default name based on the MCU name. Name the project, select the right device package. Board files: This field allows the automatic selection of a default set of board support files, else empty board files will be created. Project type:  Selecting ‘C’ will automatically select Redlib libraries, selecting c++ will select NewllibNaro librarires. Project option: enable semihost will cause the semihost variant of the chosen library to be selected;  CMSIS-Core will cause a CMSIS folder containing a variety of support code to be created. OS: For a FreeRTOS project, make sure FreeRTOS is selected. Please select the drivers and utilities according to your requirements. Click ‘next’, you will go to advanced project settings page. Advanced Project setting This page will take certain default options based on settings from the first wizard project page. Set library type:    Please use Redlib for C projects, and NewlibNarno for SDK C++ projects. Next panel allows options to be set related to Input/Output. Hardware settings: set options such as the type of floating point support available/required. MCU C compiler:  Set various compiler options Click ‘finish’ will create a simple ‘hello world’ C project for Freedom K66f . Basically does the initialization of the pins, clocks, debug console and peripherals. int main(void) {          /* Init board hardware. */     BOARD_InitBootPins();     BOARD_InitBootClocks();     BOARD_InitBootPeripherals();        /* Init FSL debug console. */     BOARD_InitDebugConsole();       PRINTF("Hello World\n");       /* Force the counter to be placed into memory. */     volatile static int i = 0 ;     /* Enter an infinite loop, just incrementing a counter. */     while(1) {         i++ ;     }     return 0 ; } Click the project settings, we can see some basic information of this project, a right click on these nodes provides direct options to edit the associated setting. Add FreeRTOS task #include <stdio.h> #include "board.h" #include "peripherals.h" #include "pin_mux.h" #include "clock_config.h" #include "MK66F18.h" #include "fsl_debug_console.h" /* TODO: insert other include files here. */   /* FreeRTOS kernel includes. */ #include "FreeRTOS.h" #include "task.h"     /* TODO: insert other definitions and declarations here. */           /* Task priorities. */ #define my_task_PRIORITY (configMAX_PRIORITIES - 1) /*******************************************************************************  * Prototypes  ******************************************************************************/ static void my_task(void *pvParameters);     /*!  * @brief Task responsible for printing of "Hello world." message.  */ static void my_task(void *pvParameters) {     for (;;)     {         PRINTF("Hello World!\r\n");         vTaskSuspend(NULL);     } }       /*  * @brief   Application entry point.  */ int main(void) {          /* Init board hardware. */     BOARD_InitBootPins();     BOARD_InitBootClocks();     BOARD_InitBootPeripherals();        /* Init FSL debug console. */     BOARD_InitDebugConsole();       if (xTaskCreate(my_task, "my_task", configMINIMAL_STACK_SIZE + 10, NULL, my_task_PRIORITY, NULL) != pdPASS)     {         PRINTF("Task creation failed!.\r\n");         while (1)             ;     }     vTaskStartScheduler();       /* Enter an infinite loop, just incrementing a counter. */     while(1) {       }     return 0 ; } Run the application Build your application, go to menu Project > Build Project. Alternatively go to the quick start panel and click the hammer button. Go to menu Run> Debug configurations… Select the ‘Debug configuration’ that matches your connection type, in this example Segger Jlink is used. Then click ‘Apply’ and ‘Debug’ Open a terminal, select the appropriate port and set baudrate to 115200 Run the application, you will see “Hello world” in terminal   For information about configuring with MCUXpresso pins tool in an FreeRTOS project, please see the following document https://community.nxp.com/docs/DOC-341987   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 KSDK community:   The Kinetis Software Development Kit is intended to ease evaluation, prototyping and development with Kinetis MCUs. Apart from the Peripheral Drivers, HAL layer, System Services, RTOS abstraction and software stacks, KSDK implements a robust hardware interrupt mechanism.   The attached document is intended to explain the interrupt handling mechanism of KSDK platform and how to use it for baremetal KSDK or "MQX for KSDK" projects. Some of the topics covered are:   >> Interrupt manager >> Installing vector table in Flash or RAM >> Interrupt priorities >> Peripheral IRQ files (fsl_<peripheral>_irq.c) >> Installing, defining or registering ISRs >> Callbacks >> MQX hardware interrupts system >> Interrupts and callbacks with Processor Expert   The last chapter explains the considerations of interrupt handling when using Kinetis Design Studio in 4 different cases:   1) KSDK baremetal project 2) KSDK baremetal + Processor Expert project 3) MQX for KSDK project 4) MQX for KSDK + Processor Expert project   I hope this document is useful for all of you who have already adopted KSDK as development solution.     /*** UPDATE July 1, 2015 ***/   Document updated for KSDK v1.2 and KDS v3.0.0     Regards! Jorge Gonzalez

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

Sharing notes taken during creation a USB stack composite demo: CDC + Generic HID, this demo is based on FrdmK22f bare mental and MCUXpresso SDK2.2. Creating the CDC + Generic HID composite demo requires combining the CDC example code and HID Generic example code into a single example. 1   Find an existing example as a template A new composite device application should use the existing examples as a template. MCUXpresso SDK2.2 USB stack provides three composite device demos, HID+AUDO, MSC+CDC, and mouse+keyboard, so I select usb_device_composite_cdc_msc as a starting point. 2   Prepare the descriptor-related data structure to ensure that the correct information about the customized composite device is relayed to the USB device stack 2.1 usb_device_class_config_list_struct_t This structure is required for the composite device and relays device callback, class callback, interface numbers, and endpoint numbers of each interface to the class driver. The structure should be placed in the “composite.c” file /* USB device class information */ usb_device_class_config_struct_t g_compositeDevice[2] = {     {         USB_DeviceCdcVcomCallback, (class_handle_t)NULL, &g_UsbDeviceCdcVcomConfig,     },     {                 USB_DeviceHidGenericCallback, (class_handle_t)NULL, &g_UsbDeviceHidGenericConfig,     }};   /* USB device class configuration information */ usb_device_class_config_list_struct_t g_compositeDeviceConfigList = { g_compositeDevice, USB_DeviceCallback, 2, }; 2.2  usb_device_class_config_struct_t This structure is required for the composite device and provides information about each class. The structure should be placed in the “composite.c” file /* USB device class information */ usb_device_class_config_struct_t g_compositeDevice[2] = {     {         USB_DeviceCdcVcomCallback, (class_handle_t)NULL, &g_UsbDeviceCdcVcomConfig,     },     {                 USB_DeviceHidGenericCallback, (class_handle_t)NULL, &g_UsbDeviceHidGenericConfig, } }; 2.3  usb_device_class_struct_t This structure is required for each class including the class type, supported configuration count and interface list for each configuration. /* Define class information for virtual com */ usb_device_class_struct_t g_UsbDeviceCdcVcomConfig = { g_UsbDeviceCdcVcomInterfaceList, kUSB_DeviceClassTypeCdc,  USB_DEVICE_CONFIGURATION_COUNT, };   usb_device_class_struct_t g_UsbDeviceHidGenericConfig = {     g_UsbDeviceHidGenericInterfaceList, /* The interface list of the HID generic */     kUSB_DeviceClassTypeHid,            /* The HID class type */     USB_DEVICE_CONFIGURATION_COUNT,     /* The configuration count */ };   2.4   usb_device_interface_list_t This structure is required for the composite device and provides information about each class. usb_device_interface_list_t g_UsbDeviceHidGenericInterfaceList[USB_DEVICE_CONFIGURATION_COUNT] = {     {         USB_HID_GENERIC_INTERFACE_COUNT, /* The interface count of the HID generic */         g_UsbDeviceHidGenericInterfaces, /* The interfaces handle */     }, };   /* Define configurations for virtual com */ usb_device_interface_list_t g_UsbDeviceCdcVcomInterfaceList[USB_DEVICE_CONFIGURATION_COUNT] = {     {         USB_CDC_VCOM_INTERFACE_COUNT, g_cdcVcomInterfaces,     }, };   2.5  usb_device_interfaces_struct_t This structure provides alternate setting interface information about each interface. usb_device_interfaces_struct_t g_UsbDeviceHidGenericInterfaces[USB_HID_GENERIC_INTERFACE_COUNT] = {     USB_HID_GENERIC_CLASS,           /* HID generic class code */     USB_HID_GENERIC_SUBCLASS,        /* HID generic subclass code */     USB_HID_GENERIC_PROTOCOL,        /* HID generic protocol code */     USB_HID_GENERIC_INTERFACE_INDEX, /* The interface number of the HID generic */     g_UsbDeviceHidGenericInterface,  /* Interfaces handle */     sizeof(g_UsbDeviceHidGenericInterface) / sizeof(usb_device_interfaces_struct_t), }; /* Define interfaces for virtual com */ usb_device_interfaces_struct_t g_cdcVcomInterfaces[USB_CDC_VCOM_INTERFACE_COUNT] = {     {USB_CDC_VCOM_CIC_CLASS, USB_CDC_VCOM_CIC_SUBCLASS, USB_CDC_VCOM_CIC_PROTOCOL, USB_CDC_VCOM_CIC_INTERFACE_INDEX,      g_cdcVcomCicInterface, sizeof(g_cdcVcomCicInterface) / sizeof(usb_device_interfaces_struct_t)},     {USB_CDC_VCOM_DIC_CLASS, USB_CDC_VCOM_DIC_SUBCLASS, USB_CDC_VCOM_DIC_PROTOCOL, USB_CDC_VCOM_DIC_INTERFACE_INDEX,      g_cdcVcomDicInterface, sizeof(g_cdcVcomDicInterface) / sizeof(usb_device_interfaces_struct_t)}, };   2.6 usb_device_interface_struct_t This structure provides information about each alternate setting interface for the current interface. /* Define interface for communication class */ usb_device_interface_struct_t g_cdcVcomCicInterface[] = {{0,                                                           {                                                               USB_CDC_VCOM_CIC_ENDPOINT_COUNT, g_cdcVcomCicEndpoints,                                                           },                                                           NULL}};   /* Define interface for data class */ usb_device_interface_struct_t g_cdcVcomDicInterface[] = {{0,                                                           {                                                               USB_CDC_VCOM_DIC_ENDPOINT_COUNT, g_cdcVcomDicEndpoints,                                                           },                                                           NULL}};   /* HID generic interface information */ usb_device_interface_struct_t g_UsbDeviceHidGenericInterface[] = {{     0U, /* The alternate setting of the interface */     {         USB_HID_GENERIC_ENDPOINT_COUNT, /* Endpoint count */         g_UsbDeviceHidGenericEndpoints, /* Endpoints handle */     }, }};     2.7 usb_device_endpoint_struct_t This structure is required for the composite device and provides ep information /* hid generic endpoint information */ usb_device_endpoint_struct_t g_UsbDeviceHidGenericEndpoints[USB_HID_GENERIC_ENDPOINT_COUNT] = {     /* HID generic interrupt IN pipe */     {         USB_HID_GENERIC_ENDPOINT_IN | (USB_IN << USB_DESCRIPTOR_ENDPOINT_ADDRESS_DIRECTION_SHIFT),         USB_ENDPOINT_INTERRUPT, FS_HID_GENERIC_INTERRUPT_IN_PACKET_SIZE,     },     /* HID generic interrupt OUT pipe */     {         USB_HID_GENERIC_ENDPOINT_OUT | (USB_OUT << USB_DESCRIPTOR_ENDPOINT_ADDRESS_DIRECTION_SHIFT),         USB_ENDPOINT_INTERRUPT, FS_HID_GENERIC_INTERRUPT_OUT_PACKET_SIZE,     }, };   /* cdc virtual com information */ /* Define endpoint for communication class */ usb_device_endpoint_struct_t g_cdcVcomCicEndpoints[USB_CDC_VCOM_CIC_ENDPOINT_COUNT] = {     {         USB_CDC_VCOM_CIC_INTERRUPT_IN_ENDPOINT | (USB_IN << 7U), USB_ENDPOINT_INTERRUPT,         HS_CDC_VCOM_BULK_IN_PACKET_SIZE,     }, };   /* Define endpoint for data class */ usb_device_endpoint_struct_t g_cdcVcomDicEndpoints[USB_CDC_VCOM_DIC_ENDPOINT_COUNT] = {     {         USB_CDC_VCOM_DIC_BULK_IN_ENDPOINT | (USB_IN << 7U), USB_ENDPOINT_BULK, FS_CDC_VCOM_BULK_IN_PACKET_SIZE,     },     {         USB_CDC_VCOM_DIC_BULK_OUT_ENDPOINT | (USB_OUT << 7U), USB_ENDPOINT_BULK, FS_CDC_VCOM_BULK_OUT_PACKET_SIZE,     }, };   3   Prepare the descriptors array and ensure that the descriptors are consistent with the descriptor-related data structure.  The descriptors for each class can be obtained from the class-related examples and class specification. For the composite device, combine multiple class descriptors.   /* Define configuration descriptor */ uint8_t g_UsbDeviceConfigurationDescriptor[USB_DESCRIPTOR_LENGTH_CONFIGURATION_ALL] = {     /* Configuration Descriptor Size*/     USB_DESCRIPTOR_LENGTH_CONFIGURE,     /* CONFIGURATION Descriptor Type */     USB_DESCRIPTOR_TYPE_CONFIGURE,     /* Total length of data returned for this configuration. */     USB_SHORT_GET_LOW(USB_DESCRIPTOR_LENGTH_CONFIGURATION_ALL),     USB_SHORT_GET_HIGH(USB_DESCRIPTOR_LENGTH_CONFIGURATION_ALL),     /* Number of interfaces supported by this configuration */     USB_INTERFACE_COUNT,     /* Value to use as an argument to the SetConfiguration() request to select this configuration */     USB_COMPOSITE_CONFIGURE_INDEX,     /* Index of string descriptor describing this configuration */     0,     /* Configuration characteristics D7: Reserved (set to one) D6: Self-powered D5: Remote Wakeup D4...0: Reserved        (reset to zero) */     (USB_DESCRIPTOR_CONFIGURE_ATTRIBUTE_D7_MASK) |         (USB_DEVICE_CONFIG_SELF_POWER << USB_DESCRIPTOR_CONFIGURE_ATTRIBUTE_SELF_POWERED_SHIFT) |         (USB_DEVICE_CONFIG_REMOTE_WAKEUP << USB_DESCRIPTOR_CONFIGURE_ATTRIBUTE_REMOTE_WAKEUP_SHIFT),     /* Maximum power consumption of the USB * device from the bus in this specific * configuration when the device is        fully * operational. Expressed in 2 mA units *  (i.e., 50 = 100 mA).  */     USB_DEVICE_MAX_POWER,       /* Interface Association Descriptor */     /* Size of this descriptor in bytes */     USB_IAD_DESC_SIZE,     /* INTERFACE_ASSOCIATION Descriptor Type  */     USB_DESCRIPTOR_TYPE_INTERFACE_ASSOCIATION,     /* The first interface number associated with this function */     0x00,     /* The number of contiguous interfaces associated with this function */     0x02,     /* The function belongs to the Communication Device/Interface Class  */     USB_CDC_VCOM_CIC_CLASS, 0x03,     /* The function uses the No class specific protocol required Protocol  */     0x00,     /* The Function string descriptor index */     0x02,       /* Interface Descriptor */     USB_DESCRIPTOR_LENGTH_INTERFACE, USB_DESCRIPTOR_TYPE_INTERFACE, USB_CDC_VCOM_CIC_INTERFACE_INDEX, 0x00,     USB_CDC_VCOM_CIC_ENDPOINT_COUNT, USB_CDC_VCOM_CIC_CLASS, USB_CDC_VCOM_CIC_SUBCLASS, USB_CDC_VCOM_CIC_PROTOCOL, 0x00,       /* CDC Class-Specific descriptor */     USB_DESCRIPTOR_LENGTH_CDC_HEADER_FUNC, /* Size of this descriptor in bytes */     USB_DESCRIPTOR_TYPE_CDC_CS_INTERFACE,  /* CS_INTERFACE Descriptor Type */     USB_CDC_HEADER_FUNC_DESC, 0x10,     0x01, /* USB Class Definitions for Communications the Communication specification version 1.10 */       USB_DESCRIPTOR_LENGTH_CDC_CALL_MANAG, /* Size of this descriptor in bytes */     USB_DESCRIPTOR_TYPE_CDC_CS_INTERFACE, /* CS_INTERFACE Descriptor Type */     USB_CDC_CALL_MANAGEMENT_FUNC_DESC,     0x01, /*Bit 0: Whether device handle call management itself 1, Bit 1: Whether device can send/receive call              management information over a Data Class Interface 0 */     0x01, /* Indicates multiplexed commands are handled via data interface */       USB_DESCRIPTOR_LENGTH_CDC_ABSTRACT,   /* Size of this descriptor in bytes */     USB_DESCRIPTOR_TYPE_CDC_CS_INTERFACE, /* CS_INTERFACE Descriptor Type */     USB_CDC_ABSTRACT_CONTROL_FUNC_DESC,     0x06, /* Bit 0: Whether device supports the request combination of Set_Comm_Feature, Clear_Comm_Feature, and              Get_Comm_Feature 0, Bit 1: Whether device supports the request combination of Set_Line_Coding,              Set_Control_Line_State, Get_Line_Coding, and the notification Serial_State 1, Bit ...  */       USB_DESCRIPTOR_LENGTH_CDC_UNION_FUNC, /* Size of this descriptor in bytes */     USB_DESCRIPTOR_TYPE_CDC_CS_INTERFACE, /* CS_INTERFACE Descriptor Type */     USB_CDC_UNION_FUNC_DESC, 0x00,        /* The interface number of the Communications or Data Class interface  */     0x01,                                 /* Interface number of subordinate interface in the Union  */       /*Notification Endpoint descriptor */     USB_DESCRIPTOR_LENGTH_ENDPOINT, USB_DESCRIPTOR_TYPE_ENDPOINT,     USB_CDC_VCOM_CIC_INTERRUPT_IN_ENDPOINT | (USB_IN << 7U), USB_ENDPOINT_INTERRUPT,     USB_SHORT_GET_LOW(FS_CDC_VCOM_INTERRUPT_IN_PACKET_SIZE), USB_SHORT_GET_HIGH(FS_CDC_VCOM_INTERRUPT_IN_PACKET_SIZE),     FS_CDC_VCOM_INTERRUPT_IN_INTERVAL,       /* Data Interface Descriptor */     USB_DESCRIPTOR_LENGTH_INTERFACE, USB_DESCRIPTOR_TYPE_INTERFACE, USB_CDC_VCOM_DIC_INTERFACE_INDEX, 0x00,     USB_CDC_VCOM_DIC_ENDPOINT_COUNT, USB_CDC_VCOM_DIC_CLASS, USB_CDC_VCOM_DIC_SUBCLASS, USB_CDC_VCOM_DIC_PROTOCOL,     0x00, /* Interface Description String Index*/       /*Bulk IN Endpoint descriptor */     USB_DESCRIPTOR_LENGTH_ENDPOINT, USB_DESCRIPTOR_TYPE_ENDPOINT, USB_CDC_VCOM_DIC_BULK_IN_ENDPOINT | (USB_IN << 7U),     USB_ENDPOINT_BULK, USB_SHORT_GET_LOW(FS_CDC_VCOM_BULK_IN_PACKET_SIZE),     USB_SHORT_GET_HIGH(FS_CDC_VCOM_BULK_IN_PACKET_SIZE), 0x00, /* The polling interval value is every 0 Frames */       /*Bulk OUT Endpoint descriptor */     USB_DESCRIPTOR_LENGTH_ENDPOINT, USB_DESCRIPTOR_TYPE_ENDPOINT, USB_CDC_VCOM_DIC_BULK_OUT_ENDPOINT | (USB_OUT << 7U),     USB_ENDPOINT_BULK, USB_SHORT_GET_LOW(FS_CDC_VCOM_BULK_OUT_PACKET_SIZE),     USB_SHORT_GET_HIGH(FS_CDC_VCOM_BULK_OUT_PACKET_SIZE), 0x00, /* The polling interval value is every 0 Frames */       USB_DESCRIPTOR_LENGTH_INTERFACE, /* Size of this descriptor in bytes */     USB_DESCRIPTOR_TYPE_INTERFACE,   /* INTERFACE Descriptor Type */     USB_HID_GENERIC_INTERFACE_INDEX, /* Number of this interface. */     0x00U,                           /* Value used to select this alternate setting                                        for the interface identified in the prior field */     USB_HID_GENERIC_ENDPOINT_COUNT,  /* Number of endpoints used by this                                        interface (excluding endpoint zero). */     USB_HID_GENERIC_CLASS,           /* Class code (assigned by the USB-IF). */     USB_HID_GENERIC_SUBCLASS,        /* Subclass code (assigned by the USB-IF). */     USB_HID_GENERIC_PROTOCOL,        /* Protocol code (assigned by the USB). */     0x02U,                           /* Index of string descriptor describing this interface */       USB_DESCRIPTOR_LENGTH_HID,      /* Numeric expression that is the total size of the                                       HID descriptor. */     USB_DESCRIPTOR_TYPE_HID,        /* Constant name specifying type of HID                                       descriptor. */     0x00U, 0x01U,                   /* Numeric expression identifying the HID Class                                        Specification release. */     0x00U,                          /* Numeric expression identifying country code of                                        the localized hardware */     0x01U,                          /* Numeric expression specifying the number of                                       class descriptors(at least one report descriptor) */     USB_DESCRIPTOR_TYPE_HID_REPORT, /* Constant name identifying type of class descriptor. */     USB_SHORT_GET_LOW(USB_DESCRIPTOR_LENGTH_HID_GENERIC_REPORT),     USB_SHORT_GET_HIGH(USB_DESCRIPTOR_LENGTH_HID_GENERIC_REPORT),       /* Numeric expression that is the total size of the        Report descriptor. */     USB_DESCRIPTOR_LENGTH_ENDPOINT, /* Size of this descriptor in bytes */     USB_DESCRIPTOR_TYPE_ENDPOINT,   /* ENDPOINT Descriptor Type */     USB_HID_GENERIC_ENDPOINT_IN | (USB_IN << USB_DESCRIPTOR_ENDPOINT_ADDRESS_DIRECTION_SHIFT),     /* The address of the endpoint on the USB device        described by this descriptor. */     USB_ENDPOINT_INTERRUPT, /* This field describes the endpoint's attributes */     USB_SHORT_GET_LOW(FS_HID_GENERIC_INTERRUPT_IN_PACKET_SIZE),     USB_SHORT_GET_HIGH(FS_HID_GENERIC_INTERRUPT_IN_PACKET_SIZE),     /* Maximum packet size this endpoint is capable of        sending or receiving when this configuration is        selected. */     FS_HID_GENERIC_INTERRUPT_IN_INTERVAL, /* Interval for polling endpoint for data transfers. */       USB_DESCRIPTOR_LENGTH_ENDPOINT,       /* Size of this descriptor in bytes */     USB_DESCRIPTOR_TYPE_ENDPOINT,         /* ENDPOINT Descriptor Type */     USB_HID_GENERIC_ENDPOINT_OUT | (USB_OUT << USB_DESCRIPTOR_ENDPOINT_ADDRESS_DIRECTION_SHIFT),     /* The address of the endpoint on the USB device        described by this descriptor. */     USB_ENDPOINT_INTERRUPT, /* This field describes the endpoint's attributes */     USB_SHORT_GET_LOW(FS_HID_GENERIC_INTERRUPT_OUT_PACKET_SIZE),     USB_SHORT_GET_HIGH(FS_HID_GENERIC_INTERRUPT_OUT_PACKET_SIZE),     /* Maximum packet size this endpoint is capable of        sending or receiving when this configuration is        selected. */     FS_HID_GENERIC_INTERRUPT_OUT_INTERVAL, /* Interval for polling endpoint for data transfers. */ };   4 Implement the specific descriptor-related callback function, which the USB Device stack calls to get the descriptor.    Please refer to the attached source code for more details

This document includes two chapters , chapter 1 is about how to use printf() to print string in KSDK1.3 project , the usage in project without MQX has been introduced on another document, you can find it here : https://community.freescale.com/docs/DOC-104349 , so in this DOC I only introduce how to use the printf() in KSDK MQX- Lite and KSDK MQX-Standard project .   Chapter 2 introduces how to check which UART port is used when use printf() to print string on the FRDM board and TOWER board .   In sum, only the project of “MQX standard” use it own driver for printf(), so we need delete the driver “fsl_debug_console”. In other SDK+PE projects , they all use the driver of “fsl_debug_console” for printf().

Problem: Unknown error in Task error code column (in Task List view from MQX TAD) is displayed when debugging MQX project in IAR with KSDK.   Cause: This error means that TAD cannot find mqx.tad file with messages for error codes. In this case code 0x0 means MQX_OK, so it might lead user to believe there is some error with task but it is not. IAR TAD was made before first KSDK release, so there is no way for IAR TAD to find mqx.tad file because it isn’t part of KSDK. It works only when classic MQX is also installed on computer.   IAR TAD finds mqx.tad file this way (written as example for MQX 4.2): It takes _mqx_version_number defined as hex number 0x04020000 in “mqx\source\kernel\mqx.c” Looks into windows registry key of specified MQX version “HKEY_LOCAL_MACHINE\SOFTWARE\Freescale\FreeScale MQX\4.2” Takes its path variable "PATH"="C:\\Freescale\\Freescale_MQX_4_2" Tries to find mqx.tad file in directory specified in PATH or in its child folder "\tools\tad\" (e.g. C:\Freescale\Freescale_MQX_4_2\tools\tad\mqx.tad)   Solution: Use of fake registry key, which will point to classic MQX installation or some blank directory with only mqx.tad file (e.g. C:\fake_mqx\mqx.tad or better C:\Freescale\KSDK_1.2.0\tools\tad\mqx.tad). This registry key must use MQX version specified in used KSDK (for KSDK 1.2 and 1.3 it is 0x05000200, for 1.1 0x05000001 and for 1.0 0x04010000). Registry key might look like this: Then TAD translates error codes to messages successfully and path to mqx.tad file can be checked in Check for errors view under Show MQX TAD Diagnostics. Attached is example registry key with \tad\mqx.tad structure for placing into KSDK\tools directory.

Hello community,   This document is the continuation of the document Line scan camera with KSDK [ADC + PIT + GPIO] which 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 control the speed in DC motors and the position in servomotors with KSDK step-by-step. This document is intended to be an example for the TPM and the GPIO peripheral drivers usage.   The required material to run this project is: A Servomotor (the project supports up to two servomotors, one servomotor is included in the smart car kit). Two DC motors (included in the smart car kit). FRDM-KL25Z based on the Kinetis Microcontroller KL25Z. FRDM-TFC shield. Mini-USB cable.   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 Controlling speed in DC motors and position in servomotors with the FRDM-KL25Z and the Kinetis SDK [FTM + GPIO] explains how to implement an application to control the motors. The result of this document is the project BM-KSDK-FRDM_KL25Z_LINE_SCAN_CAMERA-SERVO-DC_MOTORS.   If you are interested in participate in the Freescale Cup you could take a look into the groups University Programs, The Freescale Cup Technical Reports TFC - Mexico, TFC - Brazil, TFC - China, TFC - Malaysia, TFC - Japan, TFC - North America, TFC - India, TFC - Taiwan, The Freescale Cup EMEA.   Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer Freescale Semiconductor

There was a macro definition issue in the flexcan driver of ksdk 2.0, the macros of RX_FIFO_STD_MASK_TYPE_B/C were defined based on maco FLEXCAN_ID_STD(id), for example: #define FLEXCAN_RX_FIFO_STD_MASK_TYPE_B_HIGH(id, rtr, ide) \ (((uint32_t)((uint32_t)(rtr) << 31) | (uint32_t)((uint32_t)(ide) << 30)) | \ (FLEXCAN_ID_STD(id) << 16)) /**< Standard Rx FIFO Mask helper macro Type B upper part helper macro. */ but FLEXCAN_ID_STD(id) is defined for flexCAN Message Buffer structure, so FLEXCAN_ID_STD(id)  is a value of "id" left-shifted by 18,  according to the spec. while for RX FIFO ID table structure, the spec of Type B/C is different. so we should use the value of id directly to define the type B and type C Rx Frame Identifier. For example, #define FLEXCAN_RX_FIFO_STD_MASK_TYPE_B_HIGH(id, rtr, ide) \ (((uint32_t)((uint32_t)(rtr) << 31) | (uint32_t)((uint32_t)(ide) << 30)) | \ ((id & 0x7FF) << 19)) /**< Standard Rx FIFO Mask helper macro Type B upper part helper macro. */   This patch doesn't affect FlexCAN operation related with message buffers , neither with RX FIFO A type ID table.   Please kindly refer to the attachment for details.   Sorry for the inconvenience that has caused.   -Kan

Hello community,   This document is the continuation of the documents Line scan camera with KSDK [ADC + PIT + GPIO] and Controlling speed in DC motors and position in servomotors with KSDK [FTM + GPIO] which show 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 an easy way to detect the track's line from the data acquired with the linear camera.   The required material to run this project is: A Servomotor (the project supports up to two servomotors, one servomotor is included in the smart car kit). Two DC motors (included in the smart car kit). Line scan camera (the project supports up to two cameras). FRDM-KL25Z based on the Kinetis Microcontroller KL25Z. FRDM-TFC shield. Mini-USB cable.   This material can be bought in The Freescale Cup Intelligent Car Development.         If you are interested in participate in the Freescale Cup you could take a look into the groups University Programs, The Freescale Cup Technical Reports TFC - Mexico, TFC - Brazil, TFC - China, TFC - Malaysia, TFC - Japan, TFC - North America, TFC - India, TFC - Taiwan, The Freescale Cup EMEA.   Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer Freescale Semiconductor

Hi all,   there is a simple modification of ftm driver example based on KSDK 1.3, KDS 3.0 on FRDM-K22F.   enabling clocks for PORTs in hardware_init.c   void hardware_init(void) {    /* enable clock for PORTs */   CLOCK_SYS_EnablePortClock(PORTA_IDX);   CLOCK_SYS_EnablePortClock(PORTD_IDX);   CLOCK_SYS_EnablePortClock(PORTE_IDX);    PORT_HAL_SetMuxMode(PORTA,1u,kPortMuxAlt3);//red   PORT_HAL_SetMuxMode(PORTA,2u,kPortMuxAlt3);//green   PORT_HAL_SetMuxMode(PORTD,5u,kPortMuxAlt4);//blue    /* Init board clock */   BOARD_ClockInit();   dbg_uart_init(); } function for converting HSV to RGB color palette downloaded from hsv2rgb.cpp - shiftpwm - Arduino library to PWM many outputs with chained shift registers. - Google Project Hosting   setting ftm parameters for red, green and blue color, for red color: ftm_pwm_param_t ftmParamR = {         .mode                   = kFtmEdgeAlignedPWM,         .edgeMode               = kFtmLowTrue,         .uFrequencyHZ           = 24000u,         .uDutyCyclePercent      = 0,         .uFirstEdgeDelayPercent = 0,     };   setting PWM output for each color in infinite loop         FTM_DRV_PwmStart(BOARD_FTM_INSTANCE, &ftmParamR, 6);         FTM_DRV_PwmStart(BOARD_FTM_INSTANCE, &ftmParamG, 7);         FTM_DRV_PwmStart(BOARD_FTM_INSTANCE, &ftmParamB, 5);   forwarding parameters to hsv2rgb() hsv2rgb(hue,255,255,&red,&green,&blue,255);   changing hue and checking overflow of hue         hue++;         if(hue>=360)hue=0;   normalizing from 0-255 to 0-100 percent of PWM pulse width for each color         ftmParamR.uDutyCyclePercent = (uint8_t)(((float)red/255.0)*100.0);         ftmParamG.uDutyCyclePercent = (uint8_t)(((float)green/255.0)*100.0);         ftmParamB.uDutyCyclePercent = (uint8_t)(((float)blue/255.0)*100.0);   That´s all!   Importing example extract ftm_rainbow.zip to C:\Freescale\KSDK_1.3.0\examples\frdmk22f\driver_examples Go to KDS, import file and choose .wsd file After then don´t forget compile library first and then project.     I hope you will enjoy the demo 🙂   Iva

Hello KSDK fans:   As you may know, KSDK provides comprehensive software support for Kinetis MCUs to accelerate application development. Besides providing Hardware abstraccion layer and peripherals drivers it can be Processor Expert capable.   Here is an example on how to create a new project with KSDK and Processor Expert support.   It shows a simple USB HID example that is ready to add your application code by using either KSDK drivers or Processor Expert support.   I hope this can help you.   Regards,   Isaac Avila

Hello Kinetis world! Kinetis SDK is here to stay and with it there are good opportunities ahead, such as coding flexibility, portability, RTOS enablement, projects scalability and more. Right now this is a brand new solution introduced by Freescale, so a lot of tutorials, How-To's and demo codes are coming, in addition to those already in the KSDK installation. I wanted to share an example project developed with KSDK v1.0.0 and KDS v1.1.1, which uses a simple driver to communicate to an I2C EEPROM memory using a FRDM-K64F board. The driver is focused and was tested with a 256 Kbit memory (24xx256), but it should be compatible with the 64Kbit, 128 Kbit, 256 Kbit and 512 Kbit versions. This demo project demonstrates how to use the APIs of the KSDK I2C Master Driver. The connections are as next: Please notice this is not intended to be a robust driver for I2C EEPROMs. Instead consider it a basic demo code, but with time we could improve it. The attached pdf is an overview/explanation of the example, while the zip folder contains the project for Kinetis Design Studio v1.1.1. :smileyalert: Before the project can be successfully compiled, you need to have installed KSDK v1.0.0 (www.freescale.com/ksdk) and have the FRDM-K64F platform library already built. For instructions on how to build the platform library you can refer to Appendix A of the next document in KSDK installation folder: C:\Freescale\KSDK_1.0.0\doc\Kinetis SDK K64 User's Guide.pdf :smileyinfo: NOTE: Disregard IAR and Keil instructions and refer to KDS part. Importing and compiling the example project with KDS      1) Unzip the package. It is recommended to place it into your KDS workspace, but it can be located at any place.      2) From KDS go to File -> Import -> General -> Existing Projects into Workspace.      3) Check "Select root directory" and click on "Browse" to search for the location of the unzipped folder. Then click OK.      4) Mark the check box for "I2C_EEPROM_K64" and click on "Finish".      5) Go to Project -> Build Project or simply click on the hammer icon. Build process should finish with no errors. The project provides a default Debug Configuration to use with the Segger J-Link emulator firmware v2.0 installed in the FRDM-K64F. If you wish to use a different connection please refer to the next link: https://community.freescale.com/docs/DOC-101845 I hope you like this demo. Many thanks and credits to abigailinzunza, for her valuable help developing this project. Regards! Jorge Gonzalez

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.

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