memory usage and speed of execution

davejames

Hi All,

Is there anwhere documented:

1) the amount of memory each PBASIC statement occupies
2) execution speed of each PBASIC statement for a given Stamp type


I just "discovered" the significant memory usage difference between IF/THEN, SELECT/CASE, and ON/GOSUB which would have been nice to know at the outset of code development.

Regards,

DJ
·

Mike Green

There's some information on execution speed here: www.emesystems.com

LoopyByteloose

PBasic is relatively slow when compared to SXasm. I not sure much is published about the amount of memory occupied as I believe the outboard·EEPROM holds the program tokens·and it could be expanded if not enough.

The fastest Basic Stamps are using the SX48. That can be programed with assembly language for much better performance, maybe 50x faster. With SXasm you can easily get exact speed figures in the basic documents, but with PBasic the results are more or less estimates.

The main thing is the SX28 and SX48 can indeed clock faster than comparible microprocessors [noparse][[/noparse]there nearest cousins are PICs] and offer more memory. I suppose there are 32bit processors that run faster and that of course is one of the reasons Parallax introduced the Propeller.

So if you really, really need speed; you might consider directly programing is SXasm.· Or as a second best, use SX/B and speed up the slowest parts with SXasm code improvements. Or, using the Propeller.

Benchmarking microprocessors with software is really a bit of voodoo. In the 1980s tons of comparisions were made and the issue just became more and more cloudy as tests rarely reflect reality. On the other hand, the SX48 is completely deterministic - each clock cycle can be accounted for.· So is the Propeller.· That is in part why these devices can generate video. But it certainly can't be done in PBasic or SPIN alone. Only assembly language programing will offer precision timing in all cases.·

SX/B might offer you a peek into how wasteful different commands are due to their approaches in compiling.· I suspect the IF/THEN is the bare bones of the group and you will find it less wasteful. But you may have to write more lines of code to only use it instead SELECT/CASE or GO/SUB.·· SX/B may not really offer you a good representation of GO/SUB because the SX48 has paged internal memory for program storage and it is not like the storage for the tokens.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's sunny and warm here. It is always sunny and warm here.... (unless a typhoon blows through).

Tropically, G. Herzog [noparse][[/noparse] 黃鶴 ] in Taiwan

Post Edited (Kramer) : 7/31/2008 6:48:47 PM GMT

Tracy Allen

Here are direct pointers to the information that Mike referred to:

www.emesystems.com/BS2speed.htm
www.emesystems.com/BS2pbasic25.htm

Some of the constructs that you asked about came into being as part of PBASIC 2.5 including SELECT/CASE, and ON/GOSUB and many variants of IF/THEN. Those are coded behind the scenes by the interpreter back into the original PBASIC tokens. The second reference goes into that and how to save bytes. You should be aware that you can explore the size of programs and individual snippets by using the memory map feature of the IDE. If you are interested in the real nitty gritty of how PBASIC is encoded, try Brian Forbes' book.

Much of the speed of execution, apart from intrinsically timed tasks, is directly related to how much space the command or command sequence occupies in eeprom.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

davejames

Mr. Green and Mr. Allen - thank you for the links.· The information was quite interesting.· Of course it makes sense (but I didn't think about it at the time) that the retreiving of data from the EEPROM is going to slow things down, not necessarily how long the microcontroller itself takes.

(Mr.) Kramer - thanks for the feedback.· I'll be using the BS2 until it proves too slow to do what I wish.· Not knowing how long its commands require will force me to either setup a bunch of test conditions, or, complete the project and see if it's fast enough.· I have no doubt that the SX line of controllers is faster, but I've already invested some bucks into the BS2 products and tools.

All - yes, I took a look at the memory usage via the memory map and that's what tipped me off to the (almost) 1/2 memory usage of using the ON/GOSUB method versus the SELECT/CASE.· I was just hoping that this information had been officially documented.

Way back when (1984) in the automated test industry, it was imperative to know how long any particular command took to execute as many of them required milli-seconds since the equipment's computer ran at such low speeds by today's standards (<1MHz).· So when writing test programs, it behooved the engineer to avoid long execution commands.· In the semiconductor test industry, time really is money.

Regards,

DJ

Mike Green

That issue is also imperative for the SX and the Propeller where the instruction times are known and predictable and that fact is often used for I/O drivers. Even though there are some instructions with variable execution time on the Propeller, mostly involving shared (hub) memory use, multiple cogs (processors) can be synchronized so this time is predictable as well.

The Stamps, because of the Basic interpreter, doesn't lend itself to that kind of precision in terms of execution time.

davejames

OK - next question:· how long does it take for a BS2 to retrieve stored data from the EEPROM?

My project requires initially storing data into the EEPROM and then subsequently reading that data out.· The stored data is used to control various aspects of hardware latches.

I just realized that the EEPROM retrieval will probably be to slow wherein the user will see a lag time between pushing a button and observing the resultant actions.· My next thought would be to read the stored EEPROM data into the BS2's registers as variables, which...I think, would result in less lag time.· Problem there is that the BS2 only has 13 16-bit registers and that may prove too few.· Have to think about that some more.

Should this thread be in the Basic Stamp forum?

Later,

DJ

Mike Green

There are no specific timings for the READ statement which reads from the EEPROM, but I'm sure the time involved is comparable to other simple Basic statements. Tracy's web page describes how the timing was done. You could easily determine this for yourself.

davejames

OK - just reviewed Mr. Allen's site and found a reference for "READ 0,x" in which he lists 550us as the time required.

Thank you for the reminder to check the sites you'd previously mentioned.

DJ

Mike Green

Remember that these times are approximate. The Basic byte code is very compact. Some constant values take longer to process than others (and occupy different amounts of memory). Other small differences in the code you write may affect execution time. The Stamps were not intended for high speed time dependent control applications. They're relatively slow, but powerful and very easy to use.

davejames

"...times approximate..." - ok, understood.

Just rechecked my proposed design and it requires 11 14-bit registers so I'm safe there. Now I can go down the path of initially storing data into EEPROM and then during operation, copy that data into the BS2 register area for faster access.

I'm using the BS2 for 'proof of concept' and will more than likely go to the 40 pin version as I need a LOT of control lines. Yes, I could go serial, but that adds a layer of complexity I'd rather avoid right now. Again, all the effort over the last few months has been to prove the idea. Then I might come to the conclusion that there's a better way/approach.

Thanks for being a sounding board Mr. Green,

DJ