logo资料库

UCOSII 2.90 ReleaseNotes.PDF

第1页 / 共90页
第2页 / 共90页
第3页 / 共90页
第4页 / 共90页
第5页 / 共90页
第6页 / 共90页
第7页 / 共90页
第8页 / 共90页
资料共90页,剩余部分请下载后查看
Micriµm 949 Crestview Circle Weston, FL 33327 U.S.A. www.Micrium.com µC/OS-II The Real-Time kernel V2.90 Release Notes © Copyright 2010, Micriµm All Rights reserved FAX: +1 954 217 2037 Phone: +1 954 217 2036 1 of 90
V2.90 (2010/05/18) This is a minor release as it contains only a few items that were not caught prior to releasing V2.89. CHANGES TO V2.89 You should follow these steps in order to upgrade from a previous version to V2.89. 1) OS_CORE.C: Added OSSafetyCriticalStart() to indicate that all initialization has been completed and that kernel objects are no longer allowed to be created. 2) 3) 4) 5) 6) All Files: Modified the source code to reduce the number of MISRA-C 2004 rules not respected: 8.5 - there shall be no definition of objects or functions in a header file 14.7 - a function should have a single point of exit 15.2 - every non-empty case clause in a switch statement shall be terminated with a break statement 15.4 - only one case - a switch expression should not represent a Boolean value 17.4 - array indexing shall only be applied to objects defined as an array type 17.4 - pointer arithmetic should not be used uCOS_II.H: Corrected compilation error when OS_EVENT_EN is disabled and OS_FLAG_EN is enabled. OS_FLAG.C: Replaced safety critical test to check OSSafetyCriticalStartFlag set by OSSafetyCriticalStart() on OSFlagCreate(). OS_MBOX.C: Replaced safety critical test to check OSSafetyCriticalStartFlag set by OSSafetyCriticalStart() on OSMboxCreate(). OS_MEM.C: Replaced safety critical test to check OSSafetyCriticalStartFlag set by OSSafetyCriticalStart() on OSMemCreate(). 2 of 90
7) 8) 9) OS_MUTEX.C: Replaced safety critical test to check OSSafetyCriticalStartFlag set by OSSafetyCriticalStart() on OSMutexCreate(). OS_Q.C: Replaced safety critical test to check OSSafetyCriticalStartFlag set by OSSafetyCriticalStart() on OSQCreate(). OS_SEM.C: Replaced safety critical test to check OSSafetyCriticalStartFlag set by OSSafetyCriticalStart() on OSSemCreate(). 10) OS_TASK.C: on Replaced safety critical test to check OSSafetyCriticalStartFlag set by OSSafetyCriticalStart() and OSTaskCreate(). OSTaskCreateExt() 11) OS_TMR.C: Replaced safety critical test to check OSSafetyCriticalStartFlag set by OSSafetyCriticalStart() on OSTmrCreate(). 3 of 90
V2.89 (2009/06/09) This is a minor release as it contains only a few items that were not caught prior to releasing V2.88. CHANGES TO V2.88 You should follow these steps in order to upgrade from a previous version to V2.88. 1) All Files: Added „u‟ as a suffix to all constant values to denote that these numbers are unsigned. This was done to satisfy one of the MISRA-C:2004 rules. Added cast to (INT8U *) for all constants strings. 2) 3) 4) 5) 6) OS_CORE.C: The „pname‟ argument of OSEventNameGet() needed to be a „**pname‟ instead of „*pname‟. If OS_TASK_SUSPEND_EN is not set to 0 then OS_TaskStat() will call OSTimeDly(OS_TICKS_PER_SEC) if OSIdleCtrMax is zero. OS_MEM.C: The „pname‟ argument of OSMemNameGet() needed to be a „**pname‟ instead of „*pname‟. OS_MUTEX.C: Needed OSMutex_RdyAtPrio(). set to OSPrioCur to „prio‟ in internal function OS_TASK.C: The „pname‟ argument of OSTaskNameGet() needed to be a „**pname‟ instead of „*pname‟. Added OS_TaskReturn() to catch tasks from returning without deleting themselves. This function requires that a new hook function be declared: OSTaskReturnHook(). OS_TASK.C: The „pname‟ argument of OSTaskNameGet() needed to be a „**pname‟ instead of „*pname‟. 4 of 90
V2.88 (2009/01/21) This is a minor release as it contains only a few items that were not caught prior to releasing V2.87. CHANGES TO V2.87 You should follow these steps in order to upgrade from a previous version to V2.87. 1) OS_CORE.C: OSIntExit() and OS_Sched() have changed slightly because of a boundary condition found with the Cortex-M3 port. Specifically, we needed to move the statement: 2) 3) OSTCBHighRdy = OSTCBPrioTbl[OSPrioHighRdy]; Before testing for the priority. uCOS_II.H: The function prototype for OSEventPendMulti() incorrectly declared the timeout as an INT16U instead of an INT32U since we changed all time delays and timeouts to now use 32-bit values. All Files: Changed the way functions are declared to be consistent with the prototypes in ucos_ii.h. 5 of 90
V2.87 (2009/01/07) This is a major release as it contains changes to some of the elements of data structures as well as #define configuration constants. Also, some of the functionality has changed but this should not have any significant impact. If you are using a Kernel Awareness plug-in for some of the debuggers, you will need to obtain a newer version of the Kernel Awareness plug-in which is compatible with V2.87 or higher. This is because ASCII strings for names are now referenced by using a pointer instead of storing the ASCII name in the kernel object. UPGRADING TO V2.87 You should follow these steps in order to upgrade from a previous version to V2.87. 1) OS_CFG.H: You no longer need to specify the „size‟ of ASCII strings used for names. That‟s because we now store a pointer to the name instead of actually allocating storage for it in the corresponding kernel object. This was done to significantly reduce the amount of RAM needed in your application. You will need to enable this feature. Follow the following table: 2) This #define … OS_EVENT_NAME_SIZE OS_TASK_NAME_SIZE OS_FLAG_NAME_SIZE OS_MEM_NAME_SIZE OS_TMR_CFG_NAME_SIZE Changed to OS_EVENT_NAME_EN OS_TASK_NAME_EN OS_FLAG_NAME_EN OS_MEM_NAME_EN OS_TMR_CFG_NAME_EN The new value of these #defines are either 0 (to disable naming the object) or 1 (to enable naming the object). OS_TIME.C: OSTimeDly() now accepts a 32-bit argument instead of a 16-bit argument. This was done to simplify OSTimeDlyHMSM(). In most cases, you will not need to change anything in your code. time delays and also to allow longer 6 of 90
3) 4) 5) 6) 7) 8) 9) OS_CORE.C: OS_StrCopy() has been eliminated since it‟s no longer used by µC/OS-II. You should not have been using this function in your code since it was meant to be an internal function. This change should thus not cause any problem. specific registers. OS_CORE.C: as Added task OS_TASK_REG_TBL_SIZE 32-bit unsigned registers for each task. These registers ARE NOT the same as the CPU registers; they are more like task specific variables. These „registers‟ are typically used for such things as „error codes‟ (or errno in other operating systems). You can also communicate information to tasks via these registers. as many You can have OS_MBOX.C: Timeouts on OSMboxPend() are now 32-bit values. OS_MUTEX.C: Timeouts on OSMutexPend() are now 32-bit values. OS_Q.C: Timeouts on OSQPend() are now 32-bit values. OS_SEM.C: Timeouts on OSSemPend() are now 32-bit values. OS_TASK.C: item 4 above) by calling You can set and get OSTaskRegSet() and OSTaskRegGet(), respectively. Again, task registers ARE NOT the same as CPU registers. registers (see task 10) OS_TMR.C: and OSTmr_Unlock() have been OSTmr_Lock() replaced with OSSchedLock() and OSSchedUnlock(), respectively. Now, timers no longer need to rely on semaphores being available. Also, this allows you to call other timer services from the timer callback. 7 of 90
V2.86 (2007/09/12) This is a major release as it contains a new feature called „Multi-Pend‟ (implemented in OSEventPendMulti()) which allows a task to pend on multiple objects (semaphores, mailboxes or queues). If any one of those objects is posted to, the function returns and indicates which (or all) events posted. Multi-pend is the only feature added in this version and a number of changes throughout the code has been implemented in order to support this new feature. Details on how to use OSEventPendMulti() can be found in the µC/OS-II reference manual. UPGRADING TO V2.86 You should follow these steps in order to upgrade from a previous version to V2.86. Even though only Multi-Pend was added in V2.86, some of the items below are repeated from previous versions because they are important to follow. 1) Timer Manager: Timers MUST now be created by OSTmrCreate() before they can be used. In V2.82, a timer was created and started when you called OSTmrStart(). Now you MUST call OSTmrCreate() and then OSTmrStart() to create and start the timer, respectively. It is now your responsibility to delete a timer when it is no longer being used. The Timer Manager user-available functions are now: OSTmrCreate() OSTmrDel() OSTmrNameGet() OSTmrRemainGet() OSTmrStart() OSTmrStop() To create and start a timer, you need to call OSTmrCreate() and then OSTmrStart(). When you are done using a timer, you can delete it by calling OSTmrDel(). 8 of 90
分享到:
收藏