Exact match. Not showing close matches.
PICList
Thread
'[PIC]: Configuration bits'
2001\05\08@143534
by
Fernando Antoniasse
Hello,
I've been made some confusion about my _CONFIG directive
with the 16F87x PICs series.
My question is?
What means and when must I use this bits ON or OFF?
_BODEN
_PWRTE
_WRT_ENABLE
_DEBUG
_CPD
In my programs I have been used this configuration.
Realy, I don't know if are correct.
__CONFIG _CP_OFF & _WDT_OFF & _BODEN_OFF & _PWRTE_OFF
& _XT_OSC & _WRT_ENABLE_OFF & _LVP_OFF
Thanks for any help
Regards
Luis Fernando.
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2001\05\08@145526
by
Drew Vassallo
|
>What means and when must I use this bits ON or OFF?
>_BODEN
This is the brownout detection enable bit. I guess I haven't had a real
reason to turn it on, unless you're having trouble with your power source
not coming up to potential fast enough. This consumes some current when
enabled (I think), but does provide brownout correction if you need it.
>_PWRTE
This is the power-up timer. I'm not sure of the specifics of how it works,
but I think basically it sets up a timer (72ms?) after power-up to allow
time for the chip's hardware to stabilize. I usually have this turned ON.
>_WRT_ENABLE
I think this is for flash memory programming. You can enable or disable
program memory location writes with this bit.
>_DEBUG
This enables in-circuit debugger mode. I think RC6 and RC7 are used, then,
for the debugger to use if this bit is clear.
>_CPD
This enables/disables protection on the EEPROM memory location. If
disabled, you can't write to the EEPROM memory on the chip.
Note that I'm trying to recall these from memory. While these statements
may not be 100% accurate, they should at least give you something to look
for in the datasheets. These should all be explained in the datasheet for
the particular chip that you are using.
>__CONFIG _CP_OFF & _WDT_OFF & _BODEN_OFF & _PWRTE_OFF
>& _XT_OSC & _WRT_ENABLE_OFF & _LVP_OFF
You have code protection off, watchdog timer off, brownout disabled,
power-up timer off (I would change this), crystal oscillator selected,
program memory writes disabled, and low-voltage programming disabled.
These seem fine, with the exception of the power-up timer.
Here's a configuration word from a 16F872 that I used on a project:
__CONFIG _CP_OFF & _WDT_OFF & _BODEN_OFF & _PWRTE_ON & _XT_OSC &
_WRT_ENABLE_OFF & _LVP_OFF & _CPD_OFF
--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2001\05\08@152012
by
Sean H. Breheny
If I remember correctly, the power-up timer is intended to prevent the chip
from trying to start before the clock has stabilized. Crystal oscillators,
because of their high Q, take tens of milliseconds to reach a
steady-amplitude stable oscillation state. The reason why they allow you to
disable this timer is probably for cases where the clock is provided by an
RC oscillator (which start much more quickly) or by and external clock
source which has already stabilized before power is applied to the PIC.
Sean
At 02:55 PM 5/8/01 -0400, you wrote:
>>_PWRTE
>
>This is the power-up timer. I'm not sure of the specifics of how it works,
>but I think basically it sets up a timer (72ms?) after power-up to allow
>time for the chip's hardware to stabilize. I usually have this turned ON.
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
'[PIC]: Configuration bits'
2003\03\30@125506
by
j galt
Ok, I'm a newbie trying to get started with a 12f675. How do I replace this
goofy stuff with a simple hex value? I really don't feel like playing word
games. Thanks.
__CONFIG _CP_OFF & _WDT_ON & _BODEN_ON & _PWRTE_ON & _MCLRE_ON
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\03\30@133448
by
shoppa_piclist
> Ok, I'm a newbie trying to get started with a 12f675. How do I replace this
> goofy stuff with a simple hex value? I really don't feel like playing word
> games. Thanks.
> __CONFIG _CP_OFF & _WDT_ON & _BODEN_ON & _PWRTE_ON & _MCLRE_ON
You really *do* want to play word games. That said, look in the
include file for your PIC to find the corresponding numeric constants; it'll
be a file called 'p12f675.inc' somewhere on your machine:
_CP_OFF EQU H'3FFF'
_WDT_ON EQU H'3FFF'
_BODEN_ON EQU H'3FFF'
_PWRTE_ON EQU H'3FEF'
_MCLRE_ON EQU H'3FFF'
and the AND of all of these is H'3FEF'.
Again, you really do want to play word games. The alternative is to
have all sorts of hex constants that are vitally important to the operation
of your PIC but no way of saying what or why they're that value in the
source code.
Tim.
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\03\30@140354
by
jim barchuk
|
|
Hello j!
> Ok, I'm a newbie trying to get started with a 12f675. How do I replace
> this goofy stuff with a simple hex value? I really don't feel like
> playing word games. Thanks.
>
> __CONFIG _CP_OFF & _WDT_ON & _BODEN_ON & _PWRTE_ON & _MCLRE_ON
Are you a programming newbie? I don't mean that disrespectfully at all
because you don't seem to realise that this goofy stuff is for your
*convenience*. In fact it's for your sanity.
Tim's comment but not answering your q in detail:
> _CP_OFF EQU H'3FFF'
> _WDT_ON EQU H'3FFF'
> _BODEN_ON EQU H'3FFF'
> _PWRTE_ON EQU H'3FEF'
> _MCLRE_ON EQU H'3FFF'
So here's your simple answer:
__CONFIG H'3FFF' & H'3FFF' & H'3FFF' & H'3FFF' & H'3FEF' H'3FFF'
Now think about this. Somewhere, three months down the line, you're gonna
look at that ad say "I wonder what WDT is set to?" You *cannot* answer
that because you don't know which 'simple hex value' is supposed to be
which goofy config variable.
Or even simpler:
__CONFIG H'3FEF'
Somewhere, 45 mins down the line, you're gonna ask 'Now what have I got
configured?' Again, cannot be answered.
Be thankful for all that silly stuff. 'Copy con > myprog.hex' is tons more
fun than what you -think- you want to do. LOL!
Have a :) day!
jb
--
jim barchuk
spam_OUTjbTakeThisOuT
jbarchuk.com
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\03\30@151427
by
shoppa_piclist
|
|
> because you don't seem to realise that this goofy stuff is for your
> *convenience*. In fact it's for your sanity.
While I fully agree that mnemonic symbols are far superior to raw hex
constants, I honestly don't feel that they've gone far enough. For
example, with MPASM (or the Gnu equivalent gpasm) I can gleefully
set bit 5 in INTCON with a
BSF INTCON,RP0
even though RP0 has no meaning in the INTCON context (it only makes
sense in STATUS).
What we need is an assembler smart enough to say "What you've written
can be done, but it doesn't make sense to write it that way." That
way the advantage of using symbols as opposed to raw numbers will be
even more overwhelming :-)
(And sometimes, of course, it might make sense to set RP0 outside
of STATUS, especially if you're using a work variable that will be
moved into STATUS for actual use.)
Tim.
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\03\30@205239
by
jim barchuk
|
|
Hi Tim!
On Sun, 30 Mar 2003 .....shoppa_piclistKILLspam@spam@TRAILING-EDGE.COM wrote:
{Quote hidden}> > because you don't seem to realise that this goofy stuff is for your
> > *convenience*. In fact it's for your sanity.
>
> While I fully agree that mnemonic symbols are far superior to raw hex
> constants, I honestly don't feel that they've gone far enough. For
> example, with MPASM (or the Gnu equivalent gpasm) I can gleefully set
> bit 5 in INTCON with a
>
> BSF INTCON,RP0
>
> even though RP0 has no meaning in the INTCON context (it only makes
> sense in STATUS).
>
> What we need is an assembler smart enough to say "What you've written
> can be done, but it doesn't make sense to write it that way." That way
> the advantage of using symbols as opposed to raw numbers will be even
> more overwhelming :-)
Dunno. I think I'm already adequately whelmed. :)
Sounds reasonable on the surface, but not really practical I don't think.
One of the aphorisms of software (and hardware too considering this forum)
is to 'accept anything but output only pure gold.' Flagging
potential/possible faults isn't so bad. *If* they are *real*. The idea
that the assembler (or compiler or whatever) could consider all
possibilities that follow something that 'looks funny' adds orders of
orders of magnitiude of complexity to the process. The dippydoo 'Register
in operand is not in bank 0' *MESSAGES* I asked about recently is a
perfect example. It's not even frigging *checking* if it's a 'problem' or
not. It's saying 'Johnny, in my experience it's easy to drop a brick on
your foot if you're not careful. I don't even know whether it's a brick or
a feather that you're holding, if you're going to drop it, or where it
might land, but I though you might like to be informed of the
possibilities.' That, IMO, is the dumbest ummm... 'error' message I have
ever seen any software ever produce. It's on the order of installing a new
piece of software and getting those silly 'tips' popup screens that I have
to *tell* it to 'don't show me any more of that crap.' Gee, I know where
the friggin 'help' button is and I'll use it if I need to but don't shove
it in my face.
What you're suggesting, a 'doesn't make sense' message, implies that the
assembler knows the -right- way to write it. At that level I might as not
even bother to write the program because the assembler is 'ten thousand
monkeys typing' and already *knows* what I intend. :)
The assembler/compiler/interpreter should just sit back and not frigging
*interfere* with what I do because unless I tell it it has no idea what I
intend. It should comment *only* after I have already dropped a brick,
only if it knows it to be a brick, and my foot is directly under it, not
trying to decide whether I might move my foot away before it hits it or
might move my foot under it later even though it's not in the way right
now. Maybe it's a Yankee 'don't tread on me' thing. The software should
just stay outta my face and simply do what I tell it to do. :)
Have a :) day!
jb
--
jim barchuk
jbKILLspamjbarchuk.com
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\03\30@205903
by
Russell McMahon
|
> While I fully agree that mnemonic symbols are far superior to raw hex
> constants, I honestly don't feel that they've gone far enough. For
> example, with MPASM (or the Gnu equivalent gpasm) I can gleefully
> set bit 5 in INTCON with a
>
> BSF INTCON,RP0
>
> even though RP0 has no meaning in the INTCON context (it only makes
> sense in STATUS).
If you really want to avoid this you can use, as I do, explicit naming in
both the word and bit mnemonics eg
BSF INTCON, INTCON_describe_bit_function_here
eg requiring BitSet PORTA,
BPORTA_Fire_Torpedoes
helps to avoid firing torpedoes when you really want to
set a bit in INTCON :-)
For the really paranoid you can also preceded mnemonics with letters that
identify their use
eg
KThis_is_a_constant
VThis_is_a_variable
BThis_is_a_bit_descriptor
Shades of FORTRAN :-)
BUT it works.
I largely do this.
Using eg Kxxx stops you using
LD A, JIM
when you meant
LD A, #JIM
when the processor / mnemonics are of that sort
or using
LDI A, JIM
when JIM is NOT an immediate value.
Those with eidetic memories and superb programming skills may not need these
safeguards. But I think most would benefit.
Russell McMahon
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\03\30@211732
by
shoppa_piclist
|
|
> Sounds reasonable on the surface, but not really practical I don't think.
I'm not so sure how practical it is either. I've been writing assembly
for 4 decades now and it still bothers me that the assembler doesn't
catch certain classes of mistakes :-)
> The idea that the assembler (or compiler or whatever) could consider all
> possibilities that follow something that 'looks funny' adds orders of
> orders of magnitiude of complexity to the process.
Look at it the other way around, as if you're a dissassembler trying
to attach mnemonics to the "raw" instruction. Bit 5 in STATUS is
RP0, bit 5 in INTCON is T0IE, and any PIC disassembler worth its
salt will do the "right" thing. All I'm asking for is that the
assembler do the same "right" thing.
Again, I've been programming in various assemblers for 4 decades
now, and MPASM is far from the worst (it's actually pretty good, though
I do agree that "Register in operand is not in bank 0" has reached
the point of "The boy who cried wolf", it's so common that nobody
pays any attention to it), but I'll still dream of making things
better :-)
Tim.
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\03\30@211946
by
Russell C. Hay
Or you can do something like
#define SOME_BIT_YOU_NEED_TO_MANIPULATE PORTA, .1
and then just do
BSF SOME_BIT_YOU_NEED_TO_MANIPULATE
That's the way I do it so that the file register and bit are contained in
the same constant. (this is with MPLAB, of course)
{Original Message removed}
2003\03\30@220801
by
Wouter van Ooijen
> That, IMO, is the dumbest ummm... 'error'
> message I have
> ever seen any software ever produce.
That's why it is not an error message....
And IMHO it is of the same order of dumbness as the C compilers that
tell me for instance that
- this if condition always evaluates to zero (I #defined it that way!)
- this code will never be executed (then part of the above if statement)
- this local variable declaration hides a global (I want scoped debug
settings, so this is deliberate)
- this function parameter is not used (of course it is not, it must be
present to have the same prototype as another function where it is used)
But of course nothing beats the famous 'syntax error at or around line
XXX'.
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2003\03\30@223329
by
Tal
2003\03\31@040143
by
Alan B. Pearce
>Or you can do something like
>
>#define SOME_BIT_YOU_NEED_TO_MANIPULATE PORTA, .1
>
>and then just do
>
> BSF SOME_BIT_YOU_NEED_TO_MANIPULATE
>
>That's the way I do it so that the file register and bit are
>contained in the same constant. (this is with MPLAB, of course)
It is also the way that Olin's macros do it. Saves a heap of time working
out what port and bit you need. Same with the FLAG dircetive he has.
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body
2003\03\31@041840
by
Jinx
2003\03\31@082531
by
Olin Lathrop
jim barchuk wrote:
> The assembler/compiler/interpreter should just sit back and not frigging
> *interfere* with what I do because unless I tell it it has no idea what
> I intend. It should comment *only* after I have already dropped a brick,
> only if it knows it to be a brick, and my foot is directly under it, not
> trying to decide whether I might move my foot away before it hits it or
> might move my foot under it later even though it's not in the way right
> now. Maybe it's a Yankee 'don't tread on me' thing. The software should
> just stay outta my face and simply do what I tell it to do. :)
What Tim was suggesting could be achieved with a minimally intrusive type
checking. I've actually contemplated adding something like that to my
preprocessor. Right now, the bit number symbols are just integers, and
can therefore be used anywhere an integer is allowed.
It would be nice if RP0, for example, didn't just have the value 5, but
was also known to represent a bit within STATUS. Using it in a bit
manipulation instruction to any register except STATUS and INDF would
result in an assembly time error. In the relatively unusual case where it
is valid to use the RP0 symbol as other than a bit number within STATUS
(like setting a shadow register, for example), a special syntax would be
required to selectively disable the type checking. Something like the
Pascal ORD function (returns the raw integer value of any ordinal value)
would be simple and effective. Having to write ORD(RP0) on rare occasions
would be well worth the error checking it provided in the vast majority of
cases.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
2003\03\31@083829
by
Bob Ammerman
|
Olin said:
> It would be nice if RP0, for example, didn't just have the value 5, but
> was also known to represent a bit within STATUS. Using it in a bit
> manipulation instruction to any register except STATUS and INDF would
> result in an assembly time error. In the relatively unusual case where it
> is valid to use the RP0 symbol as other than a bit number within STATUS
> (like setting a shadow register, for example), a special syntax would be
> required to selectively disable the type checking. Something like the
> Pascal ORD function (returns the raw integer value of any ordinal value)
> would be simple and effective. Having to write ORD(RP0) on rare occasions
> would be well worth the error checking it provided in the vast majority of
> cases.
Amen.
People should do what people do best -- think.
Computers should do what computers do best -- bookkeeping details.
Bob Ammerman
RAm Systems
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body
2003\03\31@181218
by
Igor Pokorny
much better would be when a bit symbol represents a bit in certain byte as
is usual in some C compilers ...
writing ....
BSF RP0 ..... should be clear for anybody
Igor
{Original Message removed}
2003\03\31@200457
by
Andrew Warren
Igor Pokorny <KILLspamPICLISTKILLspammitvma.mit.edu> wrote:
> much better would be when a bit symbol represents a bit in certain
> byte as is usual in some C compilers ... writing ....
> BSF RP0 ..... should be clear for anybody
I missed the start of this thread, so perhaps this has already
been covered... But I assume that everyone who's using MPASM
already does:
#define RP0 STATUS,5 // or whatever
Once defined, RP0 can then be set just as you suggested, with:
BSF RP0
-Andy
=== Andrew Warren -- RemoveMEaiwTakeThisOuTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body
2003\03\31@200840
by
Andrew Warren
I just wrote:
> I assume that everyone who's using MPASM already does:
>
> #define RP0 STATUS,5 // or whatever
Sigh... I've been writing too much C. What I meant, of course,
was:
#define RP0 STATUS,5 ; or whatever
-Andy
=== Andrew Warren -- TakeThisOuTaiwEraseMEspam_OUTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
2003\03\31@234428
by
Bob Barr
On Mon, 31 Mar 2003 17:04:46 -0800, Andrew Warren wrote:
Igor Pokorny wrote:
>
>> much better would be when a bit symbol represents a bit in certain
>> byte as is usual in some C compilers ... writing ....
>> BSF RP0 ..... should be clear for anybody
>
> I missed the start of this thread, so perhaps this has already
> been covered... But I assume that everyone who's using MPASM
> already does:
>
> #define RP0 STATUS,5 // or whatever
>
> Once defined, RP0 can then be set just as you suggested, with:
>
> BSF RP0
>
I do something similar. To keep compatability with Microchip's
mnemonics, though, I define my own _RP0 etc to include the register
and bit number.
In my code, "RP0" is always just the bit number while "_RP0" has both
the register and the bit number.
Regards, Bob
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseME.....mitvma.mit.edu with SET PICList DIGEST in the body
'[PIC]: Configuration bits'
2003\04\01@080431
by
Olin Lathrop
> #define RP0 STATUS,5 ; or whatever
At the least you would have to pick a different name than the symbol for
the bit number, which is already defined in the Microchip include file.
The line above should result in an assembly time error.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestmitvma.mit.edu>
2003\04\01@150441
by
Andrew Warren
2003\04\01@153735
by
Dwayne Reid
|
|
At 03:13 PM 3/30/03 -0500, EraseMEshoppa_piclistspamspamBeGoneTRAILING-EDGE.COM wrote:
> > because you don't seem to realise that this goofy stuff is for your
> > *convenience*. In fact it's for your sanity.
>
>While I fully agree that mnemonic symbols are far superior to raw hex
>constants, I honestly don't feel that they've gone far enough. For
>example, with MPASM (or the Gnu equivalent gpasm) I can gleefully
>set bit 5 in INTCON with a
>
> BSF INTCON,RP0
Andy Warren suggested a simple fix many years ago and it is how I currently
write my code: I have my own set of include files that mirrors every
single bit in the special function registers. For example, the above is
handled by
#define _RP0 INTCON,RP0
within the include file.
You use it by referring to the alias:
bsf _RP0
Registers in different banks are handled with
bsf RB1(_T1IE)
where RB1 is a #define located at the start of my code:
<snippet from working code>
;other bit and register macro helpers
#define BB1(reg,bit) (reg^0x80),(bit) ;bit in bank 1
#define RB1(reg) (reg^0x80) ;reg in bank 1
;usage is: bcf BB1(_SOMEBIT)
;usage is: movwf RB1(SOMEREG)
#define BNUM(reg,bit) (bit) ;bit number within reg
#define BIT(reg,bit) 1<<(bit) ;bit within reg
#define MASK(reg,bit) ~(1<<(bit)) ;bit mask within reg
#define REG(reg,bit) (reg) ;reg
;usage is: movlw BIT(_SOMEBIT)
; do something
; movwf REG(_SOMEBIT)
Olin has a nicer method of dealing with banking issues that I intend to
adopt Real Soon Now (tm) - as soon as I get a chance.
dwayne
--
Dwayne Reid <RemoveMEdwaynerKILLspamplanet.eon.net>
Trinity Electronics Systems Ltd Edmonton, AB, CANADA
(780) 489-3199 voice (780) 487-6397 fax
Celebrating 19 years of Engineering Innovation (1984 - 2003)
.-. .-. .-. .-. .-. .-. .-. .-. .-. .-
`-' `-' `-' `-' `-' `-' `-' `-' `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.
--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspamspam_OUTmitvma.mit.edu>
2003\04\01@161621
by
Olin Lathrop
> Only if I used those dumb include files... Which I don't,
But then you have to reproduce all the information in them in some other
form, or at least the part that you use. The include files aren't
elegant, but they do eliminate the chance of you making a little mistake
that takes a long time to find.
I would leave the symbols in those include files alone and create new ones
that expand to the register and the bit within the register. That also
makes your code more standard in that RP0, for example, means what
everyone else will assume it means. For example, you could
#define STATUS_RP0 STATUS,RP0
This still takes the RP0 bit number definition from the Microchip file so
that you can't accidentally get it wrong, but still gives you the combined
symbol you want.
> as you know,
Well I didn't. Sorry, I don't keep track of everyone's individual quirks.
> mostly because they don't define bits with #define.
Again, this would best be done in addition to, not instead of, the
Microchip include file.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestSTOPspamEraseMEmitvma.mit.edu>
2003\04\01@170434
by
William Chops Westfield
It seems to me that the problem with nice macros for setting register bits
is that it only helps you do it RIGHT. What you really want is something
that flags when you do it WRONG. It's nice to be able to do
BSF STATUS_RP0
But I'd rather have
BSF STATUS,RB0
generate an error. That seems a bit impossible without undefining STATUS
or at least RB0...
BillW
--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonemitvma.mit.edu>
2003\04\01@184930
by
Andrew Warren
|
|
Olin Lathrop <EraseMEPICLISTEraseMEmitvma.mit.edu> wrote:
> > Only if I used those dumb include files... Which I don't,
>
> But then you have to reproduce all the information in them in some
> other form, or at least the part that you use. The include files
> aren't elegant, but they do eliminate the chance of you making a
> little mistake that takes a long time to find.
Maybe; I don't know. My own definitions are well over a decade
old, so it's not really an issue for me.
Hey, by the way... Speaking of little mistakes that take a long
time to find, what does W contain at the "done" label?
list p=16c54
#include p16c5x.inc
list r = hex
org 0
movlw 0 ;3 * 0 = 0x00
addlw 3 ;3 * 1 = 0x03
addlw 6 ;3 * 2 = 0x06
addlw 9 ;3 * 3 = 0x09
addlw C ;3 * 4 = 0x0C
addlw F ;3 * 5 = 0x0F
done: goto done
org 1FF
goto 0
end
{Quote hidden}> I would leave the symbols in those include files alone and create
> new ones that expand to the register and the bit within the
> register. That also makes your code more standard in that RP0, for
> example, means what everyone else will assume it means. For
> example, you could
>
> #define STATUS_RP0 STATUS,RP0
>
> This still takes the RP0 bit number definition from the Microchip file
> so that you can't accidentally get it wrong, but still gives you the
> combined symbol you want.
I couldn't disagree more. As long as Microchip's RP0 definition
remains in the include file, the assembler will still allow you
to do the wrong thing by using RP0 with registers other than
STATUS.
What we want to do is constrain the assembler so that it ONLY
accepts CORRECT usage of RP0... And the only way to do that is
to remove Microchip's error-prone definition when we add the new
error-proof definition.
> Again, this would best be done in addition to, not instead of, the
> Microchip include file.
Again, this would be best done instead of, NOT in addition to,
the definitions in the Microchip include file.
-Andy
=== Andrew Warren -- @spam@aiw@spam@spam_OUTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestKILLspammitvma.mit.edu>
2003\04\02@022218
by
hael Rigby-Jones
|
{Quote hidden}> -----Original Message-----
> From: Andrew Warren [SMTP:
.....aiwspam_OUTCYPRESS.COM]
> Sent: Wednesday, April 02, 2003 12:46 AM
> To:
TakeThisOuTPICLIST.....TakeThisOuTMITVMA.MIT.EDU
> Subject: Re: [PIC]: Configuration bits
>
> Hey, by the way... Speaking of little mistakes that take a long
> time to find, what does W contain at the "done" label?
>
> list p=16c54
> #include p16c5x.inc
>
> list r = hex
>
> org 0
>
> movlw 0 ;3 * 0 = 0x00
> addlw 3 ;3 * 1 = 0x03
> addlw 6 ;3 * 2 = 0x06
> addlw 9 ;3 * 3 = 0x09
> addlw C ;3 * 4 = 0x0C
> addlw F ;3 * 5 = 0x0F
>
> done: goto done
>
> org 1FF
> goto 0
>
> end
>
My calculator said 2Dh, but after a cup of coffee my brain kicked in and
told me that addlw dosen't exist on the 12bit cores :o)
Regards
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.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to TakeThisOuTpostmasterKILLspamspambookham.com.
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@024530
by
Wouter van Ooijen
> What you really want
> is something
> that flags when you do it WRONG. It's nice to be able to do
> BSF STATUS_RP0
> But I'd rather have
> BSF STATUS,RB0
> generate an error.
But what is realy wrong with that last line? It was probably not what
you intended, but I'd hate to be prevented from doing
BSF Shadow, RB0
MOVFW Shadow
MOVWF port_b
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@081330
by
Olin Lathrop
{Quote hidden}> Hey, by the way... Speaking of little mistakes that take a long
> time to find, what does W contain at the "done" label?
>
> list p=16c54
> #include p16c5x.inc
>
> list r = hex
>
> org 0
>
> movlw 0 ;3 * 0 = 0x00
> addlw 3 ;3 * 1 = 0x03
> addlw 6 ;3 * 2 = 0x06
> addlw 9 ;3 * 3 = 0x09
> addlw C ;3 * 4 = 0x0C
> addlw F ;3 * 5 = 0x0F
>
> done: goto done
>
> org 1FF
> goto 0
>
> end
OK, I'll bite. It sure looks like 3 * 15, or 45. If there's some hidden
trick here, I guess I'm missing it.
> I couldn't disagree more. As long as Microchip's RP0 definition
> remains in the include file, the assembler will still allow you
> to do the wrong thing by using RP0 with registers other than
> STATUS.
>
> What we want to do is constrain the assembler so that it ONLY
> accepts CORRECT usage of RP0... And the only way to do that is
> to remove Microchip's error-prone definition when we add the new
> error-proof definition.
Then what do you do in those cases where you want to access a named bit
other than thru bit manipulation instructions, or to a shadow register.
These cases are relatively rare, so I wouldn't mind a little extra syntax
to disable the checking, but your method seems to proclude them
altogether. For example:
movlw (1 << abit) | (1 << anotherbit) ;make mask of combined bits
movwf somereg ;set the new state
or:
bsf shadowreg, abit ;update shadow register of SOMEREG
Also, while it would be nice to have some sort of type checking on bit
number symbols, let's no loose sight of the fact that these kinds of
errors are quite rare. I've written tens of thousands of lines of PIC
assembler of dozens of projects, and I have no recollection of ever using
a named bit with the wrong special function register.
Hmm. Maybe I should log all PIC coding errors for a while and see what
kind of mistakes I do make. That might be useful to decide what kind of
tool upgrades would be appropriate. Just from memory, the most common
error I make is forgetting to add the ", w" after a file register
instruction when I intended the result to go into W. Fortunately these
are quick to find in debugging.
The only error (in my coding) in the last month or two that took
significant time to find was when I accidentally used the wrong temporary
variable in the low priority interrupt routine of an 18F. This was the
first time I used multiple interrupt priorities on a PIC. Until then, I
would define IREGs, which were temporary scratch registers for exclusive
use during interrupts. when I implemented low and high priority
interrupts it just didn't occur to me that I would need separate IREGs for
the two interrupts (yes, I know, duh!). One of the IREGs used in the low
priority interrupt routine would get trashed when a high priority
interrupt happened. This produced a symptom that took a whole morning of
back tracking to find.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@083429
by
Alan B. Pearce
>Also, while it would be nice to have some sort of type checking
>on bit number symbols, let's no loose sight of the fact that
>these kinds of errors are quite rare. I've written tens of
>thousands of lines of PIC assembler of dozens of projects, and I
>have no recollection of ever using a named bit with the wrong
>special function register.
I have not managed to make that mistake yet either, but in the process of
debugging a portion, some reasonable time after writing it, and having been
sidetracked into other hardware issues, have been through the loop of being
certain I have the correct bit name, but not sure if the register is really
the correct one, and had to double check to make sure.
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@084641
by
Olin Lathrop
>> Hey, by the way... Speaking of little mistakes that take a long
>> time to find, what does W contain at the "done" label?
>> ...
>
> My calculator said 2Dh, but after a cup of coffee my brain kicked in and
> told me that addlw dosen't exist on the 12bit cores :o)
Yeah, you're right, but shouldn't that have caused an assembly error? I
wouldn't put that into the "take a long time to find" category since the
assembler hands you the error on a silver platter.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@084853
by
Rick Regan
{Quote hidden}> Hey, by the way... Speaking of little mistakes that
> take a long
> time to find, what does W contain at the "done"
>label?
>
> list p=16c54
> #include p16c5x.inc
>
> list r = hex
>
> org 0
>
> movlw 0 ;3 * 0 = 0x00
> addlw 3 ;3 * 1 = 0x03
> addlw 6 ;3 * 2 = 0x06
> addlw 9 ;3 * 3 = 0x09
> addlw C ;3 * 4 = 0x0C
> addlw F ;3 * 5 = 0x0F
>
> done: goto done
>
> org 1FF
> goto 0
>
> end
>> OK, I'll bite. It sure looks like 3 * 15, or 45.
>> If there's some hidden
>> trick here, I guess I'm missing it.
Decimal 19.
Ok, I "cheated". I ran it in the simulator. F is
equal to 1 and C is equal to 0. You must prefix them
with "0x".
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@085307
by
Rick Regan
>Decimal 19.
>Ok, I "cheated". I ran it in the simulator. F is
>equal to 1 and C is equal to 0. You must prefix them
>with "0x".
I must add I did this with device set to 16f877.
Using device 16C54 gives an assmble error as Olin
states.
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@085846
by
Bob Ammerman
I'd like to see a syntax something like this:
portb = ...whatever the address is...
bitmap portb
B0
B1
...
B6
B7
endb
fire_torpedoes = B7
bsf B3
bsf fire_torpedoes
bsf shadow.b3
bsf shadow.fire_torpedoes
The bitmap symbols would be stored in the symbol table as both a file
address and a bit number, along with an indication that it was a bitmap
symbol.
The syntax shadow.b3 would replace the file address with that of 'shadow'.
The only places these symbols could be used is:
1: with or without 'shadow.' as the only argument to BSF/BCF/BTFSS/BTFSC
2: without 'shadow.' as arguments to builtin functions:
bitnum(b7)
fileaddr(b6)
bitmask(b3)
3: with or without 'shadow.' as a value to be assigned to another symbol,
which will then also be marked as a bitmap symbol.
shadow_fire = shadow.fire_torpedoes
Bob Ammerman
RAm Systems
{Original Message removed}
2003\04\02@091104
by
hael Rigby-Jones
|
|
> -----Original Message-----
> From: Olin Lathrop [SMTP:.....olin_piclistRemoveMEEMBEDINC.COM]
> Sent: Wednesday, April 02, 2003 2:46 PM
> To: RemoveMEPICLISTspamBeGoneMITVMA.MIT.EDU
> Subject: Re: [PIC]: Configuration bits
>
> >> Hey, by the way... Speaking of little mistakes that take a long
> >> time to find, what does W contain at the "done" label?
> >> ...
> >
> > My calculator said 2Dh, but after a cup of coffee my brain kicked in and
> > told me that addlw dosen't exist on the 12bit cores :o)
>
> Yeah, you're right, but shouldn't that have caused an assembly error? I
> wouldn't put that into the "take a long time to find" category since the
> assembler hands you the error on a silver platter.
>
Yep. I demand another tricky problem to debug as this one was clearly
faulty from the start :o)
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.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to spamBeGonepostmaster@spam@spam_OUTbookham.com.
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@091737
by
Olin Lathrop
> Ok, I "cheated". I ran it in the simulator. F is
> equal to 1 and C is equal to 0. You must prefix them
> with "0x".
Ah, that's more like it. Yet another reason to never use radix = HEX,
even though it's the default. I ALWAYS set radix to decimal.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@093807
by
Olin Lathrop
Bob Ammerman wrote:
> fire_torpedoes = B7
>
> bsf B3
> bsf fire_torpedoes
>
> bsf shadow.b3
> bsf shadow.fire_torpedoes
>
> The bitmap symbols would be stored in the symbol table as both a file
> address and a bit number, along with an indication that it was a bitmap
> symbol.
Check out my /INBIT and /OUTBIT preprocessor directives. See the PREPIC
documentation file at http://www.embedinc.com/pic. You write a
declaration in the project include file like this:
/outbit fire_torpedoes portb 3 0
This automatically (in my standard PORT module) causes RB3 to be set as an
output, in this case initialized low (last parameter). It also defines
FIRE_TORPEDOES_REG, FIRE_TORPEDOES_TRIS, FIRE_TORPEDOES_BIT, and
FIRE_TORPEDOES_PIN. You can write code like:
dbankif fire_torpedoes_reg ;set banks
bsf fire_torpedoes_pin ;bombs away
or:
dbankif shadow ;set banks for access to shadow reg
bsf shadow, fire_torpedoes_bit ;set shadow reg bit
movf shadow, w ;get new port register value
dbankif fire_torpedoes_reg ;set banks for port reg access
movwf fire_torpedoes_reg ;bombs away
I haven't yet added support for the 18 family LAT registers, but will Real
Soon Now (tm).
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@094409
by
Scott Dattalo
|
On Wed, 2 Apr 2003, Michael Rigby-Jones wrote:
{Quote hidden}> > -----Original Message-----
> > From: Andrew Warren [SMTP:
TakeThisOuTaiwspamCYPRESS.COM]
> > Sent: Wednesday, April 02, 2003 12:46 AM
> > To:
PICLISTEraseMEMITVMA.MIT.EDU
> > Subject: Re: [PIC]: Configuration bits
> >
> > Hey, by the way... Speaking of little mistakes that take a long
> > time to find, what does W contain at the "done" label?
> >
> > list p=16c54
> > #include p16c5x.inc
> >
> > list r = hex
> >
> > org 0
> >
> > movlw 0 ;3 * 0 = 0x00
> > addlw 3 ;3 * 1 = 0x03
> > addlw 6 ;3 * 2 = 0x06
> > addlw 9 ;3 * 3 = 0x09
> > addlw C ;3 * 4 = 0x0C
> > addlw F ;3 * 5 = 0x0F
> >
> > done: goto done
> >
> > org 1FF
> > goto 0
> >
> > end
> >
> My calculator said 2Dh, but after a cup of coffee my brain kicked in and
> told me that addlw dosen't exist on the 12bit cores :o)
That's weird, my slide rule gives me 0x13 (for a 14-bit core).
Scott
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@115736
by
William Chops Westfield
> Hey, by the way... Speaking of little mistakes that take a long
> time to find, what does W contain at the "done" label?
>
> list p=16c54
> #include p16c5x.inc
>
> list r = hex
>
> org 0
>
> movlw 0 ;3 * 0 = 0x00
> addlw 3 ;3 * 1 = 0x03
> addlw 6 ;3 * 2 = 0x06
> addlw 9 ;3 * 3 = 0x09
> addlw C ;3 * 4 = 0x0C
"C" is the definition for the Carry bit. It's value is 0, right? Numbers
can not begin with a letter, even if the default radix is hex?
> addlw F ;3 * 5 = 0x0F
Similarly, F is the defintion for the "file" destination (addw reg,f)
BillW
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@150409
by
Andrew Warren
|
|
Olin Lathrop <RemoveMEPICLISTEraseMEspam_OUTmitvma.mit.edu> wrote:
> > movlw 0 ;3 * 0 = 0x00
> > addlw 3 ;3 * 1 = 0x03
> > addlw 6 ;3 * 2 = 0x06
> > addlw 9 ;3 * 3 = 0x09
> > addlw C ;3 * 4 = 0x0C
> > addlw F ;3 * 5 = 0x0F
>
> OK, I'll bite. It sure looks like 3 * 15, or 45. If there's some
> hidden trick here, I guess I'm missing it.
As someone pointed out, my example was flawed (no "addlw"
instruction on the 12-bit core), but I guess it still served its
intended purpose, which was to disprove the statement that "The
include files .... eliminate the chance of you making a little
mistake that takes a long time to find." I'm aware that you
didn't mean "ALL little mistakes", but I figured that this
mistake, caused by the include file, was at least as common as
the one prevented by the include file.
In my example, the "hidden trick" is that C=0 and F=1, ONLY
BECAUSE I included Microchip's p16c5x.inc which defines them
that way. Without Microchip's include file, the assembler would
have properly flagged those two lines as errors.
{Quote hidden}> > What we want to do is constrain the assembler so that it ONLY
> > accepts CORRECT usage of RP0... And the only way to do that is
> > to remove Microchip's error-prone definition when we add the new
> > error-proof definition.
>
> Then what do you do in those cases where you want to access a named
> bit other than thru bit manipulation instructions, or to a shadow
> register. These cases are relatively rare, so I wouldn't mind a little
> extra syntax to disable the checking, but your method seems to
> proclude them altogether. For example:
>
> movlw (1 << abit) | (1 << anotherbit) ;make mask of combined
> bits movwf somereg ;set the new state
>
> or:
>
> bsf shadowreg, abit ;update shadow register of SOMEREG
I'd probably do something like:
#define RP0BIT 5
#define RP0 STATUS,RP0BIT
MOVLW (1 << RP0BIT)
MOVWF SOMEREG
BSF SHADOWREG,RP0BIT
> Also, while it would be nice to have some sort of type checking on
> bit number symbols, let's no loose sight of the fact that these
> kinds of errors are quite rare. I've written tens of thousands of
> lines of PIC assembler of dozens of projects, and I have no
> recollection of ever using a named bit with the wrong special
> function register.
You've never written BSF PORTA,LED when you meant BSF PORTB,LED?
Or typed BSF INTCON,INTEDG? Before #define was added to MPASM,
those errors -- judging from code I saw on the piclist and out in
the world, as well as from my own code -- were pretty common.
Before #define, it was really easy, in a program that used dozens
of flags, to lose track of which byte of RAM held a particular
flag, and there wasn't really a good alternative to
hand-checking the source code to find mismatch errors.
> Hmm. Maybe I should log all PIC coding errors for a while and see
> what kind of mistakes I do make. That might be useful to decide
> what kind of tool upgrades would be appropriate. Just from memory,
> the most common error I make is forgetting to add the ", w" after a
> file register instruction when I intended the result to go into W.
> Fortunately these are quick to find in debugging.
Yeah, I suppose that each of us has his own set of most-common
errors; arranging things so that the ASSEMBLER catches those
errors is almost as good as preventing yourself from making them
in the first place.
> The only error (in my coding) in the last month or two that took
> significant time to find was when I accidentally used the wrong
> temporary variable in the low priority interrupt routine of an
> 18F. .... when I implemented low and high priority interrupts it
> just didn't occur to me that I would need separate IREGs for the
> two interrupts (yes, I know, duh!).
Ouch. I'm sure we've all had similar "duh!" situations... My own
favorite way to generate a day of interrupt-routine debugging is
to call the same subroutine from both my main code and my ISR.
-Andy
=== Andrew Warren -- @spam@aiwRemoveMEEraseMEcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
2003\04\02@153358
by
Olin Lathrop
> You've never written BSF PORTA,LED when you meant BSF PORTB,LED?
> Or typed BSF INTCON,INTEDG?
Not that I recall. The first case is nicely taken care of with my /OUTBIT
preprocessor directive.
/outbit led portb 5 1 ;define LED as RB5, initialized to high
.
.
.
dbankif led_reg ;set banks for access to port with LED bit
bcf led_pin ;turn on the LED
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
More... (looser matching)
- Last day of these posts
- In 2003
, 2004 only
- Today
- New search...
