SPI, which stands for Serial Peripheral Interface, is a standard with a very specific hardware interface. A connection is between a master and a slave, with the master typical being a processor, and the slave being a peripheral such as a sensor, flash memory device, or a modem chip.   It can also be used for processor to processor communications, but in this case, an additional handshake signal is often used. There are normally four signals between a master and a slave, the first is a clock signal, and this signal is always driven by the master, regard which device is transmitting.  The second line is a data line for data going from the master to the slave, and this is designated as the master output, slave input line, are MOSI for short. It connects the SPI data out connection on the master and to the SPI data in connection on the slave. The next conductor is for data in the opposite direction and is labelled as the master input slave output line, are MISO for short. The last conductor is slave select with the slave chip selecting input, and is active low. If you have more than one slave, with the first being perhaps a sensor of some kind, the slave will be dedicated to slave 1. If you add a second sensor, the top 3 interface line will be shared, but it dedicates for slave’s line will be required for the second device, and the same is true of course for each of additional slave device. Most processors have a maxim of 4 slave selected lines.  The four lines could be used effectively as a multiplexed address lines to access more than 4 slaves. You cannot have more than one master on the bus,   since the interface is not support coordination between two masters as to which one is controlling the bus. Transmissions are typically sent as a sequence of bytes, but without a formal protocol, there is nothing restricting communication being   byte based. Typical by frame sizes, are in 8 to 32 bits range.  Also note the bytes and packets are not acknowledged as they are in i2c, and you could have a master synching communicating with the slave but, you don’t really know of your communications are being received OK. However, some slave devices will echo bytes sent to it, which provides an acknowledgement to the master.  it is how the data lines are synchronized with a clock signal. Clock Polarity and Phasing There are four different modes available, one mode each combination clocking in a low state and high state, with a data being read in a rising edge or falling edge of the clock signal.  For modes 0 and 1, the clock is low in idle, which is referred to  as clock and 0,  For modes 2 and 3 then the clock is in high state when idle, so it has  polarity  , one , For modes 0 and 2, the data will be sampled by the receiving device  on the leading edge of a clock signal.  Relative to the idle state, which is referred to a clock phase of zero. So for mode 0, this means the rising edge of the clock and for mode 2, means the following edge of the clock, the other two modes, use a clock phase 1 which means that trailing edge of clock as a returns to an  idle state.  And this translates to a following edge for mode 1 and the rising edge for mode 3.  Mode 0 is the most commonly supported setting. If multiple slaves in the same bus, you may have to reconfigure the settings for the master to which modes when you want to communicate with a different slave.

I have just implemented an I2C demo for my customer, he found no demo for MMA8451Q based on MQX 4.1, so I personally wrote one for him based on the I2C EEPROM demo, as well as the driver code for MMA8451Q supporting both polled and interrupt mode. I think maybe it would be interesting for someone else, so I posted it here. The demo is for TWR-K60D100M, but I think it should be easy to port to some platform else, for example , TWR-K21F120M, all you have to do is creating a new MQX project and replace the source code with the attached one, Please also note the I2C device address might be different in tower boards. You may change the deifintion of I2C_MMA8451_BUS_ADDRESS in MMA8451.h according to the schematics. Please kindly refer to the attached result.txt for more details. Hope that helps, B.R Kan

Store web pages externally step by step Web pages can be stored on any media accessible via MFS, such as USB memory stick, SD card. It is also possible to use FFS and store web pages on NAND flash. The following example is a step by step guide on how MQX can use nandflash on TWR-K70F120M, we start with the httpsrv demo. 1. Add FTP server  and nandflash flush support This demo starts with default HTTPSRV example, Shell console is enabled in the default httpdsrv.c. Ping, ipconfig and help commands are enabled by default. We add ftpsrv application to support FTP protocol , and nandflash support. 2. Allow RTCS for more sockets We will use two TCP servers. There is one socket need for HTTPSRV listening socket, second listening socket for FTP server. One socket for each connected client. 3 .Add MFS library to the HTTPSRV build project By default, MFS library is not enabled in the HTTPSRV project. It uses only TFS for web pages storage. We add path to MFS library into HTTPSRV build project   4. Add FFS support to the HTTPSRV build project Ffs library is not enabled by default. We need to add path into HTTPSRV build library. Install FFS driver and open it. 5. Resolve build errors When we try to build now the HTTPSRV example, we have compile errors. This is because by default the HTTPSRV example does not include MFS and FFS library head files. We need to add a path for MFS and FFS 6. Configure HTTPSRV root directory Web pages of this demo are to be stored in nandflash within web_pages folder. We need to set rootdir and index Before we can view the web page in browser, we need to copy web pages to nand flash. This is the purpose of FTP server, as one example how to copy files. If you wish to be sure the web pages survive power cycle, make sure you flush the FFS file system after “web_pages” are copied. 7. Build, Download, Execute As hardware we use TWR-K70F120M and TWR-SER. After you download the executable and run, start FTP server by issuing command “ftpsrv  start” on serial console; start FTP client; copy over files from PC host to TWR nandflash. Keep the folder structure of the copied files; now open your web browser (support for HTML5 is required); open Url http://192.168.1.202

Table of Contents Product Information on Freescale.com MQX Software Solutions Product Summary Page MQX Software Solutions Documentation MQX Software Solutions Downloads MQX Software Solutions Training Frequently Asked Questions (FAQ) General MQX FAQs Technical MQX FAQs Other Resources MQX Training Videos MQX Add-On Software

