[Tinyos-help] Code copying (generic) VS PoolC+QueueC+Code sharing

Philip Levis pal at cs.stanford.edu
Tue Feb 12 09:18:34 PST 2008

On Feb 12, 2008, at 2:59 AM, Krisakorn Rerkrai wrote:

> Hi,
> I'm working on one application which probably needs a generic  
> component approach.
> I'm a bit concerned about the code size generated by code copying  
> method. Another
> solution I was thinking of is to use PoolC and Queue to maintain my  
> attribute list and
> feed this list to a single component (code sharing approach but  
> manually manages
> the attribute on the upper layer component). Which approach is a  
> code optimized
> solution?
> I try with BlinkAppC to see how much memory code copying approach  
> takes.
> I simply remove the Timer component to investigate this.
> BlinkAppC
> #Timers        ROM       RAM
>     3              2642         55
>     2              2616         45
>     1              2526         35
> If I look at the memory usage by each module, I can see how much  
> VisualizeTimerC uses.
> VisualizeTimerC
> #Timers        ROM       RAM
>     3               448         30
>     2               422         20
>     1               320         10
> For RAM usage, it's clear why this is linear. However, the ROM side  
> seems to use less
> memory when a generic component is used several times. Is there any  
> reason behind this?
> Also, could somebody suggest me which approach is more efficient  
> (in terms of memory usage)?
> 1. several generic modules
> 2. PoolC+QueueC+single module

Timers are generic configurations, not modules. So they don't lead to  
code copying. Instead, they increase the uniqueCount() of the  
underlying VirtualizeTimerC. Each Timer requires 10 bytes of state,  
hence the linear increase in RAM. The increase in ROM is due to the  
slow growth in length of the switch statement. The big jump from 1 to  
2 would be (I'm guessing here) because you have a branch in the  
handler and can't inline it as easily.

The cost of code copying is why most services are generic  
configurations that sit on top of a parameterized module. That way,  
you get compile-time sizing and configuration, but only one code module.


More information about the Tinyos-help mailing list