Searching \ for '[PIC] Equates or CBlock?' 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=pic
Search entire site for: 'Equates or CBlock?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Equates or CBlock?'
2005\01\22@181501 by Micah Carrick

flavicon
face
Y'all are going to be seeing alot of questions from me in the next week
or two...

I'm trying to figure out when I should use an EQU and when to use the
CBlock.  What is the difference?

2005\01\22@212233 by Daniel Chia

flavicon
face
EQU are equates, which basically assign a constant value to a symbol,
for example

debugPin1 EQU 1

means that whenever you use debugPin1 in your program, it will be
replaced with 1.

Cblock however is used to reserve a block of RAM and to give it a more
meaningful name. Example,

Org (ram address here)

Cblock
myCounter
myCounter2
endc

in the program code you could do inc myCounter or the like, where
myCounter will actually have the address of a slot in RAM. The
allocation is automatic based on where you org -ed the cblock.

------------------------------------------------------------------------
Daniel Chia

"Genius is one percent inspiration and ninety-nine percent
perspiration."

    - Thomas Edison

E-mail: spam_OUTdanielcjhTakeThisOuTspamyahoo.com.sg
MSN: .....danstryder01KILLspamspam@spam@yahoo.com.sg
ICQ: 37878331
------------------------------------------------------------------------


> -----Original Message-----
> From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu] On
Behalf Of
> Micah Carrick
> Sent: 23 January 2005 07:15
> To: EraseMEpiclistspam_OUTspamTakeThisOuTmit.edu
> Subject: [PIC] Equates or CBlock?
>
> Y'all are going to be seeing alot of questions from me in the next
week
> or two...
>
> I'm trying to figure out when I should use an EQU and when to use the
> CBlock.  What is the difference?
> -

2005\01\22@213027 by Hopkins

flavicon
face
I use CBLOCK to reserve memory space for variables that can be referred
to by name ie MOVFW var1

EQU is used for declaring a constant.

Org        0x20                ;or were you want in memory
Test EQU .44        ; Test = decimal 44 - Use MOVLW Test to move .44 into W

Others on the list will suggest using relative addressing were you use
RES instead of CBLOCK but if you have not learnt or do not want to use
relative addressing then I find CBLock and EQU are the way to go.

Note I also use MOVFW and MOVWF - instead of MOV Var,W or Mov Var,F as I
fine it easer to type at the time.

_______________________________________
Roy
Tauranga
New Zealand
_______________________________________

{Original Message removed}

2005\01\22@215001 by Micah Carrick

flavicon
face
Thank you for you help.  So if I understand correctly...

An equate is just a way of defining constants which the compiler will
know to replace the label with the defined constant value anywhere it
sees it in the souce code.

A Cblock actually allocates a block of RAM to store a value and can
therefore be manipulated etc.

Is this correct?

Daniel Chia wrote:

{Quote hidden}

>>{Original Message removed}

2005\01\23@005419 by Daniel Chia
flavicon
face
Yep yep =D
Glad to help

------------------------------------------------------------------------
Daniel Chia

"Genius is one percent inspiration and ninety-nine percent
perspiration."

    - Thomas Edison

E-mail: KILLspamdanielcjhKILLspamspamyahoo.com.sg
MSN: RemoveMEdanstryder01TakeThisOuTspamyahoo.com.sg
ICQ: 37878331
------------------------------------------------------------------------


> {Original Message removed}

2005\01\23@032337 by Roland

flavicon
face
At 10:24 AM 23/01/05 +0800, you wrote:
>EQU are equates, which basically assign a constant value to a symbol,
>for example
>
>debugPin1 EQU 1
>
>means that whenever you use debugPin1 in your program, it will be
>replaced with 1.
>
>Cblock however is used to reserve a block of RAM and to give it a more
>meaningful name. Example,
>
>Org (ram address here)
>
>Cblock
>myCounter
>myCounter2
>endc

Hi Micah,

the code snippets;

Org 0x20
Cblock
myCounter
myCounter2
endc

and

myCounter   EQU 0x20
mycounter2  EQU 0x21

are exactly the same, perform the same function and there is no real reason
to use either.
It's the location of the variable that is constant, not it's contents.
The 'c' in cblock stands for 'constant' anyway.

Sometimes specifying the location of a variable makes it easier to find
when looking at the File registers in Mplab while debugging.
But it's usually not necessary, and is a mission, to define the exact
location of say 50, variables.

Ultimately then, cblock is used for convenience when allocating lots of
variables.


Regards
Roland Jollivet

2005\01\23@063344 by Anthony Van Herrewege

picon face
Hi Roland,
I checked MPASM's help file and it says:
"The value assigned by the equ directive may not be reassigned later."
It also says you have to use the "set" directive when you want to do that, here's an example from the help file:
perimeter set  0        ;The label 'perimeter' is

The value assigned by the set directive may be reassigned later.
lngth     equ  50H      ;The label 'lngth' is assigned the value 50H. wdth      equ  25H      ;The label 'wdth' is assigned the value 25H.


The value assigned by the equ directive may not be reassigned later.
perimeter set  2*(lngth+wdth)  ;Both 'perimeter' andarea      set  lngth*wdth      ;'area' values are reassigned.

So you can't use perimeter equ 5 or something and then use a
formula like the one above, since then you will change the constant,
which is impossible.


