Author: ian fieldDate: 12:28 21-02-08
|
|
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.
|
|
|
|
Author: Greg NeillDate: 14:01 21-02-08
|
|
"ian field" <dai.ode@ntlworld.com> wrote in message
news:zMjvj.4836$d62.2643@newsfe6-gui.ntli.net=20
>=20
> 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=20
subsequently do with that symbol.
However... when it comes across that symbol in code
that you write (code that generates instruction=20
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.
|
|
|
|
Author: ian fieldDate: 14:34 21-02-08
|
|
"Richard Seriani" <richard_s633@cox.net> wrote in message
news:e5kvj.2664$yk5.2209@newsfe18.lga...
>
> "ian field" <dai.ode@ntlworld.com> wrote in message
> news:zMjvj.4836$d62.2643@newsfe6-gui.ntli.net...
>>
>> "me" <me@here.net> wrote in message
>> news:Xns9A4B7EB195C8Cmeherenet@38.119.97.3... />
>>> "ian field" <dai.ode@ntlworld.com> wrote in
>>> news:bTivj.2312$g81.1350@newsfe3-gui.ntli.net:
>>>
>>>>
>>>>"Michael" <news@bigtoes.com> wrote in message
>>>>news:47bdb89f$0$1092$4c368faf@roadrunner.com...
>>>>> ian field wrote:
>>>>>> 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.
>>>>> It doesn't. Essentially it just wants to convert its operands to
>>>>> numbers. You could substitute WR whenever you wanted to use bit 1 of
>>>>> file register 1 or the value 1, the assembler wouldn't care.
>>>>> However, the human viewing the program would probably be very
>>>>> confused :-).
>>>>
>>>>Well it worked - I am confused!
>>>>
>>>>Perhaps my question should have been - is the example wrong/badly
>>>>written and if so how do I do it correctly?
>>>>
>>>>
>>>>
>>> It is the same as;
>>>
>>> x=7
>>> y=2
>>>
>>> It has the benefit of making changes easy and giving an easier to
>>> decipher source code. By using WR or RD you can tell what the code is
>>> doing instead of 0 or 1...
>>
>> 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?
> 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.
|
|
|
|
Author: Tom2000Date: 14:41 21-02-08
|
|
On Thu, 21 Feb 2008 19:17:29 GMT, "ian field" <dai.ode@ntlworld.com>
wrote:
>
>"Greg Neill" <gneillREM@OVEsympatico.ca> wrote in message
>news:47bdc5a1$0$14652$9a6e19ea@news.newshosting.com...
>"ian field" <dai.ode@ntlworld.com> wrote in message
>news:zMjvj.4836$d62.2643@newsfe6-gui.ntli.net
>
>>
>> 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.
>
>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
|
|
|
|
Author: ian fieldDate: 15:56 21-02-08
|
|
"Tom2000" <abuse@giganews.net> wrote in message
news:sdkrr315dp1br26908u0mp5e3v56r8ns5p@4ax.com...
> On Thu, 21 Feb 2008 19:17:29 GMT, "ian field" <dai.ode@ntlworld.com>
> wrote:
>
>>
>>"Greg Neill" <gneillREM@OVEsympatico.ca> wrote in message
>>news:47bdc5a1$0$14652$9a6e19ea@news.newshosting.com...
>>"ian field" <dai.ode@ntlworld.com> wrote in message
>>news:zMjvj.4836$d62.2643@newsfe6-gui.ntli.net
>>
>>>
>>> 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.
>>
>>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
>
>
Thanks - now it seems like one of those things that's so obvious I just
can't see it.
|
|
|
|
Author: Peter BennettDate: 16:08 21-02-08
|
|
On Thu, 21 Feb 2008 19:17:29 GMT, "ian field" <dai.ode@ntlworld.com>
wrote:
>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, VE7CEI
peterbb4 (at) interchange.ubc.ca
GPS and NMEA info: http://vancouver-webpages.com/peter
Vancouver Power Squadron: http://vancouver.powersquadron.ca
|
|
|
|
Author: Peter BennettDate: 16:15 21-02-08
|
|
On Thu, 21 Feb 2008 19:34:55 GMT, "ian field" <dai.ode@ntlworld.com>
wrote:
>
>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, VE7CEI
peterbb4 (at) interchange.ubc.ca
GPS and NMEA info: http://vancouver-webpages.com/peter
Vancouver Power Squadron: http://vancouver.powersquadron.ca
|
|
|
|
Author: Peter BennettDate: 16:16 21-02-08
|
|
|
|
|
|
Author: EeyoreDate: 18:19 21-02-08
|
|
ian field wrote:
> 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
|
|
|
|
Author: EeyoreDate: 18:23 21-02-08
|
|
Greg Neill wrote:
> "ian field" <dai.ode@ntlworld.com> wrote
> >
> > 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.
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
|
|
|
|
Author: EeyoreDate: 18:26 21-02-08
|
|
Peter Bennett wrote:
> "ian field" <dai.ode@ntlworld.com> wrote:
> >
> >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.
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
|
|
|
|
Author: EeyoreDate: 18:28 21-02-08
|
|
ian field wrote:
> 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
|
|
|
|
Author: EeyoreDate: 18:30 21-02-08
|
|
Peter Bennett wrote:
> On Thu, 21 Feb 2008 19:17:29 GMT, "ian field" <dai.ode@ntlworld.com>
> wrote:
>
> >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
Do PICs start numbering such things at '1' ? I'd have expected "LAST_ADC EQU 5".
Graham
|
|
|
|
Author: petrus bitbyterDate: 20:32 21-02-08
|
|
"ian field" <dai.ode@ntlworld.com> schreef in bericht
news:Pwivj.2311$g81.1768@newsfe3-gui.ntli.net...
> 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
|
|
|
|
Author: Anthony FremontDate: 21:25 21-02-08
|
|
Eeyore wrote:
> 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.
|
|
|
|
Author: Anthony FremontDate: 21:27 21-02-08
|
|
Eeyore wrote:
> Greg Neill wrote:
>> It doesn't know anything about bits or files.
>
> 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.
|
|
|
|
Author: Anthony FremontDate: 21:38 21-02-08
|
|
Eeyore wrote:
> ian field wrote:
<snip>
>> 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.
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).
|
|
|
|
Author: EeyoreDate: 22:08 21-02-08
|
|
Anthony Fremont wrote:
> Eeyore wrote:
>
> > 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.
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
|
|
|
|
Author: EeyoreDate: 22:10 21-02-08
|
|
Anthony Fremont wrote:
> Eeyore wrote:
> > Greg Neill wrote:
>
> >> It doesn't know anything about bits or files.
> >
> > 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.
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
|
|
|
|
Author: EeyoreDate: 22:15 21-02-08
|
|
Anthony Fremont wrote:
> Eeyore wrote:
> > ian field wrote:
> <snip>
> >> 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.
>
> 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
|
|
|
|
|