Advantage of using Delay_MS subroutine over just using pause or Pause_us?

Shawn Lowe

Well, this question has been bugging me for a while now. Why use a subroutine? Does using Pause really take that much more memory when the program is compiled?

Thanks
Shawn

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe


Maybe I should have waited to do that......

Guenther Daubach

Although I'm not an SX/B expert, I feel ready to answer your question ...

It depends on how often you call Pause from your application.

You can compare SX/B commands, like Pause with Macros in Assembly, i.e. whenever you place a Pause command in your application, the SX/B compiler replaces this by the sequence of instructions required to generate the pause each time. This is similar to how the Assembler expands macros: Each time you refer to a macro in your application, the Assembler replaces it with the instructions contained in the macro definition each time.

On the other hand, when you define a subroutine, and place the Pause command inside this subroutine, the compiler generates the code for the subroutine, and the code for Pause inside of it. Now, when your application calls the subroutine to generate the delay, the compiler only generates the code required to call that subroutine but it does not duplicate the Pause code each time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Bean

Shawn,
It depends how many times you use PAUSE.

At 4 MHz a "PAUSE 10" takes 15 instructions. Where as "Delay 10" takes 4 instructions, but the subroutine takes 19 instructions (2 for the jump, 17 for the subroutine itself). So the subroutine starts saving code after the second use.

I usually go by the rule if it is used more than twice, then make a subroutine.

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com

·

Shawn Lowe

Oh, okay. I have just seen alot of people using subroutines (jonnymac, ect.) and was wondering why since sx/b has the pause command. But if it expands into 17 instructions, then I can see the wisom wisdom in using a subroutine (save 15 instructions).

Thanks

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe


Maybe I should have waited to do that......

Post Edited (Shawn Lowe) : 11/27/2007 11:34:26 PM GMT

Zoot

Besides saving code space, there is a second reason that some of JonnyMac's code uses a pause subroutine -- any program for the SX that uses an ISR (interrupt service routine) can not reliably utilize the "time" dependent SX/B commands, like PAUSE and PAUSEUS (because the "internal" counters to those macros may not accurately reflect "real-time" if the ISR is interrupting the mainline program 1000 or 100,000 times a second).

So, if you see anything resembling this:

SUB
tmpB1 = __PARAM1
PAUSE tmpB1
RETURN
ENDSUB

then that is a space saving measure as Bean and Guenther describe.

If you see anything resembling this:

SUB
tmpB1 = __PARAM1
DO WHILE tmpB1 > 0
tix = TicksPerMS
DO WHILE tix > 0
LOOP
DEC tmpB1
LOOP
RETURN
ENDSUB

then that is an "ISR friendly" pause function -- the var "tix" is being decremented in the ISR automatically "in the background".

I would also venture that "wrapping" any command in a subroutine is a good habit, and since a lot of Jon's code gets picked up and used (and he is approaching things from an educational perspective) I think he follows really good habits by way of setting an example, even if it it's not always necessary.

Like Bean, in my own practice, I only wrap anything (SX/B commands, my own code, etc) if it gets used more than once or twice and the code itself is larger than the instructions for calling the subroutine (i.e., I would not wrap two lines of codes in a subroutine if it had parameters -- the setup of the parameter and the call/return would be larger than the code itself -- that's a candidate for a macro). However, it can improve readibility of code to break out even single calls.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

JonnyMac

Thanks for the nice comments, Zoot. I've attached a program (from my January 2008 N&V column) that includes an "ISR friendly" DELAY_MS subroutine. In order to keep the ISR as trim as possible I set a flag that can be monitored externally, in this case by DELAY_MS. I liberated this [noparse][[/noparse]good] idea from PJV who does a lot of really sophisticated multitasking with the SX and does nothing in the ISR but set a flag.

To Bean's point, if a "big" SX/B instruction (PAUSE, PAUSEUS, SERIN [noparse][[/noparse]no isr], SEROUT [noparse][[/noparse]no isr], I2C, etc.) is being used more than once then wrapping it into a subroutine of function will save program space, and sometimes you can add features to the instruction at the same time.