When creating a custom module. Does all static memory need to allocated using awe_fwMalloc.? If you need an array of fixed size can it be defined as:
float myArray[MYSIZE];
void someFunction(...)
{
}
Where it is not defined inside a function?
When creating a custom module. Does all static memory need to allocated using awe_fwMalloc.? If you need an array of fixed size can it be defined as:
float myArray[MYSIZE];
void someFunction(...)
{
}
Where it is not defined inside a function?
11:54am
Hi Darrel, sorry for the late response! Here is an answer from one of my colleagues, let me know if this helps!
12:17pm
So to clarify if a .c file (e.g. ModTest.c) which uses the awe_fwMalloc() to allocate memory for parameters, state, etc., and this file calls functions from another file (e.g file1.c), where file1.c has the form:
#include “typedefs.h”
static const uint32_t const_vals[3] = {34000, 40000, 50000};
void do_stuff(int32_t *data)
{
uint32_t k;
for (k =0; k < 3; k++)
{
data[k] += const_vals[k];
}
}
In ModTest.c:
do_stuff(&data[0]);
where data has been alloc’ed using awe_fwMalloc() but the “static const uint32_t const_vals” has not. So my question is where is the “const_vals” stored, is it on the heap or somewhere else ? Has this similar implications as mentioned above if there are multiple instances of the module ? Thanks.
11:05am
Hello David,
Because this is C, depending whether you're on Windows or Linux or something else, the storage is either in the code section or a constant section, and by language definition there will only be one copy of the storage.
The only way heap storage can ever be assigned is by calling awe_fwMalloc(). The same is true for C++.
Since the array is declared constant, the compiler will if possible place it in a non-modifiable section (depends on target), and it does not matter how many module instances you create. However, if you ever attempt to use a non-constant object, you must allocate storage for that from the heap, otherwise it will behave strangely or worse crash when multiple modules are instantiated.
Thanks,
Kevin
6:19am
I agree that a lot of this is target/implementation dependent, but can I assume that:
1. If the variable is constant (be it local, file static, or global) then you don't have to use awe_fwMalloc() as the compiler will place it probably in a read-only data section memory (.data), or maybe even in the code segment (.text).
2. If we have a static local (file static or function static) variable or a global variable (which is non-constant) then we should use awe_fwMalloc() instead so that the variable uses the heap.
3. If we have a local (i.e. automatic) variable (but not a constant), then we don't need to use awe_fwMalloc() as it gets stored on the stack ?
10:23pm
Hello David,
1 and 2 are correct assumptions, but 3 is not. Variables that are writable, but not on the stack (i.e. local) must be allocated from the heap. The module structure itself is allocated earlier from the heap when the module is created, so you can add any members you like to that structure.
What you must not do is allocate any non-local writable variables other than in those two places. You are free of course to use a custom constructor to allocate any amount of heap storage and have a module structure member point to that (a lot of modules do that).
Thanks,
Kevin