Performance profiling

Kal

Hi, we are trying to monitor 2 wheel encoder pins and drive motors based on that. This means that we need to have a fairly tight timing loop so as to not miss transitions.

My question is this: is there any timing information on the various instructions for BS2? Are bit-wise operations faster than integer operations? How about if-then? Is there any way to optimize the code for faster performance?

Any help that you can give us would be appreciated!

Thanks,

-Kal.

p.s. I did see the other posting regarding using an external counter to relieve the real-time need, but that is not an option at this time due to time and budget constraints in getting this project done! Next time, that sounds like the better plan!

Bruce Bates

Kal -

You will propably find this information to be most helpful:
http://www.emesystems.com/BS2speed.htm

Thanks go to Dr. Tracy Allen, a regular member of this forum.

Regards,

Bruce Bates

Kal

Thanks, Bruce! That link was most helpful.

Looks like the instructions profiled are pre-2.5. I wonder if he will update with 2.5 instructions. In any case, it gives me a pretty good idea as to what is going on!

-Kal.

Tracy Allen

Kai,

PBASIC 2.5 really does not change anything on the BASIC Stamp, so the timings are the same. The fancy stuff in PBASIC 2.5 is done in the IDE, and the IDE translates the new structures like DO-LOOP and SELECT-CASE into the same old tokens used by the BASIC Stamp from the beginning. The IDE is doing a lot under the hood to implement those higher structures. If you want to optimize for speed, you should understand how it does that translation. I have a page on that too, at www.emesystems.com/BS2pbasic25.htm. You can often optimize the speed of a loop by recoding it strictly in the PBASIC 2.0 syntax.

The speed of instructions on the Stamp depends mostly on how many bits of data have to be read from the EEPROM before the program can actually execute the instruction. For that reason, operations on bit variable s often take longer than operations on word variables. That might seem counterintuitive, until you consider that the address for a bit (with 128 possibilites) has to be longer than the address for a word variable (with only 16 possible addresses). Even within that there are tricks. For example, the IDE stores addresses and numbers that are powers of 2 in an especially compact form in the EEPROM, and as a consequence it can read them out faster. For example, it can address pin p8 faster than it can address pin p15. It can access the constant 2048 faster than it can access the constant 2047.


There are of couse some truly new hardware instructions (like I2C....) that first appeared in the more recent Stamps.

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

Tracy Allen

Kai,

Another pointer to a URL, which uses a state machine to scan multiple encoders with about the same time overhead as it takes to scan one:

www.emesys.com/BS2fsm.htm#twobit

It does have strong limits in terms o speed. It was okay when I wrote the code for beaded cable water depth gages in an application with a calibrated flume. The water depth never changed that fast. But with a motor, unless it is geared way down, it might overrun the Stamps' interpreter. Encoder algorithms have to catch each and every state, so the Stamp is limited to 100 Hertz or so, maybe 300 if you use the fastest Stamp, the new 'px.

The algorithm is simple boolean logic, so it can be programmed directly into an SX chip in assembly or with SX/B and then track multiplle encoders with time to spare.

Kal said...
Hi, we are trying to monitor 2 wheel encoder pins and drive motors based on that. This means that we need to have a fairly tight timing loop so as to not miss transitions.

My question is this: is there any timing information on the various instructions for BS2? Are bit-wise operations faster than integer operations? How about if-then? Is there any way to optimize the code for faster performance?

Any help that you can give us would be appreciated!

Thanks,

-Kal.

p.s. I did see the other posting regarding using an external counter to relieve the real-time need, but that is not an option at this time due to time and budget constraints in getting this project done! Next time, that sounds like the better plan!

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

Kal

Thanks, Tracy! That's pretty fancy work on the State Machine.

We are not using quadrature encoders (direction is deterministic), but we do have an additional complication in that we wait for 2 consecutive 0's or 1's before declaring a transition (debounce). Is that overly conservative? Do most people just use a single transition and have no problems with it? If we can get away with a single transition, clearly the loop can be a lot tighter. Any insights?

Thanks for the VERY informative web site, and answers on this forum!

-Kal.

Harry Stoner

Whether you debounce switches or not would depend upon the type of switch you are dealing with. If it bounces then I guess you would want to debounce it. For an application reading big leaf switches, I needed 2 consecutive readings of the same value to consider the state valid. While I don't have proof that this is perfect (it didn't need to be), it seemed good to me in the real world.

Maybe you can just try your code without debounce logic and see how it goes?

Harry

allanlane5

Usually 'debouncing' is used on mechanical contacts (push-buttons, switches, relay contacts) because when you throw a switch the contacts really do 'bounce' off each other for a few milliseconds, and the resulting signal has noise because of it. Now a wheel-encoder manufacturer knows how irritating it is to have to de-bounce in software (takes time, for one thing) so I would expect they already put out a 'debounced' output (nice square transition, no 'ringing' in the signal...).

So Harry has a good suggestion -- try it without debounce logic and see what happens.

Tracy Allen

I agree with Harry. If the signal comes from a reed switch or a mechanical switch of any kind, then debounce is necessary. On the other hand, optical and electronic sensors usually are very clean signal-wise by design and will not give any problem with a single reading.

Even with a bouncy switch, there is also the option of debouncing in hardware with an RC circuit, or with a key debounce chip like the MAX6817. That way your program doesn't have to deal with it.

If you know the debounce algorithm it is not hard to think of specific input trains that would fool it. But usually the probablilty of the bogus pulse train is low. The more samples, the lower the chance of error. For example, the MAX6817 samples many times during a 50 millisecond debounce interval, or, you could set an RC circuit to the same interval--An RC circuit with asymmetrical drive is like continuous time sampling. It would have to be an extremely bad mechanical switch to bounce for that long.

The bounce interval for a reed switch, is usually finished in well under 1 millisecond. If the reed switch is in an anemometer, for example, it may need to respond to frequencies of 60 hz or more in a high wind, so a debounce interval of 5 or 10 milliseconds would be the maximum without defeating the purpose.

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

Kal

I think I confused issues by poor choice of a word: "debounce"; I was using it as a short-hand notation, but clearly that gave the wrong impression. The specific problem that I am trying to avoid stray pick up of an IR signal from other random reflections, or an unclean edge on the encoder disk (it is laser printed on a regular printer). Again, as I said, this may be worrying too much about a non-existant problem. Maybe we should try it the other way, and only resort to it if there is a problem.

Thanks,

-Kal.