How much code can an IFI controller handle?

[Larry Barello]

I imagine this has been answered somewhere else before: But, roughly speaking, how much code can the IFI robot controller handle before missing packets?

I have heard things like 10,000 lines of basic/second which would imply ~250 lines of code.

Is there a simple way to determine when you start missing packets? Compare packet #?

Larry
#492 Titan Robotics

[Lloyd Burns]

Dr J pointed out last year that you could, in fact, store 8 programs in the BS2sx, and have one program call the next into action, sharing between programs variables stored in a special way. Just in case you should worry about running out of space.

The whole topic is probably archived here, or you could check out parallaxinc.com for details.

[Larry Barello]

The issue isn't code space, but timing: how much code can I execute between packets. I want to do some real time programming (velocity control, servo stuff) which adds up.

[Curtis Williams]

You can get the delta_t from the master processor just like you would a joystick axis. Delta_t tells you how many packets you missed (your code was still working with a packet when a new packet came in).

[Larry Barello]

Thanks. Looking at Delta_t I see that I am currently missing 1/8 packets. If I leave a subroutine out that implements a slow PWM (to get around the Victor deadband) I miss 1/16 packets. So I must be on the edge...

Now, to learn how to optimise code - pbasic style.

Any suggestions on what is good, bad and ugly with regarding pbasic coding & execution speed would be appreciated.

Cheers!

[Joe Ross]

I'm not sure how you are viewing the value of delta_t, but you should realize that debug statements are really slow. Put 1 or 2 in and delta_t will go up, so your code may be fine.

[Joe Johnson]

The following code has the lights up just on LED at a time on the OI. For me, it is easier to see.

Joe J.

PacketsMissed VAR delta_t


' put the following just after the serin command
PacketsMissed = delta_t +1

'I know the above is sort of "unclean" code because it is not obvious that a variable on the right side of the equation is also on the left, but for me it tells me that I have changed the definition of delta_t to something more to my liking. After I have incremented delta_t, I never refer to delta_t any more, only PacketsMissed


OUTS.lowbyte = 1 << PacketsMissed

'continue with code...

[Larry Barello]

THanks for the code snippet!

I had already done, logically, what you stated (look at delta T and light an LED) since, as you point out, even a trivial debug statement can easily chew up 1 cycle (9600 baud, and probably polling! - the basic stamp sure sucks)

But what I DIDN'T know, is that you can use a variable to specify which LED to illuminate. That will help make my code somewhat tighter.

Thanks!