Hi, I am having trouble to correctly understand the following : 1) task work spaces 2) rtx166 system heap 3) rtx166 context heap I am working on one application that uses 11 tasks and with far model. os_use_heap returns 66132 os_use_heap_far returns 3372 and I have: static unsigned int huge system_heap[0x1000]; static unsigned int near contxt_heap[0x1000]; for os_start_system(). all task have WSPSIZE=256 now can anyone explain a bit of how this works!!! does rtx dynamically manages the pools!!! what does os_use_heap and os_use_heap_far really returns for far model? How can I see if WSPSIZE for each task are ok! Anyone knows a trick for these configurations? Any help on this matter will be welcomed. thanks, joao
does rtx dynamically manages the pools!!! Yes, see chapter 'System- and Context-Heap' in the RTX manual: The allocation algorithm used is very simple and fast. Beginning from the lower addresses of the heap the blocks are allocated (the lowest free memory area of sufficient size is used). Blocks may be de-allocated again, thus enabling a re-use. However released blocks are not re-combined by the heap manager possibly leading to holes in the heap area. what does os_use_heap and os_use_heap_far really returns for far model? The number of bytes actually allocated. Your reported values are greater than the size of the arrays. It looks like the heaps are overwritten. In uVision2, you can see the heap usage in numerical and graphical representation: - select menu 'Peripherals \ RTX Debug session \ Start' - select tab 'System Resources' - for see detailed infos of the heaps, click on the box 'used context' or 'used system' How can I see if WSPSIZE for each task are ok! Anyone knows a trick for these configurations? You can try this one: Before 'os_start' fill the context heap with a pattern, e.g 0xaa55. Start your application. Examine the Workspace, you can see the pattern in regions never overwritten. If your application dynamically delete and create tasks, this method is not applicable. Free memory blocks are then reused for newly created workspaces.
thanks toni, " - select menu 'Peripherals \ RTX Debug session \ Start' " I do not have this menu! Maybe something is bad in my configurations or some DLL is missing. "It looks like the heaps are overwritten." This is not good. The problem is that I can not increase contxt_heap size because it must be near!!! if I change from near it does not work! Does it have to be near for what? near is faster but if it is not enough!
Hi Joao, from the information provided, it is hard to understand, what is going on. Workspace size Is it really necessary, that all tasks use 256 bytes of workspace? The workspace needed for a task depends on the nesting depth of function calls within the task, the number of concurrent interrupts and the memory space needed for local variables within the functions of the task and called by the task. How to proceed? You should check the following criteria, to find out, where the return results get unreasonable: 1. Get the latest version of the KEIL-tools and RTX. These include the RTX-Debug support DLL. 2. Check the return code of all os_create_task calls for successful creation of the task. 3. call os_heap_use and os_heap_use_far after each os_create_... call, because these calls consume heap memory. How to proceed further? Would it be possible for You to send Your uVision project - whenever possible, stripped to the bare minimum of code, which still shows the behaviour - to "baessler@mettler-fuchs.ch". I am supporting RTX-166 and would be glad to help You in finding a solution of Your problem.
Thanks Peter, I have done the following: 1) from toni comments I have filled the heaps with a pattern and then I watch if there is space available. No problem. Also the sw runs well (until now!) 2) I have try to read the heap on the fly with os_heap and os_heap_far by a command by the serial port and os_heap always gives "strange values". Since my timings are very short I have not wasted much time with it. My feeling was that the heaps were ok but anything like keil bug was happening! After your comment I have made further tests namely reading after each createtask. And I have found the following: Although RTX manual says that os_heap returns ulong it return uint!!!! SO I have made printf with %d and not %lu! Now the results are ok.