Problem with DELAYUS();

Ivan,

Ivan Debelec said:

When i put DELAYUS(200); it works fine, but when I have DELAYUS(delay); and delay is global variabe defined as uint16_t delay=200; i dont get the same delay time

I think this is because DELAYUS() is a macro, not a function.  It looks like this:

#define DELAY_US(A)  DSP28x_usDelay(((((long double) A * 1000.0L) / (long double)CPU_RATE) - 9.0L) / 5.0L)

So, if you code DELAY_US (constant), the compiler evaluates the argument calculations at compile time.  But if you code DELAY_US(variable), the argument calculations must be performed by the C28x at runtime.  You'll notice these are all floating point calculations, including a division.  They will take a long time to execute especially if you are using a fixed-pt. C2000 device (you don't say what device you are using).

So far as flash vs. RAM execution goes, the delay function in the header files is highly susceptible to the effects of the flash wait-states because it is using a conditional branch construct:

_DSP28x_usDelay:
     SUB    ACC,#1
     BF     _DSP28x_usDelay,GEQ    ;; Loop if ACC >= 0
     LRETR

Personally, I prefer to use a RPT (repeat single) construct since then the inner loop of the function is invariant to the flash wait-states (once the function is fetched from flash, it is repeated without incurring wait-state penalties).  If you download appnote SPRA958 there are DelayUs.asm source files for each device that implement this type of delay function.  The functions are tuned for the MHz the device is running at since they are hardcoded with the correct RPT count to perform a 1 uS delay.  Therefore, they will run the same whether you pass a constant or a variable as the delay parameter (the downside of this is that the functions need to be hard-coded for a particular MHz, unlike the macro approach that the header files use).  Note that the functions are NOT exact, but close.  There is call/return overhead and a little bit of one-time incurred overhead in the functions that are not accounted for.  Also, while the inner 1uS loop is essentially invariant to flash vs. RAM, the outer BF loop is not invariant so there will be some slight difference between RAM and flash execution.  One last thing is that the RPT is not interruptible.  That means you could have up to a 1uS latency before the RPT loop finishes and the interrupt can be taken.  The macro approach that the header file delay function uses does not have this issue.

http://www.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=spra958l&docCategoryId=1&familyId=1414

Regards,

David