Newbie question about program execution speed

zbroussard

Greetings all -

So the specs say 4,000 instructions per second.· When I program

DO
num·= num+1
debug ? num
LOOP

I get up to 2800 in a MINUTE.

I'm going to be looking at monitoring 10 channels of digital inputs, and I need to know how
fast this dude is really checking the inputs....· Is the problem that the Debug command slows
things down?

I know this is a silly question, but i did try to check the FAQ !

Thanks much.

allanlane5

Yes, the "DEBUG" statement is slowing you down.

If it takes 60 seconds to get 2800 messages, you are getting
46.6666 messages/second, or 21.42 mSec/Message.

A direct replacement for the debug statement is:
SEROUT 16, 16384, [noparse][[/noparse]"hi"]

The Debug statement runs at 9600 baud. The "?" in there outputs
"num = 1000" -- putting up the "num =" characters. Thus, for each increment,
you are sending 11 characters. Now at 9600 baud, a character should take
about a millisecond. Yours seem to be taking twice that -- unless your
'num' above is not really what you've named your variable?

A MUCH better test is:

MAIN:
Debug "Start"
Num = 0
WHILE NUM < 4000
Num = Num + 1
WEND
DEBUG ? Num
GOTO MAIN

Now, you should time the amount of time between two 'DEBUG' outputs. That
will give you a MUCH more realistic execution time.

P.S. I usually use the number of 300 uSec per instruction when programming the BS2.· This is for 'normal' instructions.· SERIN/SEROUT, PULSIN/PULSOUT, SHIFTIN/SHIFTOUT, and PAUSE instructions are more dependent on the data than on the instruction timing.

P.P.S.· The BS2p is about 2.5 times faster than the 'stock' BS2, and the BS2sx is faster yet, I believe.
·

zbroussard

OK -Thanks, that's very helpful.... and you're right "num" is not what I was using -

I was using "counter" I believe.

I'm used to PLC's and such, and as a mechanical type, forget silly things like the fact that messages don't get sent magically.·

Thanks again,

ZB

Jon Williams

Just a small note ... WEND is not a PBASIC keyword.·· This version should work:

Main:
· DEBUG "Start", CR
· num = 0
· DO WHILE (num <·4000)
··· num·= num + 1
· LOOP
· DEBUG DEC num, CR
· GOTO Main

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA

allanlane5

Thanks Jon, you da man.

claylj

I could be wrong, but the 4000 instructions per second would be machine instructions, not BASIC instructions. Each BASIC instruction when compiled into pcode would be several machine instructions.

Support, is there a way to determine the actual number of instruction?

Larry

allanlane5

No claylj, it's approximately 4000 PBasic Instructions Per Second. The actual PIC 16C54 processor is probably running at 4 MIPS in machine instructions.

PBasic is a 'tokenizing' compiler. There's an on-PIC library of code (burned in, hard-coded) that runs a PBasic interpreter. The IDE compiles your PBasic source code into PBasic 'tokens' -- a 'token' is basically an integer, one per PBasic keyword. The 'tokens' are downloaded into the BS2 eeprom. When the BS2 is reset, it begins reading tokens from the eeprom and based on the token runs the respective library code in the PIC. Then it fetches the next token from EEPROM.

So the PBasic run-time can do this to 4000 tokens per second.· 'Timed' tokens take longer -- SEROUT/ SERIN/PULSOUT/PULSIN, etc -- there the execution time is based more on the data, or the length of pulse, than the Token interpretation time.

And the way to determine the actual number of PBasic tokens you have is to look at the 'memory map' once your program is compiled. "DATA" is stored from location zero up. The code tokens are stored from high-memory down.

dandreae

The best way to time your code is to use an oscillosope.· First, use a HIGH and LOW command and measure it, then take another command of your choice and add it between the HIGH and LOW· command and subtract the difference.· You can do this for most of the commands, beware that this won't hold true for commands waiting on inputs.· I believe you can more information at Dr. Tracy Allen's website www.emesystems.com .

Dave





▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Dave Andreae

Tech Support
dandreae@parallax.com
www.parallax.com

·