Searching \ for '[PIC]: simple 16F877 long call strategy needed' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: 'simple 16F877 long call strategy needed'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: simple 16F877 long call strategy needed'
2002\11\12@020043 by Rob Robson

picon face
My first (unsuccessful) attempt to locate some routines on Page 1 and to
call them from Page 0 has sent me scrambling for the datasheets and whatever
other online resources I could find.  There seems be a variety of approaches
to the PCLATH issue, most of which have confused the daylights out of me.
Perhaps someday I'll be up to the more sophisticated techniques (macros,
etc.), but for now, could I not just make every single CALL in my program an
LCALL and call it good?  Would that work, or would that cause the PIC's PC
to go on some unwanted long-call sallies?  As always, I would extremely
grateful for any and all guidance.

Rob Robson

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2002\11\12@040306 by Alan B. Pearce

face picon face
>As always, I would extremely
>grateful for any and all guidance.

Go to http://www.embedinc.com/pic/ and download his development macros.
These take all the hassle out of trying to determine what you should be
doing here. There are also a heap of macros for dealing with the ram bank
issues. Believe me, you will not look back.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2002\11\12@080352 by Olin Lathrop

face picon face
> My first (unsuccessful) attempt to locate some routines on Page 1 and to
> call them from Page 0 has sent me scrambling for the datasheets and
whatever
> other online resources I could find.  There seems be a variety of
approaches
> to the PCLATH issue, most of which have confused the daylights out of
me.
> Perhaps someday I'll be up to the more sophisticated techniques (macros,
> etc.), but for now, could I not just make every single CALL in my
program an
> LCALL and call it good?

LCALL isn't documented in the MPASM manual I have (DS33014G), although it
may be old.

I strongly recommend that you don't just try to cheap out and make this
project work "somehow" quickly instead of sitting down and learning this
right.  You're going to have to do that sooner or later, and the sooner
you do it the more you will benefit from it and the less messy code you
will have around.  Macros ARE a good way of dealing with this issue, and
the macro language is trivial to learn.  You will find them a powerful
tool with many uses.

The convention I use is that PCLATH is always set for the page the current
module is located in, and modules don't cross page boundaries.  That means
I can use GOTOs and CALLs inside a module without having to worry about
PCLATH.  For calling outside a module, I use my GCALL (Global Call) macro.
It sets PCLATH to the target page, and then does a CALL.  Just as
important, on return it restores PCLATH to the local page.

You also need to think about RAM banks.  Take this first project as a
learning exercise and either write out all the paging and banking
instructions or create yourself some dumb macros to help a little.  After
you've attained a good understanding of paging and banking, then you'll be
ready to look at a bunch of more sophisticated macros I have.  You'll find
a whole PIC development environment at http://www.embedinc.com/pic.  It
handles paging, banking, abstraction of I/O pins, portability between
processors, and a few other things in a nice integrated way.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2002\11\12@125125 by Rob Robson

picon face
> Olin Lathrop wrote:
>
> I strongly recommend that you don't just try to cheap out and make this
> project work "somehow" quickly instead of sitting down and learning this
> right.  You're going to have to do that sooner or later, and the sooner
> you do it the more you will benefit from it and the less messy code you
> will have around.  Macros ARE a good way of dealing with this issue, and
> the macro language is trivial to learn.  You will find them a powerful
> tool with many uses.

This has the ring of Good Advice, and I am presently following it (despite
the funhouse challenges posed by some latent dyslexia).  Thanks again for
steering me in the right direction.  By the way, LCALL and LGOTO appear in
the Quick Reference Guide that came with a recent PICSTART Plus, but I
haven't spotted an elaboration on their function elsewhere.  They seem to
take care of PCLATH <4,3> for the initial leap, but don't clean it up again
on RETURN.

Into the Fire Swamp I go.

Rob Robson

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2002\11\12@142130 by Andrew Warren
flavicon
face
Rob Robson <EraseMEPICLISTspam_OUTspamTakeThisOuTmitvma.mit.edu> wrote:

> My first (unsuccessful) attempt to locate some routines on Page 1
> and to call them from Page 0 has sent me scrambling .... could I
> not just make every single CALL in my program an LCALL and call it
> good?  Would that work, or would that cause the PIC's PC to go on
> some unwanted long-call sallies?

Rob:

LCALL will set the PCLATH bits appropriately for the destination of
the CALL, but it won't reset PCLATH after the RETURN.  Therefore,
you'll have to change EVERY ONE of your CALLs and GOTOs to LCALL and
LGOTO.

Macros that adjust PCLATH on both sides of the CALL have been posted
numerous times to the list; I'm sure Olin will post a link to his
macros.

Be careful when using long-call (and long-goto) macros; if you
replace a fragment like:

   BTFSS   PORT,BIT
   CALL    BIT_IS_LO

with:

   BTFSS   PORT,BIT
   XCALL   BIT_IS_LO

your code will break, since that second fragment REALLY says
something like:

   BTFSS   PORT,BIT
   BSF     PCLATH,3
   BCF     PCLATH,4
   CALL    BIT_IS_LO
   BCF     PCLATH,3
   BCF     PCLATH,4

For cases like that, what you really want is:

   BTFSC   PORT,BIT
   GOTO    $+6
   BSF     PCLATH,3
   BCF     PCLATH,4
   CALL    BIT_IS_LO
   BCF     PCLATH,3
   BCF     PCLATH,4

... and the easiest, least-error-prone way to do THAT is to never use
BTFSS/CALL at all; instead, write "LCALLIF" and "LCALLIFNOT" macros
that do the whole thing for you, from the initial BTFSC/BTFSS to the
final PCLATH adjustment.

For a long-call macro to be correct in all cases, it must adjust all
the relevant PCLATH bits, even when only one bit actually NEEDS to be
adjusted.  Just about everyone tries to avoid this by writing a macro
that conditionally includes the second bit-adjustment only if it's
necessary.  Unfortunately, MPASM can't deal with macros that aren't
fixed-length, so the conditional macros don't work.

If you want maximal efficiency, then, you need a whole bunch of
macros, one for each combination of source and destination page.  To
ensure that you never use the wrong one, each macro should include
IF/ERROR lines that check for source and destination pages that match
the ones for which the macro was written, then display an error
message if there's an inconsistency.

Personally, I wouldn't bother maximizing the efficiency for most
projects.  If you're only using two pages, it's pretty easy to
arrange things so very few cross-page calls are necessary; if you're
using more, it usually isn't necessary to squeeze every last byte and
instruction cycle out of your code.

-Andy

=== Andrew Warren -- aiwspamspam_OUTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2002\11\12@142945 by hard Prosser

flavicon
face
I think the lcall "command" is actually a supplied macro. If you
disassemble the assembled program you find that you now have a line
setting/resetting the appropriate PCLATH bit. followed by a line performing
the call itself. This is fine unless you immediately precede the lcall with
a conditional skip instruction. In this event you only skip the bit
set/clear command but still execute the call (to a local address).

Things can get very confusing & hard to figure what's gone wrong. (I found
this (eventually) the hard way!)

I find it better to avoid the lcall etc. "commands" and  use an obvious
macro. - or just set/clear the PCLATH bit manually.

Richard P



My first (unsuccessful) attempt to locate some routines on Page 1 and to
call them from Page 0 has sent me scrambling for the datasheets and
whatever
other online resources I could find.  There seems be a variety of
approaches
to the PCLATH issue, most of which have confused the daylights out of me.
Perhaps someday I'll be up to the more sophisticated techniques (macros,
etc.), but for now, could I not just make every single CALL in my program
an
LCALL and call it good?  Would that work, or would that cause the PIC's PC
to go on some unwanted long-call sallies?  As always, I would extremely
grateful for any and all guidance.

