Hi Peter,

to understand the code tightness you must take in account the following:

the Pic Basic (Pro) [I think also other compilers] has a high-level
statements, e. g. LCDOUT, LET, IF, etc. It means behind the statements
there are CALLed routines. If the compiler encounters a new statement type
(i. e. new in your program, it did not occur up to that point) the whole
stuff is linked to your program. If the program is relatively complex,
this necessary overhad seems to be huge. However, if a statement of
previous type occurs, only the calling sequence will be generated inline
(i. e. several words). With LET and arithmetical expression, it is a bit
more complicated. If the expression or a sub-expression can be evaluated
during compile-time, it will be without overhead. However, multiplication
and addition causes the appropriate routines to be linked. I use the
practice if I have only a single division (being done in runtime!) I try
to replace it with RLF/RRF statements, so the whole dividing stuff can be
eliminated.

The need of RAM is another thing. Of course, the routines need some
working space. I think it is normal. I suggest to drop 16C84 as it is
obsolete and has the famous security bug.

For the LCD problem: I'm a bit surprised why it is needed to use LCD data
lines also as input... You should know... but if you depress a button to
ground, how do you want to drive the same line?

And a tip: try to define all variables to be used. E. g.

Instead of

if porta.3 = 0 ...

write

butt VAR porta.3

if butt = 0 ...

I hope I could help you

On Tue, 9 Jun 1998, Peter Cousens wrote:

> Dr. Imre Bartfai wrote:
> >
> > Hi there,
> > I used already its predecessor, the Pbasic. I purchased the PICBasicPro as
> > it came and I find it great (for the sake of truth, there are small bugs,
> > but I know only 2 at a moment and I can tell it in private [or - if there
> > is an interest - public] mail).
>
> I would like to know what bugs you've found
> I have had problems with sleep,
> also with pins ( I now ALWAYS use the full name ie: if portb.3=0
> then.....)
> and also a timing problem, out by a factor of five, (count, rctime or
> pauseus I don't remember ) at 4mhz osc.
>
>
> > I personally has studied the assembly code generated by the
> > PICBasicPRO:
> > it is very tight so one does need to be afraid from overhead.
>
> I am not as happy as you are on this one
> PBP eats up lots of ram (a big problem on 16c84's)
> also PBP has lost a lot of it's automatic functions
> that make stamp/pbc easy.
>
> ie: I have just writen a test program to drive an LCD, I also have
> buttons connected to the LCD data lines (two buttons at the moment
> porta.2/3)
> loop:
> trisa.3=1
> pause 5
> if porta.3=0 then
> lcdout "button depressed"
> endif
>
> result = strange characters on the display ?
> fix    = set the trisa.3=0 before the lcdout
> This should surely be set by the lcdout command !
>
> And as for tight code, this test program has 11 lines
> and outputs only 1 character to the LCD display. ( each character takes
> 2 words )
> It compiles with PBP to 220 words or almost 1/4 of a 16f84 program
> space.
> 22 Words per line ?
>
>
> loop:
> lcdout $fe, 1                        'clear display
> trisa = 1                            'porta set as inputs
> pause 5                              'wait 5ms
> if porta.3 = 0 then                  'test button
> trisa = 0                            'porta set as outputs
> lcdout $fe, $c0                      'go to second line on lcd
> lcdout "D"                           'down button pushed
> pause 1000
> endif
> goto loop
>
> Peter Cousens
> email: peter@cousens.her.forthnet.gr  phone: + 3081 324450, 380534
> snailmail:  Folia, Agia Fotini, Karteros, Heraklion  Crete, Greece.
>
>