PIC EQU section.

[ian field]

In a sample fragment of code (EQU section) of a program example from the
book PIC in Practice:


TMR0 EQU 1 ;TMR0 is FILE 1.
PORTA EQU 5 ;PORTA is FILE 5.
PORTB EQU 6 ;PORTB is FILE 6.
STATUS EQU 3 ;STATUS is FILE3.
ZEROBIT EQU 2 ;ZEROBIT is Bit 2.
COUNT EQU 0CH ;USER RAM LOCATION.
EEADR EQU 9 ;EEPROM address register
EEDATA EQU 8 ;EEPROM data register
EECON1 EQU 8 ;EEPROM control register1
EECON2 EQU 9 ;EEPROM control register2
RD EQU 0 ;read bit in EECON1
WR EQU 1 ;Write bit in EECON1
WREN EQU 2 ;Write enable bit in EECON1

How does the assembler tell the difference between a file and a bit?

The lines starting with ZEROBIT and WREN do not seem to have anything to
distinguish them from file EQUs.

TIA.

 

[Greg Neill]

Yes - I know what the EQU section does, but how does the assembler
know "ZEROBIT EQU 2 ;Zerobit is bit 2" means a bit and not a
file - especially when nothing specifies which file it means bit 2 of?

It doesn't know anything about bits or files. All it
knows is that you have assigned the constant 2 to a
symbol ZEROBIT. It doesn't know or care what you
subsequently do with that symbol.

However... when it comes across that symbol in code
that you write (code that generates instruction
sequences), it will substitute the number 2 for the
symbol in the context in which it is found. It's up
to you to use the symbol in the appropriate context.

 

[ian field]

Ian,

In the case of the equates, all the program is saying is that there is a
variable named ZEROBIT and you have assigned the value of 2 to it. The
comment tells you a little about what the programmer intends to use it for
(bit 2 of some register is going to be used as the zero bit).

The WREN variable is assigned a value of 2 and the programmer uses it to
describe a particular bit (write enable) in the EECON1 register. If you
look at the datasheet for the PIC being used, bit 2 of the EECON1 register
is probably called WREN and is the EEPROM Write Control bit.

Somewhere in the rest of the program, you'll find how the programmer used
thes equates.

A lot of what I see in the equates you provided looks like stuff that
could also be in an include file. Something like
#include "p16f88.inc"
sometimes covers all these type of assignments.

The author of the book this came from has opted to write his own .inc files
to replace the ones supplied by Microchip, except they have an .asm
extension and each is used as a template to which the program code is added
for a variety of programming examples.

From what I'd read, the label names were completely arbitrary - "ZEROBIT"
could be called whatever you want as long as consistency was maintained
throughout - if I'm wrong about that it probably answers my question.

 

[Tom2000]

It doesn't know anything about bits or files. All it
knows is that you have assigned the constant 2 to a
symbol ZEROBIT. It doesn't know or care what you
subsequently do with that symbol.

However... when it comes across that symbol in code
that you write (code that generates instruction
sequences), it will substitute the number 2 for the
symbol in the context in which it is found. It's up
to you to use the symbol in the appropriate context.

There is no context that I can see, unless "ZEROBIT" is a reserved name that
indicates to the assembler that when used in the equates section refers to a
bit of a file and not a file - the PIC in Practice book and the datasheet
makes no mention of this that I can find, or for that matter the WREN label
which is also EQU 2

In which case assembling the code would produce some kind of error as the
assembler would presumably equate "ZEROBIT" to file 2 and also "WREN" to
file 2, as there is nothing to indicate that either actually means a bit and
not a file - or indeed which file either is bit 2 of!

Ian, all you're doing with the equates is setting up an alias that the
assembler will use. Think search and replace in a word processor.
Every time you write ZEROBIT in you source code, the assembler will
replace that with '2' when it assembles your source.

Now, *how* ZEROBIT is used, and its context, is strictly
up to you. In your source code, you'll use ZEROBIT in
an expression that can only refer to a bit operation. An
in that expression, it won't matter if you write it as

.... ,ZEROBIT

or

.... ,2

Since the assembler will replace ZEROBIT with 2, it doesn't care a
whit how you've written the expression: 2 or ZEROBIT. The context and
form of the instruction you write tells the assembler what to do with
that 2 or its alias.

The same holds for ports, registers, memory addresses, constants, or
anything else set as aliases.

You would use these (or not, as you choose) simply to improve the
readability of your program.