(You can find this in the MPASM help file when you search for set,
there's also a link to it in the equ explanation.)


Anthony



Roland <spamBeGonejemelectricspamBeGonespammweb.co.za> wrote:


{Quote hidden}

Website: http://members.lycos.nl/anthonyvh

               
---------------------------------
Do you Yahoo!?
The all-new My Yahoo! – What will yours do

2005\01\23@101718 by Byron A Jeff

face picon face
On Fri, Jan 21, 2005 at 10:42:34PM +0200, Roland wrote:
{Quote hidden}

Not true. With the cblock if you add a label between the two the
assembler will automatically adjust all of the subsequent addresses.
Since the EQU is simply constant assignment, you would either have
to add new labels with addresses at the end, or renumber all
subsequent EQUates to compensate.

If you are programming in absolute mode, the CBLOCK is a much
cleaner interface for variable allocation.

{Quote hidden}

Roland,

I missed something in the statement:

"and there is no real reason to use either."

This implies that there is a third alternative (which there is BTW *)

is what you meant that there's no difference between the two so choose
whichever one you like?

cblock helps the programmer because you no longer have to track the exact
addresses assigned to variables.

* The third option is the RES directive in relocatable mode. Not only does
it autogenerate addresses, the linker will make sure that there's no
address overlap between variables in different modules.

BAJ

2005\01\23@120423 by John Ferrell

face picon face
CBLOCK doe not have to be changed when you port your code to another PIC.
It also makes for easy reading in a couple of years when you want to modify
the code to add a feature.

Daniel Chia's explanation gets a "perfect" from me!

John Ferrell
http://DixieNC.US

----- Original Message -----
From: "Roland" <TakeThisOuTjemelectricEraseMEspamspam_OUTmweb.co.za>
To: "Microcontroller discussion list - Public." <RemoveMEpiclistspamTakeThisOuTmit.edu>
Sent: Friday, January 21, 2005 3:42 PM
Subject: RE: [PIC] Equates or CBlock?



2005\01\24@152712 by Andrew Warren

flavicon
face
Micah Carrick <piclistEraseMEspam.....mit.edu> wrote:

> An equate is just a way of defining constants which the compiler
> will know to replace the label with the defined constant value
> anywhere it sees it in the souce code.
>
> A Cblock actually allocates a block of RAM to store a value and
> can therefore be manipulated etc.
>
> Is this correct?

Micah:

No.

CBLOCK and EQU do the same thing: They assign constant values to
symbols.  "Allocating a block of RAM" is a meaningless concept on the
PIC; CBLOCK is just a syntax that makes the assignment of consecutive
values easier, and makes it simpler to go back and insert or remove
symbols from the list without having to change other lines of code.  

This:

       CBLOCK 20H
   REG1
   REG2,2
   REG3
       ENDC

is equivalent to this:

   POINTER SET 20
   REG1    EQU POINTER
   REG2    EQU REG1+1
   REG3    EQU REG2+2
   POINTER SET REG3+1

And this:

       CBLOCK
   REG4
   REG5,4
       ENDC

is the same as:

   REG4    EQU POINTER
   REG5    EQU REG4+1
   POINTER SET REG5+4

-Andrew

=== Andrew Warren -- EraseMEaiwspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

2005\01\24@165311 by olin_piclist

face picon face
Andrew Warren wrote:
> "Allocating a block of RAM" is a meaningless concept on the
> PIC;

Not at all.  That is precisely what the RES directive is for.

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

2005\01\24@172748 by Byron A Jeff

face picon face
On Mon, Jan 24, 2005 at 04:53:07PM -0500, Olin Lathrop wrote:
> Andrew Warren wrote:
> > "Allocating a block of RAM" is a meaningless concept on the
> > PIC;
>
> Not at all.  That is precisely what the RES directive is for.

Correct. I beleve I pointed that out in my post on the subject.

BAJ

2005\01\24@172821 by Andrew Warren

flavicon
face
Olin Lathrop <RemoveMEpiclistEraseMEspamEraseMEmit.edu> wrote:

> > "Allocating a block of RAM" is a meaningless concept on the PIC;
>
> Not at all.  That is precisely what the RES directive is for.

   I guess... But as long as EQU and CBLOCK can be used in a
   program that also uses RES, the block isn't really "allocated";
   it's just protected from reuse by other RES directives, in the
   same way that registers named using CBLOCK can be kept from
   being renamed by other CBLOCK directives.  

   This is in contrast to what I think of as "real" allocation...
   Which would be the sort of thing you see in high-level
   languages, where (generally speaking) once a variable name is
   declared/used, other variable names will never be assigned to
   the same RAM.

   I see what you mean, though.

   -Andy

=== Andrew Warren -- RemoveMEaiwspam_OUTspamKILLspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

2005\01\24@173916 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Andrew Warren" <RemoveMEaiwTakeThisOuTspamspamcypress.com>
Subject: Re: [PIC] Equates or CBlock?


>     This is in contrast to what I think of as "real" allocation...
>     Which would be the sort of thing you see in high-level
>     languages, where (generally speaking) once a variable name is
>     declared/used, other variable names will never be assigned to
>     the same RAM.

I'm not so sure I see the difference.

The only time memory reserved by a res directive will be re-used for another
variable is when the res directive is in the context of a udata_ovr, where
you are declaring your intention that it be re-used, and have control over
how.  At least some high level languages have a similar capability, or at
least had back when memory was scarce.

--McD


2005\01\24@174958 by Andrew Warren

flavicon
face
John J. McDonough <EraseMEpiclistspamspamspamBeGonemit.edu> wrote:

> The only time memory reserved by a res directive will be re-used
> for another variable is when the res directive is in the context of
> a udata_ovr, where you are declaring your intention that it be
> re-used, and have control over how.

   Right.  As I said, RES-named memory is protected from reuse by
   other RES directives.

   My point, though, was that the memory can always be reused by
   either careless or deliberate use of EQU or CBLOCK... So RES
   affords no more protection than CBLOCK.

   -Andy

=== Andrew Warren -- RemoveMEaiwKILLspamspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

2005\01\24@175223 by Jan-Erik Soderholm

face picon face
John J. McDonough wrote :

> From: "Andrew Warren" <aiwSTOPspamspamspam_OUTcypress.com>
>
> >     This is in contrast to what I think of as "real" allocation...
> >     Which would be the sort of thing you see in high-level
> >     languages, where (generally speaking) once a variable name is
> >     declared/used, other variable names will never be assigned to
> >     the same RAM.
>
> I'm not so sure I see the difference.
>
> The only time memory reserved by a res directive will be
> re-used for another variable is when the res directive is
> in the context of a udata_ovr,...

Or, as Andrew implied (if I'm not wrong ?) if you are EQU'ing the
same RAM address to a symbol and use that one to "re-use" the
same address that was also RES'ed. The address allocated (note
that the MPASM manual exclusivly use the term "reserved", if
it makes any difference) is not "locked" from re-/miss-use by
EQU's and CBLOCK's in the same application.

By *exclusively* using the RES directive for RAM, you should
be safe against that kind of misstakes.

> where you are declaring your intention that it be re-used,
> and have control over how.  At least some high level
> languages have a similar capability, or at
> least had back when memory was scarce.

COMMON blocks in Fortran. Was used to share a common storage
spage (RAM) between different modules/subroutines in the
same app, or between different applications that mapped (linked)
the a "system global" COMMON area. Still useable now when
memory is cheap...

Jan-Erik.



2005\01\24@182631 by olin_piclist

face picon face
Andrew Warren wrote:
>     I guess... But as long as EQU and CBLOCK can be used in a
>     program that also uses RES, the block isn't really "allocated";
>     it's just protected from reuse by other RES directives, in the
>     same way that registers named using CBLOCK can be kept from
>     being renamed by other CBLOCK directives.

The RAM is truly allocated by the linker, and that only happens when you use
RES.  Of course there is nothing preventing you from creating a symbol that
happens to have the value of a RAM address, but that has nothing to do with
allocating the RAM.  This is the distinction between RES on one hand, and
CBLOCK and EQU on the other.  The only reason there is any confusion is
because valid RAM addresses also happen to be integer values that can have
other meanings.

For example, the assembler can't prevent you from doing something boneheaded
like:

 bkcnt  equ  h'20'    ;number of buckets left to fill

because there is no way to tell this inappropriate useage from an
appropriate one such as:

 buckets equ h'20'    ;number of buckets in each tray

And by the way, one CBLOCK statement does not prevent other CBLOCK
statements from assigning the same values to different symbols.  Each CBLOCK
merely assigns sequential values to a list of symbols.  It has absolutely
nothing to do with RAM allocation.

>     This is in contrast to what I think of as "real" allocation...
>     Which would be the sort of thing you see in high-level
>     languages, where (generally speaking) once a variable name is
>     declared/used, other variable names will never be assigned to
>     the same RAM.

But that is exactly what RES does.  It is not possible to RES the same
memory location twice.


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

2005\01\24@183551 by olin_piclist

face picon face
Jan-Erik Soderholm wrote:
> By *exclusively* using the RES directive for RAM, you should
> be safe against that kind of misstakes.

RES is already the *only* means of specifying RAM variables.  The assembler
can't be blamed if some people use EQU to define constants that happen to
have the values overlapping with RAM addresses, then use these constants to
access RAM, because it has no way to know you are misusing the constants in
that way.

Hmm.  That brings up an interesting point.  While the assembler can't tell
the intention of an EQU statement, it can tell how the symbol is used.  It
could and should issue a warning if a symbol defined with EQU or CBLOCK is
used in a context where it's obviously a memory address.  For example:

 myvar  equ    32     ;boneheaded variable definition attempt

        movf   myvar, w ;this could generate a warning


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

2005\01\24@184031 by olin_piclist

face picon face
Andrew Warren wrote:
>     Right.  As I said, RES-named memory is protected from reuse by
>     other RES directives.
>
>     My point, though, was that the memory can always be reused by
>     either careless or deliberate use of EQU or CBLOCK... So RES
>     affords no more protection than CBLOCK.

Yes, assembler is very low level and if you want to go out of your way to
shoot yourself in the foot, you can.  RES affords considerable protection.
The only time RES fails to provide protection is if you try to define
"variables" using EQU or CBLOCK, but that's a pretty unlikely to happen by
accident.


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

2005\01\24@202120 by Andrew Warren

flavicon
face
Olin Lathrop <spamBeGonepiclistSTOPspamspamEraseMEmit.edu> wrote:

> And by the way, one CBLOCK statement does not prevent other CBLOCK
> statements from assigning the same values to different symbols.
> Each CBLOCK merely assigns sequential values to a list of symbols.
> It has absolutely nothing to do with RAM allocation.
> ....
> It is not possible to RES the same memory location twice.

   Sure it is, if you use the UDATA_OVR directive... But you
   wouldn't do that accidentally, any more than you'd accidentally
   enumerate two CBLOCKs at the same value.

   I didn't claim that CBLOCK was always preferable to RES, or that
   CBLOCK "allocates" RAM, or that CBLOCK always prevents
   reassignment of registers.  My only point was that the protection
   from reassignment provided by RES is NO BETTER than what CBLOCK
   offers:

       a) EQUs trump both RES and CBLOCK equally,

       b) both CBLOCK and RES will allow registers to be reassigned
       if the right parameters are used, and

       c) if you don't use those parameters or EQUs, both CBLOCK and
       RES will keep registers from being reassigned.

   -Andy

   P.S.  If I stipulate that there's nothing wrong with using
   relocatable mode assembly, will you stop characterizing all
   register-naming with EQU or CBLOCK as "boneheaded" and a
   "misuse"?  I hope so, because I'm tired and I REALLY don't want
   to spend an hour writing up examples to rebut that
   characterization.

=== Andrew Warren -- KILLspamaiwspamBeGonespamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

2005\01\24@221230 by William Chops Westfield

face picon face

On Jan 24, 2005, at 3:26 PM, Olin Lathrop wrote:

> The RAM is truly allocated by the linker, and
>  that only happens when you use RES.

So we have:
       equ                symbol values assigned by user at asm time
    cblock  symbol values assigned by assembler at asm time
       res                symbol values assigned by linker at link time

Is that correct?  I was having trouble seeing how cblock was different
from RES.

Thanks
BillW

2005\01\24@231453 by Bob Ammerman

picon face
To further muddy this up....

I like to use CBLOCKs to allocate 'enum' style names. A primary example of
this is bit positions in a flags byte:


FLAGS    RES    1

   CBLOCK    0
       FLAG_Happy
       FLAG_Dopey
       FLAG_Doc
       FLAG_Sleepy
   ENDC

or command codes:

   CBLOCK    CMD_Start
      CMD_COPY
      CMD_FETCH
      CMD_STORE

      CMD_End        ; Dummy endmark
   ENDC

CMD_Count = CMD_End - CMD_Min


Bob Ammerman
RAm Systems



