Live LiveCode Code Event #17 - wrap-up

Kay C Lan lan.kc.macmail at gmail.com
Tue Apr 12 23:26:36 EDT 2011


This only makes sense if you've read Part 1a

----------------

MY IMPORTANT OBSERVATIONS

Basically LiveCode is EXTREMELY susceptible to timing issues and there
is a NEED to include a 'wait' command in your LiveCode loop. What is
illogical, and from my own perspective, only possible to determine
through experimentation, is the appropriate length of the wait. It's
also IMPORTANT to include 'with messages' with your 'wait' otherwise
you can lock-up LiveCode.

Here is an extract of my LiveCode script:

     open driver tDriverName for text update
     write numToChar(1) & cr to driver tDriverName
     wait 1 ticks with messages
     read from driver tDriverName until CRLF in 1 ticks --need first read
     repeat
        read from driver tDriverName until empty --normal reads
        put it after tUSBData
        wait 17 millisecs with messages
        if (the default of me = true) then
          exit to top
        end if
     end repeat
     -- more code to do stuff
     put tUSBData into field "output"


This code, without the 'wait 17 millisecs with messages' will lock-up
LiveCode and you need to Force Quit.

Initially I started with figures in the 200-300 millisec range and
placed the data straight into field "output" for viewing, and things
worked OK, but not perfect. In a quest for speed I started playing
with the wait time and placed the data into a variable 'tUSBData'.

The following is for 69 pin read at 57600 baud:

With LiveCode just sitting there doing nothing, Activity Monitor would
report that it was using 18% cpu.

Once I pressed my Button and started my LiveCode Script, with the wait
time set at ANYTHING ABOVE 50ms the cpu would drop to 4% whilst the
pins were static, ie no changes, I could leave them that way for
minutes (too impatient to wait hours to see if it were different) and
it would just sit there around 4%. As soon as I started changing the
pin status, the cpu would rise to 6%. As soon as I stopped, it would
go back down to 4%.

Repeating the same experiment with wait 50ms, again, 18% cpu whilst I
hadn't started my script, but as soon as I did it rose to 34% cpu and
it didn't matter if the pins were static or being changed, the cpu sat
at 34% cpu.

Continuing the experiment I discovered that not much changed as you
looked at waits down to around 25ms, but then below this things
started to change again.

Repeating the same experiment with wait 19ms, again 18% cpu whilst I
hadn't started my script, but as soon as I did it dropped to 13%
regardless of whether the pins were static or changing.

Repeating the same experiment with wait 17ms, again 18% cpu, then when
I started my script it dropped to 3% cpu with static pins, rose to 6%
with changing status, and drop back to 3% as soon as they became
static. Again it didn't matter how long they remained static, the cpu
remained at 3%.

Repeating the same experiment with wait 16ms, again 18% cpu before
starting, then as soon as I started the cpu rose rapidly to 100%. It
didn't matter if the pins were static or changing, the cpu would
remain at 100%. Interestingly the cpu rose faster to 100% if the pins
were static than if I were changing them. IF YOU DO NOT HAVE 'with
messaged' in you wait command, if you get to this condition you will
probably have to FORCE QUIT to get out of it.

INTERESTINGLY these figures were basically identical regardless of
whether I was reading 10 or 69 pins. Much the same regardless of 9600
or 57600 baud. See CPU Performance figures in Part 2 of my email.

For reasons I couldn't fathom, for my 10 pin experiments some of my
data was corrupted; not badly, just the data spread across two lines,
or extra blank lines added. Logically it seemed that the longer the
wait, the more correct the data. BUT, the data also IMPROVED by using
57600 baud rather than 9600. STRANGEST of all though, is that at 17ms,
57600 baud and 69 pins, the data came out perfect????. Seems LiveCode
prefers more data at a fast baud. See Data Output in Part 2 of my
email.

Please NOTE the importance of using millisec rather than ticks. 1 tick
= 16.6666 millisec. If I tried wait 1 tick I'd have the cpu hit 100%.
If I tried 2 ticks (33ms) I'd be in the 34% region, which would be the
same for 4 ticks (50ms), so I'd end up at 5 ticks, well above what is
needed.

Lastly I ASSUME, and it is a big ASSUMPTION, that if my repeat loop
contained a whole bunch of extra lines of script, these would take up
cycles, which would take up millisec which SHOULD therefore effect how
long my waits are.

What I KNOW is that LiveCode is VERY susceptible to TIMING issues when
communicating with Arduino on OS X via USB. Your repeat loops MUST
contain wait commands that INCLUDE 'with messages'. Use MILLISEC not
ticks. (This does NOT apply to the odd wait command you may have in
other areas of your script OUTSIDE the repeat loops monitoring serial
comms).

Finally, you MUST experiment with different wait values to find the
best, and just because the numbers start heading in the wrong
direction, doesn't mean that the numbers wont head in the right
direction with even lower values. 1 ms can make ALL THE
DIFFERENCE!!!!!!!

Hope that helps.




More information about the use-livecode mailing list