MQX软件解决方案知识库

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

MQX Software Solutions Knowledge Base

讨论

排序依据:
May 7, 2014   MQX plugins were rebuilt to support latest DS5.18.   Zip attached to this email contains following plugins:   - com.freescale.projectofprojects   - com.freescale.buildtoolbar   - com.freescale.mqx.configuration.editor   The plugins installation procedure is described in the MQX DS5 getting started manual (chapter 2). Plugins are backward compatible and should work also in older DS5 versions.   https://community.freescale.com/thread/323233   Regards, David Seymour
查看全文
Tutorial 5 of 6 for the iDigi Connector for MQX: Enabling iDigi Remote Firmware Update (5 of 6) - iDigi Device Cloud More information and free download at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KINETIS_IDIGI_M2M
查看全文
Tutorial 4 of 6 for the iDigi Connector for MQX: Building and Running the Kinetis K60 Tower Demo Sample (4 of 6) - iDigi Device Cloud More information and free download at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KINETIS_IDIGI_M2M
查看全文
Video Tutorial 2 of 6 for the iDigi Connector for MQX: iDigi Connector for MQX Extensions Overview (2 of 6) - iDigi Device Cloud More information and free download at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KINETIS_IDIGI_M2M
查看全文
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(); }
查看全文
  I2C is a common way to interface a processor with a peripheral such as EEPROM, accelerometer, or communication device, and can even be used to communicating with another processor. Quick Review of I2C I2c: inter-integrated circuit, meaning that is a communication channel between integrated circuit devices, typically from a microprocessor to a peripheral device, such as a memory chip, some type of sensor, a data converter or maybe a display.   By design, i2c isn’t intended for high throughput connections, so you won’t see it used for something like chip ram, rather it is typically used when relatively small amount of data is being sent or received. There are only two conductors through the i2c bus, the first is a serial clock line which is usually written as SCL,   as the name implies, SCL is a clock signal sent on this line. The second is a serial of data line, or SDA, and the data sender on this line will be synchronized with a clock signal making it easier for the receiver to decoding incoming data, and i2c connections is one to one link, with one device being as a master and the other being a slave.  But multiple devices can be connected to the same bus with different one to one pairs communicating on the channel. Only one pair can be communicating at a time of course, and having more than one device capable of being a master will acquire additional synchronization to avoid conflicts. With i2c, the communication is poll response, meaning the master will poll slave with either data that wants to send to slave or send a command request the slave sends specific information back, only the master can initiate communication and part of the job is to provide the clock signal, which should does not only when is transmitting,    but also when the slave is transmitting back. Sending Data with I2C The clock and data lines have pull up resistors, so when the bus is idle and both of the wires will be in high state. To begin a transmission,  a master  pulls a data line low which is refer to as a start condition , the master then drives the clock signal while  sent 7 address bits on the data line.  The address bits are followed immediately by either a 0 to indicate the master wants to send the data or a 1 meaning the master would like to read the data back from the slave, the seven address bits must closely bound to a slave device that is on the bus of course, and the device with margin address will set as an acknowledge or an ACK bit on the data line to   indicate that has receive the request which is done by holding the data line low. At this stage, one of two things going to happen. If the master wants to send data or   a command to address the slave , he will continue on with first byte to transmit ,  data bits will sent out   and again the address slave or add the   ACK bit at the end , this continues until the master is done sending it’s commanding data. And there is no fixed limit to size of the message. If the master is just sending data and is not expecting receive response back from the slave, it will indicate that is done by signaling a STOP condition, after the last data byte is sent. However, instead of sending data,  the master maybe expecting the salve to immediately to reply back and signals this request, with a read bit have the address, In this case,  slave acknowledge address and then sent out a byte of data synchronize to  the master’s clock , once the byte is complete, the master will indicate acknowledgement of  the data, and this continues until the master receives the amount of data  it was expecting. It signals to the device the expected amount of data has been received by not acknowledging a last byte. And instead leaves the data line high, which is called the NAK for not acknowledge. Finally the master terminates the communication by signaling a stop condition and stops generation of the clock signal. And the last thing to cover is the case when the master like to send either data or a command and immediately receive data back from the slave. So a combination of previous two scenarios,   the first part of the transaction is identical to just sending data with master sending out the number of bytes has to transmit, and the slave acknowledge each byte. However, the stop condition is not asserted at the end of transmission, and the master will send a start bit , which is called a repeatedly start bit. The seven address bits will send again followed by a read setting which the slave acknowledge. The slave then send the data with the master’s address on each byte until the last byte which isn’t acknowledged, and the session is terminated with a stop bit. Note: This document is the 11th Installment of the "Essentials of MQX RTOS Application Development" training course. Please watch the vedio for more details MQX RTOS Part 11: IC2 Driver|NXP