{Original Message removed}

2005\01\25@002237 by Tom Smith

flavicon
face
Wouldn't the assembler regard this as indirect addressing?

-----Original Message-----
From: EraseMEpiclist-bouncesspamEraseMEmit.edu [@spam@piclist-bounces@spam@spamspam_OUTmit.edu]On Behalf Of
Olin Lathrop
Sent: Monday, January 24, 2005 6:36 PM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] Equates or CBlock?

Jan-Erik Soderholm wrote:
> By *exclusively* using the RES directive for RAM, you should
> be safe against that kind of misstakes.

RES is already the *only* means of specifying RAM variables.  The assembler
can't be blamed if some people use EQU to define constants that happen to
have the values overlapping with RAM addresses, then use these constants to
access RAM, because it has no way to know you are misusing the constants in
that way.

Hmm.  That brings up an interesting point.  While the assembler can't tell
the intention of an EQU statement, it can tell how the symbol is used.  It
could and should issue a warning if a symbol defined with EQU or CBLOCK is
used in a context where it's obviously a memory address.  For example:

 myvar  equ    32     ;boneheaded variable definition attempt

        movf   myvar, w ;this could generate a warning


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

2005\01\25@031957 by Jan-Erik Soderholm

face picon face
William "Chops" Westfield wrote :

> So we have:

>  equ      symbol values assigned by user at asm time
>  cblock  symbol values assigned by assembler at asm time

And you can freely EUQ or CBLOCK two symbols to have the
same "value". Which is logical. You can say that both symbol
A and B should be, let's say h'00', right ?

>  res      symbol values assigned by linker at link time

And those "values" are always a *real* RAM address. That is the
BIG difference between EUQ/CBLOCK and RES.

And the linker also tags that address as "taken". If you try to
RES'erv another symbol using the same value (or if you run out
of RAM in the actual segment) you will get a linker error.

Note that you normaly (some would say always) would *not*
specify the actual value (address) to the RAM directive, but
let the linker do that (allocating memory or "spreading out
your variables"). The conceptual difference between EUQ and
RES, is that with RES you don't care a bit *what* address
your variables are stored at. You are always referencing it by
name, so why would you care about the actual address ?

> Is that correct?  I was having trouble seeing how cblock was different
> from RES.

The big difference is that with RES you are *specificaly* asking
for a *physical* RAM location (in the address range of the
target PIC model), not only giving a symbol a value, like
EUQ or CBLOCK does.

Note that by using RES, you can easily move your code between
PIC modells and the linker will happily just re-assign your
variable to whatever RAM address is used. No need to "move"
your variables in the source code.

Regards,
Jan-Erik.



2005\01\25@034022 by Andrew Warren

flavicon
face
Chops <spamBeGonepiclistspamKILLspammit.edu> wrote:

> So we have:
>  equ     symbol values assigned by user at asm time
>  cblock  symbol values assigned by assembler at asm time
>  res     symbol values assigned by linker at link time
>
> Is that correct?

Well, kinda...

Except that CBLOCK can be given an initial value, which makes the
values user-assigned.  And RES can, too.  And EQU can be used with
relative expressions rather than absolute numerals, so its values can
be assembler- or linker-assigned.

-Andy

=== Andrew Warren - .....aiwspam_OUTspamcypress.com
===
=== Principal Design Engineer
=== Cypress Semiconductor Corporation


2005\01\25@035149 by Andrew Warren

flavicon
face
Bob Ammerman <TakeThisOuTpiclist.....spamTakeThisOuTmit.edu> wrote:

> I like to use CBLOCKs to allocate 'enum' style names. A primary example
> of this is bit positions in a flags byte:
>
> FLAGS    RES    1
>
>     CBLOCK    0
>         FLAG_Happy
>         FLAG_Dopey
>         FLAG_Doc
>         FLAG_Sleepy
>     ENDC

   Yeah, but isn't #DEFINE a significantly better way to do that?

   If you do it with CBLOCK-assigned bit names, you must remember which
   register holds each flag (I assume that the awkward "FLAG_" prefix
   is there to aid your memory), but if you do it with #DEFINEs, you
   don't have to remember anything:

       #DEFINE HAPPY  FLAGS,0
       #DEFINE DOPEY  FLAGS,1
       #DEFINE DOC    FLAGS,2
       #DEFINE SLEEPY FLAGS,3

       ....

           BSF   HAPPY
           BCF   DOPEY
           BTFSS DOC
           BCF   SLEEPY

   Hmm... I guess you could combine the two... Put all your flags in a
   big CBLOCK list, then do:

       #DEFINE HAPPY  FLAGS,FLAG_Happy
       #DEFINE DOPEY  FLAGS,FLAG_Dopey
       #DEFINE DOC    FLAGS,FLAG_Doc
       #DEFINE SLEEPY FLAGS,FLAG_Sleepy

   It's hard to imagine a scenario in which that would be less trouble
   than it was worth, though.

   -Andy







   

{Quote hidden}

> {Original Message removed}

2005\01\25@040107 by Andrew Warren

flavicon
face
Jan-Erik Soderholm <TakeThisOuTpiclistKILLspamspamspammit.edu> wrote:

> The conceptual difference between EUQ and RES, is that with RES you
> don't care a bit *what* address your variables are stored at. You are
> always referencing it by name, so why would you care about the actual
> address ?

   How's that different from EQU or CBLOCK?  Once an initial value is
   given, there's no need to specify a specific value for any of your
   symbols whether you use RES, EQU, or CBLOCK.

> The big difference is that with RES you are *specificaly* asking for a
> *physical* RAM location (in the address range of the target PIC model),
> not only giving a symbol a value, like EUQ or CBLOCK does.

   The assembler will generate a warning if you try to access a register
   outside the address range of your PIC whether you use RES, EQU, or
   CBLOCK.

> Note that by using RES, you can easily move your code between PIC
> modells and the linker will happily just re-assign your variable to
> whatever RAM address is used. No need to "move" your variables in the
> source code.

   It's just as easy with EQU or CBLOCK, since -- again -- only the
   initial value needs to be given.

   -Andy

=== Andrew Warren - .....aiwspamRemoveMEcypress.com
===
=== Principal Design Engineer
=== Cypress Semiconductor Corporation


2005\01\25@040621 by Andrew Warren

flavicon
face
Andrew Warren <RemoveMEpiclistspamspamBeGonemit.edu> wrote:

> #DEFINE HAPPY  FLAGS,FLAG_Happy
> #DEFINE DOPEY  FLAGS,FLAG_Dopey
> #DEFINE DOC    FLAGS,FLAG_Doc
> #DEFINE SLEEPY FLAGS,FLAG_Sleepy

Bah.  That should have read:

   #DEFINE HAPPY  FLAGS + FLAG_Happy / 8,FLAG_Happy % 8
   #DEFINE DOPEY  FLAGS + FLAG_Dopey / 8,FLAG_Dopey % 8
   #DEFINE DOC    FLAGS + FLAG_Doc / 8,FLAG_Doc % 8
   #DEFINE SLEEPY FLAGS + FLAG_Sleepy / 8,FLAG_Sleepy % 8

-Andy

=== Andrew Warren - spamBeGoneaiw@spam@spamspam_OUTcypress.com
===
=== Principal Design Engineer
=== Cypress Semiconductor Corporation


2005\01\25@044953 by Jan-Erik Soderholm

face picon face
Andrew Warren wrote :

> Jan-Erik Soderholm <TakeThisOuTpiclistspamspammit.edu> wrote:
>
> > The conceptual difference between EUQ and RES, is that
> > with RES you don't care a bit *what* address your variables
> > are stored at. You are always referencing it by name, so
> > why would you care about the actual address ?
>
>     How's that different from EQU or CBLOCK?  Once an initial
>     value is given,...

You are not even *allowed* to give any "initial value" to RES !
(Given that relocatable code mode is used).
*That* is the BIG difference.

With EQU and CBLOCK you *have* to care about your RAM
addresses, even if it's only once in a single place...

(OK, on most 18F PICs, you *could* let your CBLOCK
default to h'00', but that is a very special case... :-) )

>     there's no need to specify a specific value for any of your
>     symbols whether you use RES, EQU, or CBLOCK.

???

According to the MPASM manual :

EQU *needs* a value. It's not optional.

CBLOCK either takes a value, or defaults to one higher then the
previous CBLOCK, or defualts to h'00' if this is the first CBLOCK
in the source file.

RES do not even *allow* you to specify any "value" (in relocatable
code mode).

> > The big difference is that with RES you are *specificaly*
> > asking for a *physical* RAM location (in the address
> > range of the target PIC model),  not only giving a
> > symbol a value, like EUQ or CBLOCK does.
>
> The assembler will generate a warning if you try to
> access a register outside the address range of your
> PIC whether you use RES, EQU, or CBLOCK.

Not if you by accident reads an SFR when you thought you was
reading a GPR. RES protects you against that. EQU and
CBLOCK does not. RES will never allocate an SFR address
if you asked for an address in a GPR linker section.

