time.h usage (time(null)) fail

Zafer Ocal said:

I can't use time function with msp430F2232 but I can use it with MSP430F2274.

However, it requires space (e.g. for storing the time struct in a global buffer).

The linker error tells you that after subtracting all used (by your program or by the library functions) space form the MSPs available ram, the remaining free ram is smaller than the cionfigured stack size.
Ram on this MSP is 512 bytes, only 31 bytes are not used by any variable, but 80 bytes are defined to be reserved for the stack.

You can reduce the required stack size to 31 bytes, but this is quite low. Even the default 80 bytes ar enot much if you have ISRs and local variables or (worse) use printf().
Keep in mind that there is no way to really limit the stack usage. If the program flow increases the stack, it grows, eventually overwriting your variables. The project setting is only a theoretical limit that triggers a linker error (or in debugger, a stack overflow warning), but it does not affect the actual generated code.

He is right. I had the same problem. When you add those extra functions you really start to blow out code space and ram. I have found that code composer seems to use a lot more code and ram than other compilers, however the only solution I came up with was to create my own. Depending on how much random you require, I just used the timers and WD counters and registers to create a level of random numbers, which becomes a bit more random as time passes. I only needed small numbers, but when we ran some tests and collected the numbers generated the results appeared to be reasonably random in nature. All depends on what you want as a end result. Hope this helps.

Duke Nukem said:

I have found that code composer seems to use a lot more code and ram than other compilers

However, CC is indeed not the best optimizing compiler ever regarding code size. IAR does a better job here (for a higher price). And the newer GCC4-based versions of mspgcc are much better too (even if not as good as IAR, since mspgcc is based on the rather generic GCC, but MSP specific optimizations are refined daily, asthe uniarch MSPGCC is under development right now)

In any case, hand-crafted target-specific functions are almost always smaller, faster and fit better than any generic library function.

For the original problem, this means, using Time() as seed for the random generator is a huge overhead. There is no system time, so Time() gets the 'time' from somewhere. Using this souce directly (e.g. the current Timer count), is definitely much smaller and faster.

Thanks for your answer, as you said I use a hand-crafted target-specific functions "Linear congruential generator" to solve it and it seems solve my problem. I get random numbers.... without increase the size of my code. 

Additionally I have analyze the "time.h" code but understand nothing. 

Zafer Ocal said:

I use a hand-crafted target-specific functions "Linear congruential generator" to solve it and it seems solve my problem. I get random numbers.... without increase the size of my code. 

Zafer Ocal said:

I have analyze the "time.h" code but understand nothing

Some time ago I had to implement part of it myself, since mspgcc didn't have the functions, the NutOS for the atMega128-based Charon module did have them and my code library has to support both.
I don't know what's actually provided with IAR or CC.

Hi Jens-Michael. Sorry, might have been a bit of a misunderstanding in my original message. What I intended to say was that "your" comments were correct in that using a time function would most likely add lots more code etc. My comments in regards to CCS was an observation in that I have code that is quite happy to fit within the 2K limit, but when I take the same code and paste into CCS, I get code space and stack errors and I have to remove a lot of code and reduce the stack to get it even to compile. IAR worked when I did the same thing, however that also presented other issues which I couldn't be bothered to follow up on. In CCS, I suspect maybe a lot of debug support? Don't Know and possible only a real problem if trying to do a lot in a cost effective chip. Solution - use a bigger chip?

Anyway, I agree, that if some one has a cunning plan in generating numbers then it would be good to share. I have just used a mixture of Timer, WD and any other register/s to give something random. May not be the best solution, but in my app, it works.

static unsigned long Seed; 

unsigned long NextVal(void)

{

  Seed=Seed*1664525L+1013904223L;

  return Seed;

}

/* Call before first use of NextVal */

unsigned long InitSeed()

{

   //Your code for random seed here, Correct distribution errors in seed

   NextVal();

   NextVal();

   NextVal();

   return NextVal();

}

I use  this with 

srand ( NextVal());

RNDNUM = rand();

Duke Nukem said:

My comments in regards to CCS was an observation in that I have code that is quite happy to fit within the 2K limit, but when I take the same code and paste into CCS, I get code space and stack errors and I have to remove a lot of code and reduce the stack to get it even to compile.

It might be that in IAR, some of the code is put into the functions (doubled) instead of using a sub-function for this, which itself uder other cirumstances required another sub-function etc. So in IAR, if oyu use ALL funcitons, maybe the resulting code is larger (because of the doubling), but in CCS, more code (and the variables it uses) is included if you only need a fraction of all function (but if all are used/linked, CCS might be smaller and the ram usage the same).
Without disassembling the lib or seeing the source, we'll never know.

It's a fact, however, that IAR does a better optimization of the generated code, resulting in less flash consumption. There is, however, no way to reduce the ram space used for global variables. So for the same code (which isn't true for the standard library, as these are independent works), the RAM usage at compiler time should be identical. (at runtime, however, funciton calls and local variables vs. register variables might make a difference in stack usage and therefore required stack size)

Duke Nukem said:

I have just used a mixture of Timer, WD and any other register/s to give something random.

Zafer Ocal said:

//Your code for random seed here, Correct distribution errors in seed