Rob Robson

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2002\11\12@154456 by Olin Lathrop

face picon face
> Unfortunately, MPASM can't deal with macros that aren't
> fixed-length, so the conditional macros don't work.

Huh!?  I have many macros that result in varying numbers of instructions
depending on assembly time state.  One example is the DBANKIF macro in
STD.INS.ASPIC at http://www.embedinc.com/pic.  It generates, 0, 1 or 2 bit
setting instructions depending on the old and new register bank settings.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2002\11\12@163002 by Andrew Warren

flavicon
face
Olin Lathrop <TakeThisOuTPICLISTEraseMEspamspam_OUTmitvma.mit.edu> wrote:

> > Unfortunately, MPASM can't deal with macros that aren't
> > fixed-length, so the conditional macros don't work.
>
> Huh!?  I have many macros that result in varying numbers of instructions
> depending on assembly time state.  One example is the DBANKIF macro in
> STD.INS.ASPIC at http://www.embedinc.com/pic.  It generates, 0, 1 or 2 bit
> setting instructions depending on the old and new register bank settings.

   Good point.  Let me rephrase:

       Unfortunately, MPASM can't deal with macros that aren't
       fixed-length.  Fortunately, however, Microchip now include a
       separate linker with their dev tools, so if you're one of
       those people who use MPLINK, you can go ahead and write all
       the varying-length macros that you want.

       You kids today have it so easy...

   -Andy

=== Andrew Warren -- RemoveMEaiwspamTakeThisOuTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu


2002\11\12@164422 by Wouter van Ooijen

face picon face
> Good point.  Let me rephrase:
> Unfortunately, MPASM can't deal with macros that aren't
> fixed-length.