> > Note that by using RES, you can easily move your code between PIC
> > modells and the linker will happily just re-assign your variable to
> > whatever RAM address is used. No need to "move" your
> > variables in the source code.
>
>     It's just as easy with EQU or CBLOCK, since -- again -- only the
>     initial value needs to be given.

Again, with RES you are not even allowed to specify any "initial value",
just the RAM sections where you want your variables to be
reserved. That will most of the time port to another PIC (at least
in the same "family") without *any* source code changes (with
regard to definitions of your variables). The general RAM sections
in the linker file are called the same (mostly).

Am I missing something fundamentional here ?

Jan-Erik.



2005\01\25@061251 by Alan B. Pearce

face picon face
{Quote hidden}

It seems to me that there are bits being missed in this discussion, which
are fundamental to how the newcomer perceives the different operators, such
as just how and where the location of the RAM addresses is set.

  For EQU the programmer has to keep track of all the addresses. The
assembler has no visibility of what the EQU statement is for other than to
assign a value to a name.

  For CBLOCK the programmer only needs to specify the first RAM address
used in the first CBLOCK statement, and consecutive declarations inside
CBLOCKs then allocate the "next address". The program writer does need to
keep track of when the CBLOCK will overflow a bank though, and this could be
missed which will result in run time errors. This seems to be designed to
assign RAM addresses, but otherwise does seem to be an automated EQU.
However I did like Bob Ammermans use of it to ENUMERATE values, but I prefer
Olins preprocessor macros to achieve the same result as I feel it possibly
documents the result better.

  For RES the programmer does not keep track of where in RAM the location
is, apart from specifying that it be in a named area, but the trick here is
that the named area is declared outside of the RES statement, which is not
intuitive to the beginner. The writer of the LINKER script (could be the
same person as the programmer, but not necessarily) is the one who decides
where the named area goes in RAM, and the programmer only becomes involved
in the loop again if there are link errors, which require re-allocation of
RAM to make the allocations fit the available space. It does produce an
absolute error if there is just not enough RAM, which the other two methods
do not do.

2005\01\25@064502 by Jan-Erik Soderholm

face picon face
Alan B. Pearce wrote :

> The assembler has no visibility of what the EQU statement
> is for other than to assign a value to a name.

Just as CBLOCK.

> For CBLOCK the programmer only needs to specify the first
> RAM address

Rather "first value". There is no given that it's an "RAM address".
It *could* be, just as in the EQU case (where you used the
term "value" anyway) By using different terms ("value" vs. "address")
one could make someone belive that there is a real difference
in this regard between EQU and CBLOCK. Could be nitpicking,
but I feel that clearily counts i this case. :-)

> The program writer does need to keep track of when the
> CBLOCK will overflow a bank though,...

And that the "value" actualy corresponds to a real RAM
in the specific PIC, and not e.g an SFR. Again, just as with EQU.

> However I did like Bob Ammermans use of it to ENUMERATE
> values, but I prefer Olins preprocessor macros to achieve
> the same result...

Which of Olins macros creates enumerated values ?
(I know of the FLAG macros, but that's not the same thing...)

> For RES the programmer does not keep track of where in RAM
> the location is, apart from specifying that it be in a named area,
> but the trick here is that the named area is declared outside of
> the RES statement, which is not intuitive to the beginner.

Not only outside of the RES directive, but outside of the
whole (ASM) source code !

> The writer of the LINKER script (could be the same person as
> the programmer, but not necessarily)...

IMHO, very few have to change the builtin linker scripts as they
are delivered from Microchip. Maybe if you are building a
specialized development environment (as Olin) but not
the normal user developing with MPLAB. IMHO... ;-)

Best Regards,
Jan-Erik.



2005\01\25@080845 by olin_piclist

face picon face
Andrew Warren wrote:
>    If I stipulate that there's nothing wrong with using
>    relocatable mode assembly, will you stop characterizing all
>    register-naming with EQU or CBLOCK as "boneheaded" and a
>    "misuse"?

No, that's not good enough.  It leaves the impression that there is nothing
wrong with absolute mode and defining variable symbols using EQU or CBLOCK.
These are really bad programming practises that are already far too
widespread, partly due to Microchip's own bad examples.  Microchip seems to
have cleaned up their act a bit in the last year or so, but there is still a
large volume of irresponsibly written code out there.  Note that there is no
absolute mode for dsPICs.

A newbie seeing a Microchip example could reasonably conclude that it's the
preferred way of writing code.  Unfortunately this is not true, but this has
nonetheless perpetuated more examples of bad code by others.  Therefore it
is important that those of us who have experience with PIC programming and
understand absolute mode versus relocatable mode and how the linker works (I
include you since you obviously understand this) comment on misuse of EQU
and the like when it comes up.  By not pointing it out, newbies again get
the impression that it's OK, and the problem perpetuates itself.

Unfortunately people tend to cling to what they are comfortable with, even
when a better way is clearly available.  I suppose this has something to do
with the hassle factor of switching from a well used and tweaked routine.
The new way is then treated like a threat instead of an opportunity, and
threat is trashed in the subconsious hope that it will just go away and our
comfortable method won't be obsoleted by the rest of the world.  I don't
have a problem with anyone continuing to use what they are comfortable with,
but it's important that newbies that don't yet have a comfort level
established with any particular method are pointed in the right direction.
Encouraging people to use absolute mode, or even just making it appear OK is
doing them a serious disservice.


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

2005\01\25@081238 by olin_piclist

face picon face
William Chops Westfield wrote:
> So we have:
>
> equ symbol values assigned by user at asm time
> cblock  symbol values assigned by assembler at asm time
> res symbol values assigned by linker at link time
>
> Is that correct?

Yes!  Another important point is that the symbols defined with RES only
refer to RAM locations.  Symbols defined with EQU and CBLOCK are just
ordinary constant with no inherent connection to RAM locations.


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

2005\01\25@082207 by olin_piclist

face picon face
Tom Smith wrote:
>>  myvar  equ    32     ;boneheaded variable definition attempt
>>
>>         movf   myvar, w ;this could generate a warning
>
> Wouldn't the assembler regard this as indirect addressing?

No, there is no such thing as indirect addressing at the assembler level in
MPASM.  The first argument to MOVF (and many other opcodes) is always the
direct RAM address that is coded into the instruction.  Indirect addressing
is done on these PICs by doing accesses to the INDF register, not with
special assembler syntax.  In the case of MOVF INDF,W the address of the
INDF register is coded into the instruction, so the assembler makes no
distinction and doesn't really know about indirect addressing.

(By the way, the dsPICs do have true indirect addressing and special
assembler syntax is used to specify it, but that's not what we are talking
about here.)


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

2005\01\25@084032 by olin_piclist

face picon face
Andrew Warren wrote:
>    Yeah, but isn't #DEFINE a significantly better way to do that?

Maybe specifically for flags, but I think Bob has a valid point in that
CBLOCK is useful for creating an enumerated list of values.

>    If you do it with CBLOCK-assigned bit names, you must remember which
>    register holds each flag (I assume that the awkward "FLAG_" prefix
>    is there to aid your memory), but if you do it with #DEFINEs, you
>    don't have to remember anything:
>
>        #DEFINE HAPPY  FLAGS,0
>        #DEFINE DOPEY  FLAGS,1
>        #DEFINE DOC    FLAGS,2
>        #DEFINE SLEEPY FLAGS,3

This makes accessing the flag with something like a BCF/BSF instruction
easy, but what happens when you have more than 8 flags and you want to
access the byte containing the flags in your code directly, or you need to
know its bank?

{Quote hidden}

That's why I created the /FLAG directive in my preprocessor.  You write one
line of code like:

 /FLAG  happy

and it automatically allocates the next bit in registers names GFL0 - GFLn
and defines several symbols:

 flag_happy  -  String substition for use with BCF/BSF as above

 flag_happy_regn  -  0-N number of the GFLn variable containing flag

 flag_happy_reg  -  Address of the GFLn variable containing flag

 flag_happy_bit  -  0-7 bit number within GFLn variable

The preprocessor is part of my PIC development environment available for
free at http://www.embedinc.com/pic.  You can click on the PREPIC link to
see the documentation file for more details on the /FLAG directive and all
the other things the preprocessor can do.


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

2005\01\25@084329 by olin_piclist

face picon face
Andrew Warren wrote:
>    It's just as easy with EQU or CBLOCK, since -- again -- only the
>    initial value needs to be given.

Not quite.  With CBLOCK, details about the particular processor, like where
RAM starts, appears in the source code.  When using RES, these details
appear in pre-written linker files unique to each PIC.  To rebuild for a
different PIC, you use a different linker file but don't have to go and
change the starting address of variables anywhere in the code.


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

2005\01\25@085214 by Byron A Jeff

face picon face
On Tue, Jan 25, 2005 at 08:12:02AM -0500, Olin Lathrop wrote:
> William Chops Westfield wrote:
> >So we have:
> >
> >equ symbol values assigned by user at asm time
> >cblock  symbol values assigned by assembler at asm time
> >res symbol values assigned by linker at link time
> >
> >Is that correct?
>
> Yes!  Another important point is that the symbols defined with RES only
> refer to RAM locations.  Symbols defined with EQU and CBLOCK are just
> ordinary constant with no inherent connection to RAM locations.