Does that clear it up for you?

Have fun!

Tom

 

[ian field]

Ian, all you're doing with the equates is setting up an alias that the
assembler will use. Think search and replace in a word processor.
Every time you write ZEROBIT in you source code, the assembler will
replace that with '2' when it assembles your source.

Now, *how* ZEROBIT is used, and its context, is strictly
up to you. In your source code, you'll use ZEROBIT in
an expression that can only refer to a bit operation. An
in that expression, it won't matter if you write it as

.... ,ZEROBIT

or

.... ,2

Since the assembler will replace ZEROBIT with 2, it doesn't care a
whit how you've written the expression: 2 or ZEROBIT. The context and
form of the instruction you write tells the assembler what to do with
that 2 or its alias.

The same holds for ports, registers, memory addresses, constants, or
anything else set as aliases.

You would use these (or not, as you choose) simply to improve the
readability of your program.

Does that clear it up for you?

Have fun!

Tom

Thanks - now it seems like one of those things that's so obvious I just
can't see it.

 

[Peter Bennett]

In which case assembling the code would produce some kind of error as the
assembler would presumably equate "ZEROBIT" to file 2 and also "WREN" to
file 2, as there is nothing to indicate that either actually means a bit and
not a file - or indeed which file either is bit 2 of!

EQU statements just assign numbers to names, so the programmer can use
meaningful names in his program, rather than numbers. The assembler
doesn't care what you think the names or numbers mean.

Whenever the assembler sees "ZEROBIT" or "WREN" in your source, it
will substitute the number 2. Presumably you would use each word in a
place where it makes sense to the reader, but if you exchange them, it
will only confuse the reader, not the assembler.

EQUs are also used to name frequently used numbers in the program.
For example, if you start out planning to use 6 ADC channels you might
have this statement:

LAST_ADC EQU 6

and use LAST_ADC wherever you are counting channels to see if you've
done them all. Later, someone decides you really need 8 channels, so,
if you hadn't used that line, you'd have to search through the program
for all the places you used "6" and change it to 8. Instead, with the
EQU you just change the above line to:

LAST_ADC EQU 8

and the assembler automagically makes all the required changes.

 

[Peter Bennett]

From what I'd read, the label names were completely arbitrary - "ZEROBIT"
could be called whatever you want as long as consistency was maintained
throughout - if I'm wrong about that it probably answers my question.

Yes - the label names are completely up to you - but if the chip
documentation provides names for bits in various registers, it makes
sense to use those names in your program rather than making up your
own names. Using equates, particularly for using "standard" bits or
bit patterns, greatly improves the readability of the program.

 

[Peter Bennett]

I tend to use the #define.
e.g.

#define UART_TX portb,6

My 8051 assembler seriously objects to that statement.

 

[Eeyore]

In a sample fragment of code (EQU section) of a program example from the
book PIC in Practice:

TMR0 EQU 1 ;TMR0 is FILE 1.
PORTA EQU 5 ;PORTA is FILE 5.
PORTB EQU 6 ;PORTB is FILE 6.
STATUS EQU 3 ;STATUS is FILE3.
ZEROBIT EQU 2 ;ZEROBIT is Bit 2.
COUNT EQU 0CH ;USER RAM LOCATION.
EEADR EQU 9 ;EEPROM address register
EEDATA EQU 8 ;EEPROM data register
EECON1 EQU 8 ;EEPROM control register1
EECON2 EQU 9 ;EEPROM control register2
RD EQU 0 ;read bit in EECON1
WR EQU 1 ;Write bit in EECON1
WREN EQU 2 ;Write enable bit in EECON1

How does the assembler tell the difference between a file and a bit?

Since when has a BIT had a value of 2 ?

Looks like sloppy documentation to me.

Graham

 

[Eeyore]

It doesn't know anything about bits or files.

What IS all this 'file' talk about anyway ?

All it knows is that you have assigned the constant 2 to a
symbol ZEROBIT.

At last !

Buy that man a cigar.

Graham

 

[Eeyore]

Yes - the label names are completely up to you - but if the chip
documentation provides names for bits in various registers, it makes
sense to use those names in your program rather than making up your
own names. Using equates, particularly for using "standard" bits or
bit patterns, greatly improves the readability of the program.

I 'm not familiar with PIC assembler but I'd have thought an equate assigns a
*constant* value, not a temporary value to a variable.

Graham

 

[Eeyore]

