Sleep Function

[rbytes]

Optimized.

[matt7]

For accuracy and to lessen the load on the CPU, why not ditch the PAUSEs altogether?

Code: Select all

/* These sleep functions are replacements for the PAUSE function. The
   PAUSE function does not relieve CPU load during the duration of the
   PAUSE, whereas these functions use SLOWDOWN until the specified
   duration has elapsed. Two interruptible versions are also provided. */

' A simple, uninterruptible sleep routine
DEF SLEEP(dur)
  tWake = TIME() + dur
  DO
    SLOWDOWN
  UNTIL TIME() >= tWake
END DEF

' An interruptible sleep routine that allows the sleep duration
' to be cut short if the screen is touched. Use a duration of -1
' to sleep indefinitely until the screen is touched.
DEF SLEEP_TOUCH(dur)
  tWake = TIME() + dur
  IF dur = -1 THEN
    DO
      SLOWDOWN
    UNTIL TOUCH_X(0) > -1
  ELSE
    DO
      SLOWDOWN
    UNTIL (TIME() >= tWake) OR (TOUCH_X(0) > -1)
  END IF
END DEF

' An interruptible sleep routine that allows the sleep duration
' to be cut short if the "wake" button is pressed. Use a duration
' of -1 to sleep indefinitely until the button is pressed.
DEF SLEEP_BTTN(dur)
  tWake = TIME() + dur
  BUTTON "wake" TEXT "⏰" AT SCREEN_WIDTH()/2, SCREEN_HEIGHT()/2
  IF dur = -1 THEN
    DO
      SLOWDOWN
    UNTIL BUTTON_PRESSED("wake")
  ELSE
    DO
      SLOWDOWN
    UNTIL (TIME() >= tWake) OR BUTTON_PRESSED("wake")
  END IF
  BUTTON "wake" DELETE
END DEF

On my device (iPhone 8), SLOWDOWNs take an average of 0.055 seconds, so the accuracy of these sleep functions is +/- that amount. To improve accuracy even further you could use something like this:

Code: Select all

DEF SLEEP(dur)
  tWake = TIME() + dur
  DO
    tLeft = tWake - TIME()
    IF tLeft <= 0.1 THEN    ' get to within 1/10th of a second,
      PAUSE tLeft           ' then PAUSE for the remainder
      RETURN
    END IF
    SLOWDOWN
  UNTIL 0
END DEF

In my testing, this got me to an accuracy of about 0.0001 seconds. That's an improvement from about 1/20th of a second to 1/10,000th of a second!

[rbytes]

Interesting. I have been sharing ideas with Henko on this subject for several weeks. He created some pause/sleep routines using TIME() that were excellent, and I hope he publishes them here.

I found that using SLOWDOWN in the loop in my function did lessen the load on the processor significantly. As a result, I had to add a large reduction factor to each PAUSE in the loop.

But considering what I use PAUSE commands for, it doesn't matter to me how efficient the routines are. The longest PAUSE I have used in an app so far is 10 seconds. Each of the solutions I have seen that include interrupts need a lot more coding than a single line. So I am more likely to stick with just the PAUSE command for anything that doesn't require an interrupt.

As for the pause with interrupt, it is not important to me if it is absolutely accurate, but only that it is accurate enough that no one would notice the difference. Considering battery use, I don't require routines to be as efficient as theoretically possible, but efficient enough that no one would notice the difference using any other solution.

The other factor is the fondness a programmer has for his own solutions. Again, I post mine for consideration, but I will not likely know, and don't care, who adopts my routines and who doesn't. For the program I am working on now, I chose my own, but I will definitely consider your pause/sleep code and Henko's for future projects.

I am pleased to see more posts on the Forum now that we are well into the new year, Matt7, and I am glad you are back.

[matt7]

You make many valid points, and I definitely agree that for most applications the changes I made are unnecessary and overkill. I just wanted to provide some alternatives here in the thread you started so others can choose what works best for them. For longer pauses, processor efficiency becomes a bigger deal, and I can imagine a few situations where you might want a high degree of precision in the duration. Regardless, I had fun working out my own way to address the situation posed by your OP.

I usually don't care too much about the number of lines of code, especially for libraries, because once they are done I never really look at them again. All I ever see is the function call into those libraries. For me, I enjoy striking the balance between efficiency (as in simplicity; is each line of code and instruction necessary for accomplishing the intended outcome? Is there a cleaner way of achieving the same thing?) while also providing nice-to-have features for convenience and aesthetics, all the while keeping the code as readable as possible. I can't stand looking back at my own code and not being able to figure out quickly what I was doing and why I was doing it that way, haha.

I'm glad to be back on the forum more too. I would love to get back to my gradient library and the editor, but I am working full time and also currently taking two graduate-level classes, plus I have family and house projects! Hopefully, I'll be able to squeeze in some time here and there.

[Henko]

and I hope he publishes them here.

This is the wait function that i added to my utility lib:

Code: Select all

' interruptable wait function
' x,y - location of the wait button
' t   - wait time in seconds (t=0 -> forever)
' background will be restored upon termination
'
def wait(x,y,t)
if t=0 then t=1E+6 ! to=time()
set buttons font size 80 ! button "mhtdz" text "😴" at x,y size 100,100
do slowdown ! until time()>to+t or button_pressed("mhtdz")
button "mhtdz" delete ! Set buttons font default
end def

[rbytes]

Thanks, Henk.

[rbytes]

matt7, your pause routine that uses screen touch sensing to end the pause needs a GRAPHICS command at the start. The button method works in both TEXT and GRAPHICS modes, but the touch method only works in GRAPHICS mode.

I had forgotten this and thought I had found a bug when my touch statement didn't work. But when I reread the INPUT & OUTPUT section of the manual, this required condition was mentioned in the preamble at the top of the page.

[matt7]

your pause routine that uses screen touch sensing to end the pause needs a GRAPHICS command at the start.

Yes, that is true. I probably should have mentioned that in the description above the function, that the touch-interrupt functionality only works while on the GRAPHICS screen. Whatever you do, don't call SLEEP_TOUCH(-1) while on the TEXT screen!

[rbytes]

There are inconsistencies in some of the commands.

You can position an interface object such as a button or sprite in text mode by entering screen coordinates, yet TOUCH can't detect screen coordinates. I am not familiar enough with xCode to know if this is an iOS restriction.

Since SLOWDOWN can slow the processor, why doesn't the PAUSE command use that same capability?

When Smart Basic was under development, these were the types of things that we would feed back to the developer, and he was very responsive.

[matt7]

Definitely seems inconsistent in one sense, but it is consistent in another sense. The inability to get touch coordinates when in TEXT mode is consistent with editable text boxes that appear when in GRAPHICS mode. (I think touches still work over read-only text boxes.) I think that is because priority is first to see if a text box needs to get focus, whether to highlight text or move a text selection handle, etc. And the TEXT mode is basically a text box that fills the entire screen.