Very true. And when programming in absolute mode I've been bitten by that
fact. When migrating up from the 16F84, whose 1st non SFR RAM location is
at 0x0C IIRC to the 16F877, whose 1st non SFR location is at 0x20.

Nothing about a CBLOCK would alert you to this.

Olin thanks for your very pointed and moving posts on the subject.

Since I have found clear cut examples in the GPUTILS Relocatable Object
Howto located here: http://gputils.sourceforge.net/reloc_howto.html I
guess it's time to start swimming in the deeper end of the pool.

A quick Google located this MPLINK tutorial PDF:

http://www.engj.ulst.ac.uk/sidk/PIC/mplink_tut.pdf

It has a 17C44 target but gets the point across.

BAJ

2005\01\25@085620 by olin_piclist

face picon face
Alan B. Pearce wrote:
>   For CBLOCK the programmer only needs to specify the first RAM address
> used in the first CBLOCK statement, and consecutive declarations inside
> CBLOCKs then allocate the "next address".  The program writer does need
> to keep track of when the CBLOCK will overflow a bank though, and this
> could be missed which will result in run time errors. This seems to be
> designed to assign RAM addresses, but otherwise does seem to be an
> automated EQU.

It may have been originally intended for RAM allocation in absolute mode,
but it *IS* just an automated EQU and it *DOES NOT* assign RAM addresses.

Another drawback to CBLOCK that I think was missed so far is that this
automatic continuation from the previous CBLOCK falls apart if CBLOCK is
used in more than one module to create symbols that are intended to be used
as RAM addresses.  This is seriously dangerous, and you will get no error or
warning from either the assembler or the linker.

> However I did like Bob Ammermans use of it to ENUMERATE
> values, but I prefer Olins preprocessor macros to achieve the same
> result as I feel it possibly documents the result better.

Bob's method is useful for creating sequential enumerated values in general.
My preprocessor only handles the special case when you are trying to create
global one-bit flags.


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

2005\01\25@090723 by Wouter van Ooijen

face picon face
> No, that's not good enough.  It leaves the impression that
> there is nothing wrong with absolute mode and defining
> variable symbols using EQU or CBLOCK.

Nothing wrong with that if used sensibly. You would probably argue that
there is no such thing (sensible use of absolute mode) but I simply
disagree.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\01\25@095311 by Alan B. Pearce

face picon face
I said

>> However I did like Bob Ammermans use of it to ENUMERATE
>> values, but I prefer Olins preprocessor macros to achieve the same
>> result as I feel it possibly documents the result better.

and Olin said

>Bob's method is useful for creating sequential enumerated values in
general.
>My preprocessor only handles the special case when you are trying to create
>global one-bit flags.

Yes but that is what Bob was trying to do in his example, as distinct from
using enumeration to handle a Pascal like statement of ENUM colour (red,
orange, yellow, green)

and Jan-Erik said

>Which of Olins macros creates enumerated values ?
>(I know of the FLAG macros, but that's not the same thing...)

Also the INBIT and OUTBIT macros. The three are very similar, and are the
ones I was thinking of. I grant you that they do not do true enumeration
like I illustrate above, but it is what Bob was illustrating in his example.

2005\01\25@100028 by Alan B. Pearce

face picon face
>> For RES the programmer does not keep track of where in RAM
>> the location is, apart from specifying that it be in a named area,
>> but the trick here is that the named area is declared outside of
>> the RES statement, which is not intuitive to the beginner.

>Not only outside of the RES directive, but outside of the
>whole (ASM) source code !

Not quite so. Within the source file you need

.name udata

     res variable





so that the linker knows what goes into the .name section. On this basis you
are within the source code when telling the linker where to put the
variable. Sure the actual address is defined outside the source code, in the
linker file, but you still need to reference the name for that address.

2005\01\25@104225 by Jan-Erik Soderholm

face picon face
Alan B. Pearce wrote :

> >> For RES the programmer does not keep track of where in RAM
> >> the location is, apart from specifying that it be in a named area,
> >> but the trick here is that the named area is declared outside of
> >> the RES statement, which is not intuitive to the beginner.
>
> >Not only outside of the RES directive, but outside of the
> >whole (ASM) source code !
>
> Not quite so. Within the source file you need
>
> .name udata
>
>       res variable
>

You are right of course !

I was thinking of the actual specification of the (starting)
*address* of the named section used (which is in the linker script).

Sorry...

Jan-Erik.



2005\01\25@114945 by Nathanial Hendler

flavicon
face
On Tue, Jan 25, 2005 at 09:19:57AM +0100, Jan-Erik Soderholm wrote:
> Note that by using RES, you can easily move your code between
> PIC modells and the linker will happily just re-assign your
> variable to whatever RAM address is used. No need to "move"
> your variables in the source code.

One thing that confuses me is how you handle bank switching when you use RES.
How do you know what bank the register you are trying to access is in if you
use RES?  What if you move your code over to a different PIC?

Nathan

2005\01\25@121431 by olin_piclist

face picon face
Nathanial Hendler wrote:
> One thing that confuses me is how you handle bank switching when you
> use RES. How do you know what bank the register you are trying to
> access is in if you use RES?  What if you move your code over to a
> different PIC?

That's a very good question.

The general answer is to use BANKSEL before each reference, but that always
sets all bank bits regardless if their current setting could be known.

What I do is create a separate named linker section in the linker file for
each bank, called ".bank0", ".bank1", etc.  You can then specify the bank to
reserve RAM from, but let the linker allocate it within the bank.

Now take this the next step.  Just specifying .BANK1 UDATA followed by some
RES directives puts the variables into a known bank, but you have to hard
code the bank settings.  Wouldn't it be better if you defined a constant
that specified the bank for local memory in a module, then used that
constant to set the bank in the UDATA directive and also use it to derive
the bank setting runtime code?

This is exactly what I do in my PIC development environment at
http://www.embedinc.com/pic.  Each module generally has an LBANK constant
that defines which bank is used for local state within that module.  LBANK
is used to derive LBANKADR, which is an address within that bank.  LBANKADR
is passed to the DEFRAM macro to define RAM in the selected bank, and is
also passed to the DBANKIF macro in the run time code to set the bank
appropriately for access to the local state.  There are a few more details,
but at this point I refer you to the source code for DEFRAM and DBANKIF in
STD.INS.ASPIC.  You can then take a look at the code in the various template
and example modules.


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

2005\01\25@132411 by Bob Ammerman

picon face

----- Original Message -----
From: "Andrew Warren" <aiwEraseMEspamcypress.com>
To: "Microcontroller discussion list - Public." <RemoveMEpiclistEraseMEspamspam_OUTmit.edu>
Sent: Tuesday, January 25, 2005 3:52 AM
Subject: Re: [PIC] Equates or CBlock?


{Quote hidden}

I like to be able to do things like the following:

   clrf        FLAGS

or:

   movlw    (1<<FLAG_Happy)|(1<<FLAG_Sleepy)|(1<<FLAG_Doc)
   iorwf    FLAGS,f

or:

   movlw    ~((1<<FLAG_Happy)|(1<<FLAG_Sleepy)|(1<<FLAG_Doc))
   andwf    FLAGS,f

I will often have flag bytes allocated to various major subfunctions of the
program:

IOFLAGS        RES    1
CMDFLAGS    RES    1

etc.

I would then typically use names like:

   IOF_Xxxxxx
   CMDF_Yyyyy

for the individual bits.

I find this makes it easier to keep track of what each flag means.

Bob Ammerman
RAm Systems



2005\01\25@144045 by Andrew Warren

flavicon
face
Bob Ammerman <EraseMEpiclistspam@spam@mit.edu> wrote:

> I like to be able to do things like the following

   You can still do those things.

   You can use #DEFINE to create symbols for byte/bit combinations IN
   ADDITION to the symbols you create (using EQU or CBLOCK or whatever)
   for individual bit numbers or bitmasks.

   -Andy

=== Andrew Warren - @spam@aiwspam_OUTspam.....cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation


2005\01\25@164427 by Bob Ammerman

picon face

----- Original Message -----
From: "Andrew Warren" <spamBeGoneaiwEraseMEspamcypress.com>
To: "Microcontroller discussion list - Public." <piclistspamBeGonespammit.edu>
Sent: Tuesday, January 25, 2005 2:41 PM
Subject: Re: [PIC] Equates or CBlock?


{Quote hidden}

Yech!

(no accounting for tastes ;-)

I do wish that MPASM has a token pasting operator for use in macro
definitions. It would allow a lot more powerful macros. There is just so far
you can go with #v(..)

Bob


2005\01\25@172110 by Andrew Warren

flavicon
face
Olin Lathrop <.....piclist@spam@spamEraseMEmit.edu> wrote (I'm combining comments from
multiple posts):

> This is exactly what I do in my PIC development environment at
> http://www.embedinc.com/pic.  Each module generally has an LBANK
> constant that defines which bank is used for local state within that
> module.  LBANK is used to derive LBANKADR, which is an address within
> that bank. LBANKADR is passed to the DEFRAM macro to define RAM in the
> selected bank, and is also passed to the DBANKIF macro in the run time
> code to set the bank appropriately for access to the local state.
> There are a few more details ....

   Be careful, Olin.  Your preprocessor and macro library are getting
   dangerously close to becoming one of those high-level languages that
   you so strongly abhor.  What's the reason you don't like PIC C
   compilers?  Oh, yeah... They insulate the programmer from seeing and
   understanding exactly what's going on at the low level.

> With CBLOCK, details about the particular processor, like where RAM
> starts, appears in the source code.  When using RES, these details
> appear in pre-written linker files unique to each PIC.  To rebuild for
> a different PIC, you use a different linker file but don't have to go
> and change the starting address of variables anywhere in the code.

   Wait.  Are you saying that CBLOCK isn't portable across processors
   because I have to change one constant in my source file, but RES is
   portable because SOMEONE ELSE changed one constant in a separate
   linker file?

> I created the /FLAG directive in my preprocessor.  You write one line
> of code .... and it automatically allocates the next bit in registers
> names GFL0 - GFLn and defines several symbols:
>
> flag_happy - String substition for use with BCF/BSF as above
> flag_happy_regn - 0-N number of the GFLn variable containing flag
> flag_happy_reg - Address of the GFLn variable containing flag
> flag_happy_bit - 0-7 bit number within GFLn variable

   Of course, you could do the same thing with a set of macros using
   #DEFINE and EQU.

> the symbols defined with RES only refer to RAM locations.

   Except in absolute mode, where the symbols defined with RES refer to
   EVERYTHING BUT those RAM locations... But I know what you mean.

> Symbols defined with EQU and CBLOCK are just ordinary constant with no
> inherent connection to RAM locations.

   Correct... But I guess I don't see that the distinction is
   particularly important.  Sure, RES (used correctly, and with the
   appropriate .name section identifiers) keeps an inattentive or
   inexperienced programmer from accidentally locating his variables on
   top of SFRs or at locations that don't exist... But:

       a) CBLOCK and EQU, used with section identifiers no more
       complicated than the .name parameters, can do the same thing.

       b) If we're allowed to use a preprocessor, you could easily
       write one that did all the fancy things your current one does,
       but didn't use a single RES statement and even -- gasp! --
       produced absolute-mode source as its output... Without
       constraining the user in any of the ways that you believe
       directly writing absolute-mode code does.

       c) What's the big deal, anyway?  Symbol naming is done once per
       program; once symbols are defined, they're USED the same way
       whether they're EQUs, #DEFINEs, or RESes.  If errors aren't found
       by the assembler (most are), they'll be found by a one-time look
       at the .LST file.

       d) Choosing the correct RES section-names is just as error-prone as
       choosing the correct CBLOCK initial values, anyway.

