Searching \ for '[PIC]: Configuration bits' 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: 'Configuration bits'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Configuration bits'
2001\05\08@143534 by Fernando Antoniasse

flavicon
face
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

picon face
>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

face picon face
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
picon face
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

flavicon
face
> 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

flavicon
face
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_OUTjbTakeThisOuTspamjbarchuk.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

flavicon
face
> 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

flavicon
face
Hi Tim!

On Sun, 30 Mar 2003 .....shoppa_piclistKILLspamspam@spam@TRAILING-EDGE.COM wrote:

{Quote hidden}

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
jbspamKILLspamjbarchuk.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

face
flavicon
face
> 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

flavicon
face
> 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

flavicon
face
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

face picon face
> 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

flavicon
face
> But of course nothing beats the famous 'syntax error at or
> around line XXX'.
>
> Wouter van Ooijen

This reminds the HP 85 (http://www.hpmuseum.org/85.jpg,
http://www.hpmuseum.org/hp85.htm) many many years ago. When running a
basic program, it would tell you something like 'syntax error found',
with no line number. We used to spend hours locating the errors.

However, it was very advanced at the time.

Tal

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\03\31@040143 by Alan B. Pearce

face picon face
>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 .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2003\03\31@041840 by Jinx

face picon face
> Those with eidetic memories and superb programming skills
> may not need these safeguards. But I think most would benefit.
>
>
>             Russell McMahon

"eidetic" eh ? And here's me looking for an excuse to
use "rinky-dink"

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\03\31@082531 by Olin Lathrop

face picon face
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 listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2003\03\31@083829 by Bob Ammerman

picon face
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@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\03\31@181218 by Igor Pokorny

flavicon
face
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

flavicon
face
Igor Pokorny <KILLspamPICLISTKILLspamspammitvma.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 -- RemoveMEaiwTakeThisOuTspamcypress.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 spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2003\03\31@200840 by Andrew Warren

flavicon
face
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 -- TakeThisOuTaiwEraseMEspamspam_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 RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\03\31@234428 by Bob Barr

flavicon
face
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 listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body


'[PIC]: Configuration bits'
2003\04\01@080431 by Olin Lathrop
face picon face
> #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-requestspammitvma.mit.edu>

2003\04\01@150441 by Andrew Warren

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

> > #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.

   Only if I used those dumb include files... Which I don't, as you
   know, mostly because they don't define bits with #define.

   -Andrew

=== Andrew Warren -- RemoveMEaiwspam_OUTspamKILLspamcypress.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
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu>

2003\04\01@153735 by Dwayne Reid

flavicon
face
At 03:13 PM 3/30/03 -0500, EraseMEshoppa_piclistspamspamspamBeGoneTRAILING-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   <RemoveMEdwaynerKILLspamspamplanet.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-requestSTOPspamspamspam_OUTmitvma.mit.edu>

2003\04\01@161621 by Olin Lathrop

face picon face
> 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-requestSTOPspamspamEraseMEmitvma.mit.edu>

2003\04\01@170434 by William Chops Westfield

face picon face
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-requestspamBeGonespammitvma.mit.edu>

2003\04\01@184930 by Andrew Warren

flavicon
face
Olin Lathrop <EraseMEPICLISTspamEraseMEmitvma.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 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@spamspam_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-requestspamKILLspammitvma.mit.edu>

2003\04\02@022218 by hael Rigby-Jones

picon face
{Quote hidden}

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 TakeThisOuTpostmasterKILLspamspamspambookham.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

face picon face
> 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

face picon face
{Quote hidden}

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

face picon face
>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

face picon face
>>     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

picon face
{Quote hidden}

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

picon face
>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

picon face
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

picon face
> -----Original Message-----
> From: Olin Lathrop [SMTP:.....olin_piclistspamRemoveMEEMBEDINC.COM]
> Sent: Wednesday, April 02, 2003 2:46 PM
> To:   RemoveMEPICLISTspamspamBeGoneMITVMA.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@spamspam_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

face picon face
> 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

face picon face
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

face
flavicon
face
On Wed, 2 Apr 2003, Michael Rigby-Jones wrote:

{Quote hidden}

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

face picon face
>     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

flavicon
face
Olin Lathrop <RemoveMEPICLISTEraseMEspamspam_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}

   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@aiwRemoveMEspamEraseMEcypress.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

face picon face
>     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...