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!

What is needed: SW: KDS 3.2 KSDK 2.0 Hercules (Visual Studio 2015)   HW: FRDM-K64F Ethernet Cable   Install KSDK 2.0 Be sure, that you have downloaded correct package KSDK 2.0 for FRDM-K64F, for all procedure please follow instructions mentioned at How to: install KSDK 2.0   Install KDS 3.2 Be sure, that you will work with the newest Kinetis Design Studio v.3.2, please see New Kinetis Design Studio v3.2.0 available for more details.   Import demo example For start with this example we will build on existing demo project, located under C:\Freescale\<ksdk2.0_package>\boards\frdmk64f\demo_apps\lwip\lwip_tcpecho\freertos\kds Please, import this example according to the procedure described at How to: import example in KSDK   Start with programming Let´s start with programming example for LED RGB controlling via ethernet   Checking and parsing incoming packets This packet is divided into header and data. The header represents first two bytes and the remaining three bytes are occupied by data. The zero byte is 0xFF and the first byte must be 0x00. The second byte represents red color, the third byte green color and the last fourth byte presents blue color. lwip_tcpecho_freertos.c Server is listening on port 7 and waiting for a connection from the client. If the client sends 5B, it find out according to header whether it is correct 5B. If so, each RGB parts will be parsed individually and set the LED accordingly.       while (1)     {         /* Grab new connection. */         err = netconn_accept(conn, &newconn);         /* Process the new connection. */         if (err == ERR_OK)         {             struct netbuf *buf;             u8_t *data;             u16_t len;               while ((err = netconn_recv(newconn, &buf)) == ERR_OK)             {                 do                 {                     netbuf_data(buf, &data, &len);                     if(len==5){                         if(data[0]==0xFF && data[1]==0x00){                             if(data[2]>0){                                 LED_RED_ON();                             }else {                                 LED_RED_OFF();                             }                             if(data[3]>0){                                 LED_GREEN_ON();                             }else {                                 LED_GREEN_OFF();                             }                             if(data[4]>0){                                 LED_BLUE_ON();                             }else {                                 LED_BLUE_OFF();                             }                             //err = netconn_write(newconn, "ok", 2, NETCONN_COPY);                         }                     }                 } while (netbuf_next(buf) >= 0);                 netbuf_delete(buf);             }             /* Close connection and discard connection identifier. */             netconn_close(newconn);             netconn_delete(newconn);         }     }   Initializing LEDs   It is needed to set all LEDs in pin_mux.c in BOARD_InitPins() function and initialize in lwip_tcpecho_freertos.c in main() function.   pin_mux.c Go to BOARD_InitPins() and at the end of the function add these lines: Copy and paste to your project     CLOCK_EnableClock(kCLOCK_PortB);     CLOCK_EnableClock(kCLOCK_PortE);     PORT_SetPinMux(PORTB, 21U, kPORT_MuxAsGpio);     PORT_SetPinMux(PORTB, 22U, kPORT_MuxAsGpio);     PORT_SetPinMux(PORTE, 26U, kPORT_MuxAsGpio);   lwip_tcpecho_freertos.c Go to main() and initialize LEDs Copy and paste to your project LED_RED_INIT(LOGIC_LED_OFF); LED_GREEN_INIT(LOGIC_LED_OFF); LED_BLUE_INIT(LOGIC_LED_OFF); Set up connection on PC site Set PC on 192.168.1.100   Controlling the application Hercules For test connection you can use Hercules. After testing don´t forget disconnect Hercules, server can handle only one TCP connection. IP Address of the board is set on 192.168.1.102 It works - the board is green lighting:   Visualization in Visual Studio 2015 For better controlling we will create application in Visual Studio 2015. Start with new project and create new form according this:   And set functionality for all items. Client connects to the IP Address on port 7 and sends our packet according selected colour. For red color are data set on { 0xFF, 0x00, 1, 0, 0 };, for yellow { 0xFF, 0x00, 1, 1, 0 }; etc.   Form1.cs public partial class Form1 : Form     {         Socket s = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);          public Form1()         {             InitializeComponent();                      }          private void button1_Click(object sender, EventArgs e)         {             try              {                 s.Connect(IPAddress.Parse(textBox1.Text), 7);                 byte[] data = { 0xFF, 0x00, 0, 0, 0 };                 groupBox1.Enabled = true;                 button1.Enabled = false;                 s.Send(data);                  textBox1.Enabled = false;             }             catch              {                 MessageBox.Show("Connection failed");             }         }          private void button_red_Click(object sender, EventArgs e)         {             if (s.Connected) {                 byte[] data = { 0xFF, 0x00, 1, 0, 0 };                 s.Send(data);             }         }          private void button_green_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 0, 1, 0 };                 s.Send(data);             }         }          private void button_blue_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 0, 0, 1 };                 s.Send(data);             }         }          private void button_black_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 0, 0, 0 };                 s.Send(data);             }         }          private void button_white_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 1, 1, 1 };                 s.Send(data);             }         }          private void button_cyan_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 0, 1, 1 };                 s.Send(data);             }         }          private void button_magenta_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 1, 0, 1 };                 s.Send(data);             }         }          private void button_yellow_Click(object sender, EventArgs e)         {             if (s.Connected)             {                 byte[] data = { 0xFF, 0x00, 1, 1, 0 };                 s.Send(data);             }         }     }     Enjoy! 🙂   Iva

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!

This community post describes how to combine the ADC and DMA using KSDK to simulate a flexible peripheral storing the ADC results into a buffer stored in memory.   In this configuration the MCU uses less resources, only using one ADC and the hardware (DMA) chainging the ADC channel and filling up the memory buffer with the results of the ADC. This way the MCU does not need to read the ADC result register being everything done automatically.                        KSDK The Kinetis Software Development Kit (SDK) is an extensive suite of robust peripheral drivers, stacks, middleware and example applications designed to simplify and accelerate application development on any Kinetis MCU. The addition of Processor Expert technology for software and board support configuration provides unmatched ease of use and flexibility. The Kinetis SDK is complimentary and includes full source code under a permissive open-source license for all hardware abstraction and peripheral driver software.   KINETIS_SDK   FRDM-K64M The FRDM-K64F is an ultra-low-cost development platform for Kinetis K64, K63, and K24 MCUs. The FRDM-K64F hardware is form-factor compatible with the Arduino™ R3 pin layout, providing a broad range of expansion board options. Features: MK64FN1M0VLL12 MCU (120 MHz, 1 MB flash memory, 256 KB RAM) for more information see FRDM-K64F   DMA to Emulate ADC Flexible Scan To emulate flexible scan it is necessary to configure the DMA to change the input ADC channel. The channel numbers are defined in the ADC_mux array. The conversion results are stored in the ADC0_resultBuffer array with the following order:   ADC0_CH12. ADC0_CH13. ADC0_CH23.   The Kinetis K series of microcontrollers also offers a powerfulDMA peripheral with up to 16 channels that can be combined with the ADC to allow the scanning of more than two channels.   System overview ADC Flexible Scan mode requires two DMA channels for one ADC converter. DMA channel 1 with a higher priority transfers the resultant ADC data from the ADC0_RA register to a memory buffer. DMA channel 0 with a lower priority transfers the next ADC channel setting (input multiplexer channel) from the constant buffer. The following figure depicts the application Figure 1. Depicts the application Flow diagram: The example code that accompanies this application note demonstrates a continuous scan conversion from three ADC channels. Each channel is measured four times, so the result buffer size is 3 × 4 = 12 (the real buffer size is 16, to demonstrate that only 12 data field parts are written). The ADC works in hardware trigger mode, with the LPTMR timer serving as the trigger source. Scanning is executed in continuous mode; thus, after a major loop has finished, the result buffer pointer address_0 is reloaded and the conversion begins again from the start buffer address. To calculate and change the frequency, check the macro INPUT_SIGNAL_FREQ to change the frequency value in Hz. The DMA1 is triggered by the ADC, and the DMA0 is triggered by the eLINK of minor   loop of DMA1. In this example the frequency is set to10 Hz, and is the number of samples is 10.   Figure 2. Flow diagram Configuration with SDK Configure the ADC (functions and structures):   The ADC initialization in the application is shown on the following code snippet.   The ADC is in interruption mode. Trigger by LPTMR (HW trigger)                                     Trigger for eDMA enable                                     Fist channel input is 0x0C.  Channel ADC_SE12                                     Select the channel in chnNum                             /*      * Initialization ADC for      * 12bit resolution, interrrupt mode, hw trigger enabled.      * normal convert speed, VREFH/L as reference,      * disable continuouse convert mode.      */ ADC_DRV_StructInitUserConfigForIntMode(&adcUserConfig);     adcUserConfig.hwTriggerEnable = true;     adcUserConfig.continuousConvEnable = false;     adcUserConfig.dmaEnable = true;      ADC_DRV_Init(instance, &adcUserConfig, &gAdcState);      /* Install Callback function into ISR. */    ADC_DRV_InstallCallback(instance, 0U, adc_chn0_isr_callback);      adcChnConfig.chnNum = ADC_INPUT_CHAN;     adcChnConfig.diffEnable = false;     adcChnConfig.intEnable = true;     adcChnConfig.chnMux = kAdcChnMuxOfA;      /* Configure channel0. */     ADC_DRV_ConfigConvChn(instance, 0U, &adcChnConfig);     /* Configure channel1, which is used in PDB trigger case. */      return 0;           To use the DMA driver, follow these steps:   1.  Initialize the DMA module: EDMA_DRV_Init();   2.  Request a DMA channel: DMA_DRV_RequestChannel(); 3.  Configure the TCD:  EDMA_DRV_PrepareDescriptorTransfer(); and EDMA_DRV_PushDescriptorToReg(); 4.  Register callback function: EDMA_DRV_InstallCallback(); 5.  Start the DMA channel: EDMA_DRV_StartChannel(); NOTE: the next two functions are optional for stop and free DMA channel 6.  Stop the DMA channel: EDMA_DRV_StopChannel(); 7.  Free the DMA channel: dma_free_channel().   Initialize the DMA module: EDMA_DRV_Init();   In this function you can select the eDMA channel to use and this function initializes the run-time state structure to provide the eDMA channel allocation release, protect, and track the state for channels. This function also opens the clock to the eDMA modules, resets the eDMA modules and initializes the module to user-defined settings and default settings.   chnDMA1.channel= kEDMAChannel1; chnDMA0.channel=kEDMAChannel0;   userConfig.chnArbitration = kEDMAChnArbitrationFixedPriority; userConfig2.chnArbitration= kEDMAChnArbitrationRoundrobin; userConfig.notHaltOnError = false; userConfig2.notHaltOnError = false;     EDMA_DRV_Init(&state, &userConfig); EDMA_DRV_Init(&state2, &userConfig2);          Request a DMA channel: DMA_DRV_RequestChannel();   This function allocates eDMA channel according to the required channel allocation andcorresponding to the eDMA hardware request, initializes the channel state memory provided by user and fills out the members.   This function provides two ways to allocate an eDMA channel: statically and dynamically. In a static allocation, the user provides the required channel number and eDMA driver tries to allocate the required channel to the user. If the channel is not occupied, the eDMA driver is successfully assigned to the user. If the channel is already occupied, the user gets the return value kEDMAInvalidChn, this is request a channel in a static way, In a dynamic allocation, any of the free eDMA channels are available for use. eDMA driver assigns the first free channel to the user.   //request ADC1// uint8_t requestDMA1 = EDMA_DRV_RequestChannel(kEDMAChannel1, kDmaRequestMux0ADC0, &chnDMA1); if(kEDMAInvalidChannel==requestDMA1)                      {                      printf("EDMAInvalidChannel 1 .  the request is failed.");                      } //request DMA0// uint8_t requestDMA0 = EDMA_DRV_RequestChannel(kEDMAChannel0, kDmaRequestMux0AlwaysOn63, &chnDMA0); if(kEDMAInvalidChannel==requestDMA0)                      {                      printf("EDMAInvalidChannel 0.  the request is failed.");                      }       DMA configurations: is shown on the following code snippet. (edma_transfer_config_t) TCD is a configuration structure, inside has a parameters to change for different types to transfers data.  srcAddr: memory address  pointing to the source data destAddr: memory address pointing to the destination address srcTransferSize: Source data transfer size. destTransferSize: Destination data transfer size. srcOffset: Sign-extended offset applied to the current source address form the next-state value as each source read/write is completed. destOffset: Sign-extended offset applied to the current destination address form the next-state value as each source read/write is completed. srcLastAddrAdjust: Last source address adjustment. destLastAddrAdjust: Last destination address adjustment. Note here it is only valid when scatter/gather feature is not enabled. srcModulo: Source address modulo. destModulo: Destination address modulo.                             minorLoopCount: Minor bytes transfer count. Number of bytes to be transferred in each service request of the channel. majorLoopCount: Major iteration count.   //////////configuration and ELINK DMA channel 1 //////////////////////////////////////////////////////////////////////////////////////////////////////////////        config[kEDMAChannel1].srcAddr = (uint32_t)(&ADC0_RA);  /*!< Memory address pointing to the source data. */        config[kEDMAChannel1].destAddr = (uint32_t)(&ADC0_resultBuffer[0]);/*!< Memory address pointing to the destination data. */        config[kEDMAChannel1].srcTransferSize = kEDMATransferSize_2Bytes;   /*!< Source data transfer size. */        config[kEDMAChannel1].destTransferSize = kEDMATransferSize_2Bytes;  /*!< Destination data transfer size. */        config[kEDMAChannel1].srcOffset = 0;         /*!< Sign-extended offset applied to the current source address to                                            form the next-state value as each source read/write is completed. */        config[kEDMAChannel1].destOffset = 2;        config[kEDMAChannel1].srcLastAddrAdjust = 0;    /*!< Last source address adjustment. */        config[kEDMAChannel1].destLastAddrAdjust = -24;   /*!< Last destination address adjustment. Note here it is only valid when scatter/gather feature is not enabled. */        config[kEDMAChannel1].srcModulo = kEDMAModuloDisable;       /*!< Source address modulo. */        config[kEDMAChannel1].destModulo = kEDMAModuloDisable;       /*!< Destination address modulo. */        config[kEDMAChannel1].minorLoopCount = 2;    /*!< Minor bytes transfer count. Number of bytes to be transferred                                             in each service request of the channel. */        config[kEDMAChannel1].majorLoopCount = 12;    /*!< Major iteration count. */   stcdDmaChn1.NBYTES.MLNO=0x02; /////////////////////////////Elink on/////////////////LINKCH/////major loop chn1// stcdDmaChn1.BITER.ELINKNO= (DMA_BITER_ELINKNO_ELINK_MASK|0x0000|0x0C); stcdDmaChn1.CITER.ELINKNO= (DMA_CITER_ELINKNO_ELINK_MASK|0x0C); stcdDmaChn1.ATTR= (DMA_ATTR_SSIZE(1)|DMA_ATTR_DSIZE(1)); stcdDmaChn1.CSR=(DMA_CSR_MAJORLINKCH(0)|DMA_CSR_MAJORLINKCH_MASK | DMA_CSR_INTMAJOR_MASK);   uint16_t statusChnn1 = EDMA_DRV_PrepareDescriptorTransfer(&chnDMA1, &stcdDmaChn1, &config[kEDMAChannel1], true, false);   if(kStatus_EDMA_Success == statusChnn1)        {          statusChnn1 = EDMA_DRV_PushDescriptorToReg(&chnDMA1, &stcdDmaChn1);        }         EDMA_DRV_PrepareDescriptorTransfer(); This function sets up the basic transfer for the descriptor.   EDMA_DRV_PushDescriptorToReg(); This function copies the software TCD configuration at for the hardware TCD. You needs fill up the structure stcd, and this function do transfer  all structure data in  DMA registers, is use a especial configuration In this case, the structure is filling up to configuration ELINK mode. The ELINK mode is a configuration of eDMA for triggers other DMA channel in each minion loop transfer is complete.   This is a registers of structure,  the mask to enable put on ElINKON mode  and for select channel to link and for put on the major loop to finishing trigger channel. stcd.BITER.ELINKNO= (DMA_BITER_ELINKNO_ELINK_MASK|0x0000|0x0C); stcd.CITER.ELINKNO= (DMA_CITER_ELINKNO_ELINK_MASK|0x0C);         DMA_BITER_ELINKNO_ELINK_MASK it’s a mask to active the channel-to-channel linking on minor-loop complete. As the channel completes the minor loop, this flag enables linking to another channel, defined by theLINKCH field. The link target channel initiates a channel service request via an internal mechanism You can see more information in Reference manual. ///////configuration DMA channel0 ///////////////////////////////////////////////////////////////////////////////////////     config[kEDMAChannel0].srcAddr = (uint32_t)(&ADC_mux[0]);     /*!< Memory address pointing to the source data. */        config[kEDMAChannel0].destAddr = (uint32_t)(&ADC0_SC1A);   /*!< Memory address pointing to the destination data. */        config[kEDMAChannel0].srcTransferSize = kEDMATransferSize_1Bytes;   /*!< Source data transfer size. */        config[kEDMAChannel0].destTransferSize = kEDMATransferSize_1Bytes;  /*!< Destination data transfer size. */        config[kEDMAChannel0].srcOffset = 1;         /*!< Sign-extended offset applied to the current source address to                                            form the next-state value as each source read/write is completed. */        config[kEDMAChannel0].destOffset = 0;        config[kEDMAChannel0].srcLastAddrAdjust = -3;    /*!< Last source address adjustment. */        config[kEDMAChannel0].destLastAddrAdjust = 0;   /*!< Last destination address adjustment. Note here it is only valid when scatter/gather feature is not enabled. */        config[kEDMAChannel0].srcModulo = kEDMAModuloDisable;       /*!< Source address modulo. */        config[kEDMAChannel0].destModulo = kEDMAModuloDisable;       /*!< Destination address modulo. */        config[kEDMAChannel0].minorLoopCount = 1;    /*!< Minor bytes transfer count. Number of bytes to be transferred                                             in each service request of the channel. */        config[kEDMAChannel0].majorLoopCount = 3;    /*!< Major iteration count. */         uint16_t statusChnn0 = EDMA_DRV_PrepareDescriptorTransfer(&chnDMA0, &stcdDmaChn0, &config[kEDMAChannel0], true, true);        if(kStatus_EDMA_Success == statusChnn0)        {               statusChnn0 = EDMA_DRV_PushDescriptorToReg(&chnDMA0, &stcdDmaChn0);        }         The function drivers in main file:          hardware_init();        dbg_uart_init();        OSA_Init();        init_adc(ADC_INST); init_trigger_source(ADC_INST);        config_DMA();   Open your terminal (baud rate 115200)    The results will appear on the terminal software.   Figure 3. Screen serial You can also see the results in the debugger window. Figure 4.  result buffer Steps to include ADC Flexible Scan software to KSDK   In order to include this demo in the KSDK structure, the files need to be copied into the correct place. The adc_dma_demo 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/ adc_dma_demo /iar <KSDK_install_dir>/demos/ adc_dma_demo /kds <KSDK_install_dir>/demos/ adc_dma_demo /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.

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

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! 🙂

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

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

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

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

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 demo is based on adc12_polling example , and so far I just tested it with FRDM-KE15Z, so please download SDK_2.0_FRDM-KE15Z.zip from Welcome to MCUXpresso | MCUXpresso Config Tools before you try that demo.   After opening the project, you have to import edma and dmamux driver code as below: then you may replace adc12_polling.c with the attached one.   compiling and run, you may see the console output ADC results like this.   Hope that helps, -Kan Original Attachment has been moved to: adc12_polling.c.zip

The SAR-ADC of KM family supports using 4 triggering signals to trigger SAR-ADC, for the KM sub-family with PDB, it is okay to use PDB. But for the KM family without PDB module, it is difficult to generate  4 triggering signals to trigger SAR-ADC. The DOC introduce how to use quadTimer to generate 4 sequential triggering signals to trigger SAR-ADC so taht the SAR-ADC can get 4 samples in one conversion.

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

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

Hello All,   Here is a document for creating an USB Host Project (MSC + fatfs) with KSDK 1.3 and Processor Expert support in KDS. It uses FRDM-K64F board as example and lists some specific considerations that needs to be accomplished when creating an USB Host project by using fsl_usb_framework component (Processor Expert) in Kinetis Software Development Kit (KSDK) version 1.3.   I hope you can find it useful!   Regards, Isaac Avila

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

What is it FreeMASTER?   FreeMASTER is a tool with variety GUIs in one offered free. FreeMASTER is a user-friendly real-time debug monitor and data visualization tool −GUI can be easily extend by multimedia content (charts) and user-modified content (possible mix user´s data with default values) − offers access to target variables, symbols and data types − access over UART, CAN or USB with target-side driver and over BDM − possibility to direct control via variable modifications − addresses parsed from ELF file or provided by target (TSA) − scope graphs with real-time data in [ms] resolution − recorder visualization transitions close to 10[us] resolution     FreeMASTER features Real Time Monitor -Displaying variable values in various formats (Text, Real-Time waveforms, High-speed recorded data) Control Panel - Direct variable value settings and variable stimulation, scribtable in JScript or VBScript Demonstration Platform - Demostration embedded app by HTML pages, display simultaneous real-time data monitoring Easy Project Deployment - Entire project saved to a single file   FreeMASTER communication There are two types of communication. It is possible to communicate via Direct RS232 or selected Plug-in Module. In short: SCI, UART USB – CDC – Kinetis, ColdFire V2 CAN JTAG (56F8xxx only) BDM – Kinetis, PowerPC, ColdFire, HCS with Segger, P&E Micro, CMSIS-DAP…     FreeMASTER usage Real-time debugging - FreeMASTER allows users to debug applications in true real-time through its ability to watch variables. Moreover, it allows debugging at the algorithm level, which helps to shorten the development phase Diagnostic tool - FreeMASTER remote control capability allows it to be used as a diagnostic tool for debugging customer applications remotely across a network Demonstrations - FreeMASTER is an outstanding tool for demonstrating algorithm or application execution and variable outputs. Education - FreeMASTER may be used for educational purposes. Its application control features allow students to play with the application in demonstration mode, learning how to control program execution.   FreeMASTER description of the environment   The FreeMASTER window is divided into 4 parts - Project Tree, Detail View Pane, Commands and Variable Watch Grid. Project Tree is the project, New Block is a root of the project, New Scope is similar to classical Oscilloscope. Scope periodically reads variable values and plots them in real-time. It is limited by the serial communication speed. The recorder is also monitoring and visualising variable values, but the change is much faster. The recorder is running on target board and variable values are sampled into memory buffer on the board and then these sampled data are downloaded from the board to FreeMASTER.   Detail View Area is dynamically changes depending on content which is selected in Project Tree. Detail View Tab can be control page, algorithm block description, scope, recorder or another HTML document whose URL is defined in the Scope or Recorder properties. Commands window is list of commands to send, Variable Stimulus - is the list of defined variables for the defined time. In Variable Watch Grid contains the list of watched variables.   Supported devices FreeMASTER download and support   The installation package you can download from the Official website:   FreeMASTER Official website www.nxp.com/freemaster   You can ask us on Community or you can create new SR according to https://community.freescale.com/docs/DOC-329745   More about FreeMASTER   FreeMASTER Official Website https://www.nxp.com/freemaster   Using FreeMASTER https://cache.freescale.com/files/microcontrollers/doc/reports_presentations/FREEMASTERPRESENT.pdf   FREEMASTER:  Remote Server Tutorial https://community.freescale.com/docs/DOC-103293   Tutorial: FreeMASTER Visualization and Run-Time Debugging https://mcuoneclipse.com/2013/08/24/tutorial-freemaster-visualization-and-run-time-debugging   Let´s continue with reading! Let´s start with KSDK!

The USB stack in ksdk 1.3 has provided a macro of “USBCFG_DEV_ADVANCED_SUSPEND_RESUME” , while the RM says “suspend/resume is not implemented yet.”, but if you looks into the source code, you may find APIs like USB_Suspend_Service() which is reserved for further implementation, so users may use these APIs as a starting point to add suspend and resume feature in ksdk 1.3. The test is based on FRDM-KL27Z, dev_hid_mouse_bm demo. And before we modify the device stack, we have to clone a copy of this demo. Set USBCFG_DEV_ADVANCED_SUSPEND_RESUME to 1 to releases APIs related with suspend and resume features. But we will have the following errors after compile, that is because remote resume function is not supported by KL27. so we should disable it for this device, with the help of #if USBCFG_DEV_ADVANCED_SUSPEND_RESUME == 1 && FSL_FEATURE_USB_KHCI_HOST_ENABLED == 1. For example, like below: 2.Further implement USB_Suspend_Service() and USB_Resume_Service() to let them notify the upper layer application on the event of suspend/resume. With reference of USB_Error_Service() and Don’t forget to add two more events for suspend and resume. 3.USB module has two types of resume interrupt , one is sync resume , issued by the bit of ISTAT[RESUME] bit, the other is async resume, issued by the bit of TRC0[USB_RESUME_INT], so we have to monitor these two interrupt status flag in the ISR, as below: And so we have modify the resume and sleep interrupt services for supporting the async resume interrupt as below: 4.Modify application and add code to handle suspend and resume event, in this case, such kind of events are handled in USB_App_Device_Callback() 5.Verify the hid_mouse demo with USB 2 CV tool from usb.org Select the FS device with VID 15a2 from the list. Test passed! if you print some messages on the event of suspend and resume, you will see something like below from the Terminal channel. 6. Now we can add low power mode switch function in the main application code to meet the suspend current limitation specified by USB spec, with reference of power_manager_hal_demo for frdmkl27z, and for this case, add code in USB_App_Device_Callback() of mouse.c to tell the main application when to enter low power mode. Please also note Don’t enter low power mode in this callback function, as it is called by the interrupt service, so if the device enter low power mode during interrupt, that would prevent the following resume interrupt happen, so the device never wake up! For more details on the implementation, please refer to the attached mouse.c 7.Test low power mode current:   Before test, please do the following modification to the FRDM-KL27Z board: Please note, if your board has the following jumpers, no need to remove R7,R21 and R83, just keep J19 and J22 open during the test. Select the low power mode you are going to test from the Ternimal: Leave KL27 USB port (J10) open and power the board with USB SDA port, that would make the device enter suspend interrupt out of reset. And you may also see the current vary with power mode switch with the help of USB 2 CV tool. I have tested wait, stop and vlps modes, the current measured under these modes are shown as below: Wait: Stop: VLPS: So it is recommend using VLPS mode during USB suspend mode as it far below the suspend current specified in USB spec (500uA). 8. Patch and demo code Please replace the following files with the attached one, as well as the mouse.c in dev_hid_mouse_bm demo. Recompile the stack and application code. C:\Freescale\KSDK_1.3.0\usb\usb_core\device\include\MKL27Z644 usb_device_config.h C:\Freescale\KSDK_1.3.0\usb\usb_core\device\sources\controller usb_dev.h usb_dev.c usb_framework.c C:\Freescale\KSDK_1.3.0\usb\usb_core\device\sources\controller\khci device_khci_interface.c khci_dev.c khci_dev.h C:\Freescale\KSDK_1.3.0\usb\usb_core\device\include usb_device_stack_interface.h C:\Freescale\KSDK_1.3.0\examples\frdmkl27z\demo_apps\usb\device\hid\hid_mouse mouse.c