> Encouraging people to use absolute mode, or even just making it appear
> OK is doing them a serious disservice.

   Note that I'm NOT making an argument in favor of absolute mode over
   relocatable mode.  Absolute-mode code paid for my house and some
   fast cars in a previous life, so I guess I have a certain fondness
   for it, but I honestly don't care whether anyone else uses it.

   Besides, I have only minor issues with using relocatable mode; my
   feelings about it are CERTAINLY less strong than yours about using
   absolute mode.  My point in all of this is simply that there's NOT
   MUCH DIFFERENCE between using absolute mode and using relocatable
   mode. With a preprocessor similar to yours (or just a good set of
   hard-to-write-but-easy-to-use macros, and programming conventions no
   more strict than those imposed by relocatable mode), absolute mode
   can be more-or-less equivalent to relocatable.

   The arguments posted to the list that compare your full-blown
   relocatable-mode development environment to "baby" absolute mode
   (that is, to absolute mode unassisted by macros, include files, or
   directives with symbolic parameters) are missing the point.  What
   experienced PIC programmer, for instance, would write this?

       VAR1 EQU 0x07 ; NOTE: To port this from the C54 to the C57,
       VAR2 EQU 0x08 ; you'll need to renumber starting from 8.
       VAR3 EQU 0x09 ; Start at 0x0C for the F84, from 0x20 for...
                     ; etc.

   I don't know anyone who would, but I frequently see crap like that
   offered up on the list as an example of what's wrong with absolute
   mode.

   Oh, well.  As I've said before, the fundamental difference between us
   ISN'T that I'm an evangelist for absolute mode while you believe
   relocatable mode is the One True Way.  Rather, it's that I just don't
   see much of a distinction between the two modes, while you have no
   clue what the hell you're talking about, you pinhead.

   Err, that was just a test to see if you managed to grind all the way
   through this long post.  The difference, as I was saying, is that I
   don't see a strong distinction and you do.  Which is fine, of
   course... Vive la difference... But when I see adjectives like
   "boneheaded" and "irresponsible" applied to the way I wrote all my
   PIC code, it's hard for me to restrain myself from replying.

   -Andy

=== Andrew Warren - .....aiwRemoveMEspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation


2005\01\25@174558 by Andrew Warren

flavicon
face
Bob Ammerman <.....piclistSTOPspamspam@spam@mit.edu> wrote:

> > You can use #DEFINE to create symbols for byte/bit combinations
>
> Yech!
>
> (no accounting for tastes ;-)

   The #DEFINE really does have some advantages:  It's impossible to
   accidentally pair the symbol for a bit with the symbol for the wrong
   register (this is by far the most important), you don't have to
   modify your program if you move bits from one register to another,
   you can have shorter bit names since they don't have to include
   mnemonics for their associated registers, and it makes it easier to
   reuse code.

   As you say, though, there's no accounting for taste.  If your way
   works for you, use it.

   -Andy

=== Andrew Warren - aiwEraseMEspam@spam@cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation


2005\01\26@070245 by Howard Winter

face
flavicon
picon face
Bob,

On Tue, 25 Jan 2005 13:20:44 -0500, Bob Ammerman wrote:

> I like to be able to do things like the following:
>
>     clrf        FLAGS
>
> or:
>
>     movlw    (1<<FLAG_Happy)|(1<<FLAG_Sleepy)|(1<<FLAG_Doc)
>     iorwf    FLAGS,f

I can't for the life of me see what you're doing with this one (I must be getting old! :-) - care to explain?

Cheers,


Howard Winter
St.Albans, England


2005\01\26@074715 by Howard Winter

face
flavicon
picon face
Andrew,

On Tue, 25 Jan 2005 14:21:40 -0800, Andrew Warren wrote:

>...<
>     Be careful, Olin.  Your preprocessor and macro library are getting
>     dangerously close to becoming one of those high-level languages that
>     you so strongly abhor.  What's the reason you don't like PIC C
>     compilers?  Oh, yeah... They insulate the programmer from seeing and
>     understanding exactly what's going on at the low level.

LOL!  I have seen places where instead of using the built-in features of the language they are using, they
develop a whole language of their own which is supposed to make things easier.  This is fine for the people
who developed their meta-language and so know it off by heart, but it's a complete pain for newcomers.  I
advised my firm to avoid like the plague a system that they were considering taking on, that did a lot of
accounting for foreign-exchange outlets, because it was written in the meta-language that the "not invented
here" crew had designed.  The net result was that it was unmaintainable by anyone who was not trained first in
the underlying language, and then in the functions that this group of clowns had made up.  So instead of
saying:

PRINT "Hello World"

you had to do something like:

NewPage = 0
NewLine = 1
Font = 0
FontSize = 0
PrintLines = 1
TextLine(1) = "Hello World"
CALL PRINTTEXT

and I'm not exagerating, it really was that bad (they didn't even let you pass parameters to the module, you
had to set them up on advance).  They seemed to think it was quicker and easier to do this sort of thing, for
some strange reason!

Now I'm not saying Olin's preprocessor is like this - I haven't looked at it closely enough to comment - but
there is a tendency to do the sort of thing which can (when taken to extremes) be counter-productive to almost
anyone except the inventor.

>     Wait.  Are you saying that CBLOCK isn't portable across processors
>     because I have to change one constant in my source file, but RES is
>     portable because SOMEONE ELSE changed one constant in a separate
>     linker file?

Yes, but it's done once, already, and doesn't need to be changed, ever!  And if you are using all the memory
in a chip with lots of banking and SFRs scattered around the memory map, you need a number of CBLOCKs to cover
the ground, and they'd all need to be rehashed for any change of processor.  Which means you'd need to keep a
number of different versions of the source code, each having to be maintained into the future, one for each
target processor.