Hello all, This document describes how to create a FreeRTOS project in KDS using the Kinetis SDK Project Generator tool. If you are interested in how to Create a FreeRTOS project using KDS and Kinetis SDK Project V2.0 please check the below link: https://community.freescale.com/docs/DOC-330183 In order to follow this document, first it is necessary to install: Kinetis Design Studio (KDS) Kinetis Design Studio Integrated Development |NXP KINETIS-SDK: Software Development Kit for Kinetis MCUs Software Development Kit for Kinetis MCUs|NXP KSDK Project Generator tool Software Development Kit for Kinetis MCUs|NXP Creating a new project using the Project Generator tool Kinetis SDK Project Generator tool is a supplement to the KSDK. It is intended to provide users with a convenient method for generating KSDK based projects for their intended target hardware. The KSDK Project Generator requires the user to install an instance of KSDK 1.2.0 or 1.3.0 before generating new projects. The KSDK Project Generator requires operates on Windows, Linux, and Mac OSX. 1. Launch the Project Generator executable. 2. Introduce the Project Name and choose the board used. For this example it is used the TWR-K64F120M. 3. In order to generate a FreeRTOS project, click on the "Advanced" button. 4. Choose the operating system, in this case FreeRTOS, the IDE KDS and select Generate standalone project. 5. After that, click on "Advanced Generate" button to create the project. Open the project in KDS Every application/example created using the KSDK Project Generator tool has one associated working set description file which includes the path to the example project file and the dependent RTOS library project file. Simply import that file into KDS working space. At this point you should be able to build the library and the project created. Developing a FreeRTOS with KSDK application Operating System Abstraction layer (OSA) provides a common set of services for drivers and applications so that they can work with or without the operating system. OSA provides these services: task management, semaphore, mutex, event, message queue, memory allocator, critical part, and time functions. An easy method to create a task is using  the OSA_TASK_DEFINE macro and the function OSA_TaskCreate(). The macro OSA_TASK_DEFINE declares a task handler and task stack statically. The function OSA_TaskCreate() creates task base-on the resources declared by OSA_TASK_DEFINE. The parameters for this function are: The stack size in byte. Pointer to the stack. The stack size in byte. Pointer to the stack. Initial priority of the task: OSA supports task priorities 0∼15, where priority 0 is the highest priority and priority 15 is the lowest priority. Pointer to be passed to the task when it is created. If this task will use float register or not. Pointer to the task handler. NOTE: The disadvantage with this method is that task function can only create one task instance. The project created using the Project Generator tool creates one  task (task_example) implementing OSA. For more information about functions, macros and drivers please consult the Kinetis SDK v.1.3 API Reference Manual. This is located, after install Kinetis SDK, at the path: <install_KSDK_1.3.0_path>\doc GPIO Example 1. Add a new task named task_led. Add also a macro for OSA_TASK_DEFINE, the priority of the task and the prototype. To initialize and start RTOSes, OSA uses abstract functions OSA_Init() and OSA_Start(). Call OSA_Init() after calling hardware_init(). 2. Create the empty body of task_led 3. Add the following code initialization code for GPIO driver. PRINTF("\nLED TASK is running \n"); /* Enable clock for PORTs */ CLOCK_SYS_EnablePortClock(PORTA_IDX); CLOCK_SYS_EnablePortClock(PORTE_IDX); //Initializes GPIO driver GPIO_DRV_Init(switchPins, ledPins); 4. Now add logic to toggle a LED when a button is pressed. while(1) { //  check if SW2 is pressed if(GPIO_DRV_ReadPinInput(kGpioSW3) == 0) { GPIO_SW_DELAY; GPIO_DRV_TogglePinOutput(BOARD_GPIO_LED_BLUE); } } 5. It is needed a delay for the push buttons debounce. In this case it is GPIO_SW_DELAY which is defines as follows: /*Delay for Switch debounce*/ #define GPIO_SW_DELAY \ do \ { \ uint32_t i; \ for (i = 0; i < 0x2FFFFF; i++) \ { \ __asm("nop"); \ } \ } while (0) GPIO 6. Build and debug the project. Enjoy...