查看全文
This is a friendly guide to install MQX.
查看全文
If you are interested in a PPP connection between your PC and your board using Win 7 OS you may find the attached document useful. This project (ATTACHED) starts PPP service and waits for a Windows connection. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- If you are interested in getting started with MQX for KSDK please see the following document: How To: Create a New MQX RTOS for KSDK Project in KDS If you are interested in using RTCS with Processor Expert please see the following document: How to add RTCS to a Processor Expert Project Using KDS and KSDK Regards, Carlos
查看全文
The new Freescale MQX™ 4.0.2  release is now available on the www.freescale.com/MQX ·         Files available                    # Name Description 1 FSL_MQX_RELEASE_NOTES_4_0_2 Freescale   MQX™ RTOS 4.0.2 Release Notes 2 FSL_MQX__FFS_RELEASE_NOTES_4_0_2 Freescale   MQX™ FFS package 4.0.2 Release Notes 3 FSL_MQX_ATHEROS_RELEASE_NOTES_4_0_2   Freescale   MQX™ Atheros Wifi package 4.0.2 Release Notes 4 Freescale   MQX RTOS 4.0.2 Atheros Wifi package Atheros   Wifi solution for MQX™ 4.0.2 5 Freescale   MQX RTOS 4.0.2 FFS package NAND   Flash File System solution for MQX™ 4.0.2 6 Freescale   MQX RTOS 4.0.2 MQX™   Source code. Includes an RTOS, File   System, TCP/IP and USB host/device software stacks. Does not require MQX™ 4.0   installation. ·         What is New? o   AutoEVB Vybrid A5 and M4 Board support packages §  Support for CortexA5 and CortexM cores of dual core Vybrid processor §  Supporting standard set of IO drivers o   Vybrid BSP extensions §  RTC and NAND flash driver ported to Vybrid platform §  MMU support extended by handling of 4KB memory block §  Introduced new QuadSPI driver §  CortexM4 boot option enabled. §  Direct code execution from QuadSPI flash – XIP provided. Feature demonstrated in Vybrid QuadSPI bootloader. Introduced the first version of eDMA driver – the driver is experimental and will be further extended in the next MQX version. Documentation is not provided. o   Kinetis SPI driver was updated to use the eDMA driver. o   Hardware timer driver support extended to Systick and GPT HW modules. Kinetis and Vybrid BSPs updated to leverage the Hardware timer to provide MQX tick time. o   RTCS Hardware checksum acceleration enabled in ENET driver (for TCP and UDP); the benefits are the increased throughput and a reduced processor loading. This option is enabled by default for the K60N512 platform. o   HTTP server redesigned to provide a faster and more robust solution. The server API is simplified and changed to correspond to the RTCS standard. o   New SMTP client functionality provided as a part of the RTCS network suite. The client offers a simple API for e-mail handling. The new RTCS Shell command “email” demonstrates its functionality. o   The security_email, security_webserver, and security_telnet demo applications are removed from this release. Networking functionality is demonstrated in RTCS shell and httpsrv example applications. o   Multicore Communication (MCC) library updated to version 1.1. Fixed the incorrect usage of cache macros in the mcc_send() function. ·         Known issues o   For known issues and limitations please consult the release notes.
查看全文
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
查看全文
Accelerometer and magnetometer FXOS8700CQ example code for MQX4.1.1 This example code was written for FRDM-K64F board and it is based on Tom’s bare-metal code (Thank you). Content of attached zip file could be unpacked directly to examples directory (c:\Freescale\Freescale_MQX_4_1\mqx\examples\..). It contains generated projects for CW10GCC, IAR, KDS, make and KEIL toll chains. Note: unfortunately this example project cannot be used as source for New Project Wizard in CW10. Example code uses polled I2C MQX driver for communication with FXOS8700CQ chip and it contains two options for acquisition sensors data. We can use polled (0) or interrupt (1) mode according SENSOR_USE_INTERRUPT macro definition. In polled mode we periodically read sensor status until new data are available. In interrupt mode sensor drives interrupt pin when new data are available. Example code contains calibration functions for increasing accuracy. Magnetometer calibration function collects data during 30s interval where we should rotate with board around z-axis in 360° range (leave board on table and rotate from north to south and back to north). It acquires approximately 3 samples per second. For change this ODR rate, we have to modify CTRL_REG1 value. Note: Interrupt mode works correctly up to 200Hz ODR. Higher ODRs was not tested due to capacitance on interrupt pin (C56). Polled mode was tested up to 800Hz ODR (accelerometer only). Example code displays received data on debug console and drives RGB LEDs according measured g’s. If you are interested in more complex algorithms please refer to our Freescale Sensor Fusion Library for Kinetis MCUs. I hope it helps you. RadekS
查看全文
Hi All, The new Freescale MQX™ 4.0.2.2 patch release is now available on the www.freescale.com. ·         Files available # Name Description 1 Freescale   MQX RTOS 4.0.2.2 Patch This   patch release is based on the MQX™ RTOS 4.0.2 release and provides the   solutions to software issues identified in the released version. This patch   release applies to all the BSPs. ·         Patch Description This patch provides the software workarounds for the following issues identified in MQX 4.0.2 release: o   ENGR00278434 §  Vybrid ARM Cortex®-A5: The float context is not properly saved when a task is blocked. §  Affected BSPs: TWR-VF65GS10, AutoEVB Vybrid o   ENGR00273581 §  A memory allocation problem occurs when the system is out of memory. §  Affected all BSPs o   ENGR00276466 §  Events are sometimes triggered immediately after they are added. §  Affected all BSPs o   ENGR00279275 §  RTCS connect failures via Dell router §  Affected all BSPs ·         Known issues o   For known issues and limitations please consult the release notes document.
查看全文
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 new Freescale MQX™ 4.1.0.1 patch release is now available on the www.freescale.com. ·         Files available          # Name Description 1 FSL_MQX_4_1_0_1_RELEASE_NOTE MQX™ RTOS 4.1.0.1 Patch Release Notes 2 Freescale   MQX RTOS 4.1.0.1 Patch This patch release is based on the MQX™ RTOS 4.1.0 release   and provides the solutions to software issues identified in the released   version. ·         Patch Description o   This patch provides the software workarounds for these issues identified in MQX 4.1.0 release: §  IPv6 ping issues ·         Crashes during a ping from an unknown host (IPv6 only). ·         An unhandled interrupt is generated when using the IPv6 ping. §  TCP/UDP issues ·         IPv4 sends an MSS and window size with a SYN. A SYN without an MSS or with a window size zero is dropped by some firewalls. ·         IPv6 UDP close issue. IPv6 only reuses the same IP and port. ·         Fixed the incorrect RTCS_selectset() unblocking. §  APP protocol issues ·         TELNET and Eth_to_serial peformance improvement. ·         HTTPSRV accesses data incorrectly in a session buffer while searching for SSI. ·         FTPSRV session close is missing a shutdown of a data socket. §  BSP issues ·         The TWR-K70F120M BSP is unstable when the DDR2 SDRAM is in high use due to incorrect DDR settings.
查看全文
MQX ppp communication. Could be imported to wireshark as hexdump.
查看全文
Q: I installed the MQX software release, but when I run a project, CodeWarrior can't find file x...  A: Symptom A project will build correctly, but when you run it, CodeWarrior asks you to locate files that it can't find. Solution: This problem is caused if you are running from a directory that is not the default directory that the installer placed the files. You just need to re-build the libraries. To build all MQX libraries at once, the special mass-build project may be used. The project is located together with the user_config.h file in directory: <install_dir>/config/<board>/build_libs.mcp. See the Release Notes for more details on building the libraries. Q: What software tools do I need for the MQX 3.0.0 demos and lab tutorials? A: The first release of Freescale MQX (3.0.0) requires CodeWarrior for ColdFire v7.1 Professional Edition (30-day evaluation available) to unlock the full potential of the demos and labs. Is version 7.1 necessary?  Yes, 7.1 contains the necessary support for M5225EVB and M52259DEMOKIT. What about CodeWarrior Special Edition?  Due to the code size limitation (<128k) of Special Edition, several lab demos will not compile/program.  These include MQX labs 3 and 4.  Also, Task Aware Debugging is not available in Special edition, therefore lab 5 is not possible.  Additionally, the targets which utilize the MRAM on the M52259EVB will not work. What about CodeWarrior Basic and Standard Edition? Task Aware Debugging is not available in Basic or Standard edition,therefore lab 5 is not possible.  Also, with Basic Edition the targets whichutilize the MRAM on the M52259EVB may not work. Q: I'm having trouble establishing an Ethernet connection between my PC and the board.  What do I do? A: 1) Hit the Reset button on the board after you plug in the cable.  2) Wait a minute or two for your computer to connect. Connect the board directly to your computer with an ethernet crossover cable.  You must wait a minute or two for your computer to try to aquire a network address.  Since you're no longer connected to your network the computer will eventually revert to an Auto IP address on the same subnet as board (169.254.x.x). 3) Disable your wireless router if you have one. 4) Disable proxy server settings in your web browser. Notes: When connected your computer might report limited or no connectivity, but it should still work. Ping is disabled in release 3.0.0, so pinging the board from the computer will not work. If all else fails, configure your IP address manually as instructed by the quick start guide. Q: Can I modify the webpages used in the webserver lab? A: Yes, there is a tool called MKTFS which can be used to convert web pages and images into a C array's, which are used by the MQX webserver.  Edit the webpages in the folder \demo\web_hvac\web_pages.  Then click on \demo\web_hvac\mktfs.bat.  The script will update the file tfs_data.c in the \demo\web_hvac folder.  When you recompile the hvac_web project and program it the new webpages will be loaded into memory.          Q: Can I use my own USB Flash drive in the labs? A: Yes, just copy over the files from the flash drive that is provided with the M52259EVB or M52259DEMOKIT. Q: My USB Flash drive doesn’t work, what should I do? A: Not all USB flash drive conform to the same specification and there are small differences between them that could cause some not to work.  It will say "Unable to open USB disk" at the terminal if the flash drive is not compatible. We are working to expand compatibility to as many usb flash drive manufactures and models as possible.  If you encounter one that does not work please perform the following tasks. Open up the project in <mqx install directory>/usb/host/examples/mass/msc_commands/codewarrior/ Load and run the project with the USB stick unattached. Then with the Terminal open and connected, plug in the non-functioning USB stick. A test will run automatically upon insertion of the USB stick.  The test will output useful information to the terminal that will help us. Please provide us the output that this test generates, along with the exact make and model of the USB flash drive.  We will create a thread on the forums that you can post this to. More info: Tested USB Stick Q: What are tasks and how are they created? A: Tasks share the same code space if they execute the same root function. A task always starts executing at the entry point of the root function even if the function is its creator’s root function. This is not the same behavior as fork() in UNIX. Q:Do I always need at least one autostart task? A: Yes. In an application, at least one autostart application task is required in order to start the application. In a multiprocessor application (the application can create tasks remotely), each image need not have an autostart application task; however, each image must include IPC Task as an autostart task in the task template list. If no application task is created on a processor, Idle Task runs. Q:How much stack space should I give to various tasks in my application? A: This is a really hard question to answer as the amount of stack space is extremely application specific. Different tasks will need varying amounts of stack space depending on the job they are trying to perform. We usually recommend starting all (or most) of tasks with plenty of stack memory (double or triple what you think they would need) and then later optimizing the system with TAD (Task Aware Debugging module). Q: How do I dynamically alter the task stack size? A: In a situation where a task runs a while and then blocks. In it's blocked state, it holds a couple of event connections which are used by interrupts, but otherwise needs no stack space. One would like to reduce the stack space being used by the task in its blocked state. How do you do this? If the task is never going to run again, the user could _mem_free or better yet _mem_free_part on the stack. Using _mem_free_part will not cause some of our tools to complain. In the task whose stack to be freed, the very first thing it does is to save the value of kernel_data->ACTIVE_PTR->MEMORY_RESOURCE_LIST; /* Global var */ pointer stack_ptr; { /* In task */ KERNEL_DATA_STRUCT_PTR kernel_data = _mqx_get_kernel_data(); /* Do this very first thing */ stack_ptr = kernel_data->ACTIVE_PTR->MEMORY_RESOURCE_LIST; /* Rest of code for task */ } { /* some other task*/ _mem_free(stack_ptr); } Q:How does MQX™ measure a timeslice? Is the timeslice absolute or relative? That is, if a task has a 10-ms timeslice and starts at time=0 ms, does it give up the processor at time=10 ms, or does it give up the processor after 10 ms of execution? A: With a 10-ms timeslice, MQX counts the number of periodic timer interrupts that have occurred while the task is active. If the equivalent of 10 or more milliseconds have expired, MQX effectively runs _sched_yield() for the task. As a result, a task does not get 10 ms of linear time since higher-priority tasks will preempt it. Also, if the task calls a scheduling service (for example _task_block() or _sched_yield()), MQX sets the task’s timeslice counter back to zero. As with timeouts, the time that MQX allocates is plus or minus BSP_ALARM_RESOLUTION. Q: How do I increase TCP performance? A: Increase the size of the send and/or receive windows. Send data in multiples of the maximum segment size (MSS). Disable the Nagle algorithm. Q: Is there a limit to the number of sockets that can be created with RTCS? A: No. Sockets come from a partition with an infinite growth factor, so the number of sockets is limited only by the available memory on the board. Q: Do I always need at least one autostart task? A: Yes. In an application, at least one autostart application task is required in order to start the application. In a multiprocessor application (the application can create tasks remotely), each image need not have an autostart application task; however, each image must include IPC Task as an autostart task in the task template list. If no application task is created on a processor, Idle Task runs. Q: Is it possible to rename a task after it is created? A: Here's a function to get a pointer to the task's template struct where the task's name is stored. The function needs a couple of structures from mqx_prv.h.Namely, TD_STRUCT and KERNEL_DATA_STRUCT. You can add the function to your application or add it into MQX itself. If you are adding it to app, you will need to include "mqx_inc.h" and add mqx\source\include to the compiler's include search path. /*FUNCTION*-------------------------------------------------------------------* * Function Name : _task_get_template_ptr* Returned Value : TASK_TEMPLATE_STRUCT_PTR* Comments :* Returns a pointer to the task's template structure* *END*----------------------------------------------------------------------*/TASK_TEMPLATE_STRUCT_PTR _task_get_template_ptr(_task_id){ /* Body */  KERNEL_DATA_STRUCT_PTR kernel_data;  TD_STRUCT_PTR td_ptr;  _GET_KERNEL_DATA(kernel_data);  if (task_id == MQX_NULL_TASK_ID) {    td_ptr = kernel_data->ACTIVE_PTR;  } else {    td_ptr = (TD_STRUCT_PTR)_task_get_td(_task_id);  } /* Endif */  if (td_ptr) {    return( td_ptr->TASK_TEMPLATE_PTR );  } /* Endif */  return( NULL );} /* Endbody */An example of how to use this function:/* Need prototype */extern TASK_TEMPLATE_STRUCT_PTR _task_get_template_ptr(_task_id);..../* Dynamically create the task */some_task_id = _task_create(..... );.../* Change name of some_task */template_ptr = _task_get_template_ptr(some_task_id);template_ptr->TASK_NAME = "new name";../* Change name of the current (active) task */template_ptr = _task_get_template_ptr(MQX_NULL_TASK_ID);template_ptr->TASK_NAME = "new name"; Q: How are exceptions or unhandled interrupts handled by MQX? A: Basically, there are three ways of handling unhandled interrupts. They are mutually exclusive - in other words, you can only have one active at a time. You'd pick the one that best suits you for an application and use it: 1) _int_default_isr() This is the default mode of handling interrupts - it simply blocks the offending task and sets its state to "Unhandled Interrupt Blocked" 2) _int_unexpected_isr() This mode can be activated by calling _int_install_unexpected_isr() from the application. This will also block the offending task and set its state, but also will print some info on the console about who and what caused the unexpected exception 3) _int_exception_isr() This is the most functional (but also most complex) of all the modes. It can be activated by calling _int_install_exception_isr(). Once this is installed, any unhandled interrupts will call _int_exception_isr(). It might help you understand the behavior of this function by actually looking at the code. It's in source\psp\\int_xcpt.c. Here are the comments that define the behavior: If an exception happens while a task is running, then: if a task exception handler exists, it is executed, otherwise the task is aborted. If an exception happens while an isr is running, then: if an isr exception handler exists, it is executed, and the isr aborted otherwise the isr is aborted. This is why you have to provide exception handlers. For tasks, you install these with _task_set_exception_handler(). You would need to install a handler for each task in your system that you want handled (conceivably, this could be the same handler for all of them) For ISRs, you install these with _int_set_exception_handler(). The parameter is the vector number of the interrupt your installing a handler for, not the exception vector itself (in other words, you'd install handlers for the vectors of ethernet, UARTs, timers, etc, not the divide by zero vector) So, if you want to have full "handling" of all unhandled interrupts, you'll have to install handlers for all the tasks and ISRs that exist in your system. The handler itself could simply flag the error and allow the task to continue running. Other comments: -Note that you shouldn't have to rebuild MQX libraries to change the modes - its simply done with a function call -If one of the above three methods of handling unhandled interrupts does not suit you, you can also create your own handler to take whichever action you want and install it by calling _int_install_default_isr() with your own ISR as a parameter. This might be a simpler approach than using the exception handlers. Q:How is DNS enabled? A:Include DNS.H in the application. Call DNS_init() after calling RTCS_create(). Then insert the following code: DNS_First_Local_server[0].IP_ADDR = "my dns server's ip addr"; Q:Does MQX have memory protection? A: No, not full memory protection (this allows us to run the same code on CPUs -- like DSPs -- without MMUs). However, we do have a version of MQX with some level of MMU support. It allows simple memory protection between tasks and is available for some PowerPC derivatives. Q:What happens if Idle Task blocks because of an exception? A: If Idle Task blocks, System Task, which is really a system task descriptor that has no code, becomes the active task. System Task Descriptor sets up the interrupt stack; then re-enables interrupts. As a result, the application can continue to run. Q:If more than one task "owns" a semaphore, and a priority boost is required, do all owning tasks have their priority raised, or just one? A: The owning task with the highest priority gets boosted. Q:In many RTCS examples we find "/* Enable IP forwarding */ _IP_forward = TRUE;". What does this do? A: This enables forwarding of IP packets from one interface to another. If you have two Ethernet connections, this allows RTCS to route packets between the two interfaces. Q:How do we setup Ethernet auto-negotiation? A:Normally, this is done in the file enet_ini.c, located in the BSP (source/bsp), and normally autonegotiate is the default. Sometimes (but not always) the flag passed to enet_initialize is passed down to this function, and is used to select autonegotiate. Q:How do I bind a UDP socket to a specific IP address and have it receive broadcast packets? A: RTCS does not allow UDP sockets bound to a specific IP address to receive broadcast packets. You can get around this by binding using INADDR_ANY, however in this case you may receive extra traffic you do not wish to receive (e.g. there are two Ethernet interfaces on the board). RTCS emulates BSD and we consider this to be an appropriate behavior. Q:If there is no file system on an MQX target running RTCS how can I use FTP to upload and download files to it? Say I have a datafile on a PC that I want to be able to upload over ethernet to my MQX app as well as later download it. Can I do that without a file system ... say get a file line by line and interpret it? Likewise output it line by line? A: Yes, this is possible, but it requires that you do some work to design the "device" to handle this. Without a file system, the FTP server can communicate with any MQX device - these are usually identified by a string such as "ttya:", "ittyb:", "flash:", etc. They can either by installed by the application or the BSP. The ones previously mentioned are installed by the BSP, but the RTCS apps example (apps.c) also installs two new devices called null: and kmem: In order to communicate with these devices via FTP, on the PC you would do the following: Type: ftp my_ip_address (prompt for user name) - hit Enter To put a file to the server, type: put localfilename remotedevice For example: put test.txt ttya: This will send the contents of test.txt from the PC to the target - the ttya: device will put it to the screen. If you replace ttya: with null: in the apps example, it will simply discard everything it reads. To get a file from the server, type: get remotedevice localfilename For example: get kmem: coredump This will store the contents of kernel data into a file on the PC Now, you can design your own device to do something similar. I would recommend looking at the source\io\io_mem and source\io\io_null devices to use as templates. Basically, you need to code an install, open, close, read, write and ioctl function for your device. When the FTP server calls fopen(), read() and write() on your device, it will access these functions. It would be up to you to decide what to do with the data once it arrives in your functions, but you could process it and also store it for later use. Note that both the RTCS TFTP and FTP *servers* use the same structure. The FTP client uses device names to access the data to send. However, the TFTP client API decodes the data without using a device. Q: Is there a documented API for the IP layer? A:This interface isn't documented since it's assumed that the user won't usually access it. There are four functions: IP_init(), IP_send() (for outgoing packets), IP_send_if() and IP_service() (for incoming packets). IP_send_if() is used only by BOOTP/DHCP to send a limited broadcast with a source IP address of 0.0.0.0. Q: How is the timer used on MQX? A: On ColdFires, timer PIT is used as system timer for scheduler (dispatcher) and for time counting. Q: How to free memory after use mem_alloc? A: Use mem_free
查看全文
The new Freescale MQX™ 4.0.2.1 patch release is now available on the www.freescale.com ·         Files available # Name Description 1 FSL_MQX_4_0_2_1_RELEASE_NOTE Freescale   MQX™ RTOS 4.0.2.1 Patch Release Notes 2 Freescale   MQX RTOS 4.0.2.1 Patch This   patch release is based on the MQX™ RTOS 4.0.2 release and provides Software   workaround for Errata e7166. This   patch release applies to TWR-K70F120M and TWR-K60F120 board support packages. ·         Patch Description ·         This patch provides a software workaround for Errata e7166, which is relevant to the Mask 3N96B silicon. ·         Errata: SoC: SDHC, NFC, USBOTG, and cache modules are not clocked correctly in low-power modes. o   Errata Description: SDHC, NFC, USBOTG, and Cache controller modules are connected to a single master port on the crossbar switch through a multiplexer. While the modules are still clocked in Wait mode, the multiplexer clock, which is connecting the modules to the crossbar switch, shuts off at entry into low-power modes. This prevents the three modules either to complete bus transactions during a low-power mode entry, or to start new bus transactions when the system enters Wait mode (even though the modules themselves remain clocked in Wait mode). Because the cache tag clock and data RAM clock are gated off in Wait mode, cache contents may be corrupted at low-power entry. ·         Software workaround provided: To resolve the Cache Controller issue, all bus master operations for each module should be complete before requesting system entry into any low-power mode. o   To prevent cache corruption at low-power mode entry in idle task and low power manager, the WFI instruction is encapsulated in a special code sequence. The code sequence is executed from a memory location that is not cached (SRAM_L is recommended). Additionally, the code sequence must execute without interruption from the start of the code sequence to the WFI. If an interrupt occurs between the start of the sequence and the WFI instruction, MQX dispatcher code ensures that the code sequence is restarted from the beginning. ·         Known issues o   For known issues and limitations please consult the release notes document.
查看全文
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
查看全文
Video Tutorial 1 of 6 for the iDigi Connector for MQX: Installing and Configuring the iDigi Connector for MQX (1 of 6) - iDigi Device Cloud
查看全文
It's a note to configre and use Flexbus interface in MQX platform .
查看全文