I think Olin's point is that you can reuse the same program on a multitude of different processors by
recompiling/linking, without having to even look into the source code.  If you only ever use one processor
type for each program (which using absolute mode encourages by making it awkward to do otherwise) then this is
a non-issue, but with MChip coming out with new processors at the rate they do (the 18F452 is "mature"
already?  I haven't even started using it yet! :-) and with different memory-maps which seem to depend on the
phase of the Moon when the designers made the decision (!), having the program source as processor-independant
as possible is a Good Thing!

>> the symbols defined with RES only refer to RAM locations.

>     Except in absolute mode, where the symbols defined with RES refer to
>     EVERYTHING BUT those RAM locations... But I know what you mean.

I don't understand this - could you explain?

> > Symbols defined with EQU and CBLOCK are just ordinary constant with no
> > inherent connection to RAM locations.
>
>     Correct... But I guess I don't see that the distinction is
>     particularly important.  

Then you are out of touch with newbies to programming, or old-hands at high level languages who are only just
starting in assembler languages.  To them, the distinction between data values, addresses, pointers and
compile-time constants is confusing enough as it is - trying to say there is no difference is going to really
confuse a lot of people who are trying to learn and understand.  There may not be a difference in the way they
are defined, but understanding differences in their use is vital and non-intuitive.

>...<
>     c) What's the big deal, anyway?  Symbol naming is done once per
>         program; once symbols are defined, they're USED the same way
>         whether they're EQUs, #DEFINEs, or RESes.  If errors aren't found
>         by the assembler (most are), they'll be found by a one-time look
>         at the .LST file.

Symbols defined once are fixed - any change to the environment, or indeed to the program, may make them need
to be changed, and you are advocating doing this by hand.  Minimising the work to do this (especially
eliminating the need all together) makes maintaining and enhancing a program, or porting it to another
environment, easier, quicker, and much less prone to introducing bugs.  And it reduces the amount of
regression testing needed (although not eliminating it, of course!).

>         d) Choosing the correct RES section-names is just as error-prone as
>         choosing the correct CBLOCK initial values, anyway.

Only once - the first clean run proves it's OK with RES, but with CBLOCKs you have an ongoing possibility of
bugs being introduced.

{Quote hidden}

Do you regard helping people understand your code as a bad thing?  If you're writing absolute, explaining
what's going on would seem to be more important when it needs to be changed.  Or do you expect everyone to
have memorised the memory maps of every processor, so they don't need any help?

>...<
>     The difference, as I was saying, is that I
>     don't see a strong distinction and you do.  Which is fine, of
>     course... Vive la difference... But when I see adjectives like
>     "boneheaded" and "irresponsible" applied to the way I wrote all my
>     PIC code, it's hard for me to restrain myself from replying.

Likewise when it appears that you don't "get it"... I suspect that you have written your PIC code yourself,
with nobody having to follow up and change your programs (and vice-versa with you tweaking others' programs)
and perhaps for dedicated projects where the choice of processor was fixed and unchanging.  Otherwise I can't
see why you don't understand the idea of reducing the maintenance load.

I used to tell my programming teams: "Almost every program has much more time spent on it being read, than
being written.  If you save yourself ten seconds typing when you write it, but cost other people 30 seconds
later trying to understand what you did, then you have done a bad job, and I will be down on you like ton of
bricks, after which you will have to do it again, the right way.  So do it right first time!".  This was in an
environment of writing and then supporting commercial systems which were subject to changes and development
throughout their lives, for a multitude of reasons.  Perhaps you come from an environment where "write-only"
programs were the norm, but I don't think that's a good way to train newbies to work!

Cheers,



Howard Winter
St.Albans, England


2005\01\26@074903 by michael brown

picon face



> Bob,
>
> On Tue, 25 Jan 2005 13:20:44 -0500, Bob Ammerman wrote:
>
> > I like to be able to do things like the following:
> >
> >     clrf        FLAGS
> >
> > or:
> >
> >     movlw    (1<<FLAG_Happy)|(1<<FLAG_Sleepy)|(1<<FLAG_Doc)
> >     iorwf    FLAGS,f
>
> I can't for the life of me see what you're doing with this one (I must
be getting old! :-) - care to explain?

He's setting up a bit mask.  Suppose things are like this:
FLAG_Happy  EQU 4
FLAG_Sleepy  EQU 1
FLAG_Doc EQU 0

The assembler will build a literal that consists of a 1 left shifted 4
bits (0x10) AND'd with a 1 left shifted 1 bit (0x02) AND'd with a 1 left
shifted 0 bits (0x01) resulting in a literal with a value of 0x13.  This
is a clever way to help make the program oblivious to absolute bit
positions within the registers assigned to ports.  This way you only
have to change the EQU to change pin assignments, and then recompile.
The assembler will fix the movlw automatically.

2005\01\26@075828 by Michael Rigby-Jones

picon face

{Quote hidden}

Nearly ;) They are actualy OR'd together.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\01\26@081243 by Howard Winter

face
flavicon
picon face
Michael,

On Wed, 26 Jan 2005 06:48:05 -0600, michael brown wrote:

> > >     movlw    (1<<FLAG_Happy)|(1<<FLAG_Sleepy)|(1<<FLAG_Doc)
> > >     iorwf    FLAGS,f
> >
> > I can't for the life of me see what you're doing with this one (I must
> be getting old! :-) - care to explain?
>
> He's setting up a bit mask.
>...<

Ah!  Thanks for that - it's a Demon Tweak that I'd only seen a couple of times and hadn't understood before...

> The assembler will build a literal that consists of a 1 left shifted 4
> bits (0x10) AND'd with a 1 left shifted 1 bit (0x02) AND'd with a 1 left
> shifted 0 bits (0x01) resulting in a literal with a value of 0x13.  This
> is a clever way to help make the program oblivious to absolute bit
> positions within the registers assigned to ports.

...and oblivious to this reader without an explanation - I am getting old, I'm sure :-(

> This way you only
> have to change the EQU to change pin assignments, and then recompile.
> The assembler will fix the movlw automatically.

Got it - thanks muchly!

Cheers,



Howard Winter
St.Albans, England


2005\01\26@081759 by Dennis Crawley

flavicon
face
Howard Winter <spamBeGoneHDRWKILLspamspam@spam@H2Org.demon.co.uk> wrote:
{Quote hidden}

2005\01\26@081805 by Dennis Crawley

flavicon
face
Howard Winter <HDRWspam_OUTspam@spam@H2Org.demon.co.uk> wrote:
> Bob,
>
> On Tue, 25 Jan 2005 13:20:44 -0500, Bob Ammerman wrote:
>
>> I like to be able to do things like the following:
>>
>>     clrf        FLAGS
>>
>> or:
>>
>>     movlw    (1<<FLAG_Happy)|(1<<FLAG_Sleepy)|(1<<FLAG_Doc)
>>     iorwf    FLAGS,f
>
> I can't for the life of me see what you're doing with this one (I
> must be getting old! :-) - care to explain?
>
> Cheers,

<< is called "left shift"
  | is called "bitwise inclusive OR"

If you define the bits, for example,
#define FLAG_Happy 0
#define FLAG_Sleepy 2
#define FLAG_Doc 3

    movlw (1<<FLAG_Happy)|(1<<FLAG_Sleepy)|(1<<FLAG_Doc)
    ;This will set w with 00001101
    ;You don't have to remember the bit position
    ;You can define the bit position whenever you want.

A useful example is when a bit need to be changed regardless its previous
state.

    movlw 1<<FLAG_Happy
    xorwf FLAGS,f


See more in archives.
Dennis Crawley




2005\01\26@081942 by olin_piclist

face picon face
Andrew Warren wrote:
>    Wait.  Are you saying that CBLOCK isn't portable across processors
>    because I have to change one constant in my source file, but RES is
>    portable because SOMEONE ELSE changed one constant in a separate
>    linker file?

Mostly yes.  Switching to a different pre-canned linker file is a necessary
step in switching to a different target PIC, and isn't likely to be
forgotten.  However, it's a lot easier to forget to change the start value
of a CBLOCK, or mess it up.

{Quote hidden}

Not really.  I started trying to do exactly that, but gave up and added the
logic to the preprocessor.  If the MPASM macro processor could accept
arbitrary string arguments then it would be possible, but unfortunately it
doesn't.

>> the symbols defined with RES only refer to RAM locations.
>
>    Except in absolute mode, where the symbols defined with RES refer to
>    EVERYTHING BUT those RAM locations... But I know what you mean.

It was my understanding that RES was only allowed in relocatable mode,
although I'm not where the manual is right now.

>    Correct... But I guess I don't see that the distinction is
>    particularly important.  Sure, RES (used correctly, and with the
>    appropriate .name section identifiers) keeps an inattentive or
>    inexperienced programmer from accidentally locating his variables on
>    top of SFRs or at locations that don't exist... But:
>
>        a) CBLOCK and EQU, used with section identifiers no more
>        complicated than the .name parameters, can do the same thing.

No, they don't.  There is nothing verifying that you haven't run off the end
of a block of RAM.  CBLOCK will happily create over 4 billion values,
whereas with RES the linker will produce an error if an attempt was made to
declare more memory than is available.

>        c) What's the big deal, anyway?  Symbol naming is done once per
>        program;

No, it isn't.  Each module can have local variables.  How do you coordinate
local variable allocation in multiple modules with CBLOCK?

>        d) Choosing the correct RES section-names is just as error-prone
>        as choosing the correct CBLOCK initial values, anyway.

Not really.  If I want a variable in bank 0, I say ".bank0 udata".  This
works for all PICs regardless of the starting address of bank 0 general RAM.
I'm less likely to mess up ".bank0" than to get the starting address wrong,
and ".bank0" doesn't need to change between PICs.

