Olin Lathrop <PICLIST@mitvma.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.

> >     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 -- aiw@cypress.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