On Fri, Aug 19, 2011 at 11:23 AM, Sergio Campamá <scamp...@ing.puc.cl>wrote:
> Wow, thanks for all the info! I had thought about having arrays for
> everything, but didn't want to because I wouldn't know how many of each
> struct I would have in each module. But if what you're telling me about
> malloc and free is true, maybe I should change that behavior… Until now I've
> had no real drama with them, besides the processor getting stuck after 10
> minutes of hard work or so. But it seems better to just migrate to using
> static arrays… Seems safer anyway. The real problem with it is that I would
> have to know the memory requirements at compile time, which I personally
> dislike (coming from the dynamic object oriented programming world).
>
Dynamic Object are all well and good when eveerything works right but real
ugly when they don't
more importantly the typical dynamic programming environment is based on a
larger machine where there is reasonable amounts of memory. The msp430
embedded world is a bit different having 16K of RAM or less. Static is the
way to go.
TinyOS uses NesC which is a superset of C but one of the things that NesC
provides is mechanisms for doing the static allocation you are talking about
automatically. It will size arrarys and static things appropriately given
what has been hooked in.
eric
> Thanks for all the tips!
> ---------------------------------------
> Sergio Campamá
> sergiocamp...@gmail.com
>
>
>
>
> On Aug 19, 2011, at 1:50 PM, Chris Liechti wrote:
>
> > Am 19.08.2011 17:53, schrieb Sergio Campamá:
> >> Thanks for the insight into the problem. The thing is that I have a
> >> task scheduler, a linked list that, well, lists the tasks to
> >> perform... Since linked lists are dynamic in nature, I need malloc to
> >> create the new "task" and append it to the list.. And after the task
> >> is done, I free the task and
> >> go on to the next one... The other place I use linked lists is to
> >> maintain a list of timers that the application uses to signal certain
> >> events... after
> >> the timer activates, it also gets freed...
> >>
> >> So that is why I need malloc and can't (or don't know how) to do it
> >> with other types of dynamic storage, or static. (On that subject,
> >> what other types of dynamic storage exist?)
> >
> > just because you use a linked list does not automatically mean that you
> > also need dynamic memory.
> >
> > i also implemented an event handler that uses a linked list. an event_t
> > is a struct with the information about the event. each module that wants
> > to use an event allocates its own object as [static] global. each event
> > can only be enqueued once.
> >
> > pro:
> > - each module is responsible for its own memory
> > - all statically allocable
> > - exactly as many event objects as are needed
> >
> > con:
> > - entire struct in RAM, including the function pointer which will not
> > change.
> >
> >
> > an other possibility is to have an array of objects [structs] and your
> > own allocate (and free) function that returns pointers to that array.
> > that way you also get statically allocated memory.
> >
> > pro:
> > - all statically allocable
> > - also possible to use indexes instead of pointers. indexes are easier
> > to check if they are valid (compared to pointers). and a single byte
> > is usually enough.
> >
> > con:
> > - you also have to make two design descisions:
> > - how many objects will be needed (array size). do you go for a
> > typical size or worst case size?
> > - what will you do if no object can be allocated?
> > (if selected size < worst case size)
> > - it does not automatically adjust to the application (e.g. if you have
> > different variants. the solution above only uses the RAM when the
> > modules are linked)
> >
> > chris
> >
> >
> ------------------------------------------------------------------------------
> > Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> > user administration capabilities and model configuration. Take
> > the hassle out of deploying and managing Subversion and the
> > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> > _______________________________________________
> > Mspgcc-users mailing list
> > Mspgcc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
