This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How can I use rand(), srand() function in CCS v4.2?

How can I use rand(), srand() function in CCS v4.2?


require? libraries?


I compiled program, there are no errors.

I included <stdlib.h>

But Program doesn't response in rand() function, when I run program.

  • You should only need to include stdlib.h and link against the RTS library.
    What do you mean when you say "doesn't respond" ? Does the call to function rand never return? Does it return an unreasonable value? Does the program crash?
  • Thanks for your reply.
    "doesn't respond" means never return. Program is stopped.
    I will check whether the RTS library is included or not.
  • Make sure you have an appropriate startup function, such as _c_int00. Make sure you have a reasonable amount of stack allocated. Try single-stepping the assembly code starting from main to make sure you're really entering the function rand. It's a very small function, you should be able to quickly see where it's going wrong.
  • I included libraries as above picture.
    You said RTS library, is there anything to include ?
    What is the RTS library supports rand() function ?
  • The RTS library is automatically linked for C programs. Is your program a C or assembly program?
    The RTS library will be named something like rts6740.lib
  • I wrote my development environment above, Title.
    I am using CCS v4.2.4, Dsp/Bios 5.41.10.36.
    I included <stdlib.h> and ${RTDX_LIB_DIR}.
    Do I have to be included more ?
  • If you have a call to rand, and your program linked without an error message, then you have successfully linked against the RTS library. You already have an include of <stdlib.h>. You should not need to add any further code. I do not believe that the problem you are having is due to missing code. You need to more precisely describe the symptoms so that I can analyze the problem. Please try the steps I suggested above. Make sure your executable has the _c_int00 function. Make sure you have a reasonable amount of stack allocated. Try single-stepping the assembly code starting from main to make sure you're really entering the function rand. It's a very small function, you should be able to quickly see where it's going wrong.
  • Thanks for your reply.

    I tested _c_int00 function. It is always returned the same address.

    I found another.

    I made a function, it is called by DSP/BIOS every 0.002 sec.

    rand() function is in above function.

    When rand() function is called, memories are broken.

    So I changed rand() to printf().

    When printf() fuction is called, memories are broken, too.

  • I think I know what's going on.  rand is a non-reentrant function; you shouldn't call it from an interrupt function because you might be interrupting another call to rand.  When used with DSP/BIOS, DSP/BIOS installs mutex handling for program state, such as the state of the random number generator (RNG).  When execution enters rand, DSP/BIOS locks the RNG state so that no other thread can modify the state until rand has finished execution.  However, you are interrupting that execution and calling rand again.  The second call cannot proceed because the mutex it needs is already locked, so the interrupt cannot finish, so the first call to rand cannot release the mutex.  This is called deadlock.  rand and printf, as well as many other functions, are non-reentrant.  You should not call any of them from any kind of interrupt.

  • I had used rand() function in DSP/BIOS at CCSv2.1 before using CCSv4.2
    Do you say rand() function changed above CCSv4 version ?

    If changed, Which function replace rand() function ?

  • There is no replacement for rand. I don't know precisely what has changed, but the RTS library has never supported nesting calls to rand. The fact that your program did not reach deadlock with previous versions means you were either being lucky or rand was not returning appropriate values. You need a thread-safe implementation of rand, which is not available until C6000 compiler version 7.5.0 or later, and only if you use the thread-enabled version of the RTS.
  • Is rand() related to data access model, mem model, by any chance ?
  • No, rand does not depend on any memory model.
  • Thank you for your reply.

    You said "There is no replacement for rand() function TI provides".  Non-reentrant function !!

    If so, how do I solve this problem?

    I have to use rand() function or equivalent function in DSP/BIOS Task.

    Should I make other function ?

    Maybe, If I will make, int Random (void)

    static _DATA_ACCESS unsigned long next = 1;

    _CODE_ACCESS int Random(void)

    {

    int r;

    //       _lock();

              next = next * 1103515245 + 12345;

    r = (int)((next/65536) % ((unsigned long)RAND_MAX + 1));

    //       _unlock();

    return r;

    }

    Like this way, I will make equivalent function? This is provided from TI.

    I want to know better way than this way

  • Hi, Archaeologist
    I would like to consult you that how you know the author used "rand" in an interrupt function? The author said that he made a function called by DPS/BIOS. So it is implied that the function he made himself is an interrupt?
  • Hi, kim
    I examine the function you make above. It seems to me that the variable "r" is always the same. How can it be a random number?
    Regards
    Chopper
  • The global variable "next" is the state of the RNG. For each call to Random, it is changed to a different pseudo-random value. The value of r, the return value of the function, depends on the RNG state, so it is different every time, until it eventually repeats.
  • If you absolutely must have a RNG in two or more threads, you basically have two options

    1. Each thread has its own state.  Either the RNG state must be a thread-local variable, or you must have a separate RNG state variable for every thread.
    2. Or, the interrupting thread/interrupt must relinquish control to the thread that locks the RNG state to avoid deadlock.

    If you simply remove the locks, you will have a race condition between threads.  You may have two threads getting the same value from rand at the same time.  You may or may not care about this; I don't know.