the PIC in Practice book and the datasheet
makes no mention of this that I can find, or for that matter the WREN label
which is also EQU 2

I assume it means a value of 0000010B. Calling that a 'bit' is highly
misleading.

That book sounds dodgy to me.

Graham

 

[Eeyore]

EQU statements just assign numbers to names, so the programmer can use
meaningful names in his program, rather than numbers. The assembler
doesn't care what you think the names or numbers mean.

Whenever the assembler sees "ZEROBIT" or "WREN" in your source, it
will substitute the number 2. Presumably you would use each word in a
place where it makes sense to the reader, but if you exchange them, it
will only confuse the reader, not the assembler.

EQUs are also used to name frequently used numbers in the program.
For example, if you start out planning to use 6 ADC channels you might
have this statement:

LAST_ADC EQU 6

Do PICs start numbering such things at '1' ? I'd have expected "LAST_ADC EQU 5".

Graham

 

[petrus bitbyter]

In a sample fragment of code (EQU section) of a program example from the
book PIC in Practice:


TMR0 EQU 1 ;TMR0 is FILE 1.
PORTA EQU 5 ;PORTA is FILE 5.
PORTB EQU 6 ;PORTB is FILE 6.
STATUS EQU 3 ;STATUS is FILE3.
ZEROBIT EQU 2 ;ZEROBIT is Bit 2.
COUNT EQU 0CH ;USER RAM LOCATION.
EEADR EQU 9 ;EEPROM address register
EEDATA EQU 8 ;EEPROM data register
EECON1 EQU 8 ;EEPROM control register1
EECON2 EQU 9 ;EEPROM control register2
RD EQU 0 ;read bit in EECON1
WR EQU 1 ;Write bit in EECON1
WREN EQU 2 ;Write enable bit in EECON1

How does the assembler tell the difference between a file and a bit?

The lines starting with ZEROBIT and WREN do not seem to have anything to
distinguish them from file EQUs.

TIA.

Read my answer in ABSE.

You'd better crosspost next time.

petrus bitbyter

 

[Anthony Fremont]

I 'm not familiar with PIC assembler but I'd have thought an equate
assigns a *constant* value, not a temporary value to a variable.

EQU assigns an assembler expression to a label; it must remain constant.
SET works much like EQU but can be reassigned as desired.
#define is also availabe for pure text substitutions.
Don't get these confused with the CONSTANT and VARIABLE directives.

 

[Anthony Fremont]

Greg Neill wrote:

What IS all this 'file' talk about anyway ?

"file registers", haven't you heard of them before? No doubt it's a silly
name, but an 805x expert should know these things.

 

[Anthony Fremont]

ian field wrote:

Since when has a BIT had a value of 2 ?

Looks like sloppy documentation to me.

In PIC assembler, if you want to let's say set the LSBit of a byte in RAM,
you'd code something like this:
BSF locsym, 0
the MSBit would be set by:
BSF locsym, 7

BSF stands for "Bit Set f". "f" is Microchip's stand-in for "register
file". The first operand is the RAM location you want to modify, the second
operand is the physical bit position (7 to 0).

 

[Eeyore]

EQU assigns an assembler expression to a label; it must remain constant.

As I imagined. In PL/M it would be a literal.

SET works much like EQU but can be reassigned as desired.
#define is also availabe for pure text substitutions.
Don't get these confused with the CONSTANT and VARIABLE directives.

Cheers,

Graham

 

[Eeyore]

"file registers", haven't you heard of them before? No doubt it's a silly
name, but an 805x expert should know these things.

Intel don't use the term 'file'. The 8051 has the usual working registers plus
the all important 'special function registers' that determine many aspect of
how the internals work - such as seeting up timers (TCON and TMOD), UARTs,
interrupts and the like.

Graham

 

[Eeyore]

In PIC assembler, if you want to let's say set the LSBit of a byte in RAM,
you'd code something like this:
BSF locsym, 0
the MSBit would be set by:
BSF locsym, 7

BSF stands for "Bit Set f". "f" is Microchip's stand-in for "register
file". The first operand is the RAM location you want to modify, the second
operand is the physical bit position (7 to 0).

In PL/M I might set an entire SFR (special function register) thus .....

TCON = 00101100B; or TCON = 02CH; or TCON = 44;
I like to set them using binary though (except for counter timer count values)
since you can quickly transpose the value to the individual bits.

or an individual bit of a register (for the bit-adressable ones) like this
.......

EA = 1; (or 01B for that matter - default is decimal)

Graham