Interrupts can be handled by MQX (MQX managed ISR) or bypassing MQX (MQX kernel ISR). If you want that MQX handled all the ISR process, you can use MQX managed ISR.  By this ISR,  MQX catches all hardware interrupts in the range that the BSP defined and saves the context of the active task. For most interrupts, MQX calls the ISR that is stored in the interrupt vector table at the location identified by its interrupt vector number. The disadvantage with this is the interrupt latency is longer and depends completely on MQX. Hardware vector table for all MQX managed isrs points to MQX kernel function _int_kernel_isr()). This function invokes user isr by jumping into instruction pointed by "isr_ptr" , as the below graph shows. A task can install an MQX managed ISR interrupt using:  _int_install_isr(interrupt_vector_number,isr_ptr,isr_data_ptr) _bsp_int_init(Vector, Pri, Subpri, TRUE); Vector – number of non-core vector (for example, 37 for LLWU, defined in IRQInterruptIndex in the MCU header file) Pri – priority of the interrupt source. Allowed values: MQX_HARDWARE_INTERRUPT_LEVEL_MAX, MQX_HARDWARE_INTERRUPT_LEVEL_MAX + 1, …, 7, where 7 is the lowest application interrupt priority level. Subpri – zero on Kinetis. Enable – TRUE to enable the interrupt vector source in NVIC.  At this level of interrupt, you can call MQX services. The other option is MQX kernel ISR. Some real-time applications need special event handling to occur outside the scope of MQX. The need might arise that the latency in servicing an interrupt be less than the MQX interrupt latency. If this is the case, an application can use _int_install_kernel_isr() to bypass MQX and let the interrupt be serviced immediately. You will have the very same Performance as if you were running bare metal. A kernel ISR must save the registers that it needs and must service the hardware interrupt. When the kernel ISR is finished; it must restore the registers and perform a return-from-interrupt instruction. Even though the compiler handles this for you.   In this case, you can't use MQX services.  However, you can put data in global area, which a task can access. The disadvantage on this is shared data problem and you can impact the kernel if the restoring stack fails.   If you need faster MQX kernel ISR, you can install Kernel ISR with : _int_install_kernel_isr(vector_num, isr_ptr)  _bsp_int_init(Vector, Pri, Subpri, TRUE); Vector – number of non-core vector (for example, 79 for FTM1, defined in IRQInterruptIndex in the MCU header file) Pri – priority of the interrupt source. Allowed values: 0 for highest priority kernel isr, 1, ..,MQX_HARDWARE_INTERRUPT_LEVEL_MAX-1 for lowest priority kernel isr. Subpri – zero on Kinetis. Enable – TRUE to enable the interrupt vector source in NVIC. And very important, to install a HW interrupt handler, you need the HW interrupt table in RAM, so your user_config.h has to define MQX_ROM_VECTORS to 0.   Next is a demo to show how to use mqx kernel ISR, you can download it for more details.   static void GPIO_Init(void); static void IRQ_Init (void); void PortA_ISR(void); void PortE_ISR(void);                TASK_TEMPLATE_STRUCT MQX_template_list[] = { /*  Task number, Entry point, Stack, Pri, String, Auto? */    {MAIN_TASK,   Main_task,   1500,  9,   "main", MQX_AUTO_START_TASK},    {0,           0,           0,     0,   0,      0,                 } };   char SW=0;     /*TASK*----------------------------------------------------- * * Task Name    : Main_task * Comments     : *    This task prints " Hello World " * *END*-----------------------------------------------------*/   void Main_task(uint_32 initial_data) {    int counter=0;                printf("\n Hello World \n");       GPIO_Init();       IRQ_Init();       while(1){                   if(SW==1){                                  SW=0;                                  printf("IRQ A was generated\n");                   }                   if(SW==2){                                  SW=0;                                  printf("IRQ E was generated\n\r");                   }                   printf("Waiting for IRQ... %d\n\r", counter);                   counter++;                   _time_delay(1000);    }       _mqx_exit(0); }   static void GPIO_Init(void){                               SIM_SCGC5 = (0|SIM_SCGC5_PORTA_MASK|SIM_SCGC5_PORTE_MASK); /* Enable clock for PORTA */                               PORTA_PCR19 |= (0|PORT_PCR_MUX(1)|PORT_PCR_IRQC(0xA));//|PORT_PCR_PE_MASK;//|PORT_PCR_PS_MASK;                PORTE_PCR26 |= (0|PORT_PCR_MUX(1)|PORT_PCR_IRQC(0xA))|PORT_PCR_PE_MASK|PORT_PCR_PS_MASK; }   static void IRQ_Init (void){                uint32_t result;                                                  /* install the interrupt routine */                _int_install_kernel_isr (103, PortA_ISR);                _int_install_kernel_isr (107, PortE_ISR);                                              result = _cortex_int_init(107, 2, TRUE);                result = _cortex_int_init(103, 3, TRUE);                }   void PortA_ISR(void){                SW=1;                PORTA_ISFR=0xFFFFFFFF;  //Clear Port A ISR flags }   void PortE_ISR(void){                SW=2;                PORTE_ISFR=0xFFFFFFFF;  //Clear Port E ISR flags }

