DelayUs issues

Ashwin,

You are not clear on where this DelayUS() function is coming from.  The function in ControlSuite is called DSP28x_usDelay for F28335, so I don't think you mean that function.  If you're talking about the function that comes in the example code of appnote SPRA958, then yes, that function would need to be adjusted if you run the F28335 at other than 150 MHz.  It says that right in the header information in the DelayUs.asm file:

* Notes:
*   1) The execution time of this routine is based upon a 150 MHz
*      CPUCLK.  It also assumes that the function executes out of
*      internal RAM.  If executing out of internal flash or external
*      memory, the execution speed will be slightly slower.
*      However, the inner loop of this function is essentially
*      invariant to the memory it is running in.  Therefore, even
*      when running in flash memory, the basic loop time will be
*      only slightly longer than 1 us.

It sounds like you adjusted the function correctly.

If you want to make a generic delay function that works for variable frequency (why you'd want to do this I'm not sure), you would need to pass the frequency as a parameter and do some calculations inside the function.  The assembly language is documented in SPRU430 (CPU) and SPRUEO2 (FPU).  Might be easier to write a C shell that does the scaling computations and then calls DelayUs() instead.

Regards,

David

Ashwin,

The delay time is calculated by simply counting up the instruction cycles, and multiplying for your clock period (1/freq).  The heart of the function is the RPT #n || NOP, which is one cycle for the RPT, and n+1 cycles for the NOP (RPT says REPEAT the next instruction n times, so it is executed n+1 times).  The cycle counts for each instruction are all in the CPU User's Guide, SPRU430e.  All I did when I wrote the function was count up the cycles in the outer loop (from DelayUs label to the  'BF DelayUs1, GT') for everything but the non-RPT loop.  This is the outer loop overhead, and is fairly small.  I then figured out how many total cycles I needed in the inner loop to make the outer loop execute in 1 us, based on the device frequency (60 MHz for my example).  You then just figure out the RPT argument.  I basically ignor the call and return and the few extra overhead cycles outside the outer loop.  You can't easily account for them, and they really only impact the error percentage if the delay is very small (say 1 or 2 uS or so).  For larger delay, the few extra overhead cycles get spread out across a long delay, so accuracy (as a percentage) is pretty good.

Rather than trying to modify the .asm function (which of course can be done), it might be easier for you to just make several different Delay functions that are each calibrated for a particular frequency that you need.  For example, you could make DelayUs60() for 60 MHz, DelayUs40() for 40 MHz, and so on.  Then you can write a C function that calls the correct delay function based on some variable that specifies the frequency.  This will be quick to do, and you won't have to mess with writing new asm code.  You'd just need to calibrate the delay function for each of your distinct frequencies.  Also, the delay function is small, so havaing multiple copies in memory is no big deal.  This approach will work well if you don't have a million different frequencies.  Just a thought.

Regards,

David