> while you have no clue what the hell you're talking about,
> you pinhead.

ROFL.  I guess that's as good a way as any to end the discussion.


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

2005\01\26@083150 by Bob Ammerman

picon face
> On Tue, 25 Jan 2005 13:20:44 -0500, Bob Ammerman wrote:
>>
>>     movlw    (1<<FLAG_Happy)|(1<<FLAG_Sleepy)|(1<<FLAG_Doc)
>>     iorwf    FLAGS,f
>
> I can't for the life of me see what you're doing with this one (I must be
> getting old! :-) - care to explain?
>
> Cheers,
>
>
> Howard Winter
> St.Albans, England

Sure:

The expression

(1<<FLAG_Happy)|(1<<FLAG_Sleepy)|(1<<FLAG_Doc)

Is computed at assembly time. Each component of the form

1<<FLAG_Xxxxx

evaluates to a single one bit, shifted to the correct location for the
corresponding flag.

Thus

(1<<FLAG_Happy)|(1<<FLAG_Sleepy)|(1<<FLAG_Doc)

is a value with the three flag bits set, and all the other bits clear.

Then the IORWF turns on all three flag bits at once.

Bob Ammerman
RAm Systems


2005\01\26@095354 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Howard Winter" <spamBeGoneHDRW@spam@spamH2Org.demon.co.uk>
Subject: Re: [PIC] Equates or CBlock?

> I think Olin's point is that you can reuse the same program on a
> multitude of different processors by recompiling/linking, without
> having to even look into the source code.  If you only ever use
> one processor  type for each program (which using absolute
> mode encourages by making it awkward to do otherwise) then
> this is  a non-issue,

Not only one processor, but one program.  The processor issue is a nice
advantage, but a tiny one compared to the ease with which code can be
redeployed when using relocatable code and res.

I not only have to fiddle with those cblocks for a new processor.  Really,
that isn't such a big deal.  The 84 starts at 0xc, but most of the others
start at 0x20, so really, you don't mess with the ram addresses all that
often.

No, what is more of a pain is if I have a few subroutines that I want to use
from another program.  I don't know about you, but it's not all that often
that I write something that is 100% new.  Lots of times there are LCD
routines, DDS routines, math routines, conversions, etc. that I did in some
previous program that I need to do in the next program.

With those cblocks I need to rationalize each routine's use of memory with
every other routine.  I have to merge all the cblocks, correct any place
where there are duplicate variable names, figure out which subroutines in
that include file aren't needed, and figure out what memory locations they
use that aren't used by anything else.  Heck, by the time I get done I may
as well have rewritten all the code.

With res and relocatable code I just do

   extern sub

   call sub

or better yet, I put the related routines in a library, write an include
file that contains all the externs, and let the linker figure out which
routines I need out of that mess.  Once I have a set of routines working and
tested, I can keep using them without ever opening up the source again.
That is way more useful than saving some time when I move to a new processor
model.

And it doesn't take all that much work to move from one processor to
another.  With a little thought in working out the library, it can be a
breeze.  I have been working on an LCD library for my PIC course.  Many of
the students are exploring other processors, so I wrote the library to be
useful with most of the 18 pin 16F parts.  (The experimenter board we are
using has an 18 pin socket).  I have tested the library with the 84A, 628,
88, 819 and 648A.  Moving from processor to processor requires changing ONLY
the processor configuration in MPLAB.  No code changes at all are needed
(yes, there are a few IFDEFs in there, but not all that many).  That would
be a nightmare with cblocks.  Yes, the library does need to be reassembled
for different processors, but that isn't a big deal.

Now, if I run into a bunch of cheap 84's like John Mullen, fine, I can use
them.  Need cheap? Use a 628.  Need analog? Use an 819.  Need low power?
Use an 88.  But the code is not an issue AT ALL.

Oh yes, and on a little larger project, you save a lot of time in assembling
all those bits.  Maybe if I could always get it right the first time it
wouldn't be an issue, but I'm not that talented.  I tend to assemble LOTS,
so saving a minute here and there really reduces the frustration.

--McD


2005\01\26@095504 by michael brown

picon face

{Quote hidden}

Double Doh!  That's back to back screw-ups for me.  I'm Mr. Mom this
week, and am just now having my first coffee of the day.  ;-)

2005\01\26@105308 by Jan-Erik Soderholm

face picon face
Olin Lathrop wrote :

> >> the symbols defined with RES only refer to RAM locations.
> >
> >    Except in absolute mode, where the symbols defined with
> >    RES refer to EVERYTHING BUT those RAM locations...
>
> It was my understanding that RES was only allowed in relocatable mode,
> although I'm not where the manual is right now.

You don't need the docs, you have the piclist, right :-) :-)

5.50.1 Syntax

  [<label>] res <mem_units>

5.50.2 Description

  Causes the memory location pointer to be advanced from
  its current location by the value specified in <mem_units>.

  In non-relocatable code, <label> is assumed to be a program
  memory address.

  In relocatable code (using MPLINK), res can also be used to
  reserve data storage. Address locations are defined in words
  for 12-, 14- and 16-bit PICmicros, and bytes for enhanced
  16-bit PICmicros.



Not *that* clear, IMHO...
I can't say that I understand how RES should/could be used
in abs mode.

Jan-Erik.



2005\01\26@112433 by Andrew Warren

flavicon
face
Howard Winter <spamBeGonepiclistspam_OUTspamRemoveMEmit.edu> wrote:

> > What experienced PIC programmer, for instance, would write this?
> >
> >    VAR1 EQU 0x07 ; NOTE: To port this from the C54 to the C57,
> >    VAR2 EQU 0x08 ; you'll need to renumber starting from 8.
> >    VAR3 EQU 0x09 ; Start at 0x0C for the F84, from 0x20 for...
> >                  ; etc.
> >
> > I don't know anyone who would, but I frequently see crap like
> > that offered up on the list as an example of what's wrong with
> > absolute mode.
>
> Do you regard helping people understand your code as a bad thing?  If
> you're writing absolute, explaining what's going on would seem to be
> more important when it needs to be changed.  Or do you expect everyone
> to have memorised the memory maps of every processor, so they don't
> need any help?

   Um, you miss my point.  Or you make it for me...

   The above code could be written something like this:

           CBLOCK Page0_RAM
       VAR1
       VAR2
       VAR3
           ENDC

   The start of Page0 RAM is defined in an "include" file specific to
   each processor.  To port from one processor to another, one need
   only reference a different "include" file.

   -Andy

=== Andrew Warren - .....aiwspamRemoveMEcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation


2005\01\26@113435 by Alan B. Pearce

face picon face
>Not *that* clear, IMHO...
>I can't say that I understand how RES should/could be used
>in abs mode.



Used for allocating buffer areas.

2005\01\26@114233 by John J. McDonough

flavicon
face
----- Original Message -----
Subject: RE: [PIC] Equates or CBlock?


> > It was my understanding that RES was only allowed in relocatable mode,
> > although I'm not where the manual is right now.

Boy have I got a deal for you!

The Elmer 160 lesson on relocatable code is currently being proofread.  I
could use a couple of folks to review it who are not all that familiar with
relocatable code but who might be interested in learning.

The lesson includes four exercise programs, only one of which expects
hardware substantially similar to the PIC-EL.  The other three are conducted
entirely with the MPLAB simulator.  If you have an LCD module and a
soldering iron laying around, it wouldn't be all that tough to hack together
the hardware for the fourth experiment.

If you are interested in exploring relocatable code and don't mind some not
completely ready for prime time prose (although I think it is close), email
me at mcd at is-sixsigma dot com and I will shoot the lesson off to you.  I
would very much appreciate feedback.

--McD


2005\01\26@114411 by John J. McDonough

flavicon
face
----- Original Message -----

> >      What
> >     experienced PIC programmer, for instance, would write this?
> >
> >         VAR1 EQU 0x07 ; NOTE: To port this from the C54 to the C57,

Well, since 99% of the examples on the web presume the F84 is the only
processor you will ever need, why would this be a surprise?

--McD


2005\01\26@130720 by olin_piclist

face picon face
John J. McDonough wrote:
>> It was my understanding that RES was only allowed in relocatable mode,
>> although I'm not where the manual is right now.
>
> Boy have I got a deal for you!
>
> The Elmer 160 lesson on relocatable code is currently being proofread.
> I could use a couple of folks to review it who are not all that
> familiar with relocatable code but who might be interested in learning.

Um, I think you've got the wrong guy.  I'm one of the relocatable mode
evangelists on this list, and have done over 50 PIC projects using it.  When
I first started with PICs a few years ago, I read thru the MPASM manual and
decided just from the documentation that relocatable mode was clearly the
better choice.  I used it from the start and never looked back.  I was one
of the few people here that used to answered questions on relocatable mode.

My confusion with RES was how it worked in absolute mode, which I have no
experience with and can only go by what I remember it said in the manual.  I
thought I had read that RES was not allowed in absolute mode.  Maybe this
was true for an earlier version of MPASM, or maybe I just got it wrong.  In
any case, I think I have a pretty good understanding of how it works in
relocatable mode.


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

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