----- Ursprüngliche Nachricht ----- Von: Sergio Campamá Gesendet am: 08 Dez 2011 15:28:42
Wow JM, thanks a lot! > I'll try fidgeting with these concepts when I have the chance My main worry > about having multiple stacks is detecting if I have enough memory to > "allocate" a new stack, and overflow/underflow > problems I tried to solve this by having a defined number of available > threads, and allocate space for them on RAM statically in C structs. How can > I dimension the required stack size for the thread? > Just trial and error? For allocating the new stack (or the struct, maybe a struct with an ending member of type "unsigned char[0]", which generates an offset to the space behind the struct, the 'stack area'), I use malloc. I know that malloc isn't the best for embedded use. However, if one needs dynamic allocating of memory, malloc is the easiest way to do it, and you know when you run out of memory if malloc returns 0. :) I pass the size of the struct with the management info plus the desired stack size as parameter to malloc. Instead of using 'free' when a thread ends, I save the now unused stack for later use and try to re-use it when a new thread is started. Only if I need a larger stack and malloc returns 0, I free the 'stored' stacks in the hope that they will release a lage enough portion of ram for the new threads stack. It helps against the clobebring of memory by dynamic allocation/deallocation. However, this is not likely to happen. Usually you have a fixed number of threads and do not dynamically decide to create an unforseeable of threads. It is difficult to determine the required stack size. It depends on the complexity of the thread (function call nesting level), local variables of all funcitons used by the thread, and of course you'll need storage space for all ISRs on every stack, since if an ISR is called, it will store its registers and local variables on the current stack. But usually, this is covered by the 'all registers' storage space you need for the threads witch anyway. Here again, interrupt nesting and multitasking won't work together well. :) ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
