I have noticed that new IAR EW8.10 can not accommodate the same size of INT_HEAL_LEN as in old IAR tool. Also the new Z stack 2.5.0 consumes more RAM than Z stack 1.4.3. Somehow I ran out of heap memory and I need to reduce INT_HEAP_LEN. However, our application requires as much as possible heap size for OSAL. so I have several options and I want get some advices:
1. Code optimization. reducing some unnecessary code, but I don't know which part I can reduce in z stack
2. I noticed that XSTACK occupies 0x300 bytes, which is little bit more for my point of view. I remember XSTACK is for call convention parameters. So considering it is single threading with moderate Interrupts and not so many reentrant calls. Can I reduce the XSTACK size in order to increase INT_HEAP_LEN?
thanks
Rui
I dig into this field and have some findings. The new Z stack 2.5.0 seems to occupy more RAM than 1.4.3
Z stack 1.4.3 memory map:
117 453 bytes of CODE memory 18 bytes of DATA memory (+ 85 absolute ) 7 928 bytes of XDATA memory (+ 8 absolute ) 192 bytes of IDATA memory 8 bits of BIT memory
Z stack 2.5.0 memory map:
153 338 bytes of CODE memory 32 bytes of DATA memory (+ 70 absolute ) 7 935 bytes of XDATA memory 192 bytes of IDATA memory 8 bits of BIT memory 125 bytes of CONST memory
Actually Z stack 2.5.0 occupies larger XDATA size(7935 vs 7928), but I get much less INT_HEAP_LEN for OSAL memory allocation(200 Bytes or so). Can anyone explain why this happen? Because Z stack occupy more XDATA so we don't have that much for heap? Is there anyway I can turn down some of functions to give out more memory?
Please take a look at my reply to your other post regarding INT_HEAP_LEN. There are some suggestions for "finding" RAM that can be added to your INT_HEAP_LEN.
As you suspect, the default size of the parameter stack may be larger that your application needs. You should determine your device's stack "high water mark" and try reducing the stack size accordingly - perhaps leaving 10%-20% headroom.