When working on Cortex-M4 platform, an exception which has not been expected (an interrupt without ISR, an access to an illegal address, etc). The code below shows how to implement it. static void expt_frm_dump(pointer ext_frm_ptr) {   static char *expt_name[] = {     "None",     "Reset",     "NMI",     "HardFault",     "MemManage",     "BusFault",     "UsageFault",     "Rsvd",     "Rsvd",     "Rsvd",     "SVCall",     "Debug Monitor",     "Rsvd",     "PendSV",     "SysTick"   };   uint_32 excpt_num = __get_PSR() & 0x1FF;   printf("Opps, bad thing happened.\n");   if(excpt_num < 16){     printf("The exception [%s] invoked in TASK 0x%x\n",          expt_name[excpt_num] , _task_get_id());     printf("Dump the exception frame as :\n");     printf("R0:\t0x%08x\n", *((uint_32 *)ext_frm_ptr));     printf("R1:\t0x%08x\n", *((uint_32 *)ext_frm_ptr + 1));     printf("R2:\t0x%08x\n", *((uint_32 *)ext_frm_ptr + 2));     printf("R3:\t0x%08x\n", *((uint_32 *)ext_frm_ptr + 3));     printf("R12:\t0x%08x\n", *((uint_32 *)ext_frm_ptr + 4));     printf("LR:\t0x%08x\n", *((uint_32 *)ext_frm_ptr + 5));     printf("PC:\t0x%08x\n", *((uint_32 *)ext_frm_ptr + 6));     printf("PSR:\t0x%08x\n", *((uint_32 *)ext_frm_ptr + 7));   }else{     printf("The external interrupt %d occured while no handler to serve it.\n");   } } void  task_exception_handler(_mqx_uint para, pointer stack_ptr) {     pointer expt_frm_ptr = (pointer)__get_PSP();     expt_frm_dump(expt_frm_ptr); } void test_task(unsigned long para) {   unsigned int *p_bad = (unsigned int *)0;   printf("Install the _int_exception_isr to replace the _int_default_isr\n");   _int_install_exception_isr();   /* Set the exception handler of the task */   _task_set_exception_handler(_task_get_id(), task_exception_handler);   *p_bad = 0;     // an access to address 0    _task_block(); }

MQX RTCS Memory Configuration Parameters Introduction         RTCS uses some global variables when an application creates it. All the variables have default values. If you want to change the values, the application must do so before it creates RTCS. There are various configuration parameters that allow to fine tune RTCS memory usage. Next I will introduce the parameters, and I hope it will help beginners in configuration the RTCS correctly 1    _RTCSPCB / _RTCS_msgpool / _RTCS_socket_part RTCSPCB represents the pool of Packet Control Blocks - the number of packets you want RTCS to handle at any given time. RTCSPCB has influence on losing packets. RTCS_msgpool represents the pool of RTCS messages, used to encapsulate application requests to RTCS – the number of simultaneous application requests to RTCS. RTCS_Sockets represents the pool of sockets – the number of sockets in existence at any point in time. “_init” is pre-allocated count, allocation happens when RTCS starts. During runtime, when RTCS needs more of these resources, it allocates more by "_grow" chunks until the "_max" is consumed, which is the effective limit for RTCS resources. These parameters must be called before _RTCS_start By default these parameters are defined as RTCSCFG_PCBS_INIT, RTCSCFG_PCBS_GROW, RTCS_PCBS_MAX, RTCSCFG_MSGPOOL_INIT, RTCSCFG_MSGPOOL_GROW, RTCSCFG_PCBS_MAX, RTCSCFG_SOCKET_PART_INIT, RTCSCFG_SOCKET_PART_GROW,  RTCSCFG_SOCKET_PART_MAX. In application we can override these defaults by _init, _grow, _max. We also can override these in user_config.h. How to configure these parameters?   We don’t have a formal method how to configure these for a specific application. We can start with the defaults and then spent some time increasing these parameters, then we can use RTCS TAD window to see, what RTCS resources are out. Then increase the one a bit. Example:  the configuration in web_hvac demo _RTCSPCB_init = 4; _RTCSPCB_grow = 2; _RTCSPCB_max = 20; _RTCS_msgpool_init = 4; _RTCS_msgpool_grow = 2; _RTCS_msgpool_max  = 20; _RTCS_socket_part_init = 4; _RTCS_socket_part_grow = 2; _RTCS_socket_part_max  = 20; RTCS_Create(); 2  Tx Window Size and Rx Window Size Each socket requires to allocation Tx and Rx window size for a listening socket and then for each connected client.  The default tx window size and rx window size are 4380 bytes. With TAD, we can see that every new TCP socket connection needs extra 500+4392x2+148=9432B   as follows: MQX -> Lightweight Memory Block Summary Size (Decimal) Owner    Type 500      0x10001 TCP Control Block;RTCS/TCP 4392 0x10001  TCP Tx Window;RTCS/TCP 4392 0x10001  TCP Rx Window;RTCS/TCP 148 0x10001  TCP Send Clock;RTCS/TCP (TCP/IP Task id is 0x10001) If we call setsockopt() to reduce these two buffers, for example,            uint_32 value; … value = 1024; setsockopt(sock, SOL_TCP,OPT_TBSIZE,&value,sizeof(value)); setsockopt(sock, SOL_TCP,OPT_RBSIZE,&value,sizeof(value)); The memory usage to open a new TCP socket will drop as follows: MQX -> Lightweight Memory Block Summary Size (Decimal) Owner    Type 500  -> 500   0x10001  TCP Control Block;RTCS/TCP 4392 -> 1108   0x10001 TCP Tx Window;RTCS/TCP 4392 -> 1108   0x10001  TCP Rx Window;RTCS/TCP 148  -> 84   0x10001  TCP Send Clock;RTCS/TCP So we can see that, every new socket connection needs extra 500+1108*2+84=2800

If you have noticed many TCP Retransmission, Out Of Order or Duplicate Acknowledge packets while running a TCP/IP application based on MQX RTCS then you may be interested in this article. After some investigation it comes to be that the default value of global variable _TCP_rto_min may cause this congestion depending on your application. Finally this problem was solved by setting a new value to this variable after calling function RTCS_create(). This article explains what is behind this behavior and how _TCP_rto_min affects the performance in an application using RTCS.

The MQX 4.0.2 BSP doesn't support VLPS mode out of box, and RXEDGE interrupt is not enabled either, so there are several steps to do before implementing the demo. modify user_config.h #define BSPCFG_ENABLE_TTYB                        0 #define BSPCFG_ENABLE_ITTYB                       1 MQX enables UART in polled mode by default, and here we enable the UART1 interrupt mode, the TTY port may vary depending on the platform. modify BSP_DEFAULT_IO_CHANNEL in twrk20d72,.h as below: #ifndef BSP_DEFAULT_IO_CHANNEL #if BSPCFG_ENABLE_ITTYB #define BSP_DEFAULT_IO_CHANNEL                      "ittyb:"    /* OSJTAG-COM   interrupt mode */ #define BSP_DEFAULT_IO_CHANNEL_DEFINED #else #define BSP_DEFAULT_IO_CHANNEL                      NULL #endif modify LPM_CPU_OPERATION_MODES[] in init_lpm.c as below: const LPM_CPU_OPERATION_MODE LPM_CPU_OPERATION_MODES[LPM_OPERATION_MODES] = { // LPM_OPERATION_MODE_RUN { LPM_CPU_POWER_MODE_RUN,                     // Index of predefined mode 0,                                          // Additional mode flags 0,                                          // Mode wake up events from pins 0..3 0,                                          // Mode wake up events from pins 4..7 0,                                          // Mode wake up events from pins 8..11 0,                                          // Mode wake up events from pins 12..15 0                                           // Mode wake up events from internal input sources }, // LPM_OPERATION_MODE_WAIT { LPM_CPU_POWER_MODE_VLPS,//LPM_CPU_POWER_MODE_VLPR,                    // Index of predefined mode 0,                                          // Additional mode flags 0,                                          // Mode wake up events from pins 0..3 0,                                          // Mode wake up events from pins 4..7 0,                                          // Mode wake up events from pins 8..11 0,                                          // Mode wake up events from pins 12..15 0                                           // Mode wake up events from internal input sources }, // LPM_OPERATION_MODE_SLEEP { LPM_CPU_POWER_MODE_WAIT,                    // Index of predefined mode LPM_CPU_POWER_MODE_FLAG_SLEEP_ON_EXIT,      // Additional mode flags 0,                                          // Mode wake up events from pins 0..3 0,                                          // Mode wake up events from pins 4..7 0,                                          // Mode wake up events from pins 8..11 0,                                          // Mode wake up events from pins 12..15 0                                           // Mode wake up events from internal input sources }, // LPM_OPERATION_MODE_STOP { LPM_CPU_POWER_MODE_LLS,                     // Index of predefined mode 0,                                          // Additional mode flags 0,                                          // Mode wake up events from pins 0..3 0,                                          // Mode wake up events from pins 4..7 0,                                          // Mode wake up events from pins 8..11 0,                                          // Mode wake up events from pins 12..15 LLWU_ME_WUME0_MASK                          // Mode wake up events from internal input sources - LPT } }; Here we map LPM_OPERATION_MODE_WAIT to VLPS mode add following code in _kuart_int_rx_tx_isr() from serl_int_kuart.c   if (sci_ptr->S2 & UART_S2_RXEDGIF_MASK)          {                     sci_ptr->S2 = UART_S2_RXEDGIF_MASK;                     sci_ptr->BDH &= 0xBF; /* clear RXEDGIE */          } so that RXEDG event is checked in _kuart_int_rx_tx_isr() for low power mode. replace main.c in "C:\Program Files\Freescale\MQX_4_0_2\mqx\examples\lowpower" with the attached one. After recompiling MQX libs as well as the low power demo, you may test the VLPS mode just as shown in the attached video.   Hope that helps, B.R Kan Original Attachment has been moved to: VLPS-test.7z.zip Original Attachment has been moved to: main.c.zip Original Attachment has been moved to: serl_int_kuart.c.zip Original Attachment has been moved to: user_config.h.zip Original Attachment has been moved to: init_lpm.c.zip

In this section, we will cover the light weight ADC driver, which enable you to read the ADC the output and raw form, and converted to scale form , or even as average level over a number of reads. The light weight ADC driver also allows you to configure a number of attributes of the converter.  So you can customize your application. Quick overview of ADC ADC is a system that converts an analog signal into digital signal. Simply put, Analog signals here means any variable voltage that is being monitored. It doesn’t matter what the signal is doing, it can remain the same level continuously, it can have slight wave to it, or it can be seemingly random. The analog to digital converter requires you to provide the reference voltage. That defines the maximum level that the input can be.  To determine the voltage level of the input the circular ADC generate a local voltage, and just this level until the same level as the input.   This can be done in different ways but the circuitry will adjust the level of the local signal until the comparator to detect the two inputs are the same or lease the same as the resolution of ADC, once the signal level is matched, the output generated.  Which can be read by your application.  To calculate the signal level the ADC defines the full range from the input into the three levels.  ADC typically have a resolution of 12 to 16 bits, so the 2 12   to 2 16 different levels. Whatever level input signals determined to be add , the reading from the ADC will be a digital representation of this value compare the  reference voltage. The digital output then represents what percentage of the allowed input range the input signal is currently add. Being at the minimum level will result an output of zero and being the max will resut in an output of 0xffff. And for inputs some in between the result is the output that represents the level measured. So if you are using a reference voltage of 3.3V for example, the reading will represent what flection the 3.3 v  the input voltage is .  If the input voltage is zero.  The reading will be 0 of course. And if the input is 3.3 v, the reading will be all FF, meaning 100 percent. So in between, if the input voltage is 1v, the result will be roughly 30.3%. And an input of 2v, will result the input roughly 60.6%, and 3v will be 90.9%. ADC Driver in MQX architecture Diagram The light weight ADC driver is considered a low level driver and is located alongside the LWGPIO driver. This is because we don’t trade the interfaces as a part of serial communication, they passing data back and forth in blocks or in bytes, also it doesn’t make sense to be accessing the drivers through the IO subsystem.   There is a section dedicated to ADC module in bsp files folder in project. (take twrk70f120m for example) The ADC priority is defined as 3, though ADC is typically not used with interrupts,  The default reference voltage and maximum voltage is 3300mV. The input setting of the potentiometer is connected to ADC1_SOURCE_AD20 in Twr-k70 board. The adc1 device is designated as the default ADC device ADC API    1 _lwadc_init() This function initializes the ADC module according to the parameters given in the platform specific initialization structure. Call to this function does not start any ADC conversion. This function is normally called in the BSP initialization code.   2  _lwadc_init_input () This function initializes the application allocated LWADC_STRUCT with all data needed later for quick control of particular input. This function sets the ADC input to continuous conversion mode if not already in this mode. 3 _lwadc_set_attribute / _lwadc_get_attribute :  both this functions receive a pointer to the LWADC_STRUCT_PRT ,  and the attributes you interested in. All the attributes are defined in an enum LWADC_ATTRIBUTE. 4 _lwadc_read_raw () Read the current value of the ADC input and return the result without applying any scaling. 5 _lwadc_read () This function reads the current value of the ADC input, applies scaling according to preset parameters. 6 _lwadc_read_average() This function reads num_sample samples from the specified input and returns the scaled average reading. 7  _lwadc_wait_next() This function waits for a new value to be available on the specified ADC input.

MQXv5 is Coming! NXP has teamed up with Embedded Access to continue active development of MQX software solutions, providing regular updates, enhancements and ports to new processors. With the introduction of MQX v5, an extension to MQX Classic v4.2, and with new commercial licensing, developers can continue to use MQX with the latest Kinetis, i.MX, and other processors. Compare MQX Classic and MQX v5 by visiting nxp.com/MQX. Then, give us your feedback on which devices and features you’d like supported in this newest addition, MQX v5. Note, the first MQX v5 products are expected to be available near the end of Q3, 2016. MQX v5 products will be purchasable at nxp.com/mqxv5 and through distribution partners.

Hi everybody, Some times it is necessary to work with short interrupts in MQX or get smaller delays. MQX measures time in ticks, instead of in seconds and milliseconds. This document describes how to get a smaller delay or Interrupt, editing the BSP_ALARM_FREQUENCY in order to have smaller ticks. In addition the document shows how to use the MQX hwtimer driver. I hope you like it. Best regards, Soledad Godinez Technical Support Engineer

The attached document explains how to create a C++ project using CW10.6 with GCC compiler, MQX 4.1. Regards, Carlos

MQX RTOS developers can now build and debug MQX RTOS on Linux computers right out-of-the-box without extensive setup steps.  Linux support is provided in a separate version of MQX 4.1.0, repackaged for use on Linux systems.  Kinetis & Vybrid BSPs from MQX 4.1.0 are supported.  The new package is in beta stage.  It includes the same basic code as the previous 4.1.0 version, with just the changes needed to build and debug on Linux systems. Download Freescale MQX RTOS 4.1.0 for Linux Beta Depending on the popularity of this release, Freescale may extend Linux support to future MQX RTOS mainline releases.  Stay tuned. Give us your feedback!  Post to the MQX community.  Let us know what you think. Development tools Supported: DS-5 Vybrid Controller Edition 5.16.0  (Vybrid) GNU Tools for ARM Embedded Processors version 4.7-2013-q3  (Kinetis & Vybrid) Here are some brief instructions I put together when using with Ubuntu 12.04: - Download and install gcc for arm (comes with gdb for debugging)   See other post:  gcc compiling + gdb debugging on Kinetis on a Linux host - Kinetis L Examples available - Download and extract the .tar.gz file to a location of your choice    mac@mac-VirtualBox:/$  tar -zxvf Freescale_MQX_4_1_LINUX_beta.tar.gz - Edit global.mk to tell it where your gcc toolchain is located.    mac@mac-VirtualBox:/$ cd <directory where you extracted mqx>/Freescale_MQX_4_1_LINUX_beta/build/common/make/    mac@mac-VirtualBox:/$ vi global.mak    un-comment the section on gcc_arm and set the TOOLCHAIN_ROOTDIR.  For my toolchain gcc is installed to the path /usr/    ifreq ($(TOOL),gcc_arm)        TOOLCHAIN_ROOTDIR  =  /usr/   endif - See  MQX GNU Getting Started Guide for instructions on how to build and debug.     This document is located at /Freescale_MQX_4_1_LINUX_beta/doc/tools/gnu/ Good luck with your next project.  Happy developing!

Hi all, I want to share this document that describes steps to create a new driver using MQX 4.1 and CW 10.6.  I used the Null-Device Driver,  the null device driver provides an I/O device that functions as a device driver but does not perform any work. I hope it helps. Regards Sol

The Kinetis Software Development Kit (KSDK) is a software framework for developing applications on Kinetis MCUs. The software components in the framework include peripheral drivers, middleware and real time operating systems. KSDK provides FreeRTOS OS, selected drivers provide FreeRTOS support in form of an additional layer. This solution enables simple driver integration in RTOS-based applications. Drivers with FreeRTOS layers are: • UART / LPUART / LPSCI • I2C / LPI2C • SPI / LPSPI The drivers for FreeRTOS OS is a layer built on top of standard KSDK peripheral drivers to achieve multithread (RTOS) awareness. The wrappers provide an API which blocks the calling task until the I/O operation completes and allows other tasks to run in the background. This is achieved by using the asynchronous API of the underlying driver along with RTOS task synchronization objects. Underlying drivers require enabled interrupts for proper operation. In addition, it is possible to use the KSDK bare metal drivers. This document shows how to use the LPTMR Driver in a FreeRTOS and SDK 2.0 project. For this example it is used SDK 2.0, FRDMK64F and FreeRTOS. If you want to know how to create a new SDK 2.0 with FreeRTOS project please check the below link: https://community.freescale.com/docs/DOC-330183 GPIO AND LPTMR EXAMPLE: Introduction This example toggle the Blue LED every 1 second. This example check the Timer Compare Flag bit, when this flag is set blue LED changes status. Writing the example code First it is necessary to create a new SDK 2.0 with FreeRTOS project, please check the below link for do that.      https://community.freescale.com/docs/DOC-330183    2. After create a new project, open the pin_mux.c file in order to enable the port clock and configure the necessary pins as GPIO (for FRDM-K64F the RGB LED is connected   through GPIO signals: RED to PTB22, BLUE to PTB21 and GREEN to PTE26).   3. In addition, it is necessary to enable the clock for the lptmr module, in the pin_mux.c file.   4. In main.c file it is necessary to include the fsl_lptmr.h and fsl_gpio.h.   5. In main function, create a new task. This task will initialize the LPTMR and GPIO drivers. For this example the new task function was named task_init. /* Create RTOS task */    xTaskCreate(                  task_init,                  "Task_Init",                  configMINIMAL_STACK_SIZE,                  NULL,                  task_PRIORITY,                  NULL);     6. Write the task_init function code.                   a. Using the KSDK GPIO driver: To initialize the GPIO, define a pin configuration, either input or output, in the user file. Then, call the GPIO_PinInit() function. In this case the pin PTB21 where blue LED is connected was configured as output. gpio_pin_config_t ledB_config = {kGPIO_DigitalOutput, 0,}; GPIO_PinInit(BOARD_LED_BLUE_GPIO, BOARD_LED_BLUE_GPIO_PIN, &ledB_config); After configure the GPIO pins, it is possible to use the below GPIO operations: GPIO OUTPUT OPERATIONS. GPIO_WritePinOutput  (GPIO_Type *base, uint32_t pin, uint8_t output) GPIO_SetPinsOutput (GPIO_Type *base, uint32_t mask) GPIO_ClearPinsOutput (GPIO_Type *base, uint32_t mask) GPIO_TogglePinsOutput (GPIO_Type *base, uint32_t mask) GPIO INPUT OPERATIONS. GPIO_ReadPinInput (GPIO_Type *base, uint32_t pin) The board.h file contains definitions for this operations. For example: /*!< Toggle on target LED_BLUE */ #define LED_BLUE_TOGGLE() \ GPIO_TogglePinsOutput(BOARD_LED_BLUE_GPIO, 1U << BOARD_LED_BLUE_GPIO_PIN)                   b. Using the KSDK LPTMR driver: The LPTMR_Init () should be called at the beginning of the application using the LPTMR driver. This function initializes the lptmr_config_t structure, this structure holds the configuration settings for the LPTMR peripheral. To initialize this structure to reasonable defaults, call the LPTMR_GetDefaultConfig () function and pass a pointer to your config structure instance. The config struct can be made const so it resides in flash. The default values are: config->timerMode = kLPTMR_TimerModeTimeCounter; config->pinSelect = kLPTMR_PinSelectInput_0; config->pinPolarity = kLPTMR_PinPolarityActiveHigh; config->enableFreeRunning = false; config->bypassPrescaler = true; config->prescalerClockSource = kLPTMR_PrescalerClock_1; config->value = kLPTMR_Prescale_Glitch_0; After configure the LPTMR, it is necessary to set the timer period. The LPTMR_SetTimerPeriod(), the timer counts from 0 till it equals the count value set here. The count value is written to the CMR register. Finally start the timer using the LPTMR_StarTimer (). After calling this function, the timer counts up to the CMR register value. Each time the timer reaches CMR value and then increments, it generates a trigger pulse and sets the timeout interrupt flag. An interrupt will also be triggered if the timer interrupt is enabled. For this example the below lines configure and start the LPTMR. /* Configure LPTMR */ LPTMR_GetDefaultConfig(&lptmrConfig); /* Initialize the LPTMR */ LPTMR_Init(LPTMR0, &lptmrConfig); /* Set timer period */ LPTMR_SetTimerPeriod(LPTMR0, USEC_TO_COUNT(1000000U, LPTMR_SOURCE_CLOCK)); /* Start counting */ LPTMR_StartTimer(LPTMR0);                   c. This example check the Timer Compare Flag bit, when this flag is set blue LED changes status. So in an infinity loop the LPTMR_GetStatusFlags() function check                       the status flag, if this flag is set then toggle the LED and clear the flag using the the LPTMR_ClearStatusFlags() function. while (1)    {    if (LPTMR_GetStatusFlags(LPTMR0) )           { LED_BLUE_TOGGLE();                       LPTMR_ClearStatusFlags(LPTMR0, kLPTMR_TimerCompareFlag);                } }   7. At this point you can build and debug the example. Complete Code GPIO and LPTMR Example #include <string.h> #include "board.h" #include "pin_mux.h" #include "clock_config.h" #include "fsl_debug_console.h" #include "fsl_device_registers.h" #include "fsl_lptmr.h" #include "fsl_gpio.h" /* FreeRTOS kernel includes. */ #include "FreeRTOS.h" #include "task.h" #include "queue.h" #include "timers.h" /* Task priorities. */ #define task_PRIORITY (configMAX_PRIORITIES - 1) /******************************************************************************* * Definitions ******************************************************************************/ /* Get source clock for LPTMR driver */ #define LPTMR_SOURCE_CLOCK CLOCK_GetFreq(kCLOCK_LpoClk) static void task_init(void *pvParameters); /******************************************************************************* * Variables ******************************************************************************/ volatile uint32_t lptmrCounter = 0U; int main(void) {        /* Init board hardware. */        BOARD_InitPins();        BOARD_BootClockRUN();        BOARD_InitDebugConsole();        /* Add your code here */        /* Create RTOS task */        xTaskCreate(                      task_init,                      "Task_Init",                      configMINIMAL_STACK_SIZE,                      NULL,                      task_PRIORITY,                      NULL);        vTaskStartScheduler();        for(;;) { /* Infinite loop to avoid leaving the main function */               __asm("NOP"); /* something to use as a breakpoint stop while looping */        } } static void task_init(void *pvParameters) {        for (;;) {               lptmr_config_t lptmrConfig;               PRINTF("You are running the initialization task.\r\n");               /* Init output LED GPIO. */               gpio_pin_config_t ledB_config = {kGPIO_DigitalOutput, 0,};               GPIO_PinInit(BOARD_LED_BLUE_GPIO, BOARD_LED_BLUE_GPIO_PIN, &ledB_config);               PRINTF("LED BLUE initialized \r\n");               /* Configure LPTMR */               /*                * lptmrConfig.timerMode = kLPTMR_TimerModeTimeCounter;                * lptmrConfig.pinSelect = kLPTMR_PinSelectInput_0;                * lptmrConfig.pinPolarity = kLPTMR_PinPolarityActiveHigh;                * lptmrConfig.enableFreeRunning = false;                * lptmrConfig.bypassPrescaler = true;                * lptmrConfig.prescalerClockSource = kLPTMR_PrescalerClock_1;                * lptmrConfig.value = kLPTMR_Prescale_Glitch_0;                */               LPTMR_GetDefaultConfig(&lptmrConfig);               /* Initialize the LPTMR */               LPTMR_Init(LPTMR0, &lptmrConfig);               /* Set timer period */               LPTMR_SetTimerPeriod(LPTMR0, USEC_TO_COUNT(1000000U, LPTMR_SOURCE_CLOCK));               PRINTF("Low Power Timer module initialized \r\n");               /* Start counting */               LPTMR_StartTimer(LPTMR0);               while (1)               {                      if (LPTMR_GetStatusFlags(LPTMR0) )                      {                            lptmrCounter++;                            LED_BLUE_TOGGLE();                            LPTMR_ClearStatusFlags(LPTMR0, kLPTMR_TimerCompareFlag);                      }               }        } }

Essentials of MQX RTOS Application Development Free Online Training Series with Videos, Tutorials, and Example Software! 10-Part Series - even more coming later [Scroll down to see all Sessions] Session 1: MQX Architecture and Initialization (20 min) Creating tasks Setting priorities Scheduling Synchronization concepts Introduction to drivers Session 2: Designing for a Multi-Tasking Environment (15 min) Writing applications in a Multi-Tasking Environment Super Loop Programming Limitations, Task Coding Structure Task States What is a blocking call? Task Context Switching Session 3: Task Management and the Scheduler (21 min) How does the MQX scheduler work? Scheduling Policies Priority-based, Time-slice (Round Robin) Selecting Priority Levels for Tasks What is the Task Template List? Using Tasks in your Application Session 4: Synchronization and Message Passing (17 min) What is Synchronization?  What is it used for? Data Flow, Control Flow, Mutual Exclusion Synchronization Options Events, Semaphores, Mutexes, Message Passing Message Passing Types of Message Pools, Message Pool Creation, Sending and Receiving, Light-weight Message Passing Session 5: Introduction to Drivers (28 min) Driver Architecture and options Block vs. Byte modes, POSIX drivers, Low level drivers, Polled vs. Interrupt modes Driver Initialization I/O Subsystem (POSIX) Serial Driver Details Light-weight GPIO Driver Details Session 6: Interrupts (15 min) Interrupts and the scheduler Techniques for writing an ISR Hardware Vector Table Nested Interrupts MQX Interrupt ISR Table Installing ISRs Default Interrupt handler Session 7: Light Weight Events (15 min) Overview of events Working with light-weight & full-featured events Ways to wait on an event Session 8: Light Weight Timers (17 min) One shot vs periodic timers Use cases for timers Working with correlated timers Writing timer Interrupt Service Routines (ISRs) Light weight timers & timer queues Timers and the timer task Session 9: Light Weight ADC Driver (18 min) Light-weight ADC driver (LWADC) Details Attributes of ADCs Configuring and reading ADCs Scaling the ADC output Session 10: Logging (23 min) What is logging?  Why use logs? Working with light-weight logs Working with kernel logging Logging MQX function and ISR entries and exits, task and stack usage Working with full-featured logs

MQX Chinese User Manual

This is report from internal USB flash drive plugfest (tested with MQX 4.0). VID PID VID Manufacturer Photo Vendor info Product info 0x0dba 0x0120 Realtek Generic Card Reader 0x8564 0x1000 Transcend JetFlash Transcend 4GB 0x0951 0x1654 Kingston Technology Kingston DT R500 0x0951 0x1647 Kingston Technology Kingston DT Mini Fun G2 0x0204 0x6025 Chipsbank Microelectronics CMB USB2.0 0x1516 0x1213 Myson-Century Technology USB DISK 2.0 0x1b1c 0x1ab1 Corsair Technology Corsair Voyager 0x0001 0x7778 Fry's Electronics Generic Flash Disk 0x125f 0xc08a ADATA ADATA USB Flash Drive (C008/32GB) 0x0dda 0x2026 Apacer ICSI IC1210 CF 0x0ea0 0x6828 Ours Technology 32MB HardDrive 0x0781 0x5530 SanDisk SanDisk SanDisk Cruzer (SDCZ36-004G) 0x111d 0x0000 IDT CENTON Swivel 0x0781 0x5406 SanDisk SanDisk SanDisk Cruzer (SDZ6-8192RB) 0x8564 0x1000 Transcend JetFlash Transcend 16GB 0x0951 0x1642 Kingston Technology Kingston DT 101 G2