MQXソフトウェアソリューションナレッジベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

MQX Software Solutions Knowledge Base

ディスカッション

ソート順:
Hi everybody, As there is not a New MQX 4.2 Project Wizard, it is necessary to create a project from scratch. Here, we will create a new project making a copy from an example Project, for this example we are using FRDM-K64F120M but the process is similar for all the Freescale boards. 1. Import hello_frdmk64f example and just copy-paste it using Ctrl + C and Ctrl + V keys. 2. Delete the virtual folder to avoid editing the original file. 3. Create a New physical folder and named it Sources. 4. In Sources folder create a New Source file and name it main.c 5. Go to menu Project > Properties > C/C++ Build > Settings > Cross ARM GNU Assembler > Includes and delete all the paths. 6. Go to menu Project > Properties > C/C++ Build > Settings > Cross ARM C Compiler > Includes, delete all the paths and replace them with the following: C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\bsp\Generated_Code C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\bsp C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\psp C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\mfs C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\rtcs C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\shell C:\Freescale\Freescale_MQX_4_2\usb_v2\<used_board>.kds\debug\usbh\mqx ${eclipse_home}../toolchain/lib/gcc/arm-none-eabi/4.8.4/include ${eclipse_home}../toolchain/lib/gcc/arm-none-eabi/4.8.4/include-fixed ${eclipse_home}../toolchain/arm-none-eabi/include For the FRDM-K64F120M C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug\bsp\Generated_Code C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug\bsp C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug\psp C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug\mfs C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug\rtcs C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug\shell C:\Freescale\Freescale_MQX_4_2\usb_v2\output\frdmk64f.kds\debug\usbh\mqx ${eclipse_home}../toolchain/lib/gcc/arm-none-eabi/4.8.4/include ${eclipse_home}../toolchain/lib/gcc/arm-none-eabi/4.8.4/include-fixed ${eclipse_home}../toolchain/arm-none-eabi/include Note: You can use  Ctrl + C and Ctrl + V keys. 7. Go to menu Project > Properties > C/C++ Build > Settings > Cross ARM C Linker > General and replace the linker file path with the following C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\bsp\intflash.ld For the FRDM-K64F120M C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug\bsp\intflash.ld   8. Go to menu Project > Properties > C/C++ Build > Settings > Cross ARM C Linker > Miscellaneous and replace all Other objects with the following: C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\bsp\bsp.a C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\psp\psp.a C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\mfs\mfs.a C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\rtcs\rtcs.a C:\Freescale\Freescale_MQX_4_2\lib\<used_board>.kds\debug\shell\shell.a C:\Freescale\Freescale_MQX_4_2\usb_v2\output\<used_board>.kds\debug\usbh\mqx\libusbh_mqx.a ${eclipse_home}../toolchain/lib/gcc/arm-none-eabi/4.8.4/armv7e-m/fpu/libgcc.a ${eclipse_home}../toolchain/arm-none-eabi/lib/armv7e-m/fpu/libc.a ${eclipse_home}../toolchain/arm-none-eabi/lib/armv7e-m/fpu/libsupc++.a ${eclipse_home}../toolchain/arm-none-eabi/lib/armv7e-m/fpu/libm.a ${eclipse_home}../toolchain/arm-none-eabi/lib/armv7e-m/fpu/libnosys.a For the FRDM-K64F120M C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug\psp\psp.a C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug\mfs\mfs.a C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug\rtcs\rtcs.a C:\Freescale\Freescale_MQX_4_2\lib\frdmk64f.kds\debug\shell\shell.a C:\Freescale\Freescale_MQX_4_2\usb_v2\output\frdmk64f.kds\debug\usbh\mqx\libusbh_mqx.a ${eclipse_home}../toolchain/lib/gcc/arm-none-eabi/4.8.4/armv7e-m/fpu/libgcc.a ${eclipse_home}../toolchain/arm-none-eabi/lib/armv7e-m/fpu/libc.a ${eclipse_home}../toolchain/arm-none-eabi/lib/armv7e-m/fpu/libsupc++.a ${eclipse_home}../toolchain/arm-none-eabi/lib/armv7e-m/fpu/libm.a ${eclipse_home}../toolchain/arm-none-eabi/lib/armv7e-m/fpu/libnosys.a 9. Click to Apply and Ok buttons. 10. Go to C:\Freescale\Freescale_MQX_4_2\mqx\examples\hello and copy all the content in hello.c to main.c in your project 11. At this point you can be able to build and debug your New project. Enjoy...
記事全体を表示
A pair of TCP server & client and a pair UDP server & client are implemented to demo socket API in RTCS. It supports K60N512 and K70F120M on IAR EWARM 6.50 at this moment. You can port it to other boards and IDE easily. 1) Copy Freescale_MQX_4_0 folder and override the default MQX folder 2) RTCS Socket Example Guide.doc can be found in ..\Freescale_MQX_4_0\rtcs\examples\socket
記事全体を表示
Que tal, Este documento es para toda persona que comienzan a trabajar con MQX . El documento describe como crear una tarea y como usar el driver LWGPIO. Esta escrito en español pensando en nuestros clientes de habla hispana. Saludos Sol
記事全体を表示
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.
記事全体を表示
by: Luis Garabito Applications Engineer TICS, Mexico The time invested to develop applications for the first time in a new environment can be significant. It is necessary to understand how the environment works and then be able to generate applications for this environment. The purpose of this application note is to provide the knowledge that enables developers to start quickly and easily with the development of their first application on Freescale MQXLite RTOS. This document provides the bases that developers will need to understand to create basic Freescale MQXLite applications. This Application Note is based on the Kinetis KL2 USB MCUs Family, specifically, the KL25Z128VLK4 micro controller. The Freescale Freedom development platform board (FRDM–KL25Z) is also used for this example. The full application note is attached.
記事全体を表示
CREATE MQX FOR KSDK PROJECT FROM SCRATCH IN IAR IDE Note: ${KSDK_PATH} is used in this guide line to instead of path of KSDK source (Example: C:/Freescale/KSDK_1.2.0/). This procedure was created for TWR-K64f120M 1     Create new workspace                 Open IAR  --> File  --> New  --> Workspace                 2     Create new project Project --> Create New Project  --> C  -> main --> OK                    Select project directory                              3    Add project lib to workspace         Project  -->  Add Existing Project … then select projects: {SDK_PATH}/lib/ksdk_mqx_lib/iar/K64F12/ksdk_mqx_lib.ewp {SDK_PATH}/rtos/mqx/mqx/build/iar/mqx_twrk64f120m/mqx_twrk64f120m.ewp {SDK_PATH}/rtos/mqx/mqx_stdlib/build/iar/mqx_stdlib_twrk64f120m/mqx_stdlib_twrk64f120m.ewp                        4    Build All Lib project                   5    Setting Project On the left workspace pane, right click on Mqx Project and select Options. Setting General Options         Select device:                       Setting C/C++ Compiler          Add include file and define symbols for project at Preprocessor tab: Additional include directories: {SDK_PATH}/rtos/mqx/lib/twrk64f120m.iar/debug {SDK_PATH}/rtos/mqx/lib/twrk64f120m.iar/debug/config {SDK_PATH}/rtos/mqx/lib/twrk64f120m.iar/debug/mqx {SDK_PATH}/rtos/mqx/lib/twrk64f120m.iar/debug/mqx_stdlib {SDK_PATH}/platform/osa/inc {SDK_PATH}/platform/CMSIS/Include {SDK_PATH}/platform/devices {SDK_PATH}/platform/hal/inc {SDK_PATH}/platform/drivers/inc {SDK_PATH}/platform/system/inc {SDK_PATH}/platform/devices/MK64F12/include {SDK_PATH}/platform/devices/MK64F12/startup {SDK_PATH}/platform/system/inc {SDK_PATH}/platform/hal/inc {SDK_PATH}/platform/drivers/inc {SDK_PATH}/platform/startup {SDK_PATH}/platform/utilities/inc {SDK_PATH}/examples/twrk64f120m {SDK_PATH}/rtos/mqx/config {SDK_PATH}/rtos/mqx/mqx/source/include Defined symbols: CPU_MK64FN1M0VMD12 TWR_K64F120M FSL_RTOS_MQX                         Setting Linker option           Use linker file in KSDK source:             {KSDK_PATH}/platform/devices/MK64F12/linker/iar/MK64FN1M0xxx12_flash.icf           Set stack/heap size and define __ram_vector_table__ __stack_size__=0x400 __heap_size__=0x400 __ram_vector_table__=1                           The project request three librarys: lib_mqx.a, lib_mqx_stdlib.a, libksdk_platform_mqx.a {KSDK_PATH}/lib/ksdk_mqx_lib/iar/K64F12/Debug/libksdk_platform_mqx.a {KSDK_PATH}/rtos/mqx/lib/twrk64f120m.iar/debug/mqx/lib_mqx.a {KSDK_PATH}/rtos/mqx/lib/twrk64f120m.iar/debug/mqx_stdlib/lib_mqx_stdlib.a              MQX uses owner’s startup-code (boot.S), We need to override default program entry                        6     Create project template Project structure and create group:          Specific file for board in: {KSDK_PATH}\examples\twrk64f120m\board.c {KSDK_PATH}\examples\twrk64f120m\board.h {KSDK_PATH}\examples\twrk64f120m\gpio_pins.c {KSDK_PATH}\examples\twrk64f120m\gpio_pins.h {KSDK_PATH}\examples\twrk64f120m\pin_mux.c {KSDK_PATH}\examples\twrk64f120m\pin_mux.h          BSP file in: {KSDK_PATH}\rtos\mqx\mqx\source\bsp\bsp.h {KSDK_PATH}\rtos\mqx\mqx\source\bsp\bsp_config.h {KSDK_PATH}\rtos\mqx\mqx\source\bsp\init_bsp.c {KSDK_PATH}\rtos\mqx\mqx\source\bsp\mqx_main.c {KSDK_PATH}\rtos\mqx\mqx\source\include\mqx.h          Config files in: {KSDK_PATH}\rtos\mqx\config\common\small_ram_config.h {KSDK_PATH}\rtos\mqx\config\common\verif_enabled_config.h {KSDK_PATH}\rtos\mqx\config\board\twrk64f120m\user_config.h {KSDK_PATH}\rtos\mqx\config\mcu\MK64F12\mqx_sdk_config.h           Utilities files in: {KSDK_PATH}\platform\utilities\src\print_scan.c {KSDK_PATH}\platform\utilities\src\print_scan.h {KSDK_PATH}\platform\utilities\src\fsl_debug_console.c {KSDK_PATH}\platform\utilities\inc\fsl_debug_console.h                                                                7    Write code The code below is used to turn on the LED and print out “hello world”. #include "stdio.h" #include "fsl_os_abstraction.h" #include "board.h" #include "fsl_debug_console.h" #define MAIN_TASK        8 void main_task(uint32_t param); const TASK_TEMPLATE_STRUCT  MQX_template_list[] = {    { MAIN_TASK, main_task, 0xC00, 20, "main_task", MQX_AUTO_START_TASK},    { 0L, 0L,        0L,    0L, 0L,         0L } }; void main_task(uint32_t param) {     LED1_EN;     LED1_ON;     PRINTF("Hello World\r\n");     while(1)     {} } 8    Run example: Build project:                   Select debug target                     - Set serial console 115200 baud rate, no parity, 8 data bits, 1 stop bit, without flow control - Set project as active prior we run project Run project                         See Led1 is On status and string “Hello World” is printed to screen                           
記事全体を表示
This document shows how to use a mutex and semaphores in order to synchronize two tasks in a FreeRTOS and SDK 2.0 project. For this example it is used SDK 2.0, TWR-K64F120M, 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 MUTEX EXAMPLE: Introduction A mutex provides mutual exclusion among tasks, when they access a shared resource. When used for mutual exclusion the mutex acts like a token that is used to guard a resource. When a task wishes to access the resource it must first obtain ('take') the token. When it has finished with the resource it must 'give' the token back - allowing other tasks the opportunity to access the same resource. Mutexes cannot be used in interrupt service routines. Mutexes use the same semaphore access API functions. Writing a Mutex example code The mutex example code is used to demonstrate how to use a mutex to synchronize two tasks. It creates a mutex and two tasks. Both tasks use PRINTF to print out messages. Each task will lock the mutex before printing and unlock it after printing to ensure that the outputs from tasks are not mixed together. According with this proposal it is necessary to follow the below steps. In main function, create a mutex using the xSemaphoreCreateMutex() API. This API creates a mutex, and returns a handle by which the created mutex can be referenced. Mutexes cannot be used in interrupt service routines. xMutex = xSemaphoreCreateMutex(); Create two tasks with the same priority, these tasks will use PRINTF to print out messages.        xTaskCreate(write_task_1,"write_task_1",configMINIMAL_STACK_SIZE,NULL,                      task_PRIORITY, NULL);        xTaskCreate(write_task_2,"write_task_2",configMINIMAL_STACK_SIZE,NULL,                      task_PRIORITY, NULL); The two print tasks both use the PRINTF. If they used it in the same time, there would be conflicts, so a mutex is used to synchronize the two tasks. Each print task will try to lock the mutex before printing the message, using the macro xSemaphoreTake (SemaphoreHandle_t xSemaphore,TickType_t xTicksToWait); it will wait for the mutex as long as needed. Once the mutex is locked it prints the message and then unlocks the mutex  with the macro xSemaphoreGive (SemaphoreHandle_t xSemaphore) so that the other task can lock it. This process is repeated indefinitely. static void write_task_1(void *pvParameters) {     while (1)     { xSemaphoreTake(xMutex, portMAX_DELAY);         PRINTF("Hello, this is the |");         taskYIELD();         PRINTF("first task \r\n"); xSemaphoreGive(xMutex);         taskYIELD();     } } static void write_task_2(void *pvParameters) { while (1) { xSemaphoreTake(xMutex, portMAX_DELAY); PRINTF("And now this is the |"); taskYIELD(); PRINTF(" second task\r\n"); xSemaphoreGive(xMutex); taskYIELD(); } } At this point you can build and debug the example. Complete Code /* Kernel includes. */ #include "FreeRTOS.h" #include "task.h" #include "queue.h" #include "timers.h" #include "semphr.h" /* Freescale includes. */ #include "fsl_device_registers.h" #include "fsl_debug_console.h" #include "board.h" #include "pin_mux.h" #include "clock_config.h" /******************************************************************************* * Definitions ******************************************************************************/ SemaphoreHandle_t xMutex; /******************************************************************************* * Prototypes ******************************************************************************/ static void write_task_1(void *pvParameters); static void write_task_2(void *pvParameters); /******************************************************************************* * Code ******************************************************************************/ /*! * @brief Main function */ int main(void) { xMutex = xSemaphoreCreateMutex(); BOARD_InitPins(); BOARD_BootClockRUN(); BOARD_InitDebugConsole(); xTaskCreate(write_task_1, "WRITE_TASK_1", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 1, NULL); xTaskCreate(write_task_2, "WRITE_TASK_2", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 1, NULL); /* Start scheduling. */ vTaskStartScheduler(); for (;;) ; } /*! * @brief Write Task 1 function */ static void write_task_1(void *pvParameters) { while (1) { xSemaphoreTake(xMutex, portMAX_DELAY); PRINTF("Hello, this is the "); taskYIELD(); PRINTF("first task \r\n"); xSemaphoreGive(xMutex); taskYIELD(); } } /*! * @brief Write Task 2 function */ static void write_task_2(void *pvParameters) { while (1) { xSemaphoreTake(xMutex, portMAX_DELAY); PRINTF("And now this is the "); taskYIELD(); PRINTF(" second task\r\n"); xSemaphoreGive(xMutex); taskYIELD(); } } SEMAPHORE EXAMPLE: Introduction Binary semaphores and mutexes are very similar but have some subtle differences: Mutexes include a priority inheritance mechanism, binary semaphores do not. This makes binary semaphores the better choice for implementing synchronisation (between tasks or between tasks and an interrupt), and mutexes the better choice for implementing simple mutual exclusion. A semaphore can be used in order to control the access to a particular resource that consists of a finite number of instances. Writing a Semaphore example code After install SDK 2.0 you can find a semaphore example at the path: <SDK_install_path>\SDK_2.0_xxx\boards\<your_name>\rtos_examples\freertos_sem The example uses four tasks. One producer_task and three consumer_tasks. The producer_task starts by creating of two semaphores (xSemaphore_producer and xSemaphore_consumer). These semaphores control access to virtual item. The synchronization is based on bilateral rendezvous pattern. Both of consumer and producer must be prepared to enable transaction. Here’s the API (copied from the FreeRTOS website): MODULES xSemaphoreCreateBinary SemaphoreHandle_t xSemaphoreCreateBinary( void ); Creates a binary semaphore, and returns a handle by which the semaphore can be referenced. xSemaphoreCreateBinaryStatic SemaphoreHandle_t xSemaphoreCreateBinaryStatic(                           StaticSemaphore_t *pxSemaphoreBuffer ); Creates a binary semaphore, and returns a handle by which the semaphore can be referenced. xSemaphoreCreateCounting SemaphoreHandle_t xSemaphoreCreateCounting(                                             UBaseType_t uxMaxCount, UBaseType_t uxInitialCount); Creates a counting semaphore and returns a handle by which the newly created semaphore can be referenced. xSemaphoreCreateCountingStatic SemaphoreHandle_t xSemaphoreCreateCountingStatic(                                  UBaseType_t uxMaxCount,                                  UBaseType_t uxInitialCount StaticSemaphore_t pxSempahoreBuffer ); Creates a counting semaphore and returns a handle by which the newly created semaphore can be referenced. xSemaphoreCreateMutex SemaphoreHandle_t xSemaphoreCreateMutex( void ) Creates a mutex, and returns a handle by which the created mutex can be referenced. Mutexes cannot be used in interrupt service routines. xSemaphoreCreateMutexStatic SemaphoreHandle_t xSemaphoreCreateMutexStatic(                             StaticSemaphore_t *pxMutexBuffer ); Creates a mutex, and returns a handle by which the created mutex can be referenced. Mutexes cannot be used in interrupt service routines. xSemaphoreCreateRecursiveMutex SemaphoreHandle_t xSemaphoreCreateRecursiveMutex( void ) Creates a recursive mutex, and returns a handle by which the mutex can be referenced. Recursive mutexes cannot be used in interrupt service routines. configUSE_RECURSIVE_MUTEXES must be set to 1 in FreeRTOSConfig.h for xSemaphoreCreateRecursiveMutex() to be available. xSemaphoreCreateRecursiveMutexStatic SemaphoreHandle_t xSemaphoreCreateRecursiveMutexStatic( StaticSemaphore_t *pxMutexBuffer ) Creates a recursive mutex, and returns a handle by which the mutex can be referenced. Recursive mutexes cannot be used in interrupt service routines. configUSE_RECURSIVE_MUTEXES must be set to 1 in FreeRTOSConfig.h for xSemaphoreCreateRecursiveMutexStatic() to be available. vSemaphoreDelete void vSemaphoreDelete( SemaphoreHandle_t xSemaphore ); Deletes a semaphore, including mutex type semaphores and recursive semaphores. Do not delete a semaphore that has tasks blocked on it (tasks that are in the Blocked state waiting for the semaphore to become available). xSemaphoreGetMutexHolder TaskHandle_t xSemaphoreGetMutexHolder( SemaphoreHandle_t xMutex ); Return the handle of the task that holds the mutex specified by the function parameter, if any. xSemaphoreGetMutexHolder() can be used reliably to determine if the calling task is the mutex holder, but cannot be used reliably if the mutex is held by any task other than the calling task. xSemaphoreTake xSemaphoreTake( SemaphoreHandle_t xSemaphore,                  TickType_t xTicksToWait ); Macro to obtain a semaphore. The semaphore must have previously been created with a call to xSemaphoreCreateBinary(), xSemaphoreCreateMutex() or xSemaphoreCreateCounting(). xSemaphoreTakeFromISR xSemaphoreTakeFromISR(         SemaphoreHandle_t xSemaphore,         signed BaseType_t *pxHigherPriorityTaskWoken ) A version of xSemaphoreTake() that can be called from an ISR. Unlike xSemaphoreTake(), xSemaphoreTakeFromISR() does not permit a block time to be specified. xSemaphoreTakeRecursive xSemaphoreTakeRecursive( SemaphoreHandle_t xMutex,                          TickType_t xTicksToWait ); Macro to recursively obtain, or 'take', a mutex type semaphore. The mutex must have previously been created using a call to xSemaphoreCreateRecursiveMutex(); configUSE_RECURSIVE_MUTEXES must be set to 1 in FreeRTOSConfig.h for this macro to be available. xSemaphoreGive xSemaphoreGive( SemaphoreHandle_t xSemaphore ); Macro to release a semaphore. The semaphore must have previously been created with a call to xSemaphoreCreateBinary(), xSemaphoreCreateMutex() or xSemaphoreCreateCounting(), and obtained using sSemaphoreTake(). xSemaphoreGiveRecursive xSemaphoreGiveRecursive( SemaphoreHandle_t xMutex ) Macro to recursively release, or 'give', a mutex type semaphore. The mutex must have previously been created using a call to xSemaphoreCreateRecursiveMutex(); configUSE_RECURSIVE_MUTEXES must be set to 1 in FreeRTOSConfig.h for this macro to be available. xSemaphoreGiveFromISR xSemaphoreGiveFromISR(         SemaphoreHandle_t xSemaphore,         signed BaseType_t *pxHigherPriorityTaskWoken) Macro to release a semaphore. The semaphore must have previously been created with a call to xSemaphoreCreateBinary() or xSemaphoreCreateCounting(). Mutex type semaphores (those created using a call to xSemaphoreCreateMutex()) must not be used with this macro. uxSemaphoreGetCount UBaseType_t uxSemaphoreGetCount( SemaphoreHandle_t xSemaphore ); Returns the count of a semaphore. Enjoy!!!
記事全体を表示
Quick Overview of FreeRTOS vs MQX RTOS MQX  real-time operating system is designed for uniprocessor, multiprocessor, and distributed-processor embedded real-time system. Freescale semiconductor adopted this software platform for its microprocessors.  This includes Kinetis, Coldfire, PowerPC, ARC,ARM, StrongARM, xscale CPUs. The main features of MQX RTOS are scalable size, component-oriented architecture and easy of use. FreeRTOS is a popular real-time operating system kernel for embedded devices, that has been ported to 35 architectures. It is distributed under the GPL with an optional exception. FreeRTOS provides a very small footprint, low overhead and very fast execution. The kernel itself consist of only three or four C files. 4-8k bytes of flash minimum. Similar features : [to be done] Tasks, events, semaphores,mutex, message queues, power saving when idle                                                                  Freertos unique features : 1 Task nofifications: Each RTOS task has a 32-bit notification value which is initialized to zero when the RTOS task is created. An RTOS task notification is an event sent directly to a task that can unblock the receiving task, and optionally update the receiving task’s notification value. 2 Recursive mutex:  A mutex used recursively can be 'taken' repeatedly by the owner. The mutex doesn't become available again until the owner has called xSemaphoreGiveRecursive() for each successful xSemaphoreTakeRecursive() request. For example, if a task successfully 'takes' the same mutex 5 times then the mutex will not be available to any other task until it has also 'given' the mutex back exactly five times. 3 Stack overflow hook/notification: Each task maintains its own stack. The memory used by the task stack is allocated automatically when the task is created, and dimensioned by a parameter passed to the xTaskCreate() API function. Stack overflow is a very common cause of application instability. FreeRTOS therefore provides two optional mechanisms that can be used to assist in the detection and correction of just such an occurrence 4 Deferred interrupt handling:  Used from application interrupt service routines to defer the execution of a function to the RTOS daemon task. A mechanism is provided that allows the interrupt to return directly to the task that will subsequently execute the pended function. This allows the callback function to execute contiguously in time with the interrupt - just as if the callback had executed in the interrupt itself 5 Blocking on multiple objects:  Queue sets are a FreeRTOS feature that enables an RTOS task to block (pend) when receiving from multiple queues and/or semaphores at the same time. Queues and semaphores are grouped into sets, then, instead of blocking on an individual queue or semaphore, a task instead blocks on the set. MQX unique features: 1 Destruction of resource based on ownership:  [to be done] 2 Name services:  tasks can associate a 32-bit number with a string or symbolic name.MQX RTOS stores the association in a names database that all tasks on the processor can use. The database avoids global variables. 3 Inter-Processor Communication:  An application can run concurrently on multiple processors with one executable image of MQX RTOS on each processor. The images communicate and cooperate using messages that are transferred by memory or over communication links using inter-processor communication. The application tasks in each image need not be the same and, indeed, are usually different. 4 Watchdogs: Watchdogs are option components that let the user detect task starvation and deadlock conditions at the task level. 5 Task Queue Scheduling:  you can use task queues to explicitly schedule tasks or to create more complex synchronization mechanisms. Because task queues provide minimal functionality, they are fast. An application can specify a FIFO or round robin scheduling policy when it creates the task queue
記事全体を表示
It took me a while, plus a few contradicting and confusing answers from ARM support until I managed to make this work. Therefore, I do want to share with you the easiest method in order to save you some precious time (tested with MQX 4.0): 1. Make sure to install keil's TAD plugin during the MQX installation (it can also be installed separately from MQX\tools\keil_extensions\uVision4). 2. Make the following changes in the MQX configuration file "user_config.h": #define BSPCFG_ENABLE_IODEBUG   1 #define BSP_DEFAULT_IO_CHANNEL  "iodebug:" 3. Rebuild BSP debug library. 4. Configure Debugger as detailed in your MQX release documentation, which can be found in the following folder: MQX\doc\tools\uv4\MQX-uVision4-Getting-Started.pdf That's it, you're good to go - now you can see printf's using your uVision4 IDE console!
記事全体を表示
The new Freescale MQX™ RTOS 4.1.0 FRDM-K64F release is now available on the www.freescale.com ·         Files available # Name Description 1 FSL_MQX_FRDM-K64F_RELEASE_NOTES Freescale   MQX™ RTOS 4.1.0 FRDM-K64F Release Notes 2 Freescale   MQX RTOS 4.1.0 for the FRDM-K64F Includes   an RTOS, File System, TCP/IP and USB host/device software stacks. Does not   require MQX™ 4.1 installation. ·         Target HW board o   FRDM-K64F ·         New features o   PSP support for the Kinetis K64F o   BSP for the FRDM-K64F development board o   Standard set of I/O drivers supporting the K64F peripherals including: §  LWGPI/O driver §  Serial interrupt and polled driver §  SPI driver §  I2C interrupt and polled driver §  LWADC §  Flash Driver §  RTC Driver §  PIT Timer §  LPT Timer §  WDOG §  Low-power Mode §  SAI §  DMA §  SD Card §  Ethernet driver o   USB Host and Device drivers and stacks o   Example and demo applications demonstrating MQX, USB, RTCS, and MFS usage ·         Known issues o   For known issues and limitations please consult the release notes.
記事全体を表示
Sharing notes taken during creation of MQX 4.0 K10 BSP. These particular notes are for 72 MHz version of K10 (part number K10DX128VLL7), so the baseline BSP for this is twrk20d72m, tested with CodeWarrior IDE. (I believe analogous steps could be taken for other K10 versions as well, just need to select appropriate baseline BSP.) For the K10 BSP, we need to remove USB related code (as there is no USB module on K10) and add #elif into some *mk20.c files such as adc_mk20.c and spi_mk20.c.      1. Add a new unique CPU ID into c:\Freescale\Freescale_MQX_4_0\mqx\source\psp\cortex_m\psp_cpudef.h. For example: #define PSP_CPU_MK10DX128       (PSP_CPU_NUM(PSP_CPU_ARCH_ARM_CORTEX_M4, PSP_CPU_GROUP_KINETIS_K1X, 4))      2. Copy processor header file MK10D7.h from c:\Freescale\CW MCU v10.3\MCU\ProcessorExpert\lib\Kinetis\iofiles\MK10D7.h to c:\Freescale\Freescale_MQX_4_0\mqx\source\psp\cortex_m\cpu\mk10d7.h      3. In the header file: c:\Freescale\Freescale_MQX_4_0\mqx\source\psp\cortex_m\kinetis.h add #include "MK10D7.h" for your processor. For example: #elif   (MQX_CPU == PSP_CPU_MK10DX128)    #include "MK10D7.h"      4. Use BSP clone tool to clone baseline BSP (twrk20d72m) into a new BSP with a new name such as "board_k10d72m".      5. In user_config.h of the new BSP, c:\Freescale\Freescale_MQX_4_0\config\board_k10d72m\user_config.h change MQX_CPU as it follows: #define MQX_CPU                 PSP_CPU_MK10DX128      6. PSP builds OK. From BSP, we need to remove USB related code in init_gpio.c comment lines 609 and 612 c:\Freescale\Freescale_MQX_4_0\mqx\source\bsp\board_k10d72m\init_gpio.c: /* SIM_SOPT2_REG(SIM_BASE_PTR) |= SIM_SOPT2_USBSRC_MASK | SIM_SOPT2_PLLFLLSEL_MASK;*/ /* SIM_SCGC4_REG(SIM_BASE_PTR) |= SIM_SCGC4_USBOTG_MASK;*/      7. In CW IDE, remove USB source code from "bsp_board_k10d72m" build project under "Peripheral IO Drivers". Remove complete "usb" virtual folder from the BSP build project. Remove "init_usb.c" from "board_k10d72m BSP Files"      8. In BSP source file "spi_mk20.c" c:\Freescale\Freescale_MQX_4_0\mqx\source\io\spi\spi_mk20.c add #elif for k10: #elif (MQX_CPU == PSP_CPU_MK10DX128) static const pointer dspi_address[] = {    (pointer)SPI0_BASE_PTR,    (pointer)SPI1_BASE_PTR, }; static const uint_32 /*PSP_INTERRUPT_TABLE_INDEX*/ dspi_vectors[][1] = {    { INT_SPI0 },    { INT_SPI1 }, }      9. Similar change need to adc_mk20.c c:\Freescale\Freescale_MQX_4_0\mqx\source\io\adc\kadc\adc_mk20.c: #elif (MQX_CPU == PSP_CPU_MK10DX128) static const pointer adc_address[] = {    (pointer)ADC0_BASE_PTR,    (pointer)ADC1_BASE_PTR };      10. BSP project builds OK.      11. MFS, RTCS, SHELL projects build OK.      12. If you wish to build an MQX application with this new BSP, don't forget to change the paths to MQX libs and include files in your application project: C compiler "-i" option:   (for Debug build configuration)     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\bsp     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\psp     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\mfs     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\rtcs     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\shell     $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\bsp\Generated_Code Linker additional libraries:   psp.a, bsp.a, mfs.a, rtcs.a, shell.a Linker Library search paths:   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\bsp   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\psp   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\mfs   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\rtcs   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\shell Path to linker command file:   $(MQX_ROOT_DIR)\lib\board_k10d72m.cw10\debug\bsp\intflash.lcf
記事全体を表示
If anybody meets an issue with MQX 3.8 (also 3.8.1, 4.0 and 4.0.1) writing to a Compact flash (/mfs/examples/cfcard), there is an error in the cfcard io driver. Compact flash can be read, but writing doesn't work. Fix for this is in the source file: c:\Freescale\Freescale MQX 3.8\mqx\source\io\pcflash\apcflash.c in function _io_apcflash_write() on line 452, change from: results = _io_apcflash_read_write_blocks(fd_ptr, info_ptr, data_ptr, num, FALSE); change to: results = _io_apcflash_read_write_blocks(fd_ptr, info_ptr, data_ptr, num, TRUE); Tested on M5329EVB and MQX 3.8.1.
記事全体を表示
INTRODUCTION Have you posted a question and it has been unanswered? It could be because of couple of reasons. I would like to highlight few of them. Because posts like "it does not work" have a real chance to be ignored. More you share, easier for others to reproduce it. USE SEARCH FUNCTIONALITY Before you even start creating your own post, use search functionality here in the community. Lot of questions have been answered already, do not please duplicate posts. DOCUMENTATION Available documentation is located inside MQX installation folder: <MQX_INSTALL_DIR>\doc. There are two most important documents: MQX User Guide and MQX Reference Manual. You might find your answer there. HOW WOULD AN IDEAL POST LOOK LIKE It should contain: 1. product version (MQX version) 2. platform (MCU) 3. compiler (IDE) 4. target (release/debug and flash/ram) 5. detailed description 6. code snippet (if not the exact code, at least literally what it does and where it fails) The best is to post a code or at least a snippet of what fails. Try to minimize the software, create a small application which you can share to prove it is not functional properly. The code most of the time help us to reproduce a problem and make it fail in the same way. Otherwise we can only guess what it could be which makes entire process harder and longer. Please use C++ highlight (available in Advanced editor, last symbol (>>) ). It makes code easier to read with visual splitting a code from a text. /* code example (C++ higlight) */ int main(void) {   return 1; } If you tackle with any problem, please specify what you have done so far, read or tried anyhow. State what you expected to happen. Write down an error which has occur, if any. Does current version of MQX break the code which has been running on previous release? Diff files to find out differences. Does documentation not provide enough details? Does the code look obfuscated? Let us know! SHARING IS CARING We would like to hear your feedback! Share a result with us. Helps us to improve user experience! If you get an answer which has helped you, please reply and share the outcome, how did you solve it. Any user can encounter similar or even the same problem. Be part of the community. Regards, c0170 I'll post here some references which are valuable to the topic and I suggest everybody read them. References: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html http://www.softwaretestinghelp.com/how-to-write-good-bug-report/
記事全体を表示
The Freescale MQX Software Solution includes a comprehensive Board Support Package (BSP) supporting common peripherals and functions. However, some applications will require customization of the available drivers or the development of new ones. Pulse width modulation (PWM) is a technique used to encode a message into a pulsing signal. PWM is in used in an extensive variety of applications, ranging from motor control, measurement and communications to power control and conversion, among others. PWM driver is not part of the MQX however there is possible to add your own driver. The purpose of this document is show two different ways to implement PWM signal using MQX and Kinetis devices: a) using bareboard code b) using processor expert in order to create a driver. USING BAREBOARD CODE: As there is no MQX driver for FTM peripheral, customers should create their own drivers. The AN3902 application note guides developers through the process of creating and testing I/O drivers under MQX. http://cache.freescale.com/files/32bit/doc/app_note/AN3902.pdf A simple PWM code can be as simple as shown below: /*Using FTM2_CH0 FTM2_CH1 output PWM with 90% high, 10% low wave*/ void FTM_EPWM(void) { SIM_SCGC6 |= SIM_SCGC6_FTM2_MASK;          SIM_SCGC3 |= SIM_SCGC3_FTM2_MASK;             PORTA_PCR10 = (0|PORT_PCR_MUX(3)); /* FTM2_CH0 enable on PTA10 */        PORTB_PCR18 = (0|PORT_PCR_MUX(3)); /* FTM2_CH0 enable on PTB18 */        PORTA_PCR11 = (0|PORT_PCR_MUX(3)); /* FTM2_CH1 enable on PTA11 */        PORTB_PCR19 = (0|PORT_PCR_MUX(3)); /* FTM2_CH1 enable on PTB19 */        FTM2_MOD = 0x0063;  /* 0x0063 / 60MHz = 1.6666uS PWM period */        /* Configure timers for edge aligned PWM High True Pulses */        printf("FTM2_ Edge_Aligned Test 1\r\n");        printf("Please check the waveform, 90% High True EPWM\r\n");        FTM2_C0SC = 0x28; /* No Interrupts; High True pulses on Edge Aligned PWM */        FTM2_C1SC = 0x28;         FTM2_C0V = 0x005A;  /* 90% pulse width */        FTM2_C1V = 0x005A;         FTM2_SC = 0x08;     /* Edge Aligned PWM running from BUSCLK / 1 */ } The function shown above can be called from any MQX task. Only care will be in case interrupts are needed for FTM application. There are two ways to add user interrupts into an MQX system - kernel_isr or MQX managed isr. Kernel_isr is fast but it bypasses MQX, thus, no MQX API function can be called from such a kernel_isr. MQX managed isr is slower, as it runs dispatcher in case a higher priority task becomes ready during isr. USING PROCESSOR EXPERT IN ORDER TO CREATE A DRIVER: All MQX BSP's are PE capable and Processor Expert is integrated with CodeWarrior and KDS but it is also a standalone tool that can generate code for IAR, Keil, GCC, etc. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PE_DRIVER_SUITE&tid=PEH There is an easy way to add device drivers to the MQX RTOS BSP using PE. It is necessary to activate the PE views, for do that go to Processor Expert -> Show Views Show PE views After select the PE views there is possible to look at the properties of the each component. For example, the below figure shows the properties of the MQX1 component.  Component MQX1 The below figure shows the Cpu component, here it is possible to modify the clock configurations, it is possible to find more information about this in the MQX_CW10_Getting_Started document located, after install MQX, at the path: <Freescale_MQX_4_2>\doc\tools\cw. Component CPU In order to configure a PWM signal using PE, it is necessary to follow these steps:      1. Select the PWM component. Component PWM      2. By default, the PWM component configures Channel 0 in Flex Timer 0 a PWM of 4096 timer-ticks, however it is possible to modify this values according the needs. Component PWM properties.       3. Besides Properties, Components also include Methods and Events that it is possible to enable or disable. Methods and events. Methods are user-callable functions/subroutines intended for the component functions control. Init: Initializes the device. Allocates memory for the device data structure, allocates interrupt vectors and sets interrupt priority, sets pin routing, sets timing, etc. If the property "Enable in init. code" is set to "yes" value then the device is also enabled (see the description of the Enable method). In this case the Enable method is not necessary and needn't to be generated. This method can be called only once. SetPeriodTicks: The method sets timer re-initialization period (in timer ticks). This method is available only if the property "Counter restart" is switched to 'on-match' value. ResetCounter: Resets counter. If counter is counting up then it is set to zero. If counter is counting down then counter is updated to the reload value. The method is not available if HW doesn't allow resetting of the counter. GetCounterValue: Returns the content of counter register. This method can be used both if counter is enabled and if counter is disabled. The method is not available if HW doesn't allow reading of the counter. SetOffsetTicks: Sets the new offset value to channel specified by the parameter ChannelIdx. It is user responsibility to use value below selected period. This method is available when at least one channel is configured. GetCaptureValue: Returns the content of capture register specified by the parameter ChannelIdx. This method is available when at least one channel is configured. Events are call-back functions called when an important event occurs. OnCounterRestart: Called if counter overflow/underflow or counter is reinitialized by modulo or compare register matching. OnCounterRestart event and Timer unit must be enabled. This event is available only if an Interrupt is enabled. OnChannel(x): Called if compare register match the counter registers or capture register has a new content. OnChannel(x) event and Timer unit must be enabled. This event is available only if an Interrupt is enabled.      4. If there is some change click on Generate Code and Build the project:      5. The PWM driver was created. In order to use the driver it is necessary to create a new MQX project.      6. For this example, we will edit the main task that is defined after create a new MQX project. To use PE driver some ‘handler’ variables must be declared:        7. It is necessary to initialize the component.    8. To enable de component, the PWM_Enable() function is required .       9. Finally implement the events.      10. At this point you should be able to build and run the example. Remember to check the jumper settings for the board you are using in order to debug a MQX example. The Getting Started with Freescale MQX™ RTOS document provides board-specific information related to the MQX RTOS, this document is located at the path: <Freescale_MQX_4_2>\doc It is important to connect the tower board to the elevators and check the PWM signal on A67.   Below you can check the entire code: #include "main.h" #if !BSPCFG_ENABLE_IO_SUBSYSTEM #error This application requires BSPCFG_ENABLE_IO_SUBSYSTEM defined non-zero in user_config.h. Please recompile BSP with this option. #endif #ifndef BSP_DEFAULT_IO_CHANNEL_DEFINED #error This application requires BSP_DEFAULT_IO_CHANNEL to be not NULL. Please set corresponding BSPCFG_ENABLE_TTYx to non-zero in user_config.h and recompile BSP with this option. #endif 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,                 } }; /*TASK*----------------------------------------------------- * * Task Name    : Main_task * Comments     : * This task prints " Hello World " * *END*-----------------------------------------------------*/ #define TERMINAL_CURSOR_POSITION_MAX    (80) static int                  pwm_task_count; static LDD_TDeviceData     *PWM_DeviceData; static LDD_TError           PWM_Error; volatile PWM_TValueType     PWM_Value; volatile PWM_TValueType     PWM_MaxValue; volatile PWM_TValueType     PWM_Step; volatile int                PWM_Freguency; void Main_task(uint32_t initial_data) {        static int terminal_cursor_position = 1;        printf("\n Hello World \n");        /* Initialize PWM device on FTM0 device */             puts("\nInitializing PWM device.....");            PWM_DeviceData = PWM_Init(NULL);            if (PWM_DeviceData == NULL)  {            puts("failed");                _task_block();            }            else  {                puts("done");            }            PWM_Value       = 0;            PWM_Step        = PWM_PERIOD_TICKS / 32;            PWM_MaxValue    = PWM_PERIOD_TICKS;            PWM_Freguency   = (PWM_CNT_INP_FREQ_U_0/PWM_PERIOD_TICKS);          printf("\n - PWM frequency              = %d Hz", PWM_Freguency);            puts("\nThe PWM signal is generated on FTM0 Channel 0");            puts("\n");            /* Enable PWM device */            PWM_Error = PWM_Enable(PWM_DeviceData);            while(1)            {                pwm_task_count++;                /* Suspend task for 250ms */                _time_delay(250);                /* Print dot on console to see that application is running */                if (terminal_cursor_position++ > TERMINAL_CURSOR_POSITION_MAX) {                    terminal_cursor_position = 1;                    puts("\n");                }                else {                    puts(".");                }            }        } void PWM_OnCounterRestart(LDD_TUserData *UserDataPtr) { /* Increment PWM duty-cycle from 0-100% */ PWM_Value += PWM_Step; if (PWM_Value > PWM_MaxValue) PWM_Value = 0; /* Set new PWM channel value */ PWM_Error = PWM_SetOffsetTicks(PWM_DeviceData, 0, PWM_Value); } /* EOF */
記事全体を表示
Hello All,   I want to share a client-server project. In this example the server can accept more than one client (Daemon server implementation). This example was created and tested using MQX4.2, CodeWarrior 10.6 and FRDM-K64F boards.     In general, the client-server model is the most common communication model used by the applications such as HTTP, Telnet, FTP, SSH, and others. In a client-server model, the server listens to client requests and waits for new connections. When a client needs to connect to a server, it sends a request. The server acknowledges the request, and if the client is supported by the server, the connection is established.   A TCP client-server communication can be implemented as in the following figure.         SETTING THE RTCS Below are presented the steps required to set the RTCS with the default settings: Create the RTCS. This step reserves memory for different RTCS parameters and initializes the TCP/IP task. Each project (server and client) contains an RTCS.c file which contains the initialize networking function with the RTCS configuration.     Set the RTCS IP address to the device after initialization. The main.h files have the macros and variables that store the IP parameters. You can change the IP address according your needs. In RTCS.c files,  the following code sets the address, mask, gateway and server IP addresses. ip_addr = IPADDR(A,B,C,D); phy_addr = BSP_DEFAULT_ENET_DEVICE; . . . ip_data.ip = ip_addr; ip_data.mask = ENET_IPMASK; ip_data.gateway = 0;     Calculate the MAC address for the device using the variables. Use the ENET_get_mac_address() function to build a valid MAC address for the application. MAC address calculation takes the device number and IP address as parameters, and returns a valid MAC address in the IPCFG_default_enet_address variable.   Initialize the Ethernet device available in the board with the calculated MAC address. Use the ipcfg_init_device() function to tell the RTCS task what Ethernet device should be used and to set the calculated MAC address to that device. Once the MAC address is set and the device is initialized, it is possible to bind the device to the IP address. error = ipcfg_init_device (phy_addr, serverAddress);     After Ethernet device initialization, bind the device to the IP address and it is ready to communicate. /* If DHCP Enabled, get IP address from DHCP server */              if (dhcp) {                     printf("\nDHCP bind ... ");                     error = ipcfg_bind_dhcp_wait(phy_addr, 1, &ip_data);                     if (error != IPCFG_ERROR_OK) {                            printf("Error %08x!\n", error);                     }                     else {                            printf("Successful!\n");                     }              } else {        /* Else bind with static IP */                     printf ("\nStatic IP bind ... ");                     error = ipcfg_bind_staticip(phy_addr, &ip_data);                       if (error != IPCFG_ERROR_OK) {                            printf("Error %08x!\n",error);                     }                     else {                            printf("Successful!\n");                     }              }     SERVER IMPLEMENTATION              For the server implementation, MQX uses a socket structure that is created and filled in this way: laddr.sin_family      = AF_INET; laddr.sin_port        = CONNECT_PORT; laddr.sin_addr.s_addr = INADDR_ANY;   The socket() function creates an unbound socket in a communications domain. This function also returns a handler used in later function calls that operate on sockets. /* Listen on TCP port */ listensock = socket(PF_INET, SOCK_STREAM, 0); if (listensock == RTCS_SOCKET_ERROR) { error = RTCSERR_OUT_OF_SOCKETS; }   The bind() function assigns a local socket address to a socket and the listen() function marks a socket as accepting connections. error = bind(listensock, &laddr, sizeof(laddr)); if (!error) {        error = listen(listensock, 0); }   The accept() function extracts the first connection on the queue of pending connections, creates a new socket with the same socket type protocol and address family as the specified socket, and allocates a new file descriptor for that socket. child_sock = accept(listensock, NULL, NULL);   The recv() function receives a message from a socket. error = recv(sock, (void *)cRecvBuff, sizeof(cRecvBuff), MSG_WAITALL);                     The send() function initiates transmission of a message from the specified socket to its peer. The send() function sends a message only when the socket is connected. error= send(sock, (void *)cRecvBuff, sizeof(cRecvBuff), 0);     The messages received are checked in order to toggle a LED or shutdown the connection. while(1)        {              error = recv(sock, (void *)cRecvBuff, sizeof(cRecvBuff), MSG_WAITALL);              printf("Received: %s\n", cRecvBuff);              if (error == RTCS_ERROR)              {                     printf("There was an error code %lx\n", RTCS_geterror(sock));                     shutdown(sock, FLAG_CLOSE_TX);                     return;              }              if(cRecvBuff[0]=='T')              {                     printf("Received: %s\n", cRecvBuff);                     printf("LED was toggled from child\r\n");                     lwgpio_toggle_value(&led1);              }              if(cRecvBuff[0]=='G')              {                                              printf("Received: %s\n", cRecvBuff);                     printf("Shutting down connection\n");                     shutdown(sock,FLAG_CLOSE_TX);                     _time_delay(2000);                      _task_abort(MQX_NULL_TASK_ID);              }            }            CLIENT IMPLEMENTATION   For the client implementation, it uses a socket structure that is created and filled in this way: addr.sin_family      = AF_INET; addr.sin_port        = DESTPORT; addr.sin_addr.s_addr = IPADDR(192,168,1,200); //Server address   The socket() function creates an unbound socket. sock = socket(PF_INET, SOCK_STREAM, 0);     The connect() function attempts to make a connection on a socket. error = connect(sock, &addr, sizeof(addr));        The recv() function receives a message from a socket. error= recv(sock, (void *)cReadBuff, sizeof(cReadBuff), 0);          The send() function sends a message only when the socket is connected (including when the peer of a connectionless socket has been set via connect() function). error = send(sock, (void *)cReadBuff, sizeof(cReadBuff), 0);          In addition the client example can toggle a LED in the server board or destroy the socket. /*****Infinite loop waiting for user to push a button***/ while(1){        if(lwgpio_get_value(&btn1) == LWGPIO_VALUE_LOW)        {              _time_delay(150);              sprintf((char *)cReadBuff, "Toggle from client2\n");              printf("Sending: %s", cReadBuff);              error = send(sock, (void *)cReadBuff, sizeof(cReadBuff), 0);              if (error == RTCS_ERROR)              {                     printf("There was an error trying to send to the server\n");                     return;              }        }        if(lwgpio_get_value(&btn2) == LWGPIO_VALUE_LOW)        {              _time_delay(150);              sprintf((char *)cReadBuff, "GoodBye\n");              printf("Sending: %s", cReadBuff);              error = send(sock, (void *)cReadBuff, sizeof(cReadBuff), 0);              if (error == RTCS_ERROR)              {                     printf("There was an error trying to send to the server\n");                     return;              }              printf("Shutting down connection\n");              shutdown(sock,FLAG_CLOSE_TX);              _task_abort(MQX_NULL_TASK_ID);        }       I hope this helps, Soledad Original Attachment has been moved to: ClientD_FRDM-K64_MQX4_2_CW10_6.zip Original Attachment has been moved to: ServerDeamon_FRDM-K64_MQX4_2_CW10_6.zip
記事全体を表示
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
記事全体を表示
Rev0.1 - 8/28/2012 Adding to the patch at TWR-K21D50M lowpower MQX Patch for v4.0.2, this updates the MQX BSP and lowpower example to add VLPS mode. The example works the same as the default lowpower example, except after waking from LLS, the application immediately enters VLPS.  It uses the LPTMR to wake after 10 seconds, and returns to RUN mode and restarts the example.  Because the transition is immediate from the user perspective, the user will press the switch to enter LLS mode, after 10s the MCU will wake, turn on the blue LED, enter VLPS, wait another 10s, wake, turn off the blue LED, return to RUN mode and resume printing to the terminal.  There is no text printed to the terminal between LLS and VLPS to show a quick transition. This patch covers several files to enable VLPS mode in the twrk21d50m BSP, and modifies the lowpower example. The lowpower example is provided to demonstrate the MQX Low-Power Manager (LPM) driver, and change low-power modes on the K21 board.  The BSP in the release provided does not include support for VLPS. To use this patch, copy the patch directory into the MQX v4.0.2 root directory.  The patch will over-write some existing files in the MQX installation.  The changes addressed by this patch include the following: User_config.h MQX_ENABLE_LOW_POWER macro enabled.  Required for LPM driver and lowpower example. LowPower Example main.c Modified as described above to add transition into VLPS mode bsp_cm.c Added case for VLPS mode for clock mode transition init_lpm.c Added mode to LPM_CPU_OPERATION_MODES[] for LPM_OPERATION_MODE_VLPS init_lpm.h Added mode LPM_OPERATION_MODE_VLPS to enumeration LPM_OPERATION_MODE init_sci.c Added settings for mode LPM_OPERATION_MODE_VLPS to the _bsp_sciX_operation_modes arrays for all the UARTs in the BSP lpm_smc.c Added mode DOM_VLPS to LPM_PE_OPERATION_MODE_MAP[] Disabled SPI0 clock gate when entering stop mode, otherwise stop entry is aborted.  Re-enabled clock gate after waking up.  If SPI0 peripheral is required in a stop mode, register the SPI driver with the LPM driver to properly configure when LPM changes operation mode to a stop mode.  Refer to LPM documentation for details. Disabled the SysTick interrupt for the 5ms RTOS tick before entering stop mode, and re-enabled after waking up.  Without this, the example was entering VLPS mode fine without the debugger, but with the debugger the SysTick interrupt was causing VLPS entry to abort. 
記事全体を表示
Hi, Many people has been asking about migrating from MQX RTOS to MQX RTOS for KSDK. Such guide is now available in the following link: http://www.freescale.com/files/soft_dev_tools/doc/support_info/MQXKSDKPUG.pdf?fsrch=1​ If you need to create a new MQX RTOS for KSDK project please note that there is not a New MQX for KSDK Project Wizard, therefore it is necessary to create it manually. You can find a guide in the link below. How To: Create a New MQX RTOS for KSDK Project in KDS Best regards, Carlos Musich Technical Support Engineer
記事全体を表示
NXP provides a software driver library for their Kinetis ARM Cortex-M0 and M4 devices, the ‘Kinetis SDK’, available from http://www.nxp.com/ksdk.   The below link provides information about how download a KSDK package, how to install KSKD v2.0 project wizard in Kinetis Design Studio (KDS), and how to create a KSDK v2.0 project. Using Kinetis Design Studio v3.x with Kinetis SDK v2.0 NOTE: Before you continue with this document, it is important to download and install KSDK v2.0. The purpose of this document is to provide information that enables developers to start their first application using FreeRTOS and KSDK v2.0. Creating a new FreeRTOS with KSDK V2.0 application. The following steps show how to create a new FreeRTOS project in KDS using KSDK v2.0. 1. Open Kinetis Design Studio. 2. Go to 'File' menu and click on File->New->Kinetis SDK 2.x Project 3. Select a project name and the Kinetis SDK folder then click 'Next' 4. Select the processor or board to be used, in addition it is important to include all SDK drivers and add FreeRTOS to the project and click 'Finish' 5. In the project created you can see the following folder structure: 6. The main.c file is a template for main module created by new Kinetis SDK 2.0 Project Wizard, this contains a task responsible of printing "Hello world." message. 7. If you want to build and debug this example uncomment the next lines: #include "fsl_debug_console.h" and PRINTF("Hello world.\r\n"); 8. Build and debug. Developing the first FreeRTOS with KSDK V2.0 application. This section describes the creation of a simple application that blinks LEDs on the TWR-K64F120M board. After a new project is created, in the main function the following routines are called in order to initialize the board hardware: BOARD_InitPins(); BOARD_BootClockRUN(); BOARD_InitDebugConsole(); By default only the UART0 is initialized in order to use it as debug console. Also in main it is created a task (hello_task) using xTaskCreate () function. xTaskCreate () creates a new task and adds it to the list of tasks that are ready to run; it contains the following parameters: pvTaskCode. Pointer to the task entry function. Tasks must be implemented to never return. pcName. A descriptive name for the task. This is mainly used to ease debugging. Max length defined by configMAX_TASK_NAME_LEN. usStackDepth. The size of the task stack specified as the number of variables the stack can hold - not the number of bytes. For example, if the stack is 16 bits wide and usStackDepth is defined as 100, 200 bytes will be allocated for stack storage. The stack depth multiplied by the stack width must not exceed the maximum value that can be contained in a variable of type size_t. pvParameters. Pointer that will be used as the parameter for the task being created. uxPriority. The priority at which the task should run. pvCreatedTask. Used to pass back a handle by which the created task can be referenced. Writing the application. The TWR-K64F120M contains 4 LED's connected to GPIO signals (optionally isolated using jumpers): — Green LED (D5) to PTE6 — Yellow LED (D6) to PTE7 — Orange LED (D7) to PTE8 — Blue LED (D9) to PTE9 For this example it is used the TWR-K64F120M board, however if you are using the FRDM-K64F the RGB LED is connected through GPIO signals: — RED to PTB22 — BLUE to PTB21 — GREEN to PTE26 To initialize the GPIO, enable the port clock, define a pin configuration, either input or output, in the pin_mux.c file, as is described in the below steps: Open the pin_mux.c file.    2. Enable the port clock.      CLOCK_EnableClock(kCLOCK_PortE);    3. Configure these pins as GPIO signals.       PORT_SetPinMux(PORTE, 6u, kPORT_MuxAsGpio);     PORT_SetPinMux(PORTE, 7u, kPORT_MuxAsGpio);     PORT_SetPinMux(PORTE, 8u, kPORT_MuxAsGpio);     PORT_SetPinMux(PORTE, 9u, kPORT_MuxAsGpio); Then, in main function create 5 tasks, one to initialize the GPIO driver and the other to blink the LEDs. You can find the complete code at the end of this document.   /* Create RTOS task */ xTaskCreate(init_task, "Init_task", configMINIMAL_STACK_SIZE, NULL, task_PRIORITY, NULL); xTaskCreate(task_blue, "Task_blue", configMINIMAL_STACK_SIZE, NULL, task_PRIORITY, NULL); xTaskCreate(task_orange, "Task_orange", configMINIMAL_STACK_SIZE, NULL, task_PRIORITY, NULL); xTaskCreate(task_yellow, "Task_yellow", configMINIMAL_STACK_SIZE, NULL, task_PRIORITY, NULL); xTaskCreate(task_green, "Task_green", configMINIMAL_STACK_SIZE, NULL, task_PRIORITY, NULL); Write the code of each task. 1. init_task function. In this function are initialized the GPIO pins as output using the gpio_pin_config_t structure then it is called the GPIO_PinInit() function for each GPIO pins.      The GPIO_PinInit() parameters are: base. GPIO peripheral base pointer (GPIOA, GPIOB, GPIOC, and so on.) pin. GPIO port pin number. config. GPIO pin configuration pointer.      Finally call vTaskSuspend(), this function suspend the task. When a task is suspended, it will never get back to execution unless it is explicitly set in Ready state by another task.      The code for init_task function is:      gpio_pin_config_t ledB_config = {                       kGPIO_DigitalOutput, 0,                   };          gpio_pin_config_t ledO_config = {                          kGPIO_DigitalOutput, 0,                   };          gpio_pin_config_t ledG_config = {                      kGPIO_DigitalOutput, 0,                   };          gpio_pin_config_t ledY_config = {                       kGPIO_DigitalOutput, 0,                   };       /* Init output LED GPIO. */     GPIO_PinInit(BOARD_LED_BLUE_GPIO, BOARD_LED_BLUE_GPIO_PIN, &ledB_config);     GPIO_PinInit(BOARD_LED_ORANGE_GPIO, BOARD_LED_ORANGE_GPIO_PIN, &ledO_config);     GPIO_PinInit(BOARD_LED_GREEN_GPIO, BOARD_LED_GREEN_GPIO_PIN, &ledG_config);     GPIO_PinInit(BOARD_LED_YELLOW_GPIO, BOARD_LED_YELLOW_GPIO_PIN, &ledY_config);     vTaskSuspend(NULL); 2. task_blue, task_orange, task_yellow, task green functions. It is necessary to write the code of each task. Each task uses LED_XXX_TOGGLE() and vTaskDelay (), to toggle a LED, this should be in a infinite loop.      Below is the code for the task_blue function:      while (1)        {                         /* Toggle LED BLUE */               LED_BLUE_TOGGLE();               vTaskDelay( 500 );        } Finally build and debug the project.  Enjoy! Complete Code main.c #include <string.h> #include "board.h" #include "pin_mux.h" #include "clock_config.h" #include "fsl_debug_console.h" /* FreeRTOS kernel includes. */ #include "FreeRTOS.h" #include "task.h" #include "queue.h" #include "timers.h" /* Task priorities. */ #define task_PRIORITY (configMAX_PRIORITIES - 1) static void init_task(void *pvParameters) {        /* Init output LED GPIO. */          gpio_pin_config_t ledB_config = {                       kGPIO_DigitalOutput, 0,                   };          gpio_pin_config_t ledO_config = {                          kGPIO_DigitalOutput, 0,                   };          gpio_pin_config_t ledG_config = {                      kGPIO_DigitalOutput, 0,                   };          gpio_pin_config_t ledY_config = {                       kGPIO_DigitalOutput, 0,                   };        /* Init output LED GPIO. */                   GPIO_PinInit(BOARD_LED_BLUE_GPIO, BOARD_LED_BLUE_GPIO_PIN, &ledB_config);                   GPIO_PinInit(BOARD_LED_ORANGE_GPIO, BOARD_LED_ORANGE_GPIO_PIN, &ledO_config);                   GPIO_PinInit(BOARD_LED_GREEN_GPIO, BOARD_LED_GREEN_GPIO_PIN, &ledG_config);                   GPIO_PinInit(BOARD_LED_YELLOW_GPIO, BOARD_LED_YELLOW_GPIO_PIN, &ledY_config);                   vTaskSuspend(NULL); } static void task_blue(void *pvParameters) {         while (1)        {        /* Toggle LED BLUE */               LED_BLUE_TOGGLE();               vTaskDelay( 500 );        } } static void task_orange(void *pvParameters) {         while (1)        {        /* Toggle LED ORANGE */               LED_ORANGE_TOGGLE();               vTaskDelay( 500 );        } } static void task_yellow(void *pvParameters) {         while (1)        {        /* Toggle LED YELLOW */               LED_YELLOW_TOGGLE();               vTaskDelay( 500 );        } } static void task_green(void *pvParameters) {         while (1)        {        /* Toggle LED GREEN */               LED_GREEN_TOGGLE();               vTaskDelay( 500 );        } } int main(void) { /* Init board hardware. */ BOARD_InitPins();   // This function initializes the pins used in this example BOARD_BootClockRUN(); BOARD_InitDebugConsole();   /* Create RTOS task */ xTaskCreate(init_task, "Init_task", configMINIMAL_STACK_SIZE, NULL, task_PRIORITY, NULL); xTaskCreate(task_blue, "Task_blue", configMINIMAL_STACK_SIZE, NULL, task_PRIORITY, NULL); xTaskCreate(task_orange, "Task_orange", configMINIMAL_STACK_SIZE, NULL, task_PRIORITY, NULL); xTaskCreate(task_yellow, "Task_yellow", configMINIMAL_STACK_SIZE, NULL, task_PRIORITY, NULL); xTaskCreate(task_green, "Task_green", 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 */ } } Complete Code  pin_mux.c #include "fsl_device_registers.h" #include "fsl_port.h" #include "pin_mux.h" /******************************************************************************* * Code ******************************************************************************/ /*! * @brief Initialize all pins used in this example * * @param disablePortClockAfterInit disable port clock after pin * initialization or not. */ void BOARD_InitPins(void) { /* Ungate the port clock */ CLOCK_EnableClock(kCLOCK_PortC); CLOCK_EnableClock(kCLOCK_PortE); /* Affects PORTC_PCR3 register */ PORT_SetPinMux(PORTC, 3u, kPORT_MuxAlt3); /* Affects PORTC_PCR4 register */ PORT_SetPinMux(PORTC, 4u, kPORT_MuxAlt3); PORT_SetPinMux(PORTE, 6u, kPORT_MuxAsGpio); PORT_SetPinMux(PORTE, 7u, kPORT_MuxAsGpio); PORT_SetPinMux(PORTE, 8u, kPORT_MuxAsGpio); PORT_SetPinMux(PORTE, 9u, kPORT_MuxAsGpio); }
記事全体を表示
TWR-K70F120M running MQX and RTCS can work with the Dual Phy on TWR-SER2. Below I list the modifications I did to the default BSP: 1) I add phy_dp83xxx.c and phy_dp83xxx.h to the bsp_twrk70f120m build project. These files are with MQX in /mqx/source/io/enet/Phy 2) I modify the BSP to use DP83xxx PHY for the Ethernet MACNET: in the /mqx/source/bsp/twrk70f120m/init_enet.c: #include "phy_dp83xxx.h" const ENET_IF_STRUCT ENET_0 = {      &MACNET_IF,      //&phy_ksz8041_IF,      &phy_dp83xxx_IF,      MACNET_DEVICE_0,      MACNET_DEVICE_0,      BSP_ENET0_PHY_ADDR,      BSP_ENET0_PHY_MII_SPEED }; 3) MDIO line requires an external pull up resistor, per DP83849I Data sheet. As I didn't have one at the moment, I enable internal pull up on MCU pin PTB0. in the /mqx/source/bsp/twrk70f120m/init_gpio.c: //pctl->PCR[0] = PORT_PCR_MUX(4) | PORT_PCR_ODE_MASK; /* PTB0, RMII0_MDIO/MII0_MDIO   */ /* PTB0, RMII0_MDIO/MII0_MDIO   */ /* internal pull up enabled on MDIO */ pctl->PCR[0] = PORT_PCR_MUX(4) | PORT_PCR_ODE_MASK | PORT_PCR_PE_MASK | PORT_PCR_PS_MASK; With these changes, the RTCS applications work over TWR-SER2 Dual PHY channel A. On TWR-SER2, J8 and J9 are un-shunted, SW1 = 11000000, SW2 = 10100000 on TWR-K70F120M, J18 is configured to disable 50 MHz OSC, as I use 50 MHz clock source from TWR-SER2 U504 50 MHz output. This clock is used to provide reference clock for the MCU (EXTAL), as well as for the Dual PHY X1 input (RMII reference clock).
記事全体を表示