I uploaded a (not-yet-finished) file - OttoExplorer - that uses 79
bytes of RAM, close to the limit of 86. I made very liberal use of
cut 'n paste so you may find many sections familiar. I tried to keep it
well-commented.
I used: an LCD, sonar, IR, pan/tilt servos, 2 DC motors, and lots of
Constants.
My understanding is that using constants will store values in EEPROM,
freeing up limited system resources. I also know that using VCs
(virtual circuits) can help speed program execution.

Is there a trick I am missing, or misusing? I'd luv some advice on how
to optimize the code (esp. with VCs) so I can get the most out of my
ooPIC. I tend to write sloppy code, so tightening up the code and
making best use of resources is important. Execution speed is not as
important to me as maximizing use of limited ooPIC resources.

The code is far from finished, but it is a good start, and hopefully
easy to follow. It is for a B2.2+ ooPIC using V6 compiler.
------------------------------------



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, "red71956" wrote:
>
> I uploaded a (not-yet-finished) file - OttoExplorer - that uses 79
> bytes of RAM, close to the limit of 86. I made very liberal use of
> cut 'n paste so you may find many sections familiar. I tried to keep it
> well-commented.
> I used: an LCD, sonar, IR, pan/tilt servos, 2 DC motors, and lots of
> Constants.
> My understanding is that using constants will store values in EEPROM,
> freeing up limited system resources. I also know that using VCs
> (virtual circuits) can help speed program execution.
>
> Is there a trick I am missing, or misusing? I'd luv some advice on how
> to optimize the code (esp. with VCs) so I can get the most out of my
> ooPIC. I tend to write sloppy code, so tightening up the code and
> making best use of resources is important. Execution speed is not as
> important to me as maximizing use of limited ooPIC resources.
>
> The code is far from finished, but it is a good start, and hopefully
> easy to follow. It is for a B2.2+ ooPIC using V6 compiler.
>

Your resource limitation is object memory. Adding VS's won't
necessarily improve that. In fact, the oBus or oWire objects will
probably increase the usage.

Sub explore() could probably be replaced by a VC that triggers an
event and the event code would trigger avoid() function. But all that
would do is collapse the explore() function and eliminate the loop in
main().

Using the named constants doesn't result in any less object memory and
may not really change the code space requirements either. Write a
simple program like:

dim a as new oByte
const SixtyFour = 64

sub main()
a = 64
a = SixtyFour
end sub

Then look at the emitted code and see if the two are different. I'm
not on a Windows box at the moment so I can't really test this. I
doubt they are different. YEARS ago, with interpreted Basic, named
constants were faster that numeric constants; depending on the
interpreter, of course.

You might try using Byte instead of oByte and save a little object memory.

Richard

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



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Thanx I'll try both of your suggestions (soon) and let you know what
I find.
Little tricks like using Byte rather than oByte, and better use of
VCs, that's the type of info I'm looking for.

I read somewhere in the docs that use of constants can save variable
memory, but if it ain't working I'll go with whatever is easier.

I have some 32k EEPROMs so I can go wild with programming and data
space. Now I have some work to do! Like I said, speed isn't a
priority (unless we are REALLY talking slow!) but I do want to try
coding some more advanced 'behavior' using the available variables
and objects.

Thanks again for the advice!

--- In o...@yahoogroups.com, "rtstofer" wrote:
>
> --- In o...@yahoogroups.com, "red71956" wrote:
> >
> > I uploaded a (not-yet-finished) file - OttoExplorer - that uses
79
> > bytes of RAM, close to the limit of 86. I made very liberal use
of
> > cut 'n paste so you may find many sections familiar. I tried to
keep it
> > well-commented.
> > I used: an LCD, sonar, IR, pan/tilt servos, 2 DC motors, and lots
of
> > Constants.
> > My understanding is that using constants will store values in
EEPROM,
> > freeing up limited system resources. I also know that using VCs
> > (virtual circuits) can help speed program execution.
> >
> > Is there a trick I am missing, or misusing? I'd luv some advice
on how
> > to optimize the code (esp. with VCs) so I can get the most out of
my
> > ooPIC. I tend to write sloppy code, so tightening up the code and
> > making best use of resources is important. Execution speed is not
as
> > important to me as maximizing use of limited ooPIC resources.
> >
> > The code is far from finished, but it is a good start, and
hopefully
> > easy to follow. It is for a B2.2+ ooPIC using V6 compiler.
> > Your resource limitation is object memory. Adding VS's won't
> necessarily improve that. In fact, the oBus or oWire objects will
> probably increase the usage.
>
> Sub explore() could probably be replaced by a VC that triggers an
> event and the event code would trigger avoid() function. But all
that
> would do is collapse the explore() function and eliminate the loop
in
> main().
>
> Using the named constants doesn't result in any less object memory
and
> may not really change the code space requirements either. Write a
> simple program like:
>
> dim a as new oByte
> const SixtyFour = 64
>
> sub main()
> a = 64
> a = SixtyFour
> end sub
>
> Then look at the emitted code and see if the two are different. I'm
> not on a Windows box at the moment so I can't really test this. I
> doubt they are different. YEARS ago, with interpreted Basic, named
> constants were faster that numeric constants; depending on the
> interpreter, of course.
>
> You might try using Byte instead of oByte and save a little object
memory.
>
> Richard
>

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



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

> I read somewhere in the docs that use of constants can save variable
> memory, but if it ain't working I'll go with whatever is easier.

THAT is true! To assign a constant to a variable and use it as a
constant wastes the storage space of a Byte or oByte (Word or oWord,
also).

Dim MyNamedConstantInAVariable as new oByte

sub main()
MyNamedConstantInAVariable = 3 'and I will NEVER change it!
end sub
But whether you use a named constant (const MyConstant = 3) or a
literal (3) in an expression would probably not make any difference at
all:

a = MyConstant
versus
a = 3

Named constants are nice because they help document the code. At
least they should! Literals are to be avoided as a matter of
practice. Many consider them 'magic numbers' and really hate to see
them in code. It's often impossible to determine what they mean.
Well, sometimes it is obvious but not always.

>
> I have some 32k EEPROMs so I can go wild with programming and data
> space. Now I have some work to do! Like I said, speed isn't a
> priority (unless we are REALLY talking slow!) but I do want to try
> coding some more advanced 'behavior' using the available variables
> and objects.

Figure on 300 lines per second. But having code for different
behaviors that operate independently won't slow the machine. It's
just a different group of code. The only cost is in determining which
behavior to execute. That should be short and fast.

Richard

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



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

On Jul 20, 2008, at 1:47 PM, rtstofer wrote:

>> I read somewhere in the docs that use of constants can save variable
>> memory, but if it ain't working I'll go with whatever is easier.
>
> THAT is true! To assign a constant to a variable and use it as a
> constant wastes the storage space of a Byte or oByte (Word or oWord,
> also).
>
> Dim MyNamedConstantInAVariable as new oByte
>
> sub main()
> MyNamedConstantInAVariable = 3 'and I will NEVER change it!
> end sub
> But whether you use a named constant (const MyConstant = 3) or a
> literal (3) in an expression would probably not make any difference at
> all:
>
> a = MyConstant
> versus
> a = 3

Unless you use it in multiple places and plan to tune that constant.
Invariably you use that constant in 6 places and then end up changing
it in 5, forgetting the 6th, which results in "anomalous behavior." :-)

> Named constants are nice because they help document the code. At
> least they should! Literals are to be avoided as a matter of
> practice. Many consider them 'magic numbers' and really hate to see
> them in code. It's often impossible to determine what they mean.
> Well, sometimes it is obvious but not always.

Yes. I try to get all my students to use variable and constant names
that help make the code self-documenting.

--

73 de Brian, WB6RQN
Brian Lloyd - brian HYPHEN wb6rqn AT lloyd DOT com

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



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )