2011/8/10 João Gonçalves <[email protected]>
> Hi, I have this command to find the FLLD value in UCSCTL2. For the
> FLLREFDIV in UCSCTL3 I'll need something similar.
>
> command uint16_t Msp430FreqControl.getFLLD(uint8_t flld){
>
> switch(flld){
> case 0:
> return 1;
> case 1:
> return 2;
> case 2:
> return 4;
> case 3:
> return 8;
> case 4:
> return 16;
> case 5:
> return 32;
> case 6:
> return 32;
> case 7:
> return 32;
> default:
> return 32;
> }
> return 32;
> }
>
> My question is, is it better to have this implementation or to have the
> corresponding values of FLLD in an array in memory?
>
Hi Joao,
Look at the code generated for this. If you are using the tinyprod
msp430-int-pu branch (and I beleive you have this) then a listing is
automatically generated and main.lst will show you the code generated.
Look at what the compiler generates for different optimization levels and
that will give you the flavor for what the toolchain will generate.
With the way you have the above implemented, it will be all in code space
implemented as instructions. Not the most efficient way to do it, and
until we git 20 bit support, costly in terms of code space.
It would be something like:
>
>
> command uint16_t Msp430FreqControl.getFLLD(uint8_t flld){
>
> uint8_t FLLD_value [ ] = {1, 2, 4, 8, 16, 32, 32, 32};
>
This is implemented as a local, I'm not sure how the toolchain will deal
with this. Somehow this local will get initilzed with the values you've
given it. It may use instructions to do this. It will also play
FLLD_value on the stack (RAM). So in this case you have both code space
and ram space being chewed. But you should look at the code generated and
where the space is actually allocated.
>
> return FLLD_value[flld];
>
> }
>
> Which one is lighter in terms of memory?
>
Depends on what question exactly you are asking. In terms of RAM the 1st
method is lightest at the expense of code space.
The 2nd one is pretty ugly too if the toolchain works the way I am assuming.
You should actually go and look at the code generated.
Now the way I would do it is as follows:
const uint8_t FLLD_value[] = {1, 2, 4, 8, 16, 32, 32, 32};
command uint16_t Msp430FreqControl.getFLLD(uint8_t flld) {
if (flld > 7) return 32;
return FLLD_value[flld];
}
The const puts FLLD_value into ROM and uses it from ROM. Can't be
modified.
If you leave the const off then FLLD_value will be initilized data (goes
into the .data section) and a corresponding initilizer block will be built
in ROM that contains all initilized data for the .data section. In other
words you burn both code space and ram space. The code space area is the
data itself so this is better than using instructions to set the area up but
still...
So the global const is the way to do this. Minimal code and minimal cost
in RAM and ROM.
eric
> João
>
>
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