I still don't understand what you mean. And what do you mean by length
anay, the number of instructions that are generated? MPASM deals
perfectly with macro's that generate a number of instructions that
varies, depending for instance on macro parameters, the current
location, global settings etc. I can not handle macro's that create a
varying number of instructions depending on the pass (pass 1 or pass 2,
yes, such macro's can be written!), but I guess no two-pass assembler
can.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu


2002\11\12@172843 by Olin Lathrop

face picon face
>         Unfortunately, MPASM can't deal with macros that aren't
>         fixed-length.  Fortunately, however, Microchip now include a
>         separate linker with their dev tools, so if you're one of
>         those people who use MPLINK, you can go ahead and write all
>         the varying-length macros that you want.

Everyone should be using the linker.  Talking about absolute mode here is
just a waste of bandwidth and does a disservice to newbies who might get
the impression it is a reasonable option.  Unfortunately many Microchip
examples still use the archaic absolute mode, which gives the impression
that it's the preferred way to use MPLAB.  It's not.  Relocatable mode
allows you to write much cleaner software, takes about the same effort to
learn, but makes writing the code easier and less error prone.

This issue only comes up because there is an absolute mode, which is there
for historic reasons.  Relocatable code using a linker is the normal way
to do software development in general.  Nobody complains that all Windows
development uses relocatable objects.  It's just the way it's done.
Microchip would do a big service if they supported absolute mode only with
a special -OLD command line option and said it was not recommended for new
designs.

I know I've probably offended some people that still cling to absolute
mode because relocatable mode is "too hard to learn".  Usually this means
they haven't really looked at it and are using absolute mode from long ago
and feel threatened by the "new" stuff.  In reality, all instructions are
the same, and most directives too.  Some directives have different names
(CODE instead of ORG), but work pretty much the same way.  Then there are
things that make relocatable mode easier to write, like separate modules
each with its own namespace, properly working macros (I didn't know about
the fixed size limitation before), no page boundaries within a module, and
no more manually trying to fit various routines into specific pages.  All
in all, relocatable mode is clearly better and a little easier than
absolute mode.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu


2002\11\12@173050 by Andy Kunz

flavicon
face
Olin's right.  Use C and you won't know the difference.

Andy


At 05:28 PM 11/12/02 -0500, you wrote:
{Quote hidden}

-------------------------------------------------------------------
Race Boats  - RemoveMEandyTakeThisOuTspamspamRC-Hydros.com      http://www.RC-Hydros.com
Airplanes   - EraseMEandyspamspamspamBeGoneFlyingHobbies.com  http://www.FlyingHobbies.com
Electronics - RemoveMEandyKILLspamspamMontanaDesign.com  http://www.MontanaDesign.com
-------------------------------------------------------------------

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspamspamspam_OUTmitvma.mit.edu


2002\11\12@182428 by Andrew Warren

flavicon
face
Wouter van Ooijen <spamBeGonePICLISTSTOPspamspamEraseMEmitvma.mit.edu> wrote:

> > Unfortunately, MPASM can't deal with macros that aren't
> > fixed-length.
>
> I still don't understand what you mean .... MPASM deals perfectly
> with macro's that generate a number of instructions that varies
> [but it] can not handle macro's that create a varying number of
> instructions depending on the pass

Wouter:

Actually, you clearly DO understand what I mean, even though I
phrased it much more poorly than you did.

-Andrew


=== Andrew Warren -- KILLspamaiwspamBeGonespamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamEraseMEmitvma.mit.edu


2002\11\12@182430 by William Chops Westfield

face picon face
       Unfortunately, MPASM can't deal with macros that aren't
       fixed-length.

I still don't get it?  Most macro assemblers have problems with macros that
evaluate to different lengths during different assembler passes due to
unresolved forward references (or values that change) during the first pass
(and most assemblers have two passes), but that's a pretty small subset of
"macros that aren't fixed length"...

I CAN do something like this, right:

mystring macro text
       dt text
endm

Isn't that a non-fixed-length macro?

BillW

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu


2002\11\12@191958 by Bob Ammerman

picon face
> For a long-call macro to be correct in all cases, it must adjust all
> the relevant PCLATH bits, even when only one bit actually NEEDS to be
> adjusted.  Just about everyone tries to avoid this by writing a macro
> that conditionally includes the second bit-adjustment only if it's
> necessary.  Unfortunately, MPASM can't deal with macros that aren't
> fixed-length, so the conditional macros don't work.

Actually, MPASM will work just fine with conditional (variable size) macros,
as long as the code expands to the same number of instructions on both
assembly passes for any given invocation of hte macro. The problem with most
schemes to generate optimized long calls is that, on the first pass, all the
target addresses are seen as being zero if they haven't beend defined yet.

One way around this is to define symbols at the front of your code
identifying the page that each routine is going to be in:

P_Routine1 = 0
P_Routine2 = 1

etc.

Then your LCALL macro takes two arguments:

   LCALL    Routine1,P_Routine1

It can use the second argument to determine what has to be done to PCLATH.

Finally, you use a macro to define the entry point of the subroutine:

   ENTPT    Routine1,P_Routine1

which defines the entry point, and also verifies that it is indeed in the
page that the P_Xxxxx symbol indicated it would be in.

Note that none of this magic is likely to work when using the linker.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2002\11\12@193042 by Bob Blick

face picon face
On Tue, 12 Nov 2002, Bob Ammerman wrote:
> Note that none of this magic is likely to work when using the linker.

Ahh, wizards and muggles again!

-Bob

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspam_OUTspammitvma.mit.edu


2002\11\12@193905 by Bob Ammerman

picon face
Olin,

I know you go on and on about using the linker. However, I have recently
done one job on an '876 that just plain would not have worked using a
linker. Timing was very tight and I had to carefully place code in just the
right places so that PCLATH would be set up right at various points. Note
that I don't just mean in the right 2K pages which would be reasonable with
the linker, but actually aligning code properly across 256-byte boundaries.
With a little discipline it really isn't that hard to manage.

btw: as I mentioned in a previous post, variable length macros is not a
function of whether or not you use the linker, but rather whether the macros
expand to the same size on both assembly passes.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-request.....spamTakeThisOuTmitvma.mit.edu


2002\11\12@194612 by Bob Ammerman

picon face
Ah, but which is which??

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Bob Blick" <TakeThisOuTbblickKILLspamspamspamSONIC.NET>
To: <.....PICLISTspamRemoveMEMITVMA.MIT.EDU>
Sent: Tuesday, November 12, 2002 7:28 PM
Subject: Re: [PIC]: simple 16F877 long call strategy needed


{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu


2002\11\12@200604 by Andy Kunz

flavicon
face
I see where you're coming from, Bob.  A sledge hammer isn't the right tool
for finishing trimwork.

The right tool for the job.  What a concept!

Andy


At 07:35 PM 11/12/02 -0500, you wrote:
{Quote hidden}

-------------------------------------------------------------------
Race Boats  - andyEraseMEspamRC-Hydros.com      http://www.RC-Hydros.com
Airplanes   - RemoveMEandyEraseMEspamspam_OUTFlyingHobbies.com  http://www.FlyingHobbies.com
Electronics - @spam@andyRemoveMEspamEraseMEMontanaDesign.com  http://www.MontanaDesign.com
-------------------------------------------------------------------

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam@spam@mitvma.mit.edu


2002\11\12@200616 by Bob Blick

face picon face
You've been at wizard level as long as I can remember!

-Bob Blick

On Tue, 12 Nov 2002, Bob Ammerman wrote:

> Ah, but which is which??
>
> Bob Ammerman
> RAm Systems
>
> {Original Message removed}

2002\11\13@024522 by Wouter van Ooijen

face picon face
> Actually, you clearly DO understand what I mean, even though I
> phrased it much more poorly than you did.

That makes me curious! Which assemblers do you know that can handle such
things, how do they handle it (varying number of passes?).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@025349 by Sergio Masci

picon face
----- Original Message -----
From: Andy Kunz <@spam@montanaspam_OUTspam.....FAST.NET>
To: <spamBeGonePICLISTEraseMEspamMITVMA.MIT.EDU>
Sent: Tuesday, November 12, 2002 10:30 PM
Subject: Re: [PIC]: simple 16F877 long call strategy needed


> Olin's right.  Use C and you won't know the difference.
>
> Andy

Actually the next version of the xcasm assembler (which is due for imminent
release) will automatically generate RAM (data) and ROM (code) paging
instructions if enabled. It analyses the generated code and inserts the
minimum number of instructions necessary to maintain the correct pages. You
could liken this to some kind of intelligent link phase except that by doing
it in the assembler you actually get tight control from within the assembler
which allows further optimisation. Below is an example of a short section of
assembler which decides which RAM page to put a data section into. By doing
this within the assembler, any macros used can take advantage of knowing
where the data is located (user written macros can take advantage of fixed
addresses and constants when generating code - yes the assembler can cope
with variable length output from macros). The automatic paging further
benefits from this feedback.

Regards
Sergio Masci
http://www.xcprod.com

;----------------------

The following section of assembler is generated by the XCSB compiler and fed
straight into the XCASM assembler. It allows the assembler to directly
decide in which RAM page to place some floating point variables used by some
floating point macros (yes the assembler handles floating point numbers as
well).

    .sect  prog_data2_group_base_sect

    .org  0xA0

    .group  prog_data2_group,  prog_data2_group_base_sect


xgroup_val  .set  0
    .if DEFINED("prog_data_group")
xgroup_val  .set  GROUP_SIZE("prog_data_group")
    .endif


    .if  DEFINED("code_gen_data_sect")
xsect_val  .set  SECT_SIZE("code_gen_data_sect")
    .if  xgroup_val + xsect_val < 0x70
            .group  prog_data_group,  code_gen_data_sect
xgroup_val  .set  xgroup_val+xsect_val
    .else
            .group  prog_data2_group,  code_gen_data_sect
.endif
.endif


    .if  DEFINED("code_gen_fp_data_sect")
xsect_val  .set  SECT_SIZE("code_gen_fp_data_sect")
    .if  xgroup_val + xsect_val < 0x70
            .group  prog_data_group,  code_gen_fp_data_sect
xgroup_val  .set  xgroup_val+xsect_val
    .else
            .group  prog_data2_group,  code_gen_fp_data_sect
    .endif
    .endif

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@030955 by Sergio Masci

picon face
----- Original Message -----
From: William Chops Westfield <billwspamBeGonespamCISCO.COM>
To: <RemoveMEPICLIST@spam@spamspamBeGoneMITVMA.MIT.EDU>
Sent: Tuesday, November 12, 2002 11:22 PM
Subject: Re: [PIC]: simple 16F877 long call strategy needed


>         Unfortunately, MPASM can't deal with macros that aren't
>         fixed-length.
>
> I still don't get it?  Most macro assemblers have problems with macros
that
> evaluate to different lengths during different assembler passes due to
> unresolved forward references (or values that change) during the first
pass
{Quote hidden}

A variable length macro would by something like

st16    .macro    dst, arg

       .if    (arg & $ff) == 0
       clrf    dst+0
       .else
       movlw    arg & $ff
       movwf    dst+0
       .endif

       .if    (arg & $ff00) == 0
       clrf    dst+1
       .else
       movlw    (arg >> 8) & $ff
       movwf    dst+1
       .endif

       .endm

calling st16 with an undefined label (a forward reference) would result in
zero the first time round (generating two instructions the first time) and
then a non zero the second time round (generating three or four instructions
the second time)

Regards
Sergio Masci
http://www.xcprod.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@031156 by Roman Black

flavicon
face
Olin Lathrop wrote:
>
> >         Unfortunately, MPASM can't deal with macros that aren't
> >         fixed-length.  Fortunately, however, Microchip now include a
> >         separate linker
>
> Everyone should be using the linker.  Talking about absolute mode here is
> just a waste of bandwidth and does a disservice to newbies


SURELY that decision should be left to the
majority, and *maybe* that majority are still
using (and prefer) absolute mode?? ;o)

For the "control freaks" like myself there is
little alternative to absolute mode, how else
to you get the absolute maximum amount of code
into that 512 bytes of ROM? Many of my projects
use very carefully designed code blocks and tables
and need to have every word in the right spot to
get the speed and size...

I do understand the benefits of linked and
re-usable modules in LARGER projects where they
are very superior. But as the PIC size gets
smaller and development time becomes less critical
than PIC size, a point is reached where absolute
mode gives the BEST end result.

As a consultant it benefits you to develop code
very quickly using a "standard" larger PIC and
linked modules. But as a manufacturer it benefits
me to use the SMALLEST PIC possible even it takes
weeks of fiddly absolute coding to make it all fit.

Saying cars are better than motorcycles is a rather
closed minded attitude. Next you'll be saying talking
about 16F PICs is "doing newbies a disservice" as
they should be learining on 18F, heck why stop
there, they should be soldering Pentiums into their
led flasher and we can all throw our PICs away. <grin>
-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@040445 by Michael Rigby-Jones

picon face
{Quote hidden}

The point that Olin made was that if the majority are using absolute mode,
it's most likely due to the perceived complexity of writing relocatable code
and using the linker.

Of course I agree that you should use the right tools for the job, and in a
few cases relocatable code may not be the best solution.  However, for many
projects it is, and I agree that it's worth learning.

Regards

Mike

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@040652 by Alan B. Pearce

face picon face
>That makes me curious! Which assemblers do you know
>that can handle such things, how do they handle it
>(varying number of passes?).

Well I have heard of assemblers (mini or mainframe based IIRC) which would
do more then two passes to do the best optimisation. IIRC figures like 8
passes spring to mind, with it being able to do more if necessary, and a
maximum being command line specified to stop infinite loops on the pass
count.

Also I'm not sure that the original Intel Macro86 assembler did not do
multiple passes (more than 2) to handle the optimisation of short/long jumps
and calls.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@073734 by Olin Lathrop

face picon face
> One way around this is to define symbols at the front of your code
> identifying the page that each routine is going to be in:
>
> P_Routine1 = 0
> P_Routine2 = 1
>
> ...
>
> Note that none of this magic is likely to work when using the linker.

No, it would work better.  You define the P_xxx constants in an include
file, then use them to guarantee each routine is placed onto the chosen
page.  Your ENTPT macro then doesn't need to verify that it is on the
right page, it puts it on the right page.

Here is what some of the code would look like assuming linker sections
called .PAGEn where N is the page number:

p_suba     equ    0 ;set page for SUBA

.page#v(p_suba) code
suba
 <body of SUBA goes here>

I actually use a very similar scheme for placing variable in specific
banks, but otherwise let the linker allocate memory within the bank.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@075017 by Olin Lathrop

face picon face
> I know you go on and on about using the linker. However, I have recently
> done one job on an '876 that just plain would not have worked using a
> linker.

I don't believe that.  How familiar are you with the linker, Bob?  There
seem to be a lot of myths out there about relocatable mode that just
aren't true.  I suspect that you haven't used the linker much (at all?)
and therefore aren't aware of all the things you can do in relocatable
mode.  One way to think of it is that relocatable mode is a superset of
absolute mode.  If you want to specify every last address, you can.
However, for the vast majority of cases when you don't care, you can let
the linker do it's allocation magic.  In either case you still get nice
things like private name spaces for each module.

> Timing was very tight and I had to carefully place code in just the
> right places so that PCLATH would be set up right at various points.
Note
> that I don't just mean in the right 2K pages which would be reasonable
with
> the linker, but actually aligning code properly across 256-byte
boundaries.

Of course you can do this in relocatable mode.  You can hard wire any
section to a specific address if you wish.  I've occasionally had tables
and critical routines that I stuck at specific addresses just like what
you're talking about.  I bet that you only needed a small subset of your
code at known addresses, and could have let the linker place the rest
wherever is wanted to.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@080436 by Olin Lathrop

face picon face
> For the "control freaks" like myself there is
> little alternative to absolute mode, how else
> to you get the absolute maximum amount of code
> into that 512 bytes of ROM? Many of my projects
> use very carefully designed code blocks and tables
> and need to have every word in the right spot to
> get the speed and size...

This seems to be Standard Linker Myth #1 again.  See my response to Bob.

> I do understand the benefits of linked and
> re-usable modules in LARGER projects where they
> are very superior. But as the PIC size gets
> smaller and development time becomes less critical
> than PIC size, a point is reached where absolute
> mode gives the BEST end result.

Again, same argument same response.

> As a consultant it benefits you to develop code
> very quickly using a "standard" larger PIC and
> linked modules. But as a manufacturer it benefits
> me to use the SMALLEST PIC possible even it takes
> weeks of fiddly absolute coding to make it all fit.

Some of my projects are high volume too.  In some cases I have to give the
linker a little less freedom, but I only need to do that in those cases
where it matters.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@085116 by Bob Ammerman

picon face
Bob stated:
> > I know you go on and on about using the linker. However, I have recently
> > done one job on an '876 that just plain would not have worked using a
> > linker.

Olin replied:
> I don't believe that.  How familiar are you with the linker, Bob?  There
> seem to be a lot of myths out there about relocatable mode that just
> aren't true.  I suspect that you haven't used the linker much (at all?)
> and therefore aren't aware of all the things you can do in relocatable
> mode.  One way to think of it is that relocatable mode is a superset of
> absolute mode.  If you want to specify every last address, you can.
> However, for the vast majority of cases when you don't care, you can let
> the linker do it's allocation magic.  In either case you still get nice
> things like private name spaces for each module.

Ok,

Let me rephrase. Yes, it would have worked using the linker, but it would
have involved a lot of fussing with the .LKR file. Sometimes several code
pieces were carefully packed into single 256-word chunks (so that I could
run state machines by simply copying state values toPCL). Other chunks  just
had to fit within the same 2K page as the state machines they supported. In
some cases I had to ensure that several distinct 256-word chunks, each
containing the code for one or more state machines all were within the same
2K page. I was able to ensure that everything fit where it was supposed to
by using appropriate IF checks in the asm code.

And, btw, not using the linker doesn't mean you can't modularize (although
you lose scoping of variables).

> I bet that you only needed a small subset of your
> code at known addresses, and could have let the linker place the rest
> wherever is wanted to.

Actually, most of the code had to be carefully laid out.

Again, not to say the linker isn't wonderful (it is), but it is not a
panacea, and is not _always_ the right answer.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@092254 by Olin Lathrop

face picon face
part 1 1567 bytes content-type:text/plain; (decoded 7bit)

> Let me rephrase. Yes, it would have worked using the linker, but it
would
> have involved a lot of fussing with the .LKR file.

I don't see anything in your description that would require this.  I've
attached my standard linker control file for the 16F876, which creates a
separate section for each page.  By the way, all my linker control files
are available in the PIC development tools download at
http://www.embedinc.com/pic/dload.htm.

> Sometimes several code
> pieces were carefully packed into single 256-word chunks (so that I
could
> run state machines by simply copying state values toPCL). Other chunks
just
> had to fit within the same 2K page as the state machines they supported.
In
> some cases I had to ensure that several distinct 256-word chunks, each
> containing the code for one or more state machines all were within the
same
> 2K page. I was able to ensure that everything fit where it was supposed
to
> by using appropriate IF checks in the asm code.

;   This module contains blocks of instructions that need
;   to be in the same 256-word block, and all these blocks
;   need to be on the same code page.
;
bstart   set  h'0800'     ;start the blocks here (start of page 1)
;
;   Block 1
;
.block1  code bstart
        <code for block 1>
 if ($ - bstart) > 256
        error  "Block 1 larger than 256 words"
   endif
bstart   set  bstart + 256 ;make start address for next block
;
;   Block 2
;
.block2  code bstart
        .
        .
        .


part 2 1327 bytes content-type:application/octet-stream; (decode)

part 3 328 bytes

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@113235 by William Chops Westfield

face picon face
So the linker will do variable-length bank/page fixups for you?  That's a bit
scary.  Does it do a good job?

BillW

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@114517 by Olin Lathrop

face picon face
> So the linker will do variable-length bank/page fixups for you?

I don't know where you got that idea from, but no.  This linker is on the
dumb side as linkers go, but it still beats using absolute mode.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\11\13@135346 by Mike Singer

picon face
Roman Black wrote:
> > Everyone should be using the linker.  Talking
> > about absolute mode here is just a waste of
> > bandwidth and does a disservice to newbies
>
> SURELY that decision should be left to the
> majority, and *maybe* that majority are still
> using (and prefer) absolute mode?? ;o)

  "Majority" things can't determine the best practice, I think.

> Saying cars are better than motorcycles is a rather
> closed minded attitude. Next you'll be saying talking
> about 16F PICs is "doing newbies a disservice" as
> they should be learining on 18F, heck why stop
> there, they should be soldering Pentiums into their
> led flasher and we can all throw our PICs away. <grin>

  Actually, as for me, he said " Everyone should be
 using modern vehicle, not horses".
  Talking about 16F PICs is really "doing newbies a
disservice", in my opinion and for newbies only, of
course. 18 pins 18F are coming. The 8-bit core must
be the same in all the Microchip 8-bit controllers and
in learning process as well. Can't see reasons why
18F shouldn't be cheaper then 12-16F.

  Best regards.